Návrh databáze - internetový obchod

Martin
No, jak vždycky říkám, jakmile se objeví index v názvu sloupce (tj. něco1, něco2, něco3)- je potřeba zpozornět.
A už z toho popisu mi přijde vysoce pravděpodobné, že tohle bude špatně.

Co jsou ty vlastnosti?

Nejlepší to zrovna není, ale když tam budeš mít jen 400 položek, je prakticky jedno jak to budeš mít.

„ale když tam budeš mít jen 400 položek, je prakticky jedno jak to budeš mít“
už vidím ty dotazy, jak filtrovat podle barvy, když jednou je to vlastnost1 a podruhé vlastnost8

Alphard
To zrovna ne, tohle by mě ani nenapadlo, že to tak někdo udělá a předpokládám, že to tak nemyslel. Tedy, že pod vlastnost1 bude mít stejné vlastnosti u všech produktů, to je snad logické. Pokud si u nějakého dá barvu a u jiného rozměry, pak to ale není můj problém :)

EDIT:
Teď jsem si toho všiml, se omlouvám.

Pak v tom případě přidat další tabulku s vlastnostmi.

Martin
Většina produktů bude mít hodně společných vlastností (hloubka, šířka, délka, hmotnost, výkon-od, výkon-do, prumer-od, prumer-do, cena, popisek...)

Právě by mě zajímalo, jak to řešit "správně". Díky
Tak to záleží. Pokud by ten počet vlastností bude konečný a každý výrobek bude mít skoro všechny, je to takhle správně.

Pokud jich bude společná jen část a zbytek bude hodně variabilní, nebo to budou spíš nějaké popisky, možná bych zavedl tabulku něco jako rozšířené vlastnosti s dalšími vlastnostmi a potom tabulku výrobek - vlastnost - hodnota.

Martin - správny postup:
1. identifikovať entity
2. identifikovať vzťahy medzi entitami (1:1, 1:n, n:m)
3. vytvoriť tabuľky ktoré modelujú jednotlivé entity a vzťahy

Martin - takéto obmedzené(na počet hodnôt) a nemenné(nepredpokladá sa zmena) číselníky sa riešia buď cez stĺpec s dátovým typom enum(jedna položka) alebo SET(viacero položiek) v databáze, alebo cez pole v PHP (do DB sa bude ukladať len kľúč poľa)

Martin
Pravda, výčet (enum) by s tím co jsem psal trochu komplikovanější. Ale šlo by tak, jak je naznačené- vpodstatě že jednotlivá paliva by měla přiřazené číselné hodnoty.
Další problém by byl, kdyby bylo potřeba některé vlastnosti popsat čísly a jiné textově. I když je fakt, že skoro všechno asi půjde popsat číslem nebo výčtem (který jde taky reprezentovat číslem) a takové věci jako název nebo textový popis výrobku jdou dát přímo k výrobku

no a co když budou dalši paliva? třeba LTO? co když přibude další specifikace? asi bych spiš udělal jen jednu tabulku kde bude produkt nazev nějaké obecné ifnormace a šel by metou dalších tabule a vždy přidat čislo produktu a tabulku i čislem produktu a vlastnostmi...jak to říkal tiso

Martin
hodnota (typ retezec i pro cisla)
Bych tam možná dal číslo...

Ale jinak tohle je asi nejobecnější schéma.

PRODUKTY
id | id_kategorie | typ | popis | cena

Tím omezuješ produkt na jedinou kategorii.

Martin - koľko typov produktu tam budeš mať?

Martin - ten návrh je zlý...
1. vzťah produkty:kamna je 1:n?
2. Ako vyberieš konkrétny produkt? Skús si so svojou štruktúrou poskladať dotaz na to čo potrebuješ - výpis výrobkov z kategórie, stránku s detailom produktu, porovnanie poduktov a podobne..

Martin
Nedával bych pro každý produkt zvláštní tabulku.
Když by se to rozrostlo, třeba tabulka všech produktů pak může být mega-join třeba deseti tabulek. Taky hrozí nebezpečí, že různé produkty budou mít část společných vlastností, takže některé tabulky se budou částečně významově překrývat a podobně.

Martin - konkrétnejšie: Ako budeš vedieť že produkt s id=3 je roura alebo kamna?
Skús si skontrolovať svoj návrh po jednotlivých krokoch z [#8] a napíš ku každému z nich čo si vymyslel. Niečo sa naučíš a bude jednoduchšie ukázať na chyby v návrhu.

Zrovna řeším obdobný problém, mohu rozšířit?
Každý produkt patří do nějaké cenové skupiny (více produktů může mít stejnou cenovou skupinu)

CENIK
id | kategorie
(5, kamna)

Každá cenová skupina má různé faktory, které ovlivňují cenu

FAKTORY
id | cenik_id | nazev | popis
(10, 5, palivo, druh paliva)
(11, 5, výkon, výkon topidla v kW)

No a každý faktor má různé hodnoty
HODNOTY
id | faktory_id | hodnota
(20, 10, dřevo)
(21, 10, elektrika)
(22, 11, 5)
(23, 11, 7)
(24, 11, 9)

Teď bych potřeboval vymyslet něco jako řádky ceníku, kde bude k různým kombinacím hodnot faktorů přiřazena cena.
Třeba kamna na dřevo s výkonem 5kW stojí 8000,- na elektriku 12000,-
Problém je, že počet faktorů a jejich hodnot je stále variabilní. Primární klíč v tabulce ŘÁDKYCENÍKU by vlastně byla jedinečná kombinace řádků z tabulky HODNOTY, ale jak to udělat? Nevíte prosím někdo?

Už je to sice delší dobu, ale hodím sem zjednodušeně, jak jsem to onehdá vyřešil. Kdyby měl třeba někdo návrhy na vylepšení...
Tabulka řádky ceníku obsahuje vazby HODNOT a CENIKU

RADKYCENIKU
id | cenikid | hodnotyid
(1, 5, 20)
(2, 5, 21)
(3, 5, 22)
(4, 5, 23)
(5, 5, 24)

Abych docílil toho, že ke každé kombinaci cenik,faktor,hodnota budu mít jedinečnou cenu, vyberu postupně pomocí JOIN z tabulky RADKYCENIKU řádky týkající se jednoho ceníku a faktorů jednoho po druhém. Tyto selecty potom spojím do jedné tabulky a každý řádek má jako jedinečný klíč kombinaci idček z tabulky RADKYCENIKU (idčka odděluji znakem-třeba "a"). A to natlačím do tabulky ceny.

CENY
id | cena
(a20a22, 8000)
(a20a23, 0)
(a20a24, 0)
(a21a22, 12000)
(a21a23, 0)
(a21a24, 0)

To by mělo korespondovat s uvedenýma příkladama v předchozím příspěvku. Jenom ještě dodám, že je to šité na sortiment, který tento přístup vyžaduje (tzn. do jednoho druhu zboží=ceníku spousta produktů za stejné peníze, ale mají spoustu vlastností, které mění cenu).