Hi,

I'm creating an application that will allow each of it's users to create a list of their customers. Each user will have the ability to associate an aribtrary number of fields to their list of users. So user A might have a list of 20 customers, and wants to record their name, phone number and address. However user B may have completely different requirements and wants to list each customer by only their email address and hair colour (an odd combination -- but it should be possible).

The problem is that if the application has a lot of users, one arbitrary "customer" table will not fit all their needs. One way around this would be to create a separate customer table for each user, i.e. user_A_customers would contain the fields name, phone_number and address_line_1 etc. whereas user_B_customers would have only 2 fields, email_address and hair_color.

Is this an appropriate solution to the problem? Are there any drawbacks to this?

Thanks,

--SM

My opinion: customization is a poor substitute for requirements gathering.

Under normal circumstances, I would agree -- but unfortunately this customization is to be touted as a "feature".

Putting the requirements issue aside, and accepting that the "customization" is required, is there a better way of providing this flexibility?

--SM

I'd create a standard table structure for all required and common fields, and then add an XML datatype column to store custom attributes.