Database Design - Handling Dynamically created products

We are developing an application which will allow users to define, order and provision a product. The basic steps are as follows:

PRODUCT DEFINITION
1. User defines production information common accross all products (i.e. name, desc)
2. User defines configuration information which is specific to a product (i.e. user_name, ip_address, office_location) 3. If necessary, User defines possible values for one or more cfg info items (i.e. office_location = 'Chicago' or 'Houston') 4. User defines how the all the information in steps 1-3 will be displayed (i.e. creates a form/html page)

ORDERING
1. User selects the product a customer wants to order 2. User sees the product information and all it's cfg items/possible values as defined in the product definition stages 3. User enters all values for the required cfg items

ORDER PROCESSING
1. User queries tasks to find associated cfg items 2. Database is updated with the customer's cfg information for the ordered product

Now here is what we are trying to accomplish:

A. Quick turnaround for defining new products.  Ideally on the fly
B. High integrity of data
C. High flexibility to product definers
D. Handle infinite number of products with minimal change to database tables

Here are some of our ideas :
A. Everytime a new product is created, create the appropriate tables for the new product.
+ Data integrity is high
+ Applications accessing data is straight forward
- Turnaround for creating a new product is low - Modification database during production is high

B. Store configuration information for products as name/value pairs
+ Turnaround for creating new products is low
- Data integrity is lower (i.e. how do you maintain name/value pairs which vary in number across products)
- Applications accessing data become more complex
+ Modification of database in production is minimal

C. Store cfg data in the database as a blob - No way to query cfg data (really bad - generating reports would be impossible w/o creating our own reporting application) - Time involved in retrieving data is higher (i.e. retrieve, map to appropiate types/values)
+ Turnaround for creating products is low
+ Modification of database in production is minimal

How is the rest of the world solving this? Has anyone developed a system similar to this? Are there any good articles/books which address issues like these?

Any help would be greatly appreciated,

Mauricio Zamora Received on Fri Mar 06 1998 - 00:00:00 CST