Комментарии 9
Я 25 лет работаю с MS SQL, но ни понял ничего. Что, зачем? Автор существует в каком то своем контексте
Вероятно, вы глубоко в своей задаче и позабыли, что пользователь не курсе проблемы.
Какую проблему вы решаете в этой статье?
ну прочтите внимательно же)
автор реализовал приложение на C# для обработки файлов .sql на стороне клиента плюс какое то расширение функционала самого sql
но конечно с примерами беда
Добрый день!
*** ПО ПОВОДУ ПРИМЕРОВ. ***
Стоит заметить, что любой файл .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-файл, в первоначальных её представлениях, в течение долгого времени поддерживались (в прошлом) базы данных для расчёта квартирной платы в городе Воронеж.
Спасибо за внимание и Ваш отзыв!
Уважаемы автор! В этой статье, написанной в стиле прошлого столетия, вы забыли главное - рассказать о том, что заявлено в заголовке: "Технология SQL-файл".
Есть отдельные кусочки описания, но понять, что же такое на самом деле, прочитав статью, невозможно. При этом вы много рассказываете про перечисляете используемые командеры, хелперы, эксперименты, собственные статьи...
Но где сам "SQL-файл?
Хоть бы один пример такого проектика? С описанием задачи, решаемых проблем...
А то, всё, что есть, это фраза, где-то в цитате, "Идея состоит в том, чтобы поддерживать исходный код и/или вспомогательные скрипты в виде SQL-файлов в директориях, транслируя их в базу данных, по отдельности либо группами. "
Если ваш "SQL-файл" - это хиленький препроцессор и cmd для выполнения скриптов БД, то не понятно, а что в нём интересного, кроме кучи устаревших подходов?
Кодогенерация - так есть куча альтернатив (и они сильно мощнее простенького препроцессора). Апдейт базы - так есть миграции (и это не обязательно ORM). Редакторы кода - тем более. И всё это нормально дружит с git и devops, что сильно снижает трудозатраты и риск ошибки...
Иначе говоря, скажите, какую проблему решает ваша технология, которую (проблему) не решают другие популярные современные решения.
Добрый вечер!
*** О ТОМ, ЧТО ЗАЯВЛЕНО В ЗАГОЛОВКЕ: ***
Заявлено и в заголовке статьи и в названии технологии, — ничего возмутительного; самые, казалось бы, естественные вещи присутствуют в SQL-файл.
В своём ответе на предыдущий комментарий “ну прочтите внимательно же) … но конечно с примерами беда” от qwertEHOK 26.06.2022 в 11:43 автор приводит разъяснения: “ПО ПОВОДУ ПРИМЕРОВ”, “НАСЧЁТ РЕАЛИЗОВАННЫХ ИДЕЙ”, “ФОРМИРОВАНИЕ ТЕХНОЛОГИИ SQL-ФАЙЛ” (см. выше).
Идея предельно проста: хранить исходный код в правильно организованной директории на клиенте; там же его редактировать, оттуда его и применять (транслировать скрипты в БД). Это очень просто на словах. В реальности же всё оказывается нетривиально: много команд (простая / составная трансляция); обработать отдельный файл / группу () / большую группу; определение собственных раскрывающихся слов / констант $(<Имя переменной>); организация порядка трансляции; расположение файлов в папках дерева. Автор не утверждает, что всё решается идеально. Эта небезупречная реализация, однако, действительно позволяет поддерживать подсистему внутри БД, опираясь на файлы, как исходное место для усиленного SQL (создание/удаление табличной структуры, хранение кода ХП, функций, представлений, триггеров). В базе данных на самом деле — не совсем-таки исходники, а фрагменты скриптов с учётом сеттинг-ов (с уже раскрытыми переменными пользовательского проекта / каталога / трансляции). Для нормальной коррекции такого скрипта необходимо править исходный SQL-файл и применять его. Т.е. стандартная графическая консоль для доступа в БД используется по минимуму (как правило не для правки того, что присутствует в файлах).
Вот пример того, как раскрывается обёртка основного блока:
ИСХОДНЫЙ СКРИПТ (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-ФАЙЛ: ***
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-проектов, автономный, настраиваемый / расширяемый, с поддержкой простых командных сценариев, со средней степенью интеграции с редакторами и командными пультами.
Всего доброго!
система сборки MSSQL базы и приложения на C# .NET?
и без системы контроля версии? (номер версии тоже должен быть в базе)
и без обратного преобразования из базы в проект?
Пример бы поменьше… из 2-3 табличек + вьюх + процедур
*** НАСЧЁТ СБОРКИ (БАЗА И ПРИЛОЖЕНИЕ): ***
Многие ключевые величины прописываются (т. е. хранятся изначально) в 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”).
*** 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# и др.
Технология SQL-файл, препроцессор для T-SQL, “бок-о-бок” файлы и др