Inheritance in je database

[TJHeuvel]

We zijn bezig met een applicatie waarmee je je eigen huis kan inrichten. In de huidige applicatie kan je je eigen foto dimensioneren en hier in 3d-space meubels plaatsen. Je kan van deze meubels informatie bekijken en van materiaal veranderen.

Nu is de nieuwe feature request van onze klant om de gebruiker in staat te stellen meubels zelf uit verschillende
onderdelen in elkaar te zetten. Denk aan een bank waar je kan kiezen uit verschillende leuningen, of er nog een zitplek bij te plaatsen.

Deze nieuwe `composite furniture` heeft in principe dezelfde kenmerken als de huidige meubels, en alle
functionaliteiten moeten ook beschikbaar zijn bij deze nieuwe soort meubels. Denk aan vertalingen en filters op specifieke distributies.

In een object georienteerde wereld is dit appeltje eitje, CompositeFurniture erft over Furniture en je bent klaar.
Alleen hoe kan ik deze overerfing ook in mijn rationele database (mysql) krijgen?

Ik kan natuurlijk simpelweg de huidige tabellen kopieeren, er Composite voor zetten en alle queries herschrijven en sommige tweemaal aanroepen (Omdat je nu filtert op Furniture en CompositeFurniture, bijvoorbeeld). Erg flexibel is dit niet, en erg redundant omdat je tabellen krijgt die soms 100% overeenkomen.

Voorbeeld van het huidige database ontwerp mbt meubels:


Eigenlijk waar ik naar op zoek ben is inheritance in mijn database, is dit mogelijk en/of gewenst?

[Boss]

Je kan in je database ook prima inheritance gebruiken. Het is dan wel fijn om er een laag tussen te hebben die de database omzet in objecten. Als dat eenmaal werkt kan je datamodel erg dicht op je class-model staan. Als je er niet zo'n laag tussen hebt zitten dan wordt het allemaal een stuk lastiger.

Moet je backwards compatibel blijven met de huidige situatie of is het geen probleem om het datamodel om te gooien?

Je kan uiteindelijk alle Furniture ook uit CompositeFurniture laten bestaan waarbij er slechts 1 element en geen opties bij zijn.

[zwippie]

Je zou eens kunnen kijken hoe het in Doctrine (1.2, oude versie) wordt aangepakt, ze onderscheiden drie types overerving met elk andere karakteristieken. Ook kent Doctrine behaviours zoals i18n om kolommen vertaalbaar te maken, dit gebeurt ook via overerving.

Ook al werk je misschien niet met PHP, het kan wellicht interessant zijn om het even door te nemen ter inspiratie. Zelf ben ik nog niet bekend met het nieuwere Doctrine 2.0, misschien pakken ze het daar inmiddels anders aan.

Of het mogelijk of gewenst is? Daar durf ik zelf eigenlijk geen uitspraak over te doen. De i18n mogelijkheid van Doctrine heb ik echter wel met veel plezier en gemak gebruikt.

[TJHeuvel]

Dank voor de reacties, ik denk inderdaad dat ik het gewoon aanpak met een extra veldje in de Furniture tabel, zoals Doctrine het ook bij een van hun cases doet.

[ Voor 4% gewijzigd door TJHeuvel op 29-07-2011 09:44 ]