I’m designing a program along with its database from scratch. What would be the best database design for the following scenario (SQL 2008 R2, C#):
The program will be sold to various customers with different needs. That’s why I’m trying to make it as extensible as possible. in Code-Side, I’m using DI for a plugin-based architecture.
But for the db-side:
Each customer may or may not want to add additional information to users/entities. With different data types. How should I design my db to be able to easily add additional data with minimum touch?
- Create an additional column in required tables which stores any other info about the entity in XML or CSV format and parse in in code-behind.
- Create a new table which holds the ID of an entity and has a key/value pair columns along with a DataType column(e.g.
Key="IsPremiumMember", DataType="boolean", value="true") and parse it in code-behind.
Which approach would you suggest and why?
Any other workarounds I should consider?
Thank you.
If the universe of possible columns is enumerable, then you could build your tables with the standard columns, and allow your clients to add the additional columns from your list of possible columns. This would be flexible without being too difficult to code in SQL.
If the universe of possible columns is unknown, you could use the Key / Type / Value pattern. As marc_s said, it’s flexible, but more difficult to code SQL.
Finally, you could allow your clients to define the tables with any columns they wish. Your software would have to read the database system column and database system index tables to determine what the column names and index paths are. This kind of software would be at least an order of magnitude more difficult to write, as the SQL would be generated by the results of database system tables.