Йуный джавистЪ...
Такая тулза есть, называется make, ну или аналоги. Пример мейкфайла:
...
Кстати, в своё время думали и над make-ом, а также к нему и си-шный препроцессор или аналог прикрутить. Но не нашли счастья в таком решении.
Я не приветствую здесь некоторую иронию в сторону автора этой темы, лично я разделяю его взгляды и попытки упростить жизнь. Ещё раз обращаю внимание, что речь идёт о существенных и тяжёлых проблемах при разработке БД, но с которыми, имхо, немалая часть разработчиков может и не сталкивалась в своей практике (возможно, лишь пока). Например, в моём случае есть огромные проблемы, когда целевая рабочая база для обновления не является условной копией (по метаданным) исходной эталонной (используемой при разработке). Т.е., как правило, чаще всего целевая база лишь некое подмножество исходного эталона, содержит только часть прикладных логических модулей (при этом взаимосвязанных). Кроме того, разработчики на местах могут расширять функционал, или вносить свои изменения. Причём существует вариантность одного и того же функционала в разных целевых базах, скажем, структура одной и той же таблицы отличается в зависимости от потребностей в каждом конкретном случае на местах, или код какого-нибудь триггера везде разный и т.д. и т.п. Утяжеляет ситуацию то, что целевых баз немалое количество, и процесс разработки/обновления, фактически, беспрерывный. Да и сами базы содержат немало логики внутри (такова историческая особенность), т.е. далеко не только таблицы с индексами, да и объектов в базе далеко не одна сотня и более. В этом случае многие стандартные/популярные средства вокруг серверов СУБД мало эффективны/неудобны или вовсе неработоспособны. В такой ситуации лично у меня большая нелюбовь ко всяким визуальным дизайнерам, от них гораздо больше мороки, чем пользы. Многие популярные средства для миграций типа liquebase, dbmaintener, dbdeploy и т.д. тоже хреновые помощники, ибо часто они не умеют работать с хранимками, триггерами и пр. (во всяком случае, адекватно) или требуют для этого того же ручного SQL-кодирования. Кроме того, они сами по себе нуждаются в некоем механизме для целеуказания, т.е. готовить "в лоб" вручную для них XML/json/sql-файлы и пр., требуемых на их входе, неудобно/проблематично.
Это часть айсберга, сам по себе и процесс разработки БД требует эффективности. Я хочу попытаться поделиться (упрощённо) со своими идеями насчёт некоего универсального тулза для облегчения жизни, с учётом своего опыта и уже имеющихся решений. Вокруг этого тулза частенько летают мысли, но до конкретных действий всё дело не доходит. Может быть, автору этой темы что-то пригодится для своих потуг, а если будет критика и конструктив, то буду весьма признателен.
Прежде всего, хочу отметить, почему именно такой подход (о нём ниже) взят на вооружение. В своё время пришло понимание того, что лучший DSL для разработки SQL-БД - это тот же SQL от самого же разработчика СУБД. Даже если делать свой велосипед, то, как правило, он будет вынужденно на него похожим и, чаще всего, функционально ограниченным. У меня приятные воспоминания о клиппере/фокспро (а с некоторыми древнейшими проектами и сейчас изредка приходится иметь дело), такого удобства для прикладного уровня производители платформ вокруг языков общего назначения, как жаба с нет-ом, так и не дали взамен (я имею в виду гармонию тех средств, об их технических особенностях и языковых проблемах речь не идёт). Имхо, если говорить о jvm, то, пожалуй, только у кложуры есть шансы, как у около промышленной платформы, включая и возможность интерактивной (а то и реактивной) разработки, и то, это для тех, кто может ужиться с лиспом. Но это всё лирика. Короче говоря, это решение для тех, кто нуждается непосредственно в SQL-кодировании. И при этом у предлагаемого решения нет привязки к какому-то диалекту или типу СУБД, теоретически, даже вместо SQL можно применять свой некий псевдо-SQL, к примеру, для разработки под разные СУБД (хотя это отдельная и ещё более плачевная песня).
Итак, всё рассчитано на разработку SQL-исходников "вручную", с некоторыми помогалками (об этом ниже). Глобально исходники делятся на две части: для создания БД с нуля, назовём её как create-часть, и исходники для изменения БД (накаты версий) - update-часть.
Забегая вперёд скажу, что я не буду говорить об операции отмены изменений, т.е. об откате версий. Прежде всего, по опыту - системы миграций используются в 99.99% случаев для наката последних изменений, т.е. для приведения базы в текущее актуальное состояние. Если требуется откаты изменений, то фактически это вырождается к созданию соответствующих новых правок в БД, и, как правило, всегда требует отдельной работы ручной кувалдой (ибо далеко не всегда просто это сделать). К тому же не всегда можно адекватно в общем случае отобразить парную операцию отката, скажем, для операции drop такой-то столбец в таблице - как для него написать парный откат, т.е. alter такой-то таблицы, где добавили столбец, но как восстановить данные? Т.е. требуются дополнительные телодвижения, специфичные для конкретного случая. Но на представленных здесь принципах вполне похоже реализуется и автоматическая операция отката, тем более закладывается возможность дополнительного программирования (см. ниже). Так что некий автоматический откат возможен, но я на нём не акцентирую отдельного внимания с целью здешнего упрощения.
Итак, структура исходников важна. Предлагается sql-файлы располагать по подкаталогам в зависимости от логического деления функционала, т.е. выделять некие логические модули (типовое решение для многих случаев). При этом крайне желательно выделять каждый объект в БД или группу крепко связанных друг с другом объектов в каждом отдельном SQL-файле (но важно не смешивать объекты разных функциональных типов). Например, можно вместе указать парочку таблиц, которые друг без друга ни как. Можно вместе с таблицей поместить и её индексы, а в то же время может возникать потребность указать некоторые индексы отдельно, скажем, в другом прикладном модуле (т.е. индексы должны создаваться только при наличии в БД определенного модуля) и т.д. В "create-части" в SQL-файлах указываются операции DDL для создания объектов, причём всегда в текущем актуальном состоянии.
"update"-часть содержит точно такую же структуру каталогов, как и "create-часть", и содержит sql-файлы для наката (возможно и отката) изменений в БД. При этом update-файл как бы является парным для соответствующего create-файла (т.е. некий аналог си-шного заголовка и его c/cpp-реализации). Внутри update-файла содержатся DDL-операции для модификации созданного объекта, в нужной последовательности с метками версий, при этом есть копия DDL для самого первого варианта облика этого объекта (т.е. стартовый DDL). Примерно так (для таблицы):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
#ver 2013-04-29.000
create table ... -- здесь исходный оператор (нулевая или базовая версия объекта)
#ver 2013-04-29.001
alter table ... -- новая версия 001
#ver 2013-04-29.002
alter table ...; -- новая версия 002
alter table ...;
Синтаксис меток, что там должно быть указано - номер, дата, автор и т.д. - пока опускаем (всё должно настраиваться). При этом парный create-файл на данный момент должен содержать оператор "create table ..." согласно последней версии.
Сейчас подобный подход используется на практике, но за исключением истории изменений. Сейчас каждая правка объектов оформляется отдельными файлами, формируется его спец-имя (содержащая инфу про версию), складываются изменения в спец-каталоги (в зависимости от дат, версий и пр., в общем, есть по-всякому). Мне кажется, что концептуально иметь только два файла - "create" и "update", т.е. как некий аналог си-шной разработки - проще, меньше плодятся файлы, к тому же в одном файле сразу можно изучить всю историю и т.д. Не исключено, что историю можно разделять на два и более файлов, главное, чтобы тулза понимала.
Не все create-файлы могут иметь парный свой "update". Например, плодить текст процедуры/триггера как-то геморно, явно размазывая его по истории. В этом случае лучше поступать также как с обычными исходниками приложений, т.е. править только create-файл, он всегда содержит текущую версию. Если нужно получить какую-то версию, то извлекаем её из системы контроля версий исходников, в т.ч. можно извлечь в сторонке сразу весь набор sql-каталога требуемой версии. Когда тулза делает накаты изменений, то она должна понимать, что явной истории (update-файла) может не быть. В этом случае важно иметь правильный DDL-оператор (вида, "create or replace/alter ...", т.е. выполняемый многократно).
Кроме создания явных объектов в БД файлы могут содержать некие вычисления, блоки кода, не сохраняемые в БД, или операции правки данных в таблицах и т.п. Они оформляются точно также (парные файлы), логически привязываясь к прикладным модулям.
Тулза должна иметь как минимум две операции: создание базы с нуля и выполнить накат изменений. Для создания базы обрабатываются create-файлы, для накатов - update-файлы, с учётом того, что их может и не быть, и сам create-файл есть последняя версия. Естественно, внутри БД необходимы специфичные таблицы, где будут фиксироваться проведенные действия, в т.ч. и версии примененных sql-файлов (а точнее, версии действий внутри этих файлов). Кроме того, важно, чтобы была возможность выполнять частичные операции, т.е. отдельно в разрезе прикладных модулей. К примеру, обновить модули/подмодули только XX и YY, при этом тулза должна понять, что, например, модуля YY ещё нет в целевой базе, соответственно для него нужен "create". Или тулза должна понять при обновлении, что база содержит только модуля XX и YY, остальные в неё вносить нельзя. И т.д.
Для тулса важно понять как строить последовательность действий. Для этого ей важно понимать тип sql-файла, т.е. что в нём может содержаться. Для этого можно применить несколько способов:
- через стандарты именования файлов. К примеру, файлы для создания/модификации таблиц можно задать как-то так: xx_foo_tbl.sql, где "xx" - имя прикладного модуля/подмодуля, "foo" - имя таблицы, "tbl" - признак, что это таблица. Или таблицы не имеют суффикса, а все остальные имеют: sp - stored procedure, biu_03 - триггер before insert or update position 3 (добавляется к имени таблицы) и т.д. Или через расширения: xx_foo.tbl, или двойное - xx_foo.tbl.sql
Короче говоря, всё настраивается;
- с помощью дополнительного описания в виде каких-то файлов проекта, свой DSL-велосипед или стандарт а-ля XML/json;
- с помощью явного управления файлами, к примеру, некоего оператора "input/include <файл>" (что часто имеется во многих sql-тулсах).
Вариант без дополнительной механической писанины проще, меньше подвержен ошибкам в указании последовательности (хотя можно ошибиться при именовании файла, к примеру). Кроме того, чем меньше писанины в каких-то общих файлах между разработчиками, тем меньше элементарных конфликтов в рамках системы контроля версий исходников.
Если тулса сама строит последовательность действий, то она должна понимать, что, например, сначала нужно выполнить глобальные объявления (типы/домены, переменные и пр.), затем, скажем, создать таблицы, потом - заголовки процедур/функций/пакетов или что-то в этом роде, затем - их тела и т.д., триггеры, где-то под конец строить индексы, выполнять пользовательские вычисления (тот же insert данных в таблицы) и т.д. Короче говоря, это настраивается, как минимум, эти правила СУБД-зависимые.
Чтобы правильно выполнять все выкрутасы выше важно понимать зависимость между прикладными модулями. Задать можно по-разному. Частично что-то можно понять автоматически через инфу в метаданных у БД, т.е. зависимость между таблицами, какие таблицы использует такая то хранимка и т.д. Но это не та зависимость, эти механизмы лишь могут помочь для указания зависимости между своими логическими sql-модулями. К тому же, часто нет технической связи между объектами внутри БД согласно метаданным, но эти объекты используются приложением/сервером приложений, поэтому логические связи нужно указывать явно (или через помощников, об этом далее). И, если, скажем, указали, что модуль XX требует для своей жизни модуля YY, то тулса должна не забыть, что если ей при операции не указали явно модуль YY, то она должна его учитывать, причём в первую очередь, ну и все связи по цепочке.
Сами связи можно указывать, к примеру, в файлах проекта, если они используются. Или, если стремиться к минимуму, то можно прописывать внутри исходников. Пусть файл вида "xxx.sql" (без лишних суффиксов/префиксов и пр.) означает логическое объявление самого модуля XXX, где, как правило, будет соответствующая описательная документация, некие глобальные объявления, настроечные вычисления и т.п. И где-то, пусть в начале, будет указан спец-оператор вида:
#uses YY, ZZ
(или import (хотя это как бы не то), using, require или что-то по вкусу). Зависимости указываются в разрезе логических единиц, т.е. модулей/подмодулей, которыми и оперируют в рамках создания/обновления баз.
Далее о том, чего так категорически не хватает во всех типовых sql-тулсах. SQL- язык предметно-ориентированный, относительно мощный, но специализировано, у него нет широких универсальных вычислительных возможностей (это не его стихия), что сильно ограничивает в разработке "в лоб". Поэтому есть вполне оправданные в данном случае средства, которые здорово выручают (что проверено на практике):
- препроцессор. Вполне сгодится по си-шным мотивам: #if, #ifdef, #elif, #else, #endif, #define, некий #undef и пр.
Т.е. даётся возможность для условной компиляции, использованию макросов (в т.ч. с параметрами), можно реализовать некие настроечные параметры, задаваемые в исходниках и чьи значения можно устанавливать/переопределять через ключи в командах тулсы. Как это может выглядеть - см. ниже;
- средства для автогенерации кода. На своей практике неплохо прижился подход, как в
Cog - кодогенератор под питон. Вот картинка оттуда:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
// This is my C++ file.
...
/*[[[cog
import cog
fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
for fn in fnames:
cog.outl("void %s();" % fn)
]]]*/
//[[[end]]]
...
Что превращается в:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
// This is my C++ file.
...
/*[[[cog
import cog
fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
for fn in fnames:
cog.outl("void %s();" % fn)
]]]*/
void DoSomething();
void DoAnotherThing();
void DoLastThing();
//[[[end]]]
...
Думаю, идея понятна. Питон не обязателен, можно задействовать что угодно. Есть смысл подогнать синтаксис под препроцессор и увязать с прочими внутренними командами, т.е. как-то так:
1.
2.
3.
4.
5.
#[[
<код>
]]
...
#go -- как аналог go или "/" во многих sql-консолях
В общем, синтаксис нужно адаптировать, чтобы не было конфликтов с глобальным SQL. Возможно, что всё внутреннее для тулсы нужно именовать со своего внутреннего префикса, как это делают ряд универсальных инструментов, вида
SQL Workbench/J . Пока сказанное только концепт, сейчас это не важно.
Таким образом, кодогенерация реально упрощает жизнь, в т.ч. есть потенциал как для генерации текста sql-кода, так и исходников приложения на основе sql-файлов, структуры БД и т.п.
Также в тулсе очень не помешает поддержка документации на основе комментариев. Я уже давал пример:
pldoc . Вместо синтаксиса JavaDoc можно воспользоваться из LuaDoc, т.к. есть близость комментариев: "--" вместо "//".
А если ещё будет поддержка средств для форматирования текста - вообще замечательно.
Теперь о том, в каком соусе всё это (возможно) нужно. Если говорить о реализации под java, то ядро системы должно быть относительно независимо, т.е. иметь потенциал для создания как самостоятельного приложения (под консоль), так и куда-то встраиваться. Желательно иметь возможность для создания плагинов для всяких IDE, не помешает связь с уже имеющимися там плагинами для работы с SQL-серверами. Плюс желательна реализация самостоятельного сервера, по типу сервера в эмакс или JEdit, чтобы он висел себе и реагировал на команды, постоянно не перезапускаясь, не разрывал соединение с базой и т.д. Иными словами закладывается возможность работы как в командной строке, так и интерактивно из редакторов/IDE. Например, в своём любимом редакторе выделил текст, клацнул - и текст преобразовался - т.е. получил кодогенерацию. Или из редактора выполняешь запросы к базе с учётом обработки препроцессора, или получаешь обработанный текст запроса, и т.д. и т.п.
При этом важно иметь расширяющийся функционал, в виде каких-то бинарных плагинов, а также в виде поддержки скриптования, как на BeanShell-е (чтобы "скриптовать" на самой java как языке), так и остального груви, руби, питона и пр. Это даст потенциал для создания универсальных плагинов под разные СУБД, библиотек/фреймворков и т.д. (хотя если вдруг проект потенциально пойдёт в жизнь, то потребность в развитии будет аховая, особенно если развивать интерактивную часть, типовые БД-консольные команды будут обязательными, форматированный вывод в виде текста, XML, HTML и т.д., хочется и автокомплита). Очень помогает (или фактически обязателен) для плагинов набор API для парсинга текста (он всё-равно есть в потрохах), чтобы анализировать имеющийся sql-текст и т.д.
Вот такой концептуальный взгляд. В своё время много думалось над потенциальном упрощением, о некой реализации по мотивам крутых sql-инструментов. Например, реализовать полный разбор SQL. Тогда, скажем, есть возможность упростить написание "update"-части, сократив её до минимума. Например, тулса может сделать разбор оператора "create table ..." в sql-исходнике, с учётом препроцессора и кодогенерации, сравнить с тем, что есть в базе и выполнить или сформировать нужные "alter table ...". Вроде гораздо меньше писанины при разработке в итоге, но есть и минусы:
- реализация полноценного и всеобхватывающего разбора SQL - задача неслабая, особенно под разные СУБД;
- не всегда существует один единственный способ для операций, скажем, те же таблицы можно создавать по-разному, в т.ч. и через процедуры на сервере, которые сами генерируют текст SQL-кода и его исполняют (если СУБД такое позволяет). Иными словами тогда необходимо вводить ограничения для sql-вольности (хотя те же препроцессор с кодогенерацией частично облегчают жизнь);
- операции по обновлению баз становятся непростыми (по технической реализации), довольно медленными, в некоторых случаях легко получить неприемлемое время для update базы, а то и вовсе всё может загнуться.
А представленный текущий вариант имеет недостаток: весьма проблематично выявить, что после внесения изменений в базу их никто не правил, каждый следующий накат опирается на то, что состояние базы такое же, как и после внесения последних изменений. Проблема решается дополнительными телодвижениями, к примеру, можно создать базу из исходников, с учётом всех нужных настроек и сравнить с тем (через стандартный/типовой придворный инструментарий), что есть в рабочей базе (в её копии) после актуального наката.
К чему этот весь эпос. Кроме того, чтобы дать пищу подумать автору этой темы и другим, было бы не плохо, если кто-то поделится своей практикой, подскажет, как всё выше сказанное можно заменить без гемора и т.д.
Ниже я даю ссылку на архив, где есть пример SQL-препроцессора. Делала его когда-то некая конторка "Олис" в лохматых 90-х, он простой, но не потерял своей актуальности, это пример, как можно выкручиваться. В архиве также документик-проект по некоему стандарту проектирования БД от тех же авторов. Якобы всё заточено под InterBase, но там фактически только одна особенность: обрабатывается команда input <путь\файл>, в остальном - к SQL тулса нетральна. Есть особенность в синтаксисе самих директив и макросов препроцессора, ибо делалось по подобию Delphi. Сейчас сайта авторов давно нет, раньше всё было свободно доступным, поэтому надеюсь, что авторы заочно не против публикации их труда.
P.S. Сорри, что много букв (меня самого задолбало набирать). Сорри, что возможно это и офтоп, хотя эта тема форума пошла в такое русло. Просто подобные темы задевают за живое, ибо адекватного решения проблем пока нет.
Скачать:
SQLPrecompile
