Det du är ute efter är själva relations delen i relationsdatabaser vilket t.ex mySQL är.
När det kommer till relationsdatabaser så skall du ställa dig frågan om objektet x kan tillhöra flera objekt y eller om objekt y kan innehålla flera av objekt x
I detta fallet är då x ingredienser och y är recept. Och svaret är ja.
Vad du vill ha är en tabell som innehåller recept och allt det som är unikt för det receptet(id, namn, beskrivning) i ditt exempel
Författare och ingredienser är inget som är unikt till det specifika receptet då en författare kan ha flera recept(möjligen även att ett recept kan ha flera författare), samt att ett recept kan ha flera ingredienser, osv.
Detta gör att du vill separera dina författare och ingredienser till egna tabeller som enbart innehåller deras information.
Sedan för att avsluta det hela så vill du ha en kopplingstabell där du binder ihop t.ex recept tabellen med ingrediens tabellen. Här kan du även lägga till sakerna som mängd/vikt/liter
I slutändan vill du alltså ha 3 tabeller(recept, författare, ingrediens) och 2 kopplingstabeller(recept <> författare, recept <> ingrediens).
Det positiva med att separera dessa är att du inte behöver upprepa data men mest utav allt så är författarna och ingredienserna separerade på ett sätt att de har ett eget id, m.m vilket gör att man t.ex kan söka efter recept som innehåller en specifik ingrediens eller är skriven av en specific författare.
Okej detta är ett helt nytt tänk för mig. Då ska jag börja kolla på hur jag gör kopplingstabeller. Att lägga upp databasen på detta sätt hade jag inte alls funderat över. Jag uppskattar förklaringen! Kommer säkert att återkomma med några frågor innan jag har fått detta att fungera men detta har hjälpt mig mycket!
Om jag skulle vilja lägga till hur man ska tillaga recepten, hur skulle du rekommendera att jag gör det?
Håller med Terrell, du bör fundera på vad som är unikt och vad som är generellt. Sen kan man ju gå ganska mycket längre än hans förslag utan att övernormalisera.
Jag hade nog lagt upp det (om jag vill ha allt i en databas) så att recepttabellen är en enkel tabell med namn och id typ, kanske datum och liknande om det är intressant. Alla olika ingredienser ligger i en annan tabell med namn och id typ, kanske annan metadata som inte är så intressant för själva receptet också som kostnad och liknande. Sen kan du ha en tabell med enheter, tesked, liter osv. och id till dessa. Sen en kopplingstabell som säger vilken enhet och hur många av den per ingrediens till ett visst recept, kanske också i vilken ordning denna ingrediens ska visas i receptet. Sen behöver du en tabell med instruktionerna som får ha ett stort textfält för själva texten för varje steg, receptid och ordning som det ska visas (stegId kanske). Författare borde ligga i en egen tabell och id från denna tabell i själva recepttabellen.
Slängde ihop en enkel db nedan. Dock för MS SQL så jag vet inte om allt fungerar precis likadant i MySQL.
CREATE TABLE Författare (
FörfattarID INT IDENTITY,
Förnamn NVARCHAR(100),
Efternamn NVARCHAR(100),
PRIMARY KEY (FörfattarID)
)
CREATE TABLE Recept (
ReceptID INT IDENTITY,
Namn NVARCHAR(40),
FörfattarID INT,
Datum DATETIME,
PRIMARY KEY (ReceptID),
CONSTRAINT FK_ReceptFörfattare FOREIGN KEY (FörfattarID) REFERENCES Författare(FörfattarID)
)
CREATE TABLE Ingredienser (
IngrediensID INT IDENTITY,
Namn NVARCHAR(100),
PRIMARY KEY (IngrediensID)
)
CREATE TABLE Enheter (
EnhetsID INT IDENTITY,
Namn NVARCHAR(40),
PRIMARY KEY (EnhetsID)
)
CREATE TABLE Instruktioner (
ReceptID INT,
StegID INT,
Instruktion NVARCHAR(MAX),
PRIMARY KEY (ReceptID, StegID)
)
CREATE TABLE IngrediensLista (
ReceptID INT,
IngrediensID INT,
EnhetsID INT,
Antal INT,
Ordning INT,
PRIMARY KEY (ReceptID, Ordning),
CONSTRAINT FK_ReceptLista FOREIGN KEY (ReceptID) REFERENCES Recept(ReceptID),
CONSTRAINT FK_IngrediensLista FOREIGN KEY (IngrediensID) REFERENCES Ingredienser(IngrediensID),
CONSTRAINT FK_EnhetLista FOREIGN KEY (EnhetsID) REFERENCES Enheter(EnhetsID)
)
Okej jag ska testa detta och se om det fungerar.
Recept är inte bara ingredienser utan också hur det ska förberedas, tilllagas och eventuellt serveras.
Javascipt är primärt för client side scripting (dvs körs i användarens webläsare), PHP är serverside och körs på webservern. Normalt används php för att hämta data ur databasen.
Datat passar inte att lagras på detta sätt. Bättre att ha en tabell med själva rätten, eller vad det nu är och sedan spara tillagning och ingredienser i ett fält i XML.
Fast i ärlighetens namn skulle jag hellre spara recept i en wiki. När man ska spara någonting i en databas måste man fråga sig varför. Behöver man kunna söka på något och i så fall vad? Inte så ofta man behöver söka efter ingredienser, t ex visa alla maträtter som innehåller gul paprika.
Jag har valt att vilja spara mina recept i en databas för att lära mig hur databaser fungerar och även kunna få ut något från mitt lärande. Att kunna koppla databasen till hemsidor med exempelvis javascript är för att jag har börjat gå in djupare i javascript, både löst men även i tillexempel ReactNative, Meteor mm.
@niterider:
När det kommer till kött så skulle jag påstå att det är bra att kunna söka. T.ex om man har kassler så finns det lite allt möjligt man kan göra.
Det var ännu ett tillägg jag inte tänkt på men skulle uppskatta mycket!
