Dimitry SibiryakovkamenjahrЕсли в описуемом примере в статье надо будет группировать товары по
категориям (например, "Телевизоры", "Мп3-плейеры") А в категории "Телевизоры" еще по
"дюймовости" сортировать (например, чтобы узнать, чего продано бОльше) то гемор будет у
автора статьи
Да щаз. Автор статьи умнее тебя и добавил в таблицу category_id. По которому и будет
группировать, наплевав на названия. И если у него в ТЗ есть группировка телевизоров по
дюймовости, то он просто удлинит дерево категорий на один уровень. И не будет ломать себе
голову из-за опечаток в названии, несовпадения названия с названием производителя,
несоответствием с накладными и прочей тому подобной чепухой.
А с чего ты взял, что что по названиям то группировать предложено??? Али ты из фразы "надо будет группировать товары по категориям (например, "Телевизоры", "Мп3-плейеры") " вытянул? И причем тут очепятки в названии то?? В жизненных реалиях никто не будет же ручками в уже работающей системе вбивать "теливизыры" или "теловизоры". Будет скорее всего ГУИ, где комбобох будет или еще какой графический елемент (список), который будет репрезентировать для юзера товары, а уж технически будет тот же АйДишник браться например.
И к чему увеличивать дерево айди-категорий, вводить снова новые значения lft и rgt, если достаточно нормализовать упомянутую из статьи таблицу с аттрибутом
name .
Например, ввести таблицу "dimension" с id и name, затем ввести аттрибут dimension_id в упомянутую из статьи таблицу.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
+------------+-------------------+-------------+
| product_id | name | category_id | dimension_id |
+------------+-------------------+-------------+
| 1 | TV | 3 | 100
| 2 | TV | 3 | 200
| 3 | Super-LCD | 4 |300
| 4 | Ultra-Plasma " | 5 |400
| 5 | Value Plasma | 5 |10
| 6 | Power-MP3 128mb | 7 |10
| 7 | Super-Shuffle 1gb | 8 |10
....
+------------+-------------------+-------------+
