Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: schwantner.peter 20. 06. 2021, 17:34:21
-
Ahojte, chcel by som mensiu radu / konzultaciu k vytvaranym relacnym tabulkam.
Potrebujem ukladat nastavenia, pre vysky vyplatzamestnancov. Nastavenie vysok bude ulozene v percentach, kazde nastavenie musi mat platnost od, a volitelnu platnost do - null znamena ze plati kym nepribudne novy zaznam. Vyska sa bude ukladat defaultne per poziciu zamestnanca.
Takze moj navrh je toto:
sallary_setting
- id
- from
- to (nullable)
sallary_setting_values
- id
- emp_position (nullable)
- percentage
- sallary_setting_id (fk)
Dalsi atribut ktory by mal tento design splnat, je moznost ulozenia nastavenie pre konkretne pobocky firmy, a pre konkretnych zamestnancov. Tzn, ze ak bude ulozene taketo specificke nastavenie, prepise to defaultne nastavenie.
Napadaju ma 2 sposoby ako to urobit:
1. pridat nullable stlpce employee_id a company_id do sallary_setting, aby som vedel ci je to specificky zaznam, alebo defaultny ak obe budu null
2. vytvorit nove mapovacie tabulky pre zamestnancov a pobocky, a zaroven pridat enum stlpec do sallary_setting, aky je zdroj tohto nastavenia (firma, zamestnanec, default)
Co myslite? Ak mate lepsi napad, rad si necham poradit od skusenejsich. Dakujem
-
samostatne tabulky company, employee, salary, kde jsou ciste informace o jmenu firmy, o jmenu zamestance, standartizovane urovne platu podle tabulek.
pak vazebni tabulky company_employee, employee_salary, kde budou vazby company_id, employee_id kdo kde pracuje a jeden clovek muze pracovat pro vice firem a firma muze mit vice pracovniku, a vazby employee_id a salary_id, kde je vazba pracovnika na jeho tabulkovy plat, muze tam byt i flag platnosti zaznamu v danem obdobi, klidne i doba platosti.
pak muzou byt triggery, ktere budou modifikovat flagy platnosti salary v danem obdobi, kdyz se pridaji nove zaznamy.
stare zaznamy s neplatnymi flagy se mohou zalohovat v history tabulkach.
-
samostatne tabulky company, employee, salary, kde jsou ciste informace o jmenu firmy, o jmenu zamestance, standartizovane urovne platu podle tabulek.
pak vazebni tabulky company_employee, employee_salary, kde budou vazby company_id, employee_id kdo kde pracuje a jeden clovek muze pracovat pro vice firem a firma muze mit vice pracovniku, a vazby employee_id a salary_id, kde je vazba pracovnika na jeho tabulkovy plat, muze tam byt i flag platnosti zaznamu v danem obdobi, klidne i doba platosti.
pak muzou byt triggery, ktere budou modifikovat flagy platnosti salary v danem obdobi, kdyz se pridaji nove zaznamy.
stare zaznamy s neplatnymi flagy se mohou zalohovat v history tabulkach.
Employee a company tabulky uz mame, aj ten zvysok som planoval podobne. Trosku si nesom isty v tom, ako z tabulky salary vycitam, ktore udaje su defaultne, bez vazby na ine entity? Budu tam trosku vacsie vypocty, a radsej by som sa k akymto udajom dostal lahsie nejakym wherom, ako vylucovanim zgroupenych zaznamov z inych tabuliek.
-
Smejem sa s MongoDB. ;D SRY
-
Smejem sa s MongoDB. ;D SRY
nic proti mongodb, ale jinak je ten prispevek debilita, sorry.
mohl jsi navrhnout jak to udelat v objektove databazi, ale ne, ty's tu prsknul jen hovadinu.
-
Smejem sa s MongoDB. ;D SRY
Cože, ty bys na to nepoužil Svelte? Ty heretiku!!!
-
Poradím jediné, spátky do lavice, nebo na kurz, pokud se musíš ptát na toto tak kvalita výsledné aplikace je už teď dost diskutabilní. Hlavně si pak do testovacích dat prosím dej reálé počty záznamů, ona i nejdebilnější konstrukce složená z bilionu joinů krásně maká s 3 záznamy, ale pak se to setká s realitou a místo třech jich je třeba 3M a ejhle ono se to vlěče.
-
Já jenom poznámku, výška platu bývá absolutní číslo na smlouvě, ukládat to jako procenta z něčeho je imho nešťastné.
Když vidím požadavky - různé firny, pobočky, vybaví se mi korporace - a tady zase mi přijde že ty používají na tohle spíš oracle nebo sap... Ale to je jen takový komentář, aby to nezapadlo.
-
Pane Schwantnere,
nejen vlivem chybějící diakritiky se v dané úloze ztrácím, takže řešení vám neporadím, ale dám vám jednu radu:
Úplně v první řadě si vezměte papír / nějaký SW a jako krabičky si namalujte modelované entity a vztahy mezi nimi (hodí se i rozlišit asociace, agregace a kompozice, které určují rozčlenění, ale to asi nebudete vědět) - zapomeňte, že existují nějaké DB, ideálně se vžijte do situace, že RDB nikdy neexistovaly; nemusíte ani používat UML. Teprve až to budete mít zcela ujasněné, potom se můžete pokusit schéma přeprznit do relačního modelu. Návrh schématu RDB bez hotové předchozí analýzy je sice mimořádně oblíbenou disciplínou, přesto se stále jedná o amatérismus.
-
Nejprve mě napadlo, jestli to není školní úloha, ale - s ohledem konec června - asi ne.
Pak mě napadlo, jestli náhodou nerealizujete nějakou tučnou státní zakázku nebo jestli se nejedná o multimilionový dotační projekt. Pokud ano, moc vám ty milionky přeju, také bych si rád pořádně cucnul ze státního cecíku.
Pokud to je nějaký váš projekt, držím palce.
Smejem sa s MongoDB. ;D SRY
Asi tak.
A až zjistí, že to chce/musí/potřebuje změnit, bude možné se smát ještě víc ;D
@schwantner.peter o MongoDB jste už slyšel?
-
na 99% to je skolsky projekt :)
@schwantner.peter - bod 2 - vytvor tabulky pre uroven zamestnanca aj pobocky. A hodnotu musis nacitavat "od listu" t.j. pozriet zamestnanca, potom pobocku, potom salary_setting (tvoji kamarati su funkcie NVL resp. coalesce, podla typu DB).
-
Table Salary:
- id
- employee_id
- date_from
- date_to
-
Když se tabulka jmenuje sallary, nazvěte klíč sallary_id. Když je tabulka company, nazvěte klíč company_id. Jinak se v tom ztratíte velice lehce. Ať se stejná hodnota v databázi jmenuje stejně ať je to primární nebo cizí klíč nebo cokoliv jiného. Berte to jako "must do"
-
A ještě jednou se ujistěte, že rozumíte zadání
-
Když se tabulka jmenuje sallary, nazvěte klíč sallary_id. Když je tabulka company, nazvěte klíč company_id. Jinak se v tom ztratíte velice lehce. Ať se stejná hodnota v databázi jmenuje stejně ať je to primární nebo cizí klíč nebo cokoliv jiného. Berte to jako "must do"
Proč? Salary.id říká docela přesně, o co se jedná. Nesnáším pleonasmy.
-
Já vím, je to jako pro blbce, ale mně se to osvědčilo. Dělal jsem na db s 1000 tabulkami a všechny obsahovaly desítky sloupců pro všechny verze aplikace. Takovými id sloupci se to jen hemžilo. Navíc se to přepisovalo, takže dokonalý guláš. Když koukám do tabulky, kde jsou takové pleonasmy, vidím na první pohled, kam to vede. Tím bych to uťal, každý má nějaký styl, pán si jistě vybere
-
Proč? Salary.id říká docela přesně, o co se jedná. Nesnáším pleonasmy.
Protože u tabulek v dotazech používáte aliasy a u cizích klíčů stejně musíte uvést jiné označení, než jen "id".
PostgreSQL (a myslím, že i další) zápis joinů ujednodušit, pokud se jména sloupců shodují (a prosté "id" se shoduje u více tabulek).
Takže místo
SELECT ... FROM sallary AS s INNER JOIN employee AS e ON s.employee_id = e.id
zapíšete pouze
SELECT ... FROM sallary AS s INNER JOIN employee AS e USING (employee_id)
Je to pak čitelnější, méně náchylné na chyby.
Má to pak zase jiné, menší nevýhody - ale určitě nejde říct, že používat prosté "id" je lepší.
-
Proč? Salary.id říká docela přesně, o co se jedná. Nesnáším pleonasmy.
Protože u tabulek v dotazech používáte aliasy a u cizích klíčů stejně musíte uvést jiné označení, než jen "id".
PostgreSQL (a myslím, že i další) zápis joinů ujednodušit, pokud se jména sloupců shodují (a prosté "id" se shoduje u více tabulek).
Takže místo
SELECT ... FROM sallary AS s INNER JOIN employee AS e ON s.employee_id = e.id
zapíšete pouze
SELECT ... FROM sallary AS s INNER JOIN employee AS e USING (employee_id)
Je to pak čitelnější, méně náchylné na chyby.
Má to pak zase jiné, menší nevýhody - ale určitě nejde říct, že používat prosté "id" je lepší.
Já osobně nemám USING rád. Nedej bože NATURAL JOIN. Konvenci tabulka_sloupec používám pro cizí klíče, ale už ne pro primární - pak by nebylo poznat, co je primární klíč a co cizí klíč. Navíc, a to vychází od Joe Celka, v případě, že máte název tabulky zkopírovaný v názvu sloupce, tak si nemůžete pomoct aliasy. A pokud máte delší názvy tabulek, tak zákonitě musí být dotaz delší a asi hůře čitelný.
Pokud se s databází nepracuje ručně (schéma generuje CASE, dotazy ORM nebo query designer), tak je to asi jedno, ale při ruční editaci jsou rozumně dlouhé identifikátory základ.
-
Předně, ač s vámi často nesouhlasím, vašeho názoru si velmi vážím.
Nicméně @Miroslav Šilhavý má v tom pravdu, USING umí být velmi užitečný.
Můžete to víc rozvést?
Tohle je myslím velmi zajímavé.
Osobně nemám rád některé nové funkcionality C#, ale to neznamená, že jsou špatné.
Je to vaše osobní preference, nebo jste se setkal se skutečnými problémy, které to způsobilo?
A dále, zmiňujete:
při ruční editaci jsou rozumně dlouhé identifikátory základ
Mohl byste to prosím ilustrovat na příkladu?
Děkuji, opravdu bych takové doporučení považoval za užitečné.
-
...
Mně přijde USING poměrně šikovné, protože už zápisem vidím, jestli se spojovací podmínka (více) přirozená, nebo komplikovanější. Ale to je asi jen věc zvyku. Většina SQL se bez USING () obejde, takže to nepovažuji za mantru.
Identifikátory nemusejí být tabulka_id, ale zapsané i opačně: "id_tabulka. To docela eliminuje problém s dlouhými názvy (kdy se člověk dozví, že se jedná o identifikátor až na konci).
Jako výhodu také vidím práci s pohledy. Při definici pohledu se pak jednodušeji přebírají identifikátory do výběru.
CREATE VIEW ... AS
SELECT
...
, id_tabulka
FROM
tabulka INNER JOIN druha_tabulka USING (id_tabulka)
Při vytváření pohledu to pak získá možnost pohlídat, jestli je takový zápis jednoznačný. Pokud se jedná o INNER JOIN, tak to projde, pokud se jedná o OUTER JOIN, upozorní mě to a mnohdy předejde chybě. Pokud bych používal vždy plný zápis SELECT tabulka.id AS tabulka_id připravím se o tuto výhodu a musím si dát dvojitý pozor, o jaký join se jedná a co je vlevo a co vpravo.
Proti tomu mně střídmost v pojmenování identifikátorů nepřijde tak důležitá, protože IDE stejně našeptávají a klíče naznačují.
Ale o tom se opravdu nehádám jako o jediné pravdě, všemi způsoby to jde, a jsou různá pro a proti.
-
Mohl byste to prosím ilustrovat na příkladu?
Děkuji, opravdu bych takové doporučení považoval za užitečné.
Každá konvence vede k trochu jinému zápisu. Funkčně je to úplně stejné.
SELECT zam_prijmeni, adr_ulice || adr_cp FROM zamestnanci JOIN adresy USING (zam_id)nebo
SELECT z.prijmeni, a.ulice || a.cp FROM zamestnanci z JOIN adresy a ON z.id = a.zamestnanec_id
První zápis vás nutí dodržovat konvenci (což je dobrá vlastnost), ale musím si pamatovat navíc prefixy. Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)
-
Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)
Aliasy můžete volit i u prvního zápisu, v tomto ohledu se to neliší.
-
Když se tabulka jmenuje sallary, nazvěte klíč sallary_id. Když je tabulka company, nazvěte klíč company_id. Jinak se v tom ztratíte velice lehce. Ať se stejná hodnota v databázi jmenuje stejně ať je to primární nebo cizí klíč nebo cokoliv jiného. Berte to jako "must do"
My sme zvykli este foreign key nazyvat company_id1, aby bolo na prvy pohlad jasne, ze je to fk a k comu patri. Tiez to dost pomahalo.
-
Velmi zajímavá diskuze, takové problémy s MongoDB rozhodně neřeším každý den.
Děkuji!
-
Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)
Aliasy můžete volit i u prvního zápisu, v tomto ohledu se to neliší.
Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.
Podle mne výhody, a nevýhody budou podobné jako např. u použití maďarské notace. Je to hodně podobné.
-
Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.
Tohle nějak nechápu - ale nečetl jsem nic na toto téma. Když mám v klíči jméno tabulky, tak mi přijde, že tím spíš můžu použít krátké aliasy a orientaci mi poskytne právě prefix v identifikátoru klíče. Zatímco krátké identifikátory se mi zdají v kombinaci s tabulkovými aliasy méně čitelné (a.id vs. a.account_id). Je pravdou, že při inner joinech lze pracovat úplně bez prefixu i bez aliasu, a nesníží to čitelnost.
Nemáš k tomu nějaký text? Možná by to mohlo být podnětné.
-
Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.
Tohle nějak nechápu - ale nečetl jsem nic na toto téma. Když mám v klíči jméno tabulky, tak mi přijde, že tím spíš můžu použít krátké aliasy a orientaci mi poskytne právě prefix v identifikátoru klíče. Zatímco krátké identifikátory se mi zdají v kombinaci s tabulkovými aliasy méně čitelné (a.id vs. a.account_id). Je pravdou, že při inner joinech lze pracovat úplně bez prefixu i bez aliasu, a nesníží to čitelnost.
Nemáš k tomu nějaký text? Možná by to mohlo být podnětné.
Možná je to víc o estetice (a ta je subjektivní) a až potom k tomu hledáme technické argumenty. Podobné je to třeba s formátováním SQLka. Ten subjektivní pocit je důležitý pro mentální pohodu, ale zároveň to vylučuje větší shodu.
Mně vyhovuje a vycházím ze stylu Joe Celka Joe Celko's "SQL Programming Style"
https://www.sqlstyle.guide/
-
Možná je to víc o estetice (a ta je subjektivní) a až potom k tomu hledáme technické argumenty.
Já, doufám, ani ne. Považuji všechny ty styly (co jsme si tu řekli) za technicky rovnocenné. Technicky mi vadí snad jen, pokud se v jedné databázi najde mix stylů - s tím už se pak opravdu špatně pracuje snad každému.
Díky za odkaz.
-
Tohle relační eskamotérství mi vždy připomene, jak nám vyučující vykládal vtip, jaký je rozdíl, když se kupuje vánoční stromeček v objektovém, nebo relačním obchodu.
-
vtip
Ten neznám, sem s ním ;D
https://www.sqlstyle.guide/
To jsem neznal, moc pěkné mít to takhle pohromadě!!!
-
Ten neznám, sem s ním ;D
V objektovém obchodu s vánočními stromky ukážete na stromek, který chcete, vezmete, zaplatíte, odejdete.
V relačním obchodu jsou v jednom rohu opřené kmínky, každý z nich má číslo a v sobě díry pro větve, kdy každá díra má malinkaté čisílko. O kus vedle je na zemi hromada větví, každá větev má číslo a na sobě mnoho malých čisílek - vy si musíte vyhrabat ty s odpovídajícími čísly z vybraného kmínku. Ještě o kus dál je veliká krabice s jehličím, kdy každá jehlička má opět číslo - vy opět hledáte jehličky odpovídající čisílkům na větvích. Když to všechno dohledáte, stromek sestavíte, zaplatíte, odejdete.
-
Ale to není vtip, to je krutá realita ;D
-
PanVP:To není realita, ale velmi jednostranný pohled. Respektive to cherry-pickuje zrovna ten příklad, pro který jsou dokumentové databáze (skutečných objektových moc není) opravdu vhodné.
V realitě často potřebuješ nejen koupit vybraný stromek, ale třeba najít ten, který má nejtmavší jehličí na druhé větvi od spoda. S relačními stromky prostě najdeš to jehličí, a pak se zeptáš prodejce, kterýmu že stromku to jehličí patří, on se podívá do papírů s podivným jménem index a během chvilky Ti to řekne.
Zatímco "dokumentový" prodejce v takovém bude v takovém případě dokolečka běhat přes prodejní plochu a nadávat jako špaček, protože Ti bude nosit jeden stromek za druhým, jen aby sis porovnal barvu jehličí na té správné větvi.
Každá technologie má své + a - a neexistuje "jediná správná technologie". Jen vhodné technologie na dané konkrétní nasazení. Přičemž jich může být i více, a ta vhodnost záleží i na tom, co daný člověk umí: u věcí "na hranici" ať to radši Mongař dělá v Mongu a nesnaží se o SQL, i když třeba by SQL přístup přinesl nějaké výhody - a naopak když se bude člověk s dokumentovou databází snažit pracovat "relačně", tak taky vznikne prasopes.
Takže jako vtip je to dost dobrý, ale dělat z toho nějakou hlubokou pravdu je ulítlý....
-
...
Chtěl jsem napsat něco podobného. Někdo myslel na dobrý, jednoduchý prodej. Jenže za týden si manažer vzpomene, že chce statistiku stromků na skladě, podle druhu stromu a velikosti. Jenže v návrhu objektu někdo zapomněl na krabici nalepit tyto informace zvenčí. A tak se otevírá jedna krabice za druhou, aby se někdo nakoukl, co je vevnitř. A manažer se diví, proč je na to potřeba tří směn, než mu někdo takovou informaci dodá.
:-)
-
Jáááááj, to jsem nevěděl, že tohle se svojí db nemůžu dělat :-[ tak snad abych takovou funkčnost ze svých projektů odebral no.... :P ;D ;D
-
Jáááááj, to jsem nevěděl, že tohle se svojí db nemůžu dělat :-[ tak snad abych takovou funkčnost ze svých projektů odebral no.... :P ;D ;D
Ale jo, jen se ta databáze kurevsky nadře ve srovnání s relační.
-
Mám dva druhy dat - první se pohodlně vlezou do 1 GB a bydlí si v paměti, to je problém pro Pentium 3 Tualatin.
A data nad 10 TB....a to je problém i pro můj cluster.
-
Mám dva druhy dat - první se pohodlně vlezou do 1 GB a bydlí si v paměti, to je problém pro Pentium 3 Tualatin.
A data nad 10 TB....a to je problém i pro můj cluster.
No a já znám i další druhy dat, na které se skvěle hodí relační databáze. I kdyby byla celá v RAM, pořád na ně bude vhodnější než NoSQL.
-
A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Pak snad jedině narvat tam dopředu něco jako Apache Ignite, do něj nacpat transformační logiku, definovat mu pár vzdálených backendů paralelně vedle sebe - PostgreSQL, Cassandra, CouchDB, ... a mlátit/číst data přes to Ignite dle chuti chvíli jako K/V, chvíli jako SQL (zde to má svoje ale) a ať si s tím gulášem poradí a nejčastější data drží v RAM cache. :-)
-
Ten neznám, sem s ním ;D
V objektovém obchodu s vánočními stromky ukážete na stromek, který chcete, vezmete, zaplatíte, odejdete.
V relačním obchodu jsou v jednom rohu opřené kmínky, každý z nich má číslo a v sobě díry pro větve, kdy každá díra má malinkaté čisílko. O kus vedle je na zemi hromada větví, každá větev má číslo a na sobě mnoho malých čisílek - vy si musíte vyhrabat ty s odpovídajícími čísly z vybraného kmínku. Ještě o kus dál je veliká krabice s jehličím, kdy každá jehlička má opět číslo - vy opět hledáte jehličky odpovídající čisílkům na větvích. Když to všechno dohledáte, stromek sestavíte, zaplatíte, odejdete.
Pozor, muze jit pouze o objektovou tovarnu, kterou provozuje jedinacek a nemuzete prijit s pozadavkem na nejaky abstrakni stromek. A pokud nezkonstruujete objednavku, tak ani dal nepokracujte. Pokud jejich stromek je finalni vyrobek na nejaky extra pozadavky zapomente.
A specifikovat vlastnosti toho stromku taky nemusi byt med, treba jehlice chcete jine, ale prodavac je nemy tak jen pres rozhrani posunku opakuje ze ty jehlice jsou takove a menit to nejde.
Nebo jestli barvu staci rict slovem nebo najit ve vzorniku Tridy pantone a pri konstrukci objednavky nebo metodou Vyberbarvu..
A opovazte se odejit bez destrukce uctenky.
V relacnim svete by byl akorat pruser nezauctovat transakci, to by triggernulo Scillerovou ktera by kaskadove zaklekla na vsechny subdodavatele z databaze financniho gestapa
-
A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Pak snad jedině narvat tam dopředu něco jako Apache Ignite, do něj nacpat transformační logiku, definovat mu pár vzdálených backendů paralelně vedle sebe - PostgreSQL, Cassandra, CouchDB, ... a mlátit/číst data přes to Ignite dle chuti chvíli jako K/V, chvíli jako SQL (zde to má svoje ale) a ať si s tím gulášem poradí a nejčastější data drží v RAM cache. :-)
Vetsina nevyhod relacnich databazi (ukecanost, synchronizace schematu s kodem) mizi pri pouziti rozumneho ORM.
-
Vetsina nevyhod relacnich databazi (ukecanost, synchronizace schematu s kodem) mizi pri pouziti rozumneho ORM.
Ano, ano, použijeme rovnák na ohýbák! 8) To bude cool!
ORM totiž je právě ten rovnák na ohýbák...
Nejsem proti relačním databázím, rozhodně ne, ale velmi často jsou zkrátka naprosto nevhodně použité.
Zlomená ruka? Do sádry! Nakřupnutá hlava? Do sádry! Zlomený prst? Do sádry! Zánět slepáku? Do sádry!
Je zajímavé, že pokud do sádry plácnete pacoše se zápalem plic, může mu to částečně ulevit...a třeba se i uzdraví = další argument dávat sádru.
Proč bych se měl drbat se složitou konstrukcí tabulek, když to vyřeší objektová případně nosql databáze?
Jednoduše, moc příjemně se s ní pracuje. Ano, možná ten systém nezvládne 10 000 000 současných dotazů, z čehož nemůžu spát, protože těch současných dotazů jsou maximálně tisíce a systém by zvládl i statisíce dotazů.
Databáze Oracle? Použij server !!! TURBO!!! MEGA!! RAID, hotplug, ECC killchip, iWARP, quadsocket, RAMSTORAGE!
Mašina na AI? Použij server !!! TURBO!!! MEGA!! RAID, hotplug, ECC killchip, iWARP, quadsocket, RAMSTORAGE!
Počítač na malování? Použij server !!! TURBO!!! MEGA!! RAID, hotplug, ECC killchip, iWARP, quadsocket, RAMSTORAGE!
Co?
Na malování použít server?
NO JISTĚĚĚ...co kdyby se požadavky zvýšily....
-
...
Tak jistě, to co tady píšete, je pravda.
V praxi není problém v tom, že by jeden nebo druhý přístup byl lepší. Většinou to hapruje na tom, že výběr technologie se nečiní kvalifikovaně, provádí ho někdo jiný, než ten, kdo má představu o budoucnosti projektu. Dost často ho dělá i ten, který nezná oba přístupy a jejich výhody a nevýhody.
Dohady v diskusích vnímám spíš tak, že spousta lidí (a já mezi ně patřím) považuje za bezpečnější a potentnější přístup, aby programátor nejprve na slušné úrovni ovládl RDBMS a pochopil, že skládat jehličky do větviček a do stromku nemá jen nevýhody, ale i výhody. Aby v budoucnu mohl kvalifikovaně posoudit, na co se hodí jaká technologie. Mezistupeň v poznání jsou ORM, u kterých taky pochopí další výhody a nevýhody. Tento postup je dialektický.
Proti tomu velmi často najdete programátory, kteří RDBMS neznají - maximální poznání u nich končí u joinu v mysql a jeho výkonnostních problémů. Jestli vyžadují ACID neumějí zodpovědět, ve skutečnosti ani fakticky neznají důležitost takové otázky, maximálně definici z papíru. S takovými je pak těžko diskutovat, radit a rozebírat jejich otázky typu "jakou databázi mám zvolit". Kdyby ty základní zkušenosti měli, nepoložili by takovou fundamentální otázku. Když ty znalosti nemají, je (myslím si) lepší začít od rozumných základů poznání.
To si můžete povšimnout i zde, na rootu, že když se někdo orientuje a potřebuje prodiskutovat jen nějaký technický detail nebo zkušenost, diskuse jsou věcné. Zvrtnou se ve většinou jen ve chvíli, kdy se ukáže, že na začátku asi stojí nějaký chybný úsudek. Většinou to pak končí tím, že tazatel je zklamán, že na špatnou otázku ve špatně nastavené situaci nedostane dobrou odpověď, která by vyřešila všechna trápení světa.
-
Předně, myslím, že panuje jistá úroveň shody.
Dále, domnívám se, že budoucnost leží ve spojení / unifikaci databázových enginů.
Všichni experimentují s NoSQL což ovšem nutně není/nemusí být objektová databáze, případně objektová databáze může být podskupinou NoSQL databází.
Tato diskuze ztratí veškerý smysl ve chvíli, kdy bude jen na uživateli, jaký model použije.
Jako velký příznivce MongoDB si rozhodně nedovedu představit, jak bych do toho dal pouhých pár milionů záznamů a efektivně s nimi pracoval. Stejně tak si nechci vzpomínat, jak jsem se drbal s návrhem databáze pro tak triviální věc, jako je docházkový systém, který jsem se ...já hňup... zavázal udělat za kamaráda zadarmo, protože za to přeci nebude dávat třicet tisíc.
Vždycky si vzpomenu na prosté: A...hřebík zatloukej kladívkem a díru vrtej vrtačkou, nikdy obráceně? Chápeš? Tak chápeš? Evidentně ne...
-
Tato diskuze ztratí veškerý smysl ve chvíli, kdy bude jen na uživateli, jaký model použije.
No já vidím takový fundamentální problém. Objektové databáze mohou teoreticky dosahovat stejných výkonů, jako relační. Jenže, aby toto opravdu nastalo, bylo by potřeba objekty a vlastnosti popsat tak definitivně, že by si takový popis svojí složitostí nezadal s relačními databázemi.
Jestli má tato diskuse smysl, tak podle mě naopak jedině ve chvíli, kdy se bavíme o rozdílech, mezi kterými lze volit.
Ono je ve skutečnosti jedno, jestli stejné vazby a principy manipulace s daty popíšete v SQL, nebo objektově. Bude se lišit řeč zápisu, ale jinou řečí budete popisovat totéž. Jestli mají objektové databáze nějakou výhodu, tak je to právě v tom, že pro spoustu úloh se dá zápis zjednodušit o popis toho, co RDBMS vyžadují (řekněme "zbytečně") a naopak se zaměřit na popis vlastností, které se v RDBMS zapisují složitě.
-
No já vidím takový fundamentální problém. Objektové databáze mohou teoreticky dosahovat stejných výkonů, jako relační. Jenže, aby toto opravdu nastalo, bylo by potřeba objekty a vlastnosti popsat tak definitivně, že by si takový popis svojí složitostí nezadal s relačními databázemi.
Fundamentalni problem je OOP jako takove. Vsechno ostatni jsou nasledky.
-
PanVP:
ORM - rovnák na vohejbák.
Ne, to není rovnák na vohejbák. To je způsob, jak si zjednodušit práci se SQL databází, aniž bys ztratil možnost používat některé možnosti SQL, které v NoSQL přístupu prostě nemáš. Dívej se na to jako na vícevrstvou technologii: narozdíl od NoSQL, kterej je monolit a máš přístup jen do nejvyšší vrstvy, v ORM máš možnost, když "standadní implementace nevyhovuje", jít o vrstvu níž a získat to, co potřebuješ, efektivně.
Samozřejmě za to i platíš (např. vznikají problémy, jestli má být logika v DB nebo v APP) - každá technologie má své silné a slabé stránky.
jak jsem se drbal s návrhem databáze pro tak triviální věc
Sorry, ale todle není problém SQL, ale toho, že s SQL nemáš praxi. Což není nic špatného, dokumentuje to jednu z nevýhod SQL: pomalejší křivku učení.
Proč bych se měl drbat se složitou konstrukcí tabulek, když to vyřeší objektová případně nosql databáze?
Úplně stejně Ti můžu odpovědět. Proč bych se měl drbat dokolečka s psaním rutin na vyhledávání těch správných záznamů v NoSQL, když v SQL to mám zadarmo, a podstatně výkonnější (u složitějších dotazů), než je schopen napsat za rozumný čas jeden člověk?
Ona složitost SQL dekompozice je ve skutečnosti jen zdánlivá nevýhoda. Když to umíš, tak bez probléímů rychle a správně rozložíš cokoli do SQL relací zcela automaticky a rychle. Jasně, ne tak rychle, jako v NoSQL, ale oproti implementaci logiky to rychlé je.
To, co je velká výhoda NoSQL přístupu pro jednodušší projekty - superrychlej návrh struktury, protože do ní nacpeš "cokoli jakkoli" je ve skutečnosti zároveň slabina NoSQL. Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden, NoSQL je v podstatě moderní reinkarnace stromových databází. Se všemi plusy: snadná práce s daty, když "lezeš po stromě" a mínusy: když potřebuješ chodit "napříč lesem" - a tedy nutností dobře navrhnout strukturu stromečků.
Takže zatímco v SQL databázi se navrhuje databáze "automaticky" a při dodržení patřičných pravidel to "nejde udělat blbě" (trochu přeháním, ale v porovnání s NoSQL to platí), v NoSQL u složitějších případů je poměrně podstatné, jestli se člověk na začátku vývoje "strefí" do datové struktury, která bude vhodná i třeba po letech - a tedy narozdíl od SQL databáze by ses tedy měl podstatně více drbat s analýzou dat, budoucích požadavků atd.... Anebo daleko víc času, než jsi získal "superrychlým první návrhem", ztratíš refaktory databáze když zjistíš, že tam nějaký požadavek nejde udělat efektivně.
===
Ink:Problematičnost OOP se týká toho, jestli a jak je správné "bundlovat" data a kód - a to se vůbec netýká toho, jak jsou data uložena. Kolekce nějakých datových struktur a potřebu jejich persistentního uložení (často včetně požadavků na transakce) máš snad u každého (reálně použitelného) programátorského paradigmatu.
-
Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,
Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.
-
Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,
Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.
Tak jednoduché to není. Síla RDBMS je ve výkonu, a totéž se dá řešit různými způsoby s odlišným dopadem na výkon v různých situacích. Informace může být v tabuli, může být napojena vazbou, může být uložena jako pole (nebo obdobný komplexní typ) v tabuli... Míru rozpadnutí do vazeb nástroj nerozhodne, protože to rozhodnutí se opírá o předpokládaný způsob užití a požadavek výkonu při různých operacích.
S trochou nadsázky by se dalo říct, že "stejně blbě" jako NoSQL databáze by to mohl udělat i nástroj (ostatně, ORM), a pak by opravdu nebyly RDBMS potřeba.
-
Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,
Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.
Tak jednoduché to není. Síla RDBMS je ve výkonu, a totéž se dá řešit různými způsoby s odlišným dopadem na výkon v různých situacích. Informace může být v tabuli, může být napojena vazbou, může být uložena jako pole (nebo obdobný komplexní typ) v tabuli... Míru rozpadnutí do vazeb nástroj nerozhodne, protože to rozhodnutí se opírá o předpokládaný způsob užití a požadavek výkonu při různých operacích.
To řeším tak, že tomu systému přidám hint. Takže když mám pole struktur, tak defaultně mi z toho vytvoří defaultní relaci. Ale mohu dodat informaci, že lepší je tato startegie. Výhoda SQL je ten matematickej aparát, kterej problém extrahuje do několika málo strategií (v základu šesti). S čímž se přirozeně lépe pracuje, než s "libovolností" u jiných řešení.
pak by opravdu nebyly RDBMS potřeba.
RDBMS je potřeba. Přece to engine nebudu psát znova!
Co není je potřeba low-level SQL+Relační algebra.
-
Ten neznám, sem s ním ;D
V objektovém obchodu s vánočními stromky ukážete na stromek, který chcete, vezmete, zaplatíte, odejdete.
V relačním obchodu jsou v jednom rohu opřené kmínky, každý z nich má číslo a v sobě díry pro větve, kdy každá díra má malinkaté čisílko. O kus vedle je na zemi hromada větví, každá větev má číslo a na sobě mnoho malých čisílek - vy si musíte vyhrabat ty s odpovídajícími čísly z vybraného kmínku. Ještě o kus dál je veliká krabice s jehličím, kdy každá jehlička má opět číslo - vy opět hledáte jehličky odpovídající čisílkům na větvích. Když to všechno dohledáte, stromek sestavíte, zaplatíte, odejdete.
IKEA?
-
Ink:Problematičnost OOP se týká toho, jestli a jak je správné "bundlovat" data a kód - a to se vůbec netýká toho, jak jsou data uložena. Kolekce nějakých datových struktur a potřebu jejich persistentního uložení (často včetně požadavků na transakce) máš snad u každého (reálně použitelného) programátorského paradigmatu.
A říkám, že ne? Podle mě to jsou ale spojené nádoby - jestliže nějak strukturuješ/modeluješ aplikaci, má to vliv i na to, jak nakládáš s daty při ukládání nebo rekonstrukci z DB. Pokud je řádek z tabulky struktura/n-tice, prostě ji pošleš dál nebo ji něčím rozšíříš, abys dostal kýžený tvar, se kterým chceš pracovat. Jakmile musíš řešít, jestli ta struktura je autonomní chytrý objekt, jehož vnitřní uspořádání je zapouzdřené a nikomu do něj nic není, najednou se to blbě napasovává třeba na relační databázi...
-
jehož vnitřní uspořádání je zapouzdřené a nikomu do něj nic není... [/size]najednou se to blbě napasovává třeba na relační databázi...
Když je dobře udělanej datovej objekt, tak se Ti IMHO na relační databázi pasuje úplně stejně dobře, jako "surová data" ve formě ntic.
, prostě ji pošleš dál nebo ji něčím rozšíříš, abys dostal kýžený tvar, se kterým chceš pracovat[/size]
To imho není dobrá strategie. Kód by měl mít nějakou "kulturu" a mezi to patří i rozumně definované interfacy (nikoli v objektovém smyslu) funkcí. Když rozumně navrhneš datové struktury, tak - ať už jim budeš říkat objekt, ntice nebo nevímjak - tak bys s nimi neměl mít potřebu pokaždé manipulovat na jiný tvar.
Já osobně mám zkušenost, že nejlepší architektura SW je taková, kde ten SW pokudmožno co nejlépe "modeluje realitu". A pokud tomu tak je, pak model objektů (datových struktur) jde na DB napasovat dobře, protože ta má také modelovat realitu. Samozřejmě, že to nesmí bejt tak, že DB dělá jeden člověk, návrh datových struktur v backendu někdo jiný, a pak se divěj, když každej zjednodušší realitu (protože vždy je třeba zjednodušit) jinak...
Ale to je problém vždy: i když nebudíš mít nějak vynucené datové struktury, tak si třeba krátkodobě pomůžeš tím, že tam, kde se Ti to tluče, tak to "nějak vohneš". Ale z dlouhodobého hlediska je vždy lepší to zrefaktorovat tak, aby si interfacy sedly. A pokud je interface na druhé straně neměnný (3rd-party library) tak zas není dobrá strategie se ji "přizpůsobovat" (co když to v další verzi změní), ale lepší je zavést si tam konverzí funkce.
-
ORM je tzv. "leaky abstraction" - https://en.wikipedia.org/wiki/Leaky_abstraction
-
ORM je tzv. "leaky abstraction" - https://en.wikipedia.org/wiki/Leaky_abstraction
coz vubec nevadi, pokud nepotrebujete stridat databaze. Hlavni ucel ORM je moznost psat SQL ve vyssim, expresivnejsim jazyce.
-
Ale to není vtip, to je krutá realita ;D
Já vím, ale nechtěl jsem vám to kazit.
-
A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Pak snad jedině narvat tam dopředu něco jako Apache Ignite, do něj nacpat transformační logiku, definovat mu pár vzdálených backendů paralelně vedle sebe - PostgreSQL, Cassandra, CouchDB, ... a mlátit/číst data přes to Ignite dle chuti chvíli jako K/V, chvíli jako SQL (zde to má svoje ale) a ať si s tím gulášem poradí a nejčastější data drží v RAM cache. :-)
Jsou 2 řešení: To vaše - budete to mít v jedné DB (což samo o sobě je otázkou, zda to stojí za to, u velkých systémů je stejně více zdrojů dat), ale ta data budete muset přeprzňovat mezi jejich a DB formátem. Nebo použijete pro každý typ dat určenou DB, ale bude to rychlé a bez přeprzňovaček.
-
Vetsina nevyhod relacnich databazi (ukecanost, synchronizace schematu s kodem) mizi pri pouziti rozumneho ORM.
Ale z podstaty věci to zadarmo nebude, že?
https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch (https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch)
-
A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Jsou 2 řešení: To vaše - budete to mít v jedné DB (což samo o sobě je otázkou, zda to stojí za to, u velkých systémů je stejně více zdrojů dat), ale ta data budete muset přeprzňovat mezi jejich a DB formátem. Nebo použijete pro každý typ dat určenou DB, ale bude to rychlé a bez přeprzňovaček.
Nejde třeba použít Postgres která umí fungovat i jako NoSQL, JSON a timeseries databáze (nemám zkušenost)? Kombinujete to někdo takto u Postgres?
-
ORM je tzv. "leaky abstraction" - https://en.wikipedia.org/wiki/Leaky_abstraction
coz vubec nevadi, pokud nepotrebujete stridat databaze. Hlavni ucel ORM je moznost psat SQL ve vyssim, expresivnejsim jazyce.
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
-
PanVP:
ORM - rovnák na vohejbák.
Ne, to není rovnák na vohejbák.
Nebudu vás přesvědčovat, dle vašich uvedených názorů to nemá smysl. Uvedu jen jednu okolnost, proč objekty a RDB jsou nekompatibilní:
V objektovém modelu se velice často pracuje se seznamy, přesněji jsou v obj. modelu klíčové (kdo by to byl řekl, že?). Např. takový Smalltalk má MIMOŘÁDNOU „knihovnu“ pro práci se seznamy (což se nedá říci o většině ostatních jazyků).
Když pak taková data chcete uložit do RDB, zjistíte, že RDB NEZNÁ seznamy! Jasně, už slyším křik: „Ale když udělám SELECT něco FROM něco WHERE id_rádobyseznamu = něco, tak mám seznam.“ To ale není seznam, to je pouze podmnožina VŠECH prvků seznamů STEJNÉHO typu nasypaných do jedné krabice zvané tabulka, kterou abych získal, musel jsem je v té krabici dohledat (bez ohledu na to, zda jsem při tom použil index; ano, to je jak s tím jehličím v krabici). Takže tento seznam nebyl nikde uložený jako celek (jako např. v dokumentové DB pod jedním klíčem), ten jsem musel ad hoc sestavit, a zrovna tak jej budu muset pro uložení rozebrat. A to nezmiňuju skutečnost, že onen seznam může mít jako objekt další vlastnosti (např. předpis pro řazení), které, pokud pro ně neudělám další tabulku, nebudu mít kam uložit.
Já myslím, že pro představu tento příklad stačí.
-
PanVP:
ORM - rovnák na vohejbák.
Ne, to není rovnák na vohejbák.
RDB NEZNÁ seznamy! Jasně, už slyším křik: „Ale když udělám SELECT něco FROM něco WHERE id_rádobyseznamu = něco, tak mám seznam.“ To ale není seznam, to je pouze podmnožina VŠECH prvků seznamů STEJNÉHO typu nasypaných do jedné krabice zvané tabulka, ...
V seznamu je definováno pořadí, které je závislé na pořadí přidání elementu. Seznam nepotřebuje index. RDB dodává množinu, u které není definováno pořadí, pokud není explicitně uvedeno řazení v dotazu. Update DB tabulky seznamem není triviální úlohou a zpravidla je výhodnější to řešit jinak.
-
Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,
Způsobů mapování objektů na relace je vícero, určitě ne jeden.
...NoSQL je v podstatě moderní reinkarnace stromových databází. Se všemi plusy: snadná práce s daty, když "lezeš po stromě" a mínusy: když potřebuješ chodit "napříč lesem" - a tedy nutností dobře navrhnout strukturu stromečků.
V DB NoSQL se používají právě ty seznamy proto, aby se tím lesem nemuselo zbytečně courat, to je pazvyk z RDB.
Takže zatímco v SQL databázi se navrhuje databáze "automaticky" a při dodržení patřičných pravidel to "nejde udělat blbě"
Naopak z důvodu nutnosti rozkladu seznamů do tabulek a vazebných tabulek je návrh RDB nepřehledný. Chybně navržených relačních modelů jsem viděl dost.
v NoSQL u složitějších případů je poměrně podstatné, jestli se člověk na začátku vývoje "strefí" do datové struktury, která bude vhodná i třeba po letech...
Např. dokumentové DB jsou bezschématové, takže změna struktury se provádí uložením dokumentu v jiném formátu. V RDB je třeba změna statické struktury zvláštními příkazy, a to při odstavené DB.
...a tedy narozdíl od SQL databáze by ses tedy měl podstatně více drbat s analýzou dat, budoucích požadavků atd....
Obchodní analýza se neliší podle použité DB (když to teda nedělá relačník, který návrh systému začne od databáze). Následné mapování objektů do dokumentů je výrazně jednodušší než do relací.
Anebo daleko víc času, než jsi získal "superrychlým první návrhem", ztratíš refaktory databáze když zjistíš, že tam nějaký požadavek nejde udělat efektivně.
To už je jen chybný důsledek výše uvedeného závěru. Ale když myslíte...
-
A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Jsou 2 řešení: To vaše - budete to mít v jedné DB (což samo o sobě je otázkou, zda to stojí za to, u velkých systémů je stejně více zdrojů dat), ale ta data budete muset přeprzňovat mezi jejich a DB formátem. Nebo použijete pro každý typ dat určenou DB, ale bude to rychlé a bez přeprzňovaček.
Ano, když je dat málo, cpu vše do jedné DB, co mám rád/umím. Když jich je hodně, tak víc různých řešení. K tomu tam byl zmíněn ten Ignite jako možnost, jak to řešit - to mi dovolí mít data v různých databázích a mít k nim jednotný přístup a klidně naráz můžu přistupovat pomocí NoSQL key/value interface nebo pomocí SQL ke stejným datům, ať to v pozadí je SQL nebo NoSQL. V podstatě s trochou víc násilí jde udělat to, že do ignite pošlu "select cas,a,b,c,d from ... where ..." a zpět dostanu tabulku, kde sloupec A je vytažen z PostgreSQL, sloupec B je z InfluxDB, sloupec C vyčten z binárních souborů uložených v přílohách v CouchDB a sloupec D jsou data z Cassandry (ale až takový slepenec bych nechtěl mít na krku :-) ). A pokud do toho pošlu set/insert/update, tak to skrz Ignite doteče do těch cílových DB a Ignite si drží cache nejpoužívanějších dat v RAM pro urychlení přístupu.
Nejde třeba použít Postgres která umí fungovat i jako NoSQL, JSON a timeseries databáze (nemám zkušenost)? Kombinujete to někdo takto u Postgres?
Jde, používáme, že do PgSQL mlátíme přes jsonb sloupce a i ukládáme časové řady, částečně přes array. Jde to dělat, ale čistý Postgres používat jako timeseries není úplně ono (jak to přeleze pár set giga řádků), to chce asi TimescaleDB nadstavbu (ta půjde do testu). Používáme pro timeseries i InfluxDB historicky, ale nějak se krabatí čelo nad některými změnami v 2.x.
U PgSQL vidím jako problém u nás spíše v tom, že to nemá úplně nejjendodušší řešení pro clustering už i jen těch možností pro master-slave HA setup je požehnaně, pokud si člověk třeba zvykl na multimaster u Cassandy nebo CouchDB. :-(
-
V seznamu je definováno pořadí, které je závislé na pořadí přidání elementu. Seznam nepotřebuje index.
Však taky indexy neslouží k popisu pořadí vkládání položek do seznamu.
-
V seznamu je definováno pořadí, které je závislé na pořadí přidání elementu. Seznam nepotřebuje index.
Však taky indexy neslouží k popisu pořadí vkládání položek do seznamu.
No právě. Přestože seznam nemá indexy, je definováno pořadí položek. Tohle se u RDB použít nedá. Přesto raději pracuji s RDB a pokud potřebuji stromy, sáhnu po DOM.
-
Kit:
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Ano a ne. Záleží na úhlu pohledu. SQL má samozřejmě velmi výrazně širší možnosti, než jakýkoli ORM. Z tohodle pohledu ano. Ale z hlediska snadnosti napsání dané úlohy je SQL oproti ORM "assembler". Proto je někdy vhodné psát jen v ORM (pak ale často mohou být NoSQL databáze lepší volbou), někdy jen v SQL, někdy se hodí přístup kombinovat. Samozřejmě, má to své z určitého poledu problematické stránky, jak v link postoval SB.
SB:V seznamu je definováno pořadí, které je závislé na pořadí přidání elementu. Seznam nepotřebuje index. RDB dodává množinu, u které není definováno pořadí, pokud není explicitně uvedeno řazení v dotazu. Update DB tabulky seznamem není triviální úlohou a zpravidla je výhodnější to řešit jinak.
To ale není problém OO a SQL, ale jde o obecnější problém
Objektový model neznamená nutnost používání seznamů. Ani v těch "nejpurističtějších" OO definicích žádné seznamy nejsou. Seznamy se používají čistě proto, že jsou to datové struktury, se kterými se dobře a jednoduše pracuje v imperativních jazycích. Ve skutečnosti mají být objekty "odrazem reality". Když si vezmu takový objekt "školní třída", tak ta má jako vlastnost "seznam žáků". A podle čeho má být ten seznam seřazen? Podle příjmení? Čísla ve třídním výkazu? Prospěchu? U drtivé většiny vlastností objektů není žádné "preferované pořadí", tedy jde o množiny, ne o seznamy.
Že se ta množina realizuje v praxi pomocí seznamu, to, že je tam nějaké pořadí dané časem vložení: to není žádná "objektová věc", ale je to implementační artefakt, který nemá s podstatou uložených dat nic společného. Max. se tento artefakt použije k implementačnímu urychlení procházení dané množiny podle nějakého preferovaného pořadí.
A z druhé strany - ano, SQL databáze používají na ukládání množiny. Nebo přesněji v programátorské hantýrce (pokud nejsou definovány unique constrainy) multisety. A ano, objekty jsou zpravidla implementovány seznamy. Potud ano, jenže..... Jak píšu výš ta "seznamovost" není podstata objektů. Funkcionální jazyky jsou "seznamové" ještě více, než OOP jazyky. Stejnětak v neOO přístupu, když se používají datové struktury a "funkce vedle", opět velmi často budeš pracovat se seznamy. Prostě seznam je nativní způsob ukládání něčeho v paměti při interaktivní práci, nezávislý na užitém programátorském paradigmatu
A teď je otázka - existuje nějaký "nativně seznamový" způsob persistentního ukládání dat? Jistě: samotný soubor je seznam bytů. Jenže ten je na nějaké rozumné používání hrozně nešikovný, je třeba nad ním udělat nějakou abstrakci. Tak jakou? Za "seznamovou" by se mohla částečně považovat stromové databáze, nebo jejich moderní inkarnace dokumentové databáze. Ale i tam (např. Mongo) jsou na hlavní úrovni kolekce, tedy množiny. A uvnitř sice jsou seznamy, které se velmi snadno mapují na "objekty" (ve skutečnosti na struktury pro interaktivní práci), což je velmi výhodné.....dokud nepotřebuji pracovat se "seznamy" napříč stromy. Nebo s vlastnostmi v jiném pořadí, než v kterém jsou uložené. Pak se najednou elegance těchto databází ztrácí.
Stejnětak vlastně filesystém - navenek je to stromová struktura, ale seznam souborů v adresáři není seznam, ale set, který se jednou řadí tak, jednou jinak. Stejnětak filesystém samotný je vlastně multiset datových bloků, s nějakým indexem vybudovaným nad tím setem. Když se zamyslíš, tak v podstatě každý aspoň trochu použitelný způsob práce s perzistentními daty daleko spíš připomíná práci se sety, než práci se seznamy.
To, co popisuješ není nekompatibilita mezi OO a SQL, ale je to obecně konflikt mezi strukturami vhodnými na interaktivní práci: kde z principu fungování paměti je výhodné sekvenční zpracování seznamů, a strukturami vhodnými na persistentní storage a vyhledávání dat, kde obecnost matematického množinového popisu poskytuje možnosti, které žádný "list-based approach" přinést prostě nemůže.A v podstatě i odrazem toho jsou debaty mezi SQL a NoSQL táborem: kdy jedni preferují snadnost eleganci a univerzalitu toho množinového popisu, za cenu té nikoli nekompatibility, ale práce navíc při mapování mezi těmi světy. Protože nekompatibilní to není, existuje tam bijekce. Jen je to práce navíc to "namapovat". A právě proto vznikly ORM, aby tu práci navíc co nejvíce odstínily (byť samozřejmě ne zadarmo).
A jsou lidé, kteří místo toho se snaží o co nejpřímější mapování "paměti" do persistentního úložiště, a Ti preferují jednoduchost NoSQL databází, kde je to mapování podstatně jednodušší. Ale ani jeden přístup není "ten jediný správný". Jsou případy, kde univerzálnost toho množinového popisu dalece převáží práci navíc, vynaloženou na mapování mezi těmi světy. A jsou případy, kdy tomu tak není a opravdu přímý "dokumentový" přístup je rychlejší.
A ani jeden z nich nebude mít pravdu, když bude tvrdit, že jeho přístup je "ten nejlepší na vše". Někdy se hodí mít úložiště "univerzální" za cenu té vícepráce - a někdy je ta vícepráce zbytečná.
"Seznamový" pohled na data není nic jiného, než "znásilnění" dat do formátu, s kterým se "algoritmicky dobře pracuje". A jak to u takovéhoto znásilnění bývá, tak je vhodné do té doby, dokud se nad danými daty používá "jeden způsob zpracování", pro který je vhodné způsob uložení dat optimalizovat.
Relační způsob je univerzální. Není "znásilněný", takže v něm jde všechno "dobře". Ale samozřejmě není optimalizovaný pro ten "jeden preferovaný způsob tak", jako stromové/dokumentové databáze.
Způsobů mapování objektů na relace je vícero, určitě ne jeden.
To bych se hádal. Pokud nebereš alternativy, které tu někdo zmiňoval, jako JSON a pole - což je jen jiná forma denormalizace, tak daná datová struktura má IMHO 1:1 rozpad na relace. Nebo máš nějaký konkrétní případ, kde to bude jinak?To, v čem se struktury liší je případně návrh té ukládané datové struktury, kdy se třeba někdy přizpůsobuje, aby se uložila do db vhodným způsobem, ale pokud máš nějakou strukturu entit a jejich vazeb, tak je rozpad na relace jednoznačný. Alespoň ve smyslu jako v příkladu níže.
V DB NoSQL se používají právě ty seznamy proto, aby se tím lesem nemuselo zbytečně courat, to je pazvyk z RDB.
Ne, to není pazvyk z RDB, to je prostě nutnost. Pokud máš učitelský sbor, a chceš jednou "seznam" učitelů, co učí danou třídu, podruhé seznam učitelů, co učí v dané učebně, potřetí seznam těch, co...., a počtvrté seznam žáků, co...., tak se prostě courání přes les principiálně nevyhneš.
Samozřejmě, jde to "emulovat" tak, že máš ve stromě uložen seznam "idček". Jenže to už je lezení přes strom a když se nad tím zamyslíš, tak nejde o nic jiného, než o zakuklený relační přístup.
Někdy to jde také řešit duplikací dat na více místech - ale ani to není jiného, než denormalizace v SQL, která je sice užitečná, ale vždy problematická, takže se Ti najednou výhodnost NoSQL začne ztrácet.
Chybně navržených relačních modelů jsem viděl dost.
Ano, chybně. To je právě to ono. Relační model je buďto správný, nebo chybný. Stromový model může být zcela správně: tedy může do něj být bez problémů zachytitelná jakákoli "realizace daného axiomatického systému" - prostě do něj zachytíš jakoukoli "validní" situaci, a přesto může být pro dané použití naprosto nevhodný. Např. když uděláš stromeček kdy budou nahoře žáci, pod každým žákem seznam jejich předmětů a pod každým předmětem jeho učitel, tak se Ti s tím při vytváření rozvrhu tříd bude pracovat fakt blbě. Ale datový model bude správně: korektně popíše jakoukoli "validní" situaci.
Relační model: kdy budeš mít množiny učitelů, žáků a předmětů a vazby mezi nimi, je daný jednoznačně, a když ho udělá člověk správně, tedy bude respektovat kardinalitu vazeb a z ní plynoucí způsob realizace této vazby, tak je právě jedna implementace takového "systému". A v této implementaci bude realizovatelný "jakákoli" úloha, kterou si vzpomeneš.
-
A teď je otázka - existuje nějaký "nativně seznamový" způsob persistentního ukládání dat? Jistě: samotný soubor je seznam bytů. Jenže ten je na nějaké rozumné používání hrozně nešikovný, je třeba nad ním udělat nějakou abstrakci. Tak jakou?
Takovými typickými seznamy jsou logy. Pro práci s nimi se výborně hodí textové utility grep, sed, awk, které s nimi pracují jako se skutečnými seznamy a zachovávají pořadí. Kdysi jsem na logovacích souborech postavil účetnictví - fungovalo to bezvadně a bylo to i rychlé.
-
ORM je tzv. "leaky abstraction" - https://en.wikipedia.org/wiki/Leaky_abstraction
coz vubec nevadi, pokud nepotrebujete stridat databaze. Hlavni ucel ORM je moznost psat SQL ve vyssim, expresivnejsim jazyce.
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Neni, je to jazyk nizke urovne abstrakce. SQL napriklad neumoznuje jednoduche skladani dotazu ze znovupouzitelnych casti, kdyz chcete pristupovat k nejakemu atributu pres pet joinu, musite je psat znovu a znovu v ruznych dotazech, ktere se navzajem podobaji. ORM a query buildery nahrazuji dynamicke lepeni dotazu z retezcu.
Muzeme se bavit konkretne, ukazte mi priklad SQL dotazu a ja vam ukazu radove kratsi ORM kod, ktery dela to stejne.
Pokud chcete slovickarit jako obvykle, nebudu odpovidat.
-
Mistr vyloží tři blbce, krompáč, lopatu, kolečko a povídá "Tady vykopejte díru a štěrk dejte sem!"
Tři "mladíci" se hádají, čím mají pracovat, jestli je lepší krompáč, lopata nebo kolečko.
Jeden flákne kolečkem o zem a odlétne kus země....kolečko je nejlepší na kopání! Tvrdí zkušeně.
Druhý nabere bordel na lopatu a na lopatě odnese štěrk padesát kroků....nejlepší je lopata!
Třetí vezme krompáč, vykopne kus země, otočí ho naplocho a jako hráběmi vyhrabe vykopaný štěrk, pak zkušeně nahází bordel na krompáč a odnosí to po drtkách. Všichni tři mladíci přikyvují, že KROMPÁČ je nejlepší a že se budou střídat jen u něj... Ostatně je nejzkušenější, tak ostatní přesvědčí...
...a mám radost, že i tady vidím pár takových mladíků... ::) :o ???
-
Nejde třeba použít Postgres která umí fungovat i jako NoSQL, JSON a timeseries databáze (nemám zkušenost)? Kombinujete to někdo takto u Postgres?
Jde. Já mám v tomto aktuálně dobrou zkušenost u MSSQL. Ostatní na tom budou stejně.
-
Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,
Způsobů mapování objektů na relace je vícero, určitě ne jeden.
Mám knihu a autora.
Mám blog galerii obrázků, článek může obsahovat obrázky, článek může obsahovat komentáře, galerie může obsahovat komentáře.
Kolik tě napadá způsobů mapování?
v NoSQL u složitějších případů je poměrně podstatné, jestli se člověk na začátku vývoje "strefí" do datové struktury, která bude vhodná i třeba po letech...
Např. dokumentové DB jsou bezschématové, takže změna struktury se provádí uložením dokumentu v jiném formátu. V RDB je třeba změna statické struktury zvláštními příkazy,
Takže klasický spor staticky typovaný versus dynamicky typovaný?
a to při odstavené DB.
Ale no tak. To tě není hodno.
-
Mistr vyloží tři blbce, krompáč, lopatu, kolečko a povídá "Tady vykopejte díru a štěrk dejte sem!"
Tři "mladíci" se hádají, čím mají pracovat, jestli je lepší krompáč, lopata nebo kolečko.
Jeden flákne kolečkem o zem a odlétne kus země....kolečko je nejlepší na kopání! Tvrdí zkušeně.
Druhý nabere bordel na lopatu a na lopatě odnese štěrk padesát kroků....nejlepší je lopata!
Třetí vezme krompáč, vykopne kus země, otočí ho naplocho a jako hráběmi vyhrabe vykopaný štěrk, pak zkušeně nahází bordel na krompáč a odnosí to po drtkách. Všichni tři mladíci přikyvují, že KROMPÁČ je nejlepší a že se budou střídat jen u něj... Ostatně je nejzkušenější, tak ostatní přesvědčí...
...a mám radost, že i tady vidím pár takových mladíků... ::) :o ???
https://www.krcmic.cz/krumpac-x-krompac/
-
SB: Nereagoval jsem ještě na tyto námitky - přitom jde možná o nejpodstatnější věci:
Např. dokumentové DB jsou bezschématové, takže změna struktury se provádí uložením dokumentu v jiném formátu. V RDB je třeba změna statické struktury zvláštními příkazy, a to při odstavené DB.
To ale překrucuješ, co jsem tvrdil. Nepsal jsem o složitosti provádění změny - koneckonců, když už se provádí změna, je způsob realizace změny schématu ten menší problém - daleko větš problém je nutnost adaptovat aplikaci na tu změnu, to že stará aplikace na nové struktuře nefunguje a nová na staré (anebo se kód zanáší "legacy vydličkama").
Psal jsem o tom, že tam, kde relační struktura nevyžaduje změnu, tak stromová může a dosti často bude, protože stromová struktura je podstatně méně univerzální, než ta relační.
Navíc, jak poukazuje BoneFlute, ta "statická typovanost" SQL databáze má nejen nevýhody, ale i výhody: např. podstatně větší záruky na udržení konzistence dat.
Obchodní analýza se neliší podle použité DB (když to teda nedělá relačník, který návrh systému začne od databáze). Následné mapování objektů do dokumentů je výrazně jednodušší než do relací.
Ke každé struktuře relací existuje mnoho stromových struktur, zachycujících tatáž data. Nikdo nezačíná od databáze. Začíná se od reálných objektů, které nějak mapuješ na (ať už SQL, nebo NoSQL) schéma. U SQL je to mapování (přinejmenším zpravidla) jednoznačné, u stormu prostě jednoznačné není. Má být učitel vlastnost třídy? Nebo třída učitele? Nebo to mají být dvě nezávislé kolekce odkazované idčky? Každý způsob zachycení dat se hodí pro něco jiného - a je třeba zvolit právě jeden. Nic takového není třeba u návrhu relačního schématu řešit.
Analýza SQL i NoSQL začíná úplně stejně: člověk zanalyzuje entity a vztahy mezi nimi. U SQL jsi pak v podstatě hotový, zbytek je "manuální" rozpadnutí do relací. U stromové databáze jsi ale neskončil, naopak je třeba udělat - a rozhodně ne nepodstatný - další krok: udělat analýzu, kterou konkrétní z těchto mnoha stromových struktur zachycujících ten samý logický systém zvolit.
Nemluvě o tom, že ani nemusí existovat stromová struktura, která je vhodná pro realizaci všech požadovaných pohledů na modelovaná data. Ne všechna data v realitě jsou strom a ne vždy je "zjednodušení do stromu" ku prospěchu věci. Nekdy samozřejmě ano.
-
ORM je tzv. "leaky abstraction" - https://en.wikipedia.org/wiki/Leaky_abstraction
coz vubec nevadi, pokud nepotrebujete stridat databaze. Hlavni ucel ORM je moznost psat SQL ve vyssim, expresivnejsim jazyce.
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Neni, je to jazyk nizke urovne abstrakce. SQL napriklad neumoznuje jednoduche skladani dotazu ze znovupouzitelnych casti, kdyz chcete pristupovat k nejakemu atributu pres pet joinu, musite je psat znovu a znovu v ruznych dotazech, ktere se navzajem podobaji. ORM a query buildery nahrazuji dynamicke lepeni dotazu z retezcu.
Muzeme se bavit konkretne, ukazte mi priklad SQL dotazu a ja vam ukazu radove kratsi ORM kod, ktery dela to stejne.
Pokud chcete slovickarit jako obvykle, nebudu odpovidat.
To co umožňuje perzistentní kompozici v SQL se jmenuje pohledy. Pokud si vyrobíte pohled, tak nemusíte opakovaně psát JOINy.
Stačí jednoduchá úloha - mějte relaci obce, a relaci okresy, a pro každý okres dohledejte 10 největších obcí (efektivně).
-
https://www.krcmic.cz/krumpac-x-krompac/
Jsem rád, že můj příspěvek umožnil přispět do diskuze i lidem, jako jste vy.
-
Např. dokumentové DB jsou bezschématové, takže změna struktury se provádí uložením dokumentu v jiném formátu. V RDB je třeba změna statické struktury zvláštními příkazy, a to při odstavené DB.
To ale překrucuješ, co jsem tvrdil. Nepsal jsem o složitosti provádění změny - koneckonců, když už se provádí změna, je způsob realizace změny schématu ten menší problém - daleko větš problém je nutnost adaptovat aplikaci na tu změnu, to že stará aplikace na nové struktuře nefunguje a nová na staré (anebo se kód zanáší "legacy vydličkama").
Psal jsem o tom, že tam, kde relační struktura nevyžaduje změnu, tak stromová může a dosti často bude, protože stromová struktura je podstatně méně univerzální, než ta relační.
Adaptace aplikace na změnu struktury může být rovněž jednoduchá. Stačí ji řídit tokem dat z databáze - pracuje pak se starou i novou verzí bez vidliček. Dělám to tak už dlouho a je to velmi efektivní.
-
Kit: Moh bys to "řízení tokem databáze" nějak rozvést? Nějak si neumím představit, co přesně pod tím myslíš.... a třeba se něco naučím :-)
Toho mít dvě verze kódu pro různé struktury se snad zbavit nemůžeš, ne?
-
Kit: Moh bys to "řízení tokem databáze" nějak rozvést? Nějak si neumím představit, co přesně pod tím myslíš.... a třeba se něco naučím :-)
Toho mít dvě verze kódu pro různé struktury se snad zbavit nemůžeš, ne?
Můžeš. Výsledkem DB dotazu je množina slovníků (asociativních polí). Stačí ji přes nějaký foreach nebo map nasypat do DOMu, který pak předhodíš šabloně, která ho traverzuje a exportuje do výstupní podoby. Chybějící sloupce nezobrazí, přebývající sloupce zobrazí v základním režimu. Nikde žádné vidličky, v šabloně žádné cykly a nejlépe žádné podmínky.
-
Jo, tak to jo - to je v takovém případě rozumný postup, ale to je velmi specifické užití. V okamžiku, kdy Ti na tom závisí nějaká "bussines logika", tak si nedovedu představit, že by to šlo použít. Např. když ti do tabulky zaměstnanců přibydou "skrytí agenti" - které nebudeš chtít zobrazovat na webu v seznamu zaměstnanců - tak už se s takto jednoduchým přístupem nevyřeším. Nemůžu vzít novou databázi a nad ní pustit starou verzi aplikace, prozradil bych Čepigu.
Navíc když budeš chtít pokrýt aplikaci testy, tak by Ti to mělo na té starší db zařvat atd.... Takže jo, beru, že tendle přístup se někdy hodí, ale myslím, že se nedá brát jako "univerzální řešení" na modifikaci či refaktoring databáze.
My to řešíme (ale to asi není nic nového) většinou systémem migrací - tzn. aplikace si vždycky při deployi (jak se to skloňje :-)) upraví databázi na nejvovější verzi. Což jakž takž řeší půl problému (stará db verzus nová aplikace) - dělat "downgrade databáze" je zpravidla problém. Ale to furt neřeší ten základní problém, že s každou změnu struktury db je třeba upravit jak všechen SQL kód tak veškerou bussines logiku dotčené tou změnou, včetně testů. Což může někdy být hodně práce, takže je výhoda, když je schéma DB co nejuniverzálnější a tedy se nemusí měnit.
Předtím jsem nemluvil až tak o přidání sloupce (s tím je zpravidla práce minimum) - na kteréžto, jestli jsem pochopil Tvůj post, je zaměřeno Tvé řešení především - ale o refaktoring vztahů mezi entitami. Kterej se v SQL (pokud člověk neudělá chybu v kardinalitách) dělá zřídka, ale v stromových databázích - z důvodů, které jsem popsal v minulých postech - se mu někdy vyhnout nejde.
-
Jo, tak to jo - to je v takovém případě rozumný postup, ale to je velmi specifické užití. V okamžiku, kdy Ti na tom závisí nějaká "bussines logika", tak si nedovedu představit, že by to šlo použít. Např. když ti do tabulky zaměstnanců přibydou "skrytí agenti" - které nebudeš chtít zobrazovat na webu v seznamu zaměstnanců - tak už se s takto jednoduchým přístupem nevyřeším. Nemůžu vzít novou databázi a nad ní pustit starou verzi aplikace, prozradil bych Čepigu.
K tomuto účelu se dají využít pohledy a původní tabulky zamknout před aplikací. Stará verze se tak k datům nedostane, což je ten lepší případ. Business logiku jsem dal do databáze, protože každý zákazník má svá specifika a chci udržovat jen jednu aplikaci.
Navíc když budeš chtít pokrýt aplikaci testy, tak by Ti to mělo na té starší db zařvat atd.... Takže jo, beru, že tendle přístup se někdy hodí, ale myslím, že se nedá brát jako "univerzální řešení" na modifikaci či refaktoring databáze.
Testy samozřejmě musí vypadat jinak.
My to řešíme (ale to asi není nic nového) většinou systémem migrací - tzn. aplikace si vždycky při deployi (jak se to skloňje :-)) upraví databázi na nejvovější verzi. Což jakž takž řeší půl problému (stará db verzus nová aplikace) - dělat "downgrade databáze" je zpravidla problém. Ale to furt neřeší ten základní problém, že s každou změnu struktury db je třeba upravit jak všechen SQL kód tak veškerou bussines logiku dotčené tou změnou, včetně testů. Což může někdy být hodně práce, takže je výhoda, když je schéma DB co nejuniverzálnější a tedy se nemusí měnit.
Tady mohou pomoci pohledy a uložené procedury. Data z databáze zpracovat reflexí, viz výše. Aplikace v podstatě nepotřebuje znát strukturu databáze, se kterou pracuje.
Předtím jsem nemluvil až tak o přidání sloupce (s tím je zpravidla práce minimum) - na kteréžto, jestli jsem pochopil Tvůj post, je zaměřeno Tvé řešení především - ale o refaktoring vztahů mezi entitami. Kterej se v SQL (pokud člověk neudělá chybu v kardinalitách) dělá zřídka, ale v stromových databázích - z důvodů, které jsem popsal v minulých postech - se mu někdy vyhnout nejde.
Stromové databáze zpracovávám traverzováním, případně v XML použiji XPath. Ovšem pro hromadné výstupy je to traverzování obvykle výhodnější, protože tu strukturu jednoduše znát nemusím.
-
Jo, nacpat co nejvíce bussines logiky do DB je hodně dobrá cesta. Pak se dá samozřejmě dá měnit databázi aplikaci "pod rukama", aniž by si ta vůbec všimla. Ale to už jsme hodně daleko od NoSQL databází, a taky to vyžaduje člověka, co něco umí - pro "běžnýho prací prášek" jsou stored procedure sprostý slovo.
Traversování stromu popř. nějaké wildcardy v XPath věc řeší, ale to je IMHO spíše na jednorázové zpracovávání dat (importy a podobně). Nedokážu si představit (rozumně výkonnou) aplikačku s nějak rozumně velkou databází, která nespoléhá na pevné umístění dat, ale každou entitu hledá kdekoli v stromové struktuře. Zas jsme u toho, že každej postup se hodí někde...
-
Jo, nacpat co nejvíce bussines logiky do DB je hodně dobrá cesta. Pak se dá samozřejmě dá měnit databázi aplikaci "pod rukama", aniž by si ta vůbec všimla. Ale to už jsme hodně daleko od NoSQL databází, a taky to vyžaduje člověka, co něco umí - pro "běžnýho prací prášek" jsou stored procedure sprostý slovo.
Dost se toho dá napsat i bez vnořených procedur - pohledy toho také umí hodně. V některých databázích do nich můžeš i insertovat.
Traversování stromu popř. nějaké wildcardy v XPath věc řeší, ale to je IMHO spíše na jednorázové zpracovávání dat (importy a podobně). Nedokážu si představit (rozumně výkonnou) aplikačku s nějak rozumně velkou databází, která nespoléhá na pevné umístění dat, ale každou entitu hledá kdekoli v stromové struktuře. Zas jsme u toho, že každej postup se hodí někde...
To právě není založeno na hledání v DB (samozřejmě do SELECT dávám selekci i projekci). Dostanu z ní data v nějaké struktuře a teprve v aplikaci hledám, jak ji mám zpracovat. Je to obrácený postup, který je dokonce rychlejší a přizpůsobí se prakticky jakékoli struktuře.
-
Jasně, ale i insertovací pohledy a pohledy vůbec je věc, kterou používá (a teda i umí efektivně použít) jen malá část lidí. Ale jinak samozřejmě, to jsou nástroje, kterejma se v SQL dají krásně zastřít změny DB, což je jedna z výhod SQL řešení.
a teprve v aplikaci hledám, jak ji mám zpracovat.
Možná nerozumím tomu, jak to myslíš, ale nedokážu si představit, jak z velký databáze tímto způsobem dostaneš hledaná data efektivně. Když se zase vrátím k tomu příkladu s předměty a učitely, kde můžu mít jak kolekci učitelů, kde každej má pod sebou předměty, nebo kolekci předmětů, kde každej má pod sebou učitele, tak si nedokážu představit, jak bez znalosti konkrétní struktury z toho vytáhnout např. seznam (unikátních) předmětů, aniž bych např. zkoušel obě možnosti (což znamená vydličky v kódu), nebo stáhnul "celou db" a pak to v ní "naslepo" (oni třeba ty předměty mohou být pověšeny ještě pod třídama atd....) hledal objekty typu předmět.
-
Pane Logiku, já si myslím, že si moc nerozumíme.
-
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Neni, je to jazyk nizke urovne abstrakce...
SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.
-
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Neni, je to jazyk nizke urovne abstrakce...
SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.
Problém všech abstrakcí je, že zjednodušují vývoj, ale zhoršují výkon oproti práci s normalizovanými datovými strukturami. Ideální ORM by umělo dokonale převádět požadavky do SQL, rozhodovat se, kdy užívat transakce a kdy ne, jak uzamykat záznamy, ... Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
ORM a NoSQL volí určitý kompromis, někdy přidávají možnost horizontálního škálování výkonu.
To, co vyvolává hádky mezi zastánci těchto dvou přístupů je právě to, že ten kompromis je od určitého okamžiku už nepřekročitelný, a schopnosti RDBMS databáze se suplují na úrovni aplikace (či jazyka). Z pohledu vývoje je to možná pohodlnější (možná jen zdánlivě, vedou se o tom spory).
Funguje to dobře, když vývoj i zadavatel aplikace jsou srozuměni s tím, co to obnáší a bude obnášet do budoucna. Srážka nastává, když pak přijdou požadavky, nápady, nebo kritika řešení, které by se daly řešit mnohem efektivněji pomocí RDBMS.
Pak si taky všímám, že někteří schopnosti databáze posuzují z pohledu, jak pohodlně jim naservíruje výsledky až k cílovému zpracování. Jiní zase vnímají, že uvnitř těch mechanismů musí být spousta práce (= ztraceného výkonu), která se vynakládá vzdáleně od optima.
Podle mě je ten myšlenkový souboj nerozsouditelný, podobně jako se nedá najít jednoznačná odpověď, jestli koupit levnou Dacii nebo drahé Audi, když jsou obě auta stejně velká a ve městě jezdí stejně rychle (50-80 km/h) a argumentovat tím, "co kdyby přišla potřeba jezdit napříč Evropou". Jeden koupí preventivně Audi, druhý si koupí letenku a oba jsou spokojení se svým řešením.
-
SB:
To si asi nerozumíme. Ale když nenapíšeš v čem, tak to působí, že si radši ani rozumět nechceš :-)
Vezmu stejný příklad jako jsem psal: učitele a předměty ve škole. V SQL to namodeluju jednoduše a existuje pouze jeden způsob, který dodržuje pravidla: tabulka učitelů, tabulka předmětů, a vazební tabulka X učí Y.
Jak toto namodeluješ v dokumentové databázi? Jako kolekci učitelů, kde každej bude mít pod sebou seznam "učených předmětů"? Jako kolekci předmětů, kde každej bude mít pod sebou seznam učitelů, co je učí? Nebo jako dvě nezávislé kolekce, kde v každém prvku každé kolekce bude seznam odkazů na prvky té druhé kolekce (X učí Y a Y je učen X)? Nebo jinak?
Jaké konkrétní řešení zvolíš a proč? A je Tebou zvolené řešení jediné "správné", nebo bys jindy volil jiné?
Kit měl asi na mysli PL/SQL
To IMHO neměl. Navíc se pleteš. Jednak PL/SQL i PL/PgSQL např. jak struktury, tak seznamy umí, viz např.
https://docs.oracle.com/cd/A84870_01/doc/java.816/a81354/oraoot2.htm
https://www.oracletutorial.com/plsql-tutorial/plsql-varray/
(https://docs.oracle.com/cd/A84870_01/doc/java.816/a81354/oraoot2.htmhttps://www.oracletutorial.com/plsql-tutorial/plsql-varray/a)jednak např. v Postgresu klidně můžeš psát stored procedures třeba v Pythonuhttps://www.postgresql.org/docs/9.0/plpython.html (https://www.postgresql.org/docs/9.0/plpython.html)
jakákoliv práce se seznamy znamená opakované čtení dat z tabulek.
Což jednak není pravda (viz výš), jednak (např. díky temporary tables atd...) ani opakovaný select vybraných dat nemusí být žádný problém.
Ty furt cpeš SQL do pozice jednoduchého jazyka na primitivní selekty, jako znáš z dokumentovejch databází. Čím více osekáš SQL (a návazné technologie), tím to samozřejmě líp zapouzdříš do nějakého ORM, aniž by to bylo omezující. To je sice jeden z možných usecase pro SQL (kde jsou případy, kdy tento přístup bude lepší než NoSQL - kvůli univerzálnějšímu způsobu uložení dat a s tím spojenou schopností DB optimalizovat plány a číst data z DB efektivně - ovšem také případy, kdy bude NoSQL podstatně lepší volba) - ale zbytečně tím házíš mnoho z možností, které SQL nabízí, do kanálu.
Miroslav:To bych podepsal. A ještě bych přidal, že bohužel dosti často majitelé Audi haněj letadla, že je to neflexibilní řešení, a Ti co létají haněj Audi, že jsou drahé. A to zpravidla Ti, co třeba nikdy tím letadlem neletěly, takže nevidí jeho výhody a jen nevýhody - a naopak.
-
Adaptace aplikace na změnu struktury může být rovněž jednoduchá. Stačí ji řídit tokem dat z databáze - pracuje pak se starou i novou verzí bez vidliček. Dělám to tak už dlouho a je to velmi efektivní.
Přesně tak. Aplikace (server) od začátku přímo počítá s různorodostí a změnou dat (což je tak nějak z podstaty nevyhnutelným požadavkem pocházejícím ze skutečného světa). Ví, který záznam v kterém formátu ukládá a naopak čte, podle toho rekonstruuje doménový model v paměti. Mimoto si sama řeší kontrolu dat a konzistenci (to musí bez ohledu na DB), takže p*cat se s tím ještě v DB netřeba. Jakékoliv změny tedy znamenají zapracování práce s novým formátem do doménového modelu (zde neřeším GUI atd.) bez zásahů do DB.
To samé v RDB znamená upravit schéma (nedej bože předělávat procedury a ladit je), upravit data (ano, obvykle s odstávkou DB, aby se to celé nepodělalo (závisí na provedení RDB)), v aplikaci přepracovat obvykle statickou strukturu na jinou. V případě, je-li aplikace statická, pak synchronizace nasazení změn DB a aplikace.
Ale pane Logiku, ať se nehádáme: Dělejte si to, jak chcete.
-
A ještě bych přidal, že bohužel dosti často majitelé Audi haněj letadla, že je to neflexibilní řešení, a Ti co létají haněj Audi, že jsou drahé. A to zpravidla Ti, co třeba nikdy tím letadlem neletěly, takže nevidí jeho výhody a jen nevýhody - a naopak.
Mám stejný pocit. Mám dokonce častou zkušenost, že když se zavilým příznivcům ORM a NoSQL na konkrétních usecasech ukáže ekvivalent v RDBMS, tak pochopí, že výsledná složitost není vyšší a potenciál výkonu vyšší je ("kdybych býval věděl, co budu potřebovat a jak se projekt vyvine, tak bych použil RDBMS od začátku, protože by to byla stejná práce a výsledek lepší").
Na druhou stranu ale neignorujme, že někdy je flexibilita řešení cennější, než jeho výkon. Mnohdy, v reálném životě, je lepší hrnout rychle neoptimální řešení. Často se v praxi přijde na to, že včerejší nápad je potřeba dnes stejně přehodnotit (ne kvůli technickým nedostatkům, ale prostě v životě nefunguje) - a to se stihne 2x udělat rychleji, než v RDBMS rozmyslet první změnu ve schematu.
-
SB:
To si asi nerozumíme. Ale když nenapíšeš v čem, tak to působí, že si radši ani rozumět nechceš :-)
Nenapíšu, nic tím nezískám. Vývoj aplikací vaším způsobem jsem byl nucen dělat roky a vracet se k tomu nechci ani myšlenkou. Užijte si to.
P. S.: Všimněte si, že vám netykám, ani jinak neříkám vole, p*čo či soudruhu. Nenapadá vás proč?
-
a teprve v aplikaci hledám, jak ji mám zpracovat.
Možná nerozumím tomu, jak to myslíš, ale nedokážu si představit, jak z velký databáze tímto způsobem dostaneš hledaná data efektivně.
Samozřejmě nejprve udělám selekci i projekci, abych dostal jen ta data, která potřebuji. Každý záznam pak považuji za kolekci složenou z key:value. Každý key použiji jako klíč pro další zpracování value. Nevyhledávám tedy data ve výsledku, ale algoritmus, kterým ta data mám zpracovat. Říká se tomu metoda push. Úplně nejjednodušší je však celý záznam nasypat do DOMu - výstupní šablona si s tím poradí včetně formátování a překladů.
-
SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.
To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL
https://en.wikipedia.org/wiki/Ada_(programming_language)
-
Vývoj aplikací vaším způsobem jsem byl nucen dělat roky a vracet se k tomu nechci ani myšlenkou.
Ale já přeci nechci, abys to vyvíjel po mém. Já se Tě ptám, jak takováto data uložíš po svém. Teda jaký přístup použiješ v NoSQL databázích, které tu hájíš jako "jediný správný způsob".
Ten příklad totiž přesně ukazuje, že stromová struktura má své limity, a že některá data do ní nejde dostat tak, aby byly univerzálně použitelné. Což znamená v případě, kdy existuje dobré stromové zjednodušení, práci při analýze navíc, a v případě kdy neexistuje, horší výkon výsledného řešení (anebo nějakou formu denormalizace a duplikace dat navíc, což přidělá práci).Což bys pochopil, kdybys místo výmluv tu výzvu vzal a nad řešením se zamyslel. Takto mám pocit, že se snažíš odpovědi vyhnout, protože nevíš, jak bys rozumně odpověděl.
Btw. - ne, určitě si nevyvíjel věci po mém. Zaprve neexistuje "po mém" - já narozdíl od Tebe netvrdím, že existuje "jeden správný způsob". A zadruhé, kdybys opravdu dělal skutečný (nazvěme to třeba) SQL-vývoj, tak bys věděl některé věci (např. o PL/SQL), které jsi evidentně nevěděl. Působíš na mne, jako by Tě v nějaké firmě nutili dělat v SQL, aniž by Tě naučili alespoň základní věci kolem něj - a že jsi z toho byl (vcelku oprávněně) frustrovanej - a tak je pro tebe cokoli, co Tě od SQL odstíní (ORM, NoSQl,....) "výhra". To ale není chyba SQL, ale chyba té firmy, kdes dělal....
Ví, který záznam v kterém formátu ukládá a naopak čte, podle toho rekonstruuje doménový model v paměti. Mimoto si sama řeší kontrolu dat a konzistenci (to musí bez ohledu na DB), takže p*cat se s tím ještě v DB netřeba. Jakékoliv změny tedy znamenají zapracování práce s novým formátem do doménového modelu
A po takových deseti změnách formátu je z databáze i kódu guláš, kdy v db jsou uloženy záznamy v deseti verzích, z kódu je nečitelný guláš počítající s deseti různými formáty záznamu, a nedej bože, jestli je třeba udělat větší refaktoring struktury, pak mám polovinu záznamů daného typu támdle (např. předměty pod učitelema) a polovinu úplně jinde (např. "nad učitelema"), což vede k velmi "efektivnímu" čtení takto po databázi "rozsypanejch" dat.
konzistenci (to musí bez ohledu na DB), takže p*cat se s tím ještě v DB netřeba
Vzhledem k tomu, v jakém stavu jsou často DB, kde se řeší konzistence dat jak na klientu, tak na serveru, tak se obávám, že to je teorie nestřetávající se s realitou. Možná jsi geniální člověk, který nikdy neudělal chybu a druhou kontrolu nepotřebuje. Pak se ovšem smiř s tím, že jsi na světě jediný, a že Tvý kolegové chyby dělat budou. Mraky chyb je i v databázích, kde je doublecheck na klientovi i na serveru. Natož když jednu z nich odstraníš.
To samé v RDB znamená upravit schéma
A? Schéma "v hlavě" upravit musíš tak jako tak - i v sql i v nosql databázi. A napsat k němu dokumentaci (v NoSQL o to podrobnější, že Ti schází struktura tabulky, která ji částečně může nahradit). Vyplivnout úpravu schématu do SQL kódu je oproti tomu už detail.
(nedej bože předělávat procedury a ladit je
Zatímco v Tvém řešení musíš upravit procedury tak, aby počítaty se záznamy v starém i novém formátu, v SQL řešení stačí je upravit pouze na nový formát. To je jednodušší úkol, nikoli složitější. Že ve svém řešení nemáš prodcedury? Ale máš. Akorát je máš nikoli v DB, ale na klientovi, což je - pokud umíš pracovat s DB - vlastně úplně jedno. Viz např.
https://www.pgadmin.org/docs/pgadmin4/development/debugger.html (https://www.pgadmin.org/docs/pgadmin4/development/debugger.html)
Kit:
Samozřejmě nejprve udělám selekci i projekci, abych dostal jen ta data, která potřebuji.
Ale to je problém slepice nebo vejce. Těžko uděláš projekci a selekci, když neznáš strukturu a nevíš, co a jak projektovat a strukturovat.
Jako jo, není výjimka, že se nějaké "listové atributy" (tam, kde se dají data aspoň nějak zestromovatět) ukládají v RDBS např. do JSONu a tam pak je Tvůj postup dobře použitelný, ale IMHO to rozhodně není univerzální model na to, jak pracovat s daty v nějaké aplikaci.
-
SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.
To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL
https://en.wikipedia.org/wiki/Ada_(programming_language)
Který z výše uvedených problémů to řeší?
-
SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.
To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL
https://en.wikipedia.org/wiki/Ada_(programming_language)
Který z výše uvedených problémů to řeší?
PL/SQL je plnohodnotný jazyk - podporující struktury, kolekce, kolekce kompozitních typů, globální proměnné. Takže jednoduše si můžete uložit seznam id, i seznam kompozitních hodnot. A můžete s nimi pracovat v PL/SQL, tak i v SQL. Kolekce je dictionary, hash tabulka, takže můžete dělat rychlé lookupy. I mnohem primitivnější T-SQL má inmemory tabulky - což jsou defakto pole kompozitních hodnot - a PL/pgSQL má pole jak skalárních hodnot, tak kompozitů - a existují konstrukce pro úzkou integraci s SQL. Je to mnohem efektivnější než z aplikačního serveru, protože nepřesouváte data po síti. Jinak, co PL/SQL umožňuje přenášení parametrů odkazem, co je samozřejmě rychlé. V Postgresu znám implementaci - všechny větší objekty se předávají funkcím přes ukazatele. Pouze, když je modifikujete, tak se vytváří kopie.
Jinak ke všem mně známým jazykům uložených procedur existují debuggery. Debugování je úplně v pohodě.
V podstatě nic z toho, co tu píšete o uložených procedurách není tak posledních 20 let pravda.
-
Kit:
Samozřejmě nejprve udělám selekci i projekci, abych dostal jen ta data, která potřebuji.
Ale to je problém slepice nebo vejce. Těžko uděláš projekci a selekci, když neznáš strukturu a nevíš, co a jak projektovat a strukturovat.
Jako jo, není výjimka, že se nějaké "listové atributy" (tam, kde se dají data aspoň nějak zestromovatět) ukládají v RDBS např. do JSONu a tam pak je Tvůj postup dobře použitelný, ale IMHO to rozhodně není univerzální model na to, jak pracovat s daty v nějaké aplikaci.
Používám to na relačních datech. Ano, při projekci i selekci potřebuji znát seznam sloupců i kandidátních klíčů. Pokud to vadí, použiji pohled nebo vloženou proceduru. Pak si vystačím s "SELECT * FROM Pohled" nebo "CALL procedura(parametry)". Je to pro mne jednodušší, než to komplikovaně řešit v ORM. Také je to podstatně rychlejší - někdy i o dva řády.
Co je však podstatné, mám jednu šablonu na mnoho druhů výstupů z databáze. Ta šablona se jim jednoduše přizpůsobí a zobrazí data v závislosti na názvu pohledu i na dodaných sloupcích. Jen u větších projektů tu šablonu dělím na více menších, které dědí z jedné společné.
-
My to řešíme (ale to asi není nic nového) většinou systémem migrací - tzn. aplikace si vždycky při deployi (jak se to skloňje :-)) upraví databázi na nejvovější verzi. Což jakž takž řeší půl problému (stará db verzus nová aplikace) - dělat "downgrade databáze" je zpravidla problém. Ale to furt neřeší ten základní problém, že s každou změnu struktury db je třeba upravit jak všechen SQL kód tak veškerou bussines logiku dotčené tou změnou, včetně testů. Což může někdy být hodně práce, takže je výhoda, když je schéma DB co nejuniverzálnější a tedy se nemusí měnit.
Předtím jsem nemluvil až tak o přidání sloupce (s tím je zpravidla práce minimum) - na kteréžto, jestli jsem pochopil Tvůj post, je zaměřeno Tvé řešení především - ale o refaktoring vztahů mezi entitami. Kterej se v SQL (pokud člověk neudělá chybu v kardinalitách) dělá zřídka, ale v stromových databázích - z důvodů, které jsem popsal v minulých postech - se mu někdy vyhnout nejde.
IMHO jedinej způsob - verzování:
Přihlásím se k verzi 1, a pošlu změny. Ve verzi 1 jsou háčky, které informují verzi 2. Verze 2 zpracuje události, a protože zná rozdíli, tak převede data z verze 1, na verzi 2. Verze 2 taky nemusí být poslední, tak se to přesouvá až po tu poslední, která jediná uloží data do databáze.
V reálu samozřejmě většina těch verzí už bude mrtvá, takže to bude 53 -> 54, maximálně 52 -> 53 -> 54.
V reálu ale málokdy a málokdo řeší tak ultimátní transparentnost, a většinou se prostě aplikace vypne -> zaktualizuje -> zapne. Což je sice na uživatele nemilosrdné, ale zase nevzniká ta obrovská zátěž v podobě držení zpětné kompatability.
-
Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
V tomto se hrubě neshodneme.
Díky tomu nelze souhlasit s tvými závěry.
-
Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
V tomto se hrubě neshodneme.
Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.
Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.
(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)
-
Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
V tomto se hrubě neshodneme.
Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.
Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.
(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)
Vůbec nereaguješ na to co píšu.
-
Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
V tomto se hrubě neshodneme.
Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.
Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.
(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)
Vůbec nereagujete na to co píšu.
A na co tedy? Psal jsem, že stejně definitivně namapovat v ORM nebo jiné abstrakci datové struktury, aby byly srovnatelné výkonné, by byla stejně složitá práce, jako rovnou používat SQL.
-
Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
V tomto se hrubě neshodneme.
Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.
Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.
(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)
Vůbec nereagujete na to co píšu.
A na co tedy? Psal jsem, že stejně definitivně namapovat v ORM nebo jiné abstrakci datové struktury, aby byly srovnatelné výkonné, by byla stejně složitá práce, jako rovnou používat SQL.
Tak, to už je lepší. A v tom se neshodneme. Podle mne nebylo.
Ve skutečnosti si s něčím takovým hraju, takže to mám z první ruky. Napsat pravidla, kdy tomu ORM řeknu, že v tomto případě má použít tuto nebo jinou strategii je trivka.
-
Ve skutečnosti si s něčím takovým hraju, takže to mám z první ruky. Napsat pravidla, kdy tomu ORM řeknu, že v tomto případě má použít tuto nebo jinou strategii je trivka.
Ona je trivka i data rozložit do RDBMS - to je asi o osobní preferenci.
Pointa je v tom, že obě práce vedou k tomu samému - jen jinými prostředky, jiným jazykem a v jiných momentech popisujete totéž.
U objektových databází a ORM máte rychlý start a problémy lze dlouho řešit triviálními "hinty". Pak to narazí na mantinel, kde už s tím nejde hnout jinak, než refactoringem aplikace a horizontálním škálováním.
U RDBMS strávíte nějaký čas na začátku a v průběhu optimalizací. Na opravdový limit, kdy by bylo potřeba refactorovat aplikaci narazíte o mnoho později.
Abyste rozuměl, nehádám se o tom, že jeden přístup exceluje nad druhým. Pro oba mám pochopení a u obou vidím nevýhody i výhody.
Z části vznikají flamewary i z toho, že pro spoustu lidí je MySQL / MariaDB jediný RDBMS, který kdy poznali. Pokud bychom zúžili diskusi na MySQL, pak bych stál taky prakticky bezvýhradně na straně ORM a objektových databází.
-
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....
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...
-
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í.
-
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.
-
(omyl, smazáno)
-
Tak co? Už jste něco vyřešili? :P
-
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.
-
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.
-
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í.
-
...
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. :-)
-
...
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".
-
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
-
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
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
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
-
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
-
doporucuji se podivat na http://docs.peewee-orm.com/en/latest/ , coz je podle me ORM udelane spravne, pripadne SQLAlchemy
-
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
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
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.
-
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).
-
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).
to neni querybuilder, je to plnohodnotne ORM, ale umoznuje jit o uroven niz. Doporucuji se podivat na praci s relacemi (nemusite psat stale dokola podminky joinu jako blbec), praci s migracemi atd.. Navic ty dotazy pisete v Pythonu, mnohem jednodussi generovani dynamickych dotazu nez lepeni ze stringu.
-
Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)
Ono to obvykle naráží i na to, že takový query builder neumí celý dialekt dané databáze (nebo její verze), takže to stejně skončí u exec("SELECT ...").
-
Kdyz uz mate ORM schema, muzete z neho automaticky generovat webove formulare, REST API, GraphQL api. ORM umoznuje pridani informaci, ktere SQL nepodporuje, treba ruznych pokrocilejsich validaci.
-
Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)
Ono to obvykle naráží i na to, že takový query builder neumí celý dialekt dané databáze (nebo její verze), takže to stejně skončí u exec("SELECT ...").
query buildery umoznuji kombinovat raw SQL, takze umi cokoliv
-
Kdyz uz mate ORM schema, muzete z neho automaticky generovat webove formulare, REST API, GraphQL api. ORM umoznuje pridani informaci, ktere SQL nepodporuje, treba ruznych pokrocilejsich validaci.
To jsme zase u jádra pudla. Třeba ty "pokročilejší validace" obvykle obnášejí to, co psal Pavel - čtení dat a iterace v kódu programu. Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.
Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)
Ono to obvykle naráží i na to, že takový query builder neumí celý dialekt dané databáze (nebo její verze), takže to stejně skončí u exec("SELECT ...").
query buildery umoznuji kombinovat raw SQL, takze umi cokoliv
Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.
-
Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.
databaze je vetsinou uzke hrdlo aplikace, aplikacni kod lze snadno horizontalne skalovat.
-
Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.
mozna u 1% dotazu, u zbytku vam to usetri praci. Mel byste priklad takoveho dotazu, ktery nejde napsat v querybuilderu?
-
Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.
mozna u 1% dotazu, u zbytku vam to usetri praci. Mel byste priklad takoveho dotazu, ktery nejde napsat v querybuilderu?
Typicky složité updaty, případně zřetězené s WITH.
Stačí mít UPDATE ... SET sl1.subquery.sl1, ..., FROM (SELECT ...) AS subquery, ...
Jakmile do toho subquery potřebujete zahrnout window funkce, řazení přes kostku, ..., tak už docela jistě narazíte. Pokud nenarazíte, bude ten zápis stejně nečitelný.
Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.
databaze je vetsinou uzke hrdlo aplikace, aplikacni kod lze snadno horizontalne skalovat.
Což považuji za tradovaný omyl, pramenící z neschopnosti využívat vlastností SQL.
Prakticky nikdy nenaleznete případ, kdy by byla aplikace výkonnější, než databázový stroj. I ideálně napsaný aplikační kód bude mít hendikep ve zbytečném síťovém provozu a nárocích na další prostředky.
Situací, kde je nevyhnutelná potřeba horizontálního škálování, je tak málo, že je dost nepravděpodobné, že by se s tím programátoři setkávali. Obvykle je horizontální škálování z nouze ctnost.
-
Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.
mozna u 1% dotazu, u zbytku vam to usetri praci. Mel byste priklad takoveho dotazu, ktery nejde napsat v querybuilderu?
Typicky složité updaty, případně zřetězené s WITH.
Stačí mít UPDATE ... SET sl1.subquery.sl1, ..., FROM (SELECT ...) AS subquery, ...
Jakmile do toho subquery potřebujete zahrnout window funkce, řazení přes kostku, ..., tak už docela jistě narazíte. Pokud nenarazíte, bude ten zápis stejně nečitelný.
prave v praci s poddotazy vyniknou vyhody ORM a query builderu, muzete snadno dotaz skladat z mensich celku.
-
Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.
databaze je vetsinou uzke hrdlo aplikace, aplikacni kod lze snadno horizontalne skalovat.
Pokud nebudete počítat bitcoiny, tak drtivou většinu operací můžete bezproblémově počítat v databázi. Úzkým hrdlem jsou diskové operace, případně přístupy do RAM. CPU většinou u běžných OLTP aplikací se fláká. Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.
-
Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.
pridani validaci na klientu naopak snizi prenos dat mezi klientem a serverem (nevalidni data se na server vubec nedostanou).
jinak databaze je uzke hrdlo temer u vsech aplikaci s trochu vetsim trafikem.
-
Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.
pridani validaci na klientu naopak snizi prenos dat mezi klientem a serverem (nevalidni data se na server vubec nedostanou).
jinak databaze je uzke hrdlo temer u vsech aplikaci s trochu vetsim trafikem.
Vstupy musíte validovat, ale konzistenci dat taky. To se nevylučuje.
Ale hovořil jste o složitější validaci - a pod tou si představuji např. to, že k validaci potřebuji ověřit data v jiných strukturách, abych mohl říct, že vkládaný vstup je v pořádku.
To určitě nezpůsobuje úzké hrdlo.
Databáze jsou úzké hrdlo, protože spousta lidí je neumí používat. Dejte mi příklad, kde je úzkým hrdlem databáze, můžeme si k tomu napsat.
-
Databáze jsou úzké hrdlo, protože spousta lidí je neumí používat. Dejte mi příklad, kde je úzkým hrdlem databáze, můžeme si k tomu napsat.
temer libovolna webova aplikace s vetsim provozem a vypnutym cachovanim, treba i tohle forum, kdyby tu bylo vetsi mnozstvi diskuteru. Netvrdim, ze preneseni aplikacni logiky na server ma vzdy nejaky zasadni negativni vliv, ale urcite neplati opak (databaze je vzdy efektivnejis) jak tvrdite vy.
-
Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.
pridani validaci na klientu naopak snizi prenos dat mezi klientem a serverem (nevalidni data se na server vubec nedostanou).
jinak databaze je uzke hrdlo temer u vsech aplikaci s trochu vetsim trafikem.
Kontrola na aplikační straně má tu nevýhodu, že se dá "snadno" obejít, zapomenout, ... db server side kontrolu vám nikdo neobejde. Jinak není na škodu mít kontroly implementované 2x - pro interaktivní práci různé validátory na klientovi, a pak na databázové straně, která vám garantují kvalitu dat.
Samozřejmě, že databáze je u databázových aplikací hrdlem - čekáte na disky, případně na zámky, ale to budete čekat tak jako tak. Když ale přidáte správně indexy, tak dnešní servery bezproblémově utáhnou desítky tisíc uživatelů. Před dvěma měsíci jsem pro jednoho zákazníka pomáhal doladit databázi, která měla něco kolem 200GB, a 10K současně pracujících uživatelů nevygenerovalo znatelnou zátěž na CPU. Po přidání správných indexů - trhnul jsem rekord - dotaz jsem zrychlil 10 000 krát.
-
Databáze jsou úzké hrdlo, protože spousta lidí je neumí používat. Dejte mi příklad, kde je úzkým hrdlem databáze, můžeme si k tomu napsat.
temer libovolna webova aplikace s vetsim provozem a vypnutym cachovanim, treba i tohle forum, kdyby tu bylo vetsi mnozstvi diskuteru. Netvrdim, ze preneseni aplikacni logiky na server ma vzdy nejaky zasadni negativni vliv, ale urcite neplati opak (databaze je vzdy efektivnejis) jak tvrdite vy.
Zkuste mi vysvětlit, v čem si myslíte, že může být aplikace efektivnější - třeba v tom případě více používaného fóra. Mně nenapadá nic, co bych dokázal udělat v aplikaci rychleji, než to přenést do databáze. Včetně označení uživatelem nepřečtených příspěkvů, včetně označení přečtených, ... (Pokud ovšem nezvolím, že to bude client-side logika, ale to asi není případ, o kterém hovoříme zde).
-
Databáze jsou úzké hrdlo, protože spousta lidí je neumí používat. Dejte mi příklad, kde je úzkým hrdlem databáze, můžeme si k tomu napsat.
temer libovolna webova aplikace s vetsim provozem a vypnutym cachovanim, treba i tohle forum, kdyby tu bylo vetsi mnozstvi diskuteru. Netvrdim, ze preneseni aplikacni logiky na server ma vzdy nejaky zasadni negativni vliv, ale urcite neplati opak (databaze je vzdy efektivnejis) jak tvrdite vy.
Cache je dobrá - zvlášť pro webky, které na jeden refresh stránky vygenerují 300 dotazů. Co jsem už také viděl. Dnešní servery dávají cca 3000 - 6000 dotazů za sec na 1 CPU vlákno. Takže, když máte server, který má 32 vláken, tak bez problémů zvládnete 20-40 000 dotazů za sec (většinou tyto web aplikace generují primitivní dotazy). Nicméně aktivní cache pro web aplikace (pro stránky) je důležitá - ušetříte jednak dotazy, druhak hromadu operací se řetězcema (a navíc se většinou dobře cacheuje).
U databázových aplikací ale většinou negenerujete interface, a také dost často nemůžete použít cache - ale většinou vygenerujete na obrazovku 10 dotazů - a tam pokud neděláte nějaké šílenosti, tak běžné servery utáhnou bezproblémově aplikace pro střední evropu.
-
300 dotazů na jeden refresh stránky :o :o :o
WTF (?)
Bavíme se o jedné jediné běžné webové stránce? :o
Tři sta dotazů :o
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?
-
300 dotazů na jeden refresh stránky :o :o :o
WTF (?)
Bavíme se o jedné jediné běžné webové stránce? :o
Tři sta dotazů :o
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?
Rekord, v mojí praxi, co jsem pomáhal řešit, bylo něco přes 500 dotazů na jeden reload stránky. Postaralo se o to ORM.
Po optimalizaci to bylo 6 dotazů.
Daleko běžnější je potkat cca 50 dotazů, které se dají zredukovat na pět i méně, ale smysluplných. Čísla dávám odhadem, statistiku jsem nevedl.
-
cca 50 dotazů
Ano, cca 50 bych čekal a často mají svůj důvod.
Také chápu, že se dají optimalizovat, ale vesměs to (podle mě) nemá smysl.
Čas propálený optimalizací bývá o řád dražší než pořídit o trochu silnější železo.
Mimo to, sám jsem se spálil, tak jsem optimalizoval, až byl z optimalizovaných dotazů prasečí chlívek.
Rychlý, ale chlívek. A honit chybu napříč systémem po jednotlivých dotazech byl fujtajbl.
-
300 dotazů na jeden refresh stránky :o :o :o
WTF (?)
Bavíme se o jedné jediné běžné webové stránce? :o
Tři sta dotazů :o
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?
Samozřejmě, že je to extrém - ale ve své době to byla relativně rozšířená aplikace (rok 2009). Firma, kde jsem tehdy pracoval ji používala pro správu tiketů (takový centrální mozek), a pro 300 zaměstnanců už to byl brutus. Nakonec se ukázalo, že největší průser byl vlastně samostatný dedikovaný server - a síťové latence. V tomhle počtu už to dělalo hodně. Paradoxně pomohlo dát na jeden server apache, i databázový server, a zbavit se režie sítě. Nicméně viděl jsem i nějaké portály - které na refresh stránky generovaly vyšší desítky dotazů a bez cache to pro vyšší návštěvnost (v rámci ČR) nedávalo. Na druhou stranu, zrovna oni pak jednoduchou cache vyřešili 95% přístupů.
-
Ano, cca 50 bych čekal a často mají svůj důvod.
Také chápu, že se dají optimalizovat, ale vesměs to (podle mě) nemá smysl.
Čas propálený optimalizací bývá o řád dražší než pořídit o trochu silnější železo.
Málokdy potřebujete tolik živých entit na jednu stránku.
Železem to nedotáhnete, náročnost roste se zátěží a daty víc, než lineárně. To se dá železem dotáhnout z počátku, ale na limit to narazí dřív, nebo později.
Především ale není zas tak těžké umět řemeslo tak, že taková situace ani nevznikne. To pak nestojí prakticky žádný čas navíc, ani to železo.
Už jen na těch padesáti dotazech máte dost nepříjemnou 50x režii na dotaz; pokud je DB stroj síťový (což u větších projektů chcete, protože dřív nebo později to budete potřebovat oddělit), tak už je velmi citelná.
Mimo to, sám jsem se spálil, tak jsem optimalizoval, až byl z optimalizovaných dotazů prasečí chlívek.
Rychlý, ale chlívek. A honit chybu napříč systémem po jednotlivých dotazech byl fujtajbl.
Tady už nemůžu polemizovat, musel bych vidět konkrétní situaci. Pokud je tím myšleno to, co si domýšlím, tak to lze dobře řešit pohledy a procedurami, chlívek se pak nekoná.
-
pohledy
Ano, pohledy jsou z hlediska optimalizací dobré, výrazně lepší než samostatné selecty.
Tenkrát jsem si naběhl a při refaktorizaci se pěkně zapotil...a poučil.
Železem to nedotáhnete, náročnost roste se zátěží a daty víc, než lineárně.
To určitě nelze paušalizovat!
Pan Stěhule to myslím kvantifikoval celkem slušně - Dnešní servery dávají cca 3000 - 6000 dotazů za sec na 1 CPU vlákno. Takže, když máte server, který má 32 vláken, tak bez problémů zvládnete 20-40 000 dotazů za sec
Jen slovo vlákno bych nahradil (samostatné) jádro.
Vlákna se dají na jádru pouštět souběžně tak dvě, případně tři pokud je zapnuté HT, výš už to - pokud je aplikace dobře napsaná - moc neškáluje. Pokud jsou součástí jádra blokovací operace, tak se zase nedostanete na ten počet dotazů.
Jinými slovy: 40 000 / 40 dotazy na stránku = ~10 000 souběžných uživatelů. Jenže cache chytne hrozně moc.
Z mého pohledu je důležité, aby se server nestaral o podávání triviálních věcí jako CSS, cachování, podávání obrázků a v neposlední řadě žrouta ve formě HTTPS spojení. Takže zatímco pomocí Cache zvednete počet návštěvníků i na osminásobek, ladění aplikace by určitě nepřineslo stejný efekt. Leda později, až i tak je často levnější přidat druhý server.
No ale já jsem jen prostý pobíječ much, třetiřadý programátor pracující v druhořadé firmě za prvořadé peníze :P
-
Za provadeni dotazu v cyklu nemuze ORM. Uplne stejne muzete v cyklu volat nejakou funkci, ktera dotazuje databazi i bez ORM.
-
...
Když máte 10000 dotazů, ale po 50 dotazech na požadavek, nakumulujete 50x latenci.
Když máte 10000 dotazů, ale po 5 dotazech na požadavek, nakumulujete latenci 5x.
V obou případech bude server zvládat stejně, ale v prvním případě bude aplikace 10x pomalejší. Pohled ze strany serveru nevypovídá tak přesně o výkonu aplikace.
Zmiňujete cachování, ale i to se liší. Cache blíž ke zpracování (cache RDBMS, cache OS, cache řadiče, cache CPU, ...) jsou efektivní v tom, že dávají přesná data mnohem rychleji. Někdy se ale pojem "cache" užívá v aplikační úrovni, a často je to za cenu mírně nepřesných výsledků (např. zpožděných).
Aplikační cache, která by měla přinejmenším revalidovat relevanci uložených informací, se nevyhne (opět, překvapivě) určité latenci. Ta latence bývá na tolik významná, a revalidace tím pádem na tolik náročná, že ve spoustě případů se vyplatí vzít rovnou data, než se s cache patlat. Pokud máte na mysli cache s potenciálně neaktuálními daty, pak se dostáváme na půdu unfair srovnání, a taky budeme řešit, co všechno z takového přístupu vyplývá za rizika.
-
Za provadeni dotazu v cyklu nemuze ORM. Uplne stejne muzete v cyklu volat nejakou funkci, ktera dotazuje databazi i bez ORM.
Volat v cyklu funkci, která dotazuje databázi, je návrhový antivzor. SQL je tak komplexní dotazovací jazyk, aby se tomu dalo vyhnout.
V případě užití ORM se tomu prakticky vyhnout nedá.
-
V případě užití ORM se tomu prakticky vyhnout nedá.
mytus, to platilo mozna pred dvaceti lety u nejakych primitivnich javovskych ORM.
-
naopak, pokud potrebujete v aplikaci vykreslovat nejake tabulky a v ruznych tabulkach se opakuji sloupce, treba jen s malou obmenou, s ORM muzete snadno sestavovat dotazy DRY zpusobem.
treba v Djangu staci k dotazu pridat
.annotate(sloupec_vysledku=funkce_generujici_sql(parametry))
ten kod muze pridat treba slozity join, CASE konstrukci a podobne
VZDY to vygeneruje validni SQL.
v cistem SQL je tohle oser s lepenim dotazu z retezcu, proto se casteji volaji dotazy v cyklu
ocenil bych, kdyby se do diskuze o ORM zapojovali lidi, kteri s ORM pracuji. Vy tu jen papouskujete myty, ktere znate z doslechu.
-
Pokud chcete tabulky se strankovanim + razenim, tak je MUSITE vyselektovat jednim dotazem, ma to tak vetsina webu, ORM se k tomu pouziva bezne.
Selektovani dat v cyklu je antipattern, s ORM nema nic spolecneho.
-
Pokud chcete tabulky se strankovanim + razenim, tak je MUSITE vyselektovat jednim dotazem, ma to tak vetsina webu, ORM se k tomu pouziva bezne.
Selektovani dat v cyklu je antipattern, s ORM nema nic spolecneho.
Tak samozřejmě, takovou trivku jsem na mysli neměl.
-
Já bych se v tomhle případě Mirka zastal.
(https://www.meme-arsenal.com/memes/4dc5c2c0a73fb9ec553c3f93703a02ad.jpg)
Případně lepší (asi nepůjde vložit)
(https://scontent-vie1-1.xx.fbcdn.net/v/t1.6435-9/149552863_3697659510282900_525781913078037685_n.jpg?_nc_cat=110&ccb=1-3&_nc_sid=730e14&_nc_ohc=E-YqVure9oEAX94MNIQ&_nc_ht=scontent-vie1-1.xx&oh=8ca2ba6c39d4aed5a1ef900bda06f1a7&oe=60DDB36F)
...prostě třeba od takových lidí není možné žádnou velkou hloubku ani důkladnost čekat, zaměstnavatel je nutí dělat úplně všechno...
-
Já bych se v tomhle případě Mirka zastal.
Silhavy neni zadny developer, ani backend ani frontend, vy podle vseho take ne.
-
Tak samozřejmě, takovou trivku jsem na mysli neměl.
a co jste mel na mysli? Kdy se podle vas pouziva ORM pro dotazovani v cyklu?
-
Silhavy neni zadny developer, ani backend ani frontend, vy podle vseho take ne.
Já jsem letadlo :-D páne Hackere ;D 8)
-
Tak samozřejmě, takovou trivku jsem na mysli neměl.
a co jste mel na mysli? Kdy se podle vas pouziva ORM pro dotazovani v cyklu?
exporty, generovani analytickych reportu, biling, fraud detection, ...
-
fraud detection, ...
Můžete rozvést vzorovou implementaci? Pokud bych provedl úspěšný SQL injection, tak mi to nepomůže ne? Já v jedné aplikaci transakce hashuji.
Doplněni: Je skvělé, že tu diskutujete. Ne každý někdy viděl implementovaný fraud detection.
-
fraud detection, ...
Můžete rozvést vzorovou implementaci? Pokud bych provedl úspěšný SQL injection, tak mi to nepomůže ne? Já v jedné aplikaci transakce hashuji.
Tady nerozumím otázce - fraud detection primárně neslouží k detekci SQL injection, i když by to asi mohlo detekovat úspěšný průnik (analýzou auditu). Co myslíte pod "hashováním transakcí" ? Ochranou proti SQL injection je důsledná a správná sanitizace všech parametrů dotazů, případně striktní používání prepared statements nebo parametrized statements. Pak je další kapitola minimalizace impaktu kompromitace účtu - ať zaheshováním citlivých údajů nebo používáním standardních security fíčur databáze - víc uživatelů, přístupová práva, maskování hodnot, ..
-
Doplněni: Je skvělé, že tu diskutujete. Ne každý někdy viděl implementovaný fraud detection.
Takových systémů bude mraky - co jsem se bavil s lidma, kteří detekce anomálií používají Postgres, tak existuje detekce komunikace na síti, detekce pohybu osob po budovách, automatická analýza databázového auditu, .. dokonce v novějším ANSI/SQL je pro to funkce - analýza vzorů změn
https://fosdem.org/2021/schedule/event/postgresql_postgres_and_the_artificial_intelligence_landscape/
-
300 dotazů na jeden refresh stránky :o :o :o
WTF (?)
Bavíme se o jedné jediné běžné webové stránce? :o
Tři sta dotazů :o
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?
Běžné je klidně 1500. Pavel byl ještě opatrný.
-
Rozhovor se tu krapet zvrhl v několik falešných premis:
- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.
- To, že potřebuju specializovaný dotaz, kde dělám hroznou magii neznamená, že nesmím použít ORM. Tím spíše, když specializovaný dotaz je sotva procento všeho.
- To, že někdo zprasil ORM tak, že z toho Pavel málem omdlel neznamená, že napsat si "lehkou obálku" by dopadlo lépe.
- Napsat si "lehkou obálku" nebude automaticky výhodnější.
- Narvat všechno do DB je volená strategie, která nejde přímo proti ORM.
-
Rozhovor se tu krapet zvrhl v několik falešných premis:
- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.
- To, že potřebuju specializovaný dotaz, kde dělám hroznou magii neznamená, že nesmím použít ORM. Tím spíše, když specializovaný dotaz je sotva procento všeho.
- To, že někdo zprasil ORM tak, že z toho Pavel málem omdlel neznamená, že napsat si "lehkou obálku" by dopadlo lépe.
- Napsat si "lehkou obálku" nebude automaticky výhodnější.
- Narvat všechno do DB je volená strategie, která nejde přímo proti ORM.
Takže žádná z uvedených falešných premis neplatí? Jsi tedy pro "lehké obálky", které budou automaticky výhodnější?
-
Jak to tady čtu, tak se mi zdá, že pojem ORM je přetížený. Může mít podle různých diskutujících dva dosti odlišné významy:
1) "Full ORM" - něco, co umožní existující "programming language" objekty uložit transparentně do databáze. V tomto případě je bussines logika v aplikaci, DB je storage.
2) "query builder" - něco, co umí "databázové objekty" nějakým způsobem "hezky" zpřístupnit v aplikaci. Bussines logika je tady v DB
To jsou dva naprosto odlišné přístupy, ač základ "ORM" je u nich stejný: bijekce mezi "objekty v DB" a v aplikační vrstvě. A každý má své problémy.
U 1 jsou vešekré problémy s tím, že pokud nestačí výkon ORM a dělají se např. dávkové updaty, obchází se bussines logika. 2 je použitelné, ale zas logikou v DB spousta lidí neumí pracovat a tedy je to finančně drahé (alespoň pro některé typy projektů).
Další věc je, že málokdy je to řešení čistě 1 nebo čistě 2. To právě vede k tomu směšování význam těch dvou povahou dosti odlišných ORM. A je pravda, že to částečně řeší problémy zmíněné výše, ale vzniklá schizofrenie je snad ještě větší problém: v jednu chvíli člověk tvrdě narazí na to, že nejde udělat tlustá čára mezi logikou v APP a v DB - a z toho plyne nemožnost něco dělat efektivně, vyšší riziko chyb atd. atd.
-
Jak to tady čtu, tak se mi zdá, že pojem ORM je přetížený. Může mít podle různých diskutujících dva dosti odlišné významy:
1) "Full ORM" - něco, co umožní existující "programming language" objekty uložit transparentně do databáze. V tomto případě je bussines logika v aplikaci, DB je storage.
2) "query builder" - něco, co umí "databázové objekty" nějakým způsobem "hezky" zpřístupnit v aplikaci. Bussines logika je tady v DB
Mě to dělení přijde umělé. U 1 mohu mít taky dost logiky v DB a používat custom SQL dotazy, případ 2 zase může přebírat kompetence z full-orm. Je tam mezi oběma přístupy plynulý přechod (doby kdy byl jen iBatis a Hibernate jsou pryč).
Spíš mi přijde podstatné zda a jak orm řeší persistenci objektového grafu, tj. uložení všech vnořených entit a dále jak řeší persistentní session (attached vs. detached instance), jak flexibilně umí mapovat objekty, zda má nějaké event api, zda a jak lze entity serializovat mimo databázi, zda mohu namapovat entity, ke kterým nemám zdrojový kód apod. To rozhoduje mnohem víc a použitelnosti, rychlosti vývoje a v důsledcích tedy i o výkonu aplikace.
-
moderni ORM je v querybuilder + definice entit obsahujici informace navic oproti samotne definici tabulek v databazi, ktere vyuziva jednak querybuilder k snadnejsimu generovani dotazu bez zadavani explicitnich detailu. Ale muze je vyuzivat i aplikace pro generovani API, formularu atd.
samotny nazev ORM je alespon v dynamickych jazycich trochu zavadejici, tam je mapovani sql entit na obekty trivialita, kterou muze delat jakakoliv db knihovna.
tvrzeni, ze kdo zna SQL nepotrebuje ORM, je stejne hloupe jako tvrzeni, ze kdo zna assembler nepotrebuje vyssi jazyky.
-
- ORM není o tom, nedostat se nebo schovat SQL.
presne, ORM je o efektivni praci s SQL.
-
V 1 mohu mít taky dost logiky v DB a používat custom SQL dotazy,
To jde a zpravidla se to tak dělá. Ale to má své velké problémy. Co když chci udělat jako "custom SQL dotaz" update dané vlastnosti, která ovšem je "ztrigerovaná" nikoli v DB, ale v APP? Nebo co když chci jen udělat custom select podle dané vlastnosti, ale ta je ve skutečnosti na APP vrstvě nějak předefinována?
V případě malého projektu, kde se lidé "osobně domluví co bude kde", tak to jde nějak udržet. Ale s růstem projektu se je podle mne třeba dohodnout, na které úrovni funguje bussines logika - jestli na APP nebo na DB vrstvě, a respektovat to. Lezení pod tuto dohodnutou úroveň je pak "ugly hack". Tzn. jakmile mám nějakou část logiky v APP, tak bych neměl jen tak "mírnix týrnix" lézt bokem do databáze.
Ne, že by takovou app (kde se bokem leze) nešlo "ukočírovat" - jde to, a asi nemálo lidí to tak dělá. Ale s příbývající komplexitou se pak člověk nevyhne dublování funkcionality na APP a na DB vrstvě - a i s tím spojenými chybami, když se ty implementace "rozjedou" (anebo prostě nejsou napsány 100% shodně).
-
V 1 mohu mít taky dost logiky v DB a používat custom SQL dotazy,
To jde a zpravidla se to tak dělá. Ale to má své velké problémy. Co když chci udělat jako "custom SQL dotaz" update dané vlastnosti, která ovšem je "ztrigerovaná" nikoli v DB, ale v APP? Nebo co když chci jen udělat custom select podle dané vlastnosti, ale ta je ve skutečnosti na APP vrstvě nějak předefinována?
V případě malého projektu, kde se lidé "osobně domluví co bude kde", tak to jde nějak udržet. Ale s růstem projektu se je podle mne třeba dohodnout, na které úrovni funguje bussines logika - jestli na APP nebo na DB vrstvě, a respektovat to. Lezení pod tuto dohodnutou úroveň je pak "ugly hack". Tzn. jakmile mám nějakou část logiky v APP, tak bych neměl jen tak "mírnix týrnix" lézt bokem do databáze.
Ne, že by takovou app (kde se bokem leze) nešlo "ukočírovat" - jde to, a asi nemálo lidí to tak dělá. Ale s příbývající komplexitou se pak člověk nevyhne dublování funkcionality na APP a na DB vrstvě - a i s tím spojenými chybami, když se ty implementace "rozjedou" (anebo prostě nejsou napsány 100% shodně).
uvedte priklad updatu, ktery nejde delat pomoci ORM.
-
A.P.Hacker:Asi si nerozumíme. Samozřejmě, pokud uděláš ORM turingovsky úplný, tak s ním vyjádříš jakékoli SQL. Ale - omlouvám se, že se opakuju - kde máš bussines logiku?
- Pokud v databázi, tak to není ORM. ORM je object relation mapping. Pokud máš bussines logiku v DB, tak máš objekty v databázi. To, na co je mapuješ vlastně nejsou "objekty", nemají na APP rovině logiku a objekt tvoří data+logika. V takovém případě podle mne opravdu nejde o ORM, ale o QueryBuilder. Který je samozřejmě užitečný a potřeba.
- Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.
Situaci, kdy se používá mix přístupů výše jsem už komentoval.
-
- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.
To je protimluv. SQL přímo realizuje relační algebru.
Zkuste se zamyslet nad zkratkou ORM, obsahuje přímočarou odpověď.
-
A.P.Hacker:Asi si nerozumíme. Samozřejmě, pokud uděláš ORM turingovsky úplný, tak s ním vyjádříš jakékoli SQL. Ale - omlouvám se, že se opakuju - kde máš bussines logiku?
- Pokud v databázi, tak to není ORM. ORM je object relation mapping. Pokud máš bussines logiku v DB, tak máš objekty v databázi. To, na co je mapuješ vlastně nejsou "objekty", nemají na APP rovině logiku a objekt tvoří data+logika. V takovém případě podle mne opravdu nejde o ORM, ale o QueryBuilder. Který je samozřejmě užitečný a potřeba.
vzdy bude cast logiky v aplikaci a jina cast v databazi, nikdy nebude vse v databazi, neznamena to, ze se neco duplikuje.
- Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.
Situaci, kdy se používá mix přístupů výše jsem už komentoval.
jeste jednou, ORM je (mimo jine) lepsi QueryBuilder, ktery vyuziva informace z definice modelu
- Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.
Situaci, kdy se používá mix přístupů výše jsem už komentoval.
proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.
[/list]
-
To, na co je mapuješ vlastně nejsou "objekty", nemají na APP rovině logiku a objekt tvoří data+logika. V takovém případě podle mne opravdu nejde o ORM, ale o QueryBuilder. Který je samozřejmě užitečný a potřeba.[/li][/list]
na APP rovine (v definici tridy, kdyz chcete) je definovana logika (ruzna integritni omezeni, trigery a podobne), ktera je nasledne synchonizovana s databazi. Potom objekty pouzivate stejne jako by logika byla v aplikaci. Jina cast logiky je ciste v aplkikaci.
V praxi neexistuji cista oddeleni na vrstvy a skatulky, to jen v korporatni mluve
-
- Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.
Situaci, kdy se používá mix přístupů výše jsem už komentoval.
proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.
Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.
-
Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.
Pokud ta "aplikační logika" bude vycházet přímo z vlastností objektů (když má auto výkon > 100kW a jen dvoje dveře, nemůže být obarvené na zeleno, ostatní můžou), které jsou mapovány do databáze, tak by to ORM zvládnout mohl. Ale už i ten zápis se bude asi přibližovat relačnímu SQL jazyku.
Ale já jsem stará konzerva, nejsem příznivec ORM, takže to zkoumat nebudu. :)
-
Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.
Pokud ta "aplikační logika" bude vycházet přímo z vlastností objektů (když má auto výkon > 100kW a jen dvoje dveře, nemůže být obarvené na zeleno, ostatní můžou), které jsou mapovány do databáze, tak by to ORM zvládnout mohl. Ale už i ten zápis se bude asi přibližovat relačnímu SQL jazyku.
Přesně to mám na mysli. Definice takových mapovaných objektů, nebo zápis požadavku bude sice jinou mluvou, ale nevyhne se složitosti zápisu v SQL.
Ale můžeme to rozvést dál: pokud to bude vycházet z databáze, ale jaksi "na volno" - nebude to vyjádřené vazbami, pohledy, constraints, triggery, opatřené žádoucími indexy, ..., ale třeba jen definované zápisem nějaké konfigurace => pak to taky v obecném případě nedosáhne výkonu, který RDBMS může poskytnout, a ani to nebude mít potenciál optimalizovatelnosti to ke stejnému výkonu. Pokud by to bylo v DB definované přesně, a na pevno, pak ORM neusnadní práci při tvoření struktury a práci s daty, pouze poskytne vhodnější interface bližší k jazyku aplikace.
-
- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.
To je protimluv. SQL přímo realizuje relační algebru.
Zkuste se zamyslet nad zkratkou ORM, obsahuje přímočarou odpověď.
Není to protimluv.
První věc, kterou šikovné ORM schová, tak je joinování. Každopádně pointa je jinde.
-
vzdy bude cast logiky v aplikaci a jina cast v databazi, nikdy nebude vse v databazi, neznamena to, ze se neco duplikuje.
Neduplikuje se do té doby, než zjistíš, že v nějakých SQL dotazech potřebuješ použít tu logiku, jejíž část je v APP. Protože ji tam prostě nemáš. V takovém případě prostě buďto tu logiku obcházíš (což je budoucí průšvih), nebo ji duplikuješ (což je opět budoucí průšvih).
Třetí - správná cesta - je přesun té logiky do DB, ale to může být netriviální refaktor a klient Tě umlátí, že chceš za z jeho pohledu primitivní úpravu aplikace nehoráznou sumu. Takže to tak neuděláš a volíš jedno z řešení výše... To není teorie, to je praxe...
Nejhorší na tom ale je, že ve větším projektu nevíš jaká logika je v APP a jaká v DB. Takže když chceš pracovat na DB vrstvě, tak prostě nevíš, jestli náhodou neobcházíš nějakou logiku na APP vrstvě. V lepším případě to jsi schopen ověřit kontrolou zdrojových kódů APP popř. projitím dokumentace a stojí Tě to jen nemálo času. V horším případě je dokumentace nekompletní (kdo máte v projektech dokumentaci 100%?) anebo danej kus kódu s danou logikou nenajdeš/špatně pochopíš a vyrobils problém.
proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.
Jak píšou kolegové, pokud máš logiku v APP, tak to prostě není možné, protože na APP vrstvě je aplikační logika postavená nad ORM a tedy ji ORM nevidí a neumí použít.
Leda, že bys psal APP logiku ve vrstvě pod ORM jako nějakou konfiguraci ORM - jenže v čem? Nějaký "user-friendly" deklarativní způsob nebude ani vzdáleně turingovsky úplný, a tedy v něm většinu APP bussines logiky prostě nenapíšeš. A jakýkoli složitější jazyk? Pak je otázka, proč vymešlet kolo: pokud to bude komplexní, tak to nebude o tolik jednodušší než SQL, aby to ospravedlnilo veškeré nevýhody z toho plynoucí (další jazyk v projektu, problémy vzniklé mapováním toho jazyka na SQL atd... atd....).
Jako teoreticky si dokážu představit ORM, které by bylo např. v Pythonu, a kde by definice objektů byla napsaná tak, že by se z ní automaticky vytvářely PL/Python stored procedury, ale takový ORM imho neexistuje a napsat něco takovýho by byla hodně netriviální věc.
Navíc, takový přístup by vlastně nebyl nic jiného, než dublování funkcionality, o kterém píšu více, jen díky "strojovému generování" s menším rizikem desynchronizace implementací.
-
proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.
Jak píšou kolegové, pokud máš logiku v APP, tak to prostě není možné, protože na APP vrstvě je aplikační logika postavená nad ORM a tedy ji ORM nevidí a neumí použít.
Já bych pro dávkové příkazy ORM neobcházel. To ORM tam jednou mám, a tak to píšu přes něj. Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".
-
Já bych pro dávkové příkazy ORM neobcházel. To ORM tam jednou mám, a tak to píšu přes něj. Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".
To moc dobře nefunguje. Databáze je zatížená spoustou neefektivních dotazů, a ve chvíli, kdy potřebujete jeden ladit "na krev", tak se nikam nehnete. Zjistíte, že i ten jeden, jinak třeba dobře napsaný dotaz prostě čeká kvůli ostatním neefektivním transakcím a lockům z ORM.
Celkově je hloupé mít dobrou technologii, zmrzačit ji, a pak se snažit zrmzačený pahýl znovu rozhýbat.
Psal jsem to už výše, ORM má svoje místo, ale problém nastává ve chvíli, kdy někoho napadne, že by si mohl pomoct obejitím. Získá tím málo, ale hodně zkomplikuje situaci. Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB.
-
Já bych pro dávkové příkazy ORM neobcházel. To ORM tam jednou mám, a tak to píšu přes něj. Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".
To moc dobře nefunguje. Databáze je zatížená spoustou neefektivních dotazů, a ve chvíli, kdy potřebujete jeden ladit "na krev", tak se nikam nehnete. Zjistíte, že i ten jeden, jinak třeba dobře napsaný dotaz prostě čeká kvůli ostatním neefektivním transakcím a lockům z ORM.
Celkově je hloupé mít dobrou technologii, zmrzačit ji, a pak se snažit zrmzačený pahýl znovu rozhýbat.
Psal jsem to už výše, ORM má svoje místo, ale problém nastává ve chvíli, kdy někoho napadne, že by si mohl pomoct obejitím. Získá tím málo, ale hodně zkomplikuje situaci. Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB.
Nerozumím. Odporuješ si. Já tvrdím, že bych dávkové příkazy honil přes ORM, a ty namítneš, že "Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB."?
-
Nerozumím. Odporuješ si. Já tvrdím, že bych dávkové příkazy honil přes ORM, a ty namítneš, že "Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB."?
Reagoval jsem na druhou větu: >>Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".<<
-
Nerozumím. Odporuješ si. Já tvrdím, že bych dávkové příkazy honil přes ORM, a ty namítneš, že "Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB."?
Reagoval jsem na druhou větu: >>Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".<<
OK.
V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich (ORM) obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.
Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.
-
V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.
Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.
Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.
-
V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.
Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.
Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.
Nebude zázračný ale bude více než dostatečný. Stejně, jako ručně optimalizovaný kód v asembleru bude vždy lepší jak to co vymyslí kompilátor. Je to stejná písnička (btw, to jsem už taky psal, také se opakuji).
-
V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.
Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.
Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.
Nebude zázračný ale bude více než dostatečný. Stejně, jako ručně optimalizovaný kód v asembleru bude vždy lepší jak to co vymyslí kompilátor. Je to stejná písnička (btw, to jsem už taky psal, také se opakuji).
Ok, to už je věc názoru. Potkal jsem už řádku projektů, kde po zvětšení datové nálože a zvýšení přístupů, vylétly požadavky na výkon tak moc, že už se to nijak škálovat nedalo. Pomohl jedině přepis a aspoň důležité části šly mimo ORM (čímž vznikl paskvil, ale aspoň se vyřešil problém).
Jasné, pro malý shopík na webu, kam přijde 50 objednávek za den, bude ORM stačit na věky věkův.
-
V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.
Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.
Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.
Nebude zázračný ale bude více než dostatečný. Stejně, jako ručně optimalizovaný kód v asembleru bude vždy lepší jak to co vymyslí kompilátor. Je to stejná písnička (btw, to jsem už taky psal, také se opakuji).
Ok, to už je věc názoru. Potkal jsem už řádku projektů, kde po zvětšení datové nálože a zvýšení přístupů, vylétly požadavky na výkon tak moc, že už se to nijak škálovat nedalo. Pomohl jedině přepis a aspoň důležité části šly mimo ORM (čímž vznikl paskvil, ale aspoň se vyřešil problém).
Jasné, pro malý shopík na webu, kam přijde 50 objednávek za den, bude ORM stačit na věky věkův.
Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.
Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.
-
Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.
Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.
Ta principiální potíž je v tom, že RDBMS jsou výkonné právě a tehdy, kdy jsou správně nastavené tabule, constrainty, klíče, vzdálené klíče, indexy, ..., a především, když je možné maximum rozhodovacích mechanismů přenést do DB. Interné optimalizátor dotazu se pak těchto informací může chytit a snažit se je využít k vymyšlení nejlepšího postupu pro získání / zápis dat.
Tedy např. když vím, že chci přebarvit všechna auta na červenou, vyjma zelených aut vyrobených v roce 2009, pak potřebuju, aby databáze měla takovou strukturu, aby se k diskriminantům dostala rychle. Musí umět rychle vyhodnotit, jestli nejdřív vybere auta vyrobená <> 2009 a pak s barvou <> zelenou, nebo jestli bude rychlejší opačný postup. Nebo jestli bude nejrychlejší projít všechna auta po sobě, a těch pár, které jsou zelené a vyrobené v 2009 přeskočit (tj. indexy, statistiky, složené indexy, ...).
Můžete mít také auta, u kterých nevíte rok výroby nebo nevíte barvu. ORM za Vás nerozhodne, jestli může (má) použít inner nebo outer join. V prostém případě to nebude mít na výkon velký vliv, ale pokud půjde o složený dotaz se subselecty, bude inner/outer hrát roli v tom, co dokáže optimalizátor ze subselectu vyčlenit nad něj, a co ne.
O tom, jak dotaz realizovat, musí přemýšlet i ten, kdo pracuje přímo v SQL, a nezřídka se stává, že váhá. Zejména, když sestavujete view, tak očekáváte, že bude použito v dalším složeném dotazu. Když view navrhnete špatně, tak může dávat při prostém selectu data rychle, ale může být pro optimalizátor už dále neoptimalizovatelné v dalších složených dotazech. Někdy se vyplatí, pokud víte, co se s tím bude dál dít, napsat view složitěji, ale optimalizovatelněji.
Toto všechno neumí vyřešit RDBMS, a programátor v SQL se s tím taky zapotí. Proto tvrdím, že není reálné očekávat, že ORM by i někdy v budoucnu toto uměly.
Dál mě k tomu přesvědčení vede i to, že optimalizace se musí provádět co nejblíž k datům. RDBMS jsou výkonné jen a právě díky tomu. Dovedu si představit ORM, které by nějakou svojí inteligencí přenášelo nadefinované objekty do dobře vytvořených SQL definic. Jenže to to ORM nebude schopné vymyslet samo, musí to vyčíst z definic poskytnutých programátorem. Tyto definice v rámci ORM by tedy musely být na tolik přesné, aby je šlo 1:1 přenést do DB. Pokud by ty definice měly být na tolik přesné - pak už ORM nebude šetřit práci, pouze bude jinou mluvou definovat totéž.
Mám takový pocit, že hledáte potvrzení, že nějaká ORM mechanika dokáže vymyslet to, co nikdo za desítky let nevymyslel ani v rámci RDBMS.
-
Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.
Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.
Ta principiální potíž je v tom, že RDBMS jsou výkonné právě a tehdy, kdy jsou správně nastavené tabule, constrainty, klíče, vzdálené klíče, indexy, ..., a především, když je možné maximum rozhodovacích mechanismů přenést do DB. Interné optimalizátor dotazu se pak těchto informací může chytit a snažit se je využít k vymyšlení nejlepšího postupu pro získání / zápis dat.
Tedy např. když vím, že chci přebarvit všechna auta na červenou, vyjma zelených aut vyrobených v roce 2009, pak potřebuju, aby databáze měla takovou strukturu, aby se k diskriminantům dostala rychle. Musí umět rychle vyhodnotit, jestli nejdřív vybere auta vyrobená <> 2009 a pak s barvou <> zelenou, nebo jestli bude rychlejší opačný postup. Nebo jestli bude nejrychlejší projít všechna auta po sobě, a těch pár, které jsou zelené a vyrobené v 2009 přeskočit (tj. indexy, statistiky, složené indexy, ...).
Můžete mít také auta, u kterých nevíte rok výroby nebo nevíte barvu. ORM za Vás nerozhodne, jestli může (má) použít inner nebo outer join. V prostém případě to nebude mít na výkon velký vliv, ale pokud půjde o složený dotaz se subselecty, bude inner/outer hrát roli v tom, co dokáže optimalizátor ze subselectu vyčlenit nad něj, a co ne.
O tom, jak dotaz realizovat, musí přemýšlet i ten, kdo pracuje přímo v SQL, a nezřídka se stává, že váhá. Zejména, když sestavujete view, tak očekáváte, že bude použito v dalším složeném dotazu. Když view navrhnete špatně, tak může dávat při prostém selectu data rychle, ale může být pro optimalizátor už dále neoptimalizovatelné v dalších složených dotazech. Někdy se vyplatí, pokud víte, co se s tím bude dál dít, napsat view složitěji, ale optimalizovatelněji.
Toto všechno neumí vyřešit RDBMS, a programátor v SQL se s tím taky zapotí. Proto tvrdím, že není reálné očekávat, že ORM by i někdy v budoucnu toto uměly.
Dál mě k tomu přesvědčení vede i to, že optimalizace se musí provádět co nejblíž k datům. RDBMS jsou výkonné jen a právě díky tomu. Dovedu si představit ORM, které by nějakou svojí inteligencí přenášelo nadefinované objekty do dobře vytvořených SQL definic. Jenže to to ORM nebude schopné vymyslet samo, musí to vyčíst z definic poskytnutých programátorem. Tyto definice v rámci ORM by tedy musely být na tolik přesné, aby je šlo 1:1 přenést do DB. Pokud by ty definice měly být na tolik přesné - pak už ORM nebude šetřit práci, pouze bude jinou mluvou definovat totéž.
Mám takový pocit, že hledáte potvrzení, že nějaká ORM mechanika dokáže vymyslet to, co nikdo za desítky let nevymyslel ani v rámci RDBMS.
Tomu co popisuješ dobře rozumím. Čemu nerozumím je, čím podkládáš svá tvrzení, že by to nemělo jít? To v tom textu schází.
Uvedu příklad: V MySQL je taková vlastnost, že v praxi moc nejde použít view, protože implementace v MySQL jej nedokáže optimalizovat a v mnoha případech to degraduje na fullscan. Teď neřešme nakolik je můj popis problému přesný.
Vysvětli mi prosím, máš-li chuť, proč by tuto informaci o tomto zrádném chování nemohlo vědět ORM (ve svém engine pro MySQL), a zohledňovat to při vytváření dotazů? Proč by to musel, principielně umět vývojář. Proč by tato znalost této vlastnosti bylo mnohem náročnější "naučit" ORM, než to učit vývojáře?
A naopak, PostgreSQL umí velice dobře view, a rules, a Sqlite a MySQL od verze (už si nepamatuju) umí window. Etc, etc.,
-
Tomu co popisuješ dobře rozumím. Čemu nerozumím je, čím podkládáš svá tvrzení, že by to nemělo jít? To v tom textu schází.
Uvedu příklad: V MySQL je taková vlastnost, že v praxi moc nejde použít view, protože implementace v MySQL jej nedokáže optimalizovat a v mnoha případech to degraduje na fullscan. Teď neřešme nakolik je můj popis problému přesný.
Vysvětli mi prosím, máš-li chuť, proč by tuto informaci o tomto zrádném chování nemohlo vědět ORM (ve svém engine pro MySQL), a zohledňovat to při vytváření dotazů? Proč by to musel, principielně umět vývojář. Proč by tato znalost této vlastnosti bylo mnohem náročnější "naučit" ORM, než to učit vývojáře?
Tak předně, úplně bych zapomněl na MySQL. To je parodie na RDBMS, která má pár drobných výhod a spoustu velkých nevýhod.
To, co popisujete, není vlastnost, ale chyba nebo nedodělek. Není dobrý nápad chybu nebo nedodělek napravovat o vrstvu výš. Jako nějaká obezlička, budiž, ale řešení to není.
Co je překážkou? To už jsem psal. Že struktura dat, tabulí, indexů a dotazů neexistuje jen jediná možná. Existuje mnoho způsobů, jak se dobrat téhož, a liší se složitostí zápisu dotazu (v případě automaticky generováného dotazu nás to netrápí), liší se náročností pro získání dat a liší se náročností pro zápis dat. ORM nedokáže rozhodnout, kterou strategii preferujete. Neví, jestli potřebujete rychle zapisovat a pomalu číst, nebo pomalu zapisovat a rychle číst. Nebo jestli něco mezi. Netuší, jestli bude výhodnější parciální index, ale rychlejší ve většině případů, nebo plný index, rychlý, ale o něco pomalejší v průměrném případě. Neví, jestli Vám jde o celkovou rychlost, nebo o zminimalizování locků...
To vše je na člověku - ne protože by to technologie nechtěla umět, ale protože člověk musí zvolit strategii pro daný projekt. Každá má svá pro a proti.
Nevím, jestli jste někdy tyto věci řešil - pokud se soustředíte na MySQL, musí to být dost vzdálené si to představit, protože tam opravdu často existuje jen jedna jediná "správná" cesta a všechny ostatní jsou úplně tragické.
-
Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.
Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.
Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev). Zvlášt u extrémně rychlých dotazů (dotazy, které vrací, modifikují pár řádků nad PK), je tato režie hodně vysoká. A v podstatě pak hrdlem je síť a pálíte výkon konverzí dat a realizací komunikace. Můžete si pomoct aplikační cache. Pokud ale máte víc dat, tak se nevejdete do RAM na aplikáči, a a musíte implementovat ACID nad ACIDem, což zase zvyšuje komplexitu nástroje. Implementace distribuované transakční cache je dost komplikovaná záležitost. Zvyšuje se výkon CPU, zvyšují se přenosové rychlosti, IOPS SSD jsou někde úplně jinde, ale na druhou stranu, roste objem dat, klesá trpělivost uživatelů (nikdo nechce čekat na výsledek minuty), a klesají znalosti programátorů (mění se znalosti programátorů - znají ORM, patterny, buildovací prostředí, a virtualizaci), ale neznají základy toho jak fungují databáze (což dřív také nebyla žádná sláva, ale teď to mají k databázím dál). Tudíž si myslím, že posledních 15 let, jsou u větších projektů stejné problémy (i přes brutální nárůst výkonu).
Další problém ORM je odtržení statistik. Sice mohou mít datový model (a mají), ale nemají statistiky, jak data ve skutečnosti vypadají. V ideálním případě by možná tuto znalost nepotřebovali, kdyby existoval ideální optimalizátor dotazů. Už jednoduchá úloha je docela komplikovaná - rozhodnout, jestli si inicializovat cache blokově (napřed si stáhnu potřebná data) nebo iteračně. Pokud budete mít statistiky na aplikáči, tak duplikujete funkcionalitu db, a navíc asi statistiky budete mít jen z cache (nikoliv ze všech dat). Co vím, tak většina ORM statistiky o datech nemá, proto dynamicky nedokáže měnit strategie zpracování dat (nedokáže se přizpůsobit datům). Relační SQL databáze se o to snaží - máte 3 typy JOINů, máte seq scan, index scan - a optimalizátor hledá způsob, jak co nejrychleji přenést data z disku a jak přitom spotřebovat co nejméně paměti.
SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.
-
SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.
Optimalizace na úrovni SQL ale fungují cca na 70 procent, tak jak fungují statistiky a odhady. Statistiky ale nejsou přesné, a tudíž nejsou přesné odhady. Máte korelace v datech, fyzicky data nejsou rovnoměrně uložena v tabulkách. Někdy dochází ke změně charakteru statistik v čase (což statistický model vubec nedokáže zpracovat). Modelovat se dá velice přesně, ale to vám dost pálí výkon - a ten při optimalizaci dotazu nemáte. Takže chca nechca musíte přidávat dodatečnou informaci, tím jak píšete SQL (ať už jsou to hinty, nebo použité konstrukce, nebo sekvence příkazů). Pokud je ale databáze navržená pro ORM, tak programátoři nemají znalosti, chybí jim odvaha do kódu sahat, chybí jim zkušenost, a fakt to hodně dře. U větších aplikací (u malých to není problém), pak musíte řešit jednak výkon SQL, a také výkon ORM (pokud jej používáte).
-
Co je překážkou? To už jsem psal. Že struktura dat, tabulí, indexů a dotazů neexistuje jen jediná možná. Existuje mnoho způsobů, jak se dobrat téhož, a liší se složitostí zápisu dotazu (v případě automaticky generováného dotazu nás to netrápí), liší se náročností pro získání dat a liší se náročností pro zápis dat. ORM nedokáže rozhodnout, kterou strategii preferujete. Neví, jestli potřebujete rychle zapisovat a pomalu číst, nebo pomalu zapisovat a rychle číst. Nebo jestli něco mezi. Netuší, jestli bude výhodnější parciální index, ale rychlejší ve většině případů, nebo plný index, rychlý, ale o něco pomalejší v průměrném případě. Neví, jestli Vám jde o celkovou rychlost, nebo o zminimalizování locků...
To vše je na člověku - ne protože by to technologie nechtěla umět, ale protože člověk musí zvolit strategii pro daný projekt. Každá má svá pro a proti.
Tuto myšlenku jsme už tu o pár stránek dříve probírali, včetně mých námitek na ně. Tudíž jen zopakuji: nesouhlasím. Nevidím důvod, proč by to ORM nemělo umět, proč by to neměl zvládnout lépe jak člověk. Z tvého popisuj tento závěr nevyplývá.
Nevím, jestli jste někdy tyto věci řešil - pokud se soustředíte na MySQL, musí to být dost vzdálené si to představit, protože tam opravdu často existuje jen jedna jediná "správná" cesta a všechny ostatní jsou úplně tragické.
Mám pár zkušeností s různými ORM. Mám nějaké zkušenosti s MySQL, Sqlite, PostgreSQL, MSSQL - stačí? A záleží na tom?
Já tě nevnímám jako autoritu, tudy cesta nevede. Tudíž dokavad neuvedeš důvod, proč by to jít nemělo, tak se nepohneme :-) (Jako důvod si představuji něco, na co ti řeknu: "jó, tak to nevím jak by se dalo řešit". Zatím jsem na všechny tvé nepřekonatelné problémy našel snadné řešení a napsal ti ho.)
Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.
Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.
Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev). Zvlášt u extrémně rychlých dotazů (dotazy, které vrací, modifikují pár řádků nad PK), je tato režie hodně vysoká. A v podstatě pak hrdlem je síť a pálíte výkon konverzí dat a realizací komunikace. Můžete si pomoct aplikační cache. Pokud ale máte víc dat, tak se nevejdete do RAM na aplikáči, a a musíte implementovat ACID nad ACIDem, což zase zvyšuje komplexitu nástroje. Implementace distribuované transakční cache je dost komplikovaná záležitost. Zvyšuje se výkon CPU, zvyšují se přenosové rychlosti, IOPS SSD jsou někde úplně jinde, ale na druhou stranu, roste objem dat, klesá trpělivost uživatelů (nikdo nechce čekat na výsledek minuty), a klesají znalosti programátorů (mění se znalosti programátorů - znají ORM, patterny, buildovací prostředí, a virtualizaci), ale neznají základy toho jak fungují databáze (což dřív také nebyla žádná sláva, ale teď to mají k databázím dál). Tudíž si myslím, že posledních 15 let, jsou u větších projektů stejné problémy (i přes brutální nárůst výkonu).
Další problém ORM je odtržení statistik. Sice mohou mít datový model (a mají), ale nemají statistiky, jak data ve skutečnosti vypadají. V ideálním případě by možná tuto znalost nepotřebovali, kdyby existoval ideální optimalizátor dotazů. Už jednoduchá úloha je docela komplikovaná - rozhodnout, jestli si inicializovat cache blokově (napřed si stáhnu potřebná data) nebo iteračně. Pokud budete mít statistiky na aplikáči, tak duplikujete funkcionalitu db, a navíc asi statistiky budete mít jen z cache (nikoliv ze všech dat). Co vím, tak většina ORM statistiky o datech nemá, proto dynamicky nedokáže měnit strategie zpracování dat (nedokáže se přizpůsobit datům). Relační SQL databáze se o to snaží - máte 3 typy JOINů, máte seq scan, index scan - a optimalizátor hledá způsob, jak co nejrychleji přenést data z disku a jak přitom spotřebovat co nejméně paměti.
SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.
To co popisuješ není principielní problém ORM. To jsou reálné problémy aktuálních implementací.
Pro příklad hned první věta:
Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev).
Tohle prostě není pravda. ORM nemá principielní důvod aby měl problém s výkonem. Je to mapper. Ty to popisuješ, jako kdyby si načetl všechny data z databáze k sobě a pak přes foreach to filtroval. Bez ohledu na to, že to některé případi takhle dělají, není to principielní problém.
Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.
-
Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.
Možná se nesrozumitelně vyjadřuju, beru. Pokusím se tedy shrnout:
Principiální problém je v tom, že ORM je vrstva nad databází. Očekává se od ní trochu něco jiného než od té databáze.
Pokud bychom přijali, že ideální ORM bude 100% efektivní abstrakce nad databází, v podstatě pak už by databáze nebyla potřeba. Do ORM by se doimplementovaly storage operace a bylo by hotovo.
ORM - jakožto pojem - má smysl jen právě proto, že nepřívětivé vlastnosti databáze mapuje do přívětivých objektových operací ve vyšším programovacím jazyce. Toto nelze vyřešit jinak, než kompromisem. Tedy ztráta pramenící z principu, nikoliv z implementace.
Pavel trefně zmínil absenci statistik (které samy o sobě nedávají 100% odraz skutečnosti). Taky to, že co má databáze při ruce s minimální režií, ORM může získat jen za cenu poměrně vysoké režie (síťová, a další mezivrstvy). Tedy další ztráta pramenící z principu a ne z implementace.
A pak je tu ten třetí důvod, o kterém můžeme diskutovat, jestli je principiální, nebo implementační. To je volba strategie programátorem. Já ji považuji za principiální. U složitých úloh by se jistě dalo uvažovat o tom, že budoucí optimalizátory budou rychlejší a efektivnější. Jenže pořád tu zůstává velká řada triviálních úloh, u kterých může programátor strategii přímo určit a lze ji považovat za optimální. Tedy, můžeme diskutovat o tom, že by v budoucnu mohlo ORM (kdyby mělo statistiky a mohlo vytvářet hinty), mohlo být efektivnější ve složitých úlohách, než ploché SQL, protože ORM má o struktuře dat trochu jiné, a v určitém ohledu lepší informace. Stejný mechanismus by však zdržoval u triviálních úloh, u kterých by programátor stejně dál preferoval sám určit a vysvětlit postup vykonání. Tedy, ručnímu zásahu by se nedalo vyhnout, pokud bychom hledali výkon.
-
Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.
Možná se nesrozumitelně vyjadřuju, beru. Pokusím se tedy shrnout:
Principiální problém je v tom, že ORM je vrstva nad databází. Očekává se od ní trochu něco jiného než od té databáze.
Pokud bychom přijali, že ideální ORM bude 100% efektivní abstrakce nad databází, v podstatě pak už by databáze nebyla potřeba. Do ORM by se doimplementovaly storage operace a bylo by hotovo.
To je zajímavá úvaha, ale nevidím v ní potenciál. Já nemám problém s existencí db. Mě relační databáze maximálně vyhovují. Já chci na nich stavět. Podle mě to, že ORM je vrstva nad databází je cajk - jasně, nějakým mapováním z ORM do SQL se ztratí nějaká ta setinka (sic!), ale furt lepší, než reimplementovat ty mraky práce odvedených nad databázemi. Nehledě k tomu, že relační algebra je ideální (technologickej i mentální) základ.
Kdepak. Toto nechme být, tak je to správně.
ORM - jakožto pojem - má smysl jen právě proto, že nepřívětivé vlastnosti databáze mapuje do přívětivých objektových operací ve vyšším programovacím jazyce.
Přesně tak.
Toto nelze vyřešit jinak, než kompromisem. Tedy ztráta pramenící z principu, nikoliv z implementace.
Tuto příčinnost zde nepozoruji.
Pavel trefně zmínil absenci statistik (které samy o sobě nedávají 100% odraz skutečnosti). Taky to, že co má databáze při ruce s minimální režií, ORM může získat jen za cenu poměrně vysoké režie (síťová, a další mezivrstvy). Tedy další ztráta pramenící z principu a ne z implementace.
Ve skutečnosti to není ani pravda, ani směrodatné.
Pokud mají databáze statistiky, tak ať je mají. Já jim je přece nechci brát.
ORM tý databáze do ničeho nekecá. Jen ať dělá co nejlepšího umí.
Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.
Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?
A pak je tu ten třetí důvod, o kterém můžeme diskutovat, jestli je principiální, nebo implementační. To je volba strategie programátorem. Já ji považuji za principiální. U složitých úloh by se jistě dalo uvažovat o tom, že budoucí optimalizátory budou rychlejší a efektivnější. Jenže pořád tu zůstává velká řada triviálních úloh, u kterých může programátor strategii přímo určit a lze ji považovat za optimální. Tedy, můžeme diskutovat o tom, že by v budoucnu mohlo ORM (kdyby mělo statistiky a mohlo vytvářet hinty), mohlo být efektivnější ve složitých úlohách, než ploché SQL, protože ORM má o struktuře dat trochu jiné, a v určitém ohledu lepší informace. Stejný mechanismus by však zdržoval u triviálních úloh, u kterých by programátor stejně dál preferoval sám určit a vysvětlit postup vykonání. Tedy, ručnímu zásahu by se nedalo vyhnout, pokud bychom hledali výkon.
Výborně. Toto mi dává smysl.
Podle mého názoru, ORM je k tomu, abychom pracovali s nějakými daty nějakým jiným, snad lepším, způsobem. Tak, jak jsi to pěkně popsal o pár odstavců výše. A hlavně aby usnadnilo ruční práci co se mapování týče. Já vůbec nemám problém s tím, aby vývojář tomu ORM řekl, že v tomto a v tomto případě má zvolit jinou strategii. Ve skutečnosti si myslím, že schopnost ORM ukázat, jaký SQL nakonec do db posílá považuju za zcela nutnou funkci. Stejně jako možnost do toho ORMku kecat.
Zároveň si myslím, že kecat mu do toho bude muset jen v několika málo případech.
Možná by se to dalo popsat tak, že v kanceláři si v nějakém budoucím fantastickém ORM naklikají najaký datový model (samozřejmě blbě), ORM z toho syncne změny do databáze a vesele ukládá. Firma funguje, následně narůstají data, databáze se zadejchává, zavolají si Odborníka. Ten zkontroluje datovej model, upraví. Pak zkontroluje statistiky dotazů, a zhodnotí, že na tomto a tomto místě ORMko zvolilo nevhodnou strategii, a změní to.
Nevidím zde prostor pro optimalizaci v podobě constraintů v databázi, protože buď je ORM blbé, a programátor to tam teda doplní ručně a ORM mu nebrání; nebo je ORM schopné, a ví, že ten contsraint může vložit do databáze a udělá to.
-
Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?
Ty, které může lépe získat stroj: tzn. statistiky atd...., ORM získat za rozumný čas nemůže, protože prostě na ně "nevidí". Nemá ty data, ty má DB. Proto je tato otázka chybně položená. Není problém v "STROJ versus VÝVOJÁŘ", problém je v tom, jaké možnosti má stroj na úrovni ORM vrstvy - a že kdybys chtěl ty problémy překonat, tak bys musel do té ORM vrstvy nutně zabudovat i celou databázi.
No a pak jsou informace, které prostě stroj (přinejmenším v dnešním stavu AI) získat prostě nemůže. To, co si od takového ORM představuješ je defakto schopnost programovat, a ta jestli je principiálně vůbec možná (asi jo), tak je úplně někde jinde, než co dneska umíme.
Jak píše Pavel: i SQL databáze, která řeší jednoduché a matematicky snadno popsatelné problémy relační algebry, řeší u každého přístupu jen pár vhodných strategií - a i tam občas selhává. A ty bys chtěl vlastně po ORM něco, co by umělo ne volit jednu strategii z pár "napevno zadrátovaných", ale které by umělo algoritmizaci. Jasně - teroreticky to asi možný je. Ale až to budeme umět, tak budeme umět konstruovat androidy - a programátoři přijdou o práci.... :-)
-
@BoneFlute
Podle mě v té Vaší úvaze zanedbáváte právě to, co je skutečnou překážkou.
ORM, na to, aby mohlo dělat práci blízkou optimu, musí databázi znát. Dobře, strukturu zná, protože si ji spravuje. Co nezná, jsou ty statistiky (nikoliv dotazů, ale tabulek - jejich dat a rozložení). ORM netuší, jestli v jedné tabuli je 100 záznamů a v druhé milion, nebo naopak. Neví, jestli jsou hodnoty rozprostřené rovnoměrně, nebo nerovnoměrně.
S touto znalostí pracuje databáze (vy říkáte, že to jí tím neseberete). Ale pracuje s tím i programátor, protože ten podle toho volí způsob dotazu (Pavel vypisoval šířeji). ORM zvolí outer join tam, kde programátor usoudí, že může zvolit inner join. ORM zvolí subselect tam, kde programátor zvolí (lateral) join. ORM zvolí posloupnost dotazů tam, kde programátor jeden složený. ORM uzamkne příliš, tam, kde programátor může usoudit, že stačí méně. To jsou ta nepřekročitelná omezení (resp. překročitelná jsou jedině tak, že se v ORM stejně uchýlí k sestavení konkrétního dotazu).
Ani s tou milisekundou sem, milisekundou tam podle mě nemáte pravdu. Obecně ORM systémy generují vyšší počet dotazů. Když máte 50 dotazů na úkon, a na každém dotazu ztratíte 5 ms a k systému přistupuje 100 lidí, vytvoříte si lap 25 sekund. V lepším případě se to projeví jen tím, že každý uživatel čeká o čtvrt sekundy déle, což bývá přijatelné. V horším případě čekají transakce za sebou (kvůli ACID) a lap na uživatel je mnohem vyšší.
Podle mě v úvahách směřujete spíš od ORM k nějaké objektové databázi, která aspoň některé z problémů řeší (ale zase přináší trochu jiné).
Ale jinak fajn diskuse, dává mi to trochu větší vhled do toho, jak o tom přemýšlejí ORM uživatelé, a jak bídně umím popsat to, co jsem přesvědčený, že je hlavní a nepřekročitelný problém. Díky.
-
Nejedná se o ORM versus DB. Ale o ORM versus vývojář.
Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?
To ORM same od seba nedokaze ziskat ziadne data, za tym ze ziska nejake data stoji vyvojar.
Samozrejme by bolo mozne namietnut, ze na programovanie ORM staci jeden programator a ked mame ORM tak nam stacia lopaty.
I toto je omyl, programator ktory to ORM pouzije, by mal byt schopny vystup validovat. Ak nie je validny tak musi byt schopny porozumiet tomu co chce ORM dotazom poslanym do db povedat.
V kazdom pripade vyvojar musi byt schopnejsi ako to orm, inak bude len skusat na slepo a lovit na sof.
Jedine co moze priniest ORM vyvojarovi ze mapuje typy z rdbms na typy v aplikacnom jazyku, ktory je zvedsa typovo ovela slabsi ako rdbms. To ostatne je len zjednodusenie pre slabsich kolegov, da sa na tom zdanlivo usetrit. Co sa v buducnosti predrazi, ked to potom musi dlho riesit niekto z podstatne vyssou hodinovou sadzbou.
-
Ale pracuje s tím i programátor,
Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.
Ani s tou milisekundou sem, milisekundou tam podle mě nemáte pravdu. Obecně ORM systémy generují vyšší počet dotazů. Když máte 50 dotazů na úkon, a na každém dotazu ztratíte 5 ms a k systému přistupuje 100 lidí, vytvoříte si lap 25 sekund. V lepším případě se to projeví jen tím, že každý uživatel čeká o čtvrt sekundy déle, což bývá přijatelné. V horším případě čekají transakce za sebou (kvůli ACID) a lap na uživatel je mnohem vyšší.
Já mluvil o milisekundách spálených na mapování výsledku dotazu na objektovou reprezentaci. V žádném případě na tom, že by ORM mělo posílat horší dotazy než by napsal vývojář.
Zbytek je opět sklouznutí ke steskům nad nekvalitou ORM.
Podle mě v úvahách směřujete spíš od ORM k nějaké objektové databázi,
Určitě ne.
Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?
Ty, které může lépe získat stroj: tzn. statistiky atd...., ORM získat za rozumný čas nemůže, protože prostě na ně "nevidí". Nemá ty data, ty má DB. Proto je tato otázka chybně položená. Není problém v "STROJ versus VÝVOJÁŘ", problém je v tom, jaké možnosti má stroj na úrovni ORM vrstvy - a že kdybys chtěl ty problémy překonat, tak bys musel do té ORM vrstvy nutně zabudovat i celou databázi.
No a pak jsou informace, které prostě stroj (přinejmenším v dnešním stavu AI) získat prostě nemůže. To, co si od takového ORM představuješ je defakto schopnost programovat, a ta jestli je principiálně vůbec možná (asi jo), tak je úplně někde jinde, než co dneska umíme.
Jak píše Pavel: i SQL databáze, která řeší jednoduché a matematicky snadno popsatelné problémy relační algebry, řeší u každého přístupu jen pár vhodných strategií - a i tam občas selhává. A ty bys chtěl vlastně po ORM něco, co by umělo ne volit jednu strategii z pár "napevno zadrátovaných", ale které by umělo algoritmizaci. Jasně - teroreticky to asi možný je. Ale až to budeme umět, tak budeme umět konstruovat androidy - a programátoři přijdou o práci.... :-)
To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.
-
To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.
V databázi (ve schématu) nemáte žádné informace o procesech - o tom, jak se data mění, v jakých proporcích, jak a kde dochází k zámkům, atd atd. Schéma je statická záležitost - minimálně v tuto chvíli neumí popsat dynamiku dat a dynamické (chronologické) závislosti. Schéma například neobsahuje žádnou informaci o frekvenci update, kterou já jako vývojář beru v potaz už při návrhu schématu. Jelikož sleduji vývoj zpracování statistik (práce Tomáše Vondry), tak vím, jak je náročné vysledovat něco, co není explicitně zadáno v datech databáze (například závislosti mezi sloupci, korelace mezi tabulkami). Ne, že by to nebylo technicky realizovatelné - ale ta úloha je náročná - příliš dat, příliš kombinací. Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.
-
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.
-
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.
???
-
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.
???
treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani
takovych operaci je vic a chcete je ruzne kombinovat
muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat
-
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.
???
treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani
takovych operaci je vic a chcete je ruzne kombinovat
muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat
Jasně, ale a) je to statická věc - nepodchytíte tím žádnou dynamiku, b) není to nic, co by ORM získalo samo, musí to programátor explicitně napsat - a je funkčně jedno jestli to programátor udělá ručně SQL nebo přes definici v aplikaci, a pak to SQL vygeneruje query builder. ORM nikdy nemůže získat žádnou znalost samo. A minimálně v tuto chvíli neexistuje samoučící se (adaptabilní) ORM systém - všechno to jsou statické systémy.
Je velký rozdíl jestli píšete aplikaci vůči velké databázi s netriviální zátěží nebo s malou databází s malou zátěží. U velké databáze by měl komplexní SQL dotaz programátora "bolet". Chtěnou vlastností různých ORM systémů je maskování komplexity dotazů - jenomže to způsobuje dva problémy - umožňuje dlouhodobě pracovat s špatně navržený datovým modelem, aniž by se programátor pozvracel - ale špatně navržený datový model nutně vede k pomalým dotazům a slabému výkonu - a v pozdější době, kdy už programátor musí psát některé dotazy ručně, tak zvrací každý den, nebo striktně odmítne jakýkoliv zásah - a pak tam máte dotazy, které ručně trvají 20ms, a generované 20000ms - a pokud takových dotazů máte víc, tak hezky tavíte CPU.
-
treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani
takovych operaci je vic a chcete je ruzne kombinovat
muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat
Jinak v SQL mám pro tento účel pohledy (kdybych chtěl udělat tyto vazby perzistentní) anebo CTE pro semi pohledy.
Ale je to jedno, jestli pohledy si vytváříte aplikačně nebo databázově. Dneska i 8 řada MySQL už umí nematerializované pohledy, takže není důvod obcházet databázi.
-
Ale pracuje s tím i programátor,
Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.
Já myslím, že jsme u jádra pudla.
Zkusíme to na malých a extrémních příkladech.
Zkuste mi prosím popsat, jak by ORM mohlo vědět např. kdy se vyplatí z DB vytáhnout více dat hromadně dopředu, když v daný okamžik má požadavek třeba jen na jeden záznam - přičemž programátor s určitou přesností ví, že bude potřebovat vybranou sadu záznamů? ORM se může rozhodnout mezi dvěma extrémy - vzít a doručit jednu položku (a pokud to bude ve smyčcce, tak vygeneruje spoustu dotazů), nebo natáhnout do aplikace všechny (třeba i spoustu zbytečných). ORM není schopno rozhodnout "nic mezi", zatímco programátor s určitým úspěchem ano.
Nebo, někdy se vyplatí k záznamům rovnou dotáhnout (joinem) navázané informace. Aplikace je může potřebovat až někdy později za běhu, ale ví se, že je potřebovat bude (v některých případech). ORM se zase může leda rozhodnout, že je dotáhne ad hoc po jednom (spousta dotazů ve smyčce), ad hoc hromadně (pak join provádí aplikace svojí logikou), nebo dopředu (tj. bude je tahat i v případech, kdy nebudou potřeba). Opět, toto může ovlivnit jedině programátor tím, že to tomu ORM dá nějak na vědomí.
To jsou dva úplně triviální příklady, kdy se ORM nemůže rozhodnout za programátora. Ano, programátor může ORM nahintovat, aby se zachovalo tak, jak si představuje. Tím se ale ztrácí kus univerzálnosti ORM řešení, a navíc ten programátor stejně musí znát, co je v pozadí. Bez toho nemůže vědět, jak hintovat.
Já mluvil o milisekundách spálených na mapování výsledku dotazu na objektovou reprezentaci. V žádném případě na tom, že by ORM mělo posílat horší dotazy než by napsal vývojář.
Zbytek je opět sklouznutí ke steskům nad nekvalitou ORM.
Ta ztráta času je především v tom, že potřebujete snížit počet dotazů i za cenu komplikovaného dotazu. Potřebujete to snížit, abyste omezil obvykle neefektivní aplikační logiku a nekumuloval dotazové latence. Jak jsem psal výše, to rozhodnutí nejde udělat v rámci automatiky ORM.
-
Až bude nějaké ORM + AI natolik dobré, že si tohle postupně při běhu aplikace odvodí samo a dooptimalizuje k ideálnímu stavu, tak takové AI rovnou může tvořit celé aplikace - zákazník mu jen předhodí své požadavky co od aplikace chce. ;D
A teď z růžového obláčku zatím zpátky na zem.
-
Ale pracuje s tím i programátor,
Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.
Já myslím, že jsme u jádra pudla.
Zkusíme to na malých a extrémních příkladech.
Zkuste mi prosím popsat, jak by ORM mohlo vědět např. kdy se vyplatí z DB vytáhnout více dat hromadně dopředu, když v daný okamžik má požadavek třeba jen na jeden záznam - přičemž programátor s určitou přesností ví, že bude potřebovat vybranou sadu záznamů? ORM se může rozhodnout mezi dvěma extrémy - vzít a doručit jednu položku (a pokud to bude ve smyčcce, tak vygeneruje spoustu dotazů), nebo natáhnout do aplikace všechny (třeba i spoustu zbytečných). ORM není schopno rozhodnout "nic mezi", zatímco programátor s určitým úspěchem ano.
Nebo, někdy se vyplatí k záznamům rovnou dotáhnout (joinem) navázané informace. Aplikace je může potřebovat až někdy později za běhu, ale ví se, že je potřebovat bude (v některých případech). ORM se zase může leda rozhodnout, že je dotáhne ad hoc po jednom (spousta dotazů ve smyčce), ad hoc hromadně (pak join provádí aplikace svojí logikou), nebo dopředu (tj. bude je tahat i v případech, kdy nebudou potřeba). Opět, toto může ovlivnit jedině programátor tím, že to tomu ORM dá nějak na vědomí.
Oblíbená strategie, která se už běžně používá, a tedy není to žádné scifi je, že se provede první kolo, kde se použijou úplně naivní a neefektivní dotazy, a na základě toho se odvodí, jak má vypadat optimální.
Máš tam něco těžšího? :-)
Opravdu, ta představa, že programátor ví víc, než je schopen zjistit stroj je mylná (čest výjimkám).
Normální programátor jde, a koukne se do databáze. To ORM může udělat taky. Normální programátor jde, a vytvoří nějaký požadavek na data. To ví ORM taky.
Co by ORM nemohla vědět?
To jsou dva úplně triviální příklady, kdy se ORM nemůže rozhodnout za programátora. Ano, programátor může ORM nahintovat, aby se zachovalo tak, jak si představuje. Tím se ale ztrácí kus univerzálnosti ORM řešení, a navíc ten programátor stejně musí znát, co je v pozadí. Bez toho nemůže vědět, jak hintovat.
Toto jsem měl za to, že už jsme si vyříkali, a že jsem se vyjadřoval dostatečně expresivně: motivací ORM, určitě ne primární, není schovat DB. Já jsem pro hinty, a jsem pro to, aby mi ORM ukazovalo, jaké SQL vytváří, a mít možnost to ovlivnit. OK? Můžeme se k tomu už nevracet prosím?
To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.
V databázi (ve schématu) nemáte žádné informace o procesech - o tom, jak se data mění, v jakých proporcích, jak a kde dochází k zámkům, atd atd. Schéma je statická záležitost - minimálně v tuto chvíli neumí popsat dynamiku dat a dynamické (chronologické) závislosti. Schéma například neobsahuje žádnou informaci o frekvenci update, kterou já jako vývojář beru v potaz už při návrhu schématu. Jelikož sleduji vývoj zpracování statistik (práce Tomáše Vondry), tak vím, jak je náročné vysledovat něco, co není explicitně zadáno v datech databáze (například závislosti mezi sloupci, korelace mezi tabulkami). Ne, že by to nebylo technicky realizovatelné - ale ta úloha je náročná - příliš dat, příliš kombinací. Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.
To máš samozřejmě pravdu. A to nikdo nerozporuje. A tudíž v tom nevidím ten principielní problém, který by ORM nějak zvláště hendikepovalo.
Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.
Toto vypadá na jedno ze zásadních nepochopení. Mé tvrzení, že ORM dokáže vyčíst to samé co vývojář nijak nesouvisí se skutečností, že Databáze je model, který popisuje zjednodušenou realitu. (Nehledě na to, že i tam je spoustu "ale".)
-
Prostě ORM je primárně o mapování objektů na relace, nikoli o dotazování se. To je sekundární úkol a můžu k tomu v rámci ORM použít i SQL. Tím považuju de fakto debatu za vyřešenou :D