Návrh databáze – správné řešení?

21. 8. 2011 21:54:56

Zdravím,

řeším jeden malý problém a nejsem si vůbec jist jestli se mi povedlo se dobrat ke správnému výsledku.

Potřebuji vytvořit databázi receptů s důrazem na to aby každá surovina měl vlastní sloupec aby se dalo podle surovin vyhledávat.

Mám tento návrh:

Data v databázi vypadají takto

edit: ještě doplním jak mají vypadat data ve výsledku

600 g kuřecích prsou

sůl

mletý pepř

4 lžíce tatarské omáčky

2 stroužky česneku

hladká mouka na obalení

olej na smažení

16 cherry rajčátek

2 jarní cibulky

olivový olej

Zajímalo by mě jestli jsem někde neudělal chybu.

P.S. spojování tabulek je jen pro orientaci

Předem díky

21. 8. 2011 21:54:56

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669253

Jiří Adámek

(20 hodnocení)

21. 8. 2011 21:57:48

je to spravne, jen s tim teda, ze suroviny.id_receptu a suroviny.id_surovina museji byt jako slozeny PK.

21. 8. 2011 21:57:48

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669252

toshi

(4 hodnocení)

21. 8. 2011 22:31:21

Je to víceméně správně - jen u users máš samotné "id", u ostatních tabulek "id_tabulka". Názvy tabulek jednou množné jindy jednotné číslo, jednou angličtina, jednou čeština...měl bys to sjednotit.

Druhá, víceméně praktická - pokud bych osobně dělal databázi receptů, tabulku jednotka bych si asi odpustil, přestože to není formálně špatně, bude se ti s tím hůře pracovat a eventuální přínos oddělení množství a jednotky bude nulový (nebo ne?)

Třetí - jestli chceš opravdu takový výsledek tak budeš muset vyřešit i skloňování ;)

21. 8. 2011 22:31:21

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669251

(20 hodnocení)

21. 8. 2011 22:57:02

jak rika toshi - hlavne sjednotit zpusoib nazyvani... tohle je desivy jak je to jendou tak a jednou onak - zkus si udelat db strukturu podle nejakeho ORM, to te nauci dodrzovat jednotne nazvoslovi ;)

---------- Příspěvek doplněn 21.08.2011 v 22:58 ----------

tabulka jednotka lze nahradit type ENUM (a mozna bych ho doporucil bude se hur pridavat nova jednotka - musi se upravit sloupec... ale bude se s tim mnohem lepe pracovat)

21. 8. 2011 22:57:02

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669250

Ondřej Záruba

21. 8. 2011 23:24:13

-> Názvy sjednotím, prezentoval jsem to někomu kdo aj neovládá tak sem to počeštil trochu (zapracovala lenost a něco sem nechal).

-> Id v tabulce user opravím na id_user ať je to jednotné

-> O enum jsem také přemýšlel, ale.... databáze se nebude předvyplňovat. Pokud se přidá recept, který bude obsahovat jinou jednotku (není v db) tak se do db přidá pro příště a tím pádem mi enum nepřišel jako ideální řešení.

-> O tom jestli má smysl jednotky oddělovat jsem přemýšlel, ale nerozhodl jsem se stále jestli dělit množství a jednotku nebo prostě nechat v jedné kolonce.

-> Co se týče skloňování upravím výpis tak, abych se bez toho obešel.

21. 8. 2011 23:24:13

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669249

Jiří Adámek

(20 hodnocení)

21. 8. 2011 23:31:17

jednotku a mnozstvi urcite delit

21. 8. 2011 23:31:17

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669248

toshi

(4 hodnocení)

22. 8. 2011 00:16:52

Já bych se té oddělené jednotce právě vyhnul byť i v ENUMu. Všechno bych nechal v "mnozstvi" , typem string př. "půl lžíce". Ubyde tím jedno pole ve formuláři, zjednoduší se zadávání receptů i samotný kód. Můžeme se sice bavit o záměru vyhledávat recept podle množství surovin v lednici, jenže pak bychom se museli bavit třeba o normalizaci hrníčkových receptů. Pokud tenhle záměr padá není důvod dělit - mimochodem na vareni.cz je 44 různých jednotek.

22. 8. 2011 00:16:52

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669247

(20 hodnocení)

22. 8. 2011 00:50:15

heled reknu to takhle - ne vzdy je nejlepsi na 100% normovat databazi, nekdy si totiz hodne moc usetris praci aniz bys ztracel spousty jinych vyhod pokud misto oddelene tabulky nebo spravneho typu zvolis sloupec nebo jiny trebga i na prvni pohled nespravny typ, nekdy proste vyhody ktere nabizi plne normalizovana databaze nepotrebujes vubec nebo je muzes lehce ozelet a treba te to vyjde i lip, jednoduseji :) takze ja jako toshi jsem asi pro enum (upravu sloupce muzes mj. udelat v podstate stejne jednoduse jako INSERT do jednotek primo z aplikace ;) je to jeden dotaz... ) ale to je samozrejme na tobe - obe reseni budou v tomhle pripade v podstate dobre a nemeli by ani s jendim byt problemy...

22. 8. 2011 00:50:15

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669246

Ondřej Záruba

22. 8. 2011 08:39:49

Promyslím to,

Díky za rady :)

22. 8. 2011 08:39:49

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669245

Jiří Adámek

(20 hodnocení)

22. 8. 2011 09:13:41

No chapu pohnutky, nicmene delat nenormalizovany navrh se vzdycky drive ci pozdeji vymsti. Argumentovat usetrenim tabulky nebo zjednoduseni dotazu je naprosto mimo.

22. 8. 2011 09:13:41

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669244

(20 hodnocení)

22. 8. 2011 09:18:11

mytrix: sice nemuzu rict ze nemas pravdu, ale ani nemuzu na 100% souhlasit - zrovna v tomhle pripade je mj. enum v podstate to same jako samostatna tabulka a je v podstate pro tyhle pripady urcen, navic tim neudelas nenormalizovanou databazi, jen nebude ve vyssi normalni forme :)

22. 8. 2011 09:18:11

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669243

Jiří Adámek

(20 hodnocení)

22. 8. 2011 09:30:09

No to sice moznost je, nicmene je tam horsi podpora ze strany DB. MySQL, PgSQL to podporuje, na druhou stranu napriklad MSSQL, Oracle aj. ne. (ale to je spise teoretickej problem, protoze predpokladam ze to stejne bude php/mysql)

ENUM stejne neni nic jinyho, nez jakysi zjednoduseny druh ciselniku. Je asi na kazdem, jakou cestu si zvoli, ja bych se ji vyhnul :-)

22. 8. 2011 09:30:09

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669242

toshi

(4 hodnocení)

22. 8. 2011 10:02:46

Napsal mytrix;692485
...nenormalizovany navrh se vzdycky drive ci pozdeji vymsti.

Dokážeš říct jak v tomhle konkrétním případě?

Já argumentuji tím, že právě normalizovaný návrh se vymstí, nikoliv v teorii, ale v praxi. Čistý návrh je jedna věc, ale obskurnost receptů druhá...

22. 8. 2011 10:02:46

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669241

Jiří Adámek

(20 hodnocení)

22. 8. 2011 10:54:23

Velice jednoduse. Trebas budu chtit udelat moznost prepoctu jednotek pro uzivatele. :-) A takovych funkci se do budoucna muze objevit cela rada.

A ackoliv se ti to ted muze zdat byt absorudni a muzes si rikat, ze toto bys prece nemohl vyuzit, tak te ujistuju, ze to peklo, ktere bys zazil pozdejsi upravou zaznamu by te z pochyb rychle vylecilo :-)

22. 8. 2011 10:54:23

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669240

duben

(49 hodnocení)

22. 8. 2011 11:01:48

Napsal mytrix;692485
... nenormalizovany navrh se vzdycky drive ci pozdeji vymsti ...

S tímhle rozhodně nelze souhlasit. V řadě případů má normalizace svůj význam a je snaha mít co nejvíc normalizovanou DB. Je ale také spousta případů, kdy snaha normalizace za každou cenu je takové drbání levou rukou přes hlavu za pravým uchem. Záleží na způsobu jak se data budou vkládat a používat. Často se tabulky naopak denormalizují a to z důvodů snažšího reportu, snížení zátěže DB, zbytečné složitosti návrhum který ústí v nesmyslně nákladné kontrole vstupů apod.

Zrovna v tomhle případě si nejsem jistý přínosem oddělení jednotek, protože u vaření se používá tolik možností (1 hrníček, půl lžičky, x deka, dvě hrsti apod.) a často nejsou vzájemně poměřitelné, že je asi jednoduší řešit to textovým polem jak se tu uvádí výše.

S ostatními radami ohledně sjednocení názvosloví taky souhlas, pokud to má být univerzálnější klonil bych se k anglickému názvosloví, pokud pro jeden konkrétní projekt je čeština plně vyhovující.

Pro lepší kontrolu a rady by bylo lepší vidět i datové typy, primární klíče, kde budou indexy a kde bude nebo nebude NULL případně default values.

22. 8. 2011 11:01:48

https://webtrh.cz/diskuse/navrh-databaze-spravne-reseni#reply669239