«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 10:27:46  №1788608 6
>>1788602
>Получается паттерн EAV (Entity-Attribute-Value), про который в гугле плохо пишут.
Ну, плюс-минус все интернет-магазинные cms которые умеют в мультиатрибутность такую реализуют это как раз так.
>Если кратко, то "потери производительности очень незначительные".
Ну, если так, и если тебе так удобнее-вопросов нет. В конце коноцов то что я бы так не делал не значит что так не стоит делать же.)

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

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

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

>Денормализация делается отдельными индексными таблицами, и при ОЧЕНЬ ОСТРОЙ необходимости. Нахуй джсоны.
По jsonb полю можно строить индекс. Gin или обычный btree, на любой вкус.
Ответы: >>1789949 >>1790306
Аноним 2020/08/27 13:11:52  №1789949 19
>>1789853
JSON в реляционную базу - минус мать

Я вас пидарасов с жсоном в базе всех сгною нахуй, вы черви-пидоры с говном в голове, пишете свою поебень в монгоебень или сразу в dev/null, быстро пиздец.
Ответы: >>1789969
Аноним 2020/08/27 13:20:40  №1789969 20
>>1789949
Ты своей тупорылой башкой понимаешь зачем вообще нормализуют данные? Текстовые поля тоже нормализуешь, дебич?
Ответы: >>1790055
Аноним 2020/08/27 14:03:25  №1790055 21
>>1789969
Я как раз отлично понимаю.
Если тебе надо сохранять хуиту в базу, которую целиком нужно писать/читать по айди - тебе нахуй не нужна для этого реляционная база, в противном случае, если у этих данных подразумевается структура, то нужна схема и нормализация, то есть не нужно JSON-говно.
JSON в реляционной базе, это как Any в статически типизированном языке.
Ответы: >>1790092
Аноним 2020/08/27 14:30:11  №1790092 22
>>1790055
Еще раз спрашиваю. Ты нормализуешь текстовые поля?
Ответы: >>1790130
Аноним 2020/08/27 15:13:53  №1790130 23
>>1790092
>Ты нормализуешь текстовые поля?
Нормализовать можно таблицу, а не поля.


Тебе из моего ответа непонятно что нормализовать нужно то у чего есть интересующая структура? Если этот текст везде используется целиком (его структура не важна), - он хранится в одном поле, если важны составляющие - они хранятся отдельно.
Ответы: >>1790153
Аноним 2020/08/27 15:27:50  №1790153 24
>>1790130
JSON это блядь строка. Тебе, долбоебу, просто дали возможность эту строку анализировать. LIKE в запросах использовал, а ~ ? Так вот это то же самое.
И никто не хочет ради нескольких приятных фишек поднимать другую базу, мейнтейнить её, ебаться с синхронизацией. Это блядь всем очевидно, топовые разработчики Postgres'а годами работают над удобной и быстрой работой с JSON https://www.youtube.com/watch?v=WtkhZ5P1uA8
Ответы: >>1790172
Аноним 2020/08/27 15:52:51  №1790172 25
>>1790153
>JSON это блядь строка.
А, ясно, ты - дебил. Массив, стало быть, - тоже строка.

JSON в первую очередь подразумевает структуру, с полями и вложеностями (и неявно, так как их и нет - с типами).

Дебилы которые хуярят JSON в реляционную базу делятся на 2 вида:
1. Слегка дебилы. Они сохраняют JSON, структура которого не важна и будет важна. Эти люди скорее всего просто не осведомлены, что писать и читать всякое говно по ключу в реляционку не обязательно, что для этого есть масса других более подходящих инструментов.

2. Критические дебилы. У них просто нет мозга для надлежащего дата-дизайна, поэтому любую мало-мальски сложную структуру они энкодят в JSON и пихают в базу. Нахуя им вообще нужна реляционка, когда есть монгоперделка и другие доступные их имбецильным мозга хэш-таблицы - это остаётся загадкой природы.
Что же происходит когда все эти груды JSON-говна надо наконец захендлить? Ну они пишут горы невменяемого быдлокода с миллионом ифов, где через строчку гадают есть ли такое-то поле, нужного ли оно типа, не лежит ли там нулл, действительно ли существует такой айдишник - подобное вот петушение, которое без крови из глаз читать невозможно. А всё из-за недостатка когнитивных способностей.

Не знаю к какому виду дебилов ты относишься, сначала думал что к первому, но после твоего сравнения JSON с текстом - подозреваю что ко второму.

В любом случае продолжать с тобой разговор бесполезно. Просто выйди в окно - сделай миру хорошее.
Ответы: >>1790173 >>1790174 >>1790180
Аноним 2020/08/27 15:53:49  №1790173 26
>>1790172
>не важна и не будет важна


selffix
Аноним 2020/08/27 15:56:22  №1790174 27
>>1790172
Я видимо к первым отношусь. Пихаю джейсон в виде разных payload полей, которые никак не влияют на работу базы, а используются только бизнес логикой. По мне удобнее, чем нормализовать всю базу под кучу возможных вариантов таких документных записей.
мимо
Аноним 2020/08/27 16:12:28  №1790180 28
>>1790172
>А, ясно, ты - дебил. Массив, стало быть, - тоже строка.
Тухлодырый ты пиздобол. "JSON is a text format" цитата блядь из RFC. Но тебе, хуесосу, конечно виднее что массив, а что текст.

>Эти люди скорее всего просто не осведомлены, что писать и читать всякое говно по ключу в реляционку не обязательно, что для этого есть масса других более подходящих инструментов.
Понятно, ты джун, который нихуя не понимает что такое гетерогенность и её последствия.

>В любом случае продолжать с тобой разговор бесполезно. Просто выйди в окно - сделай миру хорошее.
Тебе ещё и 18 нет.
Все ясно, дело раскрыто. Малолетний долбоеб, который с реальной базой никогда не работал, прочитал в википедии что такое четвертая нормальная форма.
Аноним 2020/08/27 18:51:13  №1790306 29
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 30
>>1790306
Ты кукухой поехал? Где запрос? Где схема базы? Какой нахуй пхп?
Вот тебе песочница https://dbfiddle.uk/?rdbms=postgres_12 напиши запросы по человечески.
Ответы: >>1790384
Аноним 2020/08/27 20:17:10  №1790384 31
>>1790372

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

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

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

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

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

Я занялся этим только из спортивного интереса. Я знаю, как именно работает БД (без совсем уж подробностей, но в общих чертах), поэтому утверждение о том, что поиск в массиве может быть быстрее джойнов заставило меня охуеть. Я просто убедился в том, что я ещё не ебанулся и это говно таки медленнее, как и должно быть. Скриншот скинул для анонов.
Аноним 2020/08/27 21:11:51  №1790428 36
>>1790306

Тут есть небольшой подвох. MySQL кеширует ответы на запросы, потому для чистоты эксперимента стоит добавлять SQL_NO_CACHE ( https://dev.mysql.com/doc/refman/5.6/en/query-cache-in-select.html ) в запрос. У тебя их нет, и если ты запустишь свой код второй раз, возможно, что ответы возьмутся из кеша и не будут отражать действительность.

Вторая проблема в том, что первому запросу может быть тяжелее выполняться, так как на момент его выполнения все данные лежат на диске, а последнему запросу не надо их загружать с диска, они уже в памяти. Чтобы избежать этого, тест можно прогнать первый раз для "прогрева" и второй раз уже для измерения.

Стоит учитывать эти 2 момента, чтобы не получить искаженные результаты.

Ну и то, что джойны тормозят - это не совсем так. Конечно, если джойнить и фильтровать 2 огромные таблицы без индексов, то будет тормозить, но разве джойны в этом виноваты?
Ответы: >>1790444
Аноним 2020/08/27 21:43:06  №1790444 37
>>1790428
>У тебя их нет, и если ты запустишь свой код второй раз, возможно, что ответы возьмутся из кеша и не будут отражать действительность.
У меня кеш по умолчанию отрублен. Ради интереса перепроверил, нихуя не поменялось.
А вот забавный момент - плейсхолдеры дают реальный прирост быстродействия, не ожидал. Конечно, на реальном проекте за 30000 запросов выебут, но тут они дали полуторократный прирост скорости.

>Ну и то, что джойны тормозят - это не совсем так.
Мне ОЧЕНЬ сильно печет жопу то, что с воплями про страшные и ужасные джойны делают кривую структуру БД, которая в результате тормозит сильнее чем изначальные джойны. Видел своими глазами. Данный товарищ со своими массивами просто проехался по старому бугурту.
Ответы: >>1790448
Аноним 2020/08/27 21:48:05  №1790448 38
>>1790444
Какими нахуй массивами, долбоеб? Я вообще всю дорогу говорил про тип данных jsonb в постгресе. Для которого давно есть индексы и язык запросов. Но ты же гений (долбоеб), который генерит запросы с помощью ОРМ без explain'а, и при этом высирающий что-то про тормоза и кривую структуру бд.
Ответы: >>1790456
Аноним 2020/08/27 22:08:17  №1790456 39
>>1790448
>Я вообще всю дорогу говорил про тип данных jsonb в постгресе.
Вот именно его я и использовал.
>Для которого давно есть индексы и язык запросов.
Использовался именно этот запрос.
И оно тормозит.

>Но ты же гений (долбоеб)
Оскорбления от человека, который на полном серьезе засовывает в БД json и рассказывает, как это заебись, не трогают меня, извини. Ты как слюнявый деревенский дурачок со спущенными штанами, который кричит прохожим, что у них грязные волосы. Я просто тыкаю в тебя палкой для собственного веселья, пока мне не надоест. Я потратил на тебя время, в ответ слышал только бессмысленные оскорбления, голословные (и насквозь лживые) утверждения о производительности, которые я опровергнул для себя, и требования предоставить больше данных. Ты этого не заслуживаешь, сори.
Ответы: >>1791393
Аноним 2020/08/28 17:15:26  №1791393 40
>>1790456
Это каким же долбоебом нужно быть, чтобы писать что-то о производительности запросов используя ссаную ОРМ.

>Да медленнее епты, только запрос я не покажу. Какой нахуй эксплейн? Какой план запроса? Просто лень постить, все там медленнее. Просто это ты хуевый, поэтому запрос я постить не буду. Но там точно медленнее.

Одни из лучших программистов на планете пять лет ебуться чтобы добавить поддержку JSON работающую быстрее чем у оракл и монги. Но долбоебу на двачах нинужно. Ему ебать орм запросы пишет. У него все три таблицы в базе нормализованные, а значит никому больше JSON не нужон.

Ну подставляй ебало, долбоеб. Вот тебе тест производительности https://dbfiddle.uk/?rdbms=postgres_12&fiddle=d41fe5001e04b9f96465de3194c3060b запросы детские, чтобы ты, чмоня, в них разобрался.
Четыре LEFT JOIN' а подряд. Против Json path запроса в одну строчку. По скорости json выигрывает в два раза, по затратам в десять.

Так что, кукаретик, свои запросы запостишь? Какое на этот раз будет оправдание?
Ответы: >>1791894
Аноним 2020/08/29 12:34:28  №1791894 41
>>1791393
Ну давай разбирать по частям тобой написанное.
https://dbfiddle.uk/?rdbms=postgres_12&fiddle=2300a430c9380dd5a5979eb1769a88e4
Вот мы добавляем ещё одно условие и сортировку, и наша быстрота куда-то испаряется, потому что json говно оно и есть говно.
Да, я прекрасно знаю, что у нас теперь разные по факту запросы (проблема в wildcard и and), мне на это похуй. Можешь сам написать как правильно, я в этом не разбираюсь и не желаю разбираться.
Самое главное - в случае join ты получил именно требуемые данные.
В случае выборки json ты выбираешь его целиком. В результате в дереве у тебя пачка элементов, с fifth.id не удовлетворяющими твоему условию. Что ты будешь с ним делать?
Ну то есть я знаю, ты будешь петушить результат выборки перебором в коде, конечно. Muh speed.

>запросы детские
ну это неудивительно, чем сложнее будут запросы тем отсос json говна будет глубже.
Ответы: >>1792057
Аноним 2020/08/29 16:24:06  №1792057 42
>>1791894
>Вот мы добавляем ещё одно условие и сортировку, и наша быстрота куда-то испаряется, потому что json говно оно и есть говно.
Криворукий ты обмудок. Кого ты хочешь наебать? Пенек осиновый, ты ведь нихуя не понимаешь почему json тут быстрее, и почему я с самого начала знал что он быстрее.
JSON Path запрос выполняется всего один раз на каждый документ. А джойны генерят записи в геометрической прогрессии, примерно 350К записей по 14 колонок. Снаружи весь этот пиздец может быть не видно, но в память все это попадает перед фильтрацией. И чем больше связей, тем медленнее это будет работать. И никакие индексы тут не помогут, потому что размер индексов приближается к размеру самой таблицы. С каждым новым джойном затраты на Json path будут возрастать линейно, в то время как обычные SQL запросы будут убивать сервер нахуй. Я добавил всего 100К записей на пятый уровень и время увеличилось до секунды, в три раза медленнее чем json path. С миллионом не факт что вообще выполнится, а не отвалится по таймауту.
Это физический предел реляционной модели, манипулировать в запросах иерархиями такой глубины становится просто не выгодно.

https://dbfiddle.uk/?rdbms=postgres_12&fiddle=f8de9cd4c650a284b1c6d3416b2e06d3
Ссу тебе на ебало второй раз. Начинай маневрировать.

>а, я прекрасно знаю, что у нас теперь разные по факту запросы (проблема в wildcard и and), мне на это похуй
Что ты несешь долбоеб криворукий? С какого хуя вдруг они стали разными? Я специально добавил подсчет количества, чтобы было видно что выборка одинаковая. Если запрос составлен правильно, то количество записей будет одинаковое. Это же надо так обосраться, беги читать в википедии как лефт джойны работают.

>В случае выборки json ты выбираешь его целиком. В результате в дереве у тебя пачка элементов, с fifth.id не удовлетворяющими твоему условию. Что ты будешь с ним делать?
Это троллинг тупостью? Это типа не очевидно, что раз можно сделать запрос любой сложности, то и достать нужный кусок тоже можно? Специально для тебя долбоеба добавил запрос, который возвращает только элементы, в которых fifth.id удовлетворяет условию.

Обоссан по всем пунктам. Но ты ловко вильнул сракой и опять не запостил свои запросы, которые сто проц доказывают что json говно. Какое оправдание будет на этот раз?
Ответы: >>1792152
Аноним 2020/08/29 18:50:11  №1792152 43
>>1792057
Ты понимаешь, что этими 2 типами запростов ты решаешь принципиально разную задачу?
При создании массивов через рандом у тебя получается пирамида зависимостей.
Часть элементов пустые, часть заполненные.
https://pastebin.ubuntu.com/p/rBvgGmKG57/
Здесь json из твоей базы, удовлетворяющий условию. Смотри на него внимательно. В нем есть такие шикарные элементы, как third null, к примеру.

Что нам с ними придется делать? Правильно, в коде как мы их получили проверяем.

Фактически, своим json ты решаешь следующую задачу - выбрать ПЯТЫЙ круг, прилинкованные к нему элементы ПЕРВОГО круга (через всю цепь) и все дети ПЕРВОГО круга на похуях. Ну типа потом мы в коде их как - нибудь обработаем.

Не возражаешь, если я так же решу задачу джойнами? Линкуем сразу 5 круг на первый.
https://dbfiddle.uk/?rdbms=postgres_12&fiddle=7dc49b28145f6aa023b5093477c63c86
Смотрим на перфоманс и орем.
Из-за того, что я линковал тир к первому рандомом вместо правильной цепочки, там разное количество элементов. Если линковать правильно будет одинаковое. Можешь заняться.

То есть, я беру твою базу с json и нормализую.
Теперь у меня есть 2 пути.
1. Либо ОЧЕНЬ прожорливый запрос, который тем не менее выдает абсолютно чистые данные, с которыми потом гораздо быстрее работать.
2. Либо запрос, который решает твою задачу, но экономичнее в 100 раз.
Оба пути обладают своими плюсами и минусами. Оба пути позволяют отнести твою json базу туда, где её и место - на помойку.

Давай остановимся на втором варианте? Я ускорил твой запрос в 100 раз. Это достаточно, что бы до тебя дошло, что ты творишь дичь? Я ожидаю новый поток визга и оскорблений, но на этом этапе я просто молча ухожу, считая дальнейшее общение бессмысленным. Оставайся пердолить свой полудохлый сервак, забитый сраным говном, и считать это хайлоадом.


У меня дежа-вю. Красный, потный Олег понимал, что он целый год пилил кривую хуйню, пялился в код, из которого была выкинута его json параша, и который работал в десятки раз быстрее его говна, был свободно расширяем в любом направлении, и судорожно придумывал как бы обосрать, вытаскивал из головы сценарии, которые решались 2 часами моей работы и вообще не прокатывали на его коде, лол.
Ответы: >>1792406
Аноним 2020/08/30 04:11:51  №1792406 44
>>1792152
>Здесь json из твоей базы, удовлетворяющий условию. Смотри на него внимательно. В нем есть такие шикарные элементы, как third null, к примеру.
>Что нам с ними придется делать? Правильно, в коде как мы их получили проверяем.
Ты в натуре ебанутый? Они пустые, потому что я их оставил пустыми, долбобеб. Я блядь своими руками создал этот JSON, убрать их дело двух секунд.

>Не возражаешь, если я так же решу задачу джойнами? Линкуем сразу 5 круг на первый.
Вот тут в голос. Ебать ты гений, лимит 400 поставил. 400 чего? Попугаев? Пиздуй в википедию читать как лефт джойны работают.
На сколько же ты хуевый. Ты продублировал колонку (не денормализация), добавил кучу foreign key'ев (долбоеб, там индексы и так есть), а производительность улучшилась только когда ты выкинул нахуй весь запрос и он теперь выдает рандомную хуйню. Буквально случайный набор цифр и букв.

После своих 20 IQ мувов ты больше не можешь добавлять записи на пятый уровень не зная какой id будет на первом. А как их получить? Да надо блядь опять пройти по всей иерархии, долбобеб. Ты же просто нагенерил случайной хуйни и этот Id просто не соответствует положению элемента в иерархии. Ахахахах, я до этого думал что ты просто джун, но теперь то понятно что ты с базой не работал никогда в своей жизни.

>То есть, я беру твою базу с json и нормализую.
Никто не делает всю базу на json, долбаеб. Ты просто можешь создать копию данных для более удобного поиска по ним. Собственно так и происходит в мое сниппете, слепой ты дегенерат.

>запрос, который решает твою задачу, но экономичнее в 100 раз
Охуенно ускорил, кек. Выдает рандомную хуйню, зато быстро.

>Давай остановимся на втором варианте? Я ускорил твой запрос в 100 раз. Это достаточно, что бы до тебя дошло, что ты творишь дичь?
Что ты ускорил, долбоеб? Ты типа думал я не открою и не посмотрю, или как? Ты серьезно думал что я не увижу лимит? Ты серьезно думал что я не увижу что запрос выдает мусор?

>я просто молча ухожу
А как же твои запросы, которые тебе так было лень показывать? Опять вильнешь сракой и проигноришь? Показывай запросики, хуйлуша.