Проектирование для каталога

[alex_anderr]

Всем привет.

На сайте есть рубрики, у них есть подрубрики, у них есть товары, у товаров есть характеристики, у характеристики есть значения характеристик.

Есть таблица пользователей, которые "управляют" этими товарами.

Как лучше организовать структуру? И где могут возникнуть проблемы в дальнейшем?

В моем представлении так.

Таблицы:

1. Рубрика (id, name)

2. Подрубрика (id, name, fk_рубрика_id)

3. Товары (id, name, fk_подрубрика_id)

4. Характеристики (id, name, fk_товары_id)

5. Значения характеристик (id, name, fk_характеристики_id)

6. Пользователи (id, login, pass)

7. Таблица вывода товаров (id, fk_значения характеристик_id * кол-во характеристик, fk_пользователи_id)

Здесь fk - foreign key, _блабла_ - на какую таблицу ссылка, id - на первичный ключ этой таблицы

Получается что в этой пирамиде последняя таблица вырастет в геометрической прогрессии. Не лучше ли таблицу 7 разделить на кучку таблиц по количеству подрубрик? (их будет совсем немного).

Спасибо, ребят

[MiksIr]

"Рубрика - подрубрика" лучше сразу реализовывать в виде дерева. Посложнее, но практичнее.

Характеристики - искать/читать про EAV (entity attribute value)

Таблица 7 - не нужна вообще.

[Veseloff]

Вот так с ходу и не скажешь. Хотя есть вопросы. А под-подрубрик точно не будет? Неочевино что такое характеристики и значения и почему они в таком виде. Может, их стоит вынести в таблицу с товарами? Или стоит это дело нормализовать? На таблице вывода товаров у меня отпада башка — я вообще не понял что и как вы хотите сделать.

[alex_anderr]

"Рубрика - подрубрика" лучше сразу реализовывать в виде дерева. Посложнее, но практичнее.

реляц? в одной таблице?

Характеристики - искать/читать про EAV (entity attribute value)

окай

Таблица 7 - не нужна вообще.

понял, спс.

Вот так с ходу и не скажешь. Хотя есть вопросы. А под-подрубрик точно не будет? Неочевино что такое характеристики и значения и почему они в таком виде. Может, их стоит вынести в таблицу с товарами? Или стоит это дело нормализовать? На таблице вывода товаров у меня отпада башка — я вообще не понял что и как вы хотите сделать.

1. Точно не будет. Это наименование товаров. А их сколь угодно много.

2. Мне тоже не очевидно пока А в каком виде лучше? EAV из поста выше?

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

5. Ввод-вывод подумал что может понадобится для сортировки и всяких пользовательских примочек. Но уже думаю, что все запросы строятся и без нее. Это мышление новичка в бд, что поделать...

--

Почитал про EAV. Проблем выходит больше чем плюсов. Мой вариант сильно плох как аналог?

--

Еще UPD: Я не совсем корректно объяснил свое представление таблиц. Таблица 3 будет как раз подподрубрикой.(рубрика "мобильная связь", подрубрика "смартфоны", подподрубрика "Андроид", например) И получается для того чтобы вывести запрос мне нужно будет обратится ко всем таблицам сразу. Или же создать как раз таблицу 7, для того чтобы храинть ключи со всех таблиц в одном месте и при запросе обращаться к одной таблице.

Скажите где я не прав?

Edited March 20, 2012 by alex_anderr

[alex_anderr]

А еще можно вопрос?

Как лучше делать таблицу с товарами (последнюю №7)? Как правильней может быть?

Вариант раз: вбивать в нее всю информацию из остальных таблиц. В этом случае будет огромная таблица со всеми видами товаров. И запросы для вывода будут по полям этой таблицы.

Вариант два: Вбивать в эту таблицу данные первичных ключей из остальных таблиц. Здесь, как я представляю, запросы для вывода товаров будут сложней, но не будет лишних "дублирующихся" значений.

[rus]

я бы наверное объединил:

1) и 2) - реализовать в виде дерева как уже сказали выше

4) и 5) - так как вообще не понимаю для чего отдельно хранить х-ки от их значений?

например: цвет (х-ка) - синий(зн-ие)... ну и т.д.

7) - так вообще не понятно для чего, выкинул бы вообще.

[alex_anderr]

1 и 2 уже поздно )

Но в переделках учту.

4 и 5 задумывалось, что характеристики для нормализации будут уникальными значениями (У различных товаров есть, например, ширина).

Но запросы оказались довольно жесткими для восприятия, поэтому вариант объединения вполне адекватный. А в товарную планировалось добавлять минимум: номер товара, номер пользователя его добавившего, и доп. пару столбцов вроде показа/скрытия товара с общих результатов поиска пользователем сайта.

[MiksIr]

Нормальный вариант - EAV, ненормальный вариант - на каждую характеристику свой столбец. Свое решение ищите где-то между этими двумя. EAV сложен поиском с условием AND - или джойны нужны или выбирать по каждому значению и в скрипте пересекать массивы. На самом деле ничего страшного в джойнах нет. Но если набор характеристик, по которым поиск, ограничен, то можно оставить их в таблице товаров, а в EAV вынести все остальное. В общем ничего сложного. Как ни крути - 3 таблицы, никак не 4. Смысла разбивать таблицу товаров на две нет.

Edited March 27, 2012 by MiksIr

[alex_anderr]

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

Плюсы тоже есть. Поэтому и ищу нечто среднее.

А почему нельзя пару "хар-ка - значение" писать в строку, а не в столбец?

Ну будет в этом случае при 100 000 товаров число строк умноженное на количество характеристик, 20 например. Получается 2 млн строк, но при поиске по индексу проблем не должно возникнуть.

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

Еще раз:

1. Рубрика и подрубрика

2. Подподрубрика

3. Характеристики и значения

4. Товар (айди товара обязательно, айди пользователя обязательно, доп. характеристики обязательны). Думаю, что без этой таблицы я не обойдусь.

5. Пользователи.

Это мой вывод из всех выше написанных сообщений. Вроде все верно. Единственное, что можно убрать таблицу 2, но мне с ней пока что удобней )

Итого 4-5 таблиц, не меньше. Все так?

[MiksIr]

Не понимаю... пара "характеристика - значение" в строку - это и есть EAV

[alex_anderr]

Вот ччерт. Значит я от него уходил и к нему пришел )

Чтож, значит использую его. А по таблицам все верно понял?

[MiksIr]

Ну да, только в таблице 3 соответственно еще внешний ключ на id товара. Вот и будет EAV (Entry - id товара, Attribute - характеристика, Value - значение).

[alex_anderr]

Мне нравится когда в каждой таблице есть автоинкрементный id. Мало ли когда понадобится.

Значит сделаю (id, характеристика, значение, FK_айди товара). Выходит AVE

[rus]

Выходит AVE

а при чем тут приветствие?

речь шла о: EAV (Entity-Attribute-Value) - Сущность-атрибут-значение.

[alex_anderr]

В моем случае полчилось Attribute-Value-Entity. Игра слов.

[rus]

В моем случае полчилось Attribute-Value-Entity. Игра слов.

да я бы может и не зацепился бы (не люблю оффтопить), но ссылка то ведет именно на Аве

[alex_anderr]

Вы сильно умный и ссылка сбила мысль. Это нормально.