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

1. Пробовал JAXB, загружаю xml-файлы в классы, но дальше проблема как с этими классами работать, как делать запросы и выборки.
2. Есть идея заюзать inmemory-database (например HSQLDB) через ORM (например Hibernate) и сеарелизовать все это дело в xml-файлы, но как то навороченно получается.

В общем прошу совета.

ЛагманBlazkowicz,

он хочет чтоб при коммите этой "бд" в систему контроле версий можно было сравнивать контент в текстовых файлах бд руками

ЛагманBlazkowicz,

он хочет чтоб при коммите этой "бд" в систему контроле версий можно было сравнивать контент в текстовых файлах бд руками

Так точно.

Petro123угу. Т.е. для программистов пишет)).
Пишу для себя, но если окажется кому то полезной то был бы рад.



Petro123И чего только программист для программиста не придумает.
Небольшая консольная утилитка для управления исходным кодом баз данных (DML, DDL и т.д.), если интересно могу рассказать вкратце (не сочтите за оффтоп или самопиар).

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


Так точно.
А RDBMS тогда зачем? Документ-ориентированые NoSQL базы не подходят?

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

Petro123Максим ННебольшая консольная утилитка для управления исходным кодом баз данных (DML, DDL и т.д.), если интересно могу рассказать вкратце (не сочтите за оффтоп или самопиар).
В соседний форум - Разработка ИС. Там точно скажут нужно или нет.

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

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

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

PSV100,

Спасибо за коммент, за ссылки.


PSV100И откровенно говоря, гораздо лучше, к примеру, сравнивать программистский текст, скажем, в виде операторов "create table ...", с нужными комментариями и пр., чем пялиться в XML/JSon и т.п.

Сгласен, я и не собираюсь затирать исходники в xml/json, он мне нужен только для описания структуры sql-файлов.

PSV100Имхо, здесь задета немалая и неоднозначная тема, где нет никакой универсальности. Отсюда и нулевая активность в соответствующем профильном разделе. В этой сфере разброд и шатание. У каждого свои СУБД, со своей спецификой, свои инструменты разработки, разные команды со своими особенностями, разные целевые продукты и т.д. и т.п.

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


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

Petro123,

Много говорится о бестпрактис хранения исходников БД в СКВ, причем каждый объект - это отдельный файл и т.д.

Так же есть множество модных (и не очень) деплойеров и changhe manager'ов, которые позволяют управлять изменениями кода БД, собирать дифф-скрипты,
накатывать на базы и контроллировать все это дело (Liquibase, dbdeploy, etc).

А есть какая-либо тулза, которая помогала бы непосредственно управлять самим исходным кодом, например:
- Могла набросать каркас из папок и файлов для хранения исходных кодов объектов;

======== PSQDeveloper - пр.клик - создать DDL \ DML


1. Это СУБД зависимое решение, что если у меня другая СУБД? И (если вы про PLSQLDeveloper), то он еще виндовый и платный.
2. Это GUI, это дело не автоматизируешь и не заскриптуешь (по крайней мере нормально).
3. Это будет уже не совсем ваш код, которым был создан тот или иной объект БД, а DDL\DML будет взят из недр базы
(сшит на основании системных таблиц/представлений, где хранится его описание).
Вроде бы и не страшно, я тоже так думал, пока не столкнулся с этим более тесно,
и сделал для себя несколько выводов, если интересно можно прочитать здесь - http://www.sql.ru/forum/actualthread.aspx?tid=927233



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

=== там же



Средтва IDE (помимо всех прочих недостатков) тупо работают с кодом объектов, созданых в БД, и даже чего то могут с ним делать, но они абсолютно
не осведомлены о логике вашего приложения БД, им на это глубоко всеравно. Они не могут выделить среди всего набора объектов схемы, те объекты,
которые объеденены логически между собой (модули, подмодули и т.д.), а разбиение на схемы, не всегда устраивает.
А что если в моей базе есть свои собственные типы объекты, например включение репликации для некоторых объектов, либо другие какие угодно конструкции.
Или если некоторые объекты должны создаваться не напрямую DML/DDL'ем, а через специальные процедуры-обертки, с регистрацией и т.д.
Например таблицы создаются не напрямую CREATE TABLE'ом, а через обертку (да и такое бывает), а обертка уже создает таблицу в зависимости от настроек
системы, прав и других обстоятельств.
Или для разных баз у меня может отличаться DML (значения справочников, тестовые данные и т.д.), и даже DDL.
Например есть таблица, на тестовом серваке должны быть одни данные в ней, на нагрузочном другие, на продакшене третьи и т.д.
И вот тут то и начинаются проблемы со сборкой базы, а для того чтобы развернуть новую базу делается дамп с одного из продакшенов с "вырезанием"
"не нужных" данных, добавлением "нужных" и т.д. тут возможны варианты.



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

== ты перепутал ORM с РСУБД. Объекты завися от маппинга. Вариантов маппинга - миллион. Индексы при грохании таблицы удаляются
автоматически - если они в БД. Или они где?


Вроде не путал. Возможно не правильно объяснил.
Иммется ввиду объекты БД (таблицы, предсталения, процедуры и т.д.), их маппинг я здесь не рассматриваю, это другая тема.
Индексы в базе грохаются, само собой, и объекты пользователя грохаются при удалении пользователя.
Но вот код этих объектов, заверсионированный в СКВ, никто не удалит, его актуальность нужно поддерживать самостоятельно.


Я имею ввиду немного другой подход к разработке БД, т.е. не "наклацать кнопок в ГУИ, выгрузить дамп", а работать непосредственно
с исходным кодом объектов БД, версионировать его, логически структурировать его и плясать именно от него, от кода.
И вот данная тулза как раз и должна это делать.

Но возможно это все перфекционизм...

Petro123Максим НЯ имею ввиду немного другой подход к разработке БД, т.е. не "наклацать кнопок в ГУИ, выгрузить дамп", а работать непосредственно
с исходным кодом объектов БД, версионировать его, логически структурировать его и плясать именно от него, от кода.
И вот данная тулза как раз и должна это делать.
Как работать без IDE и ГУИ?
Приведи ВИ \ Прецендент.

Я не хотел сказать, что использовать GUI/IDE это плохо.
Не в коем случае, я и сам ими пользуюсь.
Вопрос в том что на эти инструменты слишком много возлагается полномочий.

ИМХО
есть вещи с которыми они здорово справляются: редактирование кода (со всеми понтами, автокомплитами и т.д.), дебагеры и т.д.
А есть те, для которых они мало подходят. В частности хранение объектов БД и их описаний (они выковыривают это из базы), сборкой скриптов (и др., что я описывал в предыдущем скрипте).
Смысл в том, чтобы хранить объекты в том виде, в котором удобно и как удобно, орагинизовать собственную структуру, а не так как предоставляют это ИДЕшки.