Здравствуйте.

Есть товарный справочник

id | name

Его необходимо упорядочить в следующей иерархии

Катерория001
Катерогия002
Категория003

Товар может быть привязан только к последнему уровню в этой иерархии, категорий на любом уровне вложенности может быть несколько.

Кроме того, у товара существуют еще одноуровневые разрезы, по которым его необходимо сегментировать, а именно:
1. Фирма изготовитель
2. Страна
3. Тип


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

Пока мысль такая, хранить иерархию с наименованием товара с одной таблице вида

id | parentid | name

а одноранговые классификаторы связать с этой таблицей с помощью внешних ключей
в результате получим


id | parentid | name | idbrand | idcountry | idtype

Решение не нравится с точки зрения масштабируемости, с иерархией вопрос решается, а вот при увеличении классификаторов придется добавлять поля и ключи к ним.

Спасибо.

А если сделать так 2 таблицы

одна таблица иерархии

id | parent | name | idtovar

и таблица товаров

id | name

товары связаны с иерархией один ко многим

В иерархии будет сама иерархия + классификаторы товаров как верхние уровни с parent = null

Таким образом если товар у нас находится в "Катрегоии03", его фирма производитель "SONY" а страна "Япония" то в таблице иерархии для этого товара будет 3 записи.

Хотелось бы услышать минусы этого решения.

Naf,

допустим в таблице товаров запись
id= 1
name = "пылесос"

в таблице иерархии

id | parent | name | idtovar

1 | null | category01 | null
2 | 1 | category02 | null
3 | null | Brand | null
4 | 3 | Sony | null
5 | null | Country | null
6 | 5 | Japan | null

Для товара пыселос в таблице иерархии будут 3 записи

7 | 1 | null | 1
8 | 3 | null | 1
9| 5 | null | 1

Приблизительно вот так...

Naf,

Вот я бы и хотел услышать почему плохо, не грамотно и не удобно. Пока единственный минус вижу в том, что самому нужно контролировать, чтоб запись из таблицы товаров не дублировалась в иерархии и классификаторах, но это можно обойти путем проверки существования записи на самом верхнем уровне с parent = null

NafDinDimNaf,

Вот я бы и хотел услышать почему плохо, не грамотно и не удобно. Пока единственный минус вижу в том, что самому нужно контролировать, чтоб запись из таблицы товаров не дублировалась в иерархии и классификаторах, но это можно обойти путем проверки существования записи на самом верхнем уровне с parent = nullВы смешиваете разные сущности и связи в одну кучу: как вы проверите, что ваш товар не будет лежать в 2-х иерархиях, если уровень иерархии неограничен? как вы отличите иерарахию от свойства-классификации?

Вот!!! теперь по существу:

1. уровень иерархии неограничен, но товар может находится только на самой последней ветке, проверить его существование в иерархии легко, найдя parent=null ветки, куда я хочу его вставить

2. Отличать иерархию и классификаторы не нужно, условие одно, товар может находится только один раз в каждой ветке со значением parent = null

3. А смешивая сущности я добиваюсь универсальности

Эти минусы меня тоже смущают, поэтому и обратился на форум, но в целом решение универсальное, что кажется большим плюсом.

Naf,

В предложенной Вами выше модели отлично контролируется, то что товар может находится только на одном уровне иерархии, но связь классификаторов с товаров тоже придется контролировать руками, т.е. в таблицу которая связывает значение классификатора и значения товара, можно занести, что товар относится и к SONY и к Panasonic например... Вот если б еще и это контролировалось СУБД, решение было бы полностью универсальным.

NafDinDimNaf,

В предложенной Вами выше модели отлично контролируется, то что товар может находится только на одном уровне иерархии, но связь классификаторов с товаров тоже придется контролировать руками, т.е. в таблицу которая связывает значение классификатора и значения товара, можно занести, что товар относится и к SONY и к Panasonic например... Вот если б еще и это контролировалось СУБД, решение было бы полностью универсальным.уникальный ключ для пары полей (КлючТовара, КлючЗначенияСвойства) в таблице ЗначенияСвойствТовара

Я так и сделал, но контролирует только что товар не может дважды относится к SONY, но не контролирует, что товар может относится и к SONY и к Panasonic

NafDinDimNafDinDimNaf,

В предложенной Вами выше модели отлично контролируется, то что товар может находится только на одном уровне иерархии, но связь классификаторов с товаров тоже придется контролировать руками, т.е. в таблицу которая связывает значение классификатора и значения товара, можно занести, что товар относится и к SONY и к Panasonic например... Вот если б еще и это контролировалось СУБД, решение было бы полностью универсальным.уникальный ключ для пары полей (КлючТовара, КлючЗначенияСвойства) в таблице ЗначенияСвойствТовара

Я так и сделал, но контролирует только что товар не может дважды относится к SONY, но не контролирует, что товар может относится и к SONY и к Panasonic
Добавьте в таблицу ЗначенияСвойствТовара поле КлючСвойства и уникальный индекс по паре (КлючТовара, КлючСвойства), правда это нарушит нормализацию
либо
вставьте триггер на вставку/изменение проверяющее уникальность

Вариант, но видите при этом решение теряет нормализацию, как и у меня в двух таблицах.

Naf,

Спасибо, идею я понял, теперь буду обдумывать все за и против вашего и моего решения.