Пишу небольшой интернет магазин на 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, на любой вкус.
>>1789853JSON в реляционную базу - минус матьЯ вас пидарасов с жсоном в базе всех сгною нахуй, вы черви-пидоры с говном в голове, пишете свою поебень в монгоебень или сразу в dev/null, быстро пиздец.
>>1789949Ты своей тупорылой башкой понимаешь зачем вообще нормализуют данные? Текстовые поля тоже нормализуешь, дебич?
>>1789969Я как раз отлично понимаю. Если тебе надо сохранять хуиту в базу, которую целиком нужно писать/читать по айди - тебе нахуй не нужна для этого реляционная база, в противном случае, если у этих данных подразумевается структура, то нужна схема и нормализация, то есть не нужно JSON-говно.JSON в реляционной базе, это как Any в статически типизированном языке.
>>1790092>Ты нормализуешь текстовые поля? Нормализовать можно таблицу, а не поля.Тебе из моего ответа непонятно что нормализовать нужно то у чего есть интересующая структура? Если этот текст везде используется целиком (его структура не важна), - он хранится в одном поле, если важны составляющие - они хранятся отдельно.
>>1790130JSON это блядь строка. Тебе, долбоебу, просто дали возможность эту строку анализировать. LIKE в запросах использовал, а ~ ? Так вот это то же самое. И никто не хочет ради нескольких приятных фишек поднимать другую базу, мейнтейнить её, ебаться с синхронизацией. Это блядь всем очевидно, топовые разработчики Postgres'а годами работают над удобной и быстрой работой с JSON https://www.youtube.com/watch?v=WtkhZ5P1uA8
>>1790153>JSON это блядь строка.А, ясно, ты - дебил. Массив, стало быть, - тоже строка. JSON в первую очередь подразумевает структуру, с полями и вложеностями (и неявно, так как их и нет - с типами). Дебилы которые хуярят JSON в реляционную базу делятся на 2 вида:1. Слегка дебилы. Они сохраняют JSON, структура которого не важна и будет важна. Эти люди скорее всего просто не осведомлены, что писать и читать всякое говно по ключу в реляционку не обязательно, что для этого есть масса других более подходящих инструментов.2. Критические дебилы. У них просто нет мозга для надлежащего дата-дизайна, поэтому любую мало-мальски сложную структуру они энкодят в JSON и пихают в базу. Нахуя им вообще нужна реляционка, когда есть монгоперделка и другие доступные их имбецильным мозга хэш-таблицы - это остаётся загадкой природы. Что же происходит когда все эти груды JSON-говна надо наконец захендлить? Ну они пишут горы невменяемого быдлокода с миллионом ифов, где через строчку гадают есть ли такое-то поле, нужного ли оно типа, не лежит ли там нулл, действительно ли существует такой айдишник - подобное вот петушение, которое без крови из глаз читать невозможно. А всё из-за недостатка когнитивных способностей.Не знаю к какому виду дебилов ты относишься, сначала думал что к первому, но после твоего сравнения JSON с текстом - подозреваю что ко второму. В любом случае продолжать с тобой разговор бесполезно. Просто выйди в окно - сделай миру хорошее.
>>1790172>А, ясно, ты - дебил. Массив, стало быть, - тоже строка. Тухлодырый ты пиздобол. "JSON is a text format" цитата блядь из RFC. Но тебе, хуесосу, конечно виднее что массив, а что текст.>Эти люди скорее всего просто не осведомлены, что писать и читать всякое говно по ключу в реляционку не обязательно, что для этого есть масса других более подходящих инструментов.Понятно, ты джун, который нихуя не понимает что такое гетерогенность и её последствия.>В любом случае продолжать с тобой разговор бесполезно. Просто выйди в окно - сделай миру хорошее.Тебе ещё и 18 нет. Все ясно, дело раскрыто. Малолетний долбоеб, который с реальной базой никогда не работал, прочитал в википедии что такое четвертая нормальная форма.
