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

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

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

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í ;)

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)

-> 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.

jednotku a mnozstvi urcite delit

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.

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...

Promyslím to,
Díky za rady :)

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

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 :)

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 :-)

Původně odeslal mytrix

...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á...

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 :-)

Původně odeslal mytrix

... 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.

Ano, ale to si muzes dovolit u projektu, kde mas jasno, ze udelas a koncis. Pokud je byt teoreticky pozadavek na budouci rozsireni, tak si nenormalizovanou strukturou db zavaris. Rezie je absolutni nesmysl, to resi cache apd.

Jen aby bylo jasno, ja nerikam, ze "slouceni" v tomto pripade neni moznost, ale jen reaguju na argumentaci rezie db a slozitosti dotazu, protoze tato argumentace je naprosto irelevantni.

Původně odeslal mytrix

Jen aby bylo jasno, ja nerikam, ze "slouceni" v tomto pripade neni moznost, ale jen reaguju na argumentaci rezie db a slozitosti dotazu, protoze tato argumentace je naprosto irelevantni.

Spatne pochopeno - rezie db a slozitost dotazu je irelevantni. Co irelevantni neni je zesloziteni ui pro pridavani receptu (o to vic bude vznikat chyb pri zadavani lidmi, o to vic bude prace u redigovani o to vic bude problemu s ne beznymi jednotkami). Obsluha dalsi tabulky vyzaduje take naprogramovani dalsiho kodu, coz zase zeslozituje projekt. Budouci rozsireni je hezka vec, ale vzhledem k tomu ze vetsina projektu se nikdy nedostane k dokonceni prave diky tomu, ze je navrh moc kosaty a programator ztrati nadseni...