«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2020/08/26 08:49:50  №1788527 1
Пишу небольшой интернет магазин на laravel, сейчас думаю как лучше реализовать фильтр товаров. Аттрибуты каждого товара хранятся в json поле базы в виде:

{"factory": "Восход", "material": "Пластик"}

Как лучше в таком случае реализовать фильтр товаров? Мне в голову пришло только сделать в каталоге формочку, которая отправляет get запрос вида /products?factory=Восход&material=Пластик

Это совсем говно, или сойдет? Ничего страшного в том, что кириллицу передаем в get параметрах, или может есть более элегантное решение?
Ответы: >>1788530
Аноним 2020/08/26 08:54:28  №1788530 2
>>1788527
Ебать ты атрибуты запихнул, конечно.
Я не в курсе за вашу ларавель, но бля. Из такой штуки тупо неудобно их искать же. Медленно через like выходит же.

Ответы: >>1788541
Аноним 2020/08/26 09:07:09  №1788541 3
>>1788530
>Ебать ты атрибуты запихнул, конечно.
Аттрибуты довольно разные, и точный список заранее неизвестен, поэтому нужно что-то гибкое и более-менее масштабируемое. От EAV решил отказаться, а nosql не хочется тащить сюда. Поэтому решил аттрибуты хранить в json и просто прописать их в админке при добавлении товара.

Like не нужен, в mysql завезли же поддержку json полей, искать можно так:

select * from `products` where json_unquote(json_extract(`attributes`, '$."factory"')) = 'Восход'
Ответы: >>1788552 >>1788588
Аноним 2020/08/26 10:11:22  №1788588 4
>>1788541
>Аттрибуты довольно разные, и точный список заранее неизвестен
Можно создать таблицу в которой у тебя будут поля attribute_name, и attribute_value, и джойнить её.
>Like не нужен, в mysql завезли же поддержку json полей
И ты таки уверен что оно прям быстро работать?
Ответы: >>1788602
Аноним 2020/08/26 10:22:05  №1788602 5
>>1788588
>Можно создать таблицу в которой у тебя будут поля attribute_name, и attribute_value, и джойнить её.
Получается паттерн EAV (Entity-Attribute-Value), про который в гугле плохо пишут.

>И ты таки уверен что оно прям быстро работать?
На хабре статья была, где сравниваниют eav и jsonb, правда там posgresql, а не mysql, можешь глянуть https://habr.com/ru/post/475178/ . Если кратко, то "потери производительности очень незначительные".

Ответы: >>1788608 >>1788899
Аноним 2020/08/26 14:16:53  №1788899 6
>>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 она не имеет.
Ответы: >>1788951 >>1788951
Аноним 2020/08/26 15:21:56  №1788951 7
>>1788899
>>1788899
>Когда ты строишь каталог, то у тебя есть четкая схема:
>Product "DELL UltraSharp U2718Q" <- Type "Monitor" <- Property "Resolution" <- "3840x2160 (16:9)"
>Эта схема состоит из нескольких таблиц, полностью реляционна и нормализована. И никакого блядь отношения к EAV она не имеет.

Вот тут нихуя не понял. Из каких таблиц состоит эта схема? Или ты предлагаешь на каждое свойство свою таблицу создавать?
Ответы: >>1789350
Аноним 2020/08/27 06:32:27  №1789350 8
Product-Diagram.png (43, 724x497)
497x724
>>1788951
Важно не из каких таблиц она состоит, это дело десятое. Какие нужны, такие и сделаешь. Важен сам факт того что если у тебя есть схема каталога и она состоит из таблиц, то это не EAV.

Если ты не знаешь как схему каталога составить, то посмотри популярные PIM системы вроде akeneo. Или просто погули "product catalog database scema". Вот тут, например, хорошо расписано https://www.codingblocks.net/programming/database-schema-for-multiple-types-of-products/
Ответы: >>1789381
Аноним 2020/08/27 07:08:55  №1789381 9
>>1789350
Спасибо за инфу, буду разбираться!
Ответы: >>1789409
Аноним 2020/08/27 07:26:46  №1789409 10
>>1789381
И всё-таки, настолько ли плох Json в моем случае? Планируется интернет магазин с тремя категориями товаров, всего товаров не больше 50 штук. Проблема в том, что атрибуты товаров заранее неизвестны. Или всё-таки реляционная и нормализованная бд лучше будет?
Ответы: >>1789461
Аноним 2020/08/27 08:11:59  №1789461 11
>>1789409
Чем меньше каталог, тем меньше причин использовать nosql. Сама структура у тебя сто проц будет реляционная. JSON можно использовать для значений, типа "значение, тип, единицы измерения" https://dbfiddle.uk/?rdbms=postgres_12&fiddle=34f95d845ab52b07b68c8aa37058b522 , и то лучше сделать отдельную таблицу для единиц измерения.
Ответы: >>1789571
Аноним 2020/08/27 09:28:59  №1789571 12
>>1789461
Все понял, спасибо за советы, пойду переделывать все.
Ответы: >>1789610
Аноним 2020/08/27 09:57:03  №1789610 13
>>1789571
Ну и самое главное, если есть возможность выбирать. То используй Postgres, а не mysql. Та же работа с json в mysql 8 это сраная шутка, по сравнению с postgres.
Ответы: >>1789638
Аноним 2020/08/27 10:11:58  №1789638 14
>>1789610
>То используй Postgres, а не mysql
Согласен.
>Та же работа с json в mysql 8 это сраная шутка, по сравнению с postgres.
На правах срача. Если потребовалось работать с json в БД, то ты что-то сделал через жопу. То самый случай когда НИНУЖНО.
Ответы: >>1789689
Аноним 2020/08/27 10:41:59  №1789689 15
>>1789638
Каждого любителя четвертой нормальной формы жизнь рано или поздно ебашит головой об угол стола. И пока он в полубессознательном состоянии сзади его приобнимает dba, приспускает штанишки и шепчет на ухо ДЕНОРМАЛИЗАЦИЯ.
Ответы: >>1789738
Аноним 2020/08/27 11:21:20  №1789738 16
>>1789689
>Денормализовать json-ами
Вернейший способ сделать кривое, неподдерживаемое, нерасширяемое говно. И вишенка на торте - тормозящее.

Работал я как-то у тимлида, который обожал кукареки про быстродействие sql и правильно составленные запросы. Когда выяснилось, что запросы даже с 4 джойнами работают всё ещё быстрее его сраного поиска по jsonнам, жопу ему разнесло как в хиросиме.
Денормализация делается отдельными индексными таблицами, и при ОЧЕНЬ ОСТРОЙ необходимости. Нахуй джсоны.
Ответы: >>1789853
Аноним 2020/08/27 12:37:34  №1789853 17
>>1789738
>запросы даже с 4 джойнами работают всё ещё быстрее его сраного поиска по jsonнам
Четыре LEFT джойна подряд могут занять четрые гб памяти изи. А подзапрос к четвертому джойну может насрать тебе в чай, потому что ты нагло пиздишь про скорость поиска по json'ам. Давай пруфы скорости, маня.

>Денормализация делается отдельными индексными таблицами, и при ОЧЕНЬ ОСТРОЙ необходимости. Нахуй джсоны.
По jsonb полю можно строить индекс. Gin или обычный btree, на любой вкус.
Ответы: >>1789949 >>1790306
Аноним 2020/08/27 18:51:13  №1790306 18
200827214038.png (8, 1896x332)
332x1896
Screenshot6.png (42, 932x891)
891x932
>>1789853
>Давай пруфы скорости, маня.
Держи.

4 объекта, Data1, Data2, Data3 и Data4.

У каждого есть code, и привязки Data1->Data2, Data2->Data3 и тд.
Использовалась доктрина, но жестко прописывался селект во всех случаях, так что она возвращала массивы.

Делал 10000 выборок на каждый тип запроса.
Самое быстрое как и ожидалось поиск по прямому значению.
4 джойна сделали запрос тяжелее (естественно, лол), но не настолько как ожидалось.

А вот поиск в json оказался самым прожорливым. Причем прошу заметить json был одноуровневый.

Не надо меня деанонить позязя.
Ответы: >>1790372 >>1790428
Аноним 2020/08/27 19:57:19  №1790372 19
>>1790306
Ты кукухой поехал? Где запрос? Где схема базы? Какой нахуй пхп?
Вот тебе песочница https://dbfiddle.uk/?rdbms=postgres_12 напиши запросы по человечески.
Ответы: >>1790384
Аноним 2020/08/27 20:17:10  №1790384 20
>>1790372

Делай сам, лол. Но ты не сделаешь. Криворукий петуч с джсоном в базе (ЕБАТЬ МОЙ ХУЙ ГОВНО КРИВОРУКОЕ КРИВОЖОПОЕ ОТКРЫВАЕТ РОТ БЛЯДЬ) выебывается в треде.
Делать мне больше нехуй как прямые запросы писать.
Ответы: >>1790389
Аноним 2020/08/27 20:19:52  №1790389 21
>>1790384
Это троллинг тупостью? Возьми запрос, который сгенерила доктрина и сделай EXPLAIN. Пиздец, нахуй ты вообще выполз, дегенерат?
Ответы: >>1790398
Аноним 2020/08/27 20:28:03  №1790398 22
>>1790389
Что я получу, когда это сделаю? Твою порванную в клочья сраку окончательно? Зачем мне это?

Если бы ты общался культурно, я бы подумал над этим. Если бы тебе действительно было интересно, ты бы проверил сам. А так я только в лучшем случае добьюсь твоего слива.

Один в один история как с петухом, под руководством которого я работал 3 месяца. Когда он увидел, что я выкинул к хуям весь его код, упростил запросы вдвое и добился прироста производительности, он изошелся на говно.

В нынешней конторе мы просто не суем массивы в базу, всё. Ладно, суем, но только в тех случаях когда там будет хер знает что и по этому хер знает чему не будет никакой сортировки или поиска..
Ответы: >>1790400
Аноним 2020/08/27 20:33:05  №1790400 23
>>1790398
Че ты так порвался? Написать все это на пхп было в сто раз сложнее, чем сделать explain. У меня вообще ощущение, что это был не твой пост, а ты просто мимо проходящий хуеплет.
Ответы: >>1790410
Аноним 2020/08/27 20:46:01  №1790410 24
>>1790400
>Че ты так порвался?
Аргумент "у вас баттхерт" был моветоном уже в 2012. Простите, сэр, но в наше время это безнадежно устарело.
>Написать все это на пхп было в сто раз сложнее, чем сделать explain.
И фикстуры с псевдоданными заполнить, ага. И ключи для связей проставить. И индексы ручками генерить вместо кнопки в админке. Я слишком долго не имел дела с прямыми запросами, что бы ебаться с этим. Спулить 3 бандла и набросать схему мне гораздо проще.

Если бы тебя действительно это интересовало, ты бы сам проверил.

Я занялся этим только из спортивного интереса. Я знаю, как именно работает БД (без совсем уж подробностей, но в общих чертах), поэтому утверждение о том, что поиск в массиве может быть быстрее джойнов заставило меня охуеть. Я просто убедился в том, что я ещё не ебанулся и это говно таки медленнее, как и должно быть. Скриншот скинул для анонов.