IceNinja
7.06.2013 - 13:55
Делаю каталог на YII.
Предполагается несколько типов объектов, скажем, А, B и С, причём вот в такой родительской иерархии - A > B > C.
Объектов типа С предполагается около 15 тысяч в БД. А объектов А и B - существенно меньше, может, вместе наберётся ну две тысячи максимум..
Суть вот в чём. Где-то нужно хранить свойства этих объектов, причём есть два важных момента:
1) В принципе, наборы свойств для разных типов объектов различаются. Т.е. для А - это несколько свойств, около 5-10, для объектов типа В - ну тоже где-то столько же, а для С - около 15-20 свойств, может быть и больше, допустим, 20. Всего свойств, выходит, 20 + 10 + 10 = 40 где-то.
2) и при этом нужно иметь возможность добавлять ещё свойства, например, объекту типа А добавить несколько свойств, для него нехарактерных.
Короче, решил я это дело хранить так - объекты в одной таблице, свойства в другой, наборы свойств - в третьей, а саму связь свойств с объектами - в четвёртой. Примерно как-то так:
И вот эта четвёртая таблица ("Objects_properties") вызывает у меня нервяк. Если там будет (15000 + 2000 )* 40 = 680000 записей. Не просяду ли я с таким объёмом? Объекты нужно будет фильтровать там, то, сё. Может, вместо Мускула использовать что-то ещё? Или спроектировать иначе?
Такие проблемы решаются по мере их поступления. А не по принципу - "я решил сконструировать автомобиль, какая будет его максимальная скорость".
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
sergeiss
7.06.2013 - 16:27
T1grOK, ты не прав! Проблемы проектирования БД надо как раз на начальном этапе решать, а не тогда, когда база падать начнет
Автору темы: если набор свойств для каждого вида данных строго определенный, то тогда их можно хранить в одной строке с самим объектом.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss вопрос в чем "Насколько быстро?". На этот вопрос никто не ответит. Неизвестно какое соотношение Insert|update|select, интенсивность обращений.
И немаловажный факт - используемые аппаратные ресурсы.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
traviam
16.06.2013 - 11:46
| Цитата (sergeiss @ 7.06.2013 - 16:27) |
Автору темы: если набор свойств для каждого вида данных строго определенный, то тогда их можно хранить в одной строке с самим объектом. |
Я не автор темы, но есть такая же проблема.
Если набор свойств хранить в одной строке (типа, "width:100; height:200; cost:180;", или всякие json-ы и сериализованные массивы), то как организовать поиск? Не like-ами же.
T1grOK
16.06.2013 - 12:45
| Цитата (T1grOK @ 8.06.2013 - 05:56) |
| Я не автор темы, но есть такая же проблема. |
Ну так тему отдельную создай. Отвечу.
И другим проще будет ориентироваться, а не так что 5 тем в одной.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
sergeiss
16.06.2013 - 13:00
| Цитата (traviam @ 16.06.2013 - 11:46) |
| Если набор свойств хранить в одной строке (типа, "width:100; height:200; cost:180;", или всякие json-ы и сериализованные массивы), то как организовать поиск? Не like-ами же. |
Ты не понял... Под словами "в одной строке" я имел ввиду, что в одной записи, т.е. в разных колонках
| Цитата (T1grOK @ 16.06.2013 - 12:45) |
| Ну так тему отдельную создай. |
Да пусть тут будет, наверное. Потому что и к "основной" теме имеет отношение.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
traviam
16.06.2013 - 13:19
| Цитата (T1grOK @ 16.06.2013 - 12:45) |
| Ну так тему отдельную создай. Отвечу. |
Да я вот согласен с sergeiss, лучше в этой теме дообсуждать - проблема такая-же, только БД уже есть.. :-(
Ответь тут, если не трудно :3
| Цитата (sergeiss @ 16.06.2013 - 13:00) |
| Ты не понял... Под словами "в одной строке" я имел ввиду, что в одной записи, т.е. в разных колонках |
У фирмы уже есть заполненная БД (MySql).
Суть такова.
Таблица групп товаров {group_id, group_name} - всего около 180 штук.
И таблица самих товаров {product_id, product_group_id, product_name, product_attributes} - всего около 50 000 штук (по 200-500 штук в каждой группе).
В product_attributes - строки вида "width:100; height:200; cost:180;", самих атрибутов наберётся тоже штук 50 000..
Проблема: как искать по такой БД?
Извратиться и поменять структуру таблиц, вынеся атрибуты в отдельную таблицу вида {attribute_id, attribute_name} и добавить таблицу для связей {product_id, attribute_id, attribute_value}?
sergeiss
16.06.2013 - 16:22
| Цитата (traviam @ 16.06.2013 - 13:19) |
| Извратиться и поменять структуру таблиц, вынеся атрибуты в отдельную таблицу вида {attribute_id, attribute_name} и добавить таблицу для связей {product_id, attribute_id, attribute_value}? |
Да. Только это называеться не "извратиться", а "привести из извратного вида к
нормальной форме"
(подробнее см. ссылку)
Именно это, "нормальную форму", я и имел ввиду:
| Цитата (sergeiss @ 16.06.2013 - 13:00) |
| Под словами "в одной строке" я имел ввиду, что в одной записи, т.е. в разных колонках |
PS. В зависимости от типов данных надо смотреть: либо делать отдельную таблицу и связывать с ней по айди, либо просто отдельную колонку, где прописывать данные.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
traviam
16.06.2013 - 16:32
| Цитата (sergeiss @ 16.06.2013 - 16:22) |
| Только это называеться не "извратиться", а "привести из извратного вида к нормальной форме" |
"Извратиться" - в смысле перегона кучи имеющихся данных в новые таблицы и переписывания чужого кода для правильной работы с новой структурой..
Про нормальные формы в курсе, спасибо. Просто думал - вдруг есть способ каким-нибудь костылём сделать поиск без изменения структуры :-)
sergeiss
16.06.2013 - 16:42
| Цитата (traviam @ 16.06.2013 - 16:32) |
| Просто думал - вдруг есть способ каким-нибудь костылём сделать поиск без изменения структуры :-) |
Нее... Халява отменяется
У тебя впереди "полный изврат":
| Цитата (traviam @ 16.06.2013 - 16:32) |
| "Извратиться" - в смысле перегона кучи имеющихся данных в новые таблицы и переписывания чужого кода для правильной работы с новой структурой.. |
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
T1grOK
16.06.2013 - 17:41
| Цитата (traviam @ 16.06.2013 - 07:46) |
| Если набор свойств хранить в одной строке (типа, "width:100; height:200; cost:180;", или всякие json-ы и сериализованные массивы), то как организовать поиск? Не like-ами же. |
Отвечу более обощенно. БД очень и очень не любят большие поля. Поиск по таким полям замедляется, индексы разростаются и опять же становятся неповоротливыми и тормозят.
Вынеся атрибуты в отдельную таблицу, мы уже будем выбирать в основном по числовым данным, а это в десятки и сотни раз быстрее, чем обрабатывать строковые данные.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.