If you know most of the attributes your products will have ahead of time, you could hard-code them into the tables for different product types, such as:
books
-----
id
price
title
author
isbn
etc....
mobile_device
-------------
id
price
size
colour
model
etc...
You could also try something like this:
base_product
------------
id
base_price
product_type
book_product_attributes
-----------------------
base_product_id (FK to base_product)
title
author
mobile_dev_product_attributes
-----------------------------
base_product_id (FK to base_product)
model
colour
This way, you can group your common attributes in a base product table, and more specific attributes are stored in other tables when necessary.
This will work if your product types are mostly static. On the other hand, if you have no idea what product types or attributes you'll need in the future, and entity-attribute-value based system might work better. The idea behind that model is that you have a table for the different attributes you might have, a table for the different entities in your system, and a table for the attribute values that an entity has. Example:
entities
--------
id
attributes
----------
id
name
values
------
id
entity_id
attribute_id
value
The data might look like this:
entities
ID
----
1
attributes
ID | name
----------
1 | title
2 | author
values
ID | attribute_id | entity_id | value
---------------------------------------------------------
1 | 1 | 1 | "Great Expectations"
2 | 2 | 1 | "Charles Dickens"
This data very briefly describes a product which has two attributes: title, and author, with the valus "Great Expectations" and "Charles Dickens", respectively.
Be aware that using an EAV database can make queries very awkward. With enough data and the wrong model design, it's also possible to run into performance problems. The example I gave was very simple but more realistic designs tend to be more complicated than that. It can take time to get this kind of database correct and it's not always the best solution.
In what's called Normalization, you want to prevent storing duplicate data. For example, it would be best to store the 'DVD' text only once in the database, not for each row that has a type of 'DVD'. To achieve this, you would create a lookup table (method 2).
It will seem like extra code, but it's better in the long run.
Also, if you wanted to get a list of all types, you can query that new table instead of the large table. You could query the larger table, but it will be slower and may not have all the types.
Best Answer
One way is to design the specifications in a supertable/subtable form. Here is one such design: Fiddle. I'm sure it can be improved on, but the key point is that specification ID values are unique among all specifications, not just within each type of specification. So there are no collisions between Colour and Weight, for example. However, a spec defined as colour cannot be entered into any other spec subtable except Colors (or Colours -- try as I might, I'm afraid I mixed the spelling in at least one location). The super table (Specs) makes it easy to query individual specs.