PostgreSQL již nebude tak moc SQL (diskuse)

[vain]

Nepostrádá už to dneska trochu smysl? Jsem doufal že den "na internetu nevěřím ani slovo" už mám za sebou.

[Käyttäjä 11133]

Tenhle mě pobavil až moc :)

[m1c4a1]

Bylo to vloženo včera ve 22:02.

[vain]

A jo, jsem blb, v rss to mělo dnešní čas stáhnutí. Tak beru zpět.

[Robert Krátký]

Nejsi blb. Bylo to schváleno později, než vloženo.

[mato]

ach jo .. z duse neznasam prvy april :/

[Ladicek]

Trochu k tématu: Why NoSQL is bad for startups

[default]

A já zase říkám: "Nauč se SQL. Jde v tom udělat úplně všechno." Asi bych měl napsat knihu.

[Ladicek]

Nauč se SQL. Jde v tom udělat úplně všechno.

S tím souhlasím. S jedním drobným dodatkem: půlka z toho bude bolet databázi i programátora. There's no silver bullet – ani v databázích.

[default]

S tím dodatkem nesouhlasím. Ještě jsem se nesetkal s případem, kdy by bolest databáze byla větší než bolest programátora*.

*Za předpokladu, že programátor zná SQL dané databáze. Za předpokladu, že se jedná o Oracle Database 10gR2 a vyšší.

[Mti.]

smutne je, ze tyto "vedome lzi" pak zustavaji lezet mezi normalnim textem. :-/ (ne, nenaletel sem, vim kdy to vyslo, ale v okamziku, kdy to na jednoho casem vyleze z ghoolglu, tak ho to bude zbytecne stvat)

no suchar, no.

[Käyttäjä 11133]

Však je to v kategorii humor. :)

[Mti.]

no... ano, je to moje chyba, ze si nevsimam kategorie, ale kdyz na mne vypadne clanek casem jako vysledek nejakeho hledani, kde ve skutecnosti je si nevsimnu urcite.

[Martin]

Proboha, co je to "klusterování"??

[mrzout]

nejhloupější na těhle rádobyvtipných aprílech je, že druhého dubna nezmizí a leckdo je čte o x dní později

[bezny uzivatel]

ja si myslim, ze na tom humoru je i neco vazneho. Vyvojari pgsql se mozna velmi dobre uvedomuji, ze vsechny ty ficurky, ktere v potu tvare naprogramovali mozna budou k nicemu, protoze svet bude zrat ten novy no-sql hype.

[default]

protoze svet bude zrat ten novy no-sql hype.

Nebude. To mi věř. O to se osobně postarám.

[Dalibor Smolík]

[flaxa]

pane Smolik, znate to prislovi 'kdo se smeje, nevi cemu, podoba se prihlouplemu...'

[Dalibor Smolík]

Do Postrgre jsem jen nahlédl, s MySql pracuji od roku 2001, mám na něm postaven svůj firemní systém. Takže základní informace o problematice SQL mám .. a nerad bych své nástroje měnil

[Dalibor Smolík]

Jo a tyhle věci mám v hledáčku taky

[default]

To nevysvětlíte. To musíte cítit.

[Michal Kubeček]

Zase tak černě bych to neviděl. Část se toho asi chytne, ale že by jich byla většina, to nehrozí. A jestli ano, taky dobře, aspoň bude méně konkurence…

[Heron]

NoSQL tu existuje déle než SQL. Akorát teď se toho chytli lidi, kteří z nějakého důvodu neumí používat SQL, šíří nesmysly ("na mnoho věcí transakce nejsou potřeba", "referenční integritu zajistí aplikace", "normální formy jsou na nic, raději si pro každý projekt vymyslíme vlastní jiné schéma" apod.). Rozhodně to nepůjde tak daleko, že by se stávájící SQL DB měly bát o svou pozici.

[default]

Akorát teď se toho chytli lidi, kteří z nějakého důvodu neumí používat SQL

Přesně tohle si myslím. Akorát nemám odvahu to tak narovinu napsat. Ještě by mě mohl někdo vnoci požádat v tmavém průchodu, abych mu zvednul tužku, která mu upadla.

[okbob]

Copak v Madridu, tam jsi za vodou :)

Někdy mám pocit, že v tom je nějaký hlubší smysl. K jakémukoliv racionálnímu názoru se pokaždé objeví protinázor - čím ujetější, tím pro řadu lidi přitažlivější (nevím proč - možná pan Jílek by o tom mohl pohovořit - snad sklony k paranoii, možná hledání neobsazené niky, možná samaritánství). Jenom, co jsem si zažil na vlastní kůži - přímý přístup k souborovému systému versus databáze, databáze versus SQL databáze, logika na klientu versus uložené procedury, denormalizace versus normalizace, řešení referenční integrity na klientu versus vestavěná referenční integrita - ale také ze života kreativismus versus evoluce, katolicismus versus lefébvrismus, politika, nacionalismus, ...

Jinak k NoSQL db - možná je to dobře, že se tu objevují. SQL určitě potřebuje konkurenci - a trochu živé vody. Je také pravda, že se SQL nasazovalo naprosto bez rozmyslu (u www backendů) - což zrovna u db je špatně. Sám se divím, že se třeba memcached bylo vynalezeno až tak pozdě a že o něm dodnes většina programátorů neví - když vidím, co se občas tlačí za smetí do databáze, tak se nedivím, že to nemůže fungovat. Na read/write projekty může být blob přístup to pravé ořechové, i když se bojím, že po čase to bude o ukládání blobů v SQL databázi (protože v SQL db nepřijdete o data) - a pak se zase někdo bude divit jak je to pomalé :(.

[default]

Copak v Madridu, tam jsi za vodou :)

Jasně. Zrovna minulý pátek jsem rezignovaně nechal borce zakomitovat TRUNCATE TABLE.

Ale jinak já s tím souhlasím. SQL databáze jsou všude a neprávem. Třeba tady ten systém, se kterým si tu v podniku hrajeme, má konfiguraci uloženou v databázi. Potom druhej systém má konfiguraci ve fajlu. To je mnohem jednodušší. Prostě jen přemlasknu soubor a je vymalováno. Líp se to verzuje, ikdyž je to binární. To v tom prvním případě je to složitější. Synchronizace sekvencí, hoši to díky evoluci dotáhli k dokonalosti, takže místy už neexistuje ani referenčí integrita, což má za následek nevysvětlitelné chování, protože se věci linkují jinak než by měly a tak dále.

Zase na druhou stranu má pro mě ta konfigurace v databázi výhodu — libovolné rozšíření systému může být dynamické. Přímo v PL/SQL si vytáhnu, co potřebuji. Kdybych to měl dělat pro ten druhý systém, tak si napřed budu muset napsat parser toho binárního bordelu a patrně bych musel sáhnout po Javě nebo něčem podobným. Takhle to mám konzistentní — vše je v PL/SQL.

Jeden opravdu neví, co je lepší. A teď babo raď!

[osvc1]

...konfigurace v databázi ...

to je jako si uriznout chleba k snidani na cirkularce ....

[default]

No, řekněme, že to není konfigurace typu písmenka zeleně, ikonky skrýt. Je to mnohem složitější. Ale to neznamená, že by to nemohlo být třebas v XML nebo v něčem podobném.

Ale zkusím jim navrhnut, aby si do tý databáze uložili i JDBC URL a credentials. Pardon, ono to tam už je.