То есть, используя временные таблицы с некоторыми исходными уникальными данными, а затем заполняя его одним или несколькими полями одновременно. Иногда это делает код более читабельным, но также приводит к процессуальному мышлению. И это также медленнее, чем использование производных таблиц или других методов. Это обескураживает в промышленности?
Неправильно ли использовать временные таблицы в SQL?
Ответ 1
Было бы плохой практикой, если бы все операции на основе набора были а) реализованы и б) эффективно во всех двигателях.
Однако для некоторых задач (например, для эмуляции LAG
и LEAD
в SQL Server
, длинные цепочки вставки при каскадной автогенерации id
- это несколько таблиц и т.д.), временные таблицы или переменные таблицы являются хорошим решением.
Следует отметить, что временные таблицы очень часто создаются и удаляются самим движком для операций с using temporary
в MySQL
, spool
в SQL Server
и т.д.
Поэтому каждый раз, когда вы создаете временную таблицу, задайте себе вопрос:
- Создать временную таблицу, потому что я не знаю способ, основанный на наборе, или потому, что я знаю метод на основе набора, но сервер (или оптимизатор) не работает?
Если ответ "Я знаю, но оптимизатор не работает", создайте таблицу. Оптимизатор будет делать то же самое, если это возможно.