Autor Zpráva
Martin
Profil
Ahoj,

budu teď dělat jeden internetový obchod a přemýšlím o co nejvhodnějším řešení databáze. Jak se Vám zamlouvá toho řešení:

VYROBCE
id | nazev_vyrobce

KATEGORIE
id | nazev_kategorie

PRODUKTY
id | id_kategorie | typ | vlastnost1 | vlastnost2 | vlastnost3... vlastnostN

Obchod bude přibližně okolo 400 produktů, což není mnoho. Osobně se mi u tohoto návrhu nelíbí, že sloupce "vlastnostX", nejsou pro všechny výrobky ze všech kategorií stejné. Jedna kategorie výrobků může mít jen zlomek vlastností co druhá kategorie výrobků. Vytvoření nové kategorie s novou vlastností by znamenalo přidání nového sloupce vlastnostY. Mám cenu vůbec toho řešit? Jak se s tímto problémem případně vypořádat?
Joker
Profil
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?
joe
Profil
Nejlepší to zrovna není, ale když tam budeš mít jen 400 položek, je prakticky jedno jak to budeš mít.
Alphard
Profil
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
Martin
Profil
Joker
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
joe
Profil
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.
Joker
Profil
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.
tiso
Profil
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
Profil
Joker
I když si to zatím nemyslíme, tak do budoucna se obchod bude rozšiřovat a nikdy nevíme, co všechno přibude. Takže bych volil nějaké obecnější řešení.

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.

takže něco jako

VYROBCE
id | nazev_vyrobce

KATEGORIE
id | nazev_kategorie

PRODUKTY
id | id_kategorie | typ | popis | cena

ROZSIRENE_VLASTNOSTI
id | vlastnost
(1, vykon)
(2, prumer)
(3, palivo)

ROZSIRENE_VLASTNOSTI_PRODUKTU
id | id_produktu | id_vlastnosti | hodnota
Martin
Profil
Pak mě zas trápí, například vlastnost palivo. Palivem může být nafta, benzi, drevo, elektrina nebo kombinace techto ruznych paliv. Měla by se pak vytvořit další tabulka paliva?

PALIVA
id | nazev
(1, elektrina)
(2, drevo)

a v tabulce rozsirene_vlastnosti_produktu zapisovat udaje takto?
ROZSIRENE_VLASTNOSTI_PRODUKTU
id | id_produktu | id_vlastnosti | hodnota
(1, 1, 3, id_paliva - 1)
(2, 1, 3, id_paliva - 2)
tiso
Profil
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
Profil
tiso
ano, to vím. Ale datový typ enum ani set při návrhu popsaným výše použít, hodnoty všech vlastností (i číselných) by byly typu řetězec.
Joker
Profil
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
radas
Profil *
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
Profil
VYROBCE
id | nazev_vyrobce

KATEGORIE
id | nazev_kategorie

PRODUKTY
id | id_kategorie | typ | popis | cena

ROZSIRENE_VLASTNOSTI
id | vlastnost
(1, vykon)
(2, prumer)
(3, palivo)

PALIVA
id | nazev
(1, elektrina)
(2, drevo)

ROZSIRENE_VLASTNOSTI_PRODUKTU
id | id_produktu | id_vlastnosti | hodnota (typ retezec i pro cisla)
(1, 1, 3, id_paliva = 1)
(2, 1, 3, id_paliva = 2)

Tohle řešení se mi zdá zatím nejobecnější, ale úplně se mi nezamlouvá. Napadají Vás ještě jiné možnosti řešení?
Joker
Profil
Martin
hodnota (typ retezec i pro cisla)
Bych tam možná dal číslo...

Ale jinak tohle je asi nejobecnější schéma.
Martin
Profil
Joker
Hodnoty rozšířených vlastností nebudou pouze čísla.

Tabulku paliva pravděpodobně vytvářet nebudu a hodnoty vlastností budu zapisovat takto

ROZSIRENE_VLASTNOSTI_PRODUKTU
id | id_produktu | id_vlastnosti | hodnota (typ retezec i pro cisla)
(1, 1, 3, "dřevo")
(2, 1, 3, "elektřina")

Obdobně s ostatníma vlastnostma typu Palivo.
Martin
Profil
Jak se Vám zamlouvá tento návrh? Co typ produktu (kamna, roury) to nová tabulka.

Mastodont
Profil
PRODUKTY
id | id_kategorie | typ | popis | cena


Tím omezuješ produkt na jedinou kategorii.
Martin
Profil
Mastodont
To měl být původně záměr, ale zamyslím se nad tím. Díky
tiso
Profil
Martin - koľko typov produktu tam budeš mať?
Martin
Profil
tiso
předpokládám, že tak 5. Ale obecně by mě zajímalo, jak návrh řešit pro malý počet typů produktů, tak i pro větší.
Kamna teplovodní, kamna vzdušná, sálavá kamna bych zahrnul do jednoho typu (jedna společná tabulka vlastností). Ale do třech různých kategorií.
tiso
Profil
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
Profil
tiso
Martin - ten návrh je zlý...
můžeš být konkrétnější? Rád bych ty chyby napravil.

1. vzťah produkty:kamna je 1:n?
jeden záznam v tabulce produkty odpovídá jednomu záznamu v tabulce kamna

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..
Návrh je mírně zjednodušený, ale vždy se doberu k "id" produktu a na základě něj jeden konkrétní typ produktu vyberu.

Díky za pomoc
Joker
Profil
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ě.
tiso
Profil
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.
Martin
Profil
tiso
poznám to podle toho, do které kategorie patří, tedy podle id_kategorie
Postup dle bodu 8 vyzouším
Dad
Profil *
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?
Dad
Profil *
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).

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: