Не совсем компилятор. PL/SQL, встраиваемый язык Oracle DB.
В триггере после определённого количества (больше 4 или 5) начинаются игнорироваться return. Компилируется без ошибок и предупреждений, даже построчная отладка показывает, что return словно не существует.
Ворэраунд: не писать больше одного-двух return и использовать вложенные if.
Про запросы вида ещё скажу что их сложно отлаживать.
WITH
yearly_orders AS (/* ... */),
yearly_trans AS (/* ... */),
combined AS (
SELECT * FROM yearly_orders o...
)
Поэтому чаще всего вырастает в многоуровневый ужас внутри FROM:
SELECT
customer_id,
(order_sum + trans_sum) AS total_volume
FROM (
SELECT
COALESCE(o.customer_id, t.customer_id) AS customer_id,
COALESCE(o.order_sum, 0) AS order_sum,
COALESCE(t.trans_sum, 0) AS trans_sum
FROM
(
SELECT
user_id AS customer_id,
SUM(amount) AS trans_sum
FROM
transactions
WHERE
created_at >= CURRENT_DATE - INTERVAL '1 year'
GROUP BY
user_id
) o,
(
SELECT
customer_id,
SUM(amount) AS order_sum
FROM
orders
WHERE
created_at >= CURRENT_DATE - INTERVAL '1 year'
GROUP BY
customer_id
) t
WHERE
o.customer_id = t.customer_id
) combined
ORDER BY
total_volume DESC
LIMIT 100;
В качестве исключения можно вспомнить ситуацию (описана в статье про TLS) с Kernel TLS и HTTP/2, где HTTP/2 сильно проигрывал на сценарии отдачи больших файлов через SSL_sendfile()
С одной стороны сложно согласиться с ненужностью представлений (view). В проектах с ORM действительно нет view, либо их единицы.
С другой стороны применение view довольно простое: для ограничения доступа (создали view, добавили фильтр и выдали права пользователю, можно даже менять данные в колонках); хранение запросов, чтобы не дублировать код в десятках местах; просто спрятать большой запрос во view (например, гигантский merge с сотней колонок, часть с select уходит во view).
Вспоминаются старые инициативы (10-15 лет назад) про электронные учебники и планшеты: чтобы школьники не таскали с собой гору бумажных книг - уже тогда первые эксперименты давали противоречивые результаты.
Сразу приходит на ум Rust и паттерн проектирование NewType, где нужные инварианты поддерживаются типами данных и нет сотен проверок вначале каждой функции.
“16bit Sensation: Another Layer”
Не совсем компилятор. PL/SQL, встраиваемый язык Oracle DB.
В триггере после определённого количества (больше 4 или 5) начинаются игнорироваться return. Компилируется без ошибок и предупреждений, даже построчная отладка показывает, что return словно не существует.
Ворэраунд: не писать больше одного-двух return и использовать вложенные if.
И тега Rust нет.
Они превратили синтаксис Python в Rust! Сволочи!
Yay!.. - Fluttershy.
Потыкал эту поделку, сырая:
открыл json на 2.5 КБ, в простое жрёт 20% CPU;
нельзя сменить тип колонки, нельзя поставить null;
вкладка JSON, панелька “Поиск” - не нажимаются кнопки “Вперёд”/“Назад”/“Закрыть”.
https://habrastorage.org/r/w780/getpro/habr/upload_files/247/fd0/06f/247fd006f6aeea8988fd1260918a2112.webp
Про запросы вида ещё скажу что их сложно отлаживать.
Поэтому чаще всего вырастает в многоуровневый ужас внутри FROM:
Пару комментариев с стиле “было бы неплохо написать так”:
Кто-то узнал про реляционные СУБД?
Знаете, что мне всё это напоминает? 3D-принтеры. Когда покупают 3D-принтеры и начинают печатать предметы для 3D-принтера.
не описано
Они убили фокспро, сволочи!
С одной стороны сложно согласиться с ненужностью представлений (view). В проектах с ORM действительно нет view, либо их единицы.
С другой стороны применение view довольно простое: для ограничения доступа (создали view, добавили фильтр и выдали права пользователю, можно даже менять данные в колонках); хранение запросов, чтобы не дублировать код в десятках местах; просто спрятать большой запрос во view (например, гигантский merge с сотней колонок, часть с select уходит во view).
Современные СУБД довольно сильно оптимизируются запросы, так что проблема производительности обычно не стоит, стоит выдача гранулярных прав доступа и поддержка кода: https://javarush.com/groups/posts/423-kljevihe-optimizacii-sql-ne-zavisjajshie-ot-stoimostnoy-modeli-chastjh-5-
Живее всех живых. Но денег стоит.
del
https://priem-online.ru/all
Вспоминаются старые инициативы (10-15 лет назад) про электронные учебники и планшеты: чтобы школьники не таскали с собой гору бумажных книг - уже тогда первые эксперименты давали противоречивые результаты.
Спасибо за скриншот, меня стошнило.
Сразу приходит на ум Rust и паттерн проектирование NewType, где нужные инварианты поддерживаются типами данных и нет сотен проверок вначале каждой функции.
Опять 16-ти битный режим процессора x86… Всё жду, когда кто-нибудь напишет статью про запуск самодельного ядра ОС прямо из /EFI/BOOT/BOOTX64.EFI
Хотя нет, вот одна статья есть: https://habr.com/ru/articles/798587/