21. září bude sraz! Od 18.00 v restauraci Tradice v Praze u Anděla
Autor Zpráva
quatzael
Profil
Dostal jsem se do fáze kdy to začíná být v databázi už trochu složitější a budu muset trochu překopat strukturu.
Měl bych dotaz: je nějak možné vytvořit v databázi nějakou inteligentní relaci (tím myslím odkaz z jedné tabulky na jinou) nebo musím vždy složitě používat JOIN?

Například když budu mít v jedné tabulce sloupce : jmeno, prijemni, adresa a v tom sloupci adresa bych měl odkaz (cizí klíč) na jinou tabulku kde by byly detaily, tady např. ulice, cp, obec, psc. Je to možné udělat nějak automaticky, abych při jednoduchém selectu dostal automaticky i sloupce z té tabulky, ve které je detail adresy nebo musím vždy složitě používat JOIN?
Joker
Profil
quatzael:
K tomuhle účelu ten JOIN právě existuje. Čili se to dělá přes JOIN, ale neřekl bych, že to je nějak složité.

Pokud by to z nějakého důvodu byl zásadní problém a zároveň se v té aplikaci nespravovaly samostatně ty adresy, asi by bylo přípustné dát sloupce ulice, cp, obec a psc přímo k uživateli.

Ale pokud je to objektová aplikace, udělal bych jednu třídu, která se stará o převádění mezi objektem a databázovým záznamem, a nikde jinde ty SQL dotazy už není třeba řešit.
juriad
Profil
Vždy musíš provést ten JOIN. Můžeš si ale vytvořit VIEW, což je v podstatě pojmenovaný dotaz, který se potom používá jako tabulka. Obvykle to však není třeba.
quatzael
Profil
Joker:
a nikde jinde ty SQL dotazy už není třeba řešit.
No jo ale, když tam takovýchto případu budu mít desítky a v jedné "podtabulce" další "podtabulku" tak to stejně budu muset řešit pro všechny případy, i když si na to vytvořím objekt..


juriad:
Můžeš si ale vytvořit VIEW
Dík, za radu. To je celkem zajímavý řešení. Akorát že to řeší pouze čtení z databáze a ne zápis..
Alphard
Profil
quatzael:
Akorát že to řeší pouze čtení z databáze a ne zápis..
Při práci z databází je to čtení důležitější, protože ve většině případů existuje mnoho různých dotazů, které data vytahují, ale pouze několik těch, které je upravují.

Nejen pro modifikaci dat začne být v určité chvíli potřeba psát model. To je ten moment, kdy lidé, kteří vše patlali dohromady (žádné MVC), začnou mít problémy :-) Jestliže existuje třída Client, která má na starosti správu klientů, tak jde úpravu i složitější databázové struktury udržet pod kontrolou. Prostě vznikne metoda update($clientInfo), která vše zařídí. Pokud bude složitost této stále obecné metody příliš vysoká, vytvoří se metoda updateAddress(), která bude zapisovat třeba do 5 tabulek. Bude to všechno zapouzdřené a bude to fungovat. Tímto směrem mohu pokračovat jak bude potřeba.*
*Snad je jasné, že naznačuji princip. Pro výslednou implementaci existuje mnoho možností, včetně té, že Client bude jen datová entita a k uložení čehokoliv bude potřebovat další objekt.

Databáze má na tohle uložené procedury, které umožňují udržet model na její úrovni. To je neocenitelné, pokud k databázi přistupuje více různých aplikací. Z mých zkušeností to ale aspoň v případě MySQL není zrovna pohodlé a spíš preferuji držet složitější logiku v PHP.

Pro úplnost, view není pouze pro čtení, ale modifikační možnosti jsou značně omezené.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0