Od doby vzniku toho videa nosql hype castecne odeznel.Myslim, ze kdyz ma nekdo takovou praxi jako on tak uz ma vuci hype imunitu.
Myslim, ze kdyz ma nekdo takovou praxi jako on tak uz ma vuci hype imunitu. Je to videt i v tom videu kdyz srovnava ruzne jazyky.
Různé evidence (účetnictví, sklady, osoby) se tabulkově evidovaly dávno před databázemi, a ani dnes se z toho žádné stromy nevytváří. Takže bych řekl, že tabulkové databáze stále mají smysl. Ono totiž větší množství dat najednou ani moc jinak než tabulkově prezentovat nejde, takže pro lidi ta tabulková prezentace pořád bude přirozená, čemuž se pak samozřejmě podřizuje a systém evidence (její organizace – nezávislá na IT), a pak je přirozené takový systém reprezentovat v tabulkových databázích.OK, ale...
Mimochodem, řada SQL databází chodí v paměti. Někdy se prostě server nacpe takovým množství paměti, aby databázový stroj měl celou databázi načtenou v RAM jako v keši. Je to asi nejrychlejší řešení, pokud je hromada čtení. Jak to urychlí SSD? Bude rychlejší než RAM?
A neměl on na mysli náhodou "big data"?
Jako když budu sledovat výskyt osob na strategických uzlech infrastruktury, přičemž identifikaci budu dělat jen z obrazu kamer a dejme tomu metadat z telefonů, tak si umím představit že SQL nebude optimální nástroj. Ale nenapadá mě, proč by nemělo být vhodné u pěkně strukturovaných dat.
On v tom videu vlastne rika, ze SSD je takova persistentni RAM. Nicmene.. Pokud mam tolik pameti, ze v ni vsechno udrzim, existuje duvod proc to organizovat do tabulek?
Ta tabulkova evidence v dobach kartotek mela stejnou motivaci jako ty databaze: "Rychle se dostat k datum ktera chci".Ne vždy byla důležitá „rychlost hledání“. Třeba pro účetní záznamy je přirozené zapisovat je chronologicky tak, jak přicházejí – A to zrovna rychlosti hledání často nepomáhá. Proto se pak ty záznamy přepisovaly v jiném uspořádání – ale zase do tabulek.
Videl jsem v nedavne dobe dve aplikace (jedna stara 20 let, druha relativne moderni) u obou byla databaze vlastne jen datastore a synchronizace mezi nody. Jakmile se data vytahla tak se pracovalo se stromovou strukturou v pameti a v db byl lock az do doby nez se uzivatel rozhodl ukladat.To, že se někde používají stromové struktury, přece ale neznamená, že se používají všude, ani že nikde nejsou data přirozeně uspořádaná do tabulek.
Obe to jsou bankovni aplikace a podle me obe jsou ten typicky use case evidence (ucty, firmy, osoby...).To by mne zajímalo to konkrétní použití. Jasně, někdy jsou to třeba spíš dokumenty s nějakými vazbami – třeba firma, ta má nějaké vlastnosti, na firmu jsou navázaní lidé, ti mají zase nějaké vlastnosti. Ale třeba evidovat finanční transakce ve stromové struktuře mi moc smysl nedává.
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?
Definuj dlouho :-)Maji tabulkove databaze na novych projektech smysl?
Zavisi od projektu. Uz jen z povahy tveho dotazu vyplyva, ze si s daty neuzivas moc dlouho. ...
Vlastnosti rotačních disků (rychlé sekvenční čtení, pomalé čtení s náhodným přístupem) byl asi jen jeden z faktorů proč se rozšířily relační SQL databáze.
1. Relace (tabulky) jsou vlastně množiny, což je jednodušší abstrakce než stromy (grafy). 1D tabulka má tu výhodu, že se s ní dobře jednoduše mentálně pracuje. Když pracujete s fakturou, zajímají vás položky faktury a už vás nezajímají složky, kde je faktura zařazena. Pokud pracuji s fakturami, tak mne nezajímají položky faktur, atd. Relační model není tak obecný jako síťový, ale je dostatečně silný, a velice jednoduchý.
2. Relační databáze byly navrženy pro uživatele - umožňují neprogramátorům pracovat s daty. Tuto vlastnost konkurenční systémy nikdy ve větším měřítku nenabídly - a je to dáno možnostmi a názorností a jednoduchostí relačního modelu. Ono ručně pracovat se stromy pro laika není to pravé ořechové.
3. Relační model byl doplněný o SQL - opět jednoduchý, ale dostatečně silný nástroj. A standardizace, byť ne vždy dokonalá je neskutečně silný nástroj. Pokud umíte pracovat s Mongem, umíte pracovat s Mongem, ale už nikoliv s čímkoliv jiným. Pokud umíte SQL, tak vytvoříte tabulky a dotazy na Oracle, MSSQL, MySQL, Postgresu, SQLite. Na určité úrovni nemusíte řešit detaily a základy jsou stejné. Univerzální dotazovací jazyk nabídly pouze relační SQL databáze. Resp. byly pokusy i u dalších modelů, ale bez výraznějšího rozšíření.
4. Tabulka je implementačně halda. Struktura, která se jednoduše implementuje. Navíc v kombinaci s indexy, kterých můžete mít k haldě tolik kolik potřebujete můžete mít rychlý přístup přes různé atributy. Halda (případně pole) je velice efektivní struktura. Na uložení stromu potřebuje výrazně více paměti.
Ve výsledku je důležitá abstrakce a SQL. Obojí umožňuje pracovat s daty komukoliv. Jestli v reálu data budou uložená na SSD nebo v RAMce, jestli budou uložená v poli, v hash mapě nebo v nějaké stromové struktuře je úplně jedno .. v momentě, kdy bude dost RAM, abych data uložil na disk. Co vždy ale bude důležité, že kdokoliv, kdo má práva a trochu znalostí se může na data podívat z Excelu, z libovolné aplikace a není omezen programátorem.
CitaceMyslim, ze kdyz ma nekdo takovou praxi jako on tak uz ma vuci hype imunitu. Je to videt i v tom videu kdyz srovnava ruzne jazyky.
Dá se to pochopit. Čím větší senzace obchodník či školitel říká - tím více vydělá.
Problém je, že hype a unáhlené předpovědi už postihují dříve seriózní obory. Například vědu a fyziku, viz zpráva o částici rychlejší než světlo.
Na jednu stranu jsem rad, ze se ozval odbornik. Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.
Neuvedomuju si, ze bych potkal uzivaka kterej by umel aspon zaklad SQL, nebo si napojit excel na databazi. Mozna mam jen smulu.
CitaceNa jednu stranu jsem rad, ze se ozval odbornik. Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.
Proč by relační tabulkové databáze měly zahynout? ...
To je ale docela nefér to takto podat zrovna v tomto případě. Já tu "kauzu" sledoval dost zblízka a do hype to tlačili novináři - dost drsně (například vytrháváním vět z kontextu). Všichni vědci to brali velmi seriózně, upozorňovali na to, že je to divné, že se to musí ověřit, očekávají nějakou chybu v měření a tak. Prakticky nikdo neříkal, jaká je to revoluce a že překonali Einsteina. Bohužel novináři to dost otáčeli.
CitaceNa jednu stranu jsem rad, ze se ozval odbornik. Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.
Proč by relační tabulkové databáze měly zahynout? ...
Vubec nerozumim tvemu zpusobu diskuze.
Definuj dlouho :-)Maji tabulkove databaze na novych projektech smysl?
Zavisi od projektu. Uz jen z povahy tveho dotazu vyplyva, ze si s daty neuzivas moc dlouho. ...
OK to jsem asi prilis zjednodusil.Ta tabulkova evidence v dobach kartotek mela stejnou motivaci jako ty databaze: "Rychle se dostat k datum ktera chci".Ne vždy byla důležitá „rychlost hledání“. Třeba pro účetní záznamy je přirozené zapisovat je chronologicky tak, jak přicházejí – A to zrovna rychlosti hledání často nepomáhá. Proto se pak ty záznamy přepisovaly v jiném uspořádání – ale zase do tabulek.
Ano,ale tady mi na prvni pohled prislo, ze by davalo smysl vyuzit databazi prave kvuli konzistenci dat a transakcim.Videl jsem v nedavne dobe dve aplikace (jedna stara 20 let, druha relativne moderni) u obou byla databaze vlastne jen datastore a synchronizace mezi nody. Jakmile se data vytahla tak se pracovalo se stromovou strukturou v pameti a v db byl lock az do doby nez se uzivatel rozhodl ukladat.To, že se někde používají stromové struktury, přece ale neznamená, že se používají všude, ani že nikde nejsou data přirozeně uspořádaná do tabulek.
Credit risk management. Nejde o nejake real time transakce, spis kalkulace rizika spojeneho s poskytnutim pujcky.Obe to jsou bankovni aplikace a podle me obe jsou ten typicky use case evidence (ucty, firmy, osoby...).To by mne zajímalo to konkrétní použití. Jasně, někdy jsou to třeba spíš dokumenty s nějakými vazbami – třeba firma, ta má nějaké vlastnosti, na firmu jsou navázaní lidé, ti mají zase nějaké vlastnosti. Ale třeba evidovat finanční transakce ve stromové struktuře mi moc smysl nedává.
CitaceNa jednu stranu jsem rad, ze se ozval odbornik. Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.
Proč by relační tabulkové databáze měly zahynout? ...
Vubec nerozumim tvemu zpusobu diskuze.
1) Prvotní otázka byla o tom, že tabulkové databáze mají zahynout.
2) Do toho byla tvá pochybnost, že odborník je příliš hájí a má zkreslený názor.
I přidal jsem další argument, proč má pravdu.
Definuj dlouho :-)Maji tabulkove databaze na novych projektech smysl?
Zavisi od projektu. Uz jen z povahy tveho dotazu vyplyva, ze si s daty neuzivas moc dlouho. ...
pres 20 let :-D
1) Zahynout ne. Jen jestli maji smysl. Preziva spousta jinych nesmyslu tak proc ne databaze.
2) Myslel jsem tim nazor na schopnosti BFU pracovat s databazi. Pavel jako clovek co databazi programuje se asi setkava s jinou skupinou uzivatelu nez ja.
Vlastnosti rotačních disků (rychlé sekvenční čtení, pomalé čtení s náhodným přístupem) byl asi jen jeden z faktorů proč se rozšířily relační SQL databáze.
1. Relace (tabulky) jsou vlastně množiny, což je jednodušší abstrakce než stromy (grafy). 1D tabulka má tu výhodu, že se s ní dobře jednoduše mentálně pracuje. Když pracujete s fakturou, zajímají vás položky faktury a už vás nezajímají složky, kde je faktura zařazena. Pokud pracuji s fakturami, tak mne nezajímají položky faktur, atd. Relační model není tak obecný jako síťový, ale je dostatečně silný, a velice jednoduchý.
2. Relační databáze byly navrženy pro uživatele - umožňují neprogramátorům pracovat s daty. Tuto vlastnost konkurenční systémy nikdy ve větším měřítku nenabídly - a je to dáno možnostmi a názorností a jednoduchostí relačního modelu. Ono ručně pracovat se stromy pro laika není to pravé ořechové.
3. Relační model byl doplněný o SQL - opět jednoduchý, ale dostatečně silný nástroj. A standardizace, byť ne vždy dokonalá je neskutečně silný nástroj. Pokud umíte pracovat s Mongem, umíte pracovat s Mongem, ale už nikoliv s čímkoliv jiným. Pokud umíte SQL, tak vytvoříte tabulky a dotazy na Oracle, MSSQL, MySQL, Postgresu, SQLite. Na určité úrovni nemusíte řešit detaily a základy jsou stejné. Univerzální dotazovací jazyk nabídly pouze relační SQL databáze. Resp. byly pokusy i u dalších modelů, ale bez výraznějšího rozšíření.
4. Tabulka je implementačně halda. Struktura, která se jednoduše implementuje. Navíc v kombinaci s indexy, kterých můžete mít k haldě tolik kolik potřebujete můžete mít rychlý přístup přes různé atributy. Halda (případně pole) je velice efektivní struktura. Na uložení stromu potřebuje výrazně více paměti.
Ve výsledku je důležitá abstrakce a SQL. Obojí umožňuje pracovat s daty komukoliv. Jestli v reálu data budou uložená na SSD nebo v RAMce, jestli budou uložená v poli, v hash mapě nebo v nějaké stromové struktuře je úplně jedno .. v momentě, kdy bude dost RAM, abych data uložil na disk. Co vždy ale bude důležité, že kdokoliv, kdo má práva a trochu znalostí se může na data podívat z Excelu, z libovolné aplikace a není omezen programátorem.
Hmm tak ted nevim... :-)
Na jednu stranu jsem rad, ze se ozval odbornik.
Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.
Neuvedomuju si, ze bych potkal uzivaka kterej by umel aspon zaklad SQL, nebo si napojit excel na databazi.
Mozna mam jen smulu.
Ano,ale tady mi na prvni pohled prislo, ze by davalo smysl vyuzit databazi prave kvuli konzistenci dat a transakcim.
A zajimala by me motivace architekta k takovemu reseni. A protoze jsem videl toho Boba povidat o necem podobnem tak mi to vrta v hlave a snazim se prijit na to co bud ja nebo Bob a ty dva architekti nevidime. (BTW. jsou fakt dva ruzni, kazdy jina narodnost a kazdy v jine bance)
Je to tedy úplně OT (sorry jako), ale to video je hodně zajímavé. Ten člověk má evidentně velké zkušenosti a zejména část o tom, že C je z jeho pohledu víc OO než C++ je dost dobrá (s tím "leakem" dat do headerů v C++ má pravdu, to je dost humus).C++ moc objektové není a na C se dá postavit mnohem lepší objektový jazyk než C++ - viz Objective C. Ale to ještě neznamená, že samotné C je objektové. Ostatně takový Forth, Lisp či Lua také nejsou objektové, ale snadno se v nich dá vybudovat objektová nástavba - ve všech třech případech opět lepší než C++.
Je to tedy úplně OT (sorry jako), ale to video je hodně zajímavé. Ten člověk má evidentně velké zkušenosti a zejména část o tom, že C je z jeho pohledu víc OO než C++ je dost dobrá (s tím "leakem" dat do headerů v C++ má pravdu, to je dost humus).C++ moc objektové není a na C se dá postavit mnohem lepší objektový jazyk než C++ - viz Objective C. Ale to ještě neznamená, že samotné C je objektové. Ostatně takový Forth, Lisp či Lua také nejsou objektové, ale snadno se v nich dá vybudovat objektová nástavba - ve všech třech případech opět lepší než C++.
jj souhlas! on tam nerikal, ze C je OO jazyk, ale ze s C++ se to v urcitem ohledu zhorsilo (vzal napriklad zapouzdreni z vetsiho rozhledu, nez pouha pristupova prava k metodam/atributum)
jj souhlas! on tam nerikal, ze C je OO jazyk, ale ze s C++ se to v urcitem ohledu zhorsilo (vzal napriklad zapouzdreni z vetsiho rozhledu, nez pouha pristupova prava k metodam/atributum)
Přístupová práva jsou jen jako závora tam, kde by stačil semafor. Zapouzdření je, když jsou operace s daty tam, kde jsou data.
IMHO to stačí. Přesně jak napsal Kit. Vrtal se někdy nějaký céčkař ve struktuře FILE? Neznám žádného, ač tomu žádný private nebrání. Snad jediný smysl by to mělo jako ochrana před omylem, kdy bych se při volání metody náhodou nechtěně trefil do nějaké vnitřnosti objektu. Ale tomu se dá předejít vhodným pojmenováním, což je jednodušší řešení než další syntaktické přislazování už tak přeslazených "běžných" "objektových" jazyků. Ono je to jako s dělícími svodily vs. plnou čarou. Na dálnici to asi smysl má, ale normální silnici by to zbytečně prodražilo a neuvěřitelně by to zkomplikovalo řešení mimořádných situací.jj souhlas! on tam nerikal, ze C je OO jazyk, ale ze s C++ se to v urcitem ohledu zhorsilo (vzal napriklad zapouzdreni z vetsiho rozhledu, nez pouha pristupova prava k metodam/atributum)
Přístupová práva jsou jen jako závora tam, kde by stačil semafor. Zapouzdření je, když jsou operace s daty tam, kde jsou data.
to nestaci. zapouzdreni je totiz i metoda pro ukryvani informaci nepodstatnych pro konzumenta dane tridy. A ... no vlastne toto umi jen par jazyku.
IMHO to stačí. Přesně jak napsal Kit. Vrtal se někdy nějaký céčkař ve struktuře FILE? Neznám žádného, ač tomu žádný private nebrání. Snad jediný smysl by to mělo jako ochrana před omylem, kdy bych se při volání metody náhodou nechtěně trefil do nějaké vnitřnosti objektu. Ale tomu se dá předejít vhodným pojmenováním, což je jednodušší řešení než další syntaktické přislazování už tak přeslazených "běžných" "objektových" jazyků. Ono je to jako s dělícími svodily vs. plnou čarou. Na dálnici to asi smysl má, ale normální silnici by to zbytečně prodražilo a neuvěřitelně by to zkomplikovalo řešení mimořádných situací.jj souhlas! on tam nerikal, ze C je OO jazyk, ale ze s C++ se to v urcitem ohledu zhorsilo (vzal napriklad zapouzdreni z vetsiho rozhledu, nez pouha pristupova prava k metodam/atributum)
Přístupová práva jsou jen jako závora tam, kde by stačil semafor. Zapouzdření je, když jsou operace s daty tam, kde jsou data.
to nestaci. zapouzdreni je totiz i metoda pro ukryvani informaci nepodstatnych pro konzumenta dane tridy. A ... no vlastne toto umi jen par jazyku.
C++ moc objektové není a na C se dá postavit mnohem lepší objektový jazyk než C++ - viz Objective C.
Ale to ještě neznamená, že samotné C je objektové. Ostatně takový Forth, Lisp či Lua také nejsou objektové, ale snadno se v nich dá vybudovat objektová nástavba - ve všech třech případech opět lepší než C++.
Když si to stejné zkusíš napsat objektově (přes class), tak uživateli cpeš i všechny interní informace v hlavičkovém souboru. to mu je 1) na nic 2) každá změna si vyžaduje překlad všech zdrojáků, co na tom headeru závisí (imho horší problém u větších projektů). Takže to je ukrývání informace, ale ne přes nějaká klíčová slova, ale vlastností jazyka
A že nejlepší objekty jsou z pohledu těchto lidí ty, co jsou ještě ve snu a neexistují.GNU Hurd?
... ale ještě jsem se neodvážil to panu Krčmářovi nabídnout, neb se obávam, že by to redakca nevzala z oprávněné obavy z urážlivých komentářů pod článkem a z toho vyplývajícího popotahování s úřady. ... V dnešní diskuzi mne svými výroky překvapil pan Ponkrác (kterého považuji za nejchytřejšího člověka na zeměkouli - těsně před V. Klausem). Např:
Ja si od roku tak 1980 nepamatuji, že by existovala databáze, kde by aplikační prograátor musel vědet, kde jsou data uložena. Kde tohle pan Ponkrác sebral fakt nevím.
CitaceKdyž si to stejné zkusíš napsat objektově (přes class), tak uživateli cpeš i všechny interní informace v hlavičkovém souboru. to mu je 1) na nic 2) každá změna si vyžaduje překlad všech zdrojáků, co na tom headeru závisí (imho horší problém u větších projektů). Takže to je ukrývání informace, ale ne přes nějaká klíčová slova, ale vlastností jazyka
Prosím vás, co dělám špatně, že už 20 let píši v C++, používám třídy, a nemám detaily o interních datech třídy v hlavičkových souborech?
Předpokládám, že máte v hlavičkovém souboru public a protected atributy/metody a všechno ostatní v nějaké interní třídě, která je jen deklarována formou ukazatele na ní? Šlo by prosím dát příklad - možná se nebavíme o stejné věci (a nejsem strýček Bob, který to možná taky myslel jinak .-)
class Thread
{
public:
static Thread* getCurrentThread();
Thread();
virtual ~Thread();
int getPriority();
void setPriority(int priority);
void isAlive();
void start();
protected:
virtual void main() = 0;
private:
// Skrývání pomocí struktury __ThreadBlock, kterou zná jen implementace.
// Tento způsob je pro implementaci nejpříjemnější.
::internal_thread::__ThreadBlock * _ThreadBlock;
// Jiná možnost skrývání pomocí bloku paměti, jejíž význam zná jen implementace.
char _ThreadHandle[1024];
// Nebo nemusíte vůbec deklarovat ani typ interních dat.
void * _InternalPrivateDataBlock;
// Atd. atd. atd. - Jste omezeni jen vlastní představivostí.
};
1) Je třeba si uvědomit, že C++ umožnuje roztáhnout implementaci třídy do libovolného množství modulů. Což je vynikající věc, která mi strašně chybí v Javě, PHP, C# a mnoha dalších jazycích. Proto je potřeba, aby v hlavičkovém souboru bylo vidět vše.
už leta připravuji článek o tom, jaký je SQL ( tabulkové databáze) nesmysl, ale ještě jsem se neodvážil to panu Krčmářovi nabídnout, neb se obávam, že by to redakca nevzala z oprávněné obavy z urážlivých komentářů pod článkem a z toho vyplývajícího popotahování s úřady.
CitacePředpokládám, že máte v hlavičkovém souboru public a protected atributy/metody a všechno ostatní v nějaké interní třídě, která je jen deklarována formou ukazatele na ní?
2) C++ nepotřebuje znát detaily o datech a strukturách/třídách/atd. pokud k nim přistupuje pouze přes ukazatel. To je stejné i v C.
Pokud chcete mít privátní členy třídy nerozepsané v hlavičkovém souboru, nebo to není praktické - na každé platformě je to jinak, pak máte možnost toto použít.Kód: [Vybrat]class Thread
{
public:
static Thread* getCurrentThread();
Thread();
virtual ~Thread();
int getPriority();
void setPriority(int priority);
void isAlive();
void start();
protected:
virtual void main() = 0;
private:
// Skrývání pomocí struktury __ThreadBlock, kterou zná jen implementace.
// Tento způsob je pro implementaci nejpříjemnější.
::internal_thread::__ThreadBlock * _ThreadBlock;
už leta připravuji článek o tom, jaký je SQL ( tabulkové databáze) nesmysl, ale ještě jsem se neodvážil to panu Krčmářovi nabídnout, neb se obávam, že by to redakca nevzala z oprávněné obavy z urážlivých komentářů pod článkem a z toho vyplývajícího popotahování s úřady.
To je ta genialita některých vývojářů, že už dopředu vědí, že jejich výtvor bude rychlý. Já osobně si sice pamatuji, že relační databáze měly jeden veliký nedostatek - oproti tehdejším databázím byly pomalé. Nakonec i dnes je pan Stěhule živ z toho, že obchází firmy a zrychluje ty jejich aplikace. Samozřejmě by pan Stěhule udělal ty aplikace hned zpočátku rychlé - ale on nemůže bý u každého projektu - ledaže by si vzal k ruce pana Jirsáka.Tak Pavla Stěhule bych se zastal, ten tomu aspoň rozumí a dá se s ním bavit.
Ten článek bych si rád přečetl - klidně mi jej můžete poslat privátně, jestli máte obavy o redakci roota. Mail na mne se válí na netu - nebo někde u piva můžeme podiskutovat a výhodách a nevýhodách RDBMS.Nebyl by si sám.
24.9. bude Postgres meetup - u piva můžeme dát řeč.Kde? Dáš link prosím?
Taková čuňárna mi v PHP rozhodně nechybí. Vadí mi i když někdo použije traity.
Kde? Dáš link prosím?https://www.meetup.com/Prague-PostgreSQL-Meetup/
No přece to smalltalkovské. :) Ostatně to byl A. Kay, kdo s termínem "objektově orientované programování" přišel, a jak sám říká, "C++ jsem tím opravdu nemyslel". No a u mě to souviselo s tím, že když jsem se v 90. letech seznamoval s "novinkou", jakou bylo OOP - konkrétně na C++, pořád mi nebylo zřejmé, k čemu to je celé vlastně dobré. Spíš mi připadalo, že je to celé jen zbytečná znepřehledňující komplikace. Ten wow-efekt se dostavil, až když mi bylo doporučeno mrknout se na Smalltalk - jednoduché, až primitivní, a přitom tak neuvěřitelně mocné. Většina C++ programů, které se mi dostaly pod ruce, byly ale opravdu jen funkce naházené do tříd.CitaceC++ moc objektové není a na C se dá postavit mnohem lepší objektový jazyk než C++ - viz Objective C.Dovolte takovou otázku: Co je to "správné objektové pojetí"?
Nezvladli pointery v c, vymysleli picovinu jako jsou reference.
pak vymysleli smart nebo smrt pointery, hnus, left a right reference, to je jen
unik chytrych hlav od postaty problemu, ze staci na vsecko pointer.
ja jsem pointer vytvoril, ja ho musim smazat. Totez plati v listu, ve stromu.
CitaceKdyž si to stejné zkusíš napsat objektově (přes class), tak uživateli cpeš i všechny interní informace v hlavičkovém souboru. to mu je 1) na nic 2) každá změna si vyžaduje překlad všech zdrojáků, co na tom headeru závisí (imho horší problém u větších projektů). Takže to je ukrývání informace, ale ne přes nějaká klíčová slova, ale vlastností jazykaProsím vás, co dělám špatně, že už 20 let píši v C++, používám třídy, a nemám detaily o interních datech třídy v hlavičkových souborech?
Kód: [Vybrat]class Thread
{
public:
static Thread* getCurrentThread();
Thread();
virtual ~Thread();
int getPriority();
void setPriority(int priority);
void isAlive();
void start();
protected:
virtual void main() = 0;
private:
// Skrývání pomocí struktury __ThreadBlock, kterou zná jen implementace.
// Tento způsob je pro implementaci nejpříjemnější.
::internal_thread::__ThreadBlock * _ThreadBlock;
// Jiná možnost skrývání pomocí bloku paměti, jejíž význam zná jen implementace.
char _ThreadHandle[1024];
// Nebo nemusíte vůbec deklarovat ani typ interních dat.
void * _InternalPrivateDataBlock;
// Atd. atd. atd. - Jste omezeni jen vlastní představivostí.
};
Tak Pavla Stěhule bych se zastal, ten tomu aspoň rozumí a dá se s ním bavit.
Ten článek bych si rád přečetl - klidně mi jej můžete poslat privátně, jestli máte obavy o redakci roota. Mail na mne se válí na netu - nebo někde u piva můžeme podiskutovat a výhodách a nevýhodách RDBMS.
.....
Nebyl by si sám.
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?Zakladny omyl je, ze SSD su rychle. Nie su, SSDka su brutalne pomale, ak sa vezme v uvahu rychlost, akou dnes operuje pamat a to, akym sposobom SSD funguju, hlavne pri zapise.
...Vseobecne radsej pouzivam relacne (tabulkove) DB, MySQL... Pripadaju mi "najuniverzalnejsie". Hlavne na projektoch, kde sa struktura dat meni s pridavanim funkcnosti do aplikacie...
On v tom videu vlastne rika, ze SSD je takova persistentni RAM. Nicmene.. Pokud mam tolik pameti, ze v ni vsechno udrzim, existuje duvod proc to organizovat do tabulek?
CitaceOn v tom videu vlastne rika, ze SSD je takova persistentni RAM. Nicmene.. Pokud mam tolik pameti, ze v ni vsechno udrzim, existuje duvod proc to organizovat do tabulek?
Ano. Protože data mají logiku, mají určenou doménovou a referenční integritu. Mají zaručenou konzistenci dat a konzistenci operací. Máte zajištěno mnohem více.
Jaký existuje důvod organizovat data do grafů nebo objektových sítí? Jak vytvoříte nad těmito strukturami rychlé datové operace? Jaké bude API? Jak zajistíte konzistenci dat a vazeb mezi daty? Jak budete zajišťovat transakce? Jak budete vytvířet jazyk pro hledání dat pro obrovská data?
Jak říkám, nikdo nikomu nebrání, aby udělal databázi na grafových či objektových strukturách. A dotáhl to tak daleko, aby převálcoval relační databáze. Ale ony tu jsou omezující i fyzikální zákony, není to jen o tom, že dokážete co chcete.
***
Důvod organizovat do tabulek je proto, že vám jako aplikaci, která využívá služby databázového stroje není absolutně nic do toho, kde jsou data uložena. Váš to nezajímá. Jestli data jsou uložena na HDD, SDD, RAM, nebo na děrných štítcích, nebo na nové hyperpaměti 22. století - o to se nestaráte. Vy jen požadujete po databázovém stroji vrácení dat či operaci s daty. Tečka. Databázový stroj je abstrakce, kterou neřešíte. Administrátor databázového stroje pak vyřeší implementační detaily.
Hele, proč ta RAM nebo SSD nemají tedy úložné místo organizováno do grafů či objektů, když je to tak lepší? Proč i ta RAM a SSD jedou v alokačních blocích? Není to nápověda, proč je univerzálnější a nejpoužitelnější organizovat data a datové úložiště do tabulek?
Ale třeba evidovat finanční transakce ve stromové struktuře mi moc smysl nedává.
...Relacni DB byly, jsou a budou. Jsou pomerne lehke na pochopeni, SQL jazyk taky...
...a kdyz se spravna cast business logiky resi uz rovnou v DB (stored procedures, olap atd.)...
Proč by relační tabulkové databáze měly zahynout?
Jednak získat z relačních databází strom, graf, apod. je často spíše otázkou indexování a pak vhodného SQL dotazu.
Když chci strom/graf, tak si k tabulce X přidám druhou tabulku X_tree_index nebo X_graph_index, kde pomocí triggerů nebo ručně indexuji pár čísel, abych mohl jediným SQL dotazem načíst celou větev stromu či jiné časté operace. Mám už to jako takový "návrhový relační vzor".
Jednou z uplne prvnich databazi bylo IMS (a obcas se jeste pouziva), a ta uklada data (zaznamy) prave ve stromove strukture podle klice.
... Ale hlavni nevyhoda je, ze si musite vytvorit vlastni funkci (program), ktera ty zaznamy prochazi ...
... A pokud chcete hledat podle jinych klicu - vesmes to znamena zmenit databazi a programy, co delaji ty dotazy.
Jinak k dotazu - myslim, ze vyvoj pujde dal podobnym smerem. SQL zahrne specialni pozadavky jako limitni pripad a rozsiri tim svoji flexibilitu. Coz se ostatne v pripade tech nerelacnich databazi uz dost deje.
Jednou z uplne prvnich databazi bylo IMS (a obcas se jeste pouziva), a ta uklada data (zaznamy) prave ve stromove strukture podle klice.
... Ale hlavni nevyhoda je, ze si musite vytvorit vlastni funkci (program), ktera ty zaznamy prochazi ...
ale to je také ta největší výhoda
A pak přišla Java kde nebezpečné pointery úplně zmizely (ne jako v C++ kde si u velkého projektu nemůžete být jistý kdo kde použije paměť nebezpečným způsobem) což umožnilo zavést garbage collector a to je konečně bezpečné, rychlé a pohodlné programování.
Zrovna tohle je v C++ špatně navržené. ... Ale považuji za chybu, že privátní metody a proměnné jsou vidět v hlavičkovém souboru a co hůř, jejich změna rozbije binární kompatibilitu.
Zrovna tohle je v C++ špatně navržené. ... Ale považuji za chybu, že privátní metody a proměnné jsou vidět v hlavičkovém souboru a co hůř, jejich změna rozbije binární kompatibilitu.
To jako fakt?! Hm, dobrá sračka...
No tak kdyby C++ zavedlo stejná omezení jako má Java, tak by ta binární kompatibilita šla jednoduše. Objekty alokované po jednom na haldě, takže volající nemusí znát jejich velikost. Všechny metody virtuální, takže žádné inlinování. Akorát ta cena za to je docela drsná.Zrovna tohle je v C++ špatně navržené. ... Ale považuji za chybu, že privátní metody a proměnné jsou vidět v hlavičkovém souboru a co hůř, jejich změna rozbije binární kompatibilitu.To jako fakt?! Hm, dobrá sračka...
Tak se chci zeptat:
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?
Diky za nazory
Zrovna tohle je v C++ špatně navržené. ... Ale považuji za chybu, že privátní metody a proměnné jsou vidět v hlavičkovém souboru a co hůř, jejich změna rozbije binární kompatibilitu.
To jako fakt?! Hm, dobrá sračka...
Ono to má technický důvod. Ty struktury mají fixní velikost, takže se rozjedou pointer offsety pro přístup k atributům. Pokud to ABI musí být stabilní, je potřeba to rozdělit na stabilní "proxy" interface a privátní data s negarantovanou strukturou.
Tak se chci zeptat:
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?
Diky za nazory
Protoze jsem tu videl jen skepticke reakce a pak offtopic diskuzi, zkusim neco jineho:
Radu let jsem pouzival pro male projekty MySQL. Funkcni, hezke nastroje k organizaci, interface do ruznych jazyku. Co pul roku mam zvyk se jen tak podivat na neco noveho. Tehdy to bylo MongoDB. Slozita neintuitivni instalace a zprovoznovani (2016), ale nakonec zafungovalo. Napsal jsem si skript na zapis/cteni. A nedavno jsem (hard) preinstaloval na Ubu1804 a mel zasadni problem s prevodem dat.
Vysledne dojmy? : Uz bych nemenil.
- Zalozeni nove tabulky (tady collection) nevyzaduje zadnou specialni akci
- V pythonu je pymongo: ovladani se neda s mysql srovnavat, vsechno je jako DICT
- Pouzivam 100x intenzivneji nez kdysi mysql, takze mam kolem milionu zaznamu, zapisuji kazdych 10 sec. a nevidim latenci
- Menim tabulku za behu, proste zacnu pridavat dalsi parametr.
- Mam dost ridkou tabulku, vetsina parametru je Nan, navazujici pymongo a pyplot jsou v pohode.
- Clovek muze nechat bezet stejne MongoDB na vice strojich najednou, cimz ma duplicitu a pojisteni proti vypadku (ale nezkousel jsem)
- ... a nakonec - MongoDB neni ta nejrychlejsi a nejlepsi NoSQL databaze na trhu.....
Takze tak. Minusy? Nenasel jsem zadnej skvelej program na udrzbu (jako mysql-workbench apod). Ale nechybi mi, na vsechno mam jeden skript.
Přiznám se, že nevím co si z tohohle příspěvku odnést. Jak se ta databáze vůbec používá? Jestli na veškerou údržbu stačí jeden script tak to IMO nezní moc komplikovaně.Tak se chci zeptat:
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?
Diky za nazory
Protoze jsem tu videl jen skepticke reakce a pak offtopic diskuzi, zkusim neco jineho:
Radu let jsem pouzival pro male projekty MySQL. Funkcni, hezke nastroje k organizaci, interface do ruznych jazyku. Co pul roku mam zvyk se jen tak podivat na neco noveho. Tehdy to bylo MongoDB. Slozita neintuitivni instalace a zprovoznovani (2016), ale nakonec zafungovalo. Napsal jsem si skript na zapis/cteni. A nedavno jsem (hard) preinstaloval na Ubu1804 a mel zasadni problem s prevodem dat.
Vysledne dojmy? : Uz bych nemenil.
- Zalozeni nove tabulky (tady collection) nevyzaduje zadnou specialni akci
- V pythonu je pymongo: ovladani se neda s mysql srovnavat, vsechno je jako DICT
- Pouzivam 100x intenzivneji nez kdysi mysql, takze mam kolem milionu zaznamu, zapisuji kazdych 10 sec. a nevidim latenci
- Menim tabulku za behu, proste zacnu pridavat dalsi parametr.
- Mam dost ridkou tabulku, vetsina parametru je Nan, navazujici pymongo a pyplot jsou v pohode.
- Clovek muze nechat bezet stejne MongoDB na vice strojich najednou, cimz ma duplicitu a pojisteni proti vypadku (ale nezkousel jsem)
- ... a nakonec - MongoDB neni ta nejrychlejsi a nejlepsi NoSQL databaze na trhu.....
Takze tak. Minusy? Nenasel jsem zadnej skvelej program na udrzbu (jako mysql-workbench apod). Ale nechybi mi, na vsechno mam jeden skript.
Do třídy se dají na konec přidávat další metody bez rozbití kompatibility. Nevím, jestli je to teoreticky OK, ale prakticky to funguje. Samozřejmě, že to rozhodí metody přidané v odvozených třídách.Zrovna tohle je v C++ špatně navržené. ... Ale považuji za chybu, že privátní metody a proměnné jsou vidět v hlavičkovém souboru a co hůř, jejich změna rozbije binární kompatibilitu.
To jako fakt?! Hm, dobrá sračka...
Ono to má technický důvod. Ty struktury mají fixní velikost, takže se rozjedou pointer offsety pro přístup k atributům. Pokud to ABI musí být stabilní, je potřeba to rozdělit na stabilní "proxy" interface a privátní data s negarantovanou strukturou.
Jenže jak to udělat, abych mohl rozhraní rozšiřovat a nerozbil při tom binární kompatibilitu? I když mám čistě abstraktní/virtuální třídu, tak do ní nemohu jen tak přidat metodu.
Pro účely zpětné kompatibility se taky zavedly inline namespace. Překladač vidí všechny namespacy s číslem verze, takže manglované názvy jsou pořád stejné. Pokud se zvedne verze, tak se vytvoří nový namespace s vyšším číslem verze a ty předchozí se nechají být. A v headeru se do neverzovaného namespace nainlinuje ten s nejvyšší verzí, takže při překladu se automaticky používá nejnovější verze.
Pro účely zpětné kompatibility se taky zavedly inline namespace. Překladač vidí všechny namespacy s číslem verze, takže manglované názvy jsou pořád stejné. Pokud se zvedne verze, tak se vytvoří nový namespace s vyšším číslem verze a ty předchozí se nechají být. A v headeru se do neverzovaného namespace nainlinuje ten s nejvyšší verzí, takže při překladu se automaticky používá nejnovější verze.
Tohle mě zajímá. To jsi v reálu někde viděl? Kde?
namespace std { ... } tam je namespace std { inline namespace __1 { ... } } Celé je to ještě zabalené v makrech, jméno inline namespace __1 pochází z makra _LIBCPP_ABI_VERSION.
Do třídy se dají na konec přidávat další metody bez rozbití kompatibility. Nevím, jestli je to teoreticky OK, ale prakticky to funguje. Samozřejmě, že to rozhodí metody přidané v odvozených třídách.Zrovna tohle je v C++ špatně navržené. ... Ale považuji za chybu, že privátní metody a proměnné jsou vidět v hlavičkovém souboru a co hůř, jejich změna rozbije binární kompatibilitu.
To jako fakt?! Hm, dobrá sračka...
Ono to má technický důvod. Ty struktury mají fixní velikost, takže se rozjedou pointer offsety pro přístup k atributům. Pokud to ABI musí být stabilní, je potřeba to rozdělit na stabilní "proxy" interface a privátní data s negarantovanou strukturou.
Jenže jak to udělat, abych mohl rozhraní rozšiřovat a nerozbil při tom binární kompatibilitu? I když mám čistě abstraktní/virtuální třídu, tak do ní nemohu jen tak přidat metodu.
Interfacy verzovat a staré verze držet v původní podobě.
Pro účely zpětné kompatibility se taky zavedly inline namespace. Překladač vidí všechny namespacy s číslem verze, takže manglované názvy jsou pořád stejné. Pokud se zvedne verze, tak se vytvoří nový namespace s vyšším číslem verze a ty předchozí se nechají být. A v headeru se do neverzovaného namespace nainlinuje ten s nejvyšší verzí, takže při překladu se automaticky používá nejnovější verze.
Pokud někdo používá SQL + ORM, tak to k NoSQL přímo vybízí, protože ORM neskutečně degradují relační databáze. Zapomeňte na ORM. Pokud neumíte přemýšlet relačně, jděte do NoSQL.
Jednou z uplne prvnich databazi bylo IMS (a obcas se jeste pouziva), a ta uklada data (zaznamy) prave ve stromove strukture podle klice.
... Ale hlavni nevyhoda je, ze si musite vytvorit vlastni funkci (program), ktera ty zaznamy prochazi ...
ale to je také ta největší výhoda
Můžete to vysvětlit?
Ta výhoda spočívá v tom, že ty datové funkce jsou primitivní (rychleji už to nejde) a mají očekávanou odezvu, ať už jsou nasazeny v aplikačním programu kdekoliv. Programátor postupuje tedy tak, že vytváří primitivní aplikační funkce (kdy každá z nich si může obstarat potřebná data s max. možnou rychlostí), které kombinuje do komplexnějších celků. Změna v aplikaci se provádí záměnou jednoduchých aplikačních funkcí -říkejme tomu modularita.
Mozna te to prekvapi, ale to, co popisujes je state-of-the-art vyvoje informacnich systemu prvni poloviny devedesatych let minuleho stoleti. A ti z nas, kteri to zazili, vi, ze to nefunguje. [..]
Prave proto SQL databaze, kde je oddeleny logicky a fyzicky model dat, vyhraly nad primitivni manipulaci s daty, jakou ty popisujes.
Zrovna tohle je v C++ špatně navržené. ... Ale považuji za chybu, že privátní metody a proměnné jsou vidět v hlavičkovém souboru a co hůř, jejich změna rozbije binární kompatibilitu.
To jako fakt?! Hm, dobrá sračka...
Ta výhoda spočívá v tom, že ty datové funkce jsou primitivní (rychleji už to nejde) a mají očekávanou odezvu, ať už jsou nasazeny v aplikačním programu kdekoliv. Programátor postupuje tedy tak, že vytváří primitivní aplikační funkce (kdy každá z nich si může obstarat potřebná data s max. možnou rychlostí), které kombinuje do komplexnějších celků. Změna v aplikaci se provádí záměnou jednoduchých aplikačních funkcí -říkejme tomu modularita.
Ta výhoda spočívá v tom, že ty datové funkce jsou primitivní (rychleji už to nejde) a mají očekávanou odezvu, ať už jsou nasazeny v aplikačním programu kdekoliv. Programátor postupuje tedy tak, že vytváří primitivní aplikační funkce (kdy každá z nich si může obstarat potřebná data s max. možnou rychlostí), které kombinuje do komplexnějších celků. Změna v aplikaci se provádí záměnou jednoduchých aplikačních funkcí -říkejme tomu modularita.Jak už napsal Pavel Stěhule, obecně to není pravda - existují relační databáze, kde lze takto postupovat. Vesměs se ale jedná o historické kousky ztracené v propasti času, nebo různé malé pokusy. A jsou k tomu dobré důvody.
U relačních databází takto nelze postupovat.
Jednou z uplne prvnich databazi bylo IMS (a obcas se jeste pouziva), a ta uklada data (zaznamy) prave ve stromove strukture podle klice.
... Ale hlavni nevyhoda je, ze si musite vytvorit vlastni funkci (program), ktera ty zaznamy prochazi ...
ale to je také ta největší výhoda
Můžete to vysvětlit?
Jak už napsal Pavel Stěhule, obecně to není pravda - existují relační databáze, kde lze takto postupovat. Vesměs se ale jedná o historické kousky ztracené v propasti času, nebo různé malé pokusy. A jsou k tomu dobré důvody.
Popsaný způsob programování je v podstatě klasický procedurální, imperativní, vhodný pro počítače s von-Neumannovskou architekturou (nebo podobnou). Jak se ale během času ukázalo, to je pro relační databáze (a pravděpodobně pro databáze obecně) velmi nevhodná architektura, a proto všechny dnešní SQL databáze (a mnohé noSQL, záleží na typu a kusu) obsahují VM fungující na zcela jiném principu. Teoreticky by se daly programovat přímo (assembler == "query plan"), ale bylo by to velmi nepraktické, programátoři jsou prostě vycepovaní von Neumannem. Už takhle je pro začátečníka docela záhul query plan přečíst, instinktivně tam hledá tok programu :-)
Popsaný způsob programování je v podstatě klasický procedurální, imperativní, vhodný pro počítače s von-Neumannovskou architekturou (nebo podobnou). Jak se ale během času ukázalo, to je pro relační databáze (a pravděpodobně pro databáze obecně) velmi nevhodná architektura, a proto všechny dnešní SQL databáze (a mnohé noSQL, záleží na typu a kusu) obsahují VM fungující na zcela jiném principu. Teoreticky by se daly programovat přímo (assembler == "query plan"), ale bylo by to velmi nepraktické, programátoři jsou prostě vycepovaní von Neumannem. Už takhle je pro začátečníka docela záhul query plan přečíst, instinktivně tam hledá tok programu :-)
zde tak nějak nechápu, co jste chtěl sdělit. Jsou rel. databáze zlo, protože se musel hledat nějaký jiný způsob jejich programováni, aby to alespoň trochu fungovalo?
zde tak nějak nechápu, co jste chtěl sdělit. Jsou rel. databáze zlo, protože se musel hledat nějaký jiný způsob jejich programováni, aby to alespoň trochu fungovalo?Tak trochu polopatičtěji: relační databáze jsou dobro, protože se našel způsob jejich programování který funguje velmi dobře. Neexistuje žádná alternativa, která by umožňovala byť jen srovnatelnou automatizovanou optimalizaci. Na světě není dost programátorů kteří by implementovali všechny ty SQL dotazy co po celém světě běhají (a to ani když se omezíme na ty netriviální).
....Spousta programatoru pouziva databaze jen jako hloupe uloziste dat, na zacatku select * from, a na konci update/insert. A k vykonu asi toliko, ze vypocet mezd pro cca 100 lidi na i386 s nejakou tou lokalni databazi na lokalnim disku aplikaci bezici v DOSu ... byl velmi casto rychlejsi ( i radove) nez vypocet tehoz dnes, na HW disponujicim desitkami jader, stovkami GB ram a daty na na poli se stovkami tisic IOps.
zde tak nějak nechápu, co jste chtěl sdělit. Jsou rel. databáze zlo, protože se musel hledat nějaký jiný způsob jejich programováni, aby to alespoň trochu fungovalo?A ještě trochu jinak: tato diskuse je v podstatě stejná jako ta klasická "jaký má smysl C (nebo dokonce C++), když můžu psát v assembleru a bude to pořádně optimalizované?"
....Spousta programatoru pouziva databaze jen jako hloupe uloziste dat, na zacatku select * from, a na konci update/insert. A k vykonu asi toliko, ze vypocet mezd pro cca 100 lidi na i386 s nejakou tou lokalni databazi na lokalnim disku aplikaci bezici v DOSu ... byl velmi casto rychlejsi ( i radove) nez vypocet tehoz dnes, na HW disponujicim desitkami jader, stovkami GB ram a daty na na poli se stovkami tisic IOps.
Nejaka ta foxka by na soudobem HW musela doslova litat.
BTW: foxpro/dbase umoznovalo dotazovani do databaze uplne stejne (byt v jinem provedeni) jako libovolny SQL, zadny kod na ziskavani dat nebyl treba, ale z pohledu uzivatele je to uplne totez, bezny uzivatel nedostane data z foxpro, uplne stejne jako je nedostane z SQL. Proste proto, ze netusi jak by to mel udelat.
...Pominme to, ze by to neumelo vyuzit ramku ... vice jader ... to jsou detaily, ale i tak by to bezelo mnohonasobne rychlejs. I to jedno jadro je radove vykonejsi.
Pochybuji, že by Foxka byla na soudobém hw rychlejší - všechny optimalizace a figle...
Naprosto bezne se denne setkavam s tim, ze v aplikacich jsou do databazi selecty s joiny pres nenaindexovane a nejlepe textove pole, idealne jeste rekurzivni a pak se vsichni strasne divi, ze to dobehne ... za hodiny. Tohle kdyby nekdo udelal pred 20 lety, tak skonci obratem na dlazbe.
Dalsi zasadni problem byl v tom, ze uz pri navrhu systemu se muselo dobre pocitat s tim, jak se bude s daty pracovat a kolik jich bude. Nejednou jsem zazil situaci, kdy byl napriklad algoritmus pro nejakou uzaverku navrzen pro mnohem mensi mnozstvi dat, a pak se po par letech provozu ukazalo, ze vypocet trva den nebo dva.
Dalsi zasadni problem byl v tom, ze uz pri navrhu systemu se muselo dobre pocitat s tim, jak se bude s daty pracovat a kolik jich bude. Nejednou jsem zazil situaci, kdy byl napriklad algoritmus pro nejakou uzaverku navrzen pro mnohem mensi mnozstvi dat, a pak se po par letech provozu ukazalo, ze vypocet trva den nebo dva.To je divné, ty síťové a hierarchicke databáze maji predikovatelne odezvy a to jedine, co se s poctem dat zvysuje je prumerna doba vyhledani prvku v tom stromu a to se ridi podle tech znamych vzorecku s temi logaritmy.
Tenkrat predevsim programator vykon proste musel resit, byla to jeho primarni prace, nemoh splacat neco a spokojit se s tim, ze ono to nejak funguje. Ono to taky muselo fungovat pouzitelne rychle.Tak nějak naivně předpokládám, že tohle je normální i dneska.
zde tak nějak nechápu, co jste chtěl sdělit. Jsou rel. databáze zlo, protože se musel hledat nějaký jiný způsob jejich programováni, aby to alespoň trochu fungovalo?A ještě trochu jinak: tato diskuse je v podstatě stejná jako ta klasická "jaký má smysl C (nebo dokonce C++), když můžu psát v assembleru a bude to pořádně optimalizované?"
Kdybych se pokusi dosáhnout modularitu za pomoci RDBMS prostředků (tedy s deklarativním SQL jazykem), tak pak bych do sebemnší funkce zapsal nějaký select-statement. Taková funkce by formálně splňovala ten information hiding princip, prakticky je to ale nepoužitelné. Taková funkce může bý samozřejmě použita jakkoliv - tedy v nějaké smyčce se 100 tisic voláni. A v tu chvíli je to pomalé, nepoužitelné a tím jsme u té rychlosti , která zdánlivě zapříčiní ten problém s tou modularitou - ve skutečnosti je to ta SQL.
Tipoval bych, že Vám ani nevadí relační model, jako SQL.
Na stranu druhou - tento hard code přístup měl hodně strmou křivku učení,
ale musel jste počkat 2-3 dny, možná týden, než Vám programátor napsal report.
To je jeden z důvodů proč vzniklo SQL - efektivitu nikdo až tak moc neřešil, ale uživatelé přes terminál mohli mít data během několika minut.
To je jeden z důvodů proč vzniklo SQL - efektivitu nikdo až tak moc neřešil, ale uživatelé přes terminál mohli mít data během několika minut./quote]
Hnidopich NOTE.
SQL vzniklo v IBM jako nahrada za konkurencni dotazovaci jazyk QUEL od Stonebrakera (autor postgresu). SQL = SeQUEL to QUEL. Ten nakonec ve svych databazich nahradil quel sqlkem ne proto, ze bylo lepsi, ale ze bylo pouzivanejsi. To jen diky tomu, ze za nim stala IBM.
Doporucuju shlidnout nejaky video kde to Stonebraker vysvetluje. Treba jeho turing award speech.
aha, tak teď si myslím, že začínám chápat to nedorozumnění.
Takže, nejde o tu rychlost, jde jen a pouze o tu modularitu. Z hlediska modularity je assembler a C rovnocené řešení, protože mohu s oběma stejně dobře rozdělit problém na menší části. Jestliže ale začnu míchat imperativní jazyky s deklarativním dotazováním dat, nastane ten známý impedance missmatch a jeho výsledkem je, že mohu modularitu zapomenout.
Kdybych se pokusi dosáhnout modularitu za pomoci RDBMS prostředků (tedy s deklarativním SQL jazykem), tak pak bych do sebemnší funkce zapsal nějaký select-statement. Taková funkce by formálně splňovala ten information hiding princip, prakticky je to ale nepoužitelné. Taková funkce může bý samozřejmě použita jakkoliv - tedy v nějaké smyčce se 100 tisic voláni. A v tu chvíli je to pomalé, nepoužitelné a tím jsme u té rychlosti , která zdánlivě zapříčiní ten problém s tou modularitou - ve skutečnosti je to ta SQL.
SQL vzniklo v IBM jako nahrada za konkurencni dotazovaci jazyk QUEL od Stonebrakera (autor postgresu). SQL = SeQUEL to QUEL. Ten nakonec ve svych databazich nahradil quel sqlkem ne proto, ze bylo lepsi, ale ze bylo pouzivanejsi. To jen diky tomu, ze za nim stala IBM.
Doporucuju shlidnout nejaky video kde to Stonebraker vysvetluje. Treba jeho turing award speech.
Jasně, dnes jsou ty RDBMS to jediné, s čím je možné k zákazníkovi přijít. Přesto nechápu, jak mohli inženýři dovolit, aby se tak rozmohlo.
Mám zákazníka u kterého reporty trvají minuty, bo jsou napsány funkcionálně - což je to nejhorší, co může být.Registr vozidel? ;D
Registr vozidel to není :)Mám zákazníka u kterého reporty trvají minuty, bo jsou napsány funkcionálně - což je to nejhorší, co může být.Registr vozidel? ;D
Je to jedna z veci ktery pravidelne resim ... takze predpoklad je mylny. V nekterych pripadech sem schopnej jen zasahama do struktury dat zrychlit nektery operace o 3 rady. Cemuz nerikam optimalizace, to je prasecina tvurce. On to totiz ten dobytek na strane dodavatele, pokud vubec, tak otestuje na databazi o 10 zaznamech, a ani ve snu ho nenapadne, ze ta databaze tech zaznamu muze mit taky treba desitky milionu.Tenkrat predevsim programator vykon proste musel resit, byla to jeho primarni prace, nemoh splacat neco a spokojit se s tim, ze ono to nejak funguje. Ono to taky muselo fungovat pouzitelne rychle.Tak nějak naivně předpokládám, že tohle je normální i dneska.
...
...tam platí, co můžete udělat jednou hromadnou operací, tak byste měl udělat jednou hromadnou operací. ...A proto to spousta vsemoznych patlalu nedela. Moh bych ukazat desitky funci v ruznych aplikacich ktery nastavujou nejaky parametr na zaznamech, a delaji to ... po jednom zaznamu. A kdyz to nekdo stopne, tak to pekne po jednom rollbackuji. Takze to trva a trva a trva. Typicky to pak vypada zhruba tak, ze zamestnanci chodi za administratorem na tema "uz zas potrebuju spustit tuhle pitomost" a admin ma napsany nejaky query, ktery udela totez, jen za desetitisicinu casu.
A proto to spousta vsemoznych patlalu nedela. Moh bych ukazat desitky funci v ruznych aplikacich ktery nastavujou nejaky parametr na zaznamech, a delaji to ... po jednom zaznamu. A kdyz to nekdo stopne, tak to pekne po jednom rollbackuji. Takze to trva a trva a trva. Typicky to pak vypada zhruba tak, ze zamestnanci chodi za administratorem na tema "uz zas potrebuju spustit tuhle pitomost" a admin ma napsany nejaky query, ktery udela totez, jen za desetitisicinu casu.
Jeden priklad za vsechny, karta zbozi ma jako jeden z parametru novou cenu s platnosti od. System ma funkci na prepsani tyhle ceny (pokud uz plati) do aktualni ceny produktu. Ta funce je schopna pri desitkach tisic produktu bezet i nekolik hodin. Nacte si totiz vzdy jeden zaznam, ten aktualizuje a tak porad dokola. Update na vse do databaze dobehne v radu nekolika sekund.
Přiznám se, že nevím co si z tohohle příspěvku odnést. Jak se ta databáze vůbec používá? Jestli na veškerou údržbu stačí jeden script tak to IMO nezní moc komplikovaně.
Vysledne dojmy? : Uz bych nemenil.
- Zalozeni nove tabulky (tady collection) nevyzaduje zadnou specialni akci
- V pythonu je pymongo: ovladani se neda s mysql srovnavat, vsechno je jako DICT
- Pouzivam 100x intenzivneji nez kdysi mysql, takze mam kolem milionu zaznamu, zapisuji kazdych 10 sec. a nevidim latenci
- Menim tabulku za behu, proste zacnu pridavat dalsi parametr.
- Mam dost ridkou tabulku, vetsina parametru je Nan, navazujici pymongo a pyplot jsou v pohode.
- Clovek muze nechat bezet stejne MongoDB na vice strojich najednou, cimz ma duplicitu a pojisteni proti vypadku (ale nezkousel jsem)
- ... a nakonec - MongoDB neni ta nejrychlejsi a nejlepsi NoSQL databaze na trhu.....
Takze tak. Minusy? Nenasel jsem zadnej skvelej program na udrzbu (jako mysql-workbench apod). Ale nechybi mi, na vsechno mam jeden skript.
- O MySQL se běžně povídá, že je to spíš parodie na databázi. Rozhodně to není dobrý reprezentant toho, co SQL databáze umí.
- Jeden zápis za 10s (zápis čeho?) nemusí znamenat nic. 10 milionů záznamů taky nemusí být nic (pokud jsem to pochopil jako 10M záznamů celkem).
- A ty zásadní problémy s převodem dat zní jako hodně velké minus.
Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu ;D
IMO to vypadá jako hodně blbý nápad. Pokud nutně potřebuješ zaplnit log mraky záznamů, tak si ty upravené záznamy můžeš vytáhnout selectem. Ale fakt si nejsem jistý, co se dá z takového logu vykoukat, pokud je těch upravených záznamů víc než pár desítek.Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu ;Djak vypada ten update-statement, ktery soucasne pro kazdy zmeneny zaznam pise fprintf do nejakeho logfilu?
IMO to vypadá jako hodně blbý nápad. Pokud nutně potřebuješ zaplnit log mraky záznamů, tak si ty upravené záznamy můžeš vytáhnout selectem. Ale fakt si nejsem jistý, co se dá z takového logu vykoukat, pokud je těch upravených záznamů víc než pár desítek.
Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu ;D
jak vypada ten update-statement, ktery soucasne pro kazdy zmeneny zaznam pise fprintf do nejakeho logfilu?
Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu ;D
jak vypada ten update-statement, ktery soucasne pro kazdy zmeneny zaznam pise fprintf do nejakeho logfilu?
with x as (select * from foo where a between 7 and 10),
y as (update foo set b = foo.a + 10 from x where foo.a = x.a returning foo.*)
select 'before', x.* from x union all select 'after', y.* from y;
update ... returning *;
...ctu/pisu v ramci nektere definovane databaze do tabulky (collection)...
2/ nejvetsidatabazetabulkacollection ...
Dělám to - mám na to něco jako verzování.IMO to vypadá jako hodně blbý nápad. Pokud nutně potřebuješ zaplnit log mraky záznamů, tak si ty upravené záznamy můžeš vytáhnout selectem. Ale fakt si nejsem jistý, co se dá z takového logu vykoukat, pokud je těch upravených záznamů víc než pár desítek.
Např. se může udržovat historický log změn konkrétního "byznys" objektu. Kdo co kdy jak změnil. A nemusí to být do souboru, ale třeba do úplně jiné DB (např. zrovna to mongo).
Nevím, proč by to měla být jiná databázeNapř. proto, že pro ukládání nějakých logů nepotřebujete plýtvat prostorem na rychlých drahých malých discích, případně na to nepotřebujete vůbec plýtvat drahým výkonem relační databáze.
To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.Nejde jen o optimální SQL, jde také o strukturu dat. Jinak budete reálný svět modelovat pomocí grafu objektů a jinak pomocí relací.
To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
sum = 0
foreach a = collection_of_a()
if test(a) then
b = collection_of_b(a.b_id)
if test(b) then
sum += b.val
return sum
Není mi jasné, jak tohle dobré ORM zoptimalizuje, i když je jasné, že se to dá přepsat do jednoho SELECTu s JOINem dvou tabulek.
Za pravnika bych te nechtel ;DTo je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
Za pravnika bych te nechtel ;DTo je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
Kde jsem něco podobného už jenom slyšel... "Komunismus principiálně může v pohodě fungovat. Bohužel, zatím to všichni dělali blbě."To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
Jsi si jist, že za to může to ORM?To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
Připadá mi, že ORM svádí k programování ve stylu:Kód: [Vybrat]sum = 0Není mi jasné, jak tohle dobré ORM zoptimalizuje, i když je jasné, že se to dá přepsat do jednoho SELECTu s JOINem dvou tabulek.
foreach a = collection_of_a()
if test(a) then
b = collection_of_b(a.b_id)
if test(b) then
sum += b.val
return sum
Kde jsem něco podobného už jenom slyšel... "Komunismus principiálně může v pohodě fungovat. Bohužel, zatím to všichni dělali blbě."To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.
Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.
Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.
Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.
Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.
Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.
Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.Nechápu, co tenhle odstavec měl vyjadřovat. Jestli "oprostit od detailů práce z databází" znamená, že s databází komunikuju pomocí SQL, tak to nemá s ORM nic společného. Jestli to má znamenat, že díky deklarativnímu SQL se můžu oprostit od detailů použitím ORM, tak to není pravda.
V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.U DSL specializovaného pro nějakou konkrétní aplikaci jsem ochoten věřit, že to může generovat rozumné SQL. Ale pak to asi nebude obecně použitelné ORM.
Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.
Naopak. Díky deklarativnímu SQL se můžu oprostit od detailu uložení dat. Stejně tak nějak musím u inteligentního ORM psát deklarativně a poněkud obecně.Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.Nechápu, co tenhle odstavec měl vyjadřovat. Jestli "oprostit od detailů práce z databází" znamená, že s databází komunikuju pomocí SQL, tak to nemá s ORM nic společného. Jestli to má znamenat, že díky deklarativnímu SQL se můžu oprostit od detailů použitím ORM, tak to není pravda.
sum = 0
foreach a = collection_of_a()
if test(a) then
b = collection_of_b(a.b_id)
if test(b) then
sum += b.val
return sum
src.iters.filter(\a -> ...).b.iters.filter(\b -> ...).sum()
To aby ten LINQ "pochopil" co má udělat.Bylo to obecné DSL pro získávání obecných dat z ORM. Ale mělo to svá specifika a určitě i omezení.V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.U DSL specializovaného pro nějakou konkrétní aplikaci jsem ochoten věřit, že to může generovat rozumné SQL. Ale pak to asi nebude obecně použitelné ORM.
Nekešují se data, ale schema. Špatně jsem to popsal. Nejlépe osvětlí ukázka:Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
foreach ($users(10) as $user) {
echo $user->title;
foreach ($user->articles(10) as $article) {
echo $article->title;
foreach ($article->discuss(5) as $discuss) {
echo $discuss->title;
}
}
}
Při prvním průchodu to vytvoří 51 dotazů, při druhém už jen tři, protože si odvodí, že ty articles a discuss může sloučit.$sum = 0
foreach ($base->where(test_a) as $a) {
foreach ($a->where(test_b) as $b) {
$sum += $b->val;
}
}
return $sum;
Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
Viz můj následující příspěvek. Špatně jsem to popsal. Nejde o cache dat, ale o cache schematu. Nebo spíše logiky.Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.
Nekešují se data, ale schema. Špatně jsem to popsal. Nejlépe osvětlí ukázka:Kód: [Vybrat]foreach ($users(10) as $user) {
echo $user->title;
foreach ($user->articles(10) as $article) {
echo $article->title;
foreach ($article->discuss(5) as $discuss) {
echo $discuss->title;
}
}
}
Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.
Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.
Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.
Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.
Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.
Dotaz do cache přímo v aplikaci je mnohonásobně rychlejší než dotaz do cache v databázi (protože tam to velmi zpomaluje komunikace po síti). A i na to aby se aplikace opakovaně neptala na hodnoty které už má se dá využít právě cache v aplikaci.
Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.
Dotaz do cache přímo v aplikaci je mnohonásobně rychlejší než dotaz do cache v databázi (protože tam to velmi zpomaluje komunikace po síti). A i na to aby se aplikace opakovaně neptala na hodnoty které už má se dá využít právě cache v aplikaci.
A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?
Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.
Dotaz do cache přímo v aplikaci je mnohonásobně rychlejší než dotaz do cache v databázi (protože tam to velmi zpomaluje komunikace po síti). A i na to aby se aplikace opakovaně neptala na hodnoty které už má se dá využít právě cache v aplikaci.
A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?
A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?
Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...
Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.
A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?
Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...
Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.
A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?
Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...
Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.
Co když do té databáze zapisuje spousta aplikací zároveň? Pro mne je to velmi častý případ a nějaké zámky by mohly skončit i deadlockem.
Co když do té databáze zapisuje spousta aplikací zároveň?
...Správně používané zámky nikdy deadlockem neskončí....Fakt? Tak to bych chtel videt jak udelas ... fakt bych chtel videt, jak vyresis to, ze dva uzivatele/aplikace/... hodlaji poslat update na stejny zaznam. Nechas je to udelat oba? Pekne potichu?
...Správně používané zámky nikdy deadlockem neskončí....Fakt? Tak to bych chtel videt jak udelas ... fakt bych chtel videt, jak vyresis to, ze dva uzivatele/aplikace/... hodlaji poslat update na stejny zaznam. Nechas je to udelat oba? Pekne potichu?
Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.
Co když do té databáze zapisuje spousta aplikací zároveň?
Ještě jednou - Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Přímo do DB jen při shozené aplikaci nebo při startu, kdy ještě nemá keš inicializovanou (děláme tak větší updaty DB). Je jenom jedna RW keš. Opakuji - má to výhody i nevýhody. U nás převažují výhody, proto to takhle používáme.
Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.
Já myslel, že se tady bavíme o ORM jako o programovací technice, ne o tom, že v reálu si ORM frameworky jen s ORM přístupem nevystačí a musí k tomu přilepit funkčnost, která už nemá s ORM prakticky nic společného a která zcela zásadně narušuje tu úroveň abstrakce, na které pracuje ORM.
Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.
Já myslel, že se tady bavíme o ORM jako o programovací technice, ne o tom, že v reálu si ORM frameworky jen s ORM přístupem nevystačí a musí k tomu přilepit funkčnost, která už nemá s ORM prakticky nic společného a která zcela zásadně narušuje tu úroveň abstrakce, na které pracuje ORM.
OK, jako čistý koncept je ORM dost omezené. Ale v praxi to lze docela snadno řešit, takže to moc nevadí.
Jo, v praxi se to ojebává právě tím, že se tomu pořád říká ORM framework, ale půlka ho není ORM, ale nějaké přibastlené extra API, aby se přes to dalo s tou databází jakž takž pracovat jako s databází.Pro tento abstraktní koncept existuje dokonce i termín, ale bohužel dnes velmi politicky nekorektní:
Jo, v praxi se to ojebává právě tím, že se tomu pořád říká ORM framework, ale půlka ho není ORM, ale nějaké přibastlené extra API, aby se přes to dalo s tou databází jakž takž pracovat jako s databází.
Jo, v praxi se to ojebává právě tím, že se tomu pořád říká ORM framework, ale půlka ho není ORM, ale nějaké přibastlené extra API, aby se přes to dalo s tou databází jakž takž pracovat jako s databází.
Na ORM je tedy nejlepší to, co není součástí ORM.
Nejde jen o optimální SQL, jde také o strukturu dat. Jinak budete reálný svět modelovat pomocí grafu objektů a jinak pomocí relací.
Připadá mi, že ORM svádí k programování ve stylu:Kód: [Vybrat]sum = 0Není mi jasné, jak tohle dobré ORM zoptimalizuje, i když je jasné, že se to dá přepsat do jednoho SELECTu s JOINem dvou tabulek.
foreach a = collection_of_a()
if test(a) then
b = collection_of_b(a.b_id)
if test(b) then
sum += b.val
return sum
Nejde jen o optimální SQL, jde také o strukturu dat. Jinak budete reálný svět modelovat pomocí grafu objektů a jinak pomocí relací.Jasně, ale pak přichází otázka, jestli je vhodné reálný svět ukládat do RDB, když budu muset nutně někde udělat docela komplikovaný překlad.
Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů.
Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze.
Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.
Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.Nechápu, co tenhle odstavec měl vyjadřovat. Jestli "oprostit od detailů práce z databází" znamená, že s databází komunikuju pomocí SQL, tak to nemá s ORM nic společného. Jestli to má znamenat, že díky deklarativnímu SQL se můžu oprostit od detailů použitím ORM, tak to není pravda.
V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.U DSL specializovaného pro nějakou konkrétní aplikaci jsem ochoten věřit, že to může generovat rozumné SQL. Ale pak to asi nebude obecně použitelné ORM.
Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
ORM se lidi casto uci s tim, ze jim to usnadni pristup do DB oproti SQL. Bohuzel to tak neni, ve vysledku se budete muset to SQL (a hlavne relacni mysleni, jak pise pan Stehule, ja bych k tomu dodal jeste transakcni mysleni) stejne naucit, takze ORM vam v tom uceni bude jen prekazet. Predstava, ze se snaz naucite databaze prostrednictvim ORM, pokud uz umite OOP, je proste velky omyl.
Mě se docela líbí taková ta úplně lehká ORM jako třeba http://javalite.io/activejdbc#design-principles, akorát mě tam štve ten zápis sloupců jako string (dá se řešit tím, že si člověk napíše gettery a settery ručně).
A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?
Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...
Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.
Co když do té databáze zapisuje spousta aplikací zároveň? Pro mne je to velmi častý případ a nějaké zámky by mohly skončit i deadlockem.
ORM se lidi casto uci s tim, ze jim to usnadni pristup do DB oproti SQL. Bohuzel to tak neni, ve vysledku se budete muset to SQL (a hlavne relacni mysleni, jak pise pan Stehule, ja bych k tomu dodal jeste transakcni mysleni) stejne naucit, takze ORM vam v tom uceni bude jen prekazet. Predstava, ze se snaz naucite databaze prostrednictvim ORM, pokud uz umite OOP, je proste velky omyl.
Ty překlady do relační databáze bývají jednodušší, než se na první pohled zdá.
Zajímavá je otázka, co se děje, když nekdo přistoupí na vaše doporučení a naučí se myslet jak požadujete a programuje v nejakém OO jazyce za použití rel.databaze s SQL. Podle mých zkušeností je nejlepší dopoledne psát ten program a odpoledne k tomu dodělat ty selecty. A samozrejmě je třeba po pracovní době přepnout do toho procedurálního myšlení, aby člověk nazapomněl vystoupit na správné stanici z tramvaje.
Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde - někak se ty relace musejí měnit na objekty a naopak, a to bez ohledu na realizaci. Ano, nemusíte používat knihovní ORM, pak si překlady musíte udělat sami, ale to je právě to ORM. A nebo se na ORM vyserete a povedete model v aplikaci v n-ticích či samostatných hodnotách, to ale nemá s OOP nic společného.
Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde - někak se ty relace musejí měnit na objekty a naopak, a to bez ohledu na realizaci. Ano, nemusíte používat knihovní ORM, pak si překlady musíte udělat sami, ale to je právě to ORM. A nebo se na ORM vyserete a povedete model v aplikaci v n-ticích či samostatných hodnotách, to ale nemá s OOP nic společného.
Zní to jako řešení na hovno - platí, že čím víc toho čtu a držím navíc, tím je to 1. náročnější na zdroje, 2. musím řešit více synchronizace.
Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde
Mohl bi mi autor tohoto vlákna vysvětlit jakým způsobem by chtěl ukládat data typická pro transakční databáze?
tzn. vložím záznam, který má řekněme 30 sloupců, a pak s daty rovněž pracuji na úrovni záznamů (tj, žádné OLAP kostky nebo column based transakce)
...
Jedna z tech "jinych" veci, kterou zmini je ve strucnosti(asi od 54 minuty):
"Tabulkove databaze vznikly kvuli pomalym rotacnim diskum a v dnesni dobe kdy mame velka a rychla SSD ztraci smysl"
Mluvi o tom, ze tabulkove usporadani dat je pro programatory nepohodlne a ze stejne vetsinou z databaze data nacteme a vyrobime si z nich nejake stromy atp. se kterymi se nam dobre pracuje.
Dokonce rika: "If I were a database company right now, if I were Oracle, i'd be scared to death."
...
Stryka Boba(kdyz odhlednu od politiky) respektuju, ale tady vaham.
Nezda se mi, ze by mel pravdu, ale na druhou stranu nenachazim argument ktery by sel proti te jeho uvaze.
Tak se chci zeptat:
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?
Diky za nazory
kde maji 1TB ram. Dovedete si predstavit kolik takovy hardware musis stat.
Dovedl bych si představit mixovanou DB, kde si budu moct zvolit, zda do "tabulky" budu ukládat klasické řádky nebo objekty definované nějak složitěji jako strom (interně ať si to uloží jak chce).
A dotaz by buď vracel klasický plochý result (tabulku), nebo seznam objektů (nebo spíš jejich properties) filtrovaný přes klasický SQL dotaz podle jejich properties.
Neznam jedine ERP ktere pouziva NoSQL/dokumentovou/objektovou databazi.
Mohl bi mi autor tohoto vlákna vysvětlit ...
Dovedl bych si představit mixovanou DB, kde si budu moct zvolit, zda do "tabulky" budu ukládat klasické řádky nebo objekty definované nějak složitěji jako strom (interně ať si to uloží jak chce).
A dotaz by buď vracel klasický plochý result (tabulku), nebo seznam objektů (nebo spíš jejich properties) filtrovaný přes klasický SQL dotaz podle jejich properties.
ze je otrava a zbytecnost vytahavat data z relacni databaze pomoci nejakyho DSL, abyste z toho ziskali hash-mapu, ktera v podstate odpovida nativnim strukturam v ruznych NO / NEW SQL databazich.
Zkouší se GraphQL, ale zda je to ono, to se neodvažuji posoudit.Tohle tady nepadlo poprvé, takže raději k tomu něco napíšu.
Jinými slovy: v porovnání s SQL máte v GraphQL jen prosté sloupečky a (outer) joiny. Žádný WHERE nebo ORDER (natož pak GROUP BY).Jsem si toho vědom. Nemám s tím problém.
GraphQL není nic jako "SQL pro grafové databáze" a celkově vůbec nic srovnatelného s SQL.
GraphQL není nic jako "SQL pro grafové databáze" a celkově vůbec nic srovnatelného s SQL.
Mozna autor myslel SPARQL, to je tusim pro grafove databaze. S GraphQL se mi to taky plete.
Jinými slovy: v porovnání s SQL máte v GraphQL jen prosté sloupečky a (outer) joiny. Žádný WHERE nebo ORDER (natož pak GROUP BY).
Jinými slovy: v porovnání s SQL máte v GraphQL jen prosté sloupečky a (outer) joiny. Žádný WHERE nebo ORDER (natož pak GROUP BY).
Ano, v jazyku GraphQL pre to neexistuje specificky konstrukt.., ale v zavislosti od toho, ku akej databaze sa pripajas, si od nej mozes vediet vypytat vyfiltrovane, zoradene, alebo agregovane data...,
niektori ludia by povedali, ze v tom je krasa graphql, ze je take jednoduche.., ini ludia sa naucia graphql, lebo musia, a potom su zhrozeni, ked ho chcu pouzit s niecim inym :D
Cachovanie je dobra vec na rozne ciselniky ktore sa nemenia casto. Robit 300 sql requestov v jednom http requeste aby som zobrazil jednu tabulku, to je taky php pristup, ale inak totalna kravina. Ohladom platnosti dat, kazda normalna DB vie posielat eventy.
Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde - někak se ty relace musejí měnit na objekty a naopak, a to bez ohledu na realizaci. Ano, nemusíte používat knihovní ORM, pak si překlady musíte udělat sami, ale to je právě to ORM. A nebo se na ORM vyserete a povedete model v aplikaci v n-ticích či samostatných hodnotách, to ale nemá s OOP nic společného.
Jestli to nebude tim, ze proste na modelovani globalne konzistentnich dat (= splnujicich globalne nejakou podminku) neni OOP prilis vhodne.
Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde - někak se ty relace musejí měnit na objekty a naopak, a to bez ohledu na realizaci. Ano, nemusíte používat knihovní ORM, pak si překlady musíte udělat sami, ale to je právě to ORM. A nebo se na ORM vyserete a povedete model v aplikaci v n-ticích či samostatných hodnotách, to ale nemá s OOP nic společného.
Jestli to nebude tim, ze proste na modelovani globalne konzistentnich dat (= splnujicich globalne nejakou podminku) neni OOP prilis vhodne.
OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.
OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.Tuším nějakou Kitovinu :-) Ale můžeš to trochu rozvést? A nevím co je DM, AD.
Jestli to nebude tim, ze proste na modelovani globalne konzistentnich dat (= splnujicich globalne nejakou podminku) neni OOP prilis vhodne.
OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.
OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.Active record je pouze prostředkem uvnitř ORM, samotné ORM jej nevyžaduje. Mimoto objektový model nijak neovlivňuje.
Co má s OOP společného mít data v kolekcích a ne v objektech (sic!) a ActiveRecord či DataMapper? Zřejmě jen jel volnou asociaci, stejně jako ty.OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.Active record je pouze prostředkem uvnitř ORM, samotné ORM jej nevyžaduje. Mimoto objektový model nijak neovlivňuje.
Co s tím má společného ORM?
Co má s OOP společného mít data v kolekcích a ne v objektech (sic!) a ActiveRecord či DataMapper? Zřejmě jen jel volnou asociaci, stejně jako ty.Co s tím má společného ORM?OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.Active record je pouze prostředkem uvnitř ORM, samotné ORM jej nevyžaduje. Mimoto objektový model nijak neovlivňuje.
Jestli to nebude tim, ze proste na modelovani globalne konzistentnich dat (= splnujicich globalne nejakou podminku) neni OOP prilis vhodne.
Vysvětlete prosím to "globálně konzistentní", nikdy jsem toto spojení neslyšel, mimoto vůbec netuším, co by to mohlo znamenat.
Ahoj,Kdyz potrebujete vykopat opravdu velkou diru je bagr fajn, kdyz chcete vyhloubit jamku pro jeden stromek je preprava bagru na zahradu a hloubeni trosku neefektivni. ;-) Navic Oracle je napriklad hodne robustni software na urcite ukoly, ostatni SQL databaze at si rikda kdo chce co chce se mu proste nevyrovnaji, na druhou stranu si Oracle nechava brutalne zaplatit.
nedavno(a dneska znova, abych to nasel) jsem koukal na povidani strycka Boba o S.O.L.I.D. principles:
https://www.youtube.com/watch?v=t86v3N4OshQ (https://www.youtube.com/watch?v=t86v3N4OshQ)
Vetsinu casu povida o jinych vecech, ale poutave takze dopurucuji.
Jedna z tech "jinych" veci, kterou zmini je ve strucnosti(asi od 54 minuty):
"Tabulkove databaze vznikly kvuli pomalym rotacnim diskum a v dnesni dobe kdy mame velka a rychla SSD ztraci smysl"
Mluvi o tom, ze tabulkove usporadani dat je pro programatory nepohodlne a ze stejne vetsinou z databaze data nacteme a vyrobime si z nich nejake stromy atp. se kterymi se nam dobre pracuje.
Dokonce rika: "If I were a database company right now, if I were Oracle, i'd be scared to death."
To video je 3 roky stare a ja porad vidim jak se na novych projektech Oracle nasazuje.
Vim, ze minimalne v korporatech se tabulkove databaze udrzi jeste dlouho.
Stryka Boba(kdyz odhlednu od politiky) respektuju, ale tady vaham.
Nezda se mi, ze by mel pravdu, ale na druhou stranu nenachazim argument ktery by sel proti te jeho uvaze.
Tak se chci zeptat:
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?
Diky za nazory
Co má s OOP společného mít data v kolekcích a ne v objektech (sic!) a ActiveRecord či DataMapper? Zřejmě jen jel volnou asociaci, stejně jako ty.Co s tím má společného ORM?OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.Active record je pouze prostředkem uvnitř ORM, samotné ORM jej nevyžaduje. Mimoto objektový model nijak neovlivňuje.
Když je to DataMapper, tak přece nemapuji objekty, ale data.
Data mapper Podle tohoto vzoru neobsahuje doménový objekt žádné CRUD nebo vyhledávací operace a o vytváření, úpravu a mazání doménových objektů z databáze se stará oddělený (mapovací) objekt. Doménový objekt je tedy zcela nezávislý na databázi. Zatímco mapovací objekt má přístup jak k doménovému objektu, tak k databázovému systému. Výhodou tohoto vzoru je právě nezávislost doménového objektu na datovém modelu, kdy je veškerá zodpovědnost za persistenci přesunuta na mapovací objekt.
https://cs.wikipedia.org/wiki/Data_Mapper
CitaceData mapper Podle tohoto vzoru neobsahuje doménový objekt žádné CRUD nebo vyhledávací operace a o vytváření, úpravu a mazání doménových objektů z databáze se stará oddělený (mapovací) objekt. Doménový objekt je tedy zcela nezávislý na databázi. Zatímco mapovací objekt má přístup jak k doménovému objektu, tak k databázovému systému. Výhodou tohoto vzoru je právě nezávislost doménového objektu na datovém modelu, kdy je veškerá zodpovědnost za persistenci přesunuta na mapovací objekt.
https://cs.wikipedia.org/wiki/Data_Mapper
Ve výsledku mi Tvůj příspěvek nedává moc smysl (netuším, jak jsi to myslel).
Přičemž kolekce není objektem? DataMapper nemapuje objekty? ActiveRecord nemapuje objekty? Problém ArctiveRecordu přeci není v mapování objektů, či kolekcí. A výhoda DataMapperu není v tom, že je to modernější. Věci mají svůj důvod a význam.CitaceData mapper Podle tohoto vzoru neobsahuje doménový objekt žádné CRUD nebo vyhledávací operace a o vytváření, úpravu a mazání doménových objektů z databáze se stará oddělený (mapovací) objekt. Doménový objekt je tedy zcela nezávislý na databázi. Zatímco mapovací objekt má přístup jak k doménovému objektu, tak k databázovému systému. Výhodou tohoto vzoru je právě nezávislost doménového objektu na datovém modelu, kdy je veškerá zodpovědnost za persistenci přesunuta na mapovací objekt.
https://cs.wikipedia.org/wiki/Data_Mapper
Ve výsledku mi Tvůj příspěvek nedává moc smysl (netuším, jak jsi to myslel).
Doménovým objektem je jednoduše kolekce.
CitaceData mapper Podle tohoto vzoru neobsahuje doménový objekt žádné CRUD nebo vyhledávací operace a o vytváření, úpravu a mazání doménových objektů z databáze se stará oddělený (mapovací) objekt. Doménový objekt je tedy zcela nezávislý na databázi. Zatímco mapovací objekt má přístup jak k doménovému objektu, tak k databázovému systému. Výhodou tohoto vzoru je právě nezávislost doménového objektu na datovém modelu, kdy je veškerá zodpovědnost za persistenci přesunuta na mapovací objekt.
https://cs.wikipedia.org/wiki/Data_Mapper
Ve výsledku mi Tvůj příspěvek nedává moc smysl (netuším, jak jsi to myslel).
Doménovým objektem je jednoduše kolekce.
Doménovým objektem je jednoduše kolekce.Přičemž kolekce není objektem? DataMapper nemapuje objekty? ActiveRecord nemapuje objekty? Problém ArctiveRecordu přeci není v mapování objektů, či kolekcí. A výhoda DataMapperu není v tom, že je to modernější. Věci mají svůj důvod a význam.
OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.Active record je pouze prostředkem uvnitř ORM, samotné ORM jej nevyžaduje. Mimoto objektový model nijak neovlivňuje.
Co s tím má společného ORM?
Když je to DataMapper, tak přece nemapuji objekty, ale data.
Jestli to nebude tim, ze proste na modelovani globalne konzistentnich dat (= splnujicich globalne nejakou podminku) neni OOP prilis vhodne.
Vysvětlete prosím to "globálně konzistentní", nikdy jsem toto spojení neslyšel, mimoto vůbec netuším, co by to mohlo znamenat.
Znamena to to, co je tam napsano. :) (Pro informaci: Ze je neco v zavorce neznamena, ze se to nema cist.) Pokud s temi "objekty" chceme pracovat jako s kolekci, ktera splnuje nejakou podminku, napriklad unikatnost klicu. Nebo chceme zarucit ACID vlastnosti pro transakce. Relace v databazich proste neni "jen" soubor objektu.
Alan Kay si predstavoval OOP analogicky biologickym systemum, ze jde o vzajemnou komunikaci soucasti, ktere si jinak hledi sveho. Ty typicky takove globalni vlastnosti nesplnuji (vyjimkou jsou fyzikalni zakony zachovani).
ActiveRecord vs. Data Mapper se liší v tom, kde je zapouzdřená kompetence za persistenci - zda spolu s daty (v objektu reprezentujícím data z business domény) anebo bokem (v data mapperu). Některá ORM umožňují použít oba přístupy (vybrat si, kterému dám přednost). Viz.:
Když je to DataMapper, tak přece nemapuji objekty, ale data.Samozřejmě, protože RDB objekty neumí, takže to chování musíte zadrátovat odděleně do aplikace. Objekt se pak při rekonstrukci v aplikaci skládá z toho chování z aplikace a těch dat namapovaných z RDB.
ActiveRecord vs. Data Mapper se liší v tom, kde je zapouzdřená kompetence za persistenci - zda spolu s daty (v objektu reprezentujícím data z business domény) anebo bokem (v data mapperu). Některá ORM umožňují použít oba přístupy (vybrat si, kterému dám přednost). Viz.:Když se dívám na definici Active Recordu od Fowlera (https://www.martinfowler.com/eaaCatalog/activeRecord.html), musím se omluvit - myslel jsem, že je použit pouze jako mechanismus pro podržení mapované relace z RDB pro potřeby jednoduchého zápisu (v podstatě kopie relace), tj. objekt pro potřeby mapovače. Je to mnohem horší, má to být přímo doménový objekt. To je samo o sobě nesmysl, protože 1. neodděluje OM od RDB, 2. umožňuje mapování pouze primitivních objektů, které se vejdou do 1 relace (v praxi ne moc časté). Nenapadlo mě, že by se to někdo vůbec pokusil použít. Moje chyba.
Doménovým objektem je jednoduše kolekce.
RDB objekty umí - zvládá data včetně chování, s určitými omezeními. Jen se to musí umět. Cílem je rozdělit kompetence mezi RDB a jeho aplikace tak, aby celek byl robustní a konzistentní. Přidání další aplikace do takového systému pak nepředstavuje významný problém.
Není to tak špatné, jak to na první pohled vypadá.
1. Není nutné oddělovat OM od RDB
2. Umožňuje to mapování nejen primitivních, ale i komplexních objektů, které se skládají z mnoha relací
3. Co třeba strom?
Doménovým objektem je jednoduše kolekce.Nevím, jak to souvisí s Data Mapperem, ale kolekce vůbec nemusí být doménovým objektem. Obecně (bez ohledu na skutečnost, zda má objekt položky pojmenované (běžný objekt) či indexované (seznam)) platí, že doménový objekt je ten, který patří do domény, neboli modelovaného problému, pak je obvykle i ukládaný. Naopak při výpočtech v doméně se používá mnoho objektů (včetně seznamů), které do domény nepatří a po dokončení výpočtu zaniknou.
Seznam je mimochodem strukturou, kterou RDB neumí samostatně uložit (RDB koneckonců neumí často samostatně uložit ani objekt), což je jedním z problémů, které řeší ORM.
Není to tak špatné, jak to na první pohled vypadá.
1. Není nutné oddělovat OM od RDB
2. Umožňuje to mapování nejen primitivních, ale i komplexních objektů, které se skládají z mnoha relací
3. Co třeba strom?
1. Není, ale pak vám struktura RDB a jakékoliv její změny přeteče do domény v aplikaci s následnou nutností (hluboce) upravovat a výpočty podřizovat její struktuře. O konečné pro výměnu persistentní vrstvy (která už není vrstvou, ale součástí), tj. nejen např. více zdrojů, webovou službu místo DB, nebo jiný typ DB, ale dokonce jen jiná RDB(!!!), se doufám nemusím rozepisovat. Tento přístup jsem zažil v jedné nejmenované, velké, české firmě, tam to teda ještě dotáhli do extrému tak, že Active Record byl pouhým recordem (tj. holá data bez chování, v lepším případě se používal anemický datový model, v horším se to do recordu praskalo pokaždé extra) a komboboxy v GUI si načítaly data pomocí SQL z RDB.
Ne, tohle není ani OOP, ani koncepční přístup (přestože si to mnoho lidí z IT myslí).
2. Jak, když AR je (z definice) jedna relace na jeden (rádoby)doménový objekt???
3. Co je se stromem?
Aha, takže jste měl na mysli globálně unikátní, to je ale váš vyjadřovací problém.
Měl jste asi na mysli tabulky, ne relace.
Doménovým objektem je jednoduše kolekce.Nevím, jak to souvisí s Data Mapperem...
...Doménovým objektem může být i kolekce, proto ji k tomuto účelu používám. Jen se to některým vývojářům nelíbí, protože to nemá gettery a settery, které by však byly v uvedeném případu zbytečné a komplikující.
Odkdy má seznam indexované položky? U seznamu je definováno pouze jejich pořadí. Používání indexů v souvislosti se seznamy je cestou do pekel.
Seznam ukládám přes jeden prepared statement, za kterým hrnu data. To jsou 4 řádky mého ORM. Ovšem ukládání seznamů do databáze není zas tak časté, jak by se mohlo zdát. Kolekce i objekty je možné snadno uložit do RDB, pokud jsou serializovány.
1. Bez problémů měním strukturu RDB, aniž bych musel upravovat aplikaci. Dobře napsaná aplikace se tomu sama přizpůsobí.
2+3. Právě ten strom je ukázkou jednoho objektu, který se může skládat z mnoha relací.
Aha, takže jste měl na mysli globálně unikátní, to je ale váš vyjadřovací problém.
Nemel jsem na mysli jen tohle, to je jeden z prikladu takove vlastnosti. Rozmysli si, jestli chces nejdriv pochopit co rikam nebo to rozporovat.
Jiny priklad je treba globalni omezeni nejakeho zdroje, treba pocet vlaken nebo file descriptoru. V OOP se tohle modeluje blbe, protoze objektum obecne nemluvime do toho, jak jsou vnitrne implementovane.
CitaceMěl jste asi na mysli tabulky, ne relace.
...Jde o to, ze v OOP se objekty o ostatni objekty nemusi (a nemaji) starat, ale v relacnim modelu dat je schema globalni. Takze globalni podminky na vsechny objekty (urciteho druhu) se v OOP vynucuji obtizne, kdezto v relacnim modelu je to pomerne snadne. Ovsem za cenu, totiz ze se porusi encapsulation - schema musi kompletne videt do vsech tabulek.
Je treba si uvedomit, ze oboji ma svoje vyhody a nevyhody. Ale plynou z toho problemy pri prechodu od jednoho modelu ke druhemu. Ostatne, myslim, ze tenhle clanek uz vsechny tyto problemy (a mnohe dalsi) popsal: http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ (http://blogs.tedneward.com/post/the-vietnam-of-computer-science/)
Doménovým objektem je jednoduše kolekce.Nevím, jak to souvisí s Data Mapperem...
...Doménovým objektem může být i kolekce, proto ji k tomuto účelu používám. Jen se to některým vývojářům nelíbí, protože to nemá gettery a settery, které by však byly v uvedeném případu zbytečné a komplikující.
Nelíbí se mi ten otočený způsob uvažování. Lépe: Dom. objektem může být jakýkoliv objekt, takže i seznam.
Pravidlo o zapouzdření platí (opět) pro jakýkoliv objekt, tedy i pro seznam. Seznam bez zapouzdření je tedy z pohledu OOP chybou.
Odkdy má seznam indexované položky? U seznamu je definováno pouze jejich pořadí. Používání indexů v souvislosti se seznamy je cestou do pekel.Pochopitelně se tím myslí vnitřní reprezentace, čímž jsem chtěl ukázat, že seznam není ničím jiným než objektem, který má místo pojmenovaných položek číslované položky, a to bez ohledu na to, zda je s pořadím, bez pořadí, s řazením či jiný.
Seznam ukládám přes jeden prepared statement, za kterým hrnu data. To jsou 4 řádky mého ORM. Ovšem ukládání seznamů do databáze není zas tak časté, jak by se mohlo zdát. Kolekce i objekty je možné snadno uložit do RDB, pokud jsou serializovány.
Vizte výše - seznam je objekt jako každý jiný, proto by se mechanismus pro vyvolání uložení neměl nijak lišit. Samozřejmě musí mít identitu mapovatelnou do RDB (nějaký jedinečný identifikátor). Jinou otázkou je rozklad seznamu do tabulek na straně RDB, to je dost jiná liga, obzvláště u heterogenních seznamů. Zrovna serializace (předpokládám binární) způsobuje nemožnost deserializace při změně struktury v doméně a nemožnost vyhledávání v RDB, takže nic moc.
1. Bez problémů měním strukturu RDB, aniž bych musel upravovat aplikaci. Dobře napsaná aplikace se tomu sama přizpůsobí.
2+3. Právě ten strom je ukázkou jednoho objektu, který se může skládat z mnoha relací.
1. Jak to přizpůsobení probíhá? Je tam nějaký adaptivní mechanismus nebo umělá inteligence?
2., 3. Nenacházím žádnou souvislost mezi strukturou stromu a relace, vysvětlete to prosím.
O vnitřní reprezentaci se nebavíme, nehledě k tomu, že vnitřní reprezentace seznamu obvykle ani indexy nemají. Indexy u seznamu ani nejsou potřebné, resp. jejich používání porušuje zapouzdření.
Mezi OOP a RDB musí být vložena mezivrstva. Ta může být v aplikaci nebo v databázi, případně vhodně rozdělena mezi ně tak, aby bylo co nejjednodušší a přitom robustní API. Pro umístění v databázi hovoří zejména fakt, že už má svou cache, takže není třeba dělat v OOP nějaké náhražky.
Adaptivní mechanismus je jednoduchý: Aplikace se nespoléhá na to, že dostane co chce, ale analyzuje výsledek z RDB a ten zpracuje. Vazba je tedy adaptivní, opírá se o jednoduché a neměnné API.
Každý element stromu je relací. Strom je kolekcí, tedy i objektem.
O vnitřní reprezentaci se nebavíme, nehledě k tomu, že vnitřní reprezentace seznamu obvykle ani indexy nemají. Indexy u seznamu ani nejsou potřebné, resp. jejich používání porušuje zapouzdření.
Naopak, pole je pro implementaci seznamu výhodné, koneckonců když se implementace přesune níže do primitiv, stejně z toho nejspíš vyjde pole.
Když je to vnitřní reprezentace, tak se indexy ven nedostanou.
Mezi OOP a RDB musí být vložena mezivrstva. Ta může být v aplikaci nebo v databázi, případně vhodně rozdělena mezi ně tak, aby bylo co nejjednodušší a přitom robustní API. Pro umístění v databázi hovoří zejména fakt, že už má svou cache, takže není třeba dělat v OOP nějaké náhražky.Ona mezivrstva s mapovačem musí být stejně v aplikaci, protože jediná z těch 2 umí manipulovat s objekty i n-ticemi, pro RDB jsou objekty jaksi cizí, takže nemá jak ony objekty poskytovat (třeba v JSONech nebo já nevím v čem).
Adaptivní mechanismus je jednoduchý: Aplikace se nespoléhá na to, že dostane co chce, ale analyzuje výsledek z RDB a ten zpracuje. Vazba je tedy adaptivní, opírá se o jednoduché a neměnné API.
Takže tam už nějaké mapování je, není to jednoduchá kopie 1:1.
Každý element stromu je relací. Strom je kolekcí, tedy i objektem.Supr, a teď mi popište, jak se takový strom prochází.