Kontrola propojení tabulek v SQL databázi

[Ondřej H.]

Dobrý den,
mám začátečnický dotaz ohledně SQL a databáze, rád bych se vás zeptal, zda existují nějaké kontrolní postupy, při propojování tabulek v databázi, které by ověřili správnost těchto propojení. Jde mi o to, že když nastavím jednu vazbu, zkontroluji na vybraném příkladu, zpracuji data do reportu a následně udělám pozdější doplnění výstupu o další tabulky, abych zjistil, že vše zůstává nastavené správně.

Napadá mě kontrolovat součet vybraného měřítka, nebo si nějaké kontrolní hodnoty ukládat do dočasných tabulek, ale rád bych věděl, zda existují další metody nebo jak toto kontrolujete vy? Možná i v návaznosti na plnění databáze. Nebo zda existuje něco jako unittest u programovacích jazyků.

Děkuji

[Reklama]

[Tomas-T]

Pokud nějaká pravidla nastavujete skutečně v databázi na sloupcích (pro propojení tabulek tedy relaci/cizí klíč) tak si to normální databáze už hlídá sama a znemožní vám akce (INSERT, UPDATE, DELETE), které by ta pravidla porušily.

[Filip Jirsák]

Můžete uvést konkrétní příklad? Nevím, co si pod vaším dotazem představit. Pokud „propojením tabulek“ myslíte cizí klíče (foreign keys), ty pro tabulku jednou nastavíte a od té chvíle je bude databáze kontrolovat. Pokud vám jde o to, jestli jsou tam ty vazby logicky správně, to žádný nástroj kontrolovat nedokáže – to je věc analýzy.

[Ondřej H.]

Dobrý den,
děkuji, ale moc tomu nerozumím, chápu, že u tabulek lze nastavit cizí klíče, ale když by pak někdo použil špatný typ vazby, tak jak by se zkontrolovalo, že chybí některé hodnoty z připojené tabulky kromě toho, že na vybraných příkladech zkontroluji jejich správnost?

Hezký den

[Ondřej H.]

Pro pana Jirsáka, děkuji, je to ta druhá možnost, zajímalo mě právě, zda na to není nějaký šikovný trik z praxe a tak.., kromě té analýzy.

[Reklama]

[Pavel Stěhule]

Ve vaší otázce mícháte dvě věci. Jednak kontrolu implementace referenční integrity, druhak kontrolu vámi navrženého datového modelu. Pokud definujete referenční integritu, a ona by nefungovala, tak by se vám objevovali sirotci - hodnoty jejichž cizí klíč by nebyl validní - lze to testovat např. outer joinem.

Kvalitu datového modelu popisují tzv normální formy. V reálu se nekvalitní model projeví buďto duplicitou dat, nebo s údržbou dat - např. nebudete moc přidat další kontakt na zákazníka nebo uživatele, nebo se vám budou špatně psát SQL dotazy. Viděl jsem vývojáře vesele pracovat s extrémně nešikovně navrženou databází - od problémů je odstínilo ORMko. Bylo to ale za cenu problémových SQL dotazů a častého zamykání (což se pak negativně projeví na výkonu).

[Pavel Stěhule]

Pro pana Jirsáka, děkuji, je to ta druhá možnost, zajímalo mě právě, zda na to není nějaký šikovný trik z praxe a tak.., kromě té analýzy.

Na to žádný nástroj nemůže existovat. Data v relační databázi budou přesně v modelu, který jste si nastavil. Tudíž nějaká univerzální kontrola vůči tomuto datovému modelu nemůže najít nějakou odchylku. Abyste zjistil chybu, tak byste musel porovnat data s reálným světem nebo s jiným datovým modelem. Pak zjistíte rozdíly, ale je zase pak otázkou interpretace jestli jde o chyby nebo záměr.

[Filip Jirsák]

Co znamená „špatný typ vazby“? Že by třeba někdo v SELECTu použil INNER JOIN místo LEFT JOINu? To se nedá poznat jinak než analýzou toho dotazu a porovnáním se zadáním. Protože oba dva typy dotazu mohou mít smysl, akorát mají každý jiný význam. Např. pokud bych měl tabulku osob a z ní volitelně referencovanou tabulku adres, může napsat dotaz s LEFT JOINem i INNER JOINem, a oba budou dávat smysl – první mi vrací seznam osob s adresami, druhý seznam osob, u kterých známe adresu (třeba abych jim mohl poštou poslat nabídku).

[Ondrej Nemecek]

Postupoval bych cca takto:

• připravil bych nějaké vhodné příklady použití databáze a výstupy, které považuji za zprávné - a v unittestu bych pak vložit testovací data, provedl dotazy a porovnal s těmi očekávanými výstupy
• tu databázi i uvedené unittesty bych si nechal zkontrolovat někým, kdo kdo má s návrhem databází obsáhlé zkušenosti

Příklady:

• mám databázi faktur a řádků faktur, připravím si dvě vzorové faktury a jejich položky, ručně si spočítám celkovou cenu, v unittestu pak tyto dvě faktury vložím, provedu select, zkontroluji že u správných faktur dostanu správné položky a že celková cena, kterou databáze spočítala při vkládání položek, odpovídá ručně spočtené sumě
• mám databázi knih a jejich autorů, připravím si několik knih od několika autorů a ověřím, že mi selecty vrací správné knihy od správných autorů a že při odstranění autora mi databáze sama smaže i všechny jeho knihy

...a takto si napíšu testy pro všechny klíčové způsoby použití - osvědčilo se mi to psát i pro triviální případy, protože tak rychle odhalím např. překlepy, logické chyby, chyby způsobené copy-paste postupem, a taky když provedu refaktoring nebo změním databázi, tak jen spustím testy a ty mě opět docela snadno navedou na to, co je potřeba opravit.

[Ondřej H.]

Dobrý den,
omlouvám se měl jsem pracovní víkend. Všem mockrát děkuji, určitě jste mě nasměrovali jak dále.

Mockrát děkuji,
Hezký den,
Ondřej