Не люблю, когда для обхода данных нужна пагинация. Всякие LIMIT/OFFSET,nextToken и прочие костыли.

Да!

PostgreSQL Query Plan Visualizer add new plan

BRIN stands for Block Range Index. BRIN is designed for handling very large tables in which certain columns have some natural correlation with their physical location within the table.

SQL Polyglot is a quick way to see if a particular SQL feature is supported in different database systems. Write a query and see it run anywhere from PostgreSQL to DuckDB without leaving your browser.

Из комментариев под статьёй:

Кто-то не очень понимает, что ORM в первую очередь - маппер. Да, и называется он Object-Relational Mapper. Отвечает за взаимосвязь между реляционными данными и объектно-ориентированным миром.

Тот, кто хотя бы раз сталкивался с опечаткой при загрузке поля в объект, уже не задаёт вопросы, оправдан ли ORM. Когда за тебя связку делает кодогенератор с нулевой возможностью ошибки на любой сложности схеме - начинаешь ценить надёжность такого решения.

Что касается SQL. ORM не может в принципе покрыть весь синтаксис SQL. И не должен, это не его задача. Его задача - сделать простым синтаксис 95% случаев, когда дальше джойна и WHERE ничего не надо. ORM не мешает использовать чистый SQL, а чаще всего может его дополнить, переводя результат сложного запроса в набор объектов.

GQL is a query language with a syntax very similar to SQL with a tiny engine to perform queries on .git files instance of database files, the engine executes the query on the fly without the need to create database files or convert .git files into any other format, note that all Keywords in GQL are case-insensitive similar to SQL.

Функции должны быть чистыми, чтобы по ним работал индекс

Using UPPER or LOWER for case-insensitive search is not a good practice. Prefer using a _CI collation if possible or at least add the right indexes to make your query fast.

The most important consideration when defining a concatenated index is how to choose the column order so it can be used as often as possible.

Например, поиск по имени без фамилии бесполезен. Значит, составной индекс должен начинаться с фамилии, а потом уже будет имя.

An index lookup requires three steps: (1) the tree traversal; (2) following the leaf node chain; (3) fetching the table data. The tree traversal is the only step that has an upper bound for the number of accessed blocks—the index depth. The other two steps might need to access many blocks—they cause a slow index lookup.

SQL has evolved. Beyond the relational model. Discover it now.

Sort-merge joins do not need indexes on the join predicates.
MySQL does not support sort-merge joins at all.

Index the independent where predicates to improve hash join performance.

Indexing join predicates doesn’t improve hash join performance.

Indexing a hash join is independent of the join order.

Select fewer columns to improve hash join performance.

Hash joins do not need indexes on the join predicates. They use the hash table instead.
A hash join uses indexes only if the index supports the independent predicates.
Reduce the hash table size to improve performance; either horizontally (less rows) or vertically (less columns).
Hash joins cannot perform joins that have range conditions in the join predicates.

Avoid LIKE expressions with leading wildcards (e.g., '%TERM').

Rule of thumb: index for equality first—then for ranges.

Fun fact: There is no limit clause in the SQL standard.

Everyone uses limit.
And yet, according to the standard, we should be using fetch

Представьте, какой гемор был бы построить это в Экселе, Гугле или даже на языке программирования вроде Питона. Там с одним только парсингом дат и времени наешься, а тут все из коробки.

PRQL is a modern language for transforming data

Интересная замена SQL. Запросы для аналитики данных станет писать намного проще. Не думаю, что для чего-то другого этот проект подойдёт. Условный CRUD проще написать, используя именно SQL запросы, здесь PRQL излишен.

Для всех, кто знал SQL, но подзабыл