[PHP && MySQL] Databasdesign; initial data i php-klasser eller i databasen?

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011

[PHP && MySQL] Databasdesign; initial data i php-klasser eller i databasen?

Hejsan, önskar råd kring hur jag bör tänka gällande designen av min webbapplikation.
Använder mig av php och en MySQL-databas. Själva applikationen kommer bestå mestadels av ett formulär via vilket användare kan söka samt lägga in information. Säg att det handlar om recept, man skall kunna söka efter recept baserat på ingridienser, lägga till egna etc.

Vissa av dessa värden kommer att finnas redan innan applikationen tas i bruk. Till exempel typ av recept; förrätt, huvudrätt, efterrätt, mellanmål. Även en del ingridienser kommer finnas men användare skall kunna lägga till fler vid behov.

Har tidigare inte alls varit bekväm med databaser och hade således alla "fasta" värden i respektive php-klass. Nu när jag även har implementerat en databas blir jag konfunderad över hur jag bör göra.

Som det ser ut nu har jag en recept-tabell med över 10 kolumner som nästan alla har foreign keys till tabeller med "statisk" data. Det resulterar i väldigt många tabeller, och jag har bara skrivit en klass än så länge.

Update: Inser ju att jag kommer behöva ha alla dessa tabeller även om datan initialt finns i php-klassen... Skall det verkligen se ut så eller finns det ett bättre sätt? Håller hårt på DRY-principen...

Har kollat på tidigare WP-installationer och har nog redan fler tabeller i databasen... Dock läste jag att WP är ett exempel på "icke-bra" databasdesign.

Jag räknar med att behöva skala till en "medelstor" applikation men just nu vill jag bara få den up and running. Dock är säkerhet och skalbarhet något jag vill få med i processen så att säga.

Så, initial data i tabeller eller i klasser? Gissar att det kan variera, motivera gärna när det ena eller andra är bättre.

Mvh

Trädvy Permalänk
Medlem
Plats
i din garderob
Registrerad
Sep 2007
Skrivet av Lakritsugglan:

Hejsan, önskar råd kring hur jag bör tänka gällande designen av min webbapplikation.
Använder mig av php och en MySQL-databas. Själva applikationen kommer bestå mestadels av ett formulär via vilket användare kan söka samt lägga in information. Säg att det handlar om recept, man skall kunna söka efter recept baserat på ingridienser, lägga till egna etc.

Vissa av dessa värden kommer att finnas redan innan applikationen tas i bruk. Till exempel typ av recept; förrätt, huvudrätt, efterrätt, mellanmål. Även en del ingridienser kommer finnas men användare skall kunna lägga till fler vid behov.

Har tidigare inte alls varit bekväm med databaser och hade således alla "fasta" värden i respektive php-klass. Nu när jag även har implementerat en databas blir jag konfunderad över hur jag bör göra.

Som det ser ut nu har jag en recept-tabell med över 10 kolumner som nästan alla har foreign keys till tabeller med "statisk" data. Det resulterar i väldigt många tabeller, och jag har bara skrivit en klass än så länge.

Update: Inser ju att jag kommer behöva ha alla dessa tabeller även om datan initialt finns i php-klassen... Skall det verkligen se ut så eller finns det ett bättre sätt? Håller hårt på DRY-principen...

Har kollat på tidigare WP-installationer och har nog redan fler tabeller i databasen... Dock läste jag att WP är ett exempel på "icke-bra" databasdesign.

Jag räknar med att behöva skala till en "medelstor" applikation men just nu vill jag bara få den up and running. Dock är säkerhet och skalbarhet något jag vill få med i processen så att säga.

Så, initial data i tabeller eller i klasser? Gissar att det kan variera, motivera gärna när det ena eller andra är bättre.

Mvh

Om din applikation använder sig av en databas finns det ingen anledning till att inte ha all data i den. Det blir bara konstigt om du har viss data hängandes i en PHP-fil nånstans — om jag tolkar dig rätt. Något du bör tänka på är hur du sätter upp datan initialt, det vill säga hur du går från helt nyinstallerad app med tom databas till fungerande skick. Problemet är redan löst i form av en teknik som kallas Schema migrations.

Med migrations beskriver du strukturella förändringar av databasen; hur tabeller och kolumner läggs till, ändras och tas bort i fall du skulle behöva backa tillbaka databasschemat till ett tidigare skede. Den första migreringen definierar en/flera/alla tabeller du tror du kommer behöva sätts upp, medan en följande migration innehåller inmatningar av den grundläggande data du efterfrågar.

För Java-projekt brukar jag rekommendera flyway. Vet inte vad som rekommenderas för PHP men det finns säkerligen något trevligt där ute om du letar.

Bilanaloger är som Volvo — varenda svenne kör med dem

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011
Skrivet av Teknocide:

Om din applikation använder sig av en databas finns det ingen anledning till att inte ha all data i den. Det blir bara konstigt om du har viss data hängandes i en PHP-fil nånstans — om jag tolkar dig rätt. Något du bör tänka på är hur du sätter upp datan initialt, det vill säga hur du går från helt nyinstallerad app med tom databas till fungerande skick. Problemet är redan löst i form av en teknik som kallas Schema migrations.

Med migrations beskriver du strukturella förändringar av databasen; hur tabeller och kolumner läggs till, ändras och tas bort i fall du skulle behöva backa tillbaka databasschemat till ett tidigare skede. Den första migreringen definierar en/flera/alla tabeller du tror du kommer behöva sätts upp, medan en följande migration innehåller inmatningar av den grundläggande data du efterfrågar.

För Java-projekt brukar jag rekommendera flyway. Vet inte vad som rekommenderas för PHP men det finns säkerligen något trevligt där ute om du letar.

Hej, tack för ett jättebra svar. Uttryckte mig nog lite slarvigt, all "receptdata" kommer ju att finnas i databasen, så småningom, när applikationen tas i bruk. Min fråga är om jag helt sonika bör skriva in allt i databasen manuellt eller det som jag är inne på, att lägga logiken (men även den initiala datan) i php-klasser som sedan lägger in datan i databasen på "uppstart" av applikationen. Vill göra det så skalbart och transportabelt som möjligt. Då kanske jag har tänkt rätt men inte haft kunskap om den teknik som finns. Skall kolla upp migrations!

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011

@Teknocide: Hej igen, har läst Wiki-sidan om schema migrations och verkar helt klart vara värt att sätta sig in i. Mitt liv blev så mycket bättre när jag upptäckte Git och gissar att detta är samma princip.
Läste att man kan köra schema migrations även med Git men det kanske inte är en rekommenderad lösning?
Just nu kör jag:

mysqldump -uu -pp --no-data my_db > ~/www/my_project/dump_structure.sql mysqldump -uu -pp --no-create-info --ignore-table=my_db.data my_db >> ~/www/my_project/dump_structure.sql

varje gång jag uppdaterar strukturen och commit:ar sedan .sql-filen. Är det lite som schema migration? Alla tabeller förutom den angivna innehåller "statisk" data, dvs sådant som bör finnas initialt. Därför har jag valt att inte spara datan i tabellen data, i syfte att kunna replikera databasens grundläge vid behov. Kan detta ses som schema migrations eller är det mer komplicerat med behov av speciella verktyg för ändamålet?

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
i din garderob
Registrerad
Sep 2007
Skrivet av Lakritsugglan:

@Teknocide: Hej igen, har läst Wiki-sidan om schema migrations och verkar helt klart vara värt att sätta sig in i. Mitt liv blev så mycket bättre när jag upptäckte Git och gissar att detta är samma princip.
Läste att man kan köra schema migrations även med Git men det kanske inte är en rekommenderad lösning?
Just nu kör jag:

mysqldump -uu -pp --no-data my_db > ~/www/my_project/dump_structure.sql mysqldump -uu -pp --no-create-info --ignore-table=my_db.data my_db >> ~/www/my_project/dump_structure.sql

varje gång jag uppdaterar strukturen och commit:ar sedan .sql-filen. Är det lite som schema migration? Alla tabeller förutom den angivna innehåller "statisk" data, dvs sådant som bör finnas initialt. Därför har jag valt att inte spara datan i tabellen data, i syfte att kunna replikera databasens grundläge vid behov. Kan detta ses som schema migrations eller är det mer komplicerat med behov av speciella verktyg för ändamålet?

Skickades från m.sweclockers.com

Backups och migrations är inte likvärdiga: En backup beskriver ett totalt tillstånd i databasen medan migrations beskriver inkrementella förändringar i databasens struktur. En backup som bara innehåller rådata (INSERTs) kompletterar migrations väl.

Migrations gör det möjligt att rulla databasens struktur fram eller tillbaka till ett givet skede utan att behöva ta bort någon data. En enskild migration kan exempelvis beskriva ett namnbyte på en kolumn; vad kolumnen hette tidigare samt vad kolumnen kommer heta fortsättningsvis (kolumnen kan komma att ändras igen av en senare migration).

Precis som du uppmärksammar är det rätt likt hur Git fungerar: en Git-commit beskriver förändringen i en filstruktur medan en migration beskriver förändringen i en databas. Migrations versionshanteras precis som andra filer i ett projekt.

Bilanaloger är som Volvo — varenda svenne kör med dem

Trädvy Permalänk
Medlem
Registrerad
Okt 2011
Skrivet av Lakritsugglan:

Hej, tack för ett jättebra svar. Uttryckte mig nog lite slarvigt, all "receptdata" kommer ju att finnas i databasen, så småningom, när applikationen tas i bruk. Min fråga är om jag helt sonika bör skriva in allt i databasen manuellt eller det som jag är inne på, att lägga logiken (men även den initiala datan) i php-klasser som sedan lägger in datan i databasen på "uppstart" av applikationen. Vill göra det så skalbart och transportabelt som möjligt. Då kanske jag har tänkt rätt men inte haft kunskap om den teknik som finns. Skall kolla upp migrations!

Skickades från m.sweclockers.com

Det där låter fel. Lägg in datan manuellt i databasen, det kan du göra via något verktyg som phpMyAdmin (installeras på webservern) eller ett HeidiSQL (windows program).

Om du redan har datan i tex .csv format eller liknande kan det kanske gå att skriva ett php skript som läser in filen och sätter in datan i databasen automatiskt. Kan vara värt om det är väldigt mycket data du måste sätta in. Detta skript kör du alltså en gång, sen är datan i databasen. Data försvinner inte från databasen om du inte själv raderar den.

Programmerare -> PHP | HTML | CSS | JS | Java.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011
Skrivet av Sony?:

Det där låter fel. Lägg in datan manuellt i databasen, det kan du göra via något verktyg som phpMyAdmin (installeras på webservern) eller ett HeidiSQL (windows program).

Om du redan har datan i tex .csv format eller liknande kan det kanske gå att skriva ett php skript som läser in filen och sätter in datan i databasen automatiskt. Kan vara värt om det är väldigt mycket data du måste sätta in. Detta skript kör du alltså en gång, sen är datan i databasen. Data försvinner inte från databasen om du inte själv raderar den.

Hej, skall försöka vara lite tydligare. Med "manuellt" avser jag just att lägga in datan i databasen "direkt", via PhpMyAdmin, mysql-prompten eller annat utan att blanda in övriga delar av applikationen.
Nackdelen med det, som jag ser det, är att det inte är så "portabelt" om jag vill göra ett liknande projekt med andra tabellnamn etc. Det känns inte heller rätt att lyfta skapandet av databasen "utanför" projektet.
Alternativet tänker jag är att skriva in datan direkt i respektive klass och lägga till den därifrån. Då hänger iaf databasen mer ihop med det aktuella projektet. Eller? =S
Tänker något i stil med exemplet nedan:

<?php class Dish { protected $types; // array protected $type; // string protected $name; // string public function __construct($name, $type) { // set types $this->types = array( 'starter' => 'Förrätt', 'main' => 'Huvudrätt', 'dessert' => 'Efterrätt', 'snack' => 'Mellanmål' ); // Create table dish_type if not exists // insert data if not duplicate ... $this->name = $name; $this->type = (array_search($type, $this->types)) ? $type : false; // select id from dish_type where type = $type $id = ... // create table dish if not exists // if name and type are valid, insert data // col type_ = $id ... // ny rätt med namn $name, type $type och type_id $id har lagts till i databasen } }

Hur påverkas "performance" av att extra filer läses in? Kan obehagligt lite om de här delarna men vill göra "rätt", så gott det går. En del får jag lära mig genom trial and error, men om något verkar alldeles galet uppskattar jag om det påpekas förstås.

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Järfälla
Registrerad
Jan 2004

Skulle fundera på vad det är du vill uppnå. Hur ska man kunna söka i databasen? Hur ska man sortera? Lista ur strukturen på databasen utifrån detta.

Detta skulle jag kunna tänka mig att jag vill kunna söka på i en receptdatabas:
- Jag vill ha en förrätt med fisk (även kunna specificera vilken fisk), tillagningstid ca 20 minuter.
- Jag har daddlar, bacon och fetaost hemma, finns det något recept med det? Den måste vara lättlagad!
- Jag vill laga en barnvänlig rätt på köttfärs.

Utgå ifrån någonting sådant, sedan när du har kommit på en initial databasdesign lägger du in den informationen du redan har så att den passar den layouten. Detta kan du så klart ha ett skript för. Som du skrev i ditt tidigare inlägg är det ju smart att lägga in de typer av dish_type som normalt finns i början. Är det hårdkodat någonstans blir det extremt jobbigt om man i senare skede vill lägga in till exempel "snittar" eller dylikt.

En fråga man kan ställa sig är, vad för egenskaper har ett recept?
- Det har ingredienser, ok, vad för egenskaper har ingredienser (namn, typ av råvara (fisk,kött,spannmål) m.m)?
- Den tar en viss tid att laga.
- Det krävs vissa redskap kanske?
- m.m

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011
Skrivet av trexake:

Skulle fundera på vad det är du vill uppnå. Hur ska man kunna söka i databasen? Hur ska man sortera? Lista ur strukturen på databasen utifrån detta.

Detta skulle jag kunna tänka mig att jag vill kunna söka på i en receptdatabas:
- Jag vill ha en förrätt med fisk (även kunna specificera vilken fisk), tillagningstid ca 20 minuter.
- Jag har daddlar, bacon och fetaost hemma, finns det något recept med det? Den måste vara lättlagad!
- Jag vill laga en barnvänlig rätt på köttfärs.

Utgå ifrån någonting sådant, sedan när du har kommit på en initial databasdesign lägger du in den informationen du redan har så att den passar den layouten. Detta kan du så klart ha ett skript för. Som du skrev i ditt tidigare inlägg är det ju smart att lägga in de typer av dish_type som normalt finns i början. Är det hårdkodat någonstans blir det extremt jobbigt om man i senare skede vill lägga in till exempel "snittar" eller dylikt.

En fråga man kan ställa sig är, vad för egenskaper har ett recept?
- Det har ingredienser, ok, vad för egenskaper har ingredienser (namn, typ av råvara (fisk,kött,spannmål) m.m)?
- Den tar en viss tid att laga.
- Det krävs vissa redskap kanske?
- m.m

Hejsan, tack för kloka synpunkter. Har en ungefärlig uppfattning om de olika egenskaperna men satte mig nu med ett A2-block och färgpennor... Inser att jag har prefix på mina tabeller, typ dish_ingredients, vilka motsvarar namespaces i applikationen. Är detta helt galet?
För att göra mitt liv lite mer besvärligt har jag börjat titta på användandet av flera databaser i samma applikation... Jag tänkte att det lika gärna kan stå dish.ingredients och så behöver jag bara använda prefix när jag skall "utanför" den aktuella databasen.

Det kommer bli djävulskt många tabeller då jag verkligen vill att man skall kunna göra grundliga sökningar och det känns som att jag gör fel men vet inte hur man skulle göra annars. Är flera databaser helt fel väg att gå?

Detta är ju ett hobbyprojekt och inte på liv och död så gör det mest för att lära mig. Dock skulle jag ha nytta av en sådan typ av applikation så är ju bra om den blir bra så att säga.

Spontant vill jag samla rätter i en databas, administration i en, användarinfo i en tredje. Men kommer det resultera i att det blir segt som sjutton eller finns det andra stora nackdelar med den arkitekturen? Har försökt leta information men hittar case där folk fågar om en databas per användare, det är dock inte min initiala tanke.

Mvh

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Registrerad
Okt 2011
Skrivet av Lakritsugglan:

Det kommer bli djävulskt många tabeller då jag verkligen vill att man skall kunna göra grundliga sökningar och det känns som att jag gör fel men vet inte hur man skulle göra annars. Är flera databaser helt fel väg att gå?

Låter galet att ha flera databaser för ditt ändamål.

Varför skulle det bli djävulskt många tabeller? Du ska göra en recept hemsida, borde det inte bli något i den här stilen (3 tabeller):

recipe id | name | type | description | created_at 0 | Köttfärs sås | main | Jätte god Italienskt köttförssås som bla bla bla | 2016-01-11 19:37 ... recipe_ingredients id | recipe_id | ingredient | amount | suffix 0 | 0 | köttfärs | 2 | kg 1 | 0 | tomatpuré | 1 | burk 2 | 0 | peppar | 4 | kryddmått ... recipe_instructions id | recipe_id | instruction 0 | 0 | Blanda tomatpure med blablalba 1 | 0 | Stek köttfärsen 2 | 0 | Koka pasta ...

(sen kan man lägga till fler saker så som bild, författare, betyg, osv)

Med ovan tabellstruktur skulle du kunna skapa en hemsida som är väldigt lik tex recept.nu.

Programmerare -> PHP | HTML | CSS | JS | Java.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011
Skrivet av Sony?:

Låter galet att ha flera databaser för ditt ändamål.

Varför skulle det bli djävulskt många tabeller? Du ska göra en recept hemsida, borde det inte bli något i den här stilen (3 tabeller):

recipe id | name | type | description | created_at 0 | Köttfärs sås | main | Jätte god Italienskt köttförssås som bla bla bla | 2016-01-11 19:37 ... recipe_ingredients id | recipe_id | ingredient | amount | suffix 0 | 0 | köttfärs | 2 | kg 1 | 0 | tomatpuré | 1 | burk 2 | 0 | peppar | 4 | kryddmått ... recipe_instructions id | recipe_id | instruction 0 | 0 | Blanda tomatpure med blablalba 1 | 0 | Stek köttfärsen 2 | 0 | Koka pasta ...

(sen kan man lägga till fler saker så som bild, författare, betyg, osv)

Med ovan tabellstruktur skulle du kunna skapa en hemsida som är väldigt lik tex recept.nu.

Tack för input! Misstänkte att det vore overkill med flera databaser men hade varit kul att testa någon gång, eller en NoSQL db och en relationsdatabas...

Jadu, är uppe i 17 tabeller och då är det minimum det osm krävs för att presentera en "rätt", exklusive användardata... Så det känns ju som att något är fel men vet inte hur jag skall göra annars. Det är en hel del "små" tabeller som innehåller statiska värden att länka med rätten. Typ kategori etc. Sedan har en del "ingredienser" en radda egenskaper som de inte delar med andra, vilket gör att det behövs än fler tabeller för att länka dessa egenskaper. Så som sagt, 17 and counting...

Angående ditt exempel; jag har gjort en fristående motsvarande ingredient-tabell som länkas med respektive rätt genom en "kopplingstabell" (kommer inte på vad de heter..) som endast innehåller dish_id och ingredient_id (primary key). Detta då en rätt kan ha flera ingredienser och olika rätter kan ha samma ingredienser, dvs many-to-many. För att få ihop amount och suffix skulle jag göra en hög nya tabeller.... En för att hålla enheter/suffix, en för att koppla ihop ingrediens med amount och suffix som "receptspecifik ingrediens" och en tredje för att slutligen koppla den "färdiga" ingrediensen till receptet/rätten.
Det var kanon att du uppmärksammade mig på detta då jag har ett liknande scenario i min applikation och har inte haft en tanke på det förrän du skickade exemplet.

Är osäker på om min tilltänkta lösning ang just amount/suffix är rätt men har lärt mig att man skall ha "kopplingstabeller" för att undvika att data upprepas. Det skall bidra till normalization men det kanske finns en gräns där det stjälper snarare än hjälper?

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011

Har nu experimenterat med "amount och suffix" enligt Sony?s exempel ovan.

Det blev ännu fler tabeller...

dish_ingredient ------------------------ dish_id : int(10) ingredient_id : int(10) amount : tinyint(2) suffix_id : tinyint(2) PRIMARY KEY (dish_id, ingredient_id) suffix ------------------------ id : tinyint(2) name : varchar(20)

I min applikation är jag nu uppe i över 20 tabeller... Detta alltså endast för att presentera ett "recept". Många av dessa läser jag endast ifrån, innehållet är statiskt och ändras inte i applikationen.
Det kommer ju krävas löjligt många JOINs för att få ihop ett recept att visa. Finns det ett vettigare sätt att göra detta på? Det kan variera väldigt vilka egenskaper de olika entiteterna har så är svårt att representera med endast rader och kolumner. Har som sagt kollat liiite på NoSQL men är osäker på om det är vad jag söker. Misstänker att jag främst behöver en vettig databasdesign...

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Järfälla
Registrerad
Jan 2004
Skrivet av Lakritsugglan:

Har nu experimenterat med "amount och suffix" enligt Sony?s exempel ovan.

Det blev ännu fler tabeller...

dish_ingredient ------------------------ dish_id : int(10) ingredient_id : int(10) amount : tinyint(2) suffix_id : tinyint(2) PRIMARY KEY (dish_id, ingredient_id) suffix ------------------------ id : tinyint(2) name : varchar(20)

I min applikation är jag nu uppe i över 20 tabeller... Detta alltså endast för att presentera ett "recept". Många av dessa läser jag endast ifrån, innehållet är statiskt och ändras inte i applikationen.
Det kommer ju krävas löjligt många JOINs för att få ihop ett recept att visa. Finns det ett vettigare sätt att göra detta på? Det kan variera väldigt vilka egenskaper de olika entiteterna har så är svårt att representera med endast rader och kolumner. Har som sagt kollat liiite på NoSQL men är osäker på om det är vad jag söker. Misstänker att jag främst behöver en vettig databasdesign...

Skickades från m.sweclockers.com

Skriv gärna ner din design, 20 tabeller låter som lite överkill för att skapa denna typ av applikation, men om de har ett bra syfte så varför inte. Utifrån vad jag nämnde tidigare tror jag att följande skulle kunna fungera:

recepie
- id
- recepie_type_id
- name
- description

ingredients
- id
- råvara_id (typ av råvara)
- name
- suffix

råvaror
- id
- name
- description

recepie_types
- id
- name

tags
- id
- recepie_id
- name

Sedan någon tabell som kopplar ihop ingredients med recepten:

recepie_ingretients
- id
- recepie_id
- ingredient_id
- amount

Kanske vill man också ha en separat tabell med tags och en som kopplar ihop dem med receptet. Har inte hållt på så mycket med databaser, men utifrån detta borde man kunna söka på det mesta. Typ:

Jag har 300g köttfärs hemma och 2 gula lökar, finns det något recept som är baserat på det?

Här finns ett enkelt exempel på relationsdatabaser:
http://www.cs.indiana.edu/classes/a114-dger/lastYear/flights....

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011
Skrivet av trexake:

Skriv gärna ner din design, 20 tabeller låter som lite överkill för att skapa denna typ av applikation, men om de har ett bra syfte så varför inte. Utifrån vad jag nämnde tidigare tror jag att följande skulle kunna fungera:

recepie
- id
- recepie_type_id
- name
- description

ingredients
- id
- råvara_id (typ av råvara)
- name
- suffix

råvaror
- id
- name
- description

recepie_types
- id
- name

tags
- id
- recepie_id
- name

Sedan någon tabell som kopplar ihop ingredients med recepten:

recepie_ingretients
- id
- recepie_id
- ingredient_id
- amount

Kanske vill man också ha en separat tabell med tags och en som kopplar ihop dem med receptet. Har inte hållt på så mycket med databaser, men utifrån detta borde man kunna söka på det mesta. Typ:

Jag har 300g köttfärs hemma och 2 gula lökar, finns det något recept som är baserat på det?

Här finns ett enkelt exempel på relationsdatabaser:
http://www.cs.indiana.edu/classes/a114-dger/lastYear/flights....

Hejsan, många (de flesta?) är alltså "statiska" tabeller och i vissa kan användaren lägga till värden. Har bland annat två eller tre tabeller för olika kategorier, en för färg, en för prisgrupp, en för märke osv. Så det blir ju en del. Är lite mer invecklat än en vanlig receptdatabas och det är alltså inte recept jag skall spara men det dög som jämförelse.

Har börjat kladda upp alla tabeller på två A2-ark, eller menar du att jag skall skriva här i tråden?

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Registrerad
Okt 2015

Jag hade sett om jag kan hitta ett ORM typ http://propelorm.org/ första på google. Mycket lättare när man ska hämta och ta ut saker ur databasen.

Trädvy Permalänk
Medlem
Registrerad
Okt 2011

Inte läst igenom allt nu, men skulle hjälpa om du skrev ner alla tabeller här.

Angående normalisering så ska du inte normalisera så mycket det bara går. Det är aldrig bra. Tänk efter själv; hur mycket extra utrymme tar det att spara dubbell data? Hur mycket enklare blir mina SQL frågor? Varje join du slipper sparar mycket tid. Speciellt steget från 0 JOINS till 1 JOIN.

Detta till exempel:

dish_ingredient ------------------------ dish_id : int(10) ingredient_id : int(10) amount : tinyint(2) suffix_id : tinyint(2) PRIMARY KEY (dish_id, ingredient_id) suffix ------------------------ id : tinyint(2) name : varchar(20)

Gör om det till:

dish_ingredient ------------------------ dish_id : int(10) ingredient_id : int(10) amount : tinyint(2) suffix: varchar(20) PRIMARY KEY (dish_id, ingredient_id)

Hur många ingredienser finns det? Kanske max 100.000?
Då tar det max 100.000*21 = 2.1 MB, vilket i praktiken inte är någonting. Finns liksom hårddiskar på TB idag. Vi har inte floppy diskar längre. Ställ 2.1 MB mot mycket komplexare kod och långsammare SQL frågor. Valet är enkelt.

btw vad är dish_id och ingredient_id?
Känns som att du borde kunna lägga amount och suffix i någon av de tabellerna.

Programmerare -> PHP | HTML | CSS | JS | Java.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011
Skrivet av for_each_while:

Jag hade sett om jag kan hitta ett ORM typ http://propelorm.org/ första på google. Mycket lättare när man ska hämta och ta ut saker ur databasen.

Tack för input, har kollat lite på olika ORM men meningarna om huruvida det är något att ha tycks gå isär. Skall dock kika lite mer på RedBean och se om det kan vara något.

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jun 2011
Skrivet av Sony?:

Inte läst igenom allt nu, men skulle hjälpa om du skrev ner alla tabeller här.

Angående normalisering så ska du inte normalisera så mycket det bara går. Det är aldrig bra. Tänk efter själv; hur mycket extra utrymme tar det att spara dubbell data? Hur mycket enklare blir mina SQL frågor? Varje join du slipper sparar mycket tid. Speciellt steget från 0 JOINS till 1 JOIN.

Detta till exempel:

dish_ingredient ------------------------ dish_id : int(10) ingredient_id : int(10) amount : tinyint(2) suffix_id : tinyint(2) PRIMARY KEY (dish_id, ingredient_id) suffix ------------------------ id : tinyint(2) name : varchar(20)

Gör om det till:

dish_ingredient ------------------------ dish_id : int(10) ingredient_id : int(10) amount : tinyint(2) suffix: varchar(20) PRIMARY KEY (dish_id, ingredient_id)

Hur många ingredienser finns det? Kanske max 100.000?
Då tar det max 100.000*21 = 2.1 MB, vilket i praktiken inte är någonting. Finns liksom hårddiskar på TB idag. Vi har inte floppy diskar längre. Ställ 2.1 MB mot mycket komplexare kod och långsammare SQL frågor. Valet är enkelt.

btw vad är dish_id och ingredient_id?
Känns som att du borde kunna lägga amount och suffix i någon av de tabellerna.

Problemet med den nya tabellen är att jag inte har någon kontroll över innehållet i amount-kolumnen. Om jag har de statiska värdena i en egen tabell och gör en foreign key till den i dish_ingredient så styr databasen över villkoren och jag slipper ta med det i min kod, förutom att fånga olika exceptions. Det känns intuitivt rätt. Om jag skulle styra allt via applikationen skulle jag dessutom vara tvungen att "spara" data i arrayer i olika klasser. Det är ju det som är huvudfrågan, huruvida jag skall hysa infon i db eller klasser.

dish_ingredient är en junction table som kopplar ihop en ingrediens med ett recept, alltså är primary key receptets id och ingrediensens id. Som jag tolkat det kommer det bli väldigt många rader med samma ingrediens där det bara skiljer på mängden om jag lägger amount i ingredients. Det känns inte rätt men förstår ditt resonemang ang enklare querys. Min server har dock ingen tb-disk utan 32 gb. Men mer avancerade querys ställer ju också till det, kör på en Raspberry Pi med 0,5 gb ram.

Skall se om jag kan plita ned tabellerna, lär dock ta en stund att få det begripligt. Överväger att exportera och skicka upp sql-filen men måste första skapa alla tabeller. Än så länge finns de flesta bara på papper.

Just det, tänkte kolla på materialized views, eller rättare sagt Flexviews för att underlätta lite vid avancerade queries. Skulle det kunna vara ett vettigt alternativ till duplicerad data?

Skickades från m.sweclockers.com