Максим НДля начала в описание объекта планирую добавить порядковое поле "priority", по которому можно ранжировать элементы.
А вообще я еще задумывался о т.н. шаблонах сборки, т.е. некие пользовательские структуры (тот же xml или что то другое, неважно), в которых будет описан порядок сборки жлементов для разных случаев.
...
По поводу выключения зависимых элементов при сборке, если честно, то не думал об этом, может стоит задуматься о возможности указывать зависимости в описании типов, если это понадобится.
...
Хранение и организацию алтеров таблицы (добавление полей) я пока не рассматриваю. Для этого есть спец. средства, всякие миграторы, с их чэйнжсетами и др. Надо будет подумать как с ними подружиться, можеть объявлять элементы или еще как то, пока не знаю...
...
Смысл тулзы не только в том, чтобы выявлять косяки и давать разработчикам по шапке (хотя можно и так использовать).
В любом случае Регламент и прочие организационные мероприятия это здорово и без них естественно никуда, но когда под боком есть инструмент, который "поможет" сделать правильно и снизит уровень ошибки для разработчика, а для руководителя предоставит какие либо средства для более быстрого анализа полученного кода, думаю это не плохо. Тем более когда регламент изменяется (а от этого никто не застрахован), то вручную организационно все отследить и переделать будет достаточно проблематично (в зависимости от проекта конечно).
ПС была у меня еще идея конвертера, который сможет привести файлы, хранящиеся под одной структурой к файлам другой структуры...
...
Не не, я не предлагаю ничего запрещать и строить (куда мне там). Я и сам пользуюсь ИДЕ'шками. Просто предлагаю результат труда немного орагнизовать, структурировать, версионировать, задуматься о том, что за код генерят эти замечательные инструменты, как (а еще зачем...), ну и т.д. тут уже много об этом написано. Вот и все.
Ты как-то давал
ссылку на пример стандарта разработки БД, некий официальный от Oracle. Насколько я понимаю, твоя первичная цель организовать поддержку ведения подобной разработки. Но в таком виде, имхо, мало кто сможет пользоваться этой тулзой.
Все хотят как можно меньше возни и больше удобств. Рассмотрим тех, кто работает в GUI-DBIDE. Сначала нужно запустить в консоли jar-ник, чтобы создать новый объект, для чего будет создан файл с шаблоном и/или каталог, или в каком-то файле чего-то нового добавиться. Теперь в GUI нужно открыть этот файл, его редактировать, сохранить, выполнить и пр. Как правило, такая возня в GUI-IDE утомительна. DB-IDE, фактически, не занимаются ведением файловой структуры, обычно текстовые файлы для них - это просто импорт/экспорт содержимого текстового редактора в каком-то GUI-режиме. Поэтому, в основном, и предпочитают работать уже именно в GUI - где-то кликнули, на основе шаблонов для именования объектов вылазит какой-то режим, где вводят структуру таблицы или т.п., или создаётся в текстовом редакторе шаблон для правки содержимого будущего объекта, и т.д. Сразу всё сохраняется в БД, могут быть средства для организации проектов внутри БД (объединения объектов по своим кучам), свой контроль версий и история, распределение доступа по разработчикам и т.д. Одним словом, если уж GUI, то проще в нём же и ковыряться. Некоторые только ими и обходятся, натравили инструмент на сравнение двух баз - всё автоматом обновилось или создали скрипт для наката. Кто-то создаёт дамп БД, кладёт на всякий случай где-то рядом. Кто-то отдельно складывает sql-скрипты по папочкам, на основе утверждённого стандарта, или/и складывает скрипты для всяких накатов версий или для дополнительной обработки БД после создания или правки. Но в этом случае уже проще из GUI выгрызать нужные тексты и кидать их в файлы, т.к. GUI упрощает их создание (тут только контекстно-зависимый автокомплит может заставить работать именно с GUI). Но, обычно мало кого волнует в каком виде будут конечные тексты. Некоторым они просто нужны по принципу "чтобы было" (ну, может иногда СКВ дадут где-то конфликт правки одного и того же объекта, к примеру), в любом случае, отношение к ним где-то на уровне просто как списку команд, чтобы выполняли молча свои действия и всё, нет с ними работы как с первичным материалом.
Те, кто работает с SQL-исходниками именно как с исходным материалом. Обычно их заставляет жизнь, т.к. требуется широкий и гибкий функционал, некоторая инвариантность (не обязательно глобального функционала, например, нужно создавать БД с тестовыми или первичными данными в разных вариантах или без них и т.п.). Некоторым просто удобнее работать в текстовом редакторе или какой-то не DB-IDE, рядом с разработкой клиентской для базы части. И т.д. Короче говоря, задача создания новых файлов для новых объектов по определенным правилам при необходимости решается через редактор/IDE (и даже удобнее, скажем, дал команду - сформировался каталог с файлом, файл загрузился в буфер и сразу запустился интерактивный сниппет а-ля как в ТекстМейте). Задача удаления файлов или части файла согласно операции удаления объекта в БД автоматом решается лишь частично, не всегда есть только явные технические связи, частенько хватает и логических отношений, а всего сразу не наконфигурируешь. И задача реорганизации исходников в иную форму тоже автоматом выполнима лишь отчасти, опять же, если учитывать прикладную логику в проекте. Задачу верификации исходников очень и очень маловероятно решить только на универсальных настройках с ограниченным понятием отношений.
Иными словами, выше перечисленные задачи на практике второстепенны или имеются способы их решений (а ту же задачу анализа кода такой инструмент вряд ли решит или совсем чуть-чуть, но хоть что-то). Поэтому ради этих функций на такую утилиту вряд ли массово посмотрят. Основная задача при работе с sql-исходниками - это их "компиляция", т.е. создание БД и её модификация, плюс решение вспомогательной рутины. Более того, именно эта "компиляция" - ключевой момент, это основа основ для ведения каталога исходников, именно это и предопределяет всю пляску вокруг исходников, и часто диктует правила, как эти исходники оформлять. И если инструмент для исходников не обеспечивает решение для компиляции/сборки, то он мало будет востребован.
Ну а чтобы решить задачи компиляции/сборки через такую утилиту при её таком подходе, универсальном и настраиваемом, естественно требуется дальнейшее развитие. А вот развитие весьма проблематичное. Сейчас в конфигурационных настройках не хватает гибкости, кроме явной технической связи между элементами как объектами БД необходима "шаблонизация" для задания логики разбиения по прикладным модулям (это востребовано). Чтобы создавать БД необходимо понимать смысл каждого элемента, или нужна их взаимосвязь и нужно определять очерёдность создания элементов. Причём нужны настройки для очерёдности не только согласно их типам (т.е. сначала нужно создавать таблицы, затем индексы и отношения, заголовки процедур, пакетов и пр., затем их тела и т.д.), но и может потребоваться явная последовательность для элементов одного вида (например, правильно располагать какие-то блоки кода, которые выполняются после создания или накатов и т.п., или накаты через всякие alter-ы с возможной правкой отношений или связанных объектов, и т.д.). Поэтому, уже есть какая-то потребность в шаблонной последовательности (кроме явной организации элементов внутри файла), пусть будет нумерация на уровне файлов (т.е. 01_sqript1.sql, 02_script2.sql), и это должно как-то настраиваться. Далее, если закладываться на какую-то инвариантность, то нужны какие-то признаки для элементов. Поскольку "Start/Stop-text" - это метки для поиска "в лоб", то остаётся использовать признаки на уровне файлов, например, как в DbMaintain (т.е. аннотации через "@" или "#", их может быть несколько), или дорабатывать метки "Start/Stop-text". Тогда появляется возможность задать какие-то варианты сборки исходников, или кроме сборок баз можно писать сценарии для вспомогательных рутин, например, извлечь только тестовые данные для таблиц (плюс код для предварительного их удаления) и т.п.
По своему опыту. Такое развитие я уже проходил, был концептуально фактически похожий велосипед, и пришлось утонуть в бесконечной шаблонизации. Частично такой подход решает проблемы, но не все и задалбывает конкретно. Прямое программирование "в лоб" оказалось проще, естественнее и быстрее, без всякой xml- и подобных конфигураций, всё на основе стандартных sql-операторов. Я уже давал раньше ссылки и что-то где-то выкладывал, но опять ниже выложу всё сразу до кучи - пример некоего стандарта для разработки БД. Фактически, там организация проекта похожа на тот стандарт от оракл (ссылка выше), за исключением возможной разбивки исходников по подпроектам и есть явная последовательность сборки (через операторы "input", аналог "start"-а). Плюс натравливается велосипед-препроцессор и получаем разные варианты сборок БД и сборок скриптов-сценариев для рутины. В результате - гибкость, и инструмент даёт полную свободу под конкретные нужды. Недостаток - есть явное ручное описание этих "input-ов", причём из-за них как бы имеются общие файлы между разработчиками, но конфликты их правки разруливаются фактически автоматом. Ну и неплохо иметь какой-то плагин где-то, который помогает чего-то sql-генерировать, в т.ч. создавать новые файлы и шаблоны и эти start/input и т.д., SQL - тяжкая хрень.
Сейчас, под действием этой темы форума, я вновь ломаю мозги над новым вариантом разработки БД. У нас используются костыли по выше приведенным мотивам (т.е. на базе выложенного стандарта). В основном, напряжно следующее:
- выделять каждый объект в отдельный файл (в большинстве случаев) как-то геморно, слишком много файлов, причём частенько небольших. К этому, прежде всего, принуждает ручное управление последовательностью (через input/start), т.к. грануляция на уровне файлов;
- хотелось бы писать как можно меньше, несмотря на всякие помогалки. Например, принят подход иметь create-скрипты для создания БД в текущей последней версии и отдельно update-скрипты для накатов версий (пусть без откатов, с ними обычно только больше гемора). С одной стороны, хорошо - имеется сразу в одном месте вся необходимая информация, например, "create table ..." сразу в конечном виде в актуальном состоянии, и все его "alter"-ы отдельно в истории или в накатах. Соответственно не нужно для каких-то вспомогательных целей собирать всё до кучи: брать базовый "create table" и слепливать размазанные по коду его "alter"-ы (и, например, в редакторе достаточно в соседнем буфере открыть только один файл с "create..." и он уже обеспечит быстрый автокомплит по словам (вместо контекстного, когда его нет или он хреновый)). Но с другой стороны - лишняя писанина (хорошо, если есть помогалки).
Ещё масло в огонь подкинул проект
Sqlmake , здесь на него кто-то давал ссылку. Вот примерно о подобном подходе в организации проекта, только по гибче, как-то и думалось раньше. Там выделяется как бы две части исходников - модель данных (грубо - таблицы с индексами) и "повторяемый код" - в основном PL/SQL ("CREATE OR REPLACE ...") и др. Сюда бы добавить некий явный "постпроцессинг" как в DbMaintain. Накаты в рамках модели задаются явно, и это правильно, т.к. в общем случае нельзя всё автоматизировать (т.е. автоматом сравнить две структуры, к тому же, это может оказаться далеко не быстрым процессом). Например, добавляется столбец как not null в таблицу с уже имеющимися данными, нужно знать чем заполнить данные (нулём/пустой строкой или чем-то другим), при этом нет данных о default-значении. А вот plsql и др. накатывается автоматом, на основе данных в БД. Причём, например, если DbMaintain накатывает "повторяемый" код на основе версии файла (или его даты), то Sqlmake основывается именно на исходном коде, вычисляет изменения, при этом ом может понять, что если какой-то файл удален или объект удален в исходнике или закомментирован, то значит нужен соответствующий "drop".
Но нужно ещё подумать об удобной организации разбивки исходников по прикладным модулям/подмодулям с зависимостями, где в каждом модуле нужно вести свою "datamodel", причём так, чтобы достаточно было иметь только базовый "create table ..." и грамотно расположены связанные "alter" (тут всё-таки есть потребность в явной последовательности операций, причём перемешанной вокруг разных объектов, например, если СУБД не позволяет удалить используемый столбец, то предварительно нужно зависимые объекты сделать пустыми, чтобы убрать эту зависимость). Плюс для "инвариантности" можно подогнать "велопрепроцессор". Тут вспоминали про Rust, как раз можно добавить к условным директивам понятие аннотаций как у него (или как в жабе) по таким мотивам:
1.
2.
3.
4.
5.
6.
7.
8.
9.
#[ifdef USE_IS_PLAN]
alter table BBBB
add IS_PLAN NUMBER(1) DEFAULT 0;
update BBBB set
#ifdef PLAN_SET_AS_TRUE
IS_PLAN = 1;
#else
IS_PLAN = 0;
#endif
Т.е. "#[...]" означает атрибут/аннотацию для конкретного SQL-оператора или группы операторов, если они расположены вместе, что уменьшает писанину именно как "if-else-end". Ряд СУБД имеют свой арсенал для создания вариантного кода, т.е. непосредственные sql-операторы вида "if not exits ... then create ...", но при этом выполняется манипуляция самим сервером на основе инфы внутри БД, а не на основе текстовой конфигурации сборки. Частично некоторый функционал реализует ряд придворных инструментов, например, подмена переменных в sql plus, но лишь частично.
Но для реализации такой тулзы нужен полноценный разбор текста, причём нужны расширения как плагины, понимающие конкретный sql-диалект и потроха СУБД. Тогда возможно и решение смежных задач, вида поддержки доков-комментариев, создание скриптов как "create" в последней или нужной версии (т.е. все alter-ы свёрнуты в общий итог) и т.д. Возможно форматирование исходников и их реструктуризация (управляемая), а также и некоторая верификация. А если уж говорить о создании полноценного db-tools, то очень не хватает подобным инструментам интерактивности. Т.е. чтобы можно было запустить сервер, как emacs или JEdit, он постоянно висит себе и держит соединения с БД, к нему коннектишься, по своему протоколу или хоть с комстроки, хоть по rest-у и пр., он динамически выполняет sql-запросы, управляет каталогом sql-исходников, даёт автокомплит и т.д. И тогда пиши себе плагин хоть для иклипса, хоть для vim-а и пр., или вэб делай.
Но это всё мечты и мысли в слух. А так, я это всё к тому, чтобы дать рекомендацию. Если разрабатываемая утилита удовлетворит какие-то свои конкретные потребности, то и хорошо, и увлекаться глобальной и супер-шаблонизацией особо нет смысла.
Стандарт разработки БД (см. выше):
