Rada při návrhu db tabulek

[BoneFlute]

problémy lze dlouho řešit triviálními "hinty". Pak to narazí na mantinel, kde už s tím nejde hnout

Opět. V tomto se hrubě neshodnem.

BoneFlute:
Je trivka? Potkal jsem se s tím, že jeden dotaz jsem napsal asi deseti způsoby - unionem vevnitř, unionem venku, pomocí OR, pomocí materializované CTE, jednou byla podmínka tady, jednou ekvivalentní ale jiná tam, jednou se použilo DISTINCT ON, jednou radši window funkce, jednou GROUP BY atd. atd.... Moc si nedokážu představit, jak by takové hinty vypadaly....

Tak já sbírám různé špeky, protože mě samozřejmě zajímá, jak by se to dalo nebo nedalo tím ORM řešit. Takže když by si měl něco k dispozici budu moc rád.

Moc nevěřím, že by šel napsat ORM tak, aby opravdu uměl uživatelsky pochopitelně  pokrejt a generovat opravdu všechny možnosti vyjádření toho samého dotazu, a přitom byl pořád jednoduchej a elegantní. Věřil bych, že jde napsat něco, co pokreje většinu běžně používanejch technik, ale že by opravdu obsáhnul 100% vyjadřovacích schopností SQL bych byl dosti skeptickej.
Co si dokážu představit je query builder, který to zvládne, a kterým nakrmím nějaký ORM. Ale nikoli něco, co mne od SQL odstíní. Ale třeba se pletu...

Nedokážu kategoricky prohlásit, že sto procent. Samozřejmě v mém případě je to taky víra.

Já vím, že relační databáze jsou skvělá věc, která má věky ověřené všechno. Má můj respekt. Na druhou stranu když vidím lidi, čeho všeho jsou neschopni s databází, tak nevidím důvod, proč by to nemohl dělat stroj. Tak blbej dokáže bejt taky.

Domnívám se, že mnoho despektu k ORM od lidí jako Pavel Stěhule vyvěrá z toho, že příliš mnoho ORMek jsou velice špatné. Autoři (asi) chtěli za každou cenu objekty, a ztratili ze zřetele respekt k matematické dokonalosti relačních databází.
Pak jsou tu třeba takové výjimky, jako iBatis, které to mapování vzal za dost dobrý konec (doufám, že mu moc nefandím, viděl jsem ho jen zběžně, ale dost zaujal).
To ale neznamená, že by nemohli ORM dozrát, a být plnohodnotnou evolucí SQL databází. Despekt na základě zkušenosti je jedna věc; vytvářet z toho tvrzení, že to nejde, je zbrklé.

Nemluvě o druhé straně barikády, kdy jsou lidé, kteří si při slově ORM odplivnou, a nestojí jim to ani za úvahu. Čímž pak samozřejmě diskuse s takovými lidmi trpí. Nic o tom neví.

[Reklama]

[Miroslav Šilhavý]

Na druhou stranu když vidím lidi, čeho všeho jsou neschopni s databází, tak nevidím důvod, proč by to nemohl dělat stroj. Tak blbej dokáže bejt taky.

Já mám právě ten pocit, že to celé je řešení falešného dilematu: dělat to blbě a složitě vs. dělat to blbě a aspoň jednoduše.

V tom ORM a objektové databáze vítězí - a v praxi je přebytek programátorů bez znalostí do hloubky, a nedostatek se znalostmi. To mluví pro ORM.

Ono je takové hloupé udělat aplikaci nad ORM nebo objektovou databází, a pak si vzpomenout, např., že chci hlídat konzistenci. Třeba i složitý mechanismus na hlídání konzistence. Pak se to musí psát v aplikaci a doufat, že aspoň něco z toho ORM přenese na databázi. Zbytek poběží v aplikaci - tj. data se budou muset po síti nebo socketem přenést z DB do aplikace a odedřít to, co může být out-of-box.

Stejně tak, databázový systém (ať už to je RDBMS nebo něco jiného) může optimalizovat svoji práci teprve ve chvíli, kdy má nápovědy. Kdy ví, že určitá hodnota "zde" má nějaký vztah k hodnotě "onde" (0:n - m:n). Toto si ten stroj nemůže domyslet, protože maximálně ví, jak to s daty vypadalo před chvílí (statistiky), ale nemá jistotu, jestli to platí ještě teď, nebo bude platit za sekundu. Aplikace to vědět může, ale ta už stojí v místě, kam je potřeba na takovou práci data přenést (zdlouhavé, rozežrané).

Ale jako taky znám případy, kdy se nic takového nemusí řešit a je úplně jedno, jestli jsou data sourodá v čase, neřku-li v transakci. Tam pak může nerelační přístup k problému ušetřit práci programátora. Obvykle to ale tíhne spíš k ACID požadavkům.

Neznám moc dobrých programátorů, kteří by - po dobrém poznání obou způsobů - preferovali objektový přístup. Většinou se to pojilo s tím, že RDBMS uměli mizerně (jak jste psal), a objektový přístup byl záchranný kruh.

[Miroslav Šilhavý]

(omyl, smazáno)

[PanVP]

Tak co? Už jste něco vyřešili? 

[BoneFlute]

Na druhou stranu když vidím lidi, čeho všeho jsou neschopni s databází, tak nevidím důvod, proč by to nemohl dělat stroj. Tak blbej dokáže bejt taky.

Já mám právě ten pocit, že to celé je řešení falešného dilematu: dělat to blbě a složitě vs. dělat to blbě a aspoň jednoduše.

V tom ORM a objektové databáze vítězí - a v praxi je přebytek programátorů bez znalostí do hloubky, a nedostatek se znalostmi. To mluví pro ORM.

Ono je takové hloupé udělat aplikaci nad ORM nebo objektovou databází, a pak si vzpomenout, např., že chci hlídat konzistenci. Třeba i složitý mechanismus na hlídání konzistence. Pak se to musí psát v aplikaci a doufat, že aspoň něco z toho ORM přenese na databázi. Zbytek poběží v aplikaci - tj. data se budou muset po síti nebo socketem přenést z DB do aplikace a odedřít to, co může být out-of-box.

Stejně tak, databázový systém (ať už to je RDBMS nebo něco jiného) může optimalizovat svoji práci teprve ve chvíli, kdy má nápovědy. Kdy ví, že určitá hodnota "zde" má nějaký vztah k hodnotě "onde" (0:n - m:n). Toto si ten stroj nemůže domyslet, protože maximálně ví, jak to s daty vypadalo před chvílí (statistiky), ale nemá jistotu, jestli to platí ještě teď, nebo bude platit za sekundu. Aplikace to vědět může, ale ta už stojí v místě, kam je potřeba na takovou práci data přenést (zdlouhavé, rozežrané).

Ale jako taky znám případy, kdy se nic takového nemusí řešit a je úplně jedno, jestli jsou data sourodá v čase, neřku-li v transakci. Tam pak může nerelační přístup k problému ušetřit práci programátora. Obvykle to ale tíhne spíš k ACID požadavkům.

Neznám moc dobrých programátorů, kteří by - po dobrém poznání obou způsobů - preferovali objektový přístup. Většinou se to pojilo s tím, že RDBMS uměli mizerně (jak jste psal), a objektový přístup byl záchranný kruh.

Já nemám zájem řešit, že ORM jsou nekvalitně napsané, a díky tomu jsem schopen napsat lepší dotaz pomocí čistého SQL.
Já nemám zájem řešit, že i dnešní nekvalitní ORM jsou v některých situacích výhodnějších.
Mám zájem řešit, že zda dokáže stroj vytvořit stejně kvalitní dotaz do relační databáze jako člověk; to ale nemáš zájem řešit ty.

Tudíž za mě všechno.

[Reklama]

[Miroslav Šilhavý]

Mám zájem řešit, že zda dokáže stroj vytvořit stejně kvalitní dotaz do relační databáze jako člověk; to ale nemáš zájem řešit ty.

Zredukoval jste tu otázku až příliš. Kvalitní dotaz - co si pod tím představujete? Zkusím popsat, co si před tím představuju já.

Každá databáze se dá na úrovni uložení dat realizovat různě - vazbami, sloupci, složenými strukturami. Ta samá data, s tím samým smyslem, můžete uložit mnoha způsoby. Ten způsob volí programátor, který má představu, jak data porostou, jak budou rozložené hodnoty a jak budou používána (transakčně, pro častý zápis, pro čtení). Dál potřebuje DB nějaké indexy, aby dohledání hodnoty bylo rychlé. To taky musí rozhodnout člověk.

Nic z toho nejde nechat na stroji, protože vstupem jsou předpoklady (nejde to vyčíst z dat samotných).

Dovedu si však představit situaci, že databázi řeknu (nějakým způsobem - ať už přes SQL, nebo ORM nebo whatever else) vše potřebné. Popíšu jí data, aby je ultimativně chápala. Sdělím jí, jak budou užívána a jak budou rozložené hodnoty, jak data porostou do délky.

Pokud toto všechno splním, pak si dovedu představit, že stroj dokáže sestavit ideální dotaz a databáze ideální plán na vykonání.

A to je to, k čemu jsem se vyjadřoval a možná neuměl vysvětlit. Takto ultimativně popsat situaci, aby stoj mohl sestavovat dotazy ideálně, by podle mě bylo složitější, než je současný stav RDBMS / SQL.

[BoneFlute]

Mám zájem řešit, že zda dokáže stroj vytvořit stejně kvalitní dotaz do relační databáze jako člověk; to ale nemáš zájem řešit ty.

Každá databáze se dá na úrovni uložení dat realizovat různě - vazbami, sloupci, složenými strukturami. Ta samá data, s tím samým smyslem, můžete uložit mnoha způsoby.

Kolik je těch způsobů? Vezměme si třeba na paškál PG jako reprezentanta známé, a dostatečně schopné databáze.

Ten způsob volí programátor, který má představu, jak data porostou, jak budou rozložené hodnoty a jak budou používána (transakčně, pro častý zápis, pro čtení). Dál potřebuje DB nějaké indexy, aby dohledání hodnoty bylo rychlé. To taky musí rozhodnout člověk.

Nic z toho nejde nechat na stroji, protože vstupem jsou předpoklady (nejde to vyčíst z dat samotných).

Nesouhlasím. Jistě, některé situace opravdu ne, ale v mnoha případech lze zvolit strategie kdy člověka lze se ziskem eliminovat.

Dovedu si však představit situaci, že databázi řeknu (nějakým způsobem - ať už přes SQL, nebo ORM nebo whatever else) vše potřebné. Popíšu jí data, aby je ultimativně chápala. Sdělím jí, jak budou užívána a jak budou rozložené hodnoty, jak data porostou do délky.

Pokud toto všechno splním, pak si dovedu představit, že stroj dokáže sestavit ideální dotaz a databáze ideální plán na vykonání.

Ano. Toto je úvaha, o kterém se chci bavit.

Takto ultimativně popsat situaci, aby stoj mohl sestavovat dotazy ideálně, by podle mě bylo složitější, než je současný stav RDBMS / SQL.

Podle mně ne. Proč si to myslíš?

Abych taky odpověděl první: Ty tu sice používáš výrazy jaky "ultimativně", "všechno" a podobně, aby si vyjádřil své přesvědčení, že toho je strašně moc. Ale já se naopak domnívám, že na každý scénář uložení dat existuje několi málo variant - ať hodím cifru, dejme tomu tři. Takže pokud budu štelovat ukládání struktury tak vybírám mezi třemi scénáři (a navíc jen v případě, když náhodou default nevyhovuje, což většinou vyhovuje). To mi přijde jako usnadnění.

Na závěr, co odpůrci ORM (nebo spíše ti, co byli ORM znechuceni) nedoceňují je skutečnost, že ORM vytváří mnohem čitelnější rozhraní pro datovej model. Relační je super, je mocnej a všechno. Ale není to něco co je nám, pokud nejsem matematik, pohodlné. Takže pokud budu mít ORM ve stylu iBatis, a budu potřebovat nějaký hrozně moc optimalizovaný dotaz do databáze, tak ho tam furt můžu narvat ručně, ale navenek se to bude číst a používat pohodlně. (Ostatně je to osvědčený způsob, který se používá v programovacích jazycích leta.) To je důvod proč se ORM furt znova vymejšlejí - usnadnění práce, lepší používání.

[Miroslav Šilhavý]

...

Proč si myslím, že to nejde: dotaz, aby byl jasné "co chci" se určitě dá sestavit jednoduše. SQL či přes ORM - to jsou jen dva způsoby, jak sdělit svoje přání o tom, jaká data chci naservírovat. (query-language)

Stroj musí úlohu provést. To dokáže vždy - i na tom se (asi) shodneme. Nám jde o to, aby to dělal efektivně.

Výkon není závislý na tom, jak dobře napíšu dotaz.
Výkon je závislý na tom, jak dobře napíšu dotaz pro daný způsob, jakým jsou data uložena (zindexována apod.).

Těch způsobů, jak uložit a zindexovat data a jak sestavit plán pro vykonání dotazu, je nepřeberné množství. I kdybychom uvažovali o prostém sekvenčním čtení, musí se engine rozhodnout, v jakém pořadí načte entity, aby bylo filtrování kritérií efektivní. Jakmile se objeví možnost užití indexů a přidají se vnořené smyčky, roste závratně množství možností, jak to hardware zpracuje. Z těchto možností potřebujeme co nejdřív eliminovat ty, ke kterým máme dostatek informací, že efektivní být nemůžou a u zbylých odhadnout, jak by takový postup trval, kolik paměti by vyžádal apod. (query-plan)

Vyjadřuju se trochu srozumitelně?
Dál budu odpovídat až zítra, teď dobrou noc. :-)

[BoneFlute]

...

Proč si myslím, že to nejde: dotaz, aby byl jasné "co chci" se určitě dá sestavit jednoduše. SQL či přes ORM - to jsou jen dva způsoby, jak sdělit svoje přání o tom, jaká data chci naservírovat. (query-language)

Stroj musí úlohu provést. To dokáže vždy - i na tom se (asi) shodneme. Nám jde o to, aby to dělal efektivně.

Výkon není závislý na tom, jak dobře napíšu dotaz.
Výkon je závislý na tom, jak dobře napíšu dotaz pro daný způsob, jakým jsou data uložena (zindexována apod.).

Těch způsobů, jak uložit a zindexovat data a jak sestavit plán pro vykonání dotazu, je nepřeberné množství. I kdybychom uvažovali o prostém sekvenčním čtení, musí se engine rozhodnout, v jakém pořadí načte entity, aby bylo filtrování kritérií efektivní. Jakmile se objeví možnost užití indexů a přidají se vnořené smyčky, roste závratně množství možností, jak to hardware zpracuje. Z těchto možností potřebujeme co nejdřív eliminovat ty, ke kterým máme dostatek informací, že efektivní být nemůžou a u zbylých odhadnout, jak by takový postup trval, kolik paměti by vyžádal apod. (query-plan)

Nic z toho nedělá člověk. Tudíž to není pro téma ORM relevantní.

Abych poskytl nějaký materiál:
1/ Mám nějakou tabulku. V těch je několik sloupců, část z nich jsou cizí klíče, tedy automaticky indexovaný. Pak tam tedy mám pár sloupců, podle kterých budu nebo nebudu vyhledávat a tudíž je třeba se rozhodnout zda bude vhodné tam dát index.
2/ Mám zájem o nějaká data přes několik tabulek. Ty tabulky mohu pojoinovat různým způsobem. Těch způsobů není strašně moc, jsou dva nebo tři.
Toliko výchozí podmínka. Jak to vidím já:

1. řešení: ORM může sledovat cenu jednotlivých dotazů a vytvářet si statistiku a podle toho se rozhodnout, že zde je třeba dát index. (lehká variace na JIT) S tímto řešením mám velice dobré zkušenosti. Zvláště u skládání dotazů přes joiny.

2. řešení: Řekne se, že chci použít konkrétní strategii vytváření dotazu. U definování indexů by to asi šlo taky, ale už je to trochu divný, a nechal bych to na prvním řešení.

3. řešení: Je to tak velká exotika, že tam napíšu ruční SQL. Není se za co stydět.

Shrnuto, stroj vždycky ví nejlíp, jak poskládat dotaz. Má ty samé informace jako člověk, a dřív a rychleji. Takže dokáže lépe reagovat.
Vytváří se neoptimální plán? Může zkusit jiný. Stroj ví, proč je ten plán neoptimální, ví, který je vhodný pro jakou situaci. Ví, zda nad tím sloupcem jsou indexy. Ví kolik tam těch dat je. Ví, jak často se zapisuje nebo jak čte.
Stroj ví, jak jsou data a dotazy používány, lépe než člověk, a dokáže se jim lépe a ryhleji přizpůsobit, lépe zvolit řešení.
No a v konečném důsledku, nikdo tu nepropaguje, že v tom 0.001% případů tam do toho tomu ORMku nemohu hrábnout.

Jediné, co stroj nedokáže je rozhodnout - "to, že toto trvá tři minuty je v pořádku, protože já chci aby si ředitel počkal, chci ho totiž naštvat".

[Pavel Stěhule]

Já nemám zájem řešit, že ORM jsou nekvalitně napsané, a díky tomu jsem schopen napsat lepší dotaz pomocí čistého SQL.
Já nemám zájem řešit, že i dnešní nekvalitní ORM jsou v některých situacích výhodnějších.
Mám zájem řešit, že zda dokáže stroj vytvořit stejně kvalitní dotaz do relační databáze jako člověk; to ale nemáš zájem řešit ty.

Tudíž za mě všechno.

To, že ORM dokáže vygenerovat kvalitní dotaz bych si asi dovedl představit. U ORM vidím, ale i jiné problémy. Tím prvním je, že těžko může ORM vyřešit ISAM (iterační zpracování dat). Jakmile programátor použije cyklus (protože je tak zvyklý a dobře se mu tak uvažuje a pracuje), tak těžko už ORM může převést tuto operaci na hromadný SQL příkaz.

Některá ORM si drží vlastní cache - patrně aby urychlily provádění cyklů nad daty. K tomu potřebují vlastní transakční manager a vlastní lock manager - to už je docela brutálně komplexní, a pokud se to začne nějak tlouct s transakčním a lock managmentem v databázi, tak je to dost komplexní, křehké a programátoři do takových systémů odmítají sáhnout.

Dovedu si představit ideální ORM - ale aby ho někdo uměl správně používat, tak stejně musí hodně do hloubky rozumět SQL a relačním databázím, a u složitějších aplikací komplexnost ORM je brutální. Kdyby si programátoři napsali vlastní vrstvu pro operace a procesy, tak ve výsledku si ušetří mraky času a nervů.

Dost často se napíše prototyp nebo aplikace verze 1.0 s ORM - funguje to nad demo daty a funguje to pro menší zákazníky s pár set uživately a pár desítky GB. Pak se firmě povede protlačit produkt do nějakého většího korporátu (což je byznysově ideální), ale máte  stovky tisíc uživatelů, mnohem větší databáze, a rok - dva se řeší tuning, sizing, s většími nebo menšími úspěchy - spálí se na tom mraky hodin, a pak se napíše verze dvě bez ORM - s výkonem o 2-3 řády vyšším. Ale ten přepis stojí peníze, a nikomu se do toho moc nechce, protože už se spálilo mraky peněz na customizacích, tuningu, horizontálním škálování, ...

ORM fungují pro menší data, pro data, kde nikdy nebudete dělat hromadné operace. V opačném případě jsou s tím pekelné problémy, a to co ušetříte na programování, to 10x zaplatíte na supportu, tuningu, a řešení různých performance issue

[Google CTCCTCGGCGGGCACGTAG]

Jakmile programátor použije cyklus (protože je tak zvyklý a dobře se mu tak uvažuje a pracuje), tak těžko už ORM může převést tuto operaci na hromadný SQL příkaz.

to podle me v modernim SQL moc nepotrebujete, jde to nahradit window funkcemi

treba ten vas priklad s okresy bych v peeewee napsal nejak tak

Kód: [Vybrat]

class City(Model):
    district = IntegerField()
    inhabitants = IntegerField()

CityAlias = City.alias()

subquery = (CityAlias
            .select(
                CityAlias.district,
                CityAlias.inhabitants,
                fn.ROW_NUMBER().over(
                    partition_by=[CityAlias.district],
                    order_by=[CityAlias.inhabitants.desc()]).alias('rn')))

query = (City.select(subquery.c.district, subquery.c.inhabitants).from_(subquery).where(subquery.c.rn <= 10))

print(query)

vygeneruje takove SQL

Kód: [Vybrat]

SELECT `t1`.`district`,
       `t1`.`inhabitants`
FROM   (
                SELECT   `t2`.`district`,
                         `t2`.`inhabitants`,
                         ROW_NUMBER() OVER (PARTITION BY `t2`.`district` ORDER BY `t2`.`inhabitants` DESC) AS `rn`
                FROM     `city`                                                                            AS `t2`) AS `t1`
WHERE  (
              `t1`.`rn` <= 10)

kdybych do toho zacal pridavat nejake joiny, tak ten ORM kod bude kratsi nez generovane SQL, navic si v ORM mohu napsat obecne funkce na vytvareni podobnych dotazu

[Google CTCCTCGGCGGGCACGTAG]

ORM fungují pro menší data, pro data, kde nikdy nebudete dělat hromadné operace. V opačném případě jsou s tím pekelné problémy, a to co ušetříte na programování, to 10x zaplatíte na supportu, tuningu, a řešení různých performance issue

coz je blbost, moderni ORM funguji transparentne, vite, jaky dotaz to vygeneruje a muzete vygenerovat temer cokoliv

[Google CTCCTCGGCGGGCACGTAG]

doporucuji se podivat na http://docs.peewee-orm.com/en/latest/ , coz je podle me ORM udelane spravne, pripadne SQLAlchemy

[Pavel Stěhule]

Jakmile programátor použije cyklus (protože je tak zvyklý a dobře se mu tak uvažuje a pracuje), tak těžko už ORM může převést tuto operaci na hromadný SQL příkaz.

to podle me v modernim SQL moc nepotrebujete, jde to nahradit window funkcemi

treba ten vas priklad s okresy bych v peeewee napsal nejak tak

Kód: [Vybrat]

class City(Model):
    district = IntegerField()
    inhabitants = IntegerField()

CityAlias = City.alias()

subquery = (CityAlias
            .select(
                CityAlias.district,
                CityAlias.inhabitants,
                fn.ROW_NUMBER().over(
                    partition_by=[CityAlias.district],
                    order_by=[CityAlias.inhabitants.desc()]).alias('rn')))

query = (City.select(subquery.c.district, subquery.c.inhabitants).from_(subquery).where(subquery.c.rn <= 10))

print(query)

vygeneruje takove SQL

Kód: [Vybrat]

SELECT `t1`.`district`,
       `t1`.`inhabitants`
FROM   (
                SELECT   `t2`.`district`,
                         `t2`.`inhabitants`,
                         ROW_NUMBER() OVER (PARTITION BY `t2`.`district` ORDER BY `t2`.`inhabitants` DESC) AS `rn`
                FROM     `city`                                                                            AS `t2`) AS `t1`
WHERE  (
              `t1`.`rn` <= 10)

kdybych do toho zacal pridavat nejake joiny, tak ten ORM kod bude kratsi nez generovane SQL, navic si v ORM mohu napsat obecne funkce na vytvareni podobnych dotazu

Tohle je jen použití query buildru. Z mého pohledu je to jen jiné API pro execnutí dotazu. Sice jste explicitně nenapsal SQL, zavolal jste metody, které jednoduše vygenerují SQL. V podstatě jste napsal SQL v bledě modrém. Tady není nic, co by dělalo problém. Problémy jsou při iteraci nad kolekcí komplexnějších objektů, které ORM samo načítá, případně samo serializuje.

[Pavel Stěhule]

doporucuji se podivat na http://docs.peewee-orm.com/en/latest/ , coz je podle me ORM udelane spravne, pripadne SQLAlchemy

Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)

Tyhle query buildery jsou asi bezproblémové (je to jen manipulace se stringama), jen mi to příšlo jako řešení, aby se vlk nažral (v aplikaci se mi nevyskytuje SQL) a koza zůstala celá (v podstatě programátor musí napsat kompletní SQL).