database table design for some unknown data

So, not having come from a database design background, I've been tasked with designing a web app where the end user will be entering products, and specs for their products. Normally I think I would just create rows for each of the types of spec that they would be entering. Instead, they have a variety of products that don't share the same spec types, so my question is, what's the most efficient and future-proof way to organize this data? I was leaning towards pushing a serialized object into a generic "data" row, but th开发者_C百科en are you able to do full-text searches on this data? Any other avenues to explore?

---

split products and specifications into two tables like this:

products
id name

specifications
id name value product_id

get all the specifations of a product when you know the product id:

SELECT  name,
        value
FROM    specifications
WHERE   product_id = ?;

add a specification to a product when you know the product id, the specification's name and the value of said specification:

INSERT INTO specifications(
    name,
    value,
    product_id
) VALUES(
    ?,
    ?,
    ?
);

so before you can add specifications to a product, this product must exist. also, you can't reuse specifications for several products. that would require a somewhat more complex solution :) namely...

three tables this time:

products
id name

specifications
id name value

products_specifications
product_id specification_id

get all the specifations of a product when you know the product id:

SELECT  specifications.name,
        specifications.value
FROM    specifications
JOIN    products_specifications
ON      products_specifications.specification_id = specifications.id
WHERE   products_specifications.product_id = ?;

now, adding a specification becomes a little bit more tricky, cause you have to check if that specification already exists. so this will be a little heavier than the first way of doing this, since there are more queries on the db, and there's more logic in the application.

first, find the id of the specification:

SELECT  id
FROM    specifications
WHERE   name = ?
AND     value = ?;

if no id is returned, this means that said specification doesn't exist, so it must be created:

INSERT INTO specifications(
    name,
    value
) VALUES(
    ?,
    ?
);

next, either use the id from the select query, or get the last insert id to find the id of the newly created specification. use that id together with the id of the product that's getting the new specification, and link the two together:

INSERT INTO products_specifications(
    product_id,
    specification_id
) VALUES(
    ?,
    ?
);

however, this means that you have to create one row for every specific specification. e.g. if you have size for shoes, there would be one row for every known shoe size

specifications
id name value
1  size 7
2  size 7½
3  size 8

and so on. i think this should be enough though.

---

You could take a look at using an EAV model.

---

I've never built a products database, but I can point you to a data model for that. It's one of over 200 models available for the taking, at Database Answers. Here is the model

If you don't like this one, you can find 15 different data models for Product oriented databases. Click on "Data Models" to get a list and scroll down to "Products".

You should pick up some good design ideas there.

---

This is a pretty common problem - and there are different solutions for different scenarios.

If the different types of product and their attributes are fixed and known at development time, you could look at the description in Craig Larman's book (http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062/ref=sr_1_1/002-2801511-2159202?ie=UTF8&s=books&qid=1194351090&sr=1-1) - there's a section on object-relational mapping and how to handle inheritance. This boils down to "put all the possible columns into one table", "create one table for each sub class" or "put all base class items into a common table, and put sub class data into their own tables".

This is by far the most natural way of working with a relational database - it allows you to create reports, use off-the-shelf tools for object relational mapping if that takes your fancy, and you can use standard concepts such as "not null", indexing etc.

Of course, if you don't know the data attributes at development time, you have to create a flexible database schema.

I've seen 3 general approaches.

The first is the one described by davogotland. I built a solution on similar lines for an ecommerce store; it worked great, and allowed us to be very flexible about the product database. It performed very well, even with half a million products. Major drawbacks were creating retrieval queries - e.g. "find all products with a price under x, in category y, whose manufacturer is z". It was also tricky bringing in new developers - they had a fairly steep learning curve. It also forced us to push a lot of relational concepts into the application layer. For instance, it was hard to create foreign keys to other tables (e.g. "manufacturer") and enforce them using standard SQL functionality.

The second approach I've seen is the one you mention - storing the variable data in some kind of serialized format. This is a pain when querying, and suffers from the same drawbacks with the relational model. Overall, I'd only want to use serialization for data you don't have to be able to query or reason about.

The final solution I've seen is to accept that the addition of new product types will always require some level of development effort - you have to build the UI, if nothing else. I've seen applications which use a scaffolding style approach to automatically generate the underlying database structures when a new product type is created. This is a fairly major undertaking - only really suitable for major projects, though the use of ORM tools often helps.