Организация БД с шаблонами свойств VS скорость при объеме.
Доброго вам времени суток.
Чисто теоретически представьте базу данных с товарами.
Не суть столь важно какими. Важно лишь, что их много, и что разные типы товаров имеют определенные наборы свойств.
Как лучше всего организовать БД так, чтобы при организации шаблонов свойств снизить нагрузку на сервер MySQL при доп. выборках.
У меня была шальная мысль загнать свойства в одну строку и парсить ее уже на стороне клиента средствами JS. Но шестое чувство говорит мне что, что то тут не так.
Подскажите, пожалуйста, хотя бы в общих чертах, как, по вашему, лучше всего организовать реализацию БД c товарами и свойствами, где при необходимости возможна выборка по свойствам товара одной и той же категории
Скажем, "сигареты с кол-вом смолы такой то" или "сметана с процентом жирности таким то".
Интересует именно золотая середина между скоростью работы и низкой нагрузкой на сервер.
Заранее благодарен любому совету.
Чисто теоретически представьте базу данных с товарами.
Не суть столь важно какими. Важно лишь, что их много, и что разные типы товаров имеют определенные наборы свойств.
Как лучше всего организовать БД так, чтобы при организации шаблонов свойств снизить нагрузку на сервер MySQL при доп. выборках.
У меня была шальная мысль загнать свойства в одну строку и парсить ее уже на стороне клиента средствами JS. Но шестое чувство говорит мне что, что то тут не так.
Подскажите, пожалуйста, хотя бы в общих чертах, как, по вашему, лучше всего организовать реализацию БД c товарами и свойствами, где при необходимости возможна выборка по свойствам товара одной и той же категории
Скажем, "сигареты с кол-вом смолы такой то" или "сметана с процентом жирности таким то".
Интересует именно золотая середина между скоростью работы и низкой нагрузкой на сервер.
Заранее благодарен любому совету.
Навеяно 1С: каждый сколько-бы-то-ни-было отличающийся товар должен быть отдельной строкой таблицы и у каждого товара есть поле "Группа" посредством которого можно отнести товары к одной из введеных групп. Как хранить группы - в этой же таблице или в соседней - дело вкуса.
При оценке производительности важно знать, как именно будет идти работа с данными. Все своиства писать в строку подошло бы, если б, например, поиск объектов в бд осуществлялся всегда только по ID. А если нужно искать по свойствам, строка - не лучший вариант.
Можете посмотреть в сторону классического подхода Entity Attrib Value (EAV).
Т.к. мы используем на работе EAV в одной из частей системы, то скажу из личного опыта, такой подход может и позволяет хранить универсальные данные, но за всякую универсальность надо платить производительностью. Так что, самым лучшим решением, по прежнему, является грамотное классическое проектирвоание бд с нормализацией и всей прочей фигней.
Можете посмотреть в сторону классического подхода Entity Attrib Value (EAV).
Т.к. мы используем на работе EAV в одной из частей системы, то скажу из личного опыта, такой подход может и позволяет хранить универсальные данные, но за всякую универсальность надо платить производительностью. Так что, самым лучшим решением, по прежнему, является грамотное классическое проектирвоание бд с нормализацией и всей прочей фигней.
Понятно, что ничего не понятно) Наверно самым адекватным будет создать две базы - набить их рэндомными данными и наблюдать)
Так или иначе, спасибо, ребят... )
Так или иначе, спасибо, ребят... )
Ну, каков вопрос, таков ответ =) Трудно что-то конкретное рекомендовать не зная контекста. Еще можно сказать, что общие рекомендации такие, чтобы быстро работали выборки, нужно стараться организовать данные так, чтобы у субд была возможность использовать индекс. Если, например, все свойства запихать в строку, то чтобы найти все записи у которых значение определенного свойства в середине строки свойств равно чему-либо - субд придется просматривать каждую строку в таблице, это будет есессно дольше, чем быстрый поиск по индексу.
Цитата: De_Montale
... Наверно самым адекватным будет создать две базы - набить их рэндомными данными и наблюдать)...
Это точно! Что касается производительности, это почти всегда лучший способ проверить то или иное утверждение. Так что удачи.