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

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

@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

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

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

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

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

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

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

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

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)

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

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