с приходом упсерта делать нелепые уровни нормализации стало просто как никогда

«Меняй кучу строк в транзакции в несколько потоков и не уебись в дедлок» (игра для всей семьи)

Совет дня: никогда не пихайте NULL там, где можно без нарушения логики сделать NOT NULL DEFAULT 0/1970-01-01 00:00:00/'' Особенно если планируется потом индекс сверху городить.

Совет дня: не используй NULLS FIRST/LAST, когда можно COALESCE.

HASH ANTI JOIN как это работает, сука

Давайте поиграем в игру. Есть таблицы t1 и t2. В каждой есть колонка text. Нужно в t1.text || t2.text искать LIKE %a% AND LIKE %b% AND LIKE %c%..., причем сколько этих AND будет — непонятно. Ну, ничего сложного — делаем джоин, в селекте делаем конкатенацию, все это запихиваем в подзапрос и сверху хуярим наши WHERE-лайки. Однако записей становится дохуя и все начинает тормозить. По очевидным причинам индексы нихуя не помогают. Как выебнуться в этом случае, не прибегая к денормализации и мужеложеству?

проблема: ваши джоины выглядят хуево возможная причина: вы слишком хуево нормализовали схему

Всегда делай таблицы с айдишниками. Даже если они там ни в пизду не вперлись. Если кажется, что они не нужны — значит, ты просто еще не знаешь, для чего они будут тебе нужны через полгода. Ну а если заебут — удалишь, все равно в коде инсертов их нет. И под айдишниками я подразумеваю обычную хуергу, которая выдается по счетчику. Если рядом есть какой-нибудь UUID — все равно нужен айдишник.

Совет дня: пиздите тех, кто предлагает «просто сделать полиморфную связь».

Объяснил постороннему человеку, как работает VACUUM и VACUUM FULL. Человек обосрался. Стыдно теперь че-то.

Многие вещи в базе данных становятся гораздо проще, если ввести иммутабельные (а то и неудаляемые) строки. Главное не переусердствовать, а то место на харде закончится.

modern sql, slides: http://www.slideshare.net/MarkusWinand/modern-sql Всем, кто использует sql руками, рекомендую ознакомиться/вспомнить.

postgresql jsonb: http://www.databasesoup.com/2014/12/your-hanukkah-present-postgresql-94.html А ещё сегодня третий день хануки, а празднований чото не вижу. Ерж уже не те?

Я видел разные способы хранить интервалы дат в реляционках. Не, понятно, там два столбца, типа dt_start + dt_end, но кое-какие моменты не доходят до людей вообще. Попробую исправить. - null как дата начала/окончания -- неудобно. Правильное решение: фиксированные даты типа 01.01.0001 и 31.12.9999 и функции/вьюхи для получения видимой пользователем даты (если такая будет). Это только выглядит криво, а на самом деле спасает от тонн ошибок, связанных с нуллами. - главное: дата начала -- включительно, дата окончания -- исключительно. То есть, если есть дата начала 2014-12-07 00:00:00 и дата окончания 2014-12-08 00:00:00, в этот интервал попадают все даты 2014-12-07 XX:XX:XX, но не попадают 2014-12-08 00:00:00 и больше неё. С такими раскладами не получится сделать where mydate between dt_start and dt_end (если бы обе даты были "включительно"), но это абсолютно похуй, так как профит перевешивает: 1. условия не зависят от типов и форматов дат: в случае преобразования даты+времени в дату (если часы были 00:00:00) либо преобразования даты в дату+время (когда добавляют часы 00:00:00 к дате без часов) код продолжает работать как и раньше (а такие преобразования не всегда видны в коде невооружённым глазом, неявные преобразования типов таки случаются). 2. нет привязки к тому, какой "квант времени" подразумевался. Если бы интервал из примера выше был записан "концы включительно, квант = сутки", было бы "2014-12-07 .. 2014-12-07". Если бы надо было разбивать на часы, интервал внезапно преобразился бы в "2014-12-07 00:00:00 .. 2014-12-07 23:00:00". 3. часто надо рассмотреть "какие интервалы попадают на данную дату-время". В случае "квант = сутки" имеем where trunc(dt, 'DD') between dt_start and dt_end, заметьте функцию для обрезания даты и явное указание, докуда обрезать. А функции, как известно, не очень хорошо сотрудничают с оптимизатором запросов. - следствие обоих пунктов: валидация становится не сложнее, чем check (dt_start < dt_end) (для непустых интервалов) или check (dt_start <= dt_end) (для возможно пустых интервалов). - для извращенцев: with recursive либо connect by по условию prev.dt_end = next.dt_start

https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.4 -- постгрес хорошо движется вперёд, мне нравится.

=> SELECT NULL UNION ALL SELECT 1; (2 rows) => SELECT NULL UNION ALL SELECT NULL UNION ALL SELECT 1; ERROR: UNION types text and integer cannot be matched => SELECT pg_typeof(t.t) FROM (SELECT NULL AS t UNION ALL SELECT NULL AS t) t; text text нул юнион нул у него текст вывод типов уровня постгреса

UNION ... LIMIT в постгресе работает восхитительно: > EXPLAIN ANALYZE SELECT y FROM test WHERE x = 66 LIMIT 10; Total runtime: 0.146 ms > EXPLAIN ANALYZE (SELECT y FROM test WHERE x = 66) UNION (SELECT y FROM test WHERE x = 67) LIMIT 10; Total runtime: 86.011 ms Но зато: > EXPLAIN ANALYZE (SELECT y FROM test WHERE x = 66) UNION ALL (SELECT y FROM test WHERE x = 67) LIMIT 10; Total runtime: 0.183 ms

http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back Про enum чуть-чуть гонят (в постгресике с ним гибче, чем обычно), но, в целом, правы.

EXPLAIN ANALYZE SELECT max(y) FROM test WHERE x = 66; Total runtime: 0.124 ms EXPLAIN ANALYZE SELECT max(y) FROM test WHERE x = 66 GROUP BY x; Total runtime: 29.157 ms EXPLAIN ANALYZE SELECT max(y) FROM test WHERE x IN (SELECT generate_series (1,1) as x); Total runtime: 1908.248 ms ЭСКУЭЛЬ ДЕКЛАРАТИВНЫЕ ЗАПРОСЫ ОПТИМИЗАЦИИ АНАЛИТИЧЕСКИЕ БАЗЫ ДАННЫХ КОКОКОКОКО