Максим НДелаю некую консольную аппликацию, (утилитка для работы с файлами определенных типов, расположенными в репозитории). Приложение однопользовательское, работает на локальной машине.
Необходима СУБД (либо какое-нибудь комбинированное решение), которая могла бы хранить обычные реляционные данные (несколько таблиц, связанных между собой), позволять обращаться к ним (запросы, апдейты, делеты и т.д.) и (самое главное) хранить их в файлах в каком-нибудь человеко-читаемом виде (XML, JSON, etc).
Зачем такой изврат? Для того, чтобы эти файлы (или файл) поддавались версионированию, мерджу и т.д. и чтобы пользователь мог отредактировать их самостоятельно, без приложения.
[...]
Максим ННебольшая консольная утилитка для управления исходным кодом баз данных (DML, DDL и т.д.), если интересно могу рассказать вкратце (не сочтите за оффтоп или самопиар).


Может быть есть смысл посмотреть на Fossil . Он всё хранит в sqlite-базе, с ней можно работать самостоятельно, и можно реализовать свой функционал, которого не хватает в этой системе контроля версий (и не только). Может быть и какой-нибудь JFossil появится в дополнение к JGit-у.

Максим НPetro123пропущено...

В соседний форум - Разработка ИС. Там точно скажут нужно или нет.

Задавал уже, правда в Проектирование БД:

http://www.sql.ru/forum/actualthread.aspx?tid=1005902

правда без результатно.

Имхо, здесь задета немалая и неоднозначная тема, где нет никакой универсальности. Отсюда и нулевая активность в соответствующем профильном разделе. В этой сфере разброд и шатание. У каждого свои СУБД, со своей спецификой, свои инструменты разработки, разные команды со своими особенностями, разные целевые продукты и т.д. и т.п. В своей практике процесс разработки баз повёрнут в несколько иную сторону так, чтобы имеющиеся системы контроля версий помогали также, как и для остальных исходников. Грубо говоря, ведётся каталог исходников для создания/обновления баз (DDL, DML и пр.), со своими особенностями и под свои потребности. Нужны свои тулзы, которые, как минимум, на основе этого каталога позволяют создать базу с нуля (или сгенерировать скрипты для этого), а также позволяют накатить изменения на любую целевую базу. Вся история изменений и т.д. ведётся, фактически, также как и остальные исходники. И откровенно говоря, гораздо лучше, к примеру, сравнивать программистский текст, скажем, в виде операторов "create table ...", с нужными комментариями и пр., чем пялиться в XML/JSon и т.п.

Я как-то задавался подобным вопросом здесь , там правда речь про FireBird, но тамошнее обсуждение подойдёт под любую SQL-СУБД. Есть там и связанные ссылки по проблеме.

И кстати:
Максим Н...NoSQL можно попробовать. Только вот что? чтобы java-based, embeded и все такое?
Щупал OrientDB, но она (насколько я понял) не умеет с xml-json работать. Т.е. хранить его в качестве value можно, а вот запросы делать...

Я её раньше как-то щупал, была глючная и ломала базы. Её как-то обсуждали здесь , там же рассматривались её конкуренты. Интересно, сейчас её активно пилят, продвижения в плане надёжности имеются ?

Максим Н...
1. Это СУБД зависимое решение, что если у меня другая СУБД? И (если вы про PLSQLDeveloper), то он еще виндовый и платный.
2. Это GUI, это дело не автоматизируешь и не заскриптуешь (по крайней мере нормально).
...

Под FireBird есть IDE: IBExpert, он может скриптоваться. У него (кроме типового функционала) есть хорошая фишка - он сам занимается полным разбором текста SQL, полностью его понимает, может, скажем, сравнить объекты в БД, объект с его SQL-кодом, сами SQL-скрипты и пр., и выдавать diff-ы, к примеру. Кое-как можно всякого запрограмлять себе, но всё равно, ограниченно. В этом плане ничего мощнее под другие СУБД как-то не попадалось, как GUI-IDE (там, кстати, есть и консольные утилиты).

А в целом, все выше по постам перечисленные проблемы знакомы. Плюс у меня имеется историческая специфика, где много логики внутри базы (т.е. есть не только таблицы), много целевых баз для постоянной модификации, которые не являются как бы копией по метаданным относительно эталона (т.е. может быть только часть прикладных модулей, на местах свои разработчики могут расширять или изменять функционал и пр.). Именно поэтому в своё время и пришли к тому, что базу данных нужно именно полноценно программировать (под свои нужды). Готового решения не нашли, всякие ORM-ы, визуальные моделеры и пр. далеки до нужного функционала.
Максим Н...
Сгласен, я и не собираюсь затирать исходники в xml/json, он мне нужен только для описания структуры sql-файлов.
...

У нас, кстати, как-то задолбало то, что нужно ещё и вести некое дополнительное описание структуры SQL-проектов. Выкрутились через стандарты именования, т.е. строго предопределенная структура каталогов (папок), свои принципы для именования объектов в БД и для имён SQL-файлов и пр. (т.е. стандарты всё-равно нужны, и лучше когда они реально помогают, но не всё можно отразить только через имена, к примеру, зависимости между SQL-файлами у нас может быть прописана в спец-комментариях).

Если сейчас речь идёт о создании некой универсальной утилиты, то тут трудно что-то однозначно сказать. Сорри, не могу поделиться конкретикой насчёт своих решений, ибо это закрытая корпоративность, но я уже давал ссылку на тему форума, где можно в общих чертах прикинуть что к чему (к тому же, у нас далеко не всё идеально, с большой частной спецификой, и руки всё не доходят до нужного, и историческое наследие тяжёлое). В той теме в стартовом посте приложен архив, где есть пример некоего стандарта для разработки. В своё время он дал толчок для действий. Там же есть ссылка на эту презентацию , ещё один взгляд на накаты изменений. Собственно, подобного материала в инете хватает, готового рецепта я нигде не нашёл, представленные варианты (хоть и древние) тоже не ахти, хоть и просты и концептуально относительно универсальны (применимы для многих серверов и не зависят от жабы, нет-а и т.д. ), но это только пища для размышлений.

Если универсальная утилита должна не зависит от СУБД, то, имхо, совсем тяжко. Тут, похоже, только синтаксис комментариев может быть общий у разных СУБД, остальное мрак. Может быть и есть смысл ввести спец-комментарии в текст SQL. Например, упомянутый IBExpert чуть расширяет язык, где в т.ч., например, через комментарии можно указать условия для выполнения команд. Или та конторка, чей файлик со стандартом разработки я выкладывал (см. выше) также делилась и препроцессором, который обрабатывал SQL-скрипты с комментариями-ключами для условной компиляции, и на выходе выдавал готовый скрипт (если есть желание, могу поделиться им).

А так, действительно, не хватает удобного инструмента, который на основе набора SQL-исходников делал бы и накаты изменений, и откаты, и создание с нуля, и сравнение и т.д. и т.п. Хотя бы для базиса требуется создание базы с нуля и накатывание изменений на существующую. Причём с учётом зависимостей, наличия настраиваемых условий. И если уж ориентироваться на ручное программирование, то желательно изобретение некоего своего DSL, где бы в дополнение к основному тексту SQL, специфичному под конкретный сервер, нужно добавить универсальное SQL-расширение: настроечные параметры, условия для выполнения, зависимости между SQL-файлами (как модулями проекта), универсальные операторы включения/вызова скриптов (а-ля input/import/uses и т.п.). Возможно, пусть это будет внутри комментариев, если проще реализовать (или чтобы "левые" операторы не ломали исходный SQL, иначе всегда требуется предобработка, если текст подавать для стандартного инструментария при сервере). Можно подкрепить ведением документации а-ля pldoc . Связываться с правкой того же XML вручную - как-то нет желания. Если, скажем, нужен XML для какого-нибудь liquibase, то пусть он формируется автоматически.

И лично я, к примеру, сейчас предпочитаю вести разработку БД в удобном для себя текстовом редакторе, со своими шаблонами, автокомплитом, кодогенерацией и пр., чем тыкаться в IDE-DB, в т.ч. часто проще и быстрее копаться в структуре БД как в каталоге исходников. Но совсем без IDE пока никак.

Как-то так.

PSV100Я её раньше как-то щупал, была глючная и ломала базы. Её как-то обсуждали здесь, там же рассматривались её конкуренты. Интересно, сейчас её активно пилят, продвижения в плане надёжности имеются ?

Максим НИнформации по ней достаточно мало, это и отпугивает.

Ага, OrientDB концептуально интересна, но в плане технической реализации настораживает.

Йуный джавистЪТом Кайт писал, что использует для разработки только vi, sqlplus и rlwrap.

Ага, и в современном vim-е из коробки есть универсальный плагин для работы с SQL-серверами, правда лично я его не использовал.

Йуный джавистЪВ той теме в качестве варианта 4 вы изложили абсолютно правильный вариант разработки. Чем он вас не устраивает?

Собственно, там и указано, что такой подход и используется. Проблема в том, что всё-таки решение не без гемора, и нет универсального инструментария, которым, например, можно было бы и поделиться. Свои велосипеды имеют и свои заморочки, завязаны на свои конкретные проекты, кроме обновления баз делают и др. прикладные задачи и т.д. Потребность в новой реализации есть, но руки пока не доходят.

А в качестве универсального тулза, имхо, на первый этап нужна генерация SQL-скриптов на основе каталога исходников. Например, пусть есть каталог исходников. Его логическая структура как-то предопределена, скажем, выделены некие логические SQL-модули, как простой вариант - сама структура папок определяет модули-подмодули (типа какие-то пакеты), или структура проектов описана как-то отдельно. Тулзе дали команду сформировать sql-скрипт для создании базы с нуля, но при этом указали, что нужны только модули XX и YY. Тулза должна понять, что нужно выгребать текст для этих модулей, но т.к. эти модуля имеют некую зависимость от модуля ZZ (скажем, общие справочники, вычисления и пр.), то она также должна вычислить какую часть из ZZ нужно подхватить, и дальше разрулить зависимости. Или дали команду сформировать скрипт для наката изменений в базу. Тулза должна определить, какие модули установлены в базе, их версии, и на основе скриптов для наката изменений (из того же каталога исходников) должна сформировать нужный скрипт (или их структуру), опять же с учётом указанных целевых модулей и их зависимостей. Тулзе не важно, что прописано в самих sql-файлах. Скажем, таблицы можно создавать через явные "create table ..." или где-то будет реализация какой-то хранимки, которая выполняет всякие вычисления/анализ и сама занимается генерацией текстов нужных SQL. Тулза должна понимать некие правила как соединять/обрабатывать исходные sql-файлы, правила задаются под сервер СУБД (или проект). Зависимости, например, проще указывать между sql-файлами, вида import <такой-то файл/ы> (или что-то подобное). Можно в начале файла, как псевдо-SQL оператор или в виде спец-комментария (особенно, если ещё будет система вида java-доков). Или зависимости тоже где-то отдельно прописываются (хотя, чем проще, тем лучше). Как бонус, м.б. есть некая потребность в препроцессоре, где на основе спецкомментариев можно делать свои вычисления, с учётом возможных параметров настроек для проекта, конкретной команды запуска и т.п. Полезно, если СУБД не имеет развитых средств для SQL-логики (к примеру, нет операторов вида: if <условие> then <что-то create>), или нужен универсальный код под разные СУБД/проекты.
Как-то так.


А вообще-то, согласно той темы, хочется варианта 1, когда есть единая платформа разработки под все нужды. Всякие ORM-ы нужного варианта не дают, в большинстве случаев кроме таблиц они мало о чём знают, в качестве управления базой смогут сделать drop всему и create всё заново. Остальное sql-лить ручками. Некоторые дают немного програмлять, например, в виде классов-миграций с методами up/down до нужных версий, но всё-равно это только малая часть потребностей (и то не фонтан), от sql не избавляют.

Когда-то под jvm попался проектик на кложуре, типа мечта. Ссылку потерял, быстро найти не получилось (и названия не помню), да и когда смотрел он, похоже, был уже заброшен, функционал был в зачаточном состоянии, и то, больше задекларирован только. Это некий аналог Clojure -> JavaScript, т.е. Clojure -> SQL, в частности всё затачивалось под postgres, причём не только работа с таблицами, но и остальные объекты (триггеры, функции и пр.). Т.е. пишется всё на одном коде, и сервер приложения, и база програмляется, с версиями, генерируется код как для модификации таблиц, так и для остального (но ограниченно, конечно). Но, опять же, это не очень универсально, и даже специфично, ибо, прежде всего, это кложура, т.е. лисп.