that means that a user would have to manually define the tables his objects should be mapped to. [snip] so an o-r mapper must be able to dynamically create columns, and even remove columns, as there can be > 1 NVPs with the same name, so the column has to be moved to it's own table and mapped as a 1:n relationship. (STL container again)
I have seen two philosophies wrt orm: with or without a description (call it "schema", meta-data or whatever) of the objects to be mapped. Tangram uses a schema and it creates the tables for you (see http://tangram.utsl.gen.nz/docs/Tangram/Tour.html#creating_a_schema). In the Perl world you have several modules of both type. The advantage of schema-less tools is that they are very easy to use (just throw objects at them). Schema-based tools otoh give you predictible behavior and known database schemas (i.e. that don't depend on the particular set of objects that have ben stored) that you can get past your average db admin ;-) I have used a predecessor of Tangram to store a representation of the Belgian Justice. It had 400+ business classes with many levels of inheritance and complex relationships. I doubt that a create-the-db-as-you-go tool would have cut it. OTOH there are many situations in which schema-based tools are overkill. J-L