Построение базы данных продукции с разными свойствами(характеристиками)

Приветствую, уважаемые знатоки!
Запутался с построением базы, прошу помощи.
1. На уровне Подкатегории начинается разделение вложенных таблиц по характеристикам. Условно говоря, у деревьев или кустарников, включается характеристика(свойство): морозостойкость. А в комнатных такой нет. В таблице ВидРастения, также, если берем картофель или томат, то также не применяется, а у винограда, каждого сорта свое значение. К тому же, в Подкатегории, могут появиться другие товары, которые к растениям не относятся вовсе, они пойдут по другой линии и для них другие свойства должны быть определены.
Вопрос такой:
Как построить таблицы, чтобы в виде растений определялись НазваниеХарактеристики(свойств), которые затем заполнялись данными уже для каждого сорта?
2. Еще задумка была, создать таблицу номенклатур с разными свойствами, например растения, стройматериалы, садовый инвентарь и т.п. А далее уже оттуда вытаскивать данные и определять для них цены, т.е. номенклатура просто список, продукции, а таблица с ценами это уже другая.
2.1. Правильно ли так строить базу?
2.2 Одной таблицей всю номенклатуру или разделить по нескольким?
2.3. И таблица с ценами одна или несколько?
tolagro.zip

0

я бы делала 1 таблицу
все на рисунке
не поняла единицу учета и номенклатуру
столбики --неприемлю, особенно если типов услуг /товаров много

Миниатюры

 

1

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

1

Друзья, благодарю за рекомендации, выпал из беседы, т.к. стал набираться немного ума, чтобы достичь большего понимания.
В итоге пересмотрел некоторые моменты, прошу оценить и дать рекомендации по переделанной базе, логику кратко опишу.
1. 1_categories - формируем дерево категорий. Тут можно создать вложенные категории, указывая родительскую категорию, тем самым прописывается все дерево.
2. 2_product_list - содержит названия товаров/услуг, это может быть сорт растения, название строительного материала и т.д., просто список.
3. 5_nomenclature - товар/услуга, где уже указывается кроме названия - артикул, единица измерения - кг, шт., мешок, кассета и должны быть свойства товаров.
4. 1_5_Product_category - связывает номенклатуру (товар/услуга, где уже указывается больше данных, артикул, единица измерения - кг, шт., мешок, кассета и т.д.)
5. 7_price - тут к номенклатурным позициям подключаются цены, скидки и т.д.
6. 4_orders - заказы
7. 9_purchase - это закупки, т.е. на что были потрачены деньги, что закупалось, эти позиции также в номеклатуре прописываются и должна быть цена, количество и т.д.
8. 3_custumer - клиенты, тут все понятно

Прошу помощи в следующем:
1. Есть ли какие-то ошибки в целом в логике, какие могут быть проблемы в работе с такой базой?
2. Если товар имеет несколько цен, например базовая, опт, крупный опт, верно ли это все дело вписывать в одну таблицу price, как сделал сейчас?
3. Товары разной направленности: растения, стройматериалы, услуги, имеют разные характеристики, потом они будут использоваться для внесения в прайс листы и выгрузки на сайт.*
Например, растения
Урожайность
СрокиСорзревания
Цвет плода
Морозостойкость

Строительный материал
Расход
МаксСлойНаОдинРаз
ОбщийМаксимальныйСлой
Цвет
Время жизни
Теплопроводность
РабочаяТемпература
Время схватывания
Время твердения

Как быть с ними, куда их включить, столбцами в таблицу номенклатур, или как-то отдельными таблицами подключить или еще какие варианты?
Буду благодарен любым толковым рекомендациям.

Вложения

tolagro2.zip (82.2 Кб, 28 просмотров)

0

Сообщение от nesmehnoy прошу оценить и дать рекомендации по переделанной базе

Бегло посмотрел, вот мои "5 копеек":
01. Немного смущают числовые префиксы в названиях таблиц, по моему это лишнее, но ошибки в этом нет.
02. Похоже вы перемудрили с нормализацией БД, есть сильные подозрения, что можно было сделать проще.
03. И замеченного:
- Следите за размерность текстовых полей, длинна в 255 символов (макс. и по умолчанию) нужна далеко не всегда.
- Есть заказы клиентов - но нет таблицы состава заказа, т е. один заказ может включать только один товар, обычно это не так.

Спасибо за внимание к моему скромному мнению.
Успехов!

1

Как быть с ними, куда их включить, столбцами в таблицу номенклатур, или как-то отдельными таблицами подключить или еще какие варианты? Буду благодарен любым толковым рекомендациям.

Сделайте таблицу с характеристиками, где у вас будут все возможные характеристики товаров в базе. И вторую таблицу «Набор характеристик», где вы каждому товару будете присваивать нужные, в любом количестве

Добавлено через 4 минуты

2. Если товар имеет несколько цен, например базовая, опт, крупный опт, верно ли это все дело вписывать в одну таблицу price, как сделал сейчас?

полагаю что эти цены вычисляемые, например опт это по факту скидка, ну или наоборот.

1

Сообщение от Eugene-LS Бегло посмотрел, вот мои "5 копеек": 01. Немного смущают числовые префиксы в названиях таблиц, по моему это лишнее, но ошибки в этом нет. 02. Похоже вы перемудрили с нормализацией БД, есть сильные подозрения, что можно было сделать проще. 03. И замеченного: - Следите за размерность текстовых полей, длинна в 255 символов (макс. и по умолчанию) нужна далеко не всегда. - Есть заказы клиентов - но нет таблицы состава заказа, т е. один заказ может включать только один товар, обычно это не так. Спасибо за внимание к моему скромному мнению. Успехов!

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

Добавлено через 1 минуту

Сообщение от Zuikovod Сделайте таблицу с характеристиками, где у вас будут все возможные характеристики товаров в базе. И вторую таблицу «Набор характеристик», где вы каждому товару будете присваивать нужные, в любом количестве

Спасибо, прикину этот вариант

0