Composition for happy ORM?

None of the polymorphic mapping strategies for ORM seem to work very well.

• Table per class hierarchy - Is too evil to mention.
• Table per class - Very similar to composition?
• Table per concrete class - Makes queries and FKs painful.

Composition seems to map nicely to relational databases. Also in the real world composition can model the world nicely.

Data legacy

Nice things like automated testing means coders can relax when it comes to code structure and actual implementation but definitely does not mean we can relax about data legacy. External APIs, even for people, build up a very hard to change legacy. Even more often forgotten is the rubbish that sometimes gets put into customer databases in a hurry to get a new version out.

Seems to me it is worth being very anal and putting a lot of thought into everything that will build up legacy. Public APIs, UIs, datastores...

Value anti-pattern

It seems painfully common that software engineers decide to build a database on top of a relational database. Your lovely RDBMS can model columns, relations (duh), datatypes in a wonderful way and do all sort of clever optimisations when you query this data. When the wunderkind decides to have a table with columns name and value, to stuff any old rubbish in, they throw away all this good stuff and invent a very broken wheel on top of a very good wheel. Alfresco CMS manages to make very simple things very complicated and slow by using this pattern.