Новый клиент для современных баз данных

С встроенным AI и MCP, расширяемый через плагины.
✓ Поддержка PostgreSQL, MariaDB, MySQL и SQLite
✓ Для macOS, Windows и Linux
✓ Переведён на испанский язык

Open source и бесплатный: TabularisDB

👉 @SQLPortal

Когда ты пишешь SQL-запрос, порядок команд вроде бы логичен SELECT, FROM, WHERE и тд. Но база данных выполняет их в другом порядке 😄

Настоящая последовательность выполнения 👇

FROM
JOIN
ON
WHERE
GROUP BY
HAVING
SELECT
ORDER BY
LIMIT

💡 Поэтому WHERE не может использовать SUM() — он идёт до агрегации. А HAVING — можно

На фото слева. то в каком порядке мы обычно пишем SQL-запрос, а справа как реально работает база данных под капотом. Запомни эту логику, и ты избежишь кучи ошибок в SQL-запросах

👉 @SQLPortal

Если вы всё ещё используете PostgreSQL 14-й версии, вот две важные вещи, которые стоит знать:

Последний релиз от сообщества выйдет уже в этом ноябре.

Вы упускаете 5 лет серьёзных улучшений производительности, новых возможностей и повышения стабильности.
Обновление между мажорными версиями требует подготовки. Изменения в page headers, форматах tuple и оптимизациях индексов означают, что вам потребуется пересобрать индексы и структуры данных. Типичные пути миграции — pg_dump/restore, pg_upgrade или логическая репликация (logical replication) со всеми её известными ограничениями.

Также функции и extensions после обновления могут вести себя иначе, поэтому корректная поведенческая валидация (behavioral validation) критически важна — особенно для production-систем. Так что просто YOLO-обновление тут не вариант.
Но бояться этого тоже не стоит. Улучшения производительности и надёжности в новых версиях PostgreSQL действительно заметны — и ваши запросы, и ваша повседневная работа станут ощутимо приятнее.

https://www.crunchydata.com/blog/examining-postgres-upgrades-with-pg_upgrade

👉 @SQLPortal

5 SQL-советов, которые ускорят ваши запросы и сберегут нервы

🛑 Не злоупотребляйте индексами
🛑Индексы ускоряют поиск, но замедляют запись и занимают место
🛑Создавайте их для столбцов в WHERE, JOIN и ORDER BY

🛑 Структура запроса важна
🛑Разбивайте сложные запросы на несколько простых
🛑Запрашивайте только нужные столбцы

🛑 Оптимизируйте JOIN и WHERE
🛑Используйте индексы и фильтруйте данные как можно раньше

🛑 Избегайте коррелированных подзапросов
🛑Переписывайте их через JOIN или используйте временные таблицы

🛑 Дизайн базы — основа производительности
🛑Балансируйте между нормализацией (целостность) и денормализацией (производительность)

👉 @SQLPortal

Почему расширения PostgreSQL нужно собирать под конкретные major-версии?

Мажорные релизы PostgreSQL намеренно изменяют внутренние структуры, сигнатуры функций и layout памяти в заголовочных файлах. Это приводит к изменениям существующего ABI (application binary interface).

Расширения PostgreSQL зависят от стабильного ABI для бинарной совместимости с самим Postgres.
Обычно PostgreSQL старается сохранять совместимость расширений между минорными версиями. Это означает, что расширение, собранное под PostgreSQL 18.1, должно работать на 18.2. Однако это не всегда гарантируется.

Нюансы гарантий ABI в PostgreSQL оказались достаточно обсуждаемой темой, из-за чего в июле 2024 года появилась новая документация по этому вопросу: https://postgresql.org/docs/current/xfunc-c.html#XFUNC-API-ABI-STABILITY-GUIDANCE

Существенное изменение структуры произошло даже в минорном релизе 17.1, что даёт представление о том, как опытные разработчики расширений справляются с интеграцией PostgreSQL: https://x.com/marcoslot/status/1857403646134153438

👉 @SQLPortal

Как выжить на первой работе в Data Analysis

1. Всегда обращай внимание на детали.
Никогда не копируй-вставляй то, что не до конца понимаешь (включая AI-генерированный код). Ни SQL-запрос. Ни число из письма. Ни фильтр от коллеги.
Если ты это вставил — ты за это отвечаешь. И если оно неверное, виноват тоже ты. Следи за данными, которые используешь, за информацией, которую получаешь, и за всем, что попадает в отчёт. Если не уверен — лучше не включай.

2. Не делай предположений.
Не уверен в чём-то? Не гадай. Не «кажется». Не «скорее всего». Не «должно быть».
Спрашивай. Проверяй. И потом проверяй ещё раз. Предположения могут похоронить тебя быстрее лавины.

3. Проси помощи.
Это не одиночный спорт. Не понимаешь логику? Не знаешь, как написать join? Застрял на графике? Проси помощи. Не будь умником, который пытается всё сделать сам и ломает прод в пятницу в 18:00. Команде проще ответить на «глупый вопрос», чем чинить «глупую ошибку». Команда для этого и есть.

4. Всегда считай, что твой босс умнее тебя.
И не пытайся, повторяю, не пытайся «пускать пыль в глаза». Босс видел больше отчётов, ошибок и оправданий, чем ты можешь представить.
Если ты не уверен — говори прямо: «я не знаю» или «мне нужно проверить». Честность ценится гораздо выше попыток что-то скрыть.

5. Прокачивай технические навыки.
Учись быстро строить графики и отчёты. На лету. Под давлением.
В первые месяцы скорость + точность = доверие. Прокачивай SQL, Excel, Python, PowerPoint и т.д. Если стейкхолдеру нужен быстрый взгляд, а ты три часа «красиво оформляешь» — ты уже проиграл. Сначала скорость исследования, потом — полировка.

👉 @SQLPortal

В PostgreSQL можно предотвращать пересечения по людям, комнатам, автомобилям, оборудованию, книгам и любым другим ресурсам прямо на уровне данных.

Оператор && проверяет пересечение диапазонов — как числовых, так и диапазонов дат/времени. Чтобы запретить пересекающиеся интервалы, используется EXCLUDE constraint: например, можно запретить пересечения периодов с одинаковым user_id. В результате один пользователь (или комната, смена, машина — в зависимости от конфигурации) не сможет быть забронирован дважды на одно и то же время.

Для производительности используйте GiST-индекс. А поскольку здесь комбинируется оператор равенства с range-сравнением, понадобится расширение btree_gist.

Почему именно GiST?
B-tree работает только с <, =, > и их комбинациями. Понятия пересечения диапазонов у него нет. GiST (Generalized Search Tree) изначально проектировался для диапазонов, геометрии, full-text поиска и других более сложных типов данных.

Расширение btree_gist позволяет смешивать операторы равенства и range-операторы в одном constraint’е.
На что стоит обратить внимание:

• GiST тяжелее по записи, чем B-tree. Для средних и крупных таблиц с умеренной нагрузкой это обычно простое и практичное решение. Но при большом количестве UPDATE/INSERT нужно учитывать дополнительные расходы на обслуживание индекса.
• Создание такого constraint’а потребует блокировки таблицы на время построения.
• Если используются partitioned tables, заранее проверьте, как constraint взаимодействует с вашей схемой партиционирования.

Однажды я сам того не ожидая построил календарь…
Календари сложнее, чем кажутся. Это одновременно задача хранения дат, работы с часовыми поясами, отображения данных и взаимодействия с человеческими привычками.

Один из наших клиентов регулярно перемещался между часовыми поясами — между домом и рабочими поездками — и хотел, чтобы календарь вел себя строго определённым образом. Проблема была в том, что система всегда отображала время согласно настройкам организации. Это лишь один пример того, как календари быстро превращают seemingly simple trade-offs в реальные архитектурные проблемы.

Если проверка конфликтов находится только в application logic, вы фактически полагаетесь на один или несколько codebase’ов, которые должны синхронно предотвращать double-booking.
Когда это правило переносится в базу данных, оно становится жёстким и обязательным.
И здесь важно решить: действительно ли вам нужна такая строгость?

Большинство персональных календарных приложений допускают пересечения и оставляют пользователю право самому управлять конфликтами.

Но представьте сервисный выезд: техник физически не может находиться в двух местах одновременно.
В таких сценариях данные должны быть строгими. ПО обязано предотвращать двойное бронирование ресурсов, которые невозможно использовать параллельно.

Когда реализуете защиту от double-booking, внимательно продумывайте уровни ограничений и архитектурные trade-offs, чтобы понять, должна ли именно база данных быть источником этого правила.
Календари и так достаточно хаотичны.

Там, где это возможно — пусть хаос ограничивает PostgreSQL.

👉 @SQLPortal

База данных имеет право выполнять части SQL-выражения WHERE в любом порядке.

Так как же избежать ошибок, если известно, что выражение может выбросить ошибку,

например, извлечение квадратного корня из отрицательного числа?

Используй CASE, чтобы выполнять вычисление только для допустимых значений:

WHERE CASE 
          WHEN col > 0 THEN SQRT(col) 
          ELSE ... 
      END ...

👉 @SQLPortal

Шпаргалка по SQL для пользователей SQL Server

1. Типы данных:

⏩Точные числа: int, decimal, money, и т. д.
⏩Приблизительные числа: float, real
⏩Дата и время: datetime, timestamp
⏩Строки char, varchar, text и Unicode версии

2. Функции работы с датой: GETDATE(), YEAR(), DATEADD(), DATEDIFF() и др.

3. Функции работы со строками: LEN(), LEFT(), RIGHT(), REPLACE(), SUBSTRING(), UPPER(), LOWER()

4. Математические функции: ABS(), ROUND(), CEILING(), FLOOR(), POWER(), SQRT()

5. Агрегатные функции: SUM(), AVG(), MAX(), MIN(), COUNT()

6. Создание объектов базы данных:

⏩Хранимые процедуры: CREATE PROCEDURE
⏩Триггеры: CREATE TRIGGER
⏩Представления (view): CREATE VIEW
⏩Индексы: CREATE INDEX
⏩Функции: CREATE FUNCTION

7. Конвертация типов: CAST(), CONVERT()

8. Ранжирование и оконные функции: RANK(), DENSE_RANK(), ROW_NUMBER()

👉 @SQLPortal

Если ты новичок в SQL — это просто находка

Это сайт, который анимирует выполнение SQL-запросов.

Ты вставляешь SQL, жмёшь visualize — и видишь, как твой запрос "оживает": шаг за шагом показывает, как SELECT вытягивает данные, как JOIN соединяет таблицы, как фильтруются строки и т.д.

👉 @SQLPortal