Databáze s vazbami nebo bez?

[anonym]

Zdravím,

Hraju si s databázema v mysql a používám HeidiSQL, které nepodporuje například cizí klíče.

Chtěl bych se zeptat, zda je chyba nedefinovat tyhle vztahy v rámci databáze, ale definovat je až v programu samotném?
Resp. co je lepší způsob a včem?

Díky za názory.

[Reklama]

[RDa]

Mam pocit ze ani phpmyadmin nepodporuje cizi klice - neni to nahodou dano tim, ze cizi klice nepodporuje mysql ?

[Jirka]

PHPMyAdmin samozřejmě podporuje cizí klíče vč. integritních omezení. Dokonce umožňuje provádět i prokliky mezi záznamy s různých tabulek. Engine InnoDB cizí klíče podporuje. MyIsam tuším, že ne.

Jinak myslím, že definovat vztahy v programu je pracnější a řekl bych, že reálně méně spolehlivější než v DB. Osobně bych se do toho nepouštěl ;-).

[RDa]

Jo, to bude tim. Ze skutecne je umi jen innodb a s myisam se simuluji v pma (proto zrejme ta potreba nastavit si pro nej odkladaci prostor)... nikdy jsem pak nevyuzival.

Lepsi me prijde pokud se aplikace spravne rozvrstvi - pak lze ty cizi klice vyresit v nizsi vrstve a ta vyssi nemusi vedet zda to dela db, nebo aplikace - hlavne pokud je potreba delat navic specialni veci (ma posledni app ma datovy log - co, kdo, kde a kdy udelal).

[OndraB]

Spolehnout se na integritu dat v aplikaci může být docela sebevražda. Zvlášť pokud třeba aplikaci nevyvíjíš sám a nebo nejsou dodržovány standardy pro přístup k databázi (oddělená vrstva v MVC modelu).
Sebevražda z toho důvodu, že až se Ti po naplnění datama něco rozbije, budeš to dlouhé hodiny dávat dohromady - věř mi

A co se týče HeidiSQL, můžu doporučit, alespoň pro práci s MySQL, mysql-workbench. Zvládá i reverzní inženýrství, což se hodí při migraci na produkční DB (pokud to s projektem myslíš vážně)

[Reklama]

[James_Scott]

Přesně tak, spoléhat se na integritu dat v aplikaci je v dnešní době nesmysl. 1 DB != 1 aplikace  ...když se pak vytvoří mobilní aplikace,desktop,webová, bylo by pracné a zbytečné ověřovat integritu v každé aplikaci.

[Tomáš]

Pokud budete k datům přistupovat jen a pouze pomocí uložených procedur v té databázi, tak se nemusí definovat referenční integrita na úrovni tabulek, ale lze to uhlídat i pomocí těch procedur. Ale je to podmíněno tím, bude přísně dodržován zákaz přímé modifikace dat v tabulkách z aplikace a budou se skutečně používat jen ty uložené procedury.

Dám příklad: dělám na projektu, kde se v jednotlivých tabulkách drží historie změn jednotlivých záznamů, řádky se nemažou, neupdatují, řádek se označí jako starý nebo zrušený a vloží se případný nový. Ano, je otázka, jestli je pro toto vhodné používat relační SQL :-)

[j]

Technologicky spravnejsi reseni je struktura v databazi. Potiz ovsem nastane v situaci, kdy se neco nekde pokaka...

Osobne vnimam jako problem predevsim soudoby pristup "try - catch" => zkusime to udelat, a kdyz se to podela, tak (nekdy) nahlasime nejakou chybu. Misto toho, aby dotycny nejdriv overil, zda data ktera chce nekam nacpat tam nacpat muze. Uz sem videl pokusy insertnout string do intu (protoze proc by mela aplikace overit vstup, ze ...) a pod.

Takze pokud navrhujes DB, je treba pocitat, ze nekdo kdo s ni bude pracovat pomoci nejaky svoji aplikace tam naladuje naprosto cokoli, co mu databaze dovoli.

Mimochodem, zboznuju mazani zaznamu v databazi v cyklu, a samo pekne v jedny transakci ... to je ti tak bozi, kdyz se zaznamy v logu mazou pomalejs nez se vytvarej, a kdyz se appka zhrouti, tak se to cely rollbackuje ... (samo, data bez vazeb => do temptable si naladujou hlavicky, pak k tomu postupne odmazavaj polozky ... no proste des ...)

[Pavel]

Chtěl bych se zeptat, zda je chyba nedefinovat tyhle vztahy v rámci databáze, ale definovat je až v programu samotném?
Resp. co je lepší způsob a včem?

Kedysi ked som bol mlady a hlupy som mal jasnu odpoved: v databaze musia relacie a obmedzenia ake sa len da vymysliet.
(t.j. napriklad v Oracle do stlpca "tento_zaznam_je_zmazany" sa da constraint povolujuci iba dva stavy)

Od tych cias som stretol pomerne dost pripadov, kedy:
a) to aplikacia pouzivala a vadilo to (select ktory zbiehal pomaly pretoze FK nad stlpcom "Mena" bol znacne nevyvazeny, potreba importnut nie 100% spravne data,...)
b) to aplikacia nemala a "nikomu to nechybalo".

Vo vseobecnosti asi je rozumne sa prisposobit programovaciemu jazyku / frameworku / firemnej kulture / etc.

[TomasVoracek]

Rekl bych, ze nemit mezi tabulkami vazby na urovni FK kdyz to primo vyplyva z principu aplikace je naproste zverstvo. Nejlepsi je kdyz k necemu takovemu prijdete jak slepy k houslim a mate nad tim neco postavit 

Na urovni aplikace to urcite neres. Az prijde pozadavek na jiny typ aplikace (mobil, desktop) tak udelas co? Budes to mit na 3ti mistech?

[Logik]

Pavol:
a1) FK NENÍ index.
a2) Import špatnejch dat? To je stejně rozumnější naiporotovat vedle a nejprve opravit. Právě proti tomu ty integritní omezení chráněj
b) Ono to nechybí do tý doby, než se zjistí, že ten a ten kodér tam udělal botu a v db je povolina dat blbě..... Samo, že se to nestane v každym projektu, ale riskovat to je podobný, jako server nezálohovat.

[Pavel]

Pavol:
a1) FK NENÍ index.
a2) Import špatnejch dat? To je stejně rozumnější naiporotovat vedle a nejprve opravit. Právě proti tomu ty integritní omezení chráněj
b) Ono to nechybí do tý doby, než se zjistí, že ten a ten kodér tam udělal botu a v db je povolina dat blbě..... Samo, že se to nestane v každym projektu, ale riskovat to je podobný, jako server nezálohovat.

a1) aku realnu implementaciu, kde to je realne oddelene poznate?
a2) sediva je teoria...data ktore nie su 100% spravne mozu byt dostatocne dobre, mozte ich chciet neskor opravit, mozte chciet cyklicku referenciu a tak...
b) detto... mozte chciet vyssi vykon, mozte robit malu aplikaciu pre amaterov kde je volnost prinos, mozte pouzivat generovanu schemu kde FW nerobi kluce, ... Porovnavat to s nezalohovanim je ako tvarit sa, ze zakaz nozov a zakaz rychlopalnych zbrani je vlastne to iste.

[Pavel]

Pre pripad nepochopenia:

To je stejně rozumnější naiporotovat vedle a nejprve opravit.

Ked to naimportujete vedla, vytvorite malu sub-databazu, kde nemate tie FK, bez ktorych podla Vas nejde vlak.

[Jakub L.]

Osobne vnimam jako problem predevsim soudoby pristup "try - catch" => zkusime to udelat, a kdyz se to podela, tak (nekdy) nahlasime nejakou chybu. Misto toho, aby dotycny nejdriv overil, zda data ktera chce nekam nacpat tam nacpat muze. Uz sem videl pokusy insertnout string do intu (protoze proc by mela aplikace overit vstup, ze ...) a pod.

Samozřejmě, že takové extrémy správně nejsou, ale obecně je EAFP je lepší LBYL...

Co se týče otázky, jednoznačně s constraints! Nedávno jsem programoval netriviální aplikaci s hodně vazbami a když jsem to skoro měl, uvědomil jsem si, že je hrozně složité cokoliv smazat, aby to nic nerozbilo...

[Waseihou]

Pokud už se z jakýchkoliv důvodů rozhodnete nepoužít referenční integritu, tak PROBOHA alespoň tuto informaci uvádějte do commentu ke sloupečku. Dělám na 15 let starém projektu kde toto chybí a referenční integrita je jenom někdy a někde, SQLko se updatuje jak z C++ modelu tak pomocí procedure PL/SQL, které mohou být volány taktéž z C++, případně to nějaký vnější proces volá navzájem - naplnit tabulku v Oracle ze SAPu, zavolat C++ kde je taky část bussiness logiky, od tama se zase volá PL/SQL procedura kde je taky část té logiky, výsledek se vrátí do C++ a od tama se volá další PL/SQL procedura, procedury mají obvykle tak 20-50 vstupních a 10-15 výstupních parametrů, jsou to zprasené transakční skripty kdy je hodnota proměnné obecného jména nastavovaná v některé z mnoha větví použita o několik tisíc řádků níže a běda, pokud v ní je špatná či žádná hodnota. Pro každé možné nastavení továrny podle zákazníka jedna dlouhá nudla v IF else, a pod tím další atd. A jednou někde to zas do toho SAPu vyleze, nebo se mu alespoň umožní nahlédnout na data. Unit ani integration testy pořádně neexistují ani nejsou moc možné, byť se o to někteří pokoušejí, protože se to celé sype a program už se mnohokrát prodal za těžký prachy, takže je třeba to supportovat stůj co stůj, a mor se salesákům daří šíři dál...