Database Schema to Support Customizable/Extensible Application

We want to redesign the ticketing system of DrProject so that different sites can customize it to meet their needs. Students in undergrad courses just need an ordered to-do list; companies need all the fields we currently have (with a few more values for some of the enumerations), and one or two more as well.

Coincidentally, Jeremy Miller had a post earlier this week asking the same question I’ve been mulling over: what should the database schema look like to support extensibility? His options are:

  1. Allow sites to add customs fields to the database --- madness lies in this direction.
  2. Use "wildcard" fields (which for my money is just option #1 with poor column names).
  3. Use name/value extension tables.
  4. Structure the fields (e.g., store XML). I think this is #1 with angle brackets, but I'm not sure...

Have you been there? Done that? If so, what would you recommend? Keep in mind that testability is as important to us as extensibility…

In the wake of posts about Shopify's support for white nationalists and DataCamp's attempts to cover up sexual harassment
I have had to disable comments on this blog. Please email me if you'd like to get in touch.