SQL Programming Macroprocessor – зачем он нужен??
Serguei_Tarassov опубликовал заметку SPM (SQL Programming Macroprocessor). Создайте свой проблемный язык – 2. С заголовком согласен на 100% – еще один язык над SQL – это создание проблем себе самому, хотя подозреваю под словами “проблемный язык” имелся ввиду язык для решения проблем.
Если посмотреть на разницу в коде между sqm и sql – то 90% кода совпадает. Зачем тогда городить огород из еще одного языка?
Только что бы вместо такого кода
IF EXISTS(SELECT * FROM sys.objects WHERE object_id = object_id(N'dbo.sales') AND objectproperty(object_id, N'IsUserTable') = 1)
DROP TABLE dbo.sales
GO
CREATE TABLE dbo.sales
писать одну команду DeclareTable(dbo.sales). Тем более что приведенные четыре строчки обычного копируются из ранее написанной процедуры и делается поиск и замена на нужное название.
Я соглашусь с использованием промежуточного языка для определения структур данных – это действительно удобно. Мы например просто определили формат для описания объектов в xml, и написали аж три xsl transformation stylesheets для oracle, mssql и mysql, это удобно не только для генерации кода, но и для поиска расхождений в базе и в модели.
Но для процедур? Как по мне это излишество. И ничего кроме десяти сэкономленных строк кода не даст.
Возможно это только начало. Примеры даны только для mssql, если бы код генерировался для нескольких баз данных – например для oracle и mssql – я бы обрадовался такому подходу. Кто-то решал это? Я сдался :) из-за oracle collections, оператора for x IN (…), exceptions и аналитических функций. (Глупо ориентироваться на самое слабое звено и использовать только те возможности которые есть у всех баз данных.)
Хотя справедливости ради скажу что и у нас процедурный код на Oracle “препроцессится” – точнее из разрозненных процедур генерируется код для заголовка пакета (интерфейс) и тело. Правда никакого макро-языка нет, а делает всё один простой скрипт на перле – которому дается имя каталога с процедурами и один создает интерфейс и код пакета.