Форум MySQL

Всем привет!

Нужно создать серию таблиц (каталог-свойства) из которых одна должна быть таблица связей (много выборок, мало записей)  в которой должно быть поле со значениями разных типов (int, условно -"array",str) - тогда данное поле придется делать в 'text' чем значительно затрудню выборку. -если разделить на три самостоятельные таблицы по типам, то кажется все красиво, 'правильно' но,  большая часть работы будет с int таблицей а расстановка сил такая(соотношение загрузки таблиц ~70-80% на тип int и только ~10-20-30% на остальные типы), поэтому разделение на отдельные таблицы мне кажется более оправданно. - с типом "массивы" - я тоже не совсем в восторге то-ли использовать /serialize(array)/, то-ли построчно писать (там тип int) с сериализацией, мне очень удобно манипулировать, но тормознутый метод, писать построчно- наоборот..

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

Что-то не очень понятно, между чем и чем выбираете. Если у вас будет поиск в сериализованных данных - не используйте ни в коем случае (сериализованные данные это на случай логов)

>но, большая часть работы будет с int таблицей а расстановка сил такая(соотношение загрузки таблиц ~70-80% на тип int и
>только ~10-20-30% на остальные типы), поэтому разделение на отдельные таблицы мне кажется более оправданно
А почему "но"? int - очень быстрый тип, очень хорошо, что основная нагрузка на него падает - он исключительно хорошо процессорами обсчитывается. СУБД очень плохо обрабатывает строки чисел и вообще у неё очень бедные инструменты для работы со строками, а вот с таблицами - наоборот. Тут даже выбирать нечего, хотите преимущества СУБД и её исключительную скорость по обработки данных - создавайте нормализованную правильную схему, иначе вам придется все тащить на уровень приложения и обсчитывать там, кэшируя данные за пределами СУБД.

>Что-то не очень понятно, между чем и чем выбираете. Если у вас будет поиск в сериализованных данных - не используйте ни в коем случае (сериализованные данные это на случай логов)

cheops, а что вы подразумеваете под "..поиск в сериализованных данных.." просто пример приведите пожалуйста.
я уже до ответа принял решение разбивать по таблицам. по коду оказалось не так масштабно. единственное я застопорился на записи массивов
сначала сделал на построчной записи, все работает, но - есть проблемы с обновлением данных.
например: в админке при установке атрибутов к товару, есть образно атрибут "цвет" - он определен в чекерах (т.е. массив) и при записи построчно редактировать не получилось, так как список чекеров может быть большой и как их перезаписывать я так и не нашел решения. Тупо заменять при каждом редактировании товара, мне кажется неуместно. Может вы что дельное подскажите?
решил делать через json_encode($value) - получится один массив, одна строка. Редактировать просто.
сейчас размышляю над вашим ответом по поводу поиска в сериализации.. неужели опять переделывать?! :)) достал этот велосипед!
Спасибо!

Все просто.

Если вы у товара список цветов будете хранить в виде 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 кг возможные цвета - красный, синий, зеленый

и при этом все связи - по целочисленным первичным ключам, что крайне быстро.

Sfinks, у меня по этой схеме и сделано:
- т. товары
- т. значения свойств
- т. названия свойств
-т.связи
дополнительно:
- т.значений 'массивов' в этом пункте у меня есть проблемы-недопонимание как записывать.. описывал
ситуацию выше.

- т. значения-текст

Был бы признателен если бы помогли разобраться с проблемным пунктом.

А что еще не понятно?.... Вроде все расписал.....
Просто в таблице связей создаете не одну связь со значением типа массив, а несколько связей с одиночными значениями-текст или значениями-число.

и еще одну таблицу связей, на этот раз id связи товар-свойство из таблицы 3 со значениями соответствующих свойств
на мой взгляд это лишнее, так как определенное свойство должно принадлежать конкретному товару, даже если у другого товара есть такое-же свойство, а это связь многие одному (множество свойств одного товара)
и в таблице связи товара со свойством можно добавить соответствующие поля.

Вы прекрасно знаете, что вариантов организации много.
И я не утверждаю, что описанный - единственный.
Просто "один из".

Sfinks, что вы оправдываетесь... нормальный вариант из бредовых схем которых я встречал в инете наверное этот один из самых адекватных (это я об "общественном" каталоге) , схемы с Монго - не всчет!

Я не оправдываюсь. Я общаюсь! Valick тоже профи в этом деле =)

Благодарю, все вроде разложил, пока все работает.

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

А в чем проблема с сущностями и связями? все заранее определено.
Просто споткнулся на типах, в следствии чего и решил поднять проблему. Работаю с yii по этому приходится подстраиваться.