Завершив в недавнем прошлом очередную доработку своей легковесной технологии SQL-файл, применяемой для эффективной трансляции файлового SQL-кода в базу данных, автор данной статьи решил в очередной раз представить (в этой заметке теперь, на популярном ресурсе) свои реализованные, хотя бы отчасти, идеи касательно программирования MSSQL, а также некоторые соображения относительно применения SQL вообще. Автор полагает, что несмотря на форму предлагаемой им частной реализации SQL-файл (для MSSQL), лежащая в основе подхода концепция имеет определённую силу и смысл.
Введение
Нижеприводимая веб-ссылка (SQL-File, данный абзац) была впоследствии добавлена как необходимая (структурированная) информация для предварительного ознакомления с обсуждаемым предметом. Основным вариантом данной статьи является Введение в статически параметризованный язык SQL, в виде публикации на сайте CodeProject: SQL-File Technology for Transact-SQL (основная веб-ссылка, английский язык). (Альтернативная веб-ссылка: SQL-File Technology for Transact-SQL, Авторский блог Handicraft-CODE.) Рекомендуется сначала взглянуть, хотя бы бегло, на текст и оглавление статьи, размещённой на CodeProject.
Язык SQL (его основа), а также средства поддержки SQL придумывались давно. Классические серверы реляционных БД, как правило, не допускают прямого размещения файлов исходного кода запросов на сервере; например, в специальных директориях БД, подобно тому, как, к примеру, на веб-сервере можно выложить JS, HTML, CSS и т. п. (В реляционной СУБД всё весьма консервативно, присутствует множество серьёзных ограничений.) Вместо этого клиент SQL-сервера имеет доступ к механизму манипулирования объектами БД и сервера (путём отправки пакетов инструкций SQL). С помощью специальной (как правило графической) консоли БД создаётся подобие редактирования исходников сохраняемых в БД объектов. Собираясь же по определённым причинам переходить (всецело) на файловую базу для хранения скриптов Вы можете обнаружить недостаточную поддержку работы с подобными файлами-скриптами со стороны клиентских инструментов разработки SQL. Представленная же здесь (в статье) легковесная технология SQL-файл ориентирована как раз на файловую базу для размещения исходников, в директориях и файлах SQL, для SQL-объектов БД: таблицы (скрипты их создания), индексы, ограничения (constraint), хранимые процедуры (ХП), функции и т. п.
Описывая в общих чертах и отдельных деталях конкретное исполнение идей, статья, в то же время, содержит элементы некоторого вымысла (фантастики), нацеленные на обретение теоретического видения касательно применения различных диалектов языка SQL, в плане предлагаемого общего знаменателя (для доступа к SQL-запросам), отражённого здесь путём привнесения соответствующих терминов: Заголовок SQL-запроса (формат, подлежащий унификации), Компилируемый временный запрос к SQL-серверу (допускает определённую унификацию) и прочее. Непривычный взгляд на взаимодействие с SQL-сервером позволяет, однако, не быть обязанным к общению с т. н. большой ORM (Object-Relational Mapping), иметь свободу интенсивно задействовать программирование внутри базы данных (функции, вспомогательные ХП и прочее), при этом логически разделяя запрос к веб-серверу на универсальные части-составляющие: (1) Составляющая SQL-сервера (условно открытый SQL-заголовок + реализация); (2) Составляющая веб-сервера (декларация API + имплементация); (3) Клиентская составляющая (в основном определения для использования запроса). Наличие разнородных сред и языков программирования для исполнения одного, казалось бы простого, запроса клиента создаёт препятствие для гладкой его реализации. Сложности же, вызываемые двойственной природой реализуемого запроса (SQL-сервер + веб-сервер) навряд ли подлежат существенному устранению, учитывая даже применение, так скажем, идеальной (максимальной) ORM.
В последующих текстах присутствует определённое количество специфических наименований, а также сверхкоротких фрагментов из соответствующих скриптов и конфигурационных файлов (т. н. инишник-и, батч-и и т. п.). Можно особо не заострять на них внимание; они тут изобильно приводятся в основном с той целью, чтобы показать, что поведение т. н. SQL-трансляции (файлы => объекты SQL) подлежит конфигурированию, настраивается и доступно для управления. Так же, не следует ассоциировать применение файлового коммандер-а, процессора CMD и т. п. с какой бы то ни было отсталостью. Автономный проект (компиляция) SQL-файл, по ощущениям автора имеет, в каком-то смысле, схожие черты с автономными проектами в универсальной кроссплатформенной среде разработки VS-Code (конфигурирование, задачи, запуски и т. п.). Файловый же коммандер (здесь это, как правило, Far Manager) вкупе со сценариями обработки (здесь это в основном CMD) хорошо подходят для реализации автономного, независимого от привязок к фирменным IDE, компилируемого проекта.
Касательно же недостатков интеграции SQL-файл с Far Manager, стоит отметить отсутствие какой-либо функции автодополнения при редактировании SQL, в отличие, например, от задействования технологии IntelliSense в Visual Studio. В SQL-файл подобное редактирование (с “равнением” на коллекцию имён из базы данных в данном случае) доступно через т. н. IDE-стартер SSMS.cmd, что, однако, также имеет свои ограничения, выражающиеся, в первую очередь, в “замораживании” всего окружения (переменные среды) на моменте старта IDE (и не только это).
Минимальная формулировка назначения и замысла SQL-файл:
Когда-то, презентуя впервые свою методику взаимодействия с СУБД SQL Server, автор данной статьи писал (в прошлом) примерно следующее:
Добрый день, уважаемые разработчики SQL!
Позвольте представить Вашему вниманию самодельную легковесную технологию, именуемую как SQL-файл (или же SQL в файлах), — для MSSQL и T-SQL. Данная методика успешно применялась в течение достаточно долгого периода для программирования БД расчёта квартирной платы (город Воронеж). Технология базируются на известной утилите SQLCMD и командном процессоре CMD. В качестве IDE (командный пульт SQL + оперативный редактор) эффективно применяется Far Manager 3, со вспомогательными простейшим плагином и макросами. (Так же, возможно задействование других редакторов SQL, помимо встроенного в FAR.)
Идея состоит в том, чтобы поддерживать исходный код и/или вспомогательные скрипты в виде SQL-файлов в директориях, транслируя их в базу данных, по отдельности либо группами. Используя утилиту $SQLTRANS и соответствующие шаблоны, можно настроить трансляцию (генерацию) большого количества объектов БД, работающую, так сказать, на раз-два-три. За один приём, например, возможно обновить активную составляющую программы в базе (процедуры, функции, представления, …), или, скажем, создать табличную структуру (и наполнить её некоторым количеством необходимых данных). При умелом обращении подсистема (активные объекты) может вполне свободно корректироваться даже на работающей программе/службе.
Обзорное минимальное описание SQL-файл доступно на страницах Handicraft-CODE (англ. язык): https://handicraft.remelias.ru/sdk/sql_file.html (Handicraft-CODE :: Handicraft-SDK :: SQL-file technology); https://handicraft.remelias.ru/sdk/sql_tools.html (Handicraft-CODE :: Handicraft-SDK :: CMD-utilities :: SQL-tools).
А также, см. скриншот-ы: 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.
Вместе с командными утилитами и шаблонами предлагается возможное (опционально) использование так называемого Усиленного Transact-SQL, с препроцессором (на базе переменных среды), представленного множеством соответствующих импорт-определений и широким набором хелпер-объектов прилагаемой библиотеки SQLAUX (полезные программатик-и).
: : : : : : : : : :
Спасибо за внимание!
I. Предыстория (что не так с языком Transact-SQL, расширения SQLCMD и др.)
Автор данной статьи в течение долгого времени имел дело с СУБД MS SQL Server. Когда-то в прошлом к автору пришло осознание того, что режим исполнения инструкций (Control Flow) в языке Transact-SQL, который MSSQL предлагает по умолчанию (режим), не является надёжным. Без использования специальных блоков-обёрток для перехвата исключения — необходимо везде-везде проверять состояние последней ошибки @@ERROR. Исходя из желания использовать эффективный (полуавтоматический, с исключениями) контроль ошибок, а также и по другим (тоже веским) причинам, в течение длительного времени вырабатывалась и применялась интересная технология SQL-файл, основанная на расширениях SQLCMD. SQL-код хранится в файлах, организованных специальным образом в виде SQL-проекта (в дереве вложенных файловых папок). Для трансляции файлов в базу данных применяется легковесный обработчик — препроцессор-конкатенатор скриптов: SqlCatPP (EXE) в связке с вызывающей его обёрткой $SqlTrans (CMD). Так же, подразумевается использование вспомогательной библиотеки элементарных хелпер-объектов и констант (вида $(<ПеременнаяСреды>)) SQLAUX (в приложение к основному транслятору/препроцессору). В качестве редактора SQL в настоящее время, помимо встроенного редактора Far Manager, а также одного из GUI-редакторов для простого текста (см. в загрузках), доступно также использование SQL Server Management Studio (+Environment), в немного ограниченном, однако, виде (см. устройство SSMS.cmd в загрузках).
II. Технология SQL-файл на страницах https://handicraft.remelias.ru/
Вот ссылки на страницы автора статьи (минимальное описание + картинки и примеры):
https://handicraft.remelias.ru/sdk/sql/screenshots_1.html (Скриншот-ы SQL-файл: 1, 2, 3);
https://handicraft.remelias.ru/sdk/sql_file.html (Технология SQL-файл; Список хелперов SQLAUX);
https://handicraft.remelias.ru/sdk/sql_tools.html (Легковесные инструменты SQL).
Ещё картинки (вспомогательное применение SQL-файл, бок-о-бок файлы SQL/C# и др.):
Так же, в авторском блог-е https://blog-hc.remelias.ru/, по SQL-файл присутствует серия заметок (пост-ы):
https://blog-hc.remelias.ru/sql-file-technology-for-transact-sql/
https://blog-hc.remelias.ru/sql-file-technology-pp-for-t-sql-sbs-files-etc/
II.1. Запуск SQL-файлов с учётом подготовленного окружения
После настройки, проведённой соответствующим образом, легковесных инструментов, появляется возможность “запускать” правильно сконфигурированные (снабжённые лежащим в том же каталоге $sql_settings.cmd) файлы кода с усиленным Transact SQL. В Far Manager подобная трансляция срабатывает (приводится в действие) из панели по <Enter> (для ассоциации SQL), из встроенного редактора по <Ctrl+Enter> (простейший макрос); в отдельном окне (запуск из панели) — по <Ctrl+PgDown>, в отдельном окне (запуск из встроенного редактора) — по <Ctrl+F12>. Утилита $SQLTRANS “подхватывает” $sql_settings.cmd; файлы из подкаталогов, как правило, наследуют (и, возможно, расширяют) сеттинг-и (окружение) более высокого уровня расположения. Корневой же $sql_settings.cmd подключает, как правило, SQLAUX.cmd (из каталога библиотеки), а также @<имя_проекта>.cmd (в UTF-8). Запустив же SQL Server Management Studio посредством стартера SSMS.cmd (располагается в корне SQL-проекта), данный процесс также получает возможность использовать все тонкости настроенного окружения:
Доступны слова для обёртки основного блока:
$(BEGIN_AUX),$(END_AUX), с автоматической защитой от ошибки (т. н. “заворачивание” вbegin try/end try/ … и т. д.), которые, так же, инициализируют некоторые T-SQL-установки SET (при раскрытии$(BEGIN_AUX));Многочисленные ключевые слова и константы:
$(LOOP_AUX),$(TRUE_AUX),$(DropFunctionScript_AUX),$(num_IntStrMaxLength_AUX),$(dt_Name_AUX), и т. п.;Ссылки на собственные переменные проекта
$(<ИмяПеременной>).
Необходимо сначала должным образом установить и настроить поддержку SQL-файл!!!
При установленном плагин-е для Far Manager CmdCpAuto, появляется возможность комфортно просматривать (по F4) многочисленные CMD (с автоматическим переключением на нужную кодировку).
После прописывания в системе пути (PATH) к командным утилитам “…\HandicraftSDK\CMD-utilities” (папка с CMD, EXE) — становится работоспособным следующее: $sqltrans.cmd, $sqlupload.cmd, $sql.cmd, $sqlcon.cmd, $sqltocsvexp.cmd и прочие “$”-команды.
Так же, в системе потребуется определить путь к библиотеке скриптов и констант окружения SQLAUX: SQLAUX_ROOT = …\HandicraftSDK\SQL\SQLAUX.
При установленных макросах LUA из “HandicraftSDK\CMD-utilities\Shell\Integration(\RU)”, а также после настройки ассоциаций FAR-а согласно “!Integration of $SqlTrans with FAR Manager.txt” (или же “RU\!Интеграция $SqlTrans с FAR Manager.txt”) — всё становится довольно-таки удобным для программирования с применением SQL-файл.
Обратите внимание на папку(и): “HandicraftSDK\CMD-utilities\Shell\Integration(\RU)”.
II.2. Трансляция множеств (файлы SQL)
Помимо простой трансляции отдельного файла, имеется возможность обработать группу / подгруппу SQL. Для запуска подобной трансляции применяются, как правило, простые стартеры CMD. В одну трансляцию могут попадать не только файлы шаблона “*.sql”, но также (при соответствующем запуске $SqlCmd) и сразу несколько подпапок, а также и некоторый специальный SQL-файл. Порядок обработки файлов перестраивается посредством простейших файлов коррекции $sql_order.list. Сложные же (составные) трансляции описываются соответствующими CMD-сценариями. Подобные сценарии играют в SQL-файл значительную роль (удаление файла, запрос подтверждения, формирование текстового отчёта, и т. п.).
В загрузке, соответствующей Handicraft-SDK, присутствуют три условных SQL-проекта (перечислены в SQL-project-list.txt), а в состав BookRegistry app. входит один сложный (из 2-х разнесённых частей) SQL-проект.
II.3. Слабый и сильный препроцессинг (осуществляется подпрограммой SqlCatPP)
При использовании Environment зачастую нормальным будет положиться на поведение базового средства SQLCMD. По умолчанию (при обращении к $SQLTRANS) SqlCatPP (EXE) применяет так называемый “слабый препроцессинг”, затрагивающий одну лишь директиву :SetVar. Он попросту добавляет перед ней одну строчку-комментарий: --:SetVar … (чтобы иметь неиспорченную диагностику относительно номера строки ошибки). Однако, когда Вы не взаимодействуете с БД напрямую, а отдаёте свои скрипты дилеру (посреднику), то возникает потребность в тщательной подготовке такого скрипта, с учётом Environment SQL-проекта. (Навряд ли удастся на стороне дилера использовать какие-либо окружения.) В данном случае необходим так называемый “сильный препроцессинг”, который реализуется в SqlCatPP в тестовом виде, затрагивает директивы :SetVar, :r, а также ссылки на переменные среды: $(<ИмяПеременной>). Результат подобной обработки доступен для примера в подкаталогах $OUTPUT и $GENERATED проектов SQLAUX и “Extralight-ORM test legacy sample (En+Ru)\MyFlat app. (MVC_Razor+TS+ADO+TSQL)\SQL (DB-modelling)”. В состав sqlaux_library.sql (из $OUTPUT), например, входят (как минимум) 173 исходных SQL-скрипта (фрагменты с разделителем GO), присутствующие также и в $GENERATED (с порядковым префиксом имени файла: XNNN.<BaseFileName>.sql). Сильный препроцессинг включается CMD-инструкцией set SqlCatPP.ProcessDirectives=1, располагающейся, как правило, в корневом сеттинг-файле SQL-проекта $sql_settings.cmd.
Так же, утилита $SQLTRANS имеет возможность производить т. н. фиктивную трансляцию (set $sqltrans.TranslateToDatabase=0), выводить данные в текстовый файл результатов (для этого необходимо задать действительный 2-й параметр, например: $SqlTrans "%~n0.sql" "%~n0.txt"), а также поддерживает передачу дополнительных параметров в базовый SQLCMD (например: set $sqltrans.AdditionalParams=-y0, set $sqltrans.ContinueOnBatchError=1). И не только это (см. страницы, картинки и загрузки).
II.4. Два основных направления в использовании SQL-файл
Технология SQL-файл применяется для достижения следующих 2-х основных целей:
1) Хозяйственная обработка базы данных MSSQL: добавление таблиц, наполнение их данными, правка структуры БД, прочие рутинные операции административного характера. Поскольку всё оформляется в виде файлов, то то или иное действие может быть повторно воспроизведено впоследствии (с соответствующей доработкой скриптов).
2) Программирование в базе данных MSSQL, а именно — написание подсистемы хранимых объектов кода SQL (процедуры, функции, триггеры, представления), которые в терминологии SQL-файл обозначаются как программатик-и (общий термин). Серверную SQL-часть приложения принято, зачастую, генерировать целиком — удалять все (или подгруппу) программатики (соответствующие, например, такому-то именному префиксу) и создавать их заново. (Данное действие можно производить на разных экземплярах сервера и БД, указываемых в корневом $sql_settings.cmd соответствующего SQL-проекта.)
III. Небольшая попытка создания экспериментальной псевдо-микро-ORM для доступа к своим SQL-запросам и ХП, бок-о-бок файлы (SQL/C#) и прочее
III.1. Техника Side-by-Side (SQL/C#)
В экспериментальных проектах “Client-Server.WEB (idea)” а также “MyFlat app. (MVC_Razor+TS+ADO+TSQL)” была предпринята небольшая попытка непрямого соединения исполняемого SQL-сервером кода Transact-SQL с исполняемым веб-сервером ASP C#-кодом для .NET. В 1-м случае подобный CS-код, так же (с учётом соответствующих директив условной компиляции), работает в браузере (применяется WASM-Blazor), что привносит дополнительные усложнения. Каждый запрос к БД оформляется в виде 2-х рядом лежащих файлов с одним и тем же базовым именем: “<ИмяЗапроса>.sql” и “<ИмяЗапроса>.cs”. В данном случае под SQL-запросом понимается код хранимой процедуры T-SQL, который “попадает” на сервер в момент трансляции SQL-файла, каталога с файлами либо всего большого проекта (с применением $SqlTrans+SqlCatPP).
Соединение SBS-файлов условное (смешения кода нет). Данное исполнение стремится видеть (представлять) SQL-запросы в довольно унифицированной форме: с параметрами ХП, статусом возврата @Status uniqueidentifier = null out (параметр), сообщением ошибки @Message $(dt_Message_AUX) = null out, с возможными несколькими резалт-сет-ами. (В последующей неопубликованной версии аналогичного SDK данные параметры имеют, соответственно, имена @RStatus и @RMessage.)
Легковесный ORM к ХП и SQL-запросам (Handicraft-CODE): https://handicraft.remelias.ru/csweb/lightweight_orm.html
Попытки успешного смешивания разнородного кода известны. Например: “.razor” и “.cshtml” (смешение HTML+C#) — используются для генерации HTML-разметки посредством C#, с частичной проверкой правильности разметки. При компиляции же SQL-процедуры (например, из файла SQL) — также проводится определённая проверка правильности SQL. Совмещение SQL+CS возможно было бы, в определённой степени, усовершенствовать. Например, в некоторых трудоёмких случаях — использовать объявление именованного (не позиционного) параметра (с типом) непосредственно по месту его применения в теле запроса, “поручив” оформление заголовка(ов) запроса(ов) генератору-препроцессору SQL (добавив в него соответствующую функциональность). Так же, используя специальный вспомогательный формат двойственного (SQL-сервер/SQL-клиент) определения значений и типов (кроссплатформенные константы и синонимы для базовых типов данных), теоретически возможно было бы достичь определённого успеха. Однако, смешивание кода, работающего в совершенно разных средах и местах, навряд ли должно выглядеть просто.
Касательно имеющихся примеров псевдо-микро-ОРМ в моём Handicraft-CODE (идея Client-Server.WEB и прочее). В примере BookRegistry app. излишнюю сложность, однако (помимо состыковки веб-серверного C# с языком T-SQL), привносит использование JSON (передача данных запроса между веб-сервером и веб-клиентом WASM, на C#), а также желание надёжно “защититься” при этом (проверки-исключения) от Null-ов на стороне C# (после передачи данных через HTTP в упакованном виде, посредством JSON). В примере же “MyFlat app. (MVC_Razor+TS+ADO+TSQL)” применяется сочетание 2-х (разговорных) языков для наименований (как дополнительная сложность): английский (ASP веб-сервер) <=> русский (объекты в SQL-БД).
III.2. Зачем всё это нужно (или же почему не всё так складно в ORM)?
Данный пункт можно отнести к области фантастики. Он предполагает существование возможности вносить изменения/дополнения в некоторую реляционную СУБД, поддерживающую расширяемый диалект языка SQL.
В настоящее время, при доступности применения ORM для взаимодействия с БД, её (одну из ORM) естественно будут использовать очень многие. Несмотря даже на то, что подобное применение зачастую ведёт к определённому перевороту, когда, например, язык C# может быть поставлен выше базы данных, как принято на это смотреть в контексте применения EF Code First, и любое общение/взаимодействие с БД (даже не от имени разрабатываемого приложения) подчиняется уже C# и особенностям Entity Framework (при использовании Code First). А ежели подход с центральным Code First — это востребованное передовое, то всё, что не Code First — уже не годится (не то, что надо) и т. п. Есть и другие причины, также говорящие в пользу применения своих SQL-запросов для общения с сервером SQL. (Крупные базы данных, кстати, способны пережить и несколько клиентских фреймворков и ORM.)
Что же касается использования хранимых процедур в БД для приложения, то существует обоснованное мнение, что это (1) не современно, (2) не кроссплатформенно, а также (3) тяжело в поддержке. Поэтому — опять приходим к ORM, большой ORM. (И даже микро-ORM применять, как правило, обычно не рекомендуется.)
Непростая идея компилируемых запросов SQL:
Бок-о-бок файлы (приводятся выше), реализованные автором статьи в экспериментальном виде на базе классических хранимых процедур-запросов MSSQL, могли бы, так же (потенциально), при должной поддержке со стороны СУБД, быть исполнены, по части обработки SQL, в виде так называемых “Компилируемых запросов SQL” (Compiled SQL Queries с ограниченным управляемым временем жизни), поддерживаемых гипотетическим SQL-сервером (с функцией Compiled SQL Queries). Компилируемые SQL-запросы возможно было бы унифицировать по части заголовков с параметрами-значениями, параметрами-таблицами, резалт-сет-ами, кодом/статусом/сообщением возврата и т. п. (Т. е. — такие специальные кроссплатформенные по отношению к диалектам SQL заголовки для SQL-запросов.) Хранящийся в SQL-файле клиента SQL-сервера параметризованный код (плюс клиентская Environment) должен соответствующим образом подготавливаться (“на лету” при первом запуске запроса, или, возможно, на старте приложения):
сначала (на стороне клиента SQL) — применение аналога Environment SQL-проекта;
далее (на стороне клиента) — препроцессинг SQL (раскрытие аналогов переменных среды);
затем — подготовка на SQL-сервере, с проверкой ошибок (компиляция аналога временной ХП с параметрами, со специальным уникальным наименованием временно сохраняемого запроса).
Исправление же кода в файле с SQL-запросом приложения на работающей программе (желательно это делать, конечно, не в части заголовка) — должно восприниматься как необходимость повторной компиляции (когда потребуется) временного запроса: уничтожение/создание временного запроса+имени на сервере SQL. По-видимому, стоит предусмотреть несколько разрядов (степени долгожительства), отвечающих за продолжительность существования таких запросов на сервере, — от эфемерных до практически постоянно сохраняемых запросов.
Таким вот примерно образом автор статьи представляет себе общение с базой данных SQL на языке SQL, со стороны программы (например веб-сервера), использующей какой-либо компилируемый либо скриптовый язык. Для работы такого приложения потребуется технология, подобная SQL-файл (обозначим расширение как SQL-file-app.). Компилируемые запросы приложения (SQL-файлы) могли бы заранее (на этапе разработки) проверяться специальными командами трансляции (отсылаться на сервер) на предмет ошибок предварительной подготовки (компиляция запроса на стороне SQL). Более того: базирующиеся на SQL-файлах компилируемые запросы должны быть доступны из папок SQL-проекта для исполнения их отдельно от, собственно, приложения, — как из подготовившего запрос файла сценариев, так и из специального проверочного или хозяйственного SQL-скрипта, работающего в контексте того же (подготовившего запрос) SQL-подключения.
Кроме того, обычная (подобная существующей в исполнении автора статьи, для MSSQL) не расширенная функциональность технологии SQL-файл, также могла бы оказаться весьма полезной для работы вокруг подобного приложения.
IV. Завершение (резюме)
Как было обозначено в начале пункта III.2, то, о чём (в п. III.2) фантазируется автором статьи, весьма удалено от нашей реальности. И всё же (насчёт реальности): несмотря на могущество отдельных диалектов SQL, длительную историю знаменитых СУБД, трудно, в контексте понимания того, как обычно оформляются/выглядят запросы к базе данных (SQL-вкрапления в другую программу, либо посредством драйвера большой и умной ORM, либо же с применением отдельного SQL-файла или объекта с кодом, открываемом в консоли-редакторе БД), — трудно называть SQL первосортным языком программирования, который мы можем полноценно поддерживать (с тем же комфортом, что и классические языки ООП), когда применяем SQL для взаимодействия с БД из кода приложения или из отдельного скрипта.
*** P.S.: ПРИМЕР SIMPLE SCRIPT (HELLO): ***
Данная заметка (статья про SQL-файл) включает, помимо основного содержания технологии, определённые элементы фантастики, приводимые здесь ради попытки набросать некоторые очертания в плане потенциального развития идеи, не останавливаясь на достигнутом элементарном. Вообще, представлено лишь предварительное описание, предназначенное для беглого ознакомления, предполагающее так же обращение к соответствующим скриншот-ам SQL (см. https://handicraft.remelias.ru/sdk/sql/screenshots_1.html), а также имеющимся исходникам примеров SQL-файл (располагаются в загрузках Handicraft, в домене https://handicraft.remelias.ru/).
Основные цели технологии SQL-файл (реализованные для MSSQL) сообщаются в пункте II.4. данной статьи; см. выше: “II.4. Два основных направления в использовании 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”.)
В скриншот-ах SQL на страницах Handicraft, данный пример располагается в самом начале 1-го подмножества (соответствующие 4 ссылки с прокруткой выделены жирным):
https://handicraft.remelias.ru/sdk/sql/screenshots_1.html (SQL-file screenshots-1):
Simple script settings (SQL-file project defs: $sql_settings.cmd, @simple_script.cmd)
Simple script output (TXT-report in simple_script.txt, Console, SSMS)
Simple script run (elementary simple_script.cmd and complex run_simple_script.cmd)
Здесь иллюстрируется пример, что называется, одного скрипта — simple_script.sql (центральный файл), который, в то же время, не такой уж и элементарный, поскольку снабжается прилагаемым типичным набором файлов SQL-проекта. В результате, некоторые мелкие фрагменты T-SQL оказываются вынесенными (с соответствующим умыслом) в другие файлы: @simple_script.cmd (сеттинг-и UTF-8), %simple_script% (заголовочный скрипт SQL для декорации отчёта). Так же, в комментариях SQL и CMD присутствуют намёки на то, с чем можно “поиграть”, чтобы исследовать особенности и поведение. (Кстати, программное окружение SQL-файл предлагает клавиатурный макрос для эффективного комментирования строки CMD посредством “rem …”, по нажатию Ctrl+R в редакторе Far Manager. См.: “HandicraftSDK\CMD-utilities\Shell\Integration\RU\Editor_CtrlR.lua” и инструкции “!*.txt”.)
Имеются и другие элементарные примеры, подобные Simple script (Hello); прилагаются к SQL-файл. См. “HandicraftSDK\SQL\Programming samples (SQL-file)\**”.
V. ИНСТАЛЛЯЦИЯ SQL-ФАЙЛ
Инсталляция SQL-файл не является ни простой ни сложной. Программное окружение устанавливается вручную (требуется немного повозиться). Страница загрузок (одна из): https://handicraft.remelias.ru/; файлы: “Handicraft_Toolkit_YYYYMMDDx.7z” (без пароля) либо “HandicraftSDK YYYY-MM-DDx.7z” (пароль: qwerty).
Список действий, необходимых для установки окружения SQL-файл:
Скопировать папку HandicraftSDK (кустарный SDK) либо же папку Handicraft_Toolkit_YYYYMMDDx (SDK + дополнительные примеры) на пользовательскую машину (желательно поближе к корню тома). Путь к папке SDK не должен содержать символов восклицательного знака “!”, так же, как и путь к пользовательским проектам SQL-файл!
Прописать путь к папке CMD-utilities — учесть в переменной PATH (для работы утилит: $SQLTRANS, $SQLUPLOAD, $SQLCON, $SQL, $SQLTOCSVEXP, $CONFIRMPAUSE, $TYPEINCOLOR и др.).
Определить в системе переменную SQLAUX_ROOT так, чтобы она ссылалась на папку “SQL\SQLAUX” (для доступности скриптовой библиотеки SQLAUX); определить переменную SSMS_ExePath как “C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe” (или подобное).
Скопировать плагин CmdCpAuto в Far Manager: “Utilities\Far plugins\CmdCpAuto plugin, build 100 (Far v3)\x64” (или x86) >> %FARHOME%\Plugins\.
Скопировать файлы *.lua (все макросы, либо выборочно) в Far Manager >> %FARPROFILE%\Macros\scripts\.
Настроить ассоциацию для расширения *.sql согласно инструкциям из папки “CMD-utilities\Shell\Integration\RU” (см. файлы “!*.txt”), и другие действия по инструкциям, например заимствование понравившихся пунктов меню из файла FarMenu.ini. Там же приводится информация о том, как сконфигурировать под SQL-трансляцию (утилита $SQLTRANS) один из лучших автономных редакторов исходного текста программ (GUI, см. папку “Integration\RU”).
В SQL Server Management Studio (SSMS IDE): Главное меню :: Сервис :: Параметры :: Выполнение запроса :: По умолчанию открывать новые запросы в режиме SQLCMD (включить галочку).
Желательно добиться точной аккуратной подгонки окна Far Manager под рабочий стол, чтобы консоль была без вертикальной полосы прокрутки. Потребуется “поиграть” с настройками ярлыка программы (.LNK). Рекомендуемый шрифт: Consolas (для совместимости с Unicode). (Далее приводятся настройки, действующие на машине автора.) Размер шрифта: 18 не жирный (на экране 1920×1080, при масштабировании 125%). Размер буфера экрана: 158×43 + Перенос текстового вывода при изменении размеров: ВКЛ. Размер окна: 158×43. Положение окна: -4×-4 + Автоматический выбор: ВКЛ. Так же, для удобства запуска: Ярлык :: Быстрый вызов: Ctrl + Alt + F12 (или подобное).
Так же, предполагается, что в системе установлены клиентские утилиты MSSQL (SQLCMD, BCP) и прописан к ним соответствующий маршрут (как часть переменной PATH). Например: “C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn”.
Ещё, желательно отключить в системе возможность быстрого выделения консольного текста мышью (для устранения эффекта нечаянного такого выделения, приводящего к нежелательной остановке программного вывода на консоль): [HKEY_CURRENT_USER\Console] "QuickEdit"=dword:00000000.
(Для отражения внесённых изменений потребуется перезапуск Far Manager!)
См. также: SQL-file installation (оригинальная страница по технологии SQL-файл).
VI. SQL-QUERY-BRIDGE (АБСТРАКТНЫЙ НАБРОСОК ИДЕИ)
На корневой странице Handicraft-CODE (https://handicraft.remelias.ru/) присутствует загрузка “SQL-Query-Bridge Outline YYYY-MM-DD.7z”, содержащая набросок воображаемого SQL-проекта, для трансляции исходников запросов абстрактной утилитой-препроцессором SQL-Query-Bridge-PP. Предполагается, что существует специальный формат (структура), предназначенный для записи SQL-запроса (файлы вида “*.q.sql”, а также настройки “@*.*”), на основании чего утилита генерирует скрипт T-SQL создания хранимой процедуры, а также генерируется код C#, доступный для расширения пользователем (посредством partial-классов), CS-код для взаимодействия с соответствующим SQL-запросом, вместе с моделями данных Си-шарп (также создаются препроцессором). Пример содержит всего один запрос (T-SQL / C#): SelectBooks, являющийся аналогом одноимённого запроса из примера BookRegistry app. (из пакета Handicraft Toolkit). Данный набросок (формат запроса, проект, настройки) является фантазийным (чистая абстракция).
