PSV100Ты как-то давал ссылку на пример стандарта разработки БД, некий официальный от Oracle. Насколько я понимаю, твоя первичная цель организовать поддержку ведения подобной разработки. Но в таком виде, имхо, мало кто сможет пользоваться этой тулзой.
Да, это был один из первых мне попавшихся документов, посвященных организации разработки БД. Не синтаксису ("табличка создается таким оператором, хранимая процедура таким и т.д."), а именно так сказать "хозяйственной" части. Как хранить код, как называть объекты. Кстати автор данной статьи так же сравнивает "доставание" объектов из СУБД с декомпиляцией бинарных файлов приложения. Еще у этого автора есть интересный
проект (кстати представленная документация это часть данного проекта), это PL SQL фреймворк, универсальный каркас для приложений БД, с продуманными заранее стандартными вещами и функционалом. Но почему то такие вещи пользуются достаточно малой популярностью.
В том же мире Java (и нетолько) существует куча всяких фреймворков и всяких "наростов" и прибамбасов вокруг них, которые позволяют человеку может не очень сведующему в разработке, начинающему, уже на отточеном продуманном каркасе построить свое приложение, доработав его нужым кодом. Т.е. практически не заниматься организационными делами, а только функционалом. (И кстати не всегда это спрятано в ГУИ, можно легко использовать свой полюбившийся редактор(иде) и утилиты). Там уже все продумано, модели хранятся здесь, контроллеры здесь, а вот представления там, дата классы там ну и т.д. Взять тот же самый Play Framework. И плюс к таким вещам есть куча заточенных специально под них инструментов и библиотек, которые легко и предсказуемо пристегиваются к вашему приложению. Т.е. разработка ведется не с нуля и не на останках предыдущего (или чьего-нибудь) проекта, где есть похожий нужный функционал и подходяшая архитектура.
PSV100Все хотят как можно меньше возни и больше удобств. Рассмотрим тех, кто работает в GUI-DBIDE. Сначала нужно запустить в консоли jar-ник, чтобы создать новый объект, для чего будет создан файл с шаблоном и/или каталог, или в каком-то файле чего-то нового добавиться. Теперь в GUI нужно открыть этот файл, его редактировать, сохранить, выполнить и пр. Как правило, такая возня в GUI-IDE утомительна. DB-IDE, фактически, не занимаются ведением файловой структуры, обычно текстовые файлы для них - это просто импорт/экспорт содержимого текстового редактора в каком-то GUI-режиме. Поэтому, в основном, и предпочитают работать уже именно в GUI - где-то кликнули, на основе шаблонов для именования объектов вылазит какой-то режим, где вводят структуру таблицы или т.п., или создаётся в текстовом редакторе шаблон для правки содержимого будущего объекта, и т.д. Сразу всё сохраняется в БД, могут быть средства для организации проектов внутри БД (объединения объектов по своим кучам), свой контроль версий и история, распределение доступа по разработчикам и т.д. Одним словом, если уж GUI, то проще в нём же и ковыряться. Некоторые только ими и обходятся, натравили инструмент на сравнение двух баз - всё автоматом обновилось или создали скрипт для наката. Кто-то создаёт дамп БД, кладёт на всякий случай где-то рядом. Кто-то отдельно складывает sql-скрипты по папочкам, на основе утверждённого стандарта, или/и складывает скрипты для всяких накатов версий или для дополнительной обработки БД после создания или правки. Но в этом случае уже проще из GUI выгрызать нужные тексты и кидать их в файлы, т.к. GUI упрощает их создание (тут только контекстно-зависимый автокомплит может заставить работать именно с GUI). Но, обычно мало кого волнует в каком виде будут конечные тексты. Некоторым они просто нужны по принципу "чтобы было" (ну, может иногда СКВ дадут где-то конфликт правки одного и того же объекта, к примеру), в любом случае, отношение к ним где-то на уровне просто как списку команд, чтобы выполняли молча свои действия и всё, нет с ними работы как с первичным материалом.
С ребятами ИДЕшниками, все понятно. Если ГУИ полностью устравивает, подходит под задачи и ничего большего не требуется, то почему нет. Я и не пытаюсь сказать что это плохо, "так никто не делает" или "а давайте делать так". Просто если в проекте БД это немного нечто большее чем набор плоских табличек, забитых под мощным гнетом ОРМ, то тогда можно посмотреть на ее разработку с другой стороны, например (как всего лишь один из вариантов) как в рассматриваемой тулзе.
PSV100Те, кто работает с SQL-исходниками именно как с исходным материалом. Обычно их заставляет жизнь, т.к. требуется широкий и гибкий функционал, некоторая инвариантность (не обязательно глобального функционала, например, нужно создавать БД с тестовыми или первичными данными в разных вариантах или без них и т.п.). Некоторым просто удобнее работать в текстовом редакторе или какой-то не DB-IDE, рядом с разработкой клиентской для базы части. И т.д. Короче говоря, задача создания новых файлов для новых объектов по определенным правилам при необходимости решается через редактор/IDE (и даже удобнее, скажем, дал команду - сформировался каталог с файлом, файл загрузился в буфер и сразу запустился интерактивный сниппет а-ля как в ТекстМейте). Задача удаления файлов или части файла согласно операции удаления объекта в БД автоматом решается лишь частично, не всегда есть только явные технические связи, частенько хватает и логических отношений, а всего сразу не наконфигурируешь. И задача реорганизации исходников в иную форму тоже автоматом выполнима лишь отчасти, опять же, если учитывать прикладную логику в проекте. Задачу верификации исходников очень и очень маловероятно решить только на универсальных настройках с ограниченным понятием отношений.
Все зависит от проекта и его сложности. Может удалить или переконвертить явно 100% и не получится, но как минимум тулза может показать, что при удалении этого объекта у вас есть еще несколь зависимых объектов, которые без него будут невалидными и предлагает их удалить тоже или отменить текущую операцию. Т.е. некторый каркас, помощник, некое воплощение(частичное хотябы) Регламента разработки.
PSV100Иными словами, выше перечисленные задачи на практике второстепенны или имеются способы их решений (а ту же задачу анализа кода такой инструмент вряд ли решит или совсем чуть-чуть, но хоть что-то). Поэтому ради этих функций на такую утилиту вряд ли массово посмотрят. Основная задача при работе с sql-исходниками - это их "компиляция", т.е. создание БД и её модификация, плюс решение вспомогательной рутины. Более того, именно эта "компиляция" - ключевой момент, это основа основ для ведения каталога исходников, именно это и предопределяет всю пляску вокруг исходников, и часто диктует правила, как эти исходники оформлять. И если инструмент для исходников не обеспечивает решение для компиляции/сборки, то он мало будет востребован.
Компиляция/сборка это основная функция для меня. Т.е. мне нужен инструмент, которому я скажу: "мне нужны PLSQL пакеты PERSONS_MANAGER и SALARY_MANAGER, а так же все пакеты из модуля <<заработная плата>>, и еще все пакеты из модуля <<налоговый учет>>, которые были созданы не раньше чем 2 дня назад" (вполне реальная задача), а на выходе получить готовый скрипт, где пакеты будут в нужном мне порядке (например сначала заголовки, а потом тела), в начале будут вставлены подготовительные скрипты (например включение логирования, всяких режимов там, команды утилите-сборщику (например sqlplus-операторы)), а в конце завершающие операторы (отображение ошибок, регистрация чего нибудь). Так же вставлять чего-нибудь между скриптами (нгапример если я храню оракловые пакеты без завершающего слеша, то в скрипте для sqlplus'а, они должны быть с ним). Да придется потратить некоторое время на описание структуры, но в будущем это позволит сэкономить много времени и нервов. Если получится обойтись без xml (или с его минимумом), а только разбором sql-операторов, то буду только рад.
PSV100Ну а чтобы решить задачи компиляции/сборки через такую утилиту при её таком подходе, универсальном и настраиваемом, естественно требуется дальнейшее развитие. А вот развитие весьма проблематичное. Сейчас в конфигурационных настройках не хватает гибкости, кроме явной технической связи между элементами как объектами БД необходима "шаблонизация" для задания логики разбиения по прикладным модулям (это востребовано). Чтобы создавать БД необходимо понимать смысл каждого элемента, или нужна их взаимосвязь и нужно определять очерёдность создания элементов. Причём нужны настройки для очерёдности не только согласно их типам (т.е. сначала нужно создавать таблицы, затем индексы и отношения, заголовки процедур, пакетов и пр., затем их тела и т.д.), но и может потребоваться явная последовательность для элементов одного вида (например, правильно располагать какие-то блоки кода, которые выполняются после создания или накатов и т.п., или накаты через всякие alter-ы с возможной правкой отношений или связанных объектов, и т.д.). Поэтому, уже есть какая-то потребность в шаблонной последовательности (кроме явной организации элементов внутри файла), пусть будет нумерация на уровне файлов (т.е. 01_sqript1.sql, 02_script2.sql), и это должно как-то настраиваться. Далее, если закладываться на какую-то инвариантность, то нужны какие-то признаки для элементов. Поскольку "Start/Stop-text" - это метки для поиска "в лоб", то остаётся использовать признаки на уровне файлов, например, как в DbMaintain (т.е. аннотации через "@" или "#", их может быть несколько), или дорабатывать метки "Start/Stop-text". Тогда появляется возможность задать какие-то варианты сборки исходников, или кроме сборок баз можно писать сценарии для вспомогательных рутин, например, извлечь только тестовые данные для таблиц (плюс код для предварительного их удаления) и т.п.
Здесь тоже соглашусь. Я думал (и немного писал уже) о планируемом механизме сортировки и отбора объектов и их элементов (на сонове неких шаблонов, по дате модификации, по алфавиту и т.д., здесь нужна особенная гибкость), но это пока не реализовано. Решение в лоб в ввиде start(stop)Text, поля priority это временные базовые решения, сделанные для того, чтобы показать как примерно утилита будет работать, для чего она нужна, чтобы можно было пощупать. Ну а когда под рукой есть что осязаемое, то и новые мысли и старые проблемы становятся более ясными. То что есть сейчас это не более чем прототип.
PSV100По своему опыту. Такое развитие я уже проходил, был концептуально фактически похожий велосипед, и пришлось утонуть в бесконечной шаблонизации. Частично такой подход решает проблемы, но не все и задалбывает конкретно. Прямое программирование "в лоб" оказалось проще, естественнее и быстрее, без всякой xml- и подобных конфигураций, всё на основе стандартных sql-операторов. Я уже давал раньше ссылки и что-то где-то выкладывал, но опять ниже выложу всё сразу до кучи - пример некоего стандарта для разработки БД. Фактически, там организация проекта похожа на тот стандарт от оракл (ссылка выше), за исключением возможной разбивки исходников по подпроектам и есть явная последовательность сборки (через операторы "input", аналог "start"-а). Плюс натравливается велосипед-препроцессор и получаем разные варианты сборок БД и сборок скриптов-сценариев для рутины. В результате - гибкость, и инструмент даёт полную свободу под конкретные нужды. Недостаток - есть явное ручное описание этих "input-ов", причём из-за них как бы имеются общие файлы между разработчиками, но конфликты их правки разруливаются фактически автоматом. Ну и неплохо иметь какой-то плагин где-то, который помогает чего-то sql-генерировать, в т.ч. создавать новые файлы и шаблоны и эти start/input и т.д., SQL - тяжкая хрень.
Когдато давно у меня была идея БД-фреймворка (реализованного под конкретную СУБД на ее sql-диалекте), что то наподобие того, что указано в ссылке в начале этого письма. Т.е. где бы модули и объекты были описаны в самой БД, в специальных табличках. Т.е. в базах есть всячиские системные таблицы и представления, где хранится физическое описание объектов, а вот как они логически ораганизованы базе не интересно.
В частности на одной из моих работ была частично реализована така вещь:
Каждый создаваемый объект БД должен был пройти через специальную регистрацию (вызов спец. процедуры с имененем объкта и прочими параметрами), там на него выдавались нужные права, прописывался в служебных таблицах ну и много других штук. Нет регистрации нет объекта, его не увидит приложение, не будет доступа к функционалу и т.д.
Не было в этой схеме логической принадлежности. Т.е. чтобы я с служебной таблице добавить запись о новом модуле, а создавать и регистрировать объекты именно для этого модуля. Ну и со всеми вытекающими.
Но потом я как то охладел к это идее (во первых она полность СУБД-зависимая) и загорелся тем, о чем мы сейчас с вами разговариваем. Вариант с файлами мне кажется более естественным.
PSV100Но нужно ещё подумать об удобной организации разбивки исходников по прикладным модулям/подмодулям с зависимостями, где в каждом модуле нужно вести свою "datamodel", причём так, чтобы достаточно было иметь только базовый "create table ..." и грамотно расположены связанные "alter" (тут всё-таки есть потребность в явной последовательности операций, причём перемешанной вокруг разных объектов, например, если СУБД не позволяет удалить используемый столбец, то предварительно нужно зависимые объекты сделать пустыми, чтобы убрать эту зависимость). Плюс для "инвариантности" можно подогнать "велопрепроцессор".
На счет альтеров это больной для меня вопрос, но не менее важный. Было бы здорво иметь базовый скрипт и организованный набор алтеров, а потом получить общий скрипт создания таблицы (я не говорю о чистом create, хотя бы просто сумму файлов). Т.е. я набираю в консоле утилиту и имя объекта, а получаю в нужном месте файлик с определенным именем и версией для записи в него модифицирующих операторов. А потом говорю: "собери мне скрипты создания/модификации этой таблицы с момента создания по конец прошлого года" и он покажет.
PSV100Но для реализации такой тулзы нужен полноценный разбор текста, причём нужны расширения как плагины, понимающие конкретный sql-диалект и потроха СУБД. Тогда возможно и решение смежных задач, вида поддержки доков-комментариев, создание скриптов как "create" в последней или нужной версии (т.е. все alter-ы свёрнуты в общий итог) и т.д. Возможно форматирование исходников и их реструктуризация (управляемая), а также и некоторая верификация. А если уж говорить о создании полноценного db-tools, то очень не хватает подобным инструментам интерактивности. Т.е. чтобы можно было запустить сервер, как emacs или JEdit, он постоянно висит себе и держит соединения с БД, к нему коннектишься, по своему протоколу или хоть с комстроки, хоть по rest-у и пр., он динамически выполняет sql-запросы, управляет каталогом sql-исходников, даёт автокомплит и т.д. И тогда пиши себе плагин хоть для иклипса, хоть для vim-а и пр., или вэб делай.
Но это всё мечты и мысли в слух. А так, я это всё к тому, чтобы дать рекомендацию. Если разрабатываемая утилита удовлетворит какие-то свои конкретные потребности, то и хорошо, и увлекаться глобальной и супер-шаблонизацией особо нет смысла.
Согласен, для полноценного инструмента нужен полный модульный расширяемый разбо sql-кода.
На счет интерактивности и сервера это классная идея, не хватает такого инструмента. В частности при разработки нужно время от времени накатывать скрипты на разные базы (у меня например их число доходит до 4-5 баз: база для разработок, общая база для разработок и 2-3 тестовых (разных версий, т.к. в продакшене тоже разные версии)). Да и вообще много чего можно было бы оптимизировать и упростить.
Утилиту я начинал делать для себя, под конкретные нужды, но дальше больше, разгораются новые идеи и мысли, вспоминаются проблемы и хотелки.
Т.е. если у данного тулза будет заинтересованность, то можно поработать и над универсальность и масштабируемостью.
Причем код (точнее пока только прототип) в открытом доступе (пулл реквесты, коммитерство, а может быть даже содание нового другого репозитория - легко, вообще не вопрос), если у кого будет в нем потребность и желание что то добавить/изменить (а может и вообще кардинально переделать), то буду категорически за. Вобщем все вопросы и предложения только приветсвуются. Тем более совместными усилиями можно будет сделать более универсальный инструмент для большого (в узких круга )) ) числа пользователей. (надеюсь намек понят)) )
