[Mysql] welk datamodel het beste

[rmfloris]

Ik heb een ontwikkelingsvraag m.b.t. mijn database welke ik ga opzetten.
Ik zit te wikken op twee mogelijkheden, maar ben benieuwd naar jullie ervaringen/ideeën/feedback omtrent deze verschillende mogelijkheden.
Het betreft een database model omtrent vakantiehuisjes en waarbij het voornamelijk gaat om de mogelijkheden welke de huisjes bevatten.

Optie 1:
Tabel: Accommodatie
ID (int)
Naam (varchar)
Zwembad (enum 0,1)
Sauna (enum 0,1)
etc

Optie 2:
Tabel Accommodatie:
ID (int)
Naam (varchar)

Tabel Opties:
ID (int)
Optie (varchar)

Tabel Optie_koppel
ID (int)
oID (int)
aID (int)
(Hierbij link oID naar optie ID en aID naar accommodatie ID (mocht dit nog niet duidelijk zijn ;-) )

Hierbij heeft de eerste optie als voordeel dat alles op 1 regel, direct bij een accommodatie staat, maar uitbreiden lastig maakt. Je moet immers voor iedere optie een nieuwe kolom in je tabel aanmaken.
De tweede optie heeft dit nadeel niet, maar eventueel performance beperkingen omdat je toch 3 tabellen moet aanroepen om alle informatie hieruit te halen.

Misschien is er nog een derde/vierde/n-de optie (dan hoor ik die graag), maar waaraan moet ik denken bij de keus voor bovenstaande opties?

[Mike78]

Optie 2 heeft de voorkeur, het performance verlies zal er niet zijn.

Zie ook dit wikipedia verhaal over databasenormalisatie Wikipedia: Databasenormalisatie

[Cloud]

Persoonlijk zou ik i.v.m. onderhoudbaarheid voor optie 2 gaan. Performancebeperkingen, dat zal wel los lopen met twee tabellen en een koppeltabel. MySQL is tenslotte een relationele database, die heeft absoluut geen moeite met dit soort constructies. In principe ook niet bij honderdduizend accommodaties en 50 opties. Je moet niet bang zijn je databaseserver wat werk te laten verrichten, daar heb je dat ding tenslotte voor!

[Black Hawk]

Ik sluit me aan bij Mike78

[zwippie]

Zonder verder op je model in te gaan: wordt niet benauwd van gekoppelde tabellen.

Je DBMS kan supersnel een of meerdere JOINs doen om de gegevens te combineren en op te halen. Echt, daar is het voor gemaakt. Het enige wat jij moet doen is een fatsoenlijke query schrijven.

[YopY]

Zelfs als het performanceproblemen zou opleveren (tip: dat doet het niet), dan nog kun je beter die op de koop nemen en oplossen met een snellere databaseserver dan vele uren verspillen aan het bijwerken van de database, bestaande records en onderliggende software die je elke keer zou moeten doen als er weer een nieuwe optie toegevoegd moet worden. Zelfs als je je systeem goed geprogrammeerd hebt dan zal het nog een uur kosten om één veld toe te voegen, en al gauw een aantal uur om alles door te krijgen. Een uur kost sowieso 50 euro aan ontwikkelaar. Na twee uur kun je dus al een tweede processor (oid) aankopen.

[Verwijderd]

- Reactie Verwijderd -

[ Voor 95% gewijzigd door Verwijderd op 30-10-2014 11:35 . Reden: mistje nog een id ]

[418O2]

Je hoeft bij de koppeltabel geen ID te maken, je hebt als het goed een samengestelde sleutel dus dan is een eigen ID niet nodig.

[rmfloris]

Ik ben blij dat mijn onderbuikgevoel/ervaring toch goed was en optie 2 eigenlijk massaal wordt voorgesteld. Deze gaan we dus zeker gebruiken!

Verwijderd schreef op woensdag 23 februari 2011 @ 15:44:
Maar deze is alleen wenselijk als er heel veel verschil zit in de opties per accomodatie.

Zou je kunnen uitleggen wat je precies bedoelt met heel veel verschil in opties?

@Catch22, je hebt helemaal gelijk. Scheelt weer een veld.

[ Voor 6% gewijzigd door rmfloris op 23-02-2011 16:03 ]

[Verwijderd]

- Reactie Verwijderd -

[ Voor 101% gewijzigd door Verwijderd op 30-10-2014 11:34 . Reden: nou.. ben weer lekker bezig.. ]

[rmfloris]

Verwijderd schreef op woensdag 23 februari 2011 @ 16:08:
Het zou kunnen dat je per optie iets meer specifiek wil zijn, bijvoorbeeld:
- Infraroodsauna met [geef opties van de sauna]
- Zwembad [geef afmetingen]
- Enz..

Nu snap ik je punt. Ik was inderdaad van plan om een 'waarde' kolom toe te voegen in de koppel tabel:
Tabel Opties:
ID (int)
Optie (varchar)

Tabel Optie_koppel
oID (int)
aID (int)
waarde (varchar)

Hierin zitten dan de variaties voor de verschillende opties, of een aantal voor bijvoorbeeld kamers in accommodatie.

[Stilgar]

Om een tegengeluid te laten horen: ik zou voor optie 1 gaan. Ik zou het performance aspect even vergeten voor nu; zoals anderen al hebben aangegeven maakt dat niet veel uit. Maar met optie 2 ben je in feite een database in een database aan het bouwen.

Ik was inderdaad van plan om een 'waarde' kolom toe te voegen in de koppel tabel:
Tabel Opties:
ID (int)
Optie (varchar)

Tabel Optie_koppel
oID (int)
aID (int)
waarde (varchar)

Hierin zitten dan de variaties voor de verschillende opties, of een aantal voor bijvoorbeeld kamers in accommodatie.

En daar komt het eerste varchar veld waarin allerlei verschillende datatypes opgeslagen gaan worden.
Dit is precies waarom ik optie 2 een slecht idee vind. Het bespaart in eerste instantie misschien tijd. Maar als je de applicatie langere tijd moet onderhouden, en er opties bij gaan komen, kom je toch een beetje in de knoop. Je zult zien dat het toevoegen van opties dan snel meer tijd gaat kosten.

Numerieke waarden die je eigenlijk in een integer zou opslaan, komen nu in een varchar terecht. Hoe doe je dat wanneer je wilt gaan sorteren?

Straks besluit je dat je meerdere waarden wilt kunnen hebben voor een optie, wat ga je dan doen? Een waarde2 toevoegen? Of de waarden met komma scheiden? Of de optie dan toch maar splitsen in twee opties? Allemaal mogelijkheden, maar ze breken allemaal je normalisering: in een database gebruik je in zo'n situatie eigenlijk een extra tabel.

[Koppensneller]

Stilgar schreef op woensdag 02 maart 2011 @ 12:28:
[...]


En daar komt het eerste varchar veld waarin allerlei verschillende datatypes opgeslagen gaan worden.
Dit is precies waarom ik optie 2 een slecht idee vind.

Volgens mij is het de bedoeling om in dat varchar-veld de naam van de optie te gaan opslaan. Van meerdere datatypes is dus geen sprake.

En júist voor de onderhoudbaarheid is optie twee een veel betere keuze. Het toevoegen van opties stelt dan niet meer voor dan het aanmaken van een extra rij in de Opties-tabel, in plaats van het wijzigen van je hele databasestructuur.

[ Voor 22% gewijzigd door Koppensneller op 02-03-2011 12:34 . Reden: Tweede alinea toegevoegd ]

[rmfloris]

Voor het model
Tabel Opties:
ID (int)
Optie (varchar)

Tabel Optie_koppel
oID (int)
aID (int)
waarde (varchar)

Gaat het er in werkelijkheid voor bijvoorbeeld als volgt uitzien voor accommodatie aID=1:

Tabel Opties
1 | Kamers
2 | Badkamer
3 | Sauna

Tabel Optie_koppel
1 | 1 | 3 stuks
2 | 1 | 2 stuks
3 | 1 | NULL (dus ja, want er is een koppeling)

Op deze manier ben je flexibel, maar toch netjes genormaliseerd. Of denk ik er nu verkeerd over?

[Stilgar]

rmfloris schreef op woensdag 02 maart 2011 @ 15:27:
Gaat het er in werkelijkheid voor bijvoorbeeld als volgt uitzien voor accommodatie aID=1:

Tabel Opties
1 | Kamers
2 | Badkamer
3 | Sauna

Tabel Optie_koppel
1 | 1 | 3 stuks
2 | 1 | 2 stuks
3 | 1 | NULL (dus ja, want er is een koppeling)

Op deze manier ben je flexibel, maar toch netjes genormaliseerd. Of denk ik er nu verkeerd over?

Als je echt heel zeker bent over de manieren waarop je dit later gaat uitbreiden... ja, dan kan dit werken.

Maar stel je voor dat je bijvoorbeeld het oppervlak van een accommodatie gaat toevoegen (dus een integer). Of het aantal slaapplaatsen. En je wilt hierop sorteren in een overzicht, of het de gebruiker makkelijk maken een selectie te maken in een range. Hoe ga je dat doen?

Stel dat je in je overzicht van een accommodatie één optie per regel hebt. Maar je wilt wel graag het aantal kamers en badkamers samen op één regel. Hoe ga je dat doen?

Door een algemene tabel te maken doe je alsof er geen structuur is in de opties. Als je die structuur later toch nodig hebt voor volgorde, weergave of selectie, moet je deze alsnog gaan toevoegen. En dan moet je de bestaande data gaan overzetten.

Zoals ik zei, ik geef alleen tegengeluid. Jij hebt beter zicht op hoe de applicatie er uitziet, en ook over hoe die misschien gaat groeien.

[moozzuzz]

rmfloris schreef op woensdag 02 maart 2011 @ 15:27:
3 | 1 | NULL (dus ja, want er is een koppeling)

Deze is misschien niet zo zinvol, afhankelijk van wat je met deze rij bedoelt:
1. Er is een sauna maar we weten er niets (=NULL) meer over.
of
2. Er is geen sauna (=NULL).

[rmfloris]

moozzuzz schreef op vrijdag 04 maart 2011 @ 14:08:
[...]

Deze is misschien niet zo zinvol, afhankelijk van wat je met deze rij bedoelt:
1. Er is een sauna maar we weten er niets (=NULL) meer over.
of
2. Er is geen sauna (=NULL).

Het is optie 1, er is een sauna bij dit huisje, maar we hebben geen extra informatie omtrent deze sauna.

[kim72]

Om even wat ervaring er in te gooien:

Je wilt de oplossing met de 3 tabellen gebruiken. De reden is dat je te maken hebt met 3 verschillende soorten gegevens die je op wilt slaan:
- de accomodatie (Accomodaties)
- de opties (Opties)
- welke optie in een accomodatie beschikbaar is (Accomodatie_koppel)

Stel dat je wilt gaan zoeken op accomodaties die een bepaalde optie hebben, dan kan je eerst makkelijk een lijstje van alle opties tonen en de gebruiker daar 1 van laten kiezen, en vervolgens in de koppeltabel opzoeken welke accomodaties daar aan voldoen.

Ook wordt het erg makkelijk om een optie toe te voegen.

Ik zou ook voorstellen om wel een ID in de Accomodatie_koppel tabel te zetten, op deze manier kan je later heel makkelijk een tabel Accomodatie_koppel_gegevens toevoegen waar je dan in kan zetten om hoeveel kamers het dan gaat, of hoe groot een zwembad is, etc. Die tabel kan je dan koppelen op Accomodatie_koppel.ID en hoef je niet weer de samengestelde sleutel (Accomodatie.ID, Opties.ID) te gebruiken.

Ik hoop dat ik het begrijpbaar heb uitgelegd ;-)

[Flard]

Ik zou toch weer voor die versie met maar één tabel gaan.

Met jouw drie-tabel-optie maak je namelijk een database in een database, zoals Stilgar al zegt. Je normaliseert eigenlijk één stap te ver.

Als je alles in één tabel houdt gaat het sorteren veel makkelijker,heb je automatisch alle eigenschappen er direct bij als je een select doet, en heb je controle over je data en de datatypes.

En dat het toevoegen van opties zo gemakkelijk is: Of je nu een 'INSERT INTO `Opties`' of een 'ALTER TABLE `Accomodatie` ADD' doet, zo schokkend is dat toch niet? Zeer hoogstwaarschijnlijk moet je toch als beheerder een van die queries in phpMyAdmin ofzo invoeren...