I am nearly to grow the functionality of the Content management systems but was considering restructuring the database to really make it better to add/edit data types and values.

Presently, the Content management systems is very flat - the Content management systems takes a area within the database for each kind of saved value (by hand produced).

The very first option that involves mind is only a table which will keep the information types (ie: Address 1, Suburb, Current Email Address etc) and the other table which holds values for all these data types. Much like how Wordpress keeps values within the 'options' table, PHP serialize would be employed to store a range of values.

The 2nd choice is how Drupal works, the Content management systems produces tables for each data type. Unlike Wordpress, this is often a little of the overkill however , helpful for SQL queries when ordering and grouping by a specific value.

What's everyone's ideas?

For me, you need to avoid serialization where possible. Your relational database ought to be relational, and therefore be structured as a result. This could range from the 'Drupal Method', e.g. one table per data type. This keeps your database healthy in this way that it may be indexed en easily queried upon.

Unless of course you intend to possess many different data types that'll be added later on that are unknown now, this isn't really going that will help you and could be overkill. For those who have very wide tables and a lot of holes inside your data (i.e. plenty of posts that appear to become NULL randomly) then that's a pattern that's screaming to maybe possess a seperate table for data that could only fit in with certain records.

Make it simple and logical. Don't abstract with regard to abstraction. Indeed, storing integers cost less in relation to space for storage but unless of course that's an issue then do not do it within this situation.