А вот что пишет Клеппман
«Декларативные языки запросов весьма привлекательны … но что важнее, они скрывают подробности реализации ядра базы данных, благодаря чему у СУБД появляется возможность повышать производительность без необходимости вносить изменения в запросы.
Например, в показанном в начале данного раздела императивном коде список животных выводится в определенном порядке. Если базе данных понадобится незаметно вернуть в обращение неиспользуемое пространство на диске, то может возникнуть необходимость «перетасовать» записи, что приведет к изменению порядка вывода животных. Получится ли у базы сделать это безопасным образом, без нарушения работы существующих запросов?
Пример SQL не гарантирует конкретного порядка, следовательно, для него не важно, что порядок способен измениться. Но если запрос написан в виде императивного кода, то база данных не может быть уверена, важен ли порядок для кода. Функциональность SQL более ограничена, но это обстоятельство обеспечивает гораздо более широкие возможности для автоматической оптимизации.
Наконец, декларативные языки часто хорошо подходят для параллельного выполнения. Сегодня ускорение CPU происходит за счет добавления дополнительных ядер, а не повышения тактовой частоты. Распараллелить императивный код по нескольким ядрам и нескольким машинам очень непросто, поскольку в нем задается определенный порядок выполнения команд. Шансы декларативных языков на ускорение за счет параллельного выполнения выше, поскольку они задают лишь шаблон результатов, а не используемый для их получения алгоритм. База данных при желании может задействовать параллельную реализацию языка запросов »
Post #27
724
melikhov.dev Тут Артём развивает мысль, что оптимизации зачастую это попытка лечить последствия, а не причины. Если бы писали нормально, то никакие супер-пупер кэши и не понадобились бы (а как мы помним, кэши это вторая главная проблема программирования). А вот вам интересный…
- 👍 1