views:

33

answers:

3

It came up again today how to handle allowing users to add custom fields to the standard entity schemas delivered in your product's database. I favour actually providing a function that gives the user limited DDL functions, so they can actually add a new, custom field to a table. Another approach is to have a separate table for custom fields, e.g. Customers, and CustomersEx, where only CustomersEx can change, but here updates become trickier than normal. The last and most badass option that we discussed was providing a EAV table, where rows are entity name, field name, field value.

Which approach is best?

A: 

EAV that is added to the existing relational structure. There is a whitepaer published by SQL Server CAT (Customer Advisor Team) on this topic. Although is vendor specific, the principels discussed and the solutions proposed apply to most RDBMS: Best Practices for Semantic Data Modeling for Performance and Scalability

Remus Rusanu
A: 

I favor adding fields to a table via DDL, but that table should be separate from the main table. That way, you can script changes to your database schema without affecting your users' custom field additions. A right-join is easy enough to accomplish, and you won't need the record in the separate table if there are no custom fields.

If you just want to display data in a vertical fashion, EAV tables can be a good choice. You can also run a pivot query to display them horizontally.

Robert Harvey
+1  A: 

I favor your second idea. We do something similar but call the tables Attr[ibute] tables, e.g. Company, CompanyAttr. The attributes are a collection in our business object (1:M) and NHibernate handles database operations. We explicitly display these fields as attributes in the UI and don't try to display them as if they were additional fields in the table.

Jamie Ide
I like your noting not to try and plaster over the division between the two tables.
ProfK