Форум MySQL

Думал об этом, сериализовать массив параметров и поместить в ячейку. Возможно это будет лучше.
Но тогда пропадает "гибкость" манипуляции с заказами.

Ну, в самом крайнем случае, чтоб не плодить огромное количество столбцов или строк, можно все
параметры товара собрать в одно текстовое поле. Зачем обязатeльно отдельно держать размер и
цвет, артикул и сорт? Все записать перечислением в одно поле. Исправлять его ведь уже не надо
будет. Только для истории хранить.

Все верно, у меня вопрос именно по структуре таблицы хранения параметров заказа.
т.к. заказ может содержать в себе различные данные, которые могут расширяться.

Заказ - это и есть то, что куплено. Корзина - это корзина. У заказа м.б. разный статус - ожидание
оплаты, оплачен, удален и т.д. У корзины - только ее содержимое. Содержимое корзины не нужно
хранить после оформления заказа. А содержимое заказа желательно хранить и после его удаления
(он м.б. удален случайно).

Нет не о корзине, с ней все просто. Речь идет о хранении данных оформленного заказа в бд.

таблица заказа <> таблица купленного товара
речь, на сколько я понимаю, шла именно о "корзине заказа"

Я записываю все параметры купленного товара в таблицу заказа. И параметры покупателя
тоже. И мне уже все равно, что таблицы не нормализованы, зато я не потеряю инфу о заказе
и заказчике, даже если товар удалят или другой на его место запишут или заказчик поменяет
свои реквизиты. По сути - заказ - это отдельное от остальной базы хранилище именно того,
что заказали (с датой, номером, артикулами, размерами, цветами и адресами). Пока заказ не
завершен, все данные, конечно, таскаются из разных таблиц. Но по завершении заказа они
записаны в свою отдельную таблицу и их всегда можно найти. При удалении заказа заказчиком
заказ не удаляется, делается пометка "Удален заказчиком". Когда заказ удаляет админ, то тоже
сначала делается пометка "Удален администратором" и только со второго раза заказ можно
удалить окончательно (т.е. только те, которые уже помечены как удаленные админом и заказчик
их не видит в истории своих заказов).

Вопрос встал в построении таблицы таким образом, чтобы записать выбранные параметры товара во время заказа и не создавать громадную таблицу вроде:

/*** Список товаров в заказе ***/  CREATE TABLE `Orders-Product` (      `id` INT NOT NULL AUTO_INCREMENT,      `order_id` INT NOT NULL DEFAULT '0',      `product_id` INT NOT NULL DEFAULT '0',      `product_title` VARCHAR(255) NOT NULL DEFAULT '',      `product_count` INT NOT NULL DEFAULT '0',      `product_color` VARCHAR(255) NOT NULL DEFAULT '',    `product_weight` VARCHAR(255) NOT NULL DEFAULT '',    `product_size` VARCHAR(255) NOT NULL DEFAULT ''    /* ... и еще куча параметров... */

возникла идея создать третью таблицу: Orders-Meta

просто я не вижу других способов записать все параметры (которых может быть большое количество)

Взбредет в голову удалить устаревший товар
а что помешает взбрести в его голову удалить информацию из любой таблицы? или вообще всю БД грохнуть?))
ну и в конце концов удалять товар можно путем переноса его в отдельную таблицу, все равно я бы не рекомендовал использовать id удаленного товара
К сожалению таблица построена таким образом
ну тут я уж точно не виноват :)

/*** Список товаров в заказе ***/ CREATE TABLE `Orders-Product` (     `id` INT NOT NULL AUTO_INCREMENT,     `order_id` INT NOT NULL DEFAULT '0',     `product_id` INT NOT NULL DEFAULT '0',     `meta_id` INT NOT NULL DEFAULT '0',     `product_count` INT NOT NULL DEFAULT '0'

не?
количество товара то по любому должно быть "в другой таблице схожей с Orders-Meta" :)
вы же должны от чего-то отнимать `product_count` при успешной тразакции

БД заказов строится для конечного пользователя (админа). Взбредет в голову удалить устаревший товар, после чего в архиве списка заказов не сможем получить даже его наименование.

К сожалению таблица построена таким образом, что 1 товар (под 1 артикулом) может иметь 15 размеров, 48 цветов и 33 прочих параметров. Все эти параметры хранятся столбцом в другой таблице схожей с Orders-Meta. В связи с этим появилась нужна в создании третей таблицы. т.к. при заказе выбирается ID товара и наименование параметра.