Если товаров до 5000, то все будет летать на такой структуре: таблица товаров: ID , бла, блабла, ... таблица опции: ID(int11), IDтовара(int11), ID_Тип-Опции(int11), Значение_Опции(var255) ну до кучи можно еще и третью таблицу, где названия опции хранить, но проще в php подставлять НАЗВАНИЕ опции согласно ТИПа опции Что такое ТипОпции? Это число (для экономного хранения в БД и быстрого поиска по числу!), например: 1 - это цвет, 2 - ширина, 3 - длина, 4 - вес, ... В Значение_Опции соответственно пишем - голубой, или 436 или 623 или 3.400 Это немного не по стандартам, по стандарту - три таблицы, где в 3-ей будут храниться названия опции, но на малом магазе и так попрет! Т.е. названия опции ты простопомнишь и в php их подставляешь в зависимости от ID_Тип-Опции
Почему только для 5000? Если привязан в использовании MySQL, то такая схема в принципе единственно верная для оптимальной работы.
ну потому, что будет разбухшая таблица опции,если например берем 10000 товаров да по 5 опции, то что получится- 10000 строк в таблице product и 50000 строк в таблице опций))) И при выводе странички товара придется пробегать по всей таблице опций, чтобы найти все опции товара, опции редко идут по порядку, что-то добавляют к товару позже и т.д. Вот и получается вперемешку.. Но все решает эксперимент, да и запросы конструировать всяко проще всего на такой структуре, это к бабке не ходи!)))
