Всегда было интересно, почему на SQL так часто пишут is_active = true, хотя логично же просто is_active, как в любом нормальном языке программирования.
Покажу и свое решение задачи про параметры. Оно использует рекурсивный запрос и JSON для отслеживания текущего состояния параметров (есть удобные операции - и || для удаления и добавления ключа в объект, получается имитация множества).
WITH RECURSIVE enumerated AS (
SELECT *, row_number() OVER (ORDER BY ts) n FROM params
), r(ts, n, params) AS (
SELECT null::timestamp, 0::bigint, '{}'::jsonb
UNION ALL
SELECT p.ts, p.n,
CASE
WHEN p.value IS NULL THEN r.params - p.parameter_name
ELSE r.params || jsonb_build_object(p.parameter_name, 1)
END
FROM r, enumerated p
WHERE p.n = r.n + 1
), lens AS (
SELECT ts, n, array_length(array_agg(keys),1) len
FROM r, jsonb_object_keys(params) keys
GROUP BY ts, n
), intervals AS (
SELECT tsrange(ts, lead(ts) OVER (ORDER BY ts)) tsr, max(len) mlen
FROM lens
GROUP BY ts
)
SELECT lower(tsmr), upper(tsmr), mlen
FROM (
SELECT unnest(range_agg(tsr)) tsmr, mlen
FROM intervals
WHERE mlen = (SELECT max(mlen) FROM intervals) AND mlen > 1
GROUP BY mlen
);
Не, это by design, а не current implementation. Сохраняет первую строку, первая строка определяется по правилам `ORDER BY`, а если это предложение не указано, но ССЗБ. И пример там дальше приведен совершенно однозначный.
SELECT DISTINCT ON ( выражение [, ...] ) сохраняет только первую строку из каждого набора строк, для которого данное выражение даёт одинаковые значения. Выражения DISTINCT ON обрабатываются по тем же правилам, что и выражения ORDER BY (см. выше). Заметьте, что «первая строка» каждого набора непредсказуема, если только не применяется предложение ORDER BY, определяющее, какие строки должны быть первыми.
Чего далеко ходить, вон разработчики хабраредактора отказались от простого текста в пользу не пойми чего с внутренней структурой. Казалось бы, что может пойти не так?
Если нам надо дождаться освобождения строки, фактически мы должны дождаться окончания блокирующей транзакции — все блокировки снимаются при фиксации или откате. А для этого можно запросить блокировку номера блокирующей транзакции (которая, напомню, удерживается самой транзакцией в исключительном режиме). Таким образом число используемых блокировок пропорционально числу одновременно работающих процессов, а не количеству изменяемых строк.
После того как вторая транзакция "упрется" в первую заблокированную строку, она уже не продвинется дальше, пока блокировка номера первой транзакции не будет снята.
Справедливости ради. Строчки — это, конечно, нехорошо, надо было строки, но никак не записи. И колонки в литературе встречаются наравне со столбцами.
Записи и поля — это уже нечто не реляционное, обычно в языках программирования. К тому же поле относится к отдельной записи, а вот в качестве ключа в таблице выступают именно столбцы/колонки.
Всегда было интересно, почему на SQL так часто пишут
is_active = true, хотя логично же простоis_active, как в любом нормальном языке программирования.Больше скажу: неравнодушные к типографике не ленятся и — написать.
Учёный изнасиловал журналиста.
Если упростить до одной фразы: главное — процесс, а не результат.
Ну давайте сравним, что ли. Ткнул почти наугад. Оригинал:
Перевод 1:
Перевод 2:
Спасибо, я лучше второй почитаю.
Вот только даже 12-я версия уже не поддерживается. Зачем сейчас что-то, кроме SQL/JSON — большая загадка.
IBM 701 — это 1953-й год. В 69-м совсем другие были технологии.
Всегда пожалуйста! Расскажите, Никита, как пришла в голову такая идея и главное — как удалось это отладить? Я долго разбирался (:
Тут, увы, все смешано. Например, колоночное и построчное хранение — тоже перпендикулярная к SQL характеристика.
Красиво!
Да, но если заменить 5 и 3 на другие числа, может получиться уже не так привлекательно (:
Покажу и свое решение задачи про параметры. Оно использует рекурсивный запрос и JSON для отслеживания текущего состояния параметров (есть удобные операции
-и||для удаления и добавления ключа в объект, получается имитация множества).Не, это by design, а не current implementation. Сохраняет первую строку, первая строка определяется по правилам `ORDER BY`, а если это предложение не указано, но ССЗБ. И пример там дальше приведен совершенно однозначный.
https://postgrespro.ru/docs/postgresql/17/sql-select#SQL-DISTINCT
Об этом речь?
Чего далеко ходить, вон разработчики хабраредактора отказались от простого текста в пользу не пойми чего с внутренней структурой. Казалось бы, что может пойти не так?
Вот ключевой фрагмент:
После того как вторая транзакция "упрется" в первую заблокированную строку, она уже не продвинется дальше, пока блокировка номера первой транзакции не будет снята.
Все так.
Справедливости ради. Строчки — это, конечно, нехорошо, надо было строки, но никак не записи. И колонки в литературе встречаются наравне со столбцами.
Записи и поля — это уже нечто не реляционное, обычно в языках программирования. К тому же поле относится к отдельной записи, а вот в качестве ключа в таблице выступают именно столбцы/колонки.
Истинная правда. Но
в Постгресе как раз индексируются.
С помощью госуслуг бюрократию отлично автоматизировали, но побеждать ее и в мыслях ни у кого нет.