SQL DATABASE (6 стр)

skalogryz
> НО, в итоге выяснилось, что в "sql" синтаксисе объявить локальные переменные
> нельзя, в "plPgSQL" можно.
> + Показать
> но синтаксис разный, и по-этому придёться учить и то и то.
Вроде понял.

Ну пользуйся только PL/pgSQL - и тогда не придётся иметь проблем с локальными переменными, и не нужно будет учить языки, которыми не пользуешься.

skalogryz
> не согласен насчёт "махрового легаси"... было бы так, что MS SQL 2022 бы не
> выходил.
Очевидно же, что он выходит для того махрового легаси, которое никто не будет переписывать с нуля, но к которому всё ещё дописывают новые фичи и фиксят старые - тогда переход на новую версию убожества позволит использовать "новые" возможности движка в новом коде, при этом не ломая гигабайты старого.

skalogryz
> Так что, конторы, у которых есть бабло, могут выбрать.
Могут выбирать между неправильными ответами и постгресом.

Повторяю ключевую мысль ещё раз. Когда ты, в начале нового проекта, выбираешь MS SQL - у тебя есть вполне реальный шанс впоследствии об этом пожалеть, в форме: «как жаль, что в MS SQL этой фичи нет, вот если бы мы взяли PostgreSQL - мы бы просто взяли и решили эту задачу, а с MS SQL - придётся костылить и выкручиваться». А в случае PostgreSQL, этот сценарий гораздо менее вероятен, потому что если какой-то возможности в нём нет - скорее всего, её нет вообще ни у кого.

Dieseluga
> SELECT ISNULL(p.name, ''), SUM(o.sum)
> FROM Operation AS o
> LEFT JOIN Partner as p
> ON o.id_part = p.id_part
> GROUP BY p.name;
верно.
но SELECT ISNULL(p.name, '') конструкция не очевидна по учебнику
обычно select(names) from (tables-names)
ну и добавить именования .имена. .сумма. SELECT ISNULL(p.name, '') as names, SUM(o.sum) as summa
обозвать колонки
вообще имелось ввиду записать стандартно select from where having group order без спец моментов выкрутасов

Да взять хоть тот же NULLS LAST. MS SQL предоставляет хоть что-нибудь взамен, что могло бы скомпенсировать отсутствие этого функционала и оправдать его выбор для нового проекта?

Имбирная Ведьмочка
> MS SQL предоставляет хоть что-нибудь взамен

Я же показал в #70, как это можно сделать почти в любом диалекте SQL. Результат конструкции CASE WHEN может быть использован как более приоритетный фактор упорядочивания.

А непосредственно в MSSQL можно эту конструкцию завернуть в свою пользовательскую функцию.

Rikk
> конструкция не очевидна по учебнику

Ты инженер или нет? Инженер должен уметь простые закономерности/правила, написанные в учебниках, комбинировать в сложное требуемое поведение.

Dmitry_Milk
> Инженер должен
в мире так много вещей что всего знать нельзя=лопнешь изучать и заезжать интеллектом в тему.
Dmitry_Milk
> комбинировать в сложное требуемое поведение.
даже глубокие профи спотыкаются. певец возьмет фальшивую ноту, у хирурга задрожит рука,и тд..
и таки эта забитая фраза - высшая школа учит не вызубривать а пользоваться ресурсами найти чего требуется в каком то месте(инфо по теме). ресурс я нашел(учебник).темы отработал(лекции+упражнения). но пара не явных моментов не по стандарту затык.и это is null вворачивать в нужную обертку- вовсе не очевидно.

Rikk
> певец возьмет фальшивую ноту, у хирурга задрожит рука

Музыка и медицина - великолепные примеры инженерной деятельности :)

О чем вы говорите, в PostgreSQL нет даже элементарных (и что более важно - лаконичных) IF и IFNULL, и приходится обмазываться CASE портянкой и громоздким COALESCE.

entryway
> громоздким COALESCE

Чем он громоздкий? Тем, что на две буквы длиннее? :)

Dmitry_Milk
Длиннее, неудачное название для 99% случаев использования. COALESCE наверное везде есть, где есть IFNULL.

entryway
> О чем вы говорите, в PostgreSQL нет даже элементарных (и что более важно -
> лаконичных) IF и IFNULL, и приходится обмазываться CASE портянкой и громоздким
> COALESCE.

IF(a, b, c)
CASE WHEN a THEN b ELSE c END

IFNULL(a, b)
COALESCE(a, b)

Ну-ну, ты ещё скажи, что тебя begin/end в паскале заставляют тратить лишние 2 дня на реализацию очередной фичи.

Dmitry_Milk
> Я же показал в #70, как это можно сделать почти в любом диалекте SQL.
Троллейбус из буханки же.

Ну вернее, если ты изначально в безвыходной ситуации - когда на руках 15 гигабайт легаси, а фичу надо сделать уже вчера - тут да, можно закостылить.

Но для нового проекта - хотелось бы всё-таки предотвратить такие ситуации заранее.

Dmitry_Milk
> Музыка и медицина - великолепные примеры инженерной деятельности :)
Надо тогда хотя бы композитора брать. Прочитал учебник, поставил ноты по учебнику - збс трек, можно идти получать награды. :)

Имбирная Ведьмочка
Ты выше чуть ли не предлагал делать выбор в пользу PostgreSQL из-за ORDER BY p.name NULLS LAST, как будто с этим у кого-то есть какие-то проблемы. Почему бы мне в том же духе не ляпнуть?

Иф-кейс там, кстати, не нужен, можно же сразу сортировать результат в булах:
ORDER BY (p.name IS NULL) DESC, p.name

entryway
Ну ладно, давай ещё немного фич:

- встроенные типы для геометрических объектов;

- BVH-индексы для встроенных типов геометрических объектов;

- индексы для выражений (CREATE INDEX ON foobar (length(name) + 1));

- индексы для жисонов: CREATE INDEX ON foobar (metadata) USING gin ускоряет запрос SELECT * FROM foobar WHERE metadata ? 'meta_key', который возвращает все строчки, в которых metadata на топ-уровне содержит поле с ключом "meta_key";

- INSERT INTO foobar (key, value) VALUES ("a", "b") ON CONFLICT (key) DO UPDATE SET value = value || ',' || excluded.value.

Этого достаточно, чтобы оправдать две лишние буквы в COALESCE?

надо было просто подать решение задачи и все.
а вы флейм устроили