Задача следующая - делаю интернет магазин, в котором у товаров есть несколько атрибутов. Соответственно комбинация этих атрибутов будет иметь разную цену.. С этим у меня возникли большие сложности.
1) Как построить архитектуру в БД, чтобы свойства были динамические и их можно было бы добавлять к группам товара.
2) Окей, я изучил архитектуру eav и приблизительно понял, как буду их хранить, но как быть с выборкой немного непонятно.. То есть по идее у меня будут товары, к ним будут привязаны предложения, имеющие цену, к которым будут привязаны значения атрибутов товара.. То есть получается чтобы получить цену товара с конкретными характеристиками мне придётся сначала выбрать все предложения, связанные с айдишниками таких то значений?
3) Когда пользователь выбирает свойства, он должен видеть цену предложения, соответствующего выбранным атрибутам. Но если постоянно запрашивать её у сервера апдейт цены будет достаточно долгим.. Как лучше решить этот вопрос?
EAV - гуано по производительности
Его можно использовать для первичного хранения данных, перед тем как ты переваришь и выкинешь уже готовые для работы данные в Solr или Sphinx, например.
Но непосредственно для выборки данных EAV использовать нежелательно по соображениям производительности.
Если вам всенепременно хочется это сделать с реляционной СУБД, то вам поможет денормализация (данные будут дублироваться, но это не страшно, зато работать будет шустро).
А если вам хочется сделать это правильно и чтобы работало максимально быстрым образом, то я бы предложил рассмотреть более подходящие для данной задачи системы: Tarantool, Sphinx,
Solr.
Если вы используете БД PostgreSQL, то можете хранить аттрибуты, к примеру, в JSON-поле таблицы. Они индексируются и не придется делать кучу JOIN, как с EAV, чтобы вытащить данные.
Но тут есть очевидные минусы, это удаление атрибута, к примеру. Может быть достаточно тяжелым. Но все зависит от способа реализации.
В целом, можно взять EAV и достраивать JOIN-ами к запросу атрибуты, а можно и JSON.
Забыл сказать, JSON поддерживает индексы и запросы по полям.
Если вы используете БД PostgreSQL, то можете хранить аттрибуты, к примеру, в JSON-поле таблицы
во первых мускуль тоже умеет, во вторых это нехило нарушает нормальность таблиц, в третьих - кто-то видел тест по производительности выборки из жсон полей в постгри/мускуль? Хотелось бы глянуть как они работают, есть подозрение что не очень быстро. Буду благодарен за ссылочки.
С 5.7 вроде, и индексы вычисляемые там тоже есть, да.
Если мы говорим про быстроту, нормализация нарушается в большинстве случаев. Либо у вас таблица нормализована, и, что очень часто, медленна, либо - у вас есть денормализованные данные и работает достаточно быстро. Ссылок не дам, можно погуглить.
Можно так же посмотреть видео Олега Бартунова, в том числе https://www.youtube.com/watch?v=SNzOZKvFZ68
Хочу отметить так же, у себя я применял EAV схему расширения. Это было в 2013-2014 годах. А вот сейчас я бы попробовал именно JSON-поле.
Если я правильно понял, то вы в неправильном направлении идете. Товары с разными характеристиками это разные товары, поэтому цену нужно выставлять товару, а не его характеристикам.
Как я выставлю цену товару, если у него будет много цен? Цены зависят от характеристик.. Тут по любому отдельная таблица нужна, в которой будет цена конкретной комбинации товара, кол-во и тд
Пример: есть лампочка фирмы филипс. И есть атрибут - мощность. 40, 60, 75, 99 ватт. Так вот, это 4 разных товара. Название одно, но группа атрибутов разная. То что вы можете их показать на странице товара как один товар должно задаваться полем товара с каким-то объединяющим ключом. Все.
Я хочу сделать 1 товар, а к нему уже привязывать его разновидности. Вопрос даже не в этом, а в том, как хранить динамически эти атрибуты и делать выборку! А так то получается так как вы сказали только объединяющим ключом у меня как раз будет ид товара
Простой
Сложный
