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