Mají tabulkové databáze v dnešní době smysl?

[Xxxxxx]

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.

[Reklama]

[Někdo]

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.

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í.

[Franta <xkucf03/>]

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

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?

Zrovna tohle je v C++ špatně navržené. Ano, jde to obejít ("pimpl" idiom nebo čistě abstraktní/virtuální třídy + vytváření instancí přes tovární metodu místo přes konstruktor). 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.

Chápu, že za tím jsou zase nějaké implementační důvody jako u všeho "divného" v C++, ale z hlediska programátora se to prostě blbě používá -- resp. nakonec se to nějak dá, ale pracuje se s tím hůř než třeba v té Javě (i když nepopírám, že C++ má oproti ní zase jiné výhody).

[Linus]

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í.
};


A kde je to skrytí? Že se všechny interní atributy a funkce spojí do jediného NEskrytého prvku a všechno ostatní ve třídě se zkomplikuje? Tento trik je tady od začátku C++ a samozřejmě to moc neskrývá, prostě jen trik na obejití "céčkoidní" vlastnosti C++.

[bck]

Tak Pavla Stěhule bych se zastal, ten tomu aspoň rozumí a dá se s ním bavit.

souhlas, jestli má výpověď měla vyvolat opačný pocit, tak se omlouvám.

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.

Otázkou je, zda má takový článek ovšem dnes smysl. Většina lidí ani dnes neví, že existovalo i něco jiného než relační databáze a dnes neexistuje nějaká jiná možnost. Nepočítám do toho ty módní NoSQL výkřiky, které trpí už tím, že neexistuje jednotný dotazovací jazyk.

S Pavlem a dalšími bych se jistě dohodl na tom (a Pavel to zde již kolikraát uvedl), že existují případy, kdy je nasazení RDBMS nevhodné, jenom bych si tipnul, že já bych to viděl asi u 80 % případů v IT a Pavel tak u 20 %. Ale i kdybychom se dohodli na těch mých procentech, co to změní? - nasadit se stejně musí nějaká RDBMS. Nakonec jak jsem psal, my to děláme teď také (dříve jsme nasazovali síťovou databázi).

Další problém je v tom, že většina lidí má pouze zkušenosti s úlohami projektového charakteru. Jen málokdo kdy dělal produkty, které  používají databáze.  Teď nemám na mysli ale ORM-Frameworks. T.zn., diskutující nebo čtenáři zpočátku vůbec nemohou rozumnět, o čem autor mluvi.

Ale jestli se k tomu někdy doberu něco sepsat, tak samozřejmě využiji Pavlovy nabídky mu to poslat, aby mi sdělil co si o tom myslí. 

[Reklama]

[lt]

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.

[Krysa11]

NoSQL nebo NOSQL : někde to znamená "nejen SQL" někde to jde zase proti principu SQL, takže "ne-SQL" už v tom je rozpor. Většina těch nových databází, se kterými jsem se prakticky setkal (Mongo, Neo4j) SQL dotazování nemá vůbec. Vytváří vlastně nový jazyk pro dotazování. Podobně jako například QueryDSL. Mongo je vlastně javascript. Je to každý pes jiná ves. Ono vytvořit obecný objektově dotazový jazyk jaksi nejde, protože "objekt" je ideální pojem, který každý jednotlivý programátor, tým, projekt, implementuje jinak s ohledem na svoje potřeby a specifický pohled na konkrétní problematiku.

Ten nový dotazovací jazyk je tedy podřízen nejen konkrétnímu programovacímu jazyku, ale mnoha dalším věcem, často s návazností na nutnost mnoho funkcí implementovat na úrovni programové logiky. NoSQL databáze mají vždy velmi specifické užití - zatímco tabulka je real-world fenomén, který pochopí mnohem širší populace neprogramátorů, tak pod slovem graf si většina lidí představí klikatou čáru (která je na pravé straně víc nahoře než na levé) a světe div se, neabsolvovali ani první semestr diskrétní matematiky. Pod slovem dokument si většina lidí představí word. Tabulku jim vysvětlíte, mj. protože ten excel to vystijuje celkem dobře. Spousta neprogramátorů je ráda, že má data uložené ve formátu, který jsou schopni alespoň částečně pochopit. A pak jim tam uděláte ranec ManyToMany, ale i na to jim můžete udělat views, atd.
SQL RDMS jsou přesně na tohle dělané, i když manažeři se většinou SQL navzdory očekávání většinou nenaučili. Navíc jsou zavedené, optimalizované a neskutečně vymakané.
Začínajícímu programátorovi bych určitě poradil založit svoje snažení na SQL RDMS + ORM + Jazyk vlastního výběru (Java); to otevře cestu do světa.

[SB]

...Vseobecne radsej pouzivam relacne (tabulkove) DB, MySQL... Pripadaju mi "najuniverzalnejsie". Hlavne na projektoch, kde sa struktura dat meni s pridavanim funkcnosti do aplikacie...

Vzhledem k tomu, že RDB jsou schématové, jdou změny v struktuře dat přesně proti podstatě RDB.

[SB]

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?

DB vám může zajistit např. persistenci či transakce (ty ale stejně budete muset zohlednit v práci s daty), ale na to nepotřebujete zrovna RDB. Samotné uspořádání do tabulek je pak nadbytečné, protože musíte zbytečně překládat data.

[SB]

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?

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.

Ale hovno, data musejí řešit logiku, integritu i konzistenci v doméně v aplikaci, to, že si je zaděláte navíc v RDB, neznamená, že se na ně můžete jinde vyfláknout.

Jednoduchost a rychlost procházení grafy.
Např. hashováním, stromy, ... - obdobně jako v oné DB.
API k vnějším systémům? Jaké si ho navrhnete, každopádně NEZÁVISLOU na způsobu uložení!!!
Pravidly a odkazy.
Držením historie dat (kterou stejně budete v obchodních aplikacích potřebovat).
Nebudete, stačí vám programovací jazyk, ve kterém pracujete.

S fyzikálními zákony to nemá co do činění, jde o výhodnost uspořádání dat.

Mícháte do sebe abstrakce na různých úrovních. Samozřejmě, že je vám u pr-dele, jak si DB ukládá data, ale už vám není u prde-le, zda vám z DB vypadne relace, dokument, blob, či něco jiného, to je KURVA rozdíl a jiný způsob práce!

[SB]

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?

Nejenže nejsou organizovány do grafů, ale dokonce obsahují pouze primitivní, lineární, binární paměťové jednotky!!! :O (To je překvapení!) Veškerá abstrakce nad nimi (formáty a uspořádání dat) je umístěna a řešena v paměti počítače. Ne že by to nešlo strčit do disků, ale je to jednodušší.

[JS]

Ale třeba evidovat finanční transakce ve stromové struktuře mi moc smysl nedává.

Jednou z uplne prvnich databazi bylo IMS (a obcas se jeste pouziva), a ta uklada data (zaznamy) prave ve stromove strukture podle klice.

Ma to vyhodu - je to brutalne rychle a efektivni. Ale hlavni nevyhoda je, ze si musite vytvorit vlastni funkci (program), ktera ty zaznamy prochazi (treba IMS databaze rozlisuje jestli chcete zaznamy take sekvencne prochazet nebo najit vzdy jen jeden konkretni atd.). A pokud chcete hledat podle jinych klicu - vesmes to znamena zmenit databazi a programy, co delaji ty dotazy.

Eventualne z toho vznikl relacni model a SQL, ktery prinasi mnohem vyssi flexibilitu (na poradi klicu ani zpusobu dotazu nezalezi) za cenu ztraty vykonu (optimalizator musi umet zpracovat libovolny dotaz, databaze neni nutne optimalizovana na konkretni 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.

[SB]

...Relacni DB byly, jsou a budou. Jsou pomerne lehke na pochopeni, SQL jazyk taky...

A vůbec ne. Rozklad entit a jejich společných podentit do vzájemně oddělených (a ještě k tomu typizovaných) tabulek je nepřirozený, jejich následné opětovné spojování nadbytečné.

...a kdyz se spravna cast business logiky resi uz rovnou v DB (stored procedures, olap atd.)...

To ale nijak nesouvisí s typem DB.

[SB]

Proč by relační tabulkové databáze měly zahynout?

Není třeba, aby zahynuly, ale aby se necpaly všude. RDB nejsou univerzálním nástrojem!

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".

Dobře jste si teď nasral do bot. Víte, jak se ukládá a čte strom v dokumentové DB?

[bck]

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 pokud chcete hledat podle jinych klicu - vesmes to znamena zmenit databazi a programy, co delaji ty dotazy.

já jsem myslel, že IMS podporuje sekundární indexy?

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.

to podle mne záleží na tom, jak se rozšíří 'průmysl 4.0'. Jestli to půjde tak, jak si to představují jeho protagonisté, tak pak v takovem prostředí hraí RDBMS minimální roli