Here's the scenario: your application is frequently customized per customer, and that means the database has to accomodate new types of information. My question to you is what do you think is the best (least bad) way? Here are the strategems I've used or seen before:
- Allow custom fields to be added to the database tables. Slippery slope to Hell in my experience. As an internal IT architect, customizing 3rd party code filled me with dread because our upgrade path was shot and support was often harder. Inside a product company that kind of customization adds maintainability costs, especially if you have to keep customer specific branches. I have seen some systems accomodate this with custom data dictionaries and metadata driven architectures. Needless to say, it's complex.
- Use wildcard fields at the end of tables like "string_field_1" or "int_field_1" that can be used for anything. I refer to this kind of design as the "Mystery Meat" antipattern because it's never obvious what's in there.
- Store extended information in name/value extension tables. Flexible, but often clumsy in execution. More Mystery Meat. Drives DBA's nearly insane. Wait, that might be a plus.
- Serialize the extended properties as Xml or some other sort of Memento representation in a column. Presupposes an Object Oriented Domain Model approach. Requires some customization of the persistence layer, but I think some O/R tools support this (ActiveRecord in RoR does at least). Doesn't work all that well for reporting needs. Mystery Meat again.
On a tangential note, is anybody using a true OODB? Do you think it'll ever be feasible/practical/common? Maybe the XML hybrid databases will end up being better.
Now that Smalltalk and its variants seem to be making a bit of a comeback, I wonder it that ends up making OODB's practical if they can just use continuations to take quick snapshots of an object. All the OODB's I've ever read about were Smalltalk.