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

sdkukostiks,
С Вашей БД особо не разбирался-предлагаю вариант:
sdku, благодарю за ответ, посмотрел ваш файл, в целом логика вроде понятна. А в целом практика нормальная, когда куча характеристик устроены столбцами в таблице?

vmag,
Возможно, но теперь, по всей видимости поздно. Вот получается выбор между eav и то что sdku и Озверин, столбцами. Пока что ищу, изучаю примеры хотя бы, как это в реальных условиях выглядит, реальные рабочие базы.

sdku,
А разве не будет EAV, называться такой вариант, если я завожу отдельную таблицу id | НазваниеСвойства | ЗначениеСвойства | idТовара
И строками эти свойства заполняю.
Затем уже эта таблица каким-то образом связывается с таблицей товары или номенклатуры.
Возможно я не совсем понимаю логику построения баз данных и задаю глупые вопросы.

PredeclaredРезюмируя:
не шмогла моя одна "широкая" табличка вместить в себя все уникальные свойства описания сущности - товар.
А если разбить это на более мелкие таблицы. Например, за сущность взять не товар, а тот же принтер, жесткий диск, материнка и т.д.
И это все потом сослаться со всех к одной таблице - товар. где будет id | idnamePrinters | idPrinters , где idnamePrinters - id товара в таблице Printers, а idPrinters - id таблицы принтеров, в таблице где перечислены все названия таблиц типа tabCategories?

Друзья, благодарю за рекомендации, выпал из беседы, т.к. стал набираться немного ума, чтобы достичь большего понимания.
В итоге пересмотрел некоторые моменты, прошу оценить и дать рекомендации по переделанной базе, логику кратко опишу.
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, как сделал сейчас?
т.к. файл более 150кб даю ссылку на файл с базой
https://yadi.sk/d/Sjzi3WDgxtYveA
3. Товары разной направленности: растения, стройматериалы, услуги, имеют разные характеристики, потом они будут использоваться для внесения в прайс листы и выгрузки на сайт.
Например, растения
Урожайность
СрокиСорзревания
Цвет плода
Морозостойкость

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

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

Догадался оформить файл в архив, закрепил базу

sdku2. 2_product_list - содержит названия товаров/услуг, это может быть сорт растения, название строительного материала и т.д., просто список.
3. 5_nomenclature - товар/услуга, где уже указывается кроме названия - артикул, единица измерения - кг, шт., мешок, кассета и должны быть свойства товаров.

не совсем так
2. 2_product_list - имеет только названия товаров и услуг, т.е. как справочник и из него уже подставляется в номенклатуры, возможно это лишне и не нужное, проще просто писать в номенклатуру.

alecko каждую сущность: стройтовары или растения нужно описывать, и есть два варианта: описывать их должен разработчик в коде как у вас, или юзер в форме- (я раньше уже представлял свое видение, может пропустили).
Спасибо, ваш пример смотрел и кое-что с него почерпнул полезного. Еще раз пересмотрю.
Скорее всего я буду вносить данные, по крайней мере первое время точно, но через форму конечно удобнее.
С формами что-то я плохо разобрался, не получается делать зависимые поля делать, чтобы при выборе одного, показывалось другое и т.д. пока что не смог понять, но сначала надо с таблицами определиться и связями, а тож не во все въехал

PredeclaredВ описании вашей модели данных я этого, увы, не увидел.
Благодарю за замечание, пока что планируется только для физиков продажи.
А вот закупки могут быть откуда угодно, с того же али.

ЛапухСергей Лалов...У вас хорошая база, связи нормально проброшены,...
Эх-х-х-х, жаль что не в - MDB.
Ибо на старости лет, тоже хотса приобщиться к хорошему и нормальному, а то так и помрешь нехорошим и ненормальным.
Вроде получилось в mdb

sdkuвдогонку(перечитал после публикации)-подчиненная форма на таблице "свойства" с отображением полей для выбранной категории
Правильно понял, что делаем таблицу:
Свойства товаров
idoption
name_option
id_categories

и соответственно, для категорий указываем какая характеристика(свойство) к какой категории приходится.
а далее уже в таблице номенклатуры указываем idoption

Predeclaredkostiks..., пока что планируется только для физиков продажи...
Так описания "физиков" я и не увидел, среди прочего.
3 табличка - 3_custumer, там ФИО, тел и прочее. Или я не правильно понимаю вопрос?

Predeclaredkostiks... - 3_custumer, там ФИО, тел и прочее...
Вот-вот.
Там "фарш" сомнительного содержания, на роль описания "физиков" не подходящий.
Чего не хватает? ФИО телефоны, почта, ссылка на страницу соцсетей, город, поселок, адрес с улице и домом, индексом.

PredeclaredКстати, файлы по ссылке и в первом архиве разные.
Да, то что в топике, это уже устаревший, переделал по-другому, т.к. в том запутался уже сам) новую с нуля написал, но и то что первый, он содержит данные которые будут использоваться в дальнейшем, но я его так и не смог доработать.