Jag ska skapa en databas för en restaurangmeny, men inte riktigt kommit fram till hur jag ska strukturera upp den. Jag känner mig ganska nollställd faktiskt. Databasen ska helst fungera oavsett vilken typ av restaurang det gäller, pizzeria, kina-restaurang etc.
Att jag själv inte alls ofta går på restaurang, förutom en pizza nån gång ibland, gör ju inte saken lättare.
Vad för tabeller ska ingå, och vilka fält bör de innehålla?
Oj va svårt. Är det tänkt att restaurengerna i pluralis skall lägga in sina egna per veckodag? En sorts anslagstavla?
Det är tänkt att en databas ska representera en unik restaurang. Det är väl tänkt att man ska hålla en fast meny, fast man kanske skulle bädda in en Dagens rätt/dagens lunch-tabell?
Hur skall sökkriterierna vara upplagda? Skall man bara söka upp en lämplig restarung och sedan få se hela menyen?
Hur skall den underhållas? Per rätt eller totalt. Visningsordning och priser!
Ta hem ett antal menyer och testa att splittra upp dem i moduler.
Eller vill du ha en färdig Db?
Hur skall sökkriterierna vara upplagda? Skall man bara söka upp en lämplig restarung och sedan få se hela menyen?
Hur skall den underhållas? Per rätt eller totalt. Visningsordning och priser!
Ta hem ett antal menyer och testa att splittra upp dem i moduler.
Eller vill du ha en färdig Db?
Jag kanske bringar lite med klarhet i frågan om jag säger att det rör sig om ett "CMS-system" för en restaurang. Restaurangen(ägaren :p) ska alltså själv kunna uppdatera menyn, som sedan presenteras på hemsidan.
Rent spontant låter det ju som att det skulle räcka med en tabell som innehåller maträtt samt pris. Möjligen skulle man kunna tänka sig ett extra fält som talar om ifall maträtten är dagens rätt idag. Då kanske man vill ha någon liten tabell som anger priset för just dagens rätt. Själv har jag svårt att se varför man skulle ha så mycket mer än så.
Rent spontant låter det ju som att det skulle räcka med en tabell som innehåller maträtt samt pris. Möjligen skulle man kunna tänka sig ett extra fält som talar om ifall maträtten är dagens rätt idag. Då kanske man vill ha någon liten tabell som anger priset för just dagens rätt. Själv har jag svårt att se varför man skulle ha så mycket mer än så.
Jag tänkte mig kanske lite kategorier också, t.ex. förrätt/varmrätt/efterrätt, eller kötträtt/fiskrätt etc.
Och om man ska ha med en dagens rätt-funktion vore det ju smidigt om man kunde skriva in en vecka i förväg.
Jag tänkte mig kanske lite kategorier också, t.ex. förrätt/varmrätt/efterrätt, eller kötträtt/fiskrätt etc.
Och om man ska ha med en dagens rätt-funktion vore det ju smidigt om man kunde skriva in en vecka i förväg.
Ok. Ett uppslag:
Maträtt
matId
namn
pris
kategoriId (FK)
Kategori
kategoriId
namn
Dagens rätt
dagId
pris
Dagens namn
matId (FK)
Sedan får någon krånglig sql-fråga sammanställa kategorier, samt skilja ut den maträtt som är dagens rätt, för att hämta in det speciella "dagens rätt"-priset.
Sedan får någon krånglig sql-fråga sammanställa kategorier, samt skilja ut den maträtt som är dagens rätt, för att hämta in det speciella "dagens rätt"-priset.
Låter som en bra början att utgå ifrån, tackar :) Men nu är jag inte alls insatt i det här med databaser och MySQL. Vad är FK?
FK är foreign key. Dess uppgift är att referera till en primärnyckel. Det ger databasen en viss kontroll när du raderar poster. Då kan den se om det finns poster i andra tabeller som refererar till just den posten du försöker radera. Jag vet inte om det går att ställa in i MySQL så att vissa fält är FK. Men du kan helt klart använda fält som om de vore FK. Skillnaden är att du då inte har den kontrollen när du raderar poster.
266 ms totalt · 4 externa anrop · v20260731065814-full.e96017d9
