Hi, Firstly, you have really made my day with this story.
> Keeping with the Contacts example I am thinking of having a > contacts table with all the common fields and maybe a generic > table that contains the name of the field the value of the > field and the datatype of the field. I can then use this > information to generate the UI perhaps. Performance concerns me. If the "extra" fields are only shown when the contact is opened up then performance won't be an issue with this approach. OTOH if you need to display the extra fields in a list of contacts, performance will be a problem. I'd consider keeping a single table per customer with just the "extra" fields and the common fields in a generic table as per your initial idea. That way you can get all the fields you need with a join between the two tables. Either way, when you come to unify your UI code, you will need enumerate the available fields and display them. I'd estimate the work involved in iterating a collection of fields is much the same as iterating a collection of records. My starting point would be to find out how many "extra" fields there are. Are there fields in the different tables that serve the same purpose but just have different names & lengths? I would try to identify and consolidate those before proceeding. Adelle. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
