Struktur på en receptdatabas

Hej!

Skulle vilja ha lite tips på hur en databas för recept skulle se ut.
Jag har idag en tabell med ingredienser

Sen hade jag tänkt mig en tabell med själva receptet

eventuellt

Om jag skulle göra så så känns det som om jag begränsar mig till ett visst antal ingredienser.
En tabell för varje recept är väl inte riktigt optimalt?

Tar gärna emot tips

Mvh

Nackdelen med din design är att den kanske fungerar för enkel svensk husmanskost, men om man introducerar ett recept med många ingredienser kanske dina kolumner inte räcker till.

Är det nödvändigt att kunna filtrera / söka recept baserat på ingredieninnehåll? Om inte klarar du dig kanske bra med ingredienserna som ett textfält precis som tillagningsmetoden.

Smidigast känns väl att ha huvudsakligen tre tabeller, en för receptinformation (titel, skapare, tillagningssätt osv), en för ingredienser (Mjölk, nötfärs...), en för receptets tillhörande ingredienser.

Recepttabellen innehåller något i stil med recept_id, recept_namn, recept_skapare, recept_tillagningstid, recept_anvisningar, recept_antal_portioner osv...

Ingredienstabellen innehåller ingrediens_id- och ingrediens_namn-fält. Eventuellt något typ- och viktmåttsbestämningsfält (ingrediens_is_vegan, ingrediens_weight_type osv) också.

Tabellen för receptets tillhörande ingredienser består slutligen av något liknande parent_recept_id, ingrediens_id, ingrediens_kvantitet

På så sätt kan du hämta ut information om receptet från din recept-tabell, sedan hämtar du ingredienslistan från receptingredienstabellen där parent_recept_id motsvarar recept_id i recept-tabellen och ingrediens_id motsvarar en ingrediens i ingrediens-tabellen, kvantitet/mängd bestäms av ingrediens_kvantitet och vikt/måttenhet från ingredienstabellen.

Alternativt skippar du den tredje tabellen som håller receptingredienserna helt och hållet och bestämmer att om parent_recept_id är 0/NULL så är det recept-metainformationen, annars är det en ingrediens tillhörande ett recept.

Läs på om normaliserade databaser. Codds regler.
Då inser du att receptets namn och ingrediens inte är samma tabell.

Innehållet bör ligga in strukturtabell


Aldrig aldrig ingrediens 1 2 3 osv i samma tabell

Tack för din input.
Jag har inte ens tänkt på det men i receptDataBas v1.0 kommer jag lägga ingredienser m.m. i ett textfält som du skriver.

I version 2 skall jag fundera lite på din andra variant

Åter igen tack för inlägg

Mvh

Skall kolla upp det.

Mvh

Medan du får göra precis hur du vill skulle jag nästan rekommendera dig att lägga en kväll eller två extra på design av databasstrukturen och implementering liknande något åt det hållet jag beskrev redan från början.

Nu vet jag inte riktigt vad syftet är för dig, men en tumregel är att du tjänar på att göra 'rätt' från början och den tid du lägger ner på vettig databasdesign får du tillbaka senare jämfört med om du ska omstrukturera tabellerna, flytta datat, skriva om SQL-satser och presentationslogik i din applikation när du väljer att "uppdatera" din applikation.

Jag vill ju göra rätt från början, lite därför jag ställde frågan här
Jag skall absolut lägga ner några kvällar på att fundera på strukturen av databasen.
Nu har jag ju lite att gå på och fundera på och fått lite idéer

Mvh

Precis som beskrivits ovan då har du en många-till-många relation mellan recept och ingredienser.

Ett recept kan innehålla många ingredienser, och en ingrediens kan ingå i många recept.

Då behövs en CrossReference tabell (CR tabell)
https://en.m.wikipedia.org/wiki/Many...y_(data_model)

Om du nu vill vara lite smart så inför du också en mängdkolumn i CR tabellen och en tabell med måttenheter.

CR tabellen blir då:
recepie_id int,
ingredient_id int,
amount decimal,
unit_id int


Units är typ: deciliter, tesked, cup osv.

Det skall naturligtvis vara möjligt att göra recept som innehåller både deceliter socker, matskedar socker och teskedar socker.

Lite sent kanske men jag skulle rekommendera att använda en "Graph Database" (t.ex. https://neo4j.com).

I en grafdatabas länkar man ihop olika "nodes" med "edges". På så sätt kan man skapa djupa strukturer/relationer som går extremt snabbt att få tillbaka med en query.

ex struktur.



Nu länkar man alla recept som innehåller ägg med en edge som beskriver antal till ägg noden. Då kan man ställa en query som listar alla recept som innehåller ägg.

Kanske aningen overkill att bygga en receptdatabas med grafer men det är faktiskt både enklare och antagligen mer logiskt att göra så.
Sedan kan man också skapa noder för användare och länka vilka användare som har skapat vilka recept och vilka användare som gillar vilka recept etc. Man kan ju också skapa själva recept beskrivningen med noder/länkar som beskriver i vilken ordning man skall göra vad.

Tack!
Skall kolla upp det

Mvh

Jag skulle nog ha en tabell för ingredienser (mjölk, mjöl, salt etc), en tabell för mått (matsked, dl, gram etc), en tabell för receptet i sig (receptnamn och receptinstruktion, hur allt ska tillredas) och en kopplingstabell där man kopplar ihop ingredienser och mått med receptet.

Lägga till kolumner är inga större problem i en version 2 med databaser.

Relationsdatabaser är fantastiska men de har en mycket stor nackdel och det är feldesign i databasstrukturen. Fantastiskt krävande att byta design i en databas om man har ny version på gång.

Gör allt du kan för att göra rätt på första försöket. Det enda du kan slarva med är att inte ha tillräckligt med kolumner, de är lätta att lägga till i efterhand.