Petro123Только, проще SQL ты не придумаешь свой ЯП для БД.
Не взлетит.

Я как раз и не собираюсь изобретать SQL, мне нужен инструментарий, который облегчает жизнь при программировании непосредственно на самом "нативном" SQL для конкретной СУБД. Говоря о sql-проектах я не имею в виду "классические" проекты для java или С++ и пр. Проект - он же каталог исходников или SQL-каталог - это набор текстовых sql-файлов (плюс какие-то другие по потребности), на основе которого можно создать БД (можно сказать, что это результат "компиляции" исходников). Иными словами - это некое текстовое представление Базы Данных. Кроме создания БД есть потребность и в другом, включая внесение изменений в существующие базы согласно исходникам.

Я уже выкладывал здесь SQL-препроцессор, где в качестве демки есть простой примерчик подобного sql-проекта. Выложу этот же пример отдельно - скачать:

mad_nazgulЭ-э-э вообще-то SQL - это скорее декларативный ЯП.
Соответственно к нему не применимы те методы разработки, как в "обычных" ЯП.
Сама по себе БД, является и "исходником", и "скомпилированным приложением".
Причем "текстовое представление" БД делается в любой SQL БД одной командой.
То о чем вы говорите, называется дамп БД.
Зачем нужна лишняя сущность?

Здесь я уже говорил о причинах, почему иногда не работают типовые подходы в разработке БД и стандартный инструментарий. Если кратко, главный затык - есть потребность в вариантности функционала. К тому же и автор этой темы неоднократно описывал проблемы, с которыми пытается бороться, в т.ч. и насчёт стандартных дампов, например: здесь , здесь , а здесь статейку накатал.

Vladimir BaskakovА чего сильно боятся? Ну поругает кто. Зато быстрее повскрываются баги, хотелки.
Пока даже концептуально не очень понятно.
Я представляю себе нечто похожее на ant-скрипт. Куда пихаютсся изменения в базе, и который можно ==накатить от версии до версии==.

Насчёт ant-ов автор уже писал .

Petro123ну вот, представь себе.
Что ты пишешь одну Программу.exe сразу на 2-х ЯП - Java и ПлемениМумбоЮмбо.
Причём пытаешься всё это конверитровать-синхронизировать по типу Мастер-Мастер.
.....
Ведь по сути ты вторгаешься в область деятельности - "Разработка СУБД". Это не Java программист. И подходы (IDE\ЯП) там другие.
...
Каждый в жизни писал свою 1С )).

Да, всё так и есть. У нас давно своя "1С", со своим языком ПлемениМумбоЮмбо, плюс активное SQL-кодирование (с помогалками), что в т.ч. даёт низкий порог вхождения для подключения разработчиков на местах при необходимости (и не редко это требуется), и существенно облегчает им жизнь (и нам самим тоже). Вместо Java функциональный костяк реализован на Delphi (истоки проекта ещё с 90-х). И именно такое решение позволяет уже далеко не один год вести постоянную разработку и сопровождение систем силами небольшой команды, имея не одну сотню инсталяций, причём все они разные (за редким исключением), со своим функциональным составом и особенностями в каждом конкретном случае, и частенько у клиентов не одна база, с распределенными функционалом и данными. При этом немалая часть прикладной логики требуется держать внутри базы, т.к. большая часть работы ведётся в двухуровневом клиент-сервер, рядом может быть прикручен сервер приложений, с возможным торчанием наружу в инет, есть потребность в связке с другими 1С/акцаптами/R3/оракл-апликухами и прочим зоопарком местного софта и т.д. Короче говоря, нужен контроль данных, доступа, да и производительность тоже не на последнем месте, и пр. Если бы для наших имеющихся java- и net-проектов стояла бы подобная задача, то это было бы полная опа. Собственно, у нас далеко не один год делаются попытки переезда на новые рельсы, но пока безрезультатно, до хрена технических и политических проблем. И откровенно говоря, у меня на таких задачах возникает огромное желание закопать java (как языковую платформу), со всеми её XML-довесками и хибернейтами и прочими ORM, неудобны и решения вида iBatis, очень заморочно копаться "в лоб" в различных sql-генераторах вида java-sql-generator , не вижу счастья в попытках а-ля link, в т.ч. и те, что есть в Scala, и пр. Фактически, под мои потребности нужно лепить свой DSL и брать библиотеку вида ASM и вперёд генерить байт-код под jvm. Но это всё офтоп в другую сторону.

Поэтому я делюсь своими подходами и у меня есть интерес к тому, как другие воюют со сложной разработкой БД, в рамках java- и не очень проектов.

Petro123Впрочем, удачи!

Спасибо.

Petro123PSV100,
всё что написали, видно что круто.
НО. Как всегда, у нас велика роль личности.
Вот у вас в команде не взлюбили ErWin и тому подобные продукты.
Т.к. видно что вы их НЕ знаете. И лепите аналогичный КроссБазовый велосипед
Это личное дело вашего архитектора и руководителя проектов.
IMHO
...

В своё время смотрели на ErWin и ряд других популярных Case-средств, действительно, у нас они не прижились. Есть технические проблемы (к примеру, в основном они плевали на Interbase/FireBird, которые для нас важны), так и куча банальных неудобств при разработке. Скажем, непонятно как задать у столбца таблицы тип/домен в зависимости от каких-то условий/настроек, или как задать состав столбцов разный согласно потребностям, или как задать разный код для процедуры/функции и т.д. Я не помню, что творилось в том же ErWin и не в курсе чего есть в последних версиях, но фактически для подобного в case-средствах обычно всегда требуется создавать новые модели. Выжить с десятками (или даже с сотнями) case-моделями я не представляю как. К тому же нет ничего реально полезного от визуального проектирования, таская мышкой объекты по экрану, особенно когда требуется одновременно отразить кучу связанных объектов, они все удобно не влазят на экран, видишь перед собой лес пересекающихся линий. Как-то не в кайф ковыряться в неудобных GUI-режимах, скажем, вводя структуры объектов в каком-нибудь гриде. Для нормального программиста операции с текстом в нормальном текстовом редакторе/IDE на порядок удобнее/проще и главное быстрее. У нас в проектах были (и есть) всякие дизайнеры форм/отчётов, под влиянием в своё время модных RAID-средств, как та же Delphi. Когда объектов стало тысячи, то их программирование (через удобный DSL) вытеснило их графическое рисование, и "программирование" БД гармонично дополняет сложившеюся картину. В ряде case-средств есть и свои 4GL-языки для программирования, но они всё равно привязаны к своему пониманию модели (не всегда удобному, см. выше), или фактически являются своим "1С".

Имхо, достоинство того же ErWin в том, что это фактически некий промышленный стандарт, на пару с связанным BPwin и прочими бизнес-моделяторами. У нас некоторые клиенты требовали из-за своих корпоративных стандартов case-модели для ErWin и чего-то ещё, ибо вся информационная структура якобы описывается и сопровождается в них. Есть какие-то соответствующие генерилки, но чего там именно есть я не в курсе, ибо сам не занимался этим. Но это не первичное проектирование/разработка, это сугубо конечный результат, формальность, включая и для самого заказчика.

Максим ННа первое время думаю сделать попроще, обойтись на уровне поиска/регулярок. В будущем можно будет расширить, например добавлением пользовательских расширений под конкретную БД (некий набор правил, который сможет распознать таблицу, процедуру и т.д.)

Кстати, в своё время намучались со всякими правилами для разбора текста. Были и регэкспы, и прочие фантазии для задания правил. Но всё таки прямое программирование под конкретные задачи оказалось гибче и проще. Были и попытки полноценного SQL-разбора, но мощный анализ на основе полной BNF/PEG и подобной грамматики с использованием генераторов парсеров типа lex/yacc/JavaCC и т.п. как-то геморно для такой задачи, всё таки это не SQL-сервер. В конечном итоге прижился такой вариант. Удобным оказался простой парсер, дающий поток токенов. Парсер динамически программно настраивается, т.е. ему указывается какие токены разбирать примерно в таком упрощенном виде:

parser.AddToken(" ");
parser.AddToken("\n");

и прочие разделители. Соответственно парсер будет через метод типа "GetNextToken" последовательно возвращать всё, что есть между разделителями и сами разделители. По потребности дополняются иные токены, как скобки, запятые и пр. Должна быть возможность задать токен в виде блока:

parser.AddBlock("/*", "*/")

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

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

/* это комментарий */
create table MY_TABLE(
COL1 TYPE1,
COL2 TYPE2
);

Циклически вызывая метод GetNextToken он последовательно вернёт все токены: "create", "table", "MY_TABLE", "(", "COL1" и т.д.

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

Petro123PSV100Выжить с десятками (или даже с сотнями) case-моделями я не представляю как
Ты о чем? Модель статична т.к. маппинг. Т.е. сколько моделей столько и проектов.
...
1 Зачем разный состав столбцов для одного проекта. Приведи маппинг.
2 ты в курсе что там есть ЯП.?

В том и дело, что плач начинается тогда, когда нет статической модели, когда есть несколько/много одновременно работающих вариантов проекта. К тому же есть потребность выделять части проекта как самостоятельные проекты/модели. Т.е. есть case-модель, где имеется всё-всё-всё, но есть одновременно работающие проекты, где размещены только необходимые функциональные части от общего. Оформлять каждую часть модели как независимые или отдельные проекты/модели нецелесообразно, т.к. часто они взаимосвязаны и существует некое общее функциональное ядро, необходимое всем.

Вообще-то, действительно, типовые case-средства хреново подходят для полноценного системного моделирования. Они заточены на создание именно статической единой модели, где задаются жёсткие статические связи и нет динамических связей/факторов. Фактически, они отражают лишь один из вариантов, или это лишь один результат системного анализа/проектирования. Причём в их же тесно связанной области - моделировании бизнес-процессов - кое-какие есть попытки быть поближе к реальной жизни, к примеру, в ARIS (где eEPC-нотация, сейчас это серьёзная альтернатива для классики типа BPWin/ErWin, IDEFхх и пр.) есть понятие вариантов бизнес-процессов, но вариантов связанных ER-моделей что-то не видно (хотя, м.б. я чего-то и не досмотрел).
Из-за проблем "статики" неудобны и классические ORM в джаве, да и в нет-е.

В советские времена была такая Р-технология - технология разработки программных систем, на основе идей Вельбицкого, Глушкова и др., изначально создавалась для ракетной промышленности. Там вместо зоопарка графнотаций (ER - для данных, блок-схемы или им подобные, или нынче вновь популярные типа Scratch - для алгоритмов, или UML, если алгоритмика мимо case-средства, и прочие диаграммы для потока работ, данных и т.д.) имеется одна нотация - Р-схемы, и для алгоритмов, и для структур данных, и для процессов и пр., где задумывались над тем, чтобы не только их созерцать, но и вменяемо вводить/создавать, где есть возможность для инвариантности, модульного разделения со взаимосвязями, были и свои системы контроля версий и контроль доступа, ведение документации и т.д. Жаль, что вместе с СССР всё загнулось. Современные case-средства и прочие ERP-монстры концептуально не добрались до тогдашнего уровня.
Но это всё офтоп.

Собственно, я хочу сказать, что не вижу почвы для какого-то спора вокруг ErWin и аналогичных case-средств. Здесь Максим Н, да и я, показали некий альтернативный подход в разработке БД - от "исходников", они первичны. Максим Н правильно подметил, что альтернативных инструментов мало, но они есть, значит и есть потребность в них. Лично для меня не стоит вопрос в потребности такого подхода, вопрос в том, как это удобно реализовать. Причём не только с позиции помощи для какого-то системного проектирования, но и для решения важных рутинных технических задач, с желательной поддержкой не только метаинформации по прикладной модели, но и включением в "проект" и других не-sql технических объектов (документация, файлы БД с закачиваемыми данными (для тех СУБД, где это возможно/удобно) или текстовые/бинарные/sqlite и пр. файлы для импорта/экспорта данных, shell/bat-скрипты и др.). Даже не помешает кошерная ситуация, когда для выполнения операций вместо последовательного запуска нескольких независимых процессов отработает один, без постоянного переконнекта, или когда есть минимальное количество перебора исходников программами.
Как-то так.