I’ve got an application which is sold as a SAAS to multiple customers. Predictably, sometimes customers want to customise some areas of the application by adding their own fields, specifically the area relating to Action/Project tracking. We allow a small amount of this currently. It is handled by storing the names of additional fields for each customer in the db with an id for each field. Any values are then stored in a second table which has a column for each potential data type (String, date etc.). This table references the id of the custom field, and the key of the object it is attached to. In this way we end up storing all the custom field data in a single table. I’d not be too concerned about this if it was limited to a small amount of fields for the odd customer, but it’s now being seen as an opportunity for sales and customer service to quickly customise the application for individual customers and in some cases were getting more custom fields than there was originally on the item in question.
I’ve convinced people that we should hold off on these large scale customisations for now, and I’m generally of the opinion that if you want this sort of behaviour you should build it properly, ie creating the relevant database tables etc. There was another question which mentions 2 ways of implementing this in the database here. One solution being similar to that outlined above. The other is to have a bunch of redundant fields on the tables to be customised called Text1, Text2, Date1, Date2 etc which can then be used as required by the users renaming them as appropriate in the gui.
I was wondering though, How anyone else has solved this issue? what limitations there were to their solution? and any suggestions for further reading I might do.
cheers,
We also develop SaaS and we also have customers that want all kinds of customizations.
Where it more or less could be useful to all customers, it has a fixed implementation. Meaning, tables and fields. The feature is enabled or disabled through some access right that belongs to the user package.
We also have a different situation when users are allowed to dynamically define fields and their related subfields to create their own forms. It is as complex as it goes. Here we use a sort of Entity Attribute Value model to address these needs.
That is the thing with “enterprise” application, probably their unique feature – a customer wants something exotic and we can’t say no.