|
| |
|
|
| |
для: Denandi
(11.12.2013 в 10:48)
| | | Я не оправдываюсь. Я общаюсь! Valick тоже профи в этом деле =) | |
| |
|
|
| |
|
|
| |
для: Sfinks
(11.12.2013 в 08:41)
| | | Sfinks, что вы оправдываетесь... нормальный вариант из бредовых схем которых я встречал в инете наверное этот один из самых адекватных (это я об "общественном" каталоге) , схемы с Монго - не всчет! | |
| |
|
|
| |
|
|
| |
для: Valick
(10.12.2013 в 21:43)
| | | Вы прекрасно знаете, что вариантов организации много.
И я не утверждаю, что описанный - единственный.
Просто "один из". | |
| |
|
|
| |
|
|
| |
для: Valick
(10.12.2013 в 21:29)
| | | А в чем проблема с сущностями и связями? все заранее определено.
Просто споткнулся на типах, в следствии чего и решил поднять проблему. Работаю с yii по этому приходится подстраиваться. | |
| |
|
|
| |
|
|
| |
для: Sfinks
(10.12.2013 в 13:53)
| | | Благодарю, все вроде разложил, пока все работает. | |
| |
|
|
| |
|
|
| |
для: Sfinks
(10.12.2013 в 13:53)
| | | и еще одну таблицу связей, на этот раз id связи товар-свойство из таблицы 3 со значениями соответствующих свойств
на мой взгляд это лишнее, так как определенное свойство должно принадлежать конкретному товару, даже если у другого товара есть такое-же свойство, а это связь многие одному (множество свойств одного товара)
и в таблице связи товара со свойством можно добавить соответствующие поля. | |
| |
|
|
| |
|
|
| |
для: Denandi
(10.12.2013 в 10:58)
| | | Denandi, построение архитектуры БД начинается с определения сущностей и связей этих сущностей. На каждую сущность и связь многие ко многим выделяется по таблице.
А вы начинаете с какой-то каши заваренной на типе полей. | |
| |
|
|
| |
|
|
| |
для: Denandi
(10.12.2013 в 10:58)
| | | А что еще не понятно?.... Вроде все расписал.....
Просто в таблице связей создаете не одну связь со значением типа массив, а несколько связей с одиночными значениями-текст или значениями-число. | |
| |
|
|
| |
|
|
| |
для: Sfinks
(10.12.2013 в 10:35)
| | | Sfinks, у меня по этой схеме и сделано:
- т. товары
- т. значения свойств
- т. названия свойств
-т.связи
дополнительно:
- т.значений 'массивов' в этом пункте у меня есть проблемы-недопонимание как записывать.. описывал
ситуацию выше.
- т. значения-текст
Был бы признателен если бы помогли разобраться с проблемным пунктом. | |
| |
|
|
| |
|
|
| |
для: Denandi
(10.12.2013 в 09:12)
| | | Все просто.
Если вы у товара список цветов будете хранить в виде JSON, то как вы будете искать, например, все "красные" товары?
Вы их конечно найдете, используя: WHERE color LIKE '%красный%'
Но эта операция крайне медленная.
А правильно так:
Есть таблица товаров в которой у каждого товара есть ID.
Есть таблица характеристик (цвет, масса, материал и т.п.), где у каждой характеристики также есть ID.
Есть таблица связей товара с характеристикой, где на каждую характеристику товара заводится отдельная строка, а для тех характеристик, которые отсутствуют у данного вида товара и связь будет отсутствовать. И у каждой такой связи также есть свой ID.
Например в таблице товаров у нас есть дрель с id=1, характеристики имеют свои id: цвет - 1, масса - 2, запах - 3, материал - 4. Тогда таблица связей будет выглядеть так:
id | tovar_id | feature_id
-------------------------
1 | 1 | 1
2 | 1 | 2
3 | 1 | 4
|
как видите, у дрели нет характеристики "запах".
Теперь еще нужно создать таблицу значений характеристик, где у каждого также есть ID:
id | value
----------
1 | пластик
2 | 1 кг.
3 | красный
4 | синий
5 | зеленый
|
и еще одну таблицу связей, на этот раз id связи товар-свойство из таблицы 3 со значениями соответствующих свойств. При чем связи могут быть 1 ко многим. Это обеспечит хранение различных значений для одного свойства, не используя массив:
id_property | id_value
----------------------
1 | 3
1 | 4
1 | 5
2 | 2
3 | 1
|
Из этого набора таблиц мы можем извлечь, что товар "дрель" у нас имеет характеристики:
материал - пластик
масса - 1 кг
возможные цвета - красный, синий, зеленый
|
и при этом все связи - по целочисленным первичным ключам, что крайне быстро. | |
| |
|
|
|
