Comments 8
Не хочу вас расстраивать. Но вы изобрели велосипед.
Такой подход к хранению "произвольных" свойств используется в той же 1С уже лет 15.
Не хочу вас расстраивать. Но вы изобрели велосипед.
Такой подход к хранению "произвольных" свойств используется в той же 1С уже лет 15.
Вы меня не расстроили, я не утверждал, что открыл миру что то новое, но 1с генерирует структуру в тёмную, я в статье показал как это можно использовать в web проектах.
но 1с генерирует структуру в тёмную
Нет, я не про структуру которую делает платформа 1С. Я про типовые решения от 1С. Там структура полностью открыта и понятна.
Основная проблема такого решения в том, что когда нужно прочитать все свойства одного объекта, физических запросов к таблице скорее всего будет больше чем 1. А еще накладываются ограничения на тип хранимых значений. Для разных типов нужно делать отдельные колонки Value. Дальше помнить для каждого свойства из какой колонки брать значение. В результате писать запросы к такой таблице вручную становиться утомительно. Нужно "городить" отдельные функции для генерации текста запроса.
Появление новой категории это ведь не такое уж и частое событие. Кто мешает "наладить" процесс создания необходимых таблиц?
Вы статью то прочли? Предложенное решение как раз минует весь огород c разными типами в разных таблицах, и весь поиск идёт по двум целочисленным полям одной таблицы, что обеспечивает приемлемую скорость и простоту запросов, поскольку для нужд каталога большего и не требуется.
Значения свойств могут быть не только числовые. Они могут быть еще строковые, ссылки на другие таблицы, могут быть доп. картинки где уже может быть удобно хранить blob (а может и не удобно, все зависит от размера).
Поиск может и идёт по 2 целочисленным полям в одной таблице, но сколько раз? Вы ведь сами обратили внимание что при большим количество условий построение плана запроса становится уже ощутимым.
А писать каждый раз 30 раз join чтобы вытянуть все поля по нескольким товарам вы называете не сложным?
Таким подходом можно вообще всю БД превратить в набор из 3-х таблиц.
Прежде чем городить такой огород, вы задавались вопросом как часто происходит добавление новых категорий товаров? Где будет больше сэкономлено ресурсов? Не кажется ли вам что заставлять СУБД при каждом запросе тратить время на построение плана запроса (которые кстати не сильно будут отличаться друг от друга) в итоге потратит больше энергии чем добавление отдельной таблицы для категории?
Уважаемый @abutorin,вы наверное не совсем поняли суть предложенной схемы, загляните в любой каталог, что вы увидите в отборах? в категории телефоны, это будут: Бренд, Диагональ, мощность батареи, цветовое оформление, количество ядер, поддержка быстрой зарядки, наверное что то ещё.
Так вот Бренд - в нашем случае, это ссылочное значение, в выпадающем списке вываляться Эппл, Хуавей, и.т.д., Цвет тоже: Розовый, голубой, чёрный. Диагональ, ёмкость батареи и числовые значения и могут вводиться в виде диапазона, поддержка быстрой зарядки - булево.
То о чём написали вы это классический EAV, "универсальное решение для всего", я писал статью о каталоге и только о нём. Все приведённые запросы имеют практически конечную форму, каждое условие добавляет один предсказуемый join.
Поиск может и идёт по 2 целочисленным полям в одной таблице, но сколько раз? Вы ведь сами обратили внимание что при большим количество условий построение плана запроса становится уже ощутимым.
Особенность работы планировщика в том что, он ищет оптимальный порядок соединения таблиц, каждый join кратно увеличивает количество вариантов для которых нужно посмотреть статистику, именно это сказывается на времени планирования, мы ему можем подсказать, что если соединений больше заданного порога, то не нужно пытаться найти идеальный порядок соединения и выполнить запрос буквально, т. е. поверить запросу на слово.
Это же так называемый "join bomb" где реляционный подход пасует. Если изначально будет предполагаться, что кол-во условий будет большим, то лучше использовать графовую БД, причём она как раз безсхемная, ну или многомодельную БД, которая поддерживает как графовую так и реляционную модели (AgensGraph)
Очередной универсальный интернет каталог средствами реляционной СУБД