Разное

Во многих интернет-магазинах существует возможность создать группу, в которую будут входить товары с близкими родовыми признаками (скриншот).

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

Но ведь при создании в группе нет ни одного товара! Как же понимать такую группу, пустую?

Или для групп должна иметься отдельная таблица, содержащая только их названия?
А может быть, не только названия, но и ID входящих в группу товаров?

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

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

Как лучще действовать в этом случае?

Если один и тот же товар может относиться одновременно к разным группам, то нужны дополнительно таблица групп и таблица связей товаров с группами по id. Если же каждый товар жестко привязан к одной группе, то достаточно таблицы "группы" и поля "group_id" в таблице товаров.

1. Товар жестко привязан к группе. Соотвественно, group_id включаем в перечень

ALTER TABLE kattov ADD UNIQUE (group_id, producer, artikul, name_tov );

Так?

2. А в чем суть group_id ? Что этот параметр в себя включает?

> 2. А в чем суть group_id ? Что этот параметр в себя включает?
Создаете таблицу GROUPS. В ней будет название группы и ее ID:

group_id | group_name ---------------------   1      | холодильники   2      | телефоны     3      | машины       4      | трактора

Соответственно, если вы видите в товаре, что у него group_id=3 - знаете, что он относится к группе "машины".

Это самый простой вариант... Без вложенных групп-подгрупп и т.п.
---------------
> Соотвественно, group_id включаем в перечень
При чем тут ADD UNIQUE?

> Соотвественно, group_id включаем в перечень
При чем тут ADD UNIQUE?

Я имел в виду, что для каждого товара в таблице товаров потребуется включить в перечень полей group_id. Параметр этот необновляемый, так что в запросе

ALTER TABLE kattov ADD UNIQUE (group_id, producer, artikul, name_tov );

его надо добавить к producer, artikul, name_tov для последующего использования запроса INSERT . ON DUPLICATE KEY.

Разве не так?

Мы ж уже вроде выяснили, что даже для (producer,artikul,name_tov) уже не получается добавить уникальный индекс. А Вы к нему хотите еще что-то прибавить. Тем более не получится.

А если действовать как я предложил в разделе MySQL, т.е. через хеш, то зачем там еще одно поле, если сочетание producer,artikul,name_tov уже уникально? Это ни на что не повлияет.

Мне больше интересно, как вы думаете автоматизировать разделение товаров по группам? Не в ручную же 1,5 млн записей сортировать?

как вы думаете автоматизировать разделение товаров по группам?
Этот вопрос пока остается открытым.

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


Мы ж уже вроде выяснили, что даже для (producer,artikul,name_tov) уже не получается добавить уникальный индекс.

Во вложении скриншот PHPMyAdmin. Это нормальная ситуация?

Так вам все-таки удалось создать индекс.... Уменьшили размер полей до varchar(X)?

Тем не менее это не отменяет фразы "зачем там еще одно поле, если сочетание producer,artikul,name_tov уже уникально?"

ТАМ - подходит и к уникальному индексу, а не только к хешу. Незачем нагружать индекс еще и group_id.

Пришлось отказаться от поля ТЕХТ в пользу varchar.

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

Нет, чем больше полей - тем больше размер, тем больше нужно оперативки, и тем медленнее будет работа индекса.

Чем больше полей вообще в таблице или чем больше полей включно в формирование UNIQUE?

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

А как реализуется ситуация, когда имеют место вложенные подгруппы?

То есть, помимо товаров в корне каталога, имеется группа товаров. И в этой группе есть товары, но в ней есть еще и подгруппа.

А в подгруппе тоже есть товары, но в ней есть еще и под-подгруппа. И в под-подгруппе есть тоже товары и своя под-под-подгруппа…

Это дерево.
Есть несколько способов реализации.
Вот этот способ мой любимый. Он довольно сложен и в реализации и в понимании (так чтобы сходу взять и пользоваться), но самый удобный и функциональный после того как поймете его.

сложен и в реализации и в понимании

А какой способ самый простой?

Самый простой - таблица групп из 3ех полей:

id | parent_id | name ----------------------- 1  | 0         | подушки 2  | 0         | одеяла 3  | 1         | красные 4  | 1         | зеленые 5  | 2         | искуственные 6  | 2         | натуральные 7  | 5         | халофайбер 8  | 5         | полиэстер

где parent_id - id родительского узла.
Т.е. в этой таблице такое дерево:

-подушки --красные --зеленые -одеяла --искуственные ---халофайбер ---полиэстер --натуральные

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

А если сделать только одну таблицу групп такого вида

<?php id | name  -----------------------  1  | подушки  2  | подушки/красные  3  | подушки/зеленые  4  | одеяла  5  | одеяла/искусственные  6  | одеяла/искусственные/халофайбер  7  | одеяла искусственные/полиэстер  8  | одеяла/натуральные

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

Почему так нельзя?

Это во-первых денормализация, а во вторых, с такой структурой работать - сервер офигеет.
Представьте, что вам надо найти все товары группы "одеяла".

SELECT * FROM tovar JOIN group USING( group_id ) WHERE group_name LIKE '%одеяла%'

WHERE по строковому полю, да еще и без индекса, да еще и LIKE.
Получается полнотекстовый поиск при обычной выборке товаров.

Так что "нельзя" - понятие относительное. Смотря что вы в него закладываете. Возможно. Но вот на счет скорости и нагрузки....

А если поступить таким образом:

Группе "Одеяла" соответсвует group_id = 4.

Тогда я бы попытался выполнить запрос:

<?php SELECT * FROM tovar WHERE group_id = 4;

Это не годится?

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

Это плохо?

> Группе "Одеяла" соответсвует group_id = 4.
А откуда вы это узнаете?

Полагаю ответ на этот вопрос ниже:
> Если потребуется поиск именно по названию, то я бы предварительно сделал запрос
> к таблице групп, чтобы узнать group_id.
А это при такой структуре и есть полнотекстовый поиск.

Разница лишь в том, что вы мой запрос разделили на 2 запроса.

Кроме того, как у вас в таблице товаров будет храниться номер группы к которой принадлежит товар?
Если просто номер, то например искусственное одеяло из полиэстера будет иметь номер группы 7 и поиск всех одеял по номеру 4 его не выведет.
Т.е. искусственное одеяло из полиэстера должно принадлежать к группам 4, 5 и 7.
Как вы это будете хранить?

>> Группе "Одеяла" соответсвует group_id = 4.
>А откуда вы это узнаете?

а почему нельзя эту цифру (4) передавать в запрос вместо слова (одеяла)? т.е. на странице при выборе жестко связать эти две величины?

>Т.е. искусственное одеяло из полиэстера должно принадлежать к группам 4, 5 и 7.
>Как вы это будете хранить?

а если сделать так:
id \\товар
id_vid \\ вид товара (одеяло, подушка)
id_tip \\ материал
id_color \\ цвет

и все это цифры?

Лично я ниче не понял.

дурак не тот кто не понял, а тот кто спрашивать не умеет :(

я имею ввиду - а почему бы в таблице товаров не насоздавать столько столбцов, сколько у них (товаров) характеристик? :\ и значения в полях этих столбцов задавать не словами (подушка) а цифрами? а потом по ним выбирать?

И на каждую группу товаров по отдельной таблице "товары"?
Или у мобильных телефонов будут характеристики и от мотокультиваторов и от занавесок?
Вы хорошо представляете себе таблицу с 2000 столбцов?
А если еще учесть что тут речь идет о таблице с 1,5 млн. строк......

был неправ, вспылил, прошу дать возможность загладить, искупить. все :)

Вообще, вас сбило то, что я не удачную структуру групп товаров привел в качестве примера.
Но на то он и пример. Там можно было написать группа А, подгруппа Б.
Не в этом суть. А в том, что речь не о характеристиках, а именно о группах.
Например такая структура будет понятнее:

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

_____________
З.Ы. Кажись у велосипеда появился второй конструктор =))))))

Полагаю, что оптимальное решение зависит от задачи (хотя универсальное подходит всегда).

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

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

Каждая из этих групп вполне может быть изначально связана с соответсвующим group_id.

Предположим, что посетителя заинтересовали продукты питания. Кликнув по этой группе, он увидит группы
--молочные продукты
--колбасы
--напитки

Кликнув на молочные продукты, увидит
сыры
молоко
кефиры

А потом в каждой из них получит перечень товаров, который может быть быстро собран по group_id.

Что я здесь неверно интерпретировал?

Вы о реалистичном примере, или о программной реализации?

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

Если из программы, то выборки по всей группе понадобятся администраторам, бухгалтерам и т.п. для анализа, отчетности, логистических перестановок и т.п.

Вы о реалистичном примере, или о программной реализации?

Если из программы, то выборки по всей группе понадобятся администраторам, бухгалтерам и т.п. для анализа, отчетности, логистических перестановок и т.п.

Я о программной реализации, о показе в Панели управления сайтом.

Когда создается группа, то в таблице формируется group_id и заполняется group_name, а также id родовой группы, к которой относится создаваемая группа. По идее, этих сведений достаточно для любой выборки.

В общем, надо попробовать на макете - любопытно, получится или нет.