Vlákno názorů k článku Modelování databází od vlk - Trochu nudny clanek, nic noveho se clovek nedovi....

Trochu nudny clanek, nic noveho se clovek nedovi. Treba ale dalsi clanek bude praktictejsi - co treba napsat neco o praci v nekterem free CASE systemu pod Linuxem nebo se je pokusit srovnat?

Pobavila me veta o programu pro vsechny - super ftipek.

Lidí, kteří se bezhlavě vrhli do praxe, je kolem spousta. Když pak vidím články typu "MySQL instantně za 20 minut" na některých webech (nebudu jmenovat Živě ;-), nestačím se většinou divit, jaké "návrhy databází" autoři vytvářejí.

Zdravime Daliho! :o)))
Mas pravdu, znam par OS projektu, ktere maji neudrzitelny datovy navrh a diky nemu i malou sanci na preziti. Coz je v nekterych pripadech dost skoda. :o(((

Specializuji se na optimalizaci MySQL a musím Vám dát za pravdu. Nějteří udělají takový prasácký návrh, že zatěžují databázi na 90% a nic jin0ho tam skoro nejede.

Statistik Hampel kdysi prohlásil něco jako:
"Není nic praktičtějšího, než dobrá teorie."
Naprosto s tím souhlasím a je to i jeden z důvodů, proč se mi srozumitelně napsané teoreticky orientované články na Rootu líbí. Vzhledem k tomu, že nemám žádnou teoretickou knihu o (relačních) databázích, jsem za každý článek tohoto typu docela rád.

Nemyslím. Pro laika popř. začátečníka je to dobrý a rychlý úvod do tvorby struktury db. Samozřejmě až praxe mu ukáže, co všechno je teorie a co se dá použít v produkčních systémech.
Ale faktem je, že takto má vypadat teoretický postup návrhu db. Ovšem výkon db železa, kdy je všechno provázáno klíči a na každém sloupečku jsou nějaká constraints je mimo dosah obyčejných smrtelníků.

Můj názor je ten, že když se udělá dobře základ db (koncept. návrh, tvorba tabulek, přidání integritních omezení atd.), odpadá spousta problémů v aplikacích nad touto db. Platí to zvlášť tehdy, když každou část dělá někdo jiný. Je proto nejlepší dát toho co nejvíc přímo do databáze a na aplikace nechat jen to, co se nedá řešit jinak.

Jistě. Ale už v okamžiku vytváření db architektury se musí vzít v potaz možnosti železa a db softu na kterém to pojede.
Např. na Oracle není problém s vyjížděním stromů a nemusí se k tomu psát žádná rekurze a otvírat mraky kurzorů.

a jak stromy?
ja to ted chci delat rekurivni procedurou.
jsem prave ve stadiu topeni se v referencni prirucce. a prechod mysql->oracle je fakt krize

"Je proto nejlepší dát toho co nejvíc přímo do databáze a na aplikace nechat jen to, co se nedá řešit jinak."

Jak kdy. Souhlasim s autorem článku že podstatné je rozmyslet, jakou roli hraje databáze v architektuře aplikace a vytvořit dobře definované (transparentní) rozhraní mezi databázovou vrstvou a ostatními částmi (obecně mezi všemi částmi) aplikace.

Článek je myslím dobrým úvodnem do problematiky a může otevřít oči těm, kteří do toho skočili nabo spadli po hlavě. Opakování a shrnutí základních a osvědčených postupů není nikdy na škodu.

>> "Je proto nejlepší dát toho co nejvíc přímo do databáze a na aplikace nechat jen to, co se nedá řešit jinak."

Tohleto je dost diskutabilní. Jestliže do databáze bude psát 5 různých aplikací nebo 1 aplikace 10 různými způsoby, pak je to asi na místě. Účel ale NENÍ aby se to zajišťovalo zrovna v databázi, účel JE, aby se to zajišťovalo na jednom centrálním místě, které se nedá obejít. Jestliže vím, že žádná jiná aplikace nebude mít práva zápisu přímým přístupem do databáze (tj. obejitím níže popisované střední vrstvy), a jestliže mám objektově orientovanou aplikační logiku, kde např. rušení záznamu bude VŽDY zajišťovat jediná třída, pak je lepší integritu implementovat do této třídy - budu to totiž mít velice snadno přenositelné z jednoho datového stroje na druhý. Tím zůstaneme u otevřené architektury a nebudeme nuceni psát 3x stejný algoritmus ve 3 poněkud různých "skriptech" při používání 3 různých datových strojů u 3 zákazníků/uživatelů aplikace.