SQL паттерн для однотипных колонок: как упростить запросы

При работе с таблицами, содержащими множество однотипных столбцов (например, val_01, val_02 … val_40), разработчики часто сталкиваются с проблемой избыточного кода. Каждый запрос требует перечисления всех 40 полей, что ведёт к ошибкам и снижает читаемость. Рассмотрим эффективные способы автоматизации: от использования макросов на C до динамического SQL и паттернов проектирования.

Почему однотипные колонки - это проблема?

Таблицы с десятками столбцов вида val_NN нарушают принципы нормализации баз данных. Они усложняют написание запросов, обслуживание схемы и масштабирование. Если вам приходится писать SELECT val_01, val_02, ..., val_40 FROM table, это сигнал к рефакторингу. Однако если изменить структуру данных невозможно, существуют обходные пути.

Способы обращения по паттерну в SQL

1. Динамический SQL

Большинство СУБД (PostgreSQL, MySQL, SQL Server) поддерживают динамическое формирование запросов. Например, в PostgreSQL можно использовать string_agg для сборки списка колонок из системного каталога:

SELECT string_agg(column_name, ', ') FROM information_schema.columns WHERE table_name = 'my_table' AND column_name LIKE 'val_%';

Затем полученную строку подставляют в EXECUTE. Это избавляет от ручного перечисления, но требует осторожности с инъекциями.

2. Макросы на C (при клиентской обработке)

Если вы пишете приложение на C, макросы препроцессора помогут генерировать повторяющиеся фрагменты. Например:

#define FOREACH_VAL(ACTION) ACTION(01) ACTION(02) ... ACTION(40)

Затем макрос разворачивается в нужный список. Этот метод ускоряет написание кода, но не влияет на сам SQL-запрос - он остаётся статическим.

3. Генерация запросов скриптами

Используйте Python, Bash или PowerShell для автоматического создания SQL-команд. Скрипт проходит по числам от 1 до 40 и формирует строку с колонками. Это особенно удобно при миграциях или создании отчётов.

Альтернативы: нормализация и EAV

Лучшее решение - изменить модель данных. Вместо 40 колонок создайте таблицу с тремя полями: id, param_name, param_value. Это подход Entity-Attribute-Value (EAV). Он позволяет обращаться к данным по имени параметра, а не по индексу. Запросы становятся проще: SELECT param_value FROM params WHERE param_name = 'val_15'. Недостаток - более сложные агрегации и возможные проблемы с производительностью.

Практические рекомендации

• Для разовых отчётов - используйте динамический SQL или скрипты-генераторы.
• Для постоянного кода - рассмотрите макросы на C, если архитектура это допускает.
• Для гибкости - рефакторинг в EAV или хранение данных в JSON-колонке (PostgreSQL, MySQL).
• Для производительности - избегайте динамического SQL в циклах, предварительно компилируйте запросы.

Вывод

Прямого паттерна val_## в SQL не существует, но комбинация динамического SQL, макросов и нормализации решает проблему. Выберите метод под свою СУБД и контекст: для быстрого прототипирования подойдёт генерация скриптами, для production - макросы или EAV. Главное - не мириться с повторяющимся кодом, а автоматизировать его.