I have this great module, but I don't have a good name for it. Since the name should possibly indicate what the module does, I'll quickly describe what the module does and what use I see for it:

The module allows me to dynamically add (and maybe later remove) columns to a table in a database. It creates the correct SQL ALTER TABLE statements for me and if I want to, takes care of executing these statements as well.

In addition, it provides a convenient way to query that table with SQL::Abstract-like queries and a very ad-hoc reimplementation of the boring parts of Class::DBI because I didn't want to fight against the more interesting parts of it.

For the time being, it has been named Table::Denormalized, because that is what it represents to me.

Now, here's my use case: Let's say we want to store properties of files in a database, and we (currently) have three kinds of files, plain files, mp3 files and image files. We suspect there will be more kinds of files which will likely be recognized and parsed by some kind of plugin. So we want to have some kind of table which has a dynamic set of columns to hold the properties of the files. Not every file will have all properties though.

In a normalized database design, those "dynamic properties" would live in separate tables and the main table would hold all rows together by providing a unique ID for all other tables:

image_properties      file                        mp3_properties
id    INTEGER     --> id        INTEGER       <-- id         INTEGER
width INTEGER         name      VARCHAR(1024)     playlength INTEGER
height INTEGER        size      INTEGER           artist     VARCHAR(1
+024)
                      mime_type VARCHAR(64)
[download]

This normalized setup would allow me to add new column sets by adding a new table, and it would also allow me (and the database) to just retrieve the needed data instead of fetching lots of data that is likely not used anyway.

The drawback to this normalized scheme is that queries and updates to it are not as simple as queries to a single table, as I have to join the other tables to the table. Such joined queries are slow(er), too.

With "Table::Denormalized", the above layout could be merged into one table conveniently (and transparently):

file_denormalized
id        INTEGER PRIMARY KEY
-- file properties
name      VARCHAR(1024)           
size      INTEGER
mime_type VARCHAR(64)
-- mp3 properties
playlength INTEGER
artist     VARCHAR(1024)
-- image properties
width INTEGER                  
height INTEGER
[download]

This layout makes querying for items trivial, but it comes with two drawbacks - if I mostly store image-rows in the database, I will waste lots of space for the mp3 properties. And more importantly, a file can only ever have a single artist (unless I really sell my soul and add a artist2 column).

As I said above, the module is currently named Table::Denormalized. I think it should be named DBIx::Table::Denormalized.

The "other" name I have been considering is DBIx::Table::Dynamic, which is more about what the module allows one to do, to dynamically add (and later maybe even remove) columns to a table.

Any input on this is welcomed.