Správna štruktúra tabuliek

Můžeš použíť:
Toto přímo vloží do tabulky výsledek SQL dotazu, stačí tedy napsat dotaz tak, aby vracel data v podobě kompatibilní s novými tabulkami. Toto provedeš pro každou novou tabulku.

Pokud máš data v databázi serializované (což bys nikdy mít neměl), tak ano, musíš použít PHP pro načtení a provedení insertů.

tomas2245:
„totiž, neviem že keď budem pripájať všetky tieto tabuľky tak môžu mať väzbu stále s tou jednou príklad:“
Ano, je to tak správně. Ostatně sis mohl zkusit, jestli ten dotaz vrátí, co má. Každá vazba se v tomto případě vyhodnocuje zvlášť, není důvod přes oi.id připojit objednavky_cena, když už je předtím připojena objednavky_tovar.

tomas2245:
„ako to myslíš že nie je dôvod cez oi.id pripojiť objednavky_cena“
Mělo tam být není důvod nepřipojit.

Zkrátka, že víceré napojení na jeden sloupec jedné tabulky (oi.id) nevadí a je to tak správně :-)

tomas2245:
Protože vytahuješ z databáze i tovary, tedy počet vrácených záznamů bude stejný jako počet tovarů. Máš dvě možnosti:
1) smířit se s tím a nějak si to vyřešit v PHP
2) položit dva dotazy: jeden na objednávku bez tovarů a druhý jen na tovary konkrétní objednávky.

tomas2245:
„ako by sa dali priradiť tovary k jednotlivým objednávkam?“

Tady je nástin různých přístupů
Srovnání dotazů do závislých tabulek

tomas2245:
GROUP CONCAT je určeno spíš jako hack, než něco, co by se mělo používat. Je jen málo datábází, které něco takového nabízí a mají k tomu dobrý důvod - řešení formátování nemá být řešeno v databázi. Z možných řešení jsi si vybral asi to nejméně vhodné.

Ten vnitřní dotaz nedává úplně smysl, celé to jde nahradit za:

(Pořád si myslím, že tabulky spojuješ divně, takže si ty ON podmínky asi musíš upravit podle své situace.)

Bez zvýrazněné části tomu dotazu asi rozumíš. Připojením tabulky objednvaky_tovar se ti namnoží počet řádků, kterého se zbavíš tím GROUP BY. Nakonec jen potřebuješ pomocí GROUP_CONCAT reprezentovat každou skupinu (tovary v objednávce).

Ono ani nejde o to zavedení registrací. Lépe se o tom konceptuálně přemýšlí.

Když si vezmu ten tvůj příklad: zákazník vytvoří objednávku, která se skládá z produktů. Máme tedy tři entity, které jsou spolu nějak svázané:
Jaký je vztah mezi zákazníkem a objednávkou? Zákazník má objednávky (0 a víc). Objednávka patří vždy právě jednomu (1) zákazníkovi. Tomuto typu vazby se říká N:1 (nebo 1:N, podle směru).
Jaký je vztah mezi objednávkou a produktem? Objednávka obsahuje produkty (1 a víc). Produkt může být obsažen v nějakých objednávkách (0 a víc). Tomuto typu vazby se říká M:N.
Jaký je vztah mezi zákazníkem a produktem? Žádný.

Jaké atributy má zákazník? Jméno, příjmení, nějaký kontakt.
Jaké atributy má objednávka? Kdy byla založená, celková cena, kam ji doručit, vybraný způsob dopravy, poznámka.
Jaké atributy má produkt? Název, popis, cena.

Jaké atributy má mít vazba mezi zákazníkem a objednávkou? Asi nic není, protože vazba je 1:N, vždy je tedy možné přidat informaci do strany s N (což je v tomto případě objednávka).
Jaké atributy má mít vazba mezi objednávkou a produktem? Počet, hodí se cena (protože cena uložená v produktu se může měnit), může se hodit celková cena (množstevní slevy, akce).

Toto je přibližně všechno, co bys mohl kdy chtít modelovat. Ty však chceš začít s něčím menším (vynechat atributy je možné ty lze později snadno přidat; vynechat entity ještě asi také půjde za cenu duplicity dat v databázi), ale změnit vazby mezi entitami mění pohled na celý model.

Všimni si, že jsem doposud nemluvil o tabulkách a sloupcích v databázi. To totiž přijde, až když máš hotový takovýto model; pak provedeš transformaci do tabulek v datábázi:
1) Z entity se stane tabulka; každá tabulka entity bude mít jako primární klíč id; atributy entity se stanou sloupci tabulky.
2) Vazba 1:1 mezi X a Y se vyřeší jedním z možností (která to bude, závisí na tom, zda některá ze stran vazby může být nulová):
- spojení tabulek propojených entit do jedné (místo tabulek X a Y bude tabulka XY)
- přidáním sloupce X_id do Y
- přidáním sloupce Y_id do X.
3) Vazba 1:N mezi X a Y se vyřeší přidáním sloupce X_id do tabulky Y. (A přesně opačně pro vazby N:1)
4) Vazba M:N mezi X a Y se vyřeší přidáním vazební tabulky X_Y se sloupci X_id a Y_id (tyto dva sloupce dohromady budou tvořit primární klíč).
5) Pokud vazba má atributy (což myslím nastane jen u M:N vazby), tak patří jako sloupce do vazební tabulky.
Toto je docela automatický postup, který ti z popisu, co jak s čím souvisí, vytvoří databázové schéma.

Když se koukáš na tabulky v databázi, tak vlastně nepřemýšlíš o tom, že tabulka má nějaké sloupce a že sloupec id má shodnou hodnotu jako sloupec X_id v jiné tabulce, ale přemýšlíš o tom modelu, jak jsem ho popsal výše: jak jsou spolu jednotlivé entity propojené. V ideálním případě, pokud dodržuješ nějakou konvenci - třeba jak jsem ji načrtnul výše v 5 bodech - přecházíš mezi modelem a tabulkami v databázi automaticky; dokonce tabulky v databázi tak chápeš - jejich úkolem není být tabulkou, ale realizovat nějakou část modelu.

Podobně jako jako odvodíš tabulky z modelu, můžeš z něj odvodit dotazy. Jejich psaní se pak většinou stane rutinou, protože ti bude přesně jasné, proč jaký JOIN s jakou vazební ON podmínkou máš použít.

Když jsi tedy vytvořil databázi, ve které není zakaznik_id, ale naopak zakaznik má objednavka_id, tak jsi namodeloval svět, ve kterém zákazník nemá nějaké objednávky, ale naopak objednávka má zákazníka. A pokud bys byl důsledný, tak se tento způsob myšlení projeví i jinde v aplikaci. Než abys vytvořil omezený model, ty jsi vlastně vytvořil jiný model, a pokud jej časem budeš chtít rozšířit, je možné, že to bude stát víc práce.

Chápu, že s databázemi začínáš a že větší množství tabulek a různých joinů může být děsivé, ale databáze je jen nástroj, který používáš k implementaci modelu. Také chápu, že je pro tebe teď mnohem jednodušší přemýšlet o tom, že máš jednu centrální tabulku objednávek a k ní připojuješ další docela stejným způsobem.

tomas2245:
Tak si kup nějakou pěknou knihu o MySQL a začni hezky od začátku. Stavíš e-shop a nemáš ani základy a třeba mě osobně už tohle vlákno leze na nervy.
Tohle je diskusní fórum kam můžeš přijít pro radu s nějakým problémem, ale ty jich máš skutečně hodně a opakuji je to diskusní fórum, ne dlouhodobý průvodce pro začátečníky co se vrhnou na větší aplikaci bez zkušeností a základů, které musí mít!