Комментарии 15
И именно тогда я открыл для себя потрясающие возможности PostgreSQL, которые значительно мою жизнь.
Куда спешим? Притормозите, ведь жизнь уже значительно!
Для меня большим мучением до сих пор является группировка по полю в выводом всех полей. Как это работает не совсем понятно.
Поддерживаю. Максимально дебильное решение из-за которого группировку по возможности не использую.
Вы немного не до конца описали задачу, поэтому не может быть однозначного ответа. Если пытаться обобщить, то когда вы группируете по какому то полю, то дальше сами решаете что именно сделать с остальными полями. Функции которые этим занимаются, так и называются групповые. Они могут делать разные вещи суммировать/конкатенировать/выбирать максимальное/выбирать первое попавшееся/ собирать массив и тд и тп и др
Что это значит? Можно пример?
Я бы с радостью посмотрел на компанию, которая дает новичкам добавлять расширения в базу и разрешает им писать рекурсивные запросы на чистом SQL.
Рекурсивные запросы позволяют работать с иерархическими структурами, например такими, как категории продуктов или организационная структура.
Если говорить о работе с иерархическими структурами, то мне кажется, что стоит упомянуть тип данных ltree. На мой вкус это не такой громоздкий способ, как рекурсивные запросы, но он требует предварительной подготовки данных.
Положим третий пункт есиь и в мариидб, а с массивами покажите выборку набора юзверей у которых данное предпочтение на третьем месте массива..
Если полнотекстовый поиск и CTE - вполне нормальные фичи, то вот за хранение атрибутов как указано в примерах первого пункта (JSON), я бы просто порол.
Эти атрибуты должны быть в таблице пользователей или связанных таблицах. Т.е. нужно нормально проектировать структуру БД, а не втыкать туда JSON в невообразимом виде, а потом мучиться с тормозными запросами.
В общем, крайне плохой пример в отношении JSON, особенно "для начинающих".
Я согласен, но тут это скорее просто в качестве примера того, как это выглядит. JSON следует избегать в рядовых случаях, но, например, если хранить ответы апи в чистом виде, не стоит размазывать ключи по полям - можно просто записать в jwon. Плюс бывают ситуации, когда поля часто меняются, и тогда с точки зрения бизнес логики выгоднее положить эти поля в json, чтобы каждый раз не менять БД, и в таком случае обсуждаемый пример выглядит корректно. Это всё конечно не для новичков
It depends, как говорится.
Если profile - это какие-то кишки фронтенда, то бить их по полям не нужно
Хахаах ну и фичи, стандартный синтаксис выдаем за фичи, знаете фичу на питоне как выводит текст? print('Hello world')
- фича?
- фича.
Никого не смутил запрос про джойн продуктов и покупателей по айдишнику?
Три фичи PostgreSQL, которые будут полезны каждому новичку