Форум MySQL

Добрый день, при создании архивов заказов возник вопрос о правильном подходе к реализации структуры базы данных.

Как обычно бывает, посетитель помещает в корзину N товаров. Каждый товар имеет свои параметры (вес, цвет, цена, количество и пр.)

Пока что вижу следующий вид таблиц:

/*** Список заказов ***/ CREATE TABLE `Orders` (     `id` INT NOT NULL AUTO_INCREMENT,     `order_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',     `order_user` INT NOT NULL DEFAULT '0',     `order_method` VARCHAR(10) NOT NULL DEFAULT 'mail',     `order_comment` VARCHAR(255) NOT NULL DEFAULT 'Ожидает проверки',     `order_status` INT NOT NULL DEFAULT '0' )

/*** Список товаров в заказе ***/ 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_price` VARCHAR(10) NOT NULL DEFAULT '0'

/*** Таблица с прочими параметрами заказа или продукта ***/ CREATE TABLE `Orders-Meta` (     `id` INT NOT NULL AUTO_INCREMENT,     `order_id` INT NOT NULL DEFAULT '0',     `meta_id` INT NOT NULL DEFAULT '0',     `meta_key` VARCHAR(255) NOT NULL DEFAULT '',     `meta_value` TEXT NOT NULL )

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

На сколько верен такой подход?

Спасибо!

первая таблица норм
вторая таблица

/*** Список товаров в заказе ***/ 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_count` INT NOT NULL DEFAULT '0'

третья таблица не нужна
в место этого должна быть полноценная БД товаров (или услуг) откуда извлекается вся остальная необходимая информация по `product_id` в том числе и цена и название

Если вдруг товар будет удален из бд? Или как узнать какой был выбран цвет товара или размер или вес? Не расширять же таблицу до количества возможных вариантов выбора параметров товаров?
Именно из за "универсальности" возникла задача.

Если вдруг товар будет удален из бд?
а что вы тогда будете продавать, позвольте вас спросить? )
Или как узнать какой был выбран цвет товара или размер или вес?
ну об этом я говорил, что БД дожна быть правильно сформирована
полагаю у товара с разным весом или цветом (и тд) должен быть разный артикул, в любом случае необходимо хранить товары в разных строках таблицы из-за количества того или иного товара
допустим у вас есть товар майка размера M синего (30 штук) и красного (50 штук) цвета, размера L синего(15 штук), красного (3 штуки) и оранжевого (17 штук) вы намерены все это запихать под один id?
Я уже молчу о том что физически удалять из БД размеры или цвета которых на складе ноль, я бы не стал и у них будет тоже свой id.

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

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

Взбредет в голову удалить устаревший товар
а что помешает взбрести в его голову удалить информацию из любой таблицы? или вообще всю БД грохнуть?))
ну и в конце концов удалять товар можно путем переноса его в отдельную таблицу, все равно я бы не рекомендовал использовать 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` при успешной тразакции

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

/*** Список товаров в заказе ***/  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

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

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

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

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

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

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

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

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