SQL select

[Kolemjdoucí]

Jestliže nedošlo na ručně psané SQL anebo stored procedure na serveru, dosud jsi neměl tu čest s velkým reálným projektem, stane se to vždy, je to jistota jako že ráno vyjde Slunce. Dál se k tomu nevyjadřuji.

[Reklama]

[Žížala]

A nestačilo by prostě tohle?

Kód: [Vybrat]

SELECT DISTINCT id FROM tabulka WHERE attribut = 'a' AND id IN (SELECT id FROM test WHERE attribut <> 'a') ORDER BY id


[Žížala]

Sakra správně má být

Kód: [Vybrat]

SELECT DISTINCT id FROM test WHERE attribut = 'a' AND id IN (SELECT id FROM test WHERE attribut <> 'a') ORDER BY id

[Ondrej Nemecek]

Jestliže nedošlo na ručně psané SQL anebo stored procedure na serveru, dosud jsi neměl tu čest s velkým reálným projektem, stane se to vždy, je to jistota jako že ráno vyjde Slunce. Dál se k tomu nevyjadřuji.

Trochu nanic příspěvek. Pokud byste uvedl příklady ze své praxe, posloužil byste lépe sobě i ostatním. Správně byste měl uvést segment, kde se pohybujete (jaké projekty rozsahem, typem, pro koho a s jakou životností) a jaké tam jsou zvyklosti. Asi byste zjistil, že segment Raskala je jiný a že tam je prostě jiná praxe. A nemusí jít zrovna o školní úlohy.

No a po technické stránce není stored procedure jako stored procedure - v některých případech může fungovat s ORM bez problémů. Každé rozumné ORM navíc umožňuje používat holé sql, čímž se stírá rozdíl ORM/neORM a lze se tím vyhnout nevýhodám obojího a spojit výhody obojího. Tož asi tak.

[Kit]

... Každé rozumné ORM navíc umožňuje používat holé sql, čímž se stírá rozdíl ORM/neORM a lze se tím vyhnout nevýhodám obojího a spojit výhody obojího. Tož asi tak.

ORM je stejně jen berličkou pro ty, kteří SQL neumí. Kombinací ORM a SQL vznikne kočkopes, který věčně válčí se špinavou cache.

[Reklama]

[Kolemjdoucí]

Trochu nanic příspěvek.

Nanic je každá diskuze o užitečnosti ORM ve spojitosti s SQL DB. Komu se z nějakého důvodu líbí styl práce s daty, nechť použije vhodnější NoSQL, nemusí se zdržovat ani s ORM ani s SQL DB.

[Ondrej Nemecek]

Nanic je každá diskuze o užitečnosti ORM ve spojitosti s SQL DB. Komu se z nějakého důvodu líbí styl práce s daty, nechť použije vhodnější NoSQL, nemusí se zdržovat ani s ORM ani s SQL DB.

Tak zaprve záleží, jestli si můžete vybrat. Když si vybrat nemůžete a máte ORM daný, potřebujete o tom co nejvíc vědět, abyste nedojel na naivní použití. A když si vybrat můžete, potřebujete taky co nejvíc vědět, abyste si správně vybral :-D

Jinak, když už něco jiného. tak rovnou objektovou databázi.

[Raskal]

Jestliže nedošlo na ručně psané SQL anebo stored procedure na serveru, dosud jsi neměl tu čest s velkým reálným projektem, stane se to vždy, je to jistota jako že ráno vyjde Slunce. Dál se k tomu nevyjadřuji.

Segment webovych aplikaci je narocny na optimalizaci a to predevsim databaze na backendu (nejen SQL a DDL, ale i DB stroje). A nejak si nedovedu predstavit praci s ORM bez znalosti SQL. Kazdy, kdo chce pouzivat ORM, by mel SQL znat alespon na takove urovni, aby vedel, co mu to ORM generuje za dotazy. Co pises, je nicim nepodlozene tvrzeni, ktera je v rozporu s tim, co jsem napsal v jednom z nimulych prispevku: "Backendy pro Webove aplikace navrhuji a implementuji...". Navrh a optimalizace DB schematu je soucasti me prace. S ORM jsem se uspesne preklenul pres to, abych psal kazde sql pouzite v aplikaci. Dost spatne se refaktoruje aplikace, ktera ma v sobe x100 zadratovanych SQL prikazu a nektere z nich je treba utvaret dynamicky v zavislosti na datech. Vhodne pouziti ORM tento problem eliminuje a dovoluje se soustredit na reseny problem. Zpusob psani aplikaci na strane DB je, podle meho narozu, zastaraly a nepruzny. SQL a PL/SQL na to nejsou vhodne nastroje, ackoliv bylo dostatek snahy aby byly. Presne timto zpusobem psani aplikaci jsem zacal nekdy cca pred 15 lety a dosel jsem k tomu, ze vyuzivam sluzeb ORM. ORM je nastroj a jako takovy se musi pouzivat spravne, jinank je to ke skode. Toto je hlavni problem proc na nej lidi nadavaji - neznalost a nevhodne pouziti.

Chce to trochu nadhledu a mene do ostatnich kopat.

[Kit]

Tak zaprve záleží, jestli si můžete vybrat. Když si vybrat nemůžete a máte ORM daný, potřebujete o tom co nejvíc vědět, abyste nedojel na naivní použití. A když si vybrat můžete, potřebujete taky co nejvíc vědět, abyste si správně vybral :-D

Pokud mám ORM dané, tak stejně nebudu vědět nic, protože na rozdíl od SQL k tomu není žádná univerzální dokumentace. Takže o ORM nepotřebuji vědět vůbec nic - zkušenosti z jednoho ORM u jiného ORM nevyužiji.

A pokud si vybrat můžu, tak jednoznačně SQL. Je fakt, že mezi jednotlivými implementacemi jsou velké rozdíly - např. hstore z PostgreSQL by se jako řešení dotazu velmi dobře hodil, ale Firebird tím nedisponuje. Vůbec však netuším, které ORM podporuje hstore a které ne. A je mi to jedno, protože s ORM dělat nebudu.

[Kit]

Dost spatne se refaktoruje aplikace, ktera ma v sobe x100 zadratovanych SQL prikazu a nektere z nich je treba utvaret dynamicky v zavislosti na datech.

SQL dotazy mají v aplikaci své místo a není tedy problém s refaktorováním ani dynamickým generováním. Pokud některé z nich jsou implementačně závislé (každý zákazník to chce jinak), umístím je do databáze.

[Raskal]

... Každé rozumné ORM navíc umožňuje používat holé sql, čímž se stírá rozdíl ORM/neORM a lze se tím vyhnout nevýhodám obojího a spojit výhody obojího. Tož asi tak.

ORM je stejně jen berličkou pro ty, kteří SQL neumí. Kombinací ORM a SQL vznikne kočkopes, který věčně válčí se špinavou cache.

To, co to ORM dela je pevne v rukou vyvojare. Pokud ho spatne pouzijes, pak se spatne chova.

Spinava cache je ve vsech distribuovanych systemech, ktere porizuji kopii dat urcenou ke cteni a modifikaci, takze to nelze pricitat specielne k problemum ORM.

Souhlasim s tim, ze tandem DB + ORM neni stastne reseni. Bohuzel se za tech nekolik desitek let do RDBMS nainvestovalo tolik, ze se i dnes vyplati je pouzivat. Lepsi by bylo nemit ORM vrstvu, ale zaroven mit k dispozici objekty (resp. funkce) bez zbytecne mezivrstvy. Bohuzel neznam zadny takovy produkt, ktery by tento handicap odstranoval a zaroven zachoval vyhody, ktere mainstreamove relacni DB poskytuji.

[Ondrej Nemecek]

Pokud mám ORM dané, tak stejně nebudu vědět nic, protože na rozdíl od SQL k tomu není žádná univerzální dokumentace. Takže o ORM nepotřebuji vědět vůbec nic - zkušenosti z jednoho ORM u jiného ORM nevyužiji.

A pokud si vybrat můžu, tak jednoznačně SQL. Je fakt, že mezi jednotlivými implementacemi jsou velké rozdíly - např. hstore z PostgreSQL by se jako řešení dotazu velmi dobře hodil, ale Firebird tím nedisponuje. Vůbec však netuším, které ORM podporuje hstore a které ne. A je mi to jedno, protože s ORM dělat nebudu.

Ještě byste byl rád za ORM - konkrétní ORM nástroj naopak představuje standard, který je výhrou v porovnání s lepením sql jak koho při psaní té nebo oné applikace napadlo.

[Ondrej Nemecek]

(...) Spinava cache je ve vsech distribuovanych systemech, ktere porizuji kopii dat urcenou ke cteni a modifikaci, takze to nelze pricitat specielne k problemum ORM.

Souhlasim s tim, ze tandem DB + ORM neni stastne reseni. Bohuzel se za tech nekolik desitek let do RDBMS nainvestovalo tolik, ze se i dnes vyplati je pouzivat. Lepsi by bylo nemit ORM vrstvu, ale zaroven mit k dispozici objekty (resp. funkce) bez zbytecne mezivrstvy. Bohuzel neznam zadny takovy produkt, ktery by tento handicap odstranoval a zaroven zachoval vyhody, ktere mainstreamove relacni DB poskytuji.

No a zkoušel jste nějaké objektové databáze? V době, kdy se už docela běžně používá map-reduce apod. by mohly bok po boku NoSQL databází proniknout do praxe, ne?

[Raskal]

No a zkoušel jste nějaké objektové databáze? V době, kdy se už docela běžně používá map-reduce apod. by mohly bok po boku NoSQL databází proniknout do praxe, ne?

Objektove DB jsem par zkusil a jsou samozrejme nejlepe vyhovujici, protoze zde neni zbytecna mezivrstva.
Zakaznikovi se neda jen tak predat projekt udelany nad jinou nez mainstreamovou DB, protoze ho pak casto bude udrzovat nekdo jiny a kolik vyvojaru dobre ovlada nejakou objektovou DB...

Map-reduce a NoSQL resi jine kategorie problemu nez zminuji a uz treba s transakcema a integritnimi omezenimi to neni zrovna v poradku. Zkousel jste nad map-reduce navrhnout datove schema treba inzertniho serveru nebo eshopu, ktery je jako komercni reseni minen zcela vazne? Ja myslim, ze to zatim neni dost dobre mozne. Do toho dynamicky vyvoj datoveho modelu a jeho refaktoring. A i kdyby to bylo mozne (spise akademicka predstava), tak na to ja ani zakaznik nema kapacity.

[Kit]

To, co to ORM dela je pevne v rukou vyvojare. Pokud ho spatne pouzijes, pak se spatne chova.

K ORM není ani pořádný manuál, tak jak ho mohu použít správně? Vidím ho jen jako zbytečnou mezivrstvu, která hází vývojáři klacky pod nohy a nutí ho učit se nový jazyk, který není nijak ustálený.

Spinava cache je ve vsech distribuovanych systemech, ktere porizuji kopii dat urcenou ke cteni a modifikaci, takze to nelze pricitat specielne k problemum ORM.

Proto je lepší vyhnout se zbytečnému pořizování kopií dat. SQL databáze mají mnohem lepší cache, které nemusím nijak hlídat.

Souhlasim s tim, ze tandem DB + ORM neni stastne reseni. Bohuzel se za tech nekolik desitek let do RDBMS nainvestovalo tolik, ze se i dnes vyplati je pouzivat. Lepsi by bylo nemit ORM vrstvu, ale zaroven mit k dispozici objekty (resp. funkce) bez zbytecne mezivrstvy. Bohuzel neznam zadny takovy produkt, ktery by tento handicap odstranoval a zaroven zachoval vyhody, ktere mainstreamove relacni DB poskytuji.

Lepší je nemít ORM vrstvu a s relačními daty v relační databázi pracovat relačně. Ta objektová mezivrstva je zbytečná i z toho důvodu, že jen málo vývojářů programuje skutečně objektově...