Пишу небольшой интернет магазин на laravel, сейчас думаю как лучше реализовать фильтр товаров. Аттрибуты каждого товара хранятся в json поле базы в виде:{"factory": "Восход", "material": "Пластик"}Как лучше в таком случае реализовать фильтр товаров? Мне в голову пришло только сделать в каталоге формочку, которая отправляет get запрос вида /products?factory=Восход&material=ПластикЭто совсем говно, или сойдет? Ничего страшного в том, что кириллицу передаем в get параметрах, или может есть более элегантное решение?
>>1788527Ебать ты атрибуты запихнул, конечно.Я не в курсе за вашу ларавель, но бля. Из такой штуки тупо неудобно их искать же. Медленно через like выходит же.
>>1788530>Ебать ты атрибуты запихнул, конечно.Аттрибуты довольно разные, и точный список заранее неизвестен, поэтому нужно что-то гибкое и более-менее масштабируемое. От EAV решил отказаться, а nosql не хочется тащить сюда. Поэтому решил аттрибуты хранить в json и просто прописать их в админке при добавлении товара. Like не нужен, в mysql завезли же поддержку json полей, искать можно так: select * from `products` where json_unquote(json_extract(`attributes`, '$."factory"')) = 'Восход'
>>1788541>Аттрибуты довольно разные, и точный список заранее неизвестенМожно создать таблицу в которой у тебя будут поля attribute_name, и attribute_value, и джойнить её.>Like не нужен, в mysql завезли же поддержку json полейИ ты таки уверен что оно прям быстро работать?
>>1788588>Можно создать таблицу в которой у тебя будут поля attribute_name, и attribute_value, и джойнить её.Получается паттерн EAV (Entity-Attribute-Value), про который в гугле плохо пишут. >И ты таки уверен что оно прям быстро работать?На хабре статья была, где сравниваниют eav и jsonb, правда там posgresql, а не mysql, можешь глянуть https://habr.com/ru/post/475178/ . Если кратко, то "потери производительности очень незначительные".
>>1788602>{"factory": "Восход", "material": "Пластик"}Ебать я вскекнул. Очередной лопух начитался про jsonb. А хули ты будешь делать если нужно "factory" переименовать? Если у тебя там "fucktory" написано, ты весь миллион товаров апдейтить будешь? Особенно охуенно будет с десятками свойств типа "resolution", которые у каждого тапка свои.>Получается паттерн EAV (Entity-Attribute-Value), про который в гугле плохо пишутТы бы хоть прочитал что такое EAV. EAV это когда вся БАЗА ДАННЫХ создается в виде одной единственной таблицы. Вот каноничный пример EAV https://dbfiddle.uk/?rdbms=postgres_12&fiddle=1972d91317eeb172ffd647d363b72d1c сразу видно почему он считается антипаттерном. Нужно каждую сущность собирать буквально по частям. Схема данных спрятана внутри самой базы, именно поэтому EAV считается медленней, чем обычная реляционная схема. Нужен минимум один дополнительный шаг чтобы получить схему.Когда ты строишь каталог, то у тебя есть четкая схема:Product "DELL UltraSharp U2718Q" <- Type "Monitor" <- Property "Resolution" <- "3840x2160 (16:9)"Эта схема состоит из нескольких таблиц, полностью реляционна и нормализована. И никакого блядь отношения к EAV она не имеет.
>>1788899>>1788899>Когда ты строишь каталог, то у тебя есть четкая схема:>Product "DELL UltraSharp U2718Q" <- Type "Monitor" <- Property "Resolution" <- "3840x2160 (16:9)">Эта схема состоит из нескольких таблиц, полностью реляционна и нормализована. И никакого блядь отношения к EAV она не имеет.Вот тут нихуя не понял. Из каких таблиц состоит эта схема? Или ты предлагаешь на каждое свойство свою таблицу создавать?
>>1788951Важно не из каких таблиц она состоит, это дело десятое. Какие нужны, такие и сделаешь. Важен сам факт того что если у тебя есть схема каталога и она состоит из таблиц, то это не EAV.Если ты не знаешь как схему каталога составить, то посмотри популярные PIM системы вроде akeneo. Или просто погули "product catalog database scema". Вот тут, например, хорошо расписано https://www.codingblocks.net/programming/database-schema-for-multiple-types-of-products/
>>1789381И всё-таки, настолько ли плох Json в моем случае? Планируется интернет магазин с тремя категориями товаров, всего товаров не больше 50 штук. Проблема в том, что атрибуты товаров заранее неизвестны. Или всё-таки реляционная и нормализованная бд лучше будет?
>>1789409Чем меньше каталог, тем меньше причин использовать nosql. Сама структура у тебя сто проц будет реляционная. JSON можно использовать для значений, типа "значение, тип, единицы измерения" https://dbfiddle.uk/?rdbms=postgres_12&fiddle=34f95d845ab52b07b68c8aa37058b522 , и то лучше сделать отдельную таблицу для единиц измерения.
>>1789571Ну и самое главное, если есть возможность выбирать. То используй Postgres, а не mysql. Та же работа с json в mysql 8 это сраная шутка, по сравнению с postgres.
>>1789610>То используй Postgres, а не mysqlСогласен.>Та же работа с json в mysql 8 это сраная шутка, по сравнению с postgres. На правах срача. Если потребовалось работать с json в БД, то ты что-то сделал через жопу. То самый случай когда НИНУЖНО.
>>1789638Каждого любителя четвертой нормальной формы жизнь рано или поздно ебашит головой об угол стола. И пока он в полубессознательном состоянии сзади его приобнимает dba, приспускает штанишки и шепчет на ухо ДЕНОРМАЛИЗАЦИЯ.
>>1789689>Денормализовать json-амиВернейший способ сделать кривое, неподдерживаемое, нерасширяемое говно. И вишенка на торте - тормозящее.Работал я как-то у тимлида, который обожал кукареки про быстродействие sql и правильно составленные запросы. Когда выяснилось, что запросы даже с 4 джойнами работают всё ещё быстрее его сраного поиска по jsonнам, жопу ему разнесло как в хиросиме.Денормализация делается отдельными индексными таблицами, и при ОЧЕНЬ ОСТРОЙ необходимости. Нахуй джсоны.
>>1789738>запросы даже с 4 джойнами работают всё ещё быстрее его сраного поиска по jsonнамЧетыре LEFT джойна подряд могут занять четрые гб памяти изи. А подзапрос к четвертому джойну может насрать тебе в чай, потому что ты нагло пиздишь про скорость поиска по json'ам. Давай пруфы скорости, маня.>Денормализация делается отдельными индексными таблицами, и при ОЧЕНЬ ОСТРОЙ необходимости. Нахуй джсоны. По jsonb полю можно строить индекс. Gin или обычный btree, на любой вкус.
>>1789853>Давай пруфы скорости, маня.Держи.4 объекта, Data1, Data2, Data3 и Data4.У каждого есть code, и привязки Data1->Data2, Data2->Data3 и тд.Использовалась доктрина, но жестко прописывался селект во всех случаях, так что она возвращала массивы.Делал 10000 выборок на каждый тип запроса.Самое быстрое как и ожидалось поиск по прямому значению.4 джойна сделали запрос тяжелее (естественно, лол), но не настолько как ожидалось.А вот поиск в json оказался самым прожорливым. Причем прошу заметить json был одноуровневый.Не надо меня деанонить позязя.
>>1790306Ты кукухой поехал? Где запрос? Где схема базы? Какой нахуй пхп?Вот тебе песочница https://dbfiddle.uk/?rdbms=postgres_12 напиши запросы по человечески.
>>1790372Делай сам, лол. Но ты не сделаешь. Криворукий петуч с джсоном в базе (ЕБАТЬ МОЙ ХУЙ ГОВНО КРИВОРУКОЕ КРИВОЖОПОЕ ОТКРЫВАЕТ РОТ БЛЯДЬ) выебывается в треде.Делать мне больше нехуй как прямые запросы писать.
>>1790384Это троллинг тупостью? Возьми запрос, который сгенерила доктрина и сделай EXPLAIN. Пиздец, нахуй ты вообще выполз, дегенерат?
>>1790389Что я получу, когда это сделаю? Твою порванную в клочья сраку окончательно? Зачем мне это?Если бы ты общался культурно, я бы подумал над этим. Если бы тебе действительно было интересно, ты бы проверил сам. А так я только в лучшем случае добьюсь твоего слива.Один в один история как с петухом, под руководством которого я работал 3 месяца. Когда он увидел, что я выкинул к хуям весь его код, упростил запросы вдвое и добился прироста производительности, он изошелся на говно.В нынешней конторе мы просто не суем массивы в базу, всё. Ладно, суем, но только в тех случаях когда там будет хер знает что и по этому хер знает чему не будет никакой сортировки или поиска..
>>1790398Че ты так порвался? Написать все это на пхп было в сто раз сложнее, чем сделать explain. У меня вообще ощущение, что это был не твой пост, а ты просто мимо проходящий хуеплет.
>>1790400>Че ты так порвался?Аргумент "у вас баттхерт" был моветоном уже в 2012. Простите, сэр, но в наше время это безнадежно устарело.>Написать все это на пхп было в сто раз сложнее, чем сделать explain.И фикстуры с псевдоданными заполнить, ага. И ключи для связей проставить. И индексы ручками генерить вместо кнопки в админке. Я слишком долго не имел дела с прямыми запросами, что бы ебаться с этим. Спулить 3 бандла и набросать схему мне гораздо проще.Если бы тебя действительно это интересовало, ты бы сам проверил.Я занялся этим только из спортивного интереса. Я знаю, как именно работает БД (без совсем уж подробностей, но в общих чертах), поэтому утверждение о том, что поиск в массиве может быть быстрее джойнов заставило меня охуеть. Я просто убедился в том, что я ещё не ебанулся и это говно таки медленнее, как и должно быть. Скриншот скинул для анонов.
