Databáze : Bludné balvany v databázi

V mé praxi databázového inženýra narážím často na ten samý problém. „Máš pravdu chtělo by to změnit, ale nemůžeme to udělat protože …“ A následuje série důvodů objektivních i těch subjektivních.  Když se v databází se realizuje něco, co pak je nutno změnit a vy to přesto změnit nemůžete, tak těmto věcem v databázi a vůbec v programování říkám Bludné balvany.

Databáze : Bludné balvany v databázi

Možná to znáte. Jedete krásnou rovnou krajinou s mírnými kopečky. A pojednou se objeví obrovský balvan a vy žasnete kde se tam v té krajině vzal. Chcete jej pohnout, nebo zničit, aby nenarušil ráz krajiny. Ale on je příliš veliký a vy příliš slabý, abyste ten balvan odstranily, nebo s ním alespoň pohnuly. A pak si v duchu kladete pouze otázku. Je toto vůbec možné? A nezůstává Vám nic jiné než tento bludný balvan obejít. 

I ve virtuální světe se vyskytují bludné balvany. Na rozdíl od těch reálných nejsou vidět. Jsou zakopané ve směsi kódu a dat. Ačkoliv nejsou vidět, víte o nich, protože kdykoliv na ne narazíte a chcete s nimi pohnout nejde to, nebo velice těžko. To proto, že jsou „zadrátované“ na množství různých místech kódu.

Jak vznikají bludné kameny?

Jednoduše nejdříve musí být zásobárna kamene. Ty naše pocházejí ze Skandinávie. Ty virtuální z nutnosti provést určitou funkčnost. Pak musí být nosič, který urve kámen z masívu. Tím je v přírodě ledovec. Ve virtuálním světě vývojář s ad-hoc řešením. Jenomže ledovec s kamenem nehne, dokud nemá pohon a tím je sníh a chladné počasí, který živý ledovec a ten roste a posouvá se i s balvanem krajinou. Ve virtuálním světe je chlad nahrazený termíny, nebo snahou dokončit práci co nejdříve. Tím sněhem jsou kolegové, kteří se chovají pasívně, nebo nemají čas se problémem zabývat a diskutovat o něm. A tak se bludný balvan posouvá krajinou a ten virtuální kódem, kde se „zadrátuje“ na co nejvíce místech. V realitě přijde oteplení a balvan zůstane tam, kde jej ledovec zanechal.

Jak předcházet bludným balvanům?

Někdy to jde velice těžko, ale pár jednoduchých pravidel jsem z praxe odpozoroval:

1. Konstruujte databázi nezávislou na aplikacích, které s ní čtou nebo zapisují data.

Je velice jednoduché navrhnout databázovou strukturu a napojit přímo na ní aplikaci, která čte a zapisuje data přímo do tabulek databáze. Nevýhodou tohoto řešení je, že aplikace se až příliš spoléhá na existující databázové objekty. Řešením je položit mezi aplikací a databázi rozhraní (interface). A je jedno jestli databázové (view, funkce), nebo aplikační. 

2. Do databázi ukládejte data v nativním formátu databáze

Jednak tím urychlíte použití SQL jazyka pro různé výběry a manipulace s daty. A jednak přestanete být závislý na aplikaci, přes kterou tečou data. Když připojíte k takové databázi jinou aplikaci, tak se Vám adapter na data bude psát mnohem pohodlněji.

3. Navrhujte databázi jako celek

Existuje takzvaná salámová metoda. Kdy začnete řešit pouze část databáze, to, co Vás nejvíce trápí až do zadrátovaní do aplikace. Pak si zase ukrojíte další kolečko ze salámu, a to se pokusíte napasovat do existující databáze. Někdy se to povede jednoduše a někdy, když se v databázi vyrojí bludné balvany těžce.

4. Pokuste se maximálně zobecňovat db struktury.

Např:

• Když použijete fyzický číselník jako tabulku, tak ji můžete lehce změnit. Když v číselníku nepoužívejte jako primární klíč významový kód, ale abstraktní identifikátor typu integer, který navíc není generovaný přes sekvenci, ale natvrdo zadaný, tak můžete se v kódu spolehnout na hodnoty primárního klíče jako jedinečného neměnného identifikátoru řádku.
• Když vyvedte enum hodnoty, které může nabývat sloupec tabulky, z kódu checku nebo procedury jako select do tabulky. Zamezíte hledání míst, kde je nutné jej změnit kódy.

• Počítejte ze servisními sloupci v každé tabulce.
  •    Jako je status řádku (nový, validní, nevalidní, logicky zrušen (soft delete))
  •    Kdy byl naposledy změn řádek
  •    Kdo naposledy změnil řádek
  Když je do db doplníte, v budoucnosti to oceníte, když nebudou vidět nevalidní záznamy a lehce dohledáte, který z uživatelů provedl danou změnu.

5. Konkretizujte co nejvíce s jakými daty pracujete

• Na druhé straně, když děláte select a nepoužívejte * za SELECT klíčovým slovem, ale vyjmenujete sloupce, které potřebujete vybírat a pracovat s nimi. Nemusíte při přidání nového sloupce do db zažít horké zklamání, že mnoho věcí přestane fungovat.

• Používejte constraint a referenční integritu přes cizí klíče jako poslední kontrolu správnosti vložených dat. Když je potřeba, tak je nastavte jako DEFERABLE, aby byly v transakci rychlejší.