Saving module settings (metadata) as rows, not as columns

Topics: Writing modules
Developer
Aug 27, 2011 at 6:58 PM

Hi all!

I have seen that the practice everybody is using to store various settings is to create a content part (and its record), where the properties (columns) are the parameters. This technique produces many tables that only have one row. If a parameter should be added, a new column should be added.

For my own module with several independent features (3-5 parameters to store each) the traditional approach would be to create several content parts and therefore, db tables. In my opinion a cleaner way would be to store all the settings in one table indexed by string keys (the name of the parameters), with a second column (the value). This way, the whole module would require one table for all settings (and settings could be changed without schema alteration).

Does this make sense, is it worth the effort (as this would - without the possibility to use a lot of helper methods - greatly complicate the way data is saved from the admin page; not to mention the problem of storing various types of data in the same column), or why am I worrying about SQL Server running out of tables :-)? Anybody has used this approach?

Coordinator
Aug 27, 2011 at 7:17 PM
Actually, this is simply because settings are treated like regular content items. It is not true that these tables have only one row: there is one site content item per tenant.
Treating tenants like items has many advantages which outweigh the small problem of table inflation.

Sent from my TI-99/4A

From: Piedone
Sent: Saturday, August 27, 2011 11:59 AM
To: Bertrand Le Roy
Subject: Saving module settings (metadata) as rows, not as columns [orchard:270641]

From: Piedone

Hi all!

I have seen that the practice everybody is using to store various settings is to create a content part (and its record), where the properties (columns) are the parameters. This technique produces many tables that only have one row. If a parameter should be added, a new column should be added.

For my own module with several independent features (3-5 parameters to store each) the traditional approach would be to create several content parts and therefore, db tables. In my opinion a cleaner way would be to store all the settings in one table indexed by string keys (the name of the parameters), with a second column (the value). This way, the whole module would require one table for all settings (and settings could be changed without schema alteration).

Does this make sense, is it worth the effort (as this would - without the possibility to use a lot of helper methods - greatly complicate the way data is saved from the admin page; not to mention the problem of storing various types of data in the same column), or why am I worrying about SQL Server running out of tables :-)? Anybody has used this approach?

Developer
Aug 27, 2011 at 7:41 PM

Thank you for your answer! I didn't know that multi-tenancy has something to do with that (however if I understand the docs correctly this is not an issue with custom modules, because their tables are prefixed with the tenant's name). But I understand that the current practice is the clever way to go.

Developer
Sep 1, 2011 at 9:54 PM

For those who stumble upon this discussion, something similar: http://orchard.codeplex.com/discussions/267905