SergeiKitaev 25 июн 2022 в 17:19

Технология SQL-файл, препроцессор для T-SQL, “бок-о-бок” файлы и др

20 мин

MySQL*PostgreSQL*SQL*Microsoft SQL Server*Администрирование баз данных*

Комментарии 14

Tzimie 25 июн 2022 в 18:51

Я 25 лет работаю с MS SQL, но ни понял ничего. Что, зачем? Автор существует в каком то своем контексте

SergeiKitaev 1 авг 2022 в 14:40

Прояснение контекста

*** ПАРАМЕТРИЗОВАННЫЙ SQL НА БАЗЕ ФАЙЛОВ И СВОЙСТВ: ***

Чтобы было более понятно, о чём, собственно, ведётся речь в статье (а говорится в ней сразу о многом, и не только про реализованную форму SQL-файл), полагаю, что стоит выделить ключевую составляющую всех моих рассуждений. Название же для основной составляющей: Параметризованный файловый SQL. Это весьма полезная вещь, универсальное средство для усиления языка SQL на стороне клиенте. В противоположность параметризованному клиентскому SQL существует, так же (всем известно), динамический SQL, позволяющий формировать текст запроса на сервере.

Так вот, насчёт клиентской параметризации файлов. Описывая свойства в центральном месте проекта Вы, тем самым, влияете на все те файлы проектного дерева, которые зависят от соответствующих определений. Это могут быть константы, выражения, … (на усмотрение разработчика). Клиентская утилита/режим SQLCMD (от Microsoft) предлагает стандартный препроцессор для применения свойств трансляции файла, на базе переменных среды окружения в качестве параметров файлового скрипта. (Применяется известный универсальный способ определения свойств для процесса ОС.) Препроцессинг при этом осуществляется на клиенте. Однако, ничего конкретного явно не предлагается в MSSQL, чтобы эффективно и удобно формировать наборы свойств-параметров для трансляций параметризованного файла SQL посредством SQLCMD.

Для параметризованных файлов необходимо как-то подготавливать множество свойств-параметров. Чтобы в файловых запросах успешно работали вставки вида $(<Имя переменной>), обрабатываемые SQLCMD и SSMS в режиме SQLCMD (процессы ОС), необходимо наличие присвоенных ранее переменных окружения (т. е. нужно инициализировать именованные свойства-параметры). Для описания свойств трансляции подошли бы разные форматы; однако соответствующая инициализация должна, помимо простого присваивания (было бы крайне желательно), позволять внедрение условия (как поддержка отдельного и блочного условных присваиваний), а так же — возможность генерации ошибки с соответствующим сообщением.

Кустарная (Handicraft) реализация технологии SQL-файл активно использует возможности процессора Windows CMD, как для определения свойств-переменных, так и для построения сценариев простой и сложной трансляции. Язык командной строки адаптируется к SQL-файл посредством оснащения файлов CMD многочисленными вспомогательными процедурами по месту определения различных команд (избыточно присутствуют внутри соответствующих батч-ей).

Импорт сеттинг-ов SQL-файл является подобием подключения заголовочного H-файла определений в языке C.

Технология SQL-файл, использующая SQLCMD для трансляции скриптов, подготавливает соответствующее окружение на базе одного или нескольких сеттинг-овых CMD (см. далее, выделены жирным). Утилита $SQLTRANS “подхватывает” $sql_settings.cmd из текущей папки; файлы из подкаталогов SQL-проекта, как правило, наследуют (и, возможно, расширяют) сеттинг-и (окружение) более высокого уровня расположения. Корневой же (в проекте) $sql_settings.cmd подключает, как правило, SQLAUX.cmd (определения из каталога библиотеки SQLAUX), а так же @<имя_проекта>.cmd (сеттинг-и проекта в UTF-8). Запустив же SQL Server Management Studio (IDE для MSSQL) посредством стартера SSMS.cmd (располагается в корне SQL-проекта), данный процесс так же получает возможность использовать все тонкости настроенного окружения.

(Вышеприведённое относится к базовой части SQL-файл.)

*** БОК-О-БОК ФАЙЛЫ (C#/SQL И Т.П.): ***

Параметризованный файловый SQL реализуется в SQL-файл посредством утилит времени разработки. Если Вы строите приложение (веб-сервер) на классических ХП, функциях БД, представлениях данных и прочих объектах SQL программного (активного) характера (именуются программатик-ами), то, возможно, удобно будет располагать “рядом” (в одном каталоге) и SQL-составляющую веб-запроса (один или более файлов SQL) вместе с ключевым файлом запроса в проекте веб-сервера (CS и т. п.). Об этом, собственно, и рассказывается в пункте “III.1. Техника Side-by-Side (SQL/C#)” статьи. Для доступа же к процедурным ХП-запросам (со статусом результата @RStatus и результирующим сообщением ошибки @RMessage, происходящим непосредственно и явно из кода SQL запроса) применяется специальный чисто экспериментальный псевдо-микро-ОРМ к подобным запросам.

*** SQL-FILE-APP. (ФАНТАСТИКА): ***

Кустарная (Handicraft) технология SQL-файл предлагает утилиты (и среду) времени разработки. Однако, ничто не мешает реализовать применение параметризованного файлового SQL и для запросов приложения (не ХП). Такие запросы, так же, хочется исполнять эффективно, сравнимо по временным затратам с обращением к ранее подготовленной SQL-сервером ХП. Посему возникает идея поддержки т. н. преподготовленных временных запросов SQL. См.п. III.2., то, что идёт под надписью “Непростая идея компилируемых запросов SQL:”. Что касается MSSQL, то для проверки запроса на предмет ошибки (без исполнения), существует соответствующая настройка: set NOEXEC on. Имеются в Transact-SQL так же (есть возможность для задействования) и временные хранимые процедуры: #<Имя временного запроса>, ##<Имя временного запроса>.

Однако, насчёт т. н. “Compiled SQL Queries”, — идея состоит не в том, чтобы приспособиться к одному лишь конкретному диалекту SQL. Предлагается (для начала на теоретическом уровне) унифицировать так называемый заголовок SQL-запроса (т. е. обрисовать достаточно универсальный его формат): с параметрами, кодом возврата, статусом результата, результирующим сообщением ошибки, резалт-сет-ами и подобное. Ежели в двух разных диалектах SQL (СУБД) применяются подобные заголовки, то код запросов веб-сервера, содержащий обращения к SQL-запросам (не сам SQL) будет практически (почти всегда) одинаковым. Перевод же веб-сервера с одной такой СУБД на другую должен выражаться лишь в переписывании имплементирующего содержимого SQL-запросов (что размещаются в параметризованных свойствами проекта/приложения файлах SQL), с сохранением унифицированных заголовков SQL. Т. е. “предлагается”, так скажем, частичная кроссплатформенность, где исправлению подлежит лишь side-by-side SQL (с сохранением заголовков). Такая вот фантастика: компилируемые запросы приложения (с унифицированными заголовками), а так же параметризованный файловый SQL (на базе свойств проекта/приложения), — моё универсальной видение частичной унификации SQL.

*** P.S.: ПРИМЕР SIMPLE SCRIPT (HELLO): ***

Для первоначального понимания идеи SQL-файл предлагается ознакомиться со специально подготовленным примером т. н. простого скрипта Simple script (Hello): “HandicraftSDK\SQL\Programming samples (SQL-file)\Simple script (Hello)”, наряду с другими (простыми и сложными) примерами. (См.: “HandicraftSDK\SQL-project-list.txt”, “Handicraft_Toolkit_YYYYMMDDx\SQL-projects-sum.txt”.)

Так же, смотрите: *** P.S.: SIMPLE SCRIPT (HELLO): *** (в окончании статьи). В скриншот-ах SQL на страницах Handicraft, данный пример располагается в самом начале 1-го подмножества (соответствующие 4 ссылки с прокруткой выделены жирным): https://handicraft.remelias.ru/sdk/sql/screenshots_1.html (SQL-file screenshots-1).

Всего доброго!

vagon333 25 июн 2022 в 19:00

Вероятно, вы глубоко в своей задаче и позабыли, что пользователь не курсе проблемы.
Какую проблему вы решаете в этой статье?

SergeiKitaev 30 июл 2022 в 13:15

Добрый день!

После небольшой доработки материала (SQL-файл, Handicraft-SDK, домен https://handicraft.remelias.ru/, данная статья) отвечаю на Ваш вопрос.

Во-первых, был добавлен новый пункт (статьи): *** P.S.: SIMPLE SCRIPT (HELLO): *** (См. окончание статьи.) См. так же: https://handicraft.remelias.ru/sdk/sql/screenshots_1.html (SQL-file screenshots-1), — первые 4 пункта списка (выделены жирным), посвящённые примеру Simple script (Hello).

Во-вторых, что касается, как Вы говорите, решаемых проблем, то таковых стоит отметить по крайней мере две:

I. Ограниченность и неполноценность взаимодействия с SQL-сервером через фирменную консоль. Дело в том, что база данных не столь удачно подходит в качестве первичного хранилища исходных скриптов. Файлы, организованные внутри проекта, — гораздо более пригодное место для сохранения и применения исходников.

II. Касательно контроля отработки инструкций Transact-SQL на предмет ошибки. Речь идёт об унаследованном от самых ранних версий MSSQL (в ту пору, когда в языке ещё не существовало поддержки исключений) режима, применяемого в качестве режима по умолчанию и по сей день. Т. е. это (как 2-я проблема) — ненадёжность (“неудобство”) языка Transact-SQL в плане обработки ошибок, — обременительный (в режиме по умолчанию) Control Flow, выражающийся в необходимости проверки @@ERROR везде-везде. Для решения проблемы была придумана обёртка основного блока запроса, в виде раскрывающихся слов: $(BEGIN_AUX) и $(END_AUX) (см. далее). Помимо внедрения в скрипт основного перехватчика исключений, определение $(BEGIN_AUX) так же добавляет кое-какие установки SQL; см. $(BEGIN_AUX) macro in DB (preprocessing result).

Вот пример того, как раскрывается обёртка основного блока:

ИСХОДНЫЙ СКРИПТ (SQL-ФАЙЛ):
[[
$(BEGIN_AUX)
-- ТЕЛО ЗАПРОСА:
: : : : :
$(END_AUX)
]]

СКРИПТ ДЛЯ ИСПОЛНЕНИЯ СЕРВЕРОМ SQL:
[[
begin set xact_abort off; set ansi_nulls,ansi_null_dflt_on,quoted_identifier,arithabort,nocount on; set implicit_transactions off; declare @initial_tran_count_aux int, @is_local_tran_open_aux bit; select @initial_tran_count_aux=@@trancount, @is_local_tran_open_aux=0; begin try
-- ТЕЛО ЗАПРОСА:
: : : : :
if @is_local_tran_open_aux=1 raiserror ('Not closed local transaction was detected, previously opened by BEGIN_TRANSACTION_AUX macro.',11,1); end try begin catch if @is_local_tran_open_aux=1 and (@@trancount>@initial_tran_count_aux or xact_state()=-1) rollback transaction; set @is_local_tran_open_aux=0; throw; end catch; end
]]

Основная цель SQL-файл (реализованная для MSSQL) — это создание+подборка программной среды на клиентской машине, которая позволяет редактировать и исполнять усиленный (снабжённый вспомогательными определениями-словами/константами, а так же хелпер-объектами в БД) язык SQL на базе файлов автономного SQL-проекта, как первичного места (в файлах) для хранения и применения исходного кода: параметризированный T-SQL + сеттинг-и на базе файлов CMD. Использование специального SQL-окружения проекта позволяет извлекать выгоду от интенсивного применения стандартных (от MS) возможностей препроцессора SQLCMD. Технология SQL-файл включает так же скриптовую библиотеку SQLAUX (определения-слова/константы + объекты БД). Для конфигурирования SQL-проекта, создания простых и сложных команд, прилагается, как основа для нового проекта, множество примеров с соответствующими сценариями-заготовками на базе процессора Windows CMD. Язык командной строки также (подобно усилению для T-SQL) адаптирован к SQL-файл, посредством оснащения многочисленными вспомогательными процедурами по месту определения различных команд (избыточно присутствуют внутри соответствующих батч-ей).

Основное (I-е) назначение (направление применения) SQL-файл — это, в первую очередь, поддержка обычной хозяйственной рутины, заключающейся в необходимости проведения, возможно повторяющихся через какое-то время (с небольшими, однако, отличиями) структурных модификаций БД и/или коррекций, собственно, самих табличных данных. Поскольку весь код модификации/коррекции БД сохраняется в проекте SQL-файл, то подобную процедуру не так сложно будет повторить с небольшими изменениями, к примеру, скажем, через месяц, и/или применить модификацию/коррекцию уже к другому экземпляру БД.

Так же, как II-е основное направление, Вы можете использовать технологию SQL-файл для создания (и поддержки) программной подсистемы в БД; например, как часть приложения (и не только). Подобная БД-составляющая приложения представлена, как правило, набором хранимых процедур, скалярных и табличных функций БД, а так же, быть может, списком представлений (и не только это). Вышеупомянутые типы объектов в SQL-файл называются программатик-ами. Сами объекты именуются обычно (за исключением, разве что, представлений) с использованием одинакового (для всех объектов приложения) префикса, чтобы, помимо прочего, иметь возможность зачищать (удалять из базы) сразу целое подмножество хранимых (скомпилированных ранее из файлов) скриптов БД. Трансляция же файловых исходников (объекты поддержки приложения) в базу данных может предваряться одной из соответствующих зачисток множества; она может осуществляться по отдельному файлу / объекту, а так же для группы файлов (по типу объекта, например), или же целиком по всем программатик-ам приложения; и т. п.

Для первоначально понимания идеи SQL-файл предлагается ознакомиться со специально подготовленным примером т. н. простого скрипта Simple script (Hello): “HandicraftSDK\SQL\Programming samples (SQL-file)\Simple script (Hello)”, наряду с другими (простыми и сложными) примерами. (См.: “HandicraftSDK\SQL-project-list.txt”, “Handicraft_Toolkit_YYYYMMDDx\SQL-projects-sum.txt”.)

Всего доброго!

qwertEHOK 26 июн 2022 в 11:43

ну прочтите внимательно же)

автор реализовал приложение на C# для обработки файлов .sql на стороне клиента плюс какое то расширение функционала самого sql

но конечно с примерами беда

SergeiKitaev 27 июн 2022 в 19:05

Добрый день!

*** ПО ПОВОДУ ПРИМЕРОВ. ***

Стоит заметить, что любой файл .SQL из загрузок (а так же: .CMD, .LIST, .TXT) является, в каком-то смысле, небольшим примером.

Примеры, как таковые, располагаются в следующих местах:

= I.=
— В ЗАГРУЗКАХ: например “Handicraft_Toolkit_20210910.7z” (комплексная):
Там имеется файл-описатель: “HandicraftSDK\SQL-project-list.txt” (основные примеры):
[[
List of SQL-projects in Handicraft-SDK (SQL-file technology)

Project folders (with root "$sql_settings.cmd"):

1) HandicraftSDK\SQL\SQLAUX\Source;

2) HandicraftSDK\SQL\Programming samples (SQL-file)\**;

3) HandicraftSDK\SQL\Extralight-ORM test legacy sample (En+Ru)\MyFlat app. (MVC_Razor+TS+ADO+TSQL)\SQL (DB-modelling).

— — —
]]
— А ТАК ЖЕ, В РАСШИРЕНИИ ПРИМЕРОВ (эксперимент Client-Server.WEB):
“BookRegistry\SQL (DB-modelling)\**” (SQL, CMD) и “BookRegistry\SHARED\$ClientServer\!DB-queries (application SP)\**” (CS+SQL).
(см. так же: https://handicraft.remelias.ru/csweb/client_server_web.html)

= II.=
— В БАЗЕ ДАННЫХ [TEST], ДОСТУПНОЙ ДЛЯ “ПОДНЯТИЯ” ЛИБО ПОДКЛЮЧЕНИЯ:
Файл “TEST (DB)!DB-info.txt”:
[[
Test database for BookRegistry and MyFlat sample applications

=== Content (files): ===

1) TEST 2021-08-25.BAK — MSSQL-backup file;

2) TEST 2021-08-25\TEST.mdf — main data-file;

3) TEST 2021-08-25\TEST_log.ldf — database log-file.

Microsoft SQL Server 2017 (140)+
SQL-Server database:
– compatibility level: Microsoft SQL Server 2017 (140);
– collation: Cyrillic_General_CI_AS;
– name: TEST (DB logical names: TEST, TEST_log).
]]
Там же, в папке “TEST (DB)”: “TEST 2021-08-25.BAK”, “db_restore.sql”, “db_attach.sql” и др.
В БД, однако, можно увидеть (посмотреть SQL) лишь оттранслированные объекты, с развёрнутыми исходными переменными окружения $(<Имя переменной>).

= III.=
— В МНОГОЧИСЛЕННЫХ КАРТИНКАХ (СКРИНШОТ-Ы), ЧУДЕСНЫМ ОБРАЗОМ ЗАМЕНЯЮЩИХ МНОЖЕСТВО СЛОВ:

https://handicraft.remelias.ru/sdk/sql_file.html#screenshots
https://handicraft.remelias.ru/sdk/sql/screenshots_1.html
https://handicraft.remelias.ru/sdk/sql/screenshots_2.html
https://handicraft.remelias.ru/sdk/sql/screenshots_3.html
(см. также: https://handicraft.remelias.ru/sdk/sql_file.html,
https://handicraft.remelias.ru/sdk/sql_tools.html и
https://blog-hc.remelias.ru/)

https://handicraft.remelias.ru/csweb/screenshots/dev_screenshots.html
https://handicraft.remelias.ru/csweb/screenshots/dev_screenshots_sql.html
(см. так же: https://handicraft.remelias.ru/csweb/client_server_web.html;
https://blog-hc.remelias.ru/client-server-wasm-application-in-cs-typescript-and-t-sql/,
https://www.c-sharpcorner.com/article/client-server-wasm-application-in-c-sharp-typescript-and-transact-sql/)

*** НАСЧЁТ РЕАЛИЗОВАННЫХ ИДЕЙ: ***

= I.=
Основная идея SQL-файл очень простая: запускать (исполнять скриптовый код на SQL-сервере) сконфигурированные SQL-файлы, снабжённые настраиваемым окружением различной сложности. Т.е., выбрал с помощью пульта файл-команду (SQL либо CMD), нажал кнопку запуска — увидел консоль исполнения с выводом и/или, возможно, просмотрел отчёт-вывод в файле .TXT. Файлы CMD, кстати, нормально запускаются и из Windows Explorer, по двойному щелчку мыши. (Т.е. не обязательно везде задействовать Far Manager.) Дерево исходников — это всегда такой маленький (или средний по размеру) автономный SQL-проект, с существенной составляющей от слова конфигурация (или сеттинг-и). При таком подходе (SQL в файлах) бывает, как правило, критически важен порядок обработки последовательности этих файлов. Так же, иметь возможность исполнять отдельный файл, обрабатывать подгруппу, большую группу, производить составные трансляции (с задействованием сценария), — становится просто необходимо.

= II.=
Ещё одна идея — снабдить основной блок перехватчиком исключений, посредством ключевых макро-слов: $(BEGIN_AUX) и $(END_AUX), что позволяет уйти (не использовать) от того безумного Control Flow (при отсутствии перехвата исключений, с проверкой @@ERROR везде-везде), доставшемуся T-SQL по наследству от самых старинных версий MSSQL.

= III.=
В некоторых случаях, однако, нет возможности применять какие-либо специальные утилиты. Вы передаёте т.н. дилеру SQL-скрипт(ы), предназначенный(ые) для разворота или обновления SQL-кода удалённой подсистемы. (Т.е. у Вас нет доступа к БД.) Дилеру доступны только стандартные инструменты, как правило SQL-Server Management Studio (и всё). Для подобного случая возможно (аккуратно, с проверками у себя на месте) подготовить для него развёрнутый(ые) скрипт(ы) с учётом Вашей конфигурации, — используя функцию т.н. сильного препроцессинг-а. Например, библиотека SQLAUX может быть отправлена дилеру в виде одного “развёрнутого” (все объекты, с учётом Environment SQLAUX) файла: “HandicraftSDK\SQL\SQLAUX\Source$OUTPUT\sqlaux_library.sql” (тут есть и удаление и создание и, даже, кое-где, наполнение таблиц).
Сильный препроцессинг, вообще-то, небезопасен, поскольку проблематично запрограммировать обработку директивы :SetVar с учётом комментариев, строковых литералов и разделителя батч-ей GO с точно таким же поведением (во всех мелочах), как у SQLCMD.
Обычный же, слабый препроцессинг необходим лишь для устранения эффекта сбоя диагностики номера строки, присутствующего у SQLCMD за счёт необдуманного “съедания” в отправленном на SQL-сервер скрипте строки с директивой :SetVar. Кстати, для :setvar (строчными буквами) или же :SETVAR (заглавными), препроцессинг вообще не должен задействоваться. (Для :SetVAR дублирование вида --:SetVAR … будет производиться всегда, без анализа того, комментарий ли это /*…*/, строковый литерал, или же обычный фрагмент SQL-кода.) Препроцессинг, собственно, является встроенной функцией SQLCMD, и не стоит сильно “отрываться” от этого замечательного инструмента, режим которого поддерживается (при включении настройки) так же и в IDE SSMS. В наименовании же утилиты SqlCatPP (EXE) слово Preprocessor (“PP”) идёт после слова Catenation (“Cat”). Основная его функция это, всё-таки — сцепление нескольких SQL-файлов (как правило имеющих разделитель GO) для передачи большого слитного скрипта утилите SQLCMD, которая, в свою очередь, обработав его стандартным образом, уже отправит окончательные пакеты-батч-и на SQL-сервер.

= IV.=
SQL-файл возможно задействовать как минимально, так и с интенсивным обращением к расширениям.
Можно не подключать библиотеку SQLAUX, не ссылаться в пользовательском скрипте на раскрывающиеся её слова вида $(…_AUX).
Возможно, напротив, использовать кое-что из коллекции оттранслированных (посредством, например, “HandicraftSDK\SQL\SQLAUX\Source\translate_programmatics.cmd”) в пользовательскую БД вспомогательных программатик-ов, таких как “AUX:DropProcedure”, “AUX:ToString.Int”, “AUX:IsInServerAdminRole” (см. “HandicraftSDK\SQL\SQLAUX\API (headers)\Programmatics.AUX.txt”; см. https://handicraft.remelias.ru/sdk/sql_file.html#sqlaux_programmatics).
Из файла сеттинг-ов “$sql_settings.cmd” (папка “SQLAUX\Source”):
[[
: : : : :
set $sql_server=(local)
set $sql_database=TEST
: : : : :
]]
(Потребуется указать пользовательскую БД.)

= V.=
Помимо, собственно, SQL-файл, в статье присутствуют идеи, относящиеся к экспериментальным и теоретическим.
— См. “Client-Server.WEB (idea)”: https://handicraft.remelias.ru/csweb/client_server_web.html;
— Последняя перед заключением большая часть статьи, представленная номером III:
III. Небольшая попытка создания экспериментальной псевдо-микро-ORM для доступа к своим SQL-запросам и ХП, бок-о-бок файлы (SQL/C#) и прочее:
III.1. Техника Side-by-Side (SQL/C#);
III.2. Зачем всё это нужно (или же почему не всё так складно в ORM)?

*** ФОРМИРОВАНИЕ ТЕХНОЛОГИИ SQL-ФАЙЛ: ***

Когда-то, имея дело с ранними версиями Microsoft SQL Server, автор статьи долго испытывал удивление по поводу того, насколько ненадёжно (“неудобно”) устроен язык Transact-SQL в плане обработки ошибок. Так же, работа с запросами, их редактирование непосредственно в БД посредством графической консоли (хранимые процедуры, функции, триггеры и т.п.), — всё это было и остаётся весьма далёким от совершенства. После многолетнего удивления возникла (постепенно сложилась) технология SQL-файл, позволявшая держать скрипты в директориях и файлах (и применять их непосредственно оттуда). Каждый скрипт в SQL-файл всегда должен располагаться в правильном месте, с соответствующими настройками окружения проекта / каталога. Такой, казалось бы, более трудоёмкий подход позволяет, однако, эффективно воссоздавать сохранённые подсистемы, вносить коррекции, применять скрипты (массово и по отдельности) к другим экземплярам БД. Поскольку проект в SQL-файл — автономный (не нуждается в SSMS), ему потребуются редактор(ы) и пульт для исполнения команд, коих предвидится немало. Посему, как самый совершенный из файловых командеров, был выбран Far Manager (в качестве основного пульта для SQL-файл). (Примечательно, что в Америке нет моды на командеры; каждый вендор ПО пытается либо предложить своё собственное исполнение для IDE, либо осуществить интеграцию в фирменную IDE.) Возможности Far Manager позволяют использовать его как универсальную IDE, в данном случае для автономного проекта, с применением так же и дополнительного расширенного GUI-редактора SQL (вызывается для .SQL из панели по <Shift+Enter>). В SQL-файл нет какого-то ярко выраженного особо-центрального элемента. Все компоненты в определённой степени важны и работают в комплексе, однако не все её средства обязательны для применения. (Использование технологии чем-то похоже на применение конструктора вокруг множества файловых SQL-скриптов, для обслуживания подсистемы внутри БД.) С помощью SQL-файл, в первоначальных её представлениях, в течение долгого времени поддерживались (в прошлом) базы данных для расчёта квартирной платы в городе Воронеж.

Спасибо за внимание и Ваш отзыв!

Mikluho 26 июн 2022 в 14:21

Уважаемы автор! В этой статье, написанной в стиле прошлого столетия, вы забыли главное - рассказать о том, что заявлено в заголовке: "Технология SQL-файл".
Есть отдельные кусочки описания, но понять, что же такое на самом деле, прочитав статью, невозможно. При этом вы много ~~рассказываете про~~ перечисляете используемые командеры, хелперы, эксперименты, собственные статьи...

Но где сам "SQL-файл?
Хоть бы один пример такого проектика? С описанием задачи, решаемых проблем...
А то, всё, что есть, это фраза, где-то в цитате, "Идея состоит в том, чтобы поддерживать исходный код и/или вспомогательные скрипты в виде SQL-файлов в директориях, транслируя их в базу данных, по отдельности либо группами. "

Если ваш "SQL-файл" - это хиленький препроцессор и cmd для выполнения скриптов БД, то не понятно, а что в нём интересного, кроме кучи устаревших подходов?
Кодогенерация - так есть куча альтернатив (и они сильно мощнее простенького препроцессора). Апдейт базы - так есть миграции (и это не обязательно ORM). Редакторы кода - тем более. И всё это нормально дружит с git и devops, что сильно снижает трудозатраты и риск ошибки...

Иначе говоря, скажите, какую проблему решает ваша технология, которую (проблему) не решают другие популярные современные решения.

SergeiKitaev 27 июн 2022 в 19:41

Добрый вечер!

*** О ТОМ, ЧТО ЗАЯВЛЕНО В ЗАГОЛОВКЕ: ***

Заявлено и в заголовке статьи и в названии технологии, — ничего возмутительного; самые, казалось бы, естественные вещи присутствуют в SQL-файл.
В своём ответе на предыдущий комментарий “ну прочтите внимательно же) … но конечно с примерами беда” от qwertEHOK 26.06.2022 в 11:43 автор приводит разъяснения: “ПО ПОВОДУ ПРИМЕРОВ”, “НАСЧЁТ РЕАЛИЗОВАННЫХ ИДЕЙ”, “ФОРМИРОВАНИЕ ТЕХНОЛОГИИ SQL-ФАЙЛ” (см. выше).
Идея предельно проста: хранить исходный код в правильно организованной директории на клиенте; там же его редактировать, оттуда его и применять (транслировать скрипты в БД). Это очень просто на словах. В реальности же всё оказывается нетривиально: много команд (простая / составная трансляция); обработать отдельный файл / группу () / большую группу; определение собственных раскрывающихся слов / констант $(<Имя переменной>); организация порядка трансляции; расположение файлов в папках дерева. Автор не утверждает, что всё решается идеально. Эта небезупречная реализация, однако, действительно позволяет поддерживать подсистему внутри БД, опираясь на файлы, как исходное место для усиленного SQL (создание/удаление табличной структуры, хранение кода ХП, функций, представлений, триггеров). В базе данных на самом деле — не совсем-таки исходники, а фрагменты скриптов с учётом сеттинг-ов (с уже раскрытыми переменными пользовательского проекта / каталога / трансляции). Для нормальной коррекции такого скрипта необходимо править исходный SQL-файл и применять его. Т.е. стандартная графическая консоль для доступа в БД используется по минимуму (как правило не для правки того, что присутствует в файлах).

Вот пример того, как раскрывается обёртка основного блока:

ИСХОДНЫЙ СКРИПТ (SQL-ФАЙЛ):
[[
$(BEGIN_AUX)
-- ТЕЛО ЗАПРОСА:
: : : : :
$(END_AUX)
]]

*** ГДЕ НАХОДИТСЯ САМ SQL-ФАЙЛ: ***

SQL-файл располагается в директории-проекте (рядом с другими с SQL-файлами) у разработчика / администратора. Проект снабжается сеттинг-ами “@sql_settings.cmd”. Корневые сеттинг-и, часто ссылаются на настройки проекта “@<Имя проекта>.cmd” (в кодировке UTF-8). “@sql_settings.cmd” из подпапки проектного дерева обычно ссылается на “@sql_settings.cmd” более высокого (директория выше) уровня и иногда дополняет/модифицирует родительские сеттинг-и.

*** “ХИЛЕНЬКИЙ ПРЕПРОЦЕССОР”: ***

Как было сказано в ответе на предыдущий комментарий, функция слабого препроцессинг-а нужна, прежде всего, чтобы устранять сбой диагностики номера строки, присущий SQLCMD за счёт т.н. “съедания” директивы :SetVar стандартным препроцессинг-ом (в SQLCMD). Сильный же препроцессинг требуется лишь в особых случаях и содержит элемент риска (эта функция появилась в SQL-файл последней и ещё недостаточно опробована). Как говорится в соответствующем разъяснении, препроцессинг — не главное, в отличие от конкатенации группы исходников (снабжённых, как правило, разделителем GO). Смотрите ответ автора на предыдущий пользовательский комментарий.

*** ПРОБЛЕМЫ, РЕШАЕМЫЕ SQL-ФАЙЛ: ***

Смотрите ответ автора на предыдущий пользовательский комментарий: “НАСЧЁТ РЕАЛИЗОВАННЫХ ИДЕЙ” и др. В общих словах можно кратко обозначить две грустные особенности касательно взаимодействия разработчика с SQL:

1) — Ненадёжность (“неудобство”) языка Transact-SQL в плане обработки ошибок, — обременительный (в режиме по умолчанию) Control Flow, выражающийся в необходимости проверки @@ERROR везде-везде. Для решения этой проблемы была придумана обёртка основного блока запроса, в виде раскрывающихся слов: $(BEGIN_AUX) и $(END_AUX) (см. выше).

2) — Ограниченность и неполноценность взаимодействия с SQL-сервером через фирменную консоль. База данных не столь удачно подходит в качестве первичного хранилища скриптов. Даже если Вы их уже извлекли из БД и храните в системе управления версиями, что это означает? Как быть с клиентским окружением SQL-проекта; где оно тогда присутствует с доступностью для исправления, влияющего на множество скриптов? Где определяются трансляции файловых групп (для соответствующих SQL-объектов): множества файлов, их порядок обработки, команды применения?

*** В ДУХЕ ПРОШЛОГО СТОЛЕТИЯ; КУЧА АЛЬТЕРНАТИВ И Т.П.: ***

Не совсем понятно, к чему здесь сравнение с прошлым столетием. Если так уж не нравится применение в статье абстракций (трансляция SQL, поддержка скриптов на файловой базе, программатик-и, сеттинг-и проекта / каталога / трансляции, настройки окружения, и т.п.), то всем этим терминам соответствуют вполне реальные вещи. Да и сам SQL, кстати, появился ещё в прошлом столетии. Только в отличие от большинства языков программирования, где принято использовать непосредственно файлы, в языке SQL в силу, быть может, присущей СУБД её серверной локации, клиентская составляющая не получила достойного развития. И вообще, всё, что придумывается, например электронная почта (в том виде, как мы её знаем), обретёт весьма отличное устройство, исполнение, терминологию и понятия, будь оно создано, к примеру, на другом континенте и / или же другими людьми.

Насчёт альтернатив. В мире есть огромное количество всякого полезного добра. Однако, несправедливо отрицать результаты, полученные автором в ходе выработки и практического использования технологии SQL-файл на основании лишь того, что полезное добро повсюду успешно применяется. Существуют продукты, предназначенные для облегчения разработки в SQL, на которые SQL-файл чем-то (быть может) похожа по своему назначению. Однако, автору не известно конкретно ни одной штуковины, которая бы совпадала или существенно превосходила SQL-файл в плане полноценного программирования в SQL, ориентированного первично (т.е. изначально — скрипты) на файловую базу для размещения и правки исходников. И это, в результате (у автора), т.н. “кустарная” (handicraft) технология SQL-файл (в её текущем исполнении), — конструктор SQL-проектов, автономный, настраиваемый / расширяемый, с поддержкой простых командных сценариев, со средней степенью интеграции с редакторами и командными пультами.

Всего доброго!

HomeDimoN 29 июн 2022 в 14:10

эээ
система сборки MSSQL базы и приложения на C# .NET?
и без системы контроля версии? (номер версии тоже должен быть в базе)
и без обратного преобразования из базы в проект?

Пример бы поменьше… из 2-3 табличек + вьюх + процедур

SergeiKitaev 14 июл 2022 в 11:17

*** НАСЧЁТ СБОРКИ (БАЗА И ПРИЛОЖЕНИЕ): ***

Многие ключевые величины прописываются (т. е. хранятся изначально) в SQL-сеттинг-ах, а именно в файле “@<наименование sql-проекта>.cmd” (UTF-8): номер(а) версии, размеры (scale), точности (precision), ограничения (restriction) и т. п. Например (для проекта “MyFlat app.”) задействуется файл “@flat_owner_cabinet.cmd” (подключается из “$sql_settings.cmd”):

[[ : : : : :

:: SIZE PARAMETERS OF DATA TYPES: set num_UnitsPrecision=19 set num_UnitsScale=4 set num_UnitsEpsilon=0.0001 set num_SquarePrecision=19 set num_SquareScale=4 set num_SquarePrecision_2=17 set num_SquareScale_2=2 set num_CoefficientPrecision=!num_MPDecimalPrecision_AUX! set num_CoefficientScale=!num_MPDecimalScale_AUX! set num_UnitsStrMaxLength=21 set num_SquareStrMaxLength=21 set num_SquareStrMaxLength_2=19 set num_CoefficientStrMaxLength=!num_MPDecimalStrMaxLength_AUX! set num_AccessCodeMaxLength=15 set num_TinyNameCapacity=15 : : : : :

:: SIZES OF SOME VALUES: set num_BuildingNoMaxLength=7 set num_FlatNoMaxLength=20 set num_AccountCodeDigits=10 set num_MaxAccountCode=9999999999 set num_TechsubdivCodeDigits=4 set num_MaxTechsubdivId=9999

: : : : : ]]

Импорт сеттинг-ов SQL-файл напоминает подключение заголовочного H-файла в языке C.

Так же, в SQL-проекте может присутствовать команда “generate_metadata.cmd” (и одноимённые файлы .PROPS/.TARGETS), генерирующая на базе SQL-сеттинг-ов маленький промежуточный C#-исходник “DBConstants.auto.cs” (реализуется посредством MSBUILD-задачи WriteLinesToFile). Таким образом сеттинг-и являются не только параметрами для SQL-исходников проектного дерева (учитываются как переменные среды при трансляции SQL-файлов в БД утилитой SQLCMD, стандартный препроцессинг от MS), но так же и попадают в бинарные EXE/DLL соответствующей программы или программ.

База данных — не столь подходящее место для прописывания в ней ключевых констант и значений сборки. Нечто, подобное межплатформенным (универсальным) текстовым заголовочным/сеттинг-овым файлам, могло бы представлять более удачную альтернативу для задания величин, нацеленных на учёт сразу в нескольких разнородных программах. В текущем же “кустарном” (handicraft) исполнении SQL-файл используется старинный универсальный подход с переменными Environment (на базе файлов CMD).

*** ПО ПОВОДУ Т. Н. ОБРАТНОГО ПРЕОБРАЗОВАНИЯ: ***

Обратное преобразование (БД => файлы SQL) не обладает возможностью для восстановления всей сложной картины оригинальных исходников. Подобное можно сравнить с попыткой получить (вернуть обратно) оригинальный исходный TypeScript из траспилированного JS.

*** ПЕРЕЧИСЛЕНИЕ ПРИМЕРОВ И ИСХОДНИКОВ SQL-ФАЙЛ: ***

Основные примеры SQL-файл (из загрузки “Handicraft_Toolkit_20210910.7z”):

1) “HandicraftSDK\SQL\SQLAUX\Source”;

2) “HandicraftSDK\SQL\Programming samples (SQL-file)\**”;

3) “HandicraftSDK\SQL\Extralight-ORM test legacy sample (En+Ru)\MyFlat app. (MVC_Razor+TS+ADO+TSQL)\SQL (DB-modelling)”.

Содержимое директории “Programming samples (SQL-file)” — вложенные папки (примеры простейших микро-проектов SQL):

1) “GUID-list generation”;

2) “Lists downloading (sys-info)”;

3) “Nested transaction test”;

4) “Trigger test”;

5) “Uploading to DB (used buildings)”.

Дополнительный пример из “BookRegistry app.” (две “разнесённые” папки):

1) “BookRegistry\SQL (DB-modelling)\**” (SQL, CMD);

2) “BookRegistry\SHARED\$ClientServer\!DB-queries (application SP)” (CS+SQL).

*** SQL-ФАЙЛ КАК КОНСТРУКТОР (ССЫЛКА-ПОСТ): ***

https://blog-hc.remelias.ru/sql-file-as-constructor/

— Компоненты SQL-файл;

— Системные зависимости SQL-файл;

— Перечисление ключевых слов Усиленного T-SQL (из файла “#SQL_extensions.AUX.sql”).

SergeiKitaev 14 июл 2022 в 17:00

*** PS: НАСЧЁТ СБОРКИ (БАЗА И ПРИЛОЖЕНИЕ): ***

У Microsoft имеется XML-формат для универсального определения зависимых друг от друга свойств, — это файлы .PROPS, работающие совместно с .TARGETS (платформа сборки MSBUILD). Собственно свойства (Properties, статические значения) задаются в теге <PropertyGroup>, а элементы (Items, входные наборы файлов и папок на обработку) — в теге <ItemGroup>. MSBUILD позволяет так же (в файлах .TARGETS) определять сценарии для достижения определяемых Вами, зависимых друг от друга целей (Target).

*** РАЗМЫШЛЕНИЯ ПО ПОВОДУ РЕАЛИЗАЦИИ SQL-ФАЙЛ: ***

Однако, размышляя насчёт более серьёзной (от слова по взрослому) реализации SQL-файл, автор статьи не склонен к задействованию MSBUILD, известных командных оболочек (PowerShell, Bash), равно как и применению стандартной (в MSSQL) утилиты SQLCMD для осуществления трансляции файлового SQL.

Для наиболее полноценного воплощения технологии потребуются (как минимум):

1) Выработка специального текстового (файлы) формата сеттинг-ов (подключаемые свойства-параметры для файлового SQL), а так же — формата командных сценариев комплексной трансляции SQL (описание последовательности шагов);

2) Возможность задействования при этом (в сценариях SQL-трансляции) широко известного скриптового языка (например JS, движок вне браузера);

3) Интеграция с популярным(и) редактором(ами) программного кода, таким(и) как IDE VS Code (например), с целью достижения эффекта автодополнения идентификаторов редактируемого кода, с т. н. “равнением” на коллекцию имён из файлов SQL-проекта (SQL + все подключенные сеттинг-и), а так же — и на коллекцию имён из основной БД;

4) Поддержка (клиентом и/или сервером) т. н. “Компилируемых временных запросов SQL”, включая так же (на этапе разработки) генерацию (на основе SQL-файлов и сеттинг-ов) соответствующей декларативной/вспомогательной информации (исходный код CS, например), обеспечивающей доступность подобных запросов из классических языков ООП, таких как C# и др.

SergeiKitaev 29 июл 2022 в 21:25

Добавлен новый пункт статьи: *** P.S.: SIMPLE SCRIPT (HELLO): *** (см. окончание статьи).

См. так же: https://handicraft.remelias.ru/sdk/sql/screenshots_1.html (SQL-file screenshots-1), — первые 4 пункта списка (выделены жирным), посвящённые примеру Simple script (Hello).

SergeiKitaev 9 авг 2022 в 13:53

О ПОЛЬЗЕ КОМАНДНЫХ СКРИПТОВ

*** НЕБОЛЬШОЕ ОТСТУПЛЕНИЕ ОТ ТЕМАТИКИ SQL: ***

Исходники, соответствующие бинарным утилитам SQL-file, располагаются в папках “Auxiliary programs (sources)\Command line\**” пакета HandicraftSDK. Так вот, каждый такой небольшой проект C# снабжается вспомогательными командами на базе CMD. В Вашем распоряжении оказываются: build.cmd, rebuild.cmd, clean-all.cmd, run.cmd / test.cmd, build-n-run.cmd и т. п. Запустивши (щёлкнув мышью в Windows Explorer) $console.cmd, Вы можете воспользоваться полными или сокращёнными наименованиями команд: ca (clean all), cr (clean + rebuild), … Полноэкранная консоль с вертикальной прокруткой хорошо подходит для автономной компиляции MSBUILD / dotnet build, помимо, так же, простого вызова CMD-файла в консоли Far Manager.

Подобный усиленный C#-проект .CSPROJ сопровождается вспомогательными .PROPS, .TARGETS, .USER. Последний (файл .user) “подхватывается” автоматом (при исполнении сценария MSBUILD; при открытии проекта в IDE), как расширение пользователя для проекта .csproj, подключая так же .targets (а тот, в свою очередь, подключает .props). Применяется расширение для проекта C#, с набором дополнительных целей (TARGET) и установок (PROPERTY, ITEMS). Некоторые такие специальные цели (TARGET) необходимо как-то запускать (исполнять посредством MSBUILD) отдельно от IDE.

И здесь на помощь приходят так называемые стартеры команд (CMD, упоминаются выше). Данный формат (язык интерпретатора командной строки Windows CMD), несмотря на то, что не является современным, очень неплохо, однако, справляется с функцией определения командного стартера: декораторы с минимальной псевдографикой для консоли, команда PAUSE (для возможной задержки после исполнения), и т. п. (Кстати, консольные команды применяют сигнал “звоночка” BEL 07, используется в случае неудачного завершения; см. метку :ERROR в CMD.) Дополнительные сеттинг-и (для стартеров) прописываются в #settings.cmd (UTF-8 без сигнатуры); они представляют из себя переменные окружения, имя которых начинается с символа “#”.

Польза от процессора CMD заключается, в данном случае (в примере со стартерами), в количестве прилагаемых скриптов, которые, несмотря на присущие CMD недостатки, удаётся-таки поддерживать / заимствовать / корректировать и т. п., что навряд ли было бы столь же легко и удобно, а так же красиво, если бы использовался какой-то другой (более современный, продвинутый) интерпретатор командной строки. Так что (касательно CMD) можно сказать, что вся сила в скриптах, достаточно простых, чтобы их сопровождать, и которых нужно много.

Команды проекта C# (файлы CMD) доступны для запуска и из Windows Explorer. Консоль не закрывается сразу же после отработки, поскольку батч-и поддерживают т. н. двойственный вызов: обычный и вложенный (см. переменную is_nested_call в CMD, а так же вызовы вида “call <ИМЯ_КОМАНДЫ>.cmd …”). Таким образом, мы имеем три варианта для задействования стартера CMD: (1) из Windows Explorer (консоль с прокруткой); (2) консоль, открытая посредством батч-а $console.cmd (максимизированное окно с прокруткой, режим $cmd_plain=1, см. поведение и устройство батч-ей); (3) а так же в консоли Far Manager (без прокрутки). Отдельная же консоль для стартера открывается из панели Far Manager посредством Shift+Enter (на соответствующем CMD). (Есть, так же, в системе полезное сочетание клавиш: Windows key + Up arrow, — это чтобы максимизировать окно консоли, не прибегая к помощи мыши.)

Кстати, в интерактивном режиме CMD (открывается через $console.cmd) так же доступно консольное псевдо-окошко последних вызовов, открывается по F7, — это помимо перебора стрелками вверх-вниз по месту набора команды ( под указателем “>”).

*** ПОЧЕМУ ТАК ХОРОШ FAR MANAGER ДЛЯ ВЗАИМОДЕЙСТВИЯ С CMD: ***

Тот, кому приходится взаимодействовать с CMD (поддерживает скрипты командной строки), может по-настоящему ощутить полезность Far Manager: его оперативный встроенный редактор с т. н. “колорёр”-ом (синтаксическая раскраска), правильное отображение символов, выделение вертикальных блоков (Alt + стрелки) и т. п. Для работы с командными скриптами — FAR это естественная среда, как правило, совместимая со всем тем, что имеет отношение к понятию текстовая консоль.

Необходимо иметь возможность для исправления CMD (чтобы это было удобно, чётко и оперативно). Касательно Far Manager, в SQL-файл существует поддержка автоматического включения соответствующей кодировки, когда Вы открываете содержимое CMD во встроенном его редакторе (с подкраской синтаксиса) по F4. Прилагается соответствующий, специально созданный плагин CmdCpAuto.dll (с исходниками), учитывающий определённые особенности именования CMD. Из файла “%FARHOME%\Plugins\CmdCpAuto\Supported CP and file extensions.txt” (поддерживаемые кодовые страницы и файловые расширения):

[[ SUPPORTED CODE PAGES AND FILE EXTENSIONS == I. => OEM-CP: === .cmd / .bat; .cmd.bak / .bat.bak; .CmdIn.txt / .CmdOut.txt; .CmdOut.tmp / .CmdTempOut.txt == II. => UTF-8 (65001): === @*.cmd / #*.cmd; @*.cmd.bak / #*.cmd.bak ]]

Т. о., помимо естественной кодировки OEM (CP-866 для русскоязычной локализации), командные батч-и (в проекте SQL-файл; в усиленном C#-проекте), так же, могут существовать и в UTF-8 (без сигнатуры): “@<project_name>.cmd” (сеттинг-и проекта SQL-файл); “#settings.cmd” (сеттинг-и усиленного проекта C#). Заходя из Far Manager в соответствующий CMD (открывая встроенный редактор по F4), Вы получаете результат-содержимое в соответствующей ожидаемой кодировке, — как правило OEM (если только у батч-а нет префикса “@” либо “#”). Редактор Far Manager является полностью совместимым с CMD в OEM (так же, как и с CMD/UTF-8), — правильно отображает символы, включая специальные управляющие (BEL 07), а так же псевдографику.

Юникод же для CMD используется лишь там, где это действительно необходимо — в определении сеттинг-ов (кратковременное включение кодовой страницы).

*** И СНОВА ПРО ТЕХНОЛОГИЮ SQL-ФАЙЛ: ***

В технологии SQL-файл (при поддержке Far Manager), помимо вызова команд CMD (файлы из проекта), для отдельного файла SQL существует (как интеграция SQL-файл и Far Manager) т. н. “быстрый привод” его трансляции SQL (вызов исполнения $SQLTRANS):

Из файловой панели-списка, по Enter, в консоли Far Manager, с применением страховочного предупреждения. (Реализуется через определение ассоциации для файла SQL в Far Manger.)
Из файловой панели-списка, по Ctrl + Page Down, в отдельной максимизированной консоли, без страховочного предупреждения. (Реализуется через определение ассоциации для файла SQL в Far Manger.)
Из редактора Far Manager, по Ctrl + Enter, с предварительным сохранением файла, в консоли Far Manager, с применением страховочного предупреждения. (Реализуется посредством плагин-а “Editor_CtrlEnter.lua” в Far Manger.)
Из редактора Far Manager, по Ctrl + F12, с предварительным сохранением файла, в отдельной максимизированной консоли, без страховочного предупреждения. (Реализуется посредством плагин-а “Editor_CtrlF12.lua” в Far Manger.)

Кроме того. Из файловой панели Far Manager файл SQL возможно открыть (вызывая из панели-списка) во внешнем автономном текстовом редакторе (GUI) — по Shift + Enter. Там (во внешнем редакторе) так же может быть доступно исполнение SQL (вызов $SQLTRANS), с предварительным сохранением файла, по соответствующей кнопке-значку и/или горячей клавише. (См. прилагаемые инструкции по интеграции: папка “HandicraftSDK\CMD-utilities\Shell\Integration\RU”, текстовые файлы вида “!*.txt”.)

После выполнения трансляции SQL приходится, так же, “заглядывать” в т. н. простые SQL-отчёты (файлы TXT). Far Manager позволяет делать это оперативно, не прибегая к вызову внешнего редактора. Файл .TXT (отчёт трансляции SQL) доступен для быстрого просмотра во встроенном редакторе, открывается по F4 (после позиционировании на соответствующий файл TXT).

Для технологии SQL-файл Far Manager выступает, во-первых, в качестве командного пульта; а во-вторых — представляет из себя упрощённую IDE с оперативным редактором с синтаксической раскраской (так называемым “колорёр”-ом). Интегрированная среда разработки (IDE, Integrated Development Environment) для проекта SQL-файл, упрощённая, без поддержки функции автодополнения идентификаторов при редактировании кода SQL. Основная же фирменная IDE (SQL Server Management Studio) также доступна (хотя и с определёнными ограничениями) для работы с отдельными файлами проекта SQL-файл. Интенсивное же применение процессора Window CMD: для настройки сеттинг-ов, для определения сценариев простой и комплексной (в несколько приёмов) трансляции SQL даёт ещё одно основание считать Far Manager основным интегрирующим инструментом для технологии SQL-файл.

*** ЧТО ИЗ ПОТЕНЦИАЛЬНО ПОЛЕЗНОГО ТАК И НЕ БЫЛО ДОБАВЛЕНО В FAR-MANAGER: ***

Кстати, не всё потенциально полезное для SQL-файл было добавлено в Far Manager; здесь имеется ввиду, прежде всего, поддержка в виде различных плагин-ов FAR-а для SQL-файл.

I. Для отображения файлов в панели неплохо бы было задействовать содержимое порядкового файла $sql_order.list — списка трансляции в каталоге (;SQL-TRANSLATION PRIMARY ORDER: …), чтобы он влиял на список файлов в своей папке (в панелях FAR-UI).

II. Для запуска файла SQL из редактора FAR по Ctrl+Enter (сейчас для это прилагается макрос Editor_CtrlEnter.lua: code="Keys("F2 Esc Enter F4")") — тоже следовало бы предложить соответствующий плагин.

*** ОБ УНИВЕРСАЛЬНОСТИ СЕТТИНГ-ОВ: ***

И ещё кое-что (насчёт универсальности сеттинг-ов). В SQL-проекте может присутствовать (см. примеры сложных проектов) команда “generate_metadata.cmd” (и одноимённые файлы .PROPS/.TARGETS), генерирующая на основе SQL-сеттинг-ов промежуточный C#-исходник “DBConstants.auto.cs” (реализуется посредством MSBUILD-задачи WriteLinesToFile). Таким образом сеттинг-и являются не только параметрами для SQL-исходников проектного дерева (учитываются как переменные среды при трансляции SQL-файлов в БД утилитой SQLCMD, стандартный препроцессинг от MS), но так же и попадают в бинарные EXE / DLL соответствующей программы или программ.

База данных — не столь подходящее место для прописывания в ней ключевых констант и значений, используемых для сборки приложения (пример: извлечение из БД информации о вместимости типа данных БД для программы на C#). Нечто, подобное межплатформенным (универсальным) текстовым файлам свойств (наименование / значение), могло бы представлять более удачную альтернативу для задания величин, нацеленных на учёт сразу в нескольких разнородных программах. В текущем же “кустарном” (handicraft) исполнении SQL-файл используется старинный универсальный подход с переменными Environment (на базе файлов CMD).

*** ЗАКЛЮЧЕНИЕ: ***

Выше приводятся технические особенности устройства технологий SQL-файл. В текущем “кустарном” (handicraft) исполнении SQL-файл эффективно используются старинные универсальные подходы: сеттинг-и (свойства проекта/трансляции) как переменные Environment (на базе файлов CMD), интенсивное задействование сценариев Windows CMD и т. п.

Технология SQL-файл это, прежде всего, идея. А для MSSQL (в текущем исполнении SQL-файл) Вы можете попробовать, насколько полезен и интересен параметризованный SQL на базе файлов и свойств, применительно к традиционному программированию, что называется, внутри БД (хранимые процедуры в файлах, скалярные и табличные функции БД, представления данных, файловые скрипты для модификации структуры и/или по изменению данных).

SergeiKitaev 16 авг 2022 в 20:06

Ещё одно, элементарное, применение утилиты $SQLTRANS

Средства технологии SQL-файл возможно задействовать в разной степени. Не обязательно создавать т. н. SQL-проект (сеттинг-и: $sql_settings.cmd + @<project_name>.cmd). Во-первых, можно обойтись одним лишь $sql_settings.cmd, указывая в нём лишь параметры подключения: set $sql_server=…, set $sql_database=… и т. д. (Потребуется так же нейтрализовать в $sql_settings.cmd один или два вызова с импортом сеттинг-ов: проекта и, если оно чем-то мешает, библиотеки SQLAUX: “rem call :CALL_SETTINGS_BATCH …”.)

Однако, можно и вовсе не использовать файлы CMD. Для этого в системе или родительском (для запуска SQL-трансляции) процессе ОС следует определить переменные подключения к серверу SQL. Поддерживается авторизация 2-х видов: (1) через интегрированную безопасность Windows; (2) авторизация самим сервером SQL.

1) Пример задания переменных для случая с интегрированной безопасностью: $sql_server=(local) $sql_database=TEST

2) Пример задания переменных в случае авторизации сервером SQL: $sql_server=(local) $sql_database=TEST $sql_user=SA $sql_password_var=TestDB_SA_Password TestDB_SA_Password=…

Вышеприведённый способ с использованием промежуточной переменной для значения пароля применяется с той целью, чтобы пароль не хранился в исходных файлах проекта SQL-файл. (Переменную со значением пароля следует инициализировать отдельно.)

При использовании Far Manager следует воспользоваться настройкой ассоциации для расширения SQL: по Enter (из файловой панели, с предупреждением), по Ctrl+PgDown (из файловой панели); а так же: по Ctrl+Enter (из редактора, с предупреждением, макрос Editor_CtrlEnter.lua), по Ctrl+F12 (из редактора, макрос Editor_CtrlF12.lua). См. инструкции: “HandicraftSDK\CMD-utilities\Shell\Integration\RU”, файлы “!*.txt”.

В Far Manager есть возможность применения пользовательского меню (вызывается по F2). Можно задействовать конструктор меню (F2,Insert; F2,F4), а можно редактировать непосредственно FarMenu.ini: “%FARPROFILE%\FarMenu.ini”, либо в текущей папке (для локального меню). См. пример меню Far Manager: “HandicraftSDK\CMD-utilities\Shell\Integration\RU\FarMenu.ini”. Так вот, в подобном меню Вы можете прописать несколько инициализаторов переменных (серия команд вида “set <variable_name>=…”).

Пример инициализации переменных $SQLTRANS посредством файла FarMenu.ini (фрагмент):

[[: Инициализация переменных подключения к БД set $sql_server=(local) set $sql_database=TEST rem set $sql_user=SA rem set $sql_password_var=TestDB_SA_Password set $sql_settings_script=-]]

Ежели используется единственная БД, то параметры подключения можно задать глобально, в пользовательском профиле системы. Хотя, подобное упрощённое определение не рекомендовано (из соображений безопасности при применении трансляций SQL-файл).

Так же, помимо “запуска” отдельного файла, возможно обрабатывать группу SQL (без задействования файлов CMD), путём набора в командной строке следующей команды (например): “$sqltrans *.sql”.

В примере инициализации переменных посредством файла FarMenu.ini (см. выше) присутствует строчка: “set $sql_settings_script=-”. Эта необязательная установка устраняет автоматическое “подцепление” к скрипту инициального батч-а с настройками: “HandicraftSDK\CMD-utilities\$sql_settings.sql”. Скрипт $sql_settings.sql из каталога CMD-utilities содержит (пока в него не вписано иное) одни лишь комментарии, а также разделитель GO. Подобные настройки возможно располагать и в каталоге проекта (в файле $sql_settings.sql. Однако, это не рекомендуется делать по причине отсутствия совместимости с SSMS (фирменный исполнитель скриптов от MS не предусматривает подобных хитростей). В случае же подключения определений библиотеки SQLAUX, автоматическое подцепление инициальных сеттинг-ов в виде файла SQL по умолчанию нейтрализуется (командой из библиотечного CMD): “set $sql_settings_script=-”.

Насчёт исполнения батч-ей утилитой $SQLTRANS в плане возможной ошибки. До тех пор, пока не будет включена опция “set $sqltrans.ContinueOnBatchError=1”, до этих пор можно не волноваться за “немного сомнительные” скрипты SQL, которые SSMS генерирует по имеющемся объектам БД (для создания объекта), где в начало скрипта добавляется батч с командой “use [<Имя БД>]” и разделитель GO. Отсутствие на сервере указанной в скрипте базы данных ведёт (в данном случае) к ошибке, которая рассматривается как причина для прекращения обработки батч-ей: sqlcmd: -b (terminate batch job if there is an error). Таким образом, потенциально ненадёжная, как и многие другие команды T-SQL (в режиме по умолчанию) команда переключения текущей базы данных не представляет в данном случае опасности (того, что последующие инструкции отработают в отличной от указанной в скрипте БД).

Утилита $SQLTRANS (как и вся SQL-файл) довольно тесно совмещается с фирменной IDE SSMS. Например, при отсутствии сигнатуры (BOM) в исполняемом файле SQL, его содержимое будет восприниматься как в кодировке UTF-8, что совпадает с кодировкой по умолчанию для генерации файловых скриптов в SSMS. При желании же возможно трактовать отсутствие сигнатуры у скрипта SQL как содержимое в системной однобайтовой кодировке ANSI (CP-1251 при русскоязычной локализации). Для этого следует “выключить” умолчание UTF-8: “set SqlCatPP.DefaultInputEncodingUTF8=0”. (Настройки конкатенатор-а/препроцессора SqlCatPP наглядно выводятся батч-ем синтаксиса: “HandicraftSDK\CMD-utilities\Assemblies\SqlCatPP\!syntax.cmd”.)

Однако, несмотря на возможность неприменения пользователем файлов CMD при исполнении скриптов, рекомендованным способом для трансляции в SQL-файл является всё же сопровождение каталога (с файлами SQL) хотя бы одними лишь простыми сеттинг-ами в виде файла $sql_settings.cmd (см. примеры). Так же, желательно оставить в нём (не блокировать комментарием “rem …”) подключение библиотеки SQLAUX, содержащей набор существенных, хотя бы для потенциального использования, определений (свойства-переменные), таких как $(BEGIN_AUX), $(END_AUX), $(BEGIN_TRANSACTION_AUX), $(LOOP_AUX), $(NL_AUX) и т. п. См. папку: “HandicraftSDK\SQL\SQLAUX\API (headers)”, т. н. псевдозаголовочные (описательные, для пользователя) файлы SQL. Помимо раскрывающихся слов усиленного T-SQL, в каталоге присутствуют так же и заголовки всех библиотечных программатик-ов (сохраняемые в БД объекты SQLAUX, предназначенные для расширенного полноценного применения скриптовой библиотеки).

В ОС Windows-XP существовала возможность настраивать именованные ассоциации для расширений файлов. По правой кнопке мыши на файле SQL можно было (когда-то) выполнять действие Translate. В настоящее же время (как было и в прошлом) навряд ли удастся подобрать для технологии SQL-файл, ориентированной (в текущем исполнении) на консоль и файлы CMD, более достойный и совместимый с ней командный пульт (плюс оперативный редактор скриптов), нежели известный файловый командер Far Manager.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Технология SQL-файл, препроцессор для T-SQL, “бок-о-бок” файлы и др

Комментарии 14

Публикации

Истории