Custom type system in relational database

For an application we capture certain form data. The user can include the various sections at will.

The kind of data that needs to be captured in each section is custom per section. Sometimes they are simple dictionaries of key-value pairs. Sometimes they contain sub-components with one-to-many or many-to-many relationships. Though the number of sections may grow, for each section a schema would be known.

In the past, the form sections were fixed and so we could just hard-code the table structures for each section. We do not have a generic way to implement sections - it's new data access and tables for each new section.

BUT, a new requirements says that the user should be able to design their OWN sections. To avoid dynamically manipulating database tables, we'd like to migrate to a higher-order schema that can express these sections in data.

If the data were just key-value pairs of single valued fields, this could be implemented with a 开发者_StackOverflow中文版Sections table and a SectionFields table. But because of the possibility of nesting through multiple-valued fields and fields of complex type, I believe we should approach this as a rudimentary type system. I don't think it needs inheritance.

Rather than reinvent this from scratch, I assume that work has been done in schemas for efficient type systems stored in the database. Any thoughts/guidance?

Thanks.

If the user is allowed to create their own data types, then the database that stores them is no longer a relational database. Attempting to store this data in a traditional manner is going to be chaos.

You should consider storing this data as XML snippits. If you can build an XML schema that can support the users' selections, and if your database supports an XML datatype (as newer versions of SQL Server do), then you may still be able to do some useful queries on the data.

Jason,

I'm not sure I understand your question. This is a summary of what I've gleaned from reading it over:

You capture form data for an application. Your requirements have changed to allow for user defined sections. This is a headache for you because in a relational database you'd have to dynamically alter the tables to accommodate this new requirement.

This might be the case where you are using the wrong tool for the job. Relational databases are great for storing and retrieving data with well-established relationships, but are kind of terrible when you have loosely-coupled or undefined relationships in the data. You might find that you're better off with a technology like XML, which handles storage for loosely coupled data sets much better.

Sorry if this is not what you were looking for. This is my first answer post on StackOverflow so I'm still getting the hang of this.

Best of luck,

Michael