Jag kommer skapa ett enklare ärendehanteringssystem där det kommer att finnas lite olika typer av ärenden. Olika ärendetyper kan se ut på olika sätt tex ett beställningsärende av en produkt har en property för antal av en produkt m.m. Jag är ganska klar med hur domänstruktur kommer att se ut men jag är osäker på hur jag ska skapa databasstrukturen.

Vad tror ni om något liknande som detta:
I Errand-tabellen sparas huvudstrukturen av ett ärende. I denna tabell sparas tex ErrandID, CreatedDate, Description m.m. Dvs värden som alla ärenden har gemensamt

I ErrandTemplate-tabellen sparas mallen för hur ett ärende ser ut, dvs vilka properties som finns på ärendet

I ErrandXXX-tabellen sparas varje (property) värde på radnivå (dock ej värden som finns i huvudstrukturen). Tex antal av en produkt sparas i en rad och storlek sparas i en annan rad. Kolumnerna som man har är ErrandID, ErrandColumnName, ErrandValue

Vad tror ni om det eller skulle ni gjort annorlunda?

PS. Jag vill eventuellt också diskutera vissa detaljer i domänstrukturen så jag lägger ärendet i arkitekturforumet och inte databasforumet.

Jag är kluven, en annan variant är att du kör med "arv", dvs om du lägger ihop kolumnerna från alla tabellerna så får du de egenskaper du vill ha. Nackdelen är ju att det blir många tabeller, men å andra sidan kan du lättare lägga ut bra index, relationer, effektivare sökningar etc.

1. Är "Errand" verkligen rätt? Jag har inget annat förslag men det låter som en annan typ av ärende...
2. Detta är ju egentligen ett klassiskt exempel på när db/oo inte klaffar, och du har ett spektra att välja ifrån;

Antingen löser man det superdynamiskt på db-sidan med alternativ:
- en "propertyname/propertyvalue"-tabell.
- xml lagrat i db
- andra strängbaserade varianter.
Problemen är ju de Oskar nämner; all typsäkerhet försvinner vilket även inkluderar saker som att felaktiga värden fylls i. (Det finns inget som stoppar en från att fylla i "tankstorlek" på "elbil", och inte heller att fylla i "gargamel" som värde.)



Eller så släpper man på dynamiken och har olika "propertyvalue"-kolumner för olika värden. Alltså PropertyValueBool, PropertyValueInt, ...

Man blir de mindre flexibel om nya datatyper ska in, men man får å andra sidan typsäkerhet på de man har.



Eller så släpper man ytterligare lite på flexibiliteteten, och definierar upp de Properties som är tillåtna, och tappar den enskilda typsäkerheten.
Properties
ID, Name, Type

Eller så tar man i ännu mer och har kopplingar och constraints på alla ledder, så att man får något i stil med:

Properties
ID, Name, Type

BoolProperties (constraint att type måste vara = 1, i övrigt fk på båda)
PropID, Type

IntProperties (constraint att type måste vara = 2, i övrigt fk på båda)
PropID, Type

...
IntValues
IntPropID, Value

Då kan man inte använda properties som saknas, och det blir alltid rätt typ, samtidigt som det är hyfsat lätt att utöka.



Ovanstående går ju också att utöka så att man verkligen bara kan använda en property om man är av rätt sort, på snarlikt sätt som jag har gjort med IntProperties etc.


Och vidare kommer man ut till den mest statiska och rigida, där varje enskild subklass i själva verket får en helt egen, hårt specad tabell. Då är man tillbaka i ganska lite jobb att sätta upp, men med bra typsäkerhet. Och nackdelen är framförallt att många förändringar kräver nya tabeller.

Jag har använt ganska exakt den strukturen till ett system jag håller på med nu. Har inte gått skarpt än, så det är väl för tidigt att ropa hej, men det känns bra så här långt.

Visst, man offrar typsäkerhet i databasen, men jag upprätthåller den i objekten (GUI't använder dessutom dynamiska PropertyDescriptors så ur slutanvändarperspektiv är det typsäkert).

Det som blir knöligt är om man tex. behöver göra rapporter med ett traditionellt rapportverktyg, typ Crystal. Men så är det ju alltid när saker ska vara dynamiska och användardefinerade.

Intressant nog kom den här posten på slashdot idag:
http://developers.slashdot.org/story/09/11/09/2335214/The-NoSQL-Ecosystem
http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/

Intressant :) Men, men, inte aktuellt här tror jag. Mjo, jag tror nog att det kan fungera med niklas förslag.