Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: 6312
Последний выпуск: 19.06.2015

Организация БД с шаблонами свойств VS скорость при объеме.

9.9K
26 сентября 2011 года
De_Montale
80 / / 23.08.2007
Доброго вам времени суток.
Чисто теоретически представьте базу данных с товарами.
Не суть столь важно какими. Важно лишь, что их много, и что разные типы товаров имеют определенные наборы свойств.

Как лучше всего организовать БД так, чтобы при организации шаблонов свойств снизить нагрузку на сервер MySQL при доп. выборках.

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

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

Скажем, "сигареты с кол-вом смолы такой то" или "сметана с процентом жирности таким то".

Интересует именно золотая середина между скоростью работы и низкой нагрузкой на сервер.

Заранее благодарен любому совету.
14
26 сентября 2011 года
Phodopus
3.3K / / 19.06.2008
Навеяно 1С: каждый сколько-бы-то-ни-было отличающийся товар должен быть отдельной строкой таблицы и у каждого товара есть поле "Группа" посредством которого можно отнести товары к одной из введеных групп. Как хранить группы - в этой же таблице или в соседней - дело вкуса.
385
27 сентября 2011 года
SomewherSomehow
477 / / 25.07.2004
При оценке производительности важно знать, как именно будет идти работа с данными. Все своиства писать в строку подошло бы, если б, например, поиск объектов в бд осуществлялся всегда только по ID. А если нужно искать по свойствам, строка - не лучший вариант.
Можете посмотреть в сторону классического подхода Entity Attrib Value (EAV).
Т.к. мы используем на работе EAV в одной из частей системы, то скажу из личного опыта, такой подход может и позволяет хранить универсальные данные, но за всякую универсальность надо платить производительностью. Так что, самым лучшим решением, по прежнему, является грамотное классическое проектирвоание бд с нормализацией и всей прочей фигней.
9.9K
28 сентября 2011 года
De_Montale
80 / / 23.08.2007
Понятно, что ничего не понятно) Наверно самым адекватным будет создать две базы - набить их рэндомными данными и наблюдать)
Так или иначе, спасибо, ребят... )
385
29 сентября 2011 года
SomewherSomehow
477 / / 25.07.2004
Ну, каков вопрос, таков ответ =) Трудно что-то конкретное рекомендовать не зная контекста. Еще можно сказать, что общие рекомендации такие, чтобы быстро работали выборки, нужно стараться организовать данные так, чтобы у субд была возможность использовать индекс. Если, например, все свойства запихать в строку, то чтобы найти все записи у которых значение определенного свойства в середине строки свойств равно чему-либо - субд придется просматривать каждую строку в таблице, это будет есессно дольше, чем быстрый поиск по индексу.
Цитата: De_Montale
... Наверно самым адекватным будет создать две базы - набить их рэндомными данными и наблюдать)...

Это точно! Что касается производительности, это почти всегда лучший способ проверить то или иное утверждение. Так что удачи.

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог