Vladimir BaskakovЯ не против, но слоган "Снимаю запои зависимость от ИДЕ" не кажется мне отражающим правду жизни....

Хороший слоган получился.

Vladimir Baskakovа где зависимость от ИДЕ. Альтерящий скрипт родился - хоть из среды, хоть из емакса страшного, и его надо засунуть.

или - новая версия полного криэйта объекта, написана ли рукой в емаксе или автовыгрузкой из базы родилась в ИДЕ, и ее надо засунуть.


Во первых разница большая: в 1-м случае вы храните, а потом распоряжаетесь с ним как хотите, свой честно написанный скрипт, где есть форматирование и комментарии, который выполняет ровно столько сколько вы в нем написали. В сгенерированных же скриптах ни чего этого нет, комментарии съедаются, форматирование заменяется машинным, и плюс к этому сам код может серьезно видоизменится (например могут добавится или наоборот удалиться имена схем, параметры, которые определяются по дефолту от настроек системы при создании объекта, вплоть до изменения типов полей в create table, потому что видители ИДЕшный сборщик посчитал так лучше (сам натыкался на такое в ТОАД'е)). Да, безусловно, есть настройки генрации/отображения кода, но это все припарки. Т.е. это уже получится зомбо-скрипт, который за вас достали и собрали по винтикам со дна базы. Так зачем же до этого доходить если можно просто сохранить ваш собственный код создания объекта и работать конкретно с ним.
С другой стороны если разработчик работает полность с ГУИ, и его все устраивает, все работает, нареканий нет, то на здоровье.

Во вторых (я уже говорил об этом но повторюсь), ГУИ отображают несколько жестко заранее определенных типов объектов: в дереве объектов клацаем на табличку, там открывается список полей, затем на вкладках индексы, триггера, зависимые объекты, и вкладочка со свежесгенеренным исходным кодом, например "CREATE TABLE тра та та". Т.е. все жестко, ни в лево ни в право, никакого творчества. А во многих системах (крупнее средних) бывает что объекты (или некоторые из них) создаются не просто стандартным create'ом, а через какую либо обертку, или после создания их необходимо зарегистрировать в системе. Т.е. скрипт создания объекта "таблица" это уже не тупо "create", а более сложный код, а ИДЕ об этом ничего не знает, она может только достать результирующий CREATE и все. Причем в разных модулях одного приложения может быть разная политика, в одном мы шарашим таблицы на прямую, а в другом через обертку и т.д.. Так же возможны новые пользовательские типы объектов, например параметры, т.е. некий функционал для создания параметров в системе специальными процедурами.
Или если это система, основанная на EAV, то ИДЕ тут вообще бессильны, т.е. удобно хранить в версионнике некий сгруппированный набор скриптов для создания классов, объектов, параметров и т.д. Т.е. не просто набор всех инсертов, а например в этом файле скрипт создания класса "Дом", в этом класс "Автомобиль" и т.д. И работать с этим имхо горазд удобнее.

Vladimir BaskakovТулза по сути - структурированное хоронилище, в котором это рукописное или выгруженно-сформированное закопано.

Может и так, была у меня идея сделать такую иде (ну или что то похожее на иде), которая бы ничего не навязывала разработчику, и по максимуму использовала привычные, удобные и полюбившиеся разработчиками инструменты. Т.е. выбираем любой редактора кода (vi, emacs, jedit, может что-нибудь из полбившихся ИДЕ, что угодно), в качестве инструмента для навигации по объектам (дереву объектов) любой файловый менеджер (mc, far, nautilus, Проводник etc) ну и то же самое с дебагерами, форматерами и всем другим. Так же нет жестко заданных типов объектов, все настраиваемо. Причем эта иде не заменитель больших и взрослых ИДЕ, ее можно использовать параллелльно когда нужно, когда удобно, можно заскриптовать как надо.
Но это пока все мечты...

PSV100В рамках офтопа: Максим, если вдруг сделаешь IDE или плагин для vim/emacs/sublime/jedit для работы с SQL в стиле или с поддержкой xiki , при этом с поддержкой фишек Light Table (вывод связанного контекстного кода и "живая" отладка) - дай обязательно знать.

ок.

PSV100Максим, а как ты собрался автоматизировать составление операций для накатов? В общем случае это не так просто, например, нужно корректно выявлять операции переименования. Тут нужна IDE или страшный эмакс, которые протоколируют операции и формируют команды на основе истории.

Я сейчас думаю над этим вопросом, чуть позже отпишусь.


PSV100Максим, пока ты не сформируешь чёткие концепции своего некоего фреймворка, возможные методики разработки БД, ты вряд ли найдешь какой-то поддержки. Те, кто работает с исходниками, те и будут с ними работать сами, как бы разрабатывая программу. Как у тебя нет доверия к ликвибэйсовским xml-командам, так и у них очень вероятно не будет доверия к какому-то шаблоно-конфигурируемому ненадёжному grep-у. Если кому-то нужно иметь разные гранты, разные данные и пр., то и будут всё программировать сами, в т.ч. могут и кодогенераторов задействовать (опять же, надёжно запрограммированных), или решать задачи за рамками скриптов и т.д.

Согласен, я сам еще не все понимаю, но по мере работы и обсуждения что от складывается. Попробую это где то записать.
Да, сейчас это расширенный grep, но распознование объектов на основе регулярок я заяпрячу в отдельный модуль, если интере будет, то переделаю этот модуль для разборка текста, если нет, то лично мне и регулярок вполне хватит.

PSV100Может есть смысл перенаправить энергию на свой альтернативный мигратор, если подумываешь об их поддержке. Кому-то XML не нравится. Вот здесь есть пример своего DSL, что-то подобное можно под джаву сделать. Кто-то накатывает через sql, используя какой-нибудь DbMaintain или dbdeploy и т.п. В любом случае всех можно приманить своим специфичным функционалом, что-то гибкое на счёт инвариантности выполнения операций. Подкрепить это дело каким-нибудь вьювером БД по мотивам SchemaSpy , который будет не только "правильно" показывать структуру БД, но и историю изменений и пр., плюс "правильно" извлекать DDL и др.
Или сделать мигратор по мотивам рубивских рельсов как здесь , но под джаву и плюс твои закладываемые широкие возможности, всё через джава-код.

P.S. У меня фантазии закончились.


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

Basil A. SidorovМаксим Н"найти все таблицы из модуля <<<Заработная плата>>".Таблица <<Персонал>> это "из модуля <<Заработная плата>>"? Или это "из модуля <<Кадры>>"? Или вообще - "<<Системные справочники>>"?
А это как вы сами настроете, можете поместить ее в некий базовый модуль, от которого зависят и <<Заработная плата>> и <<Кадры>> и может быть даже <<Системные справочники>>.

Basil A. SidorovМаксим НА это как вы сами настроете, можете поместить ее в некий базовый модуль, от которого зависят и <<Заработная плата>> и <<Кадры>> и может быть даже <<Системные справочники>>.Я, вообще-то, другой вопрос задал, но если вы не поняли, то повторю: что является признаком принадлежности таблицы модулю?

Пока планируется на основе правил, т.е. по имени папок, файлов, выделение части файлов комментариями и т.д.

Petro123Потом, бд - это бд. А модули это БЛ.


Возможно, но группировать объекты каким-либо образом это неплохая идея. Например на одной моей работе была файербердная база (где как вы знаете дела со схемами обстоят несколько по другому чем в Oracle, Postgresql etc) при открытии ветки "Stored procedures" (или как она там называется) на тебя вываливается 4000+ хранимок, в ветка "Tables" несколько сотен табличек и разобраться что к чему бывало оочень сложно. Я уже молчу про количество триггеров, индексов, констрейнтов и генераторов. Иногда в таких случаях добавляют префиксы с именем модуля, в котором они используются, но это тоже не панацея, и самые настоящие костыли, страдает читаемость объектов и их переносимость из одного модуля в другой. А вот храня исходники в СКВ можно решить эту проблему более красиво. Как именно лучше я пока думаю.

PSV100Я рекомендую смоделировать реальную задачу, оценить, что и как можно сделать с планируемой утилитой в паре с каким-то мигратором, например, liquibase и dbmaintain (как представитель тех, кто работает через прямой sql). Представить, что имеются разные БД, где может быть "Заработная плата", "Кадры", "Системные справочники", все вместе или что-то скомбинировано, причём состав "справочников" зависит от состава зависимых модулей. В каждом случае могут быть разные загружаемые данные и пр., если пойти дальше, то и разный функциональный состав модуля, где и структуры таблиц могут отличаться, инварианты кода процедур и т.д. Оценить для себя, на основе какой методологии вести набор исходников, как их лучше организовать, нужны или нет, скажем, "create-"операторы для тех же таблиц согласно их последней текущей версии и т.д. и т.п.

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

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

Хорошая идея. В том и дело, что описанные тобой вопросы не имеют каких либо стандартных комплексных решений (по крайней мере я не нашел, и занимаюсь поиском до сих пор). Каждый разработчик, каждый коллектив справляется с ними самостоятельно, изобретая свои методики, инструменты, утилиты или пытаясь приспособить для этого гуевые идешки, у которых несколько другое назначение.

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


PSV100На счёт своих подходов для решения подобных задач я уже в двух словах писал. В качестве альтернативы, имхо, есть потенциал у "рельсовых" накатов, т.е. система "create/drop/up/down" через сам java-код, ссылки на примеры давал в постах выше. Как раз в контекст твоей темы DB specific ORM. Т.е. возможен некий фреймворк, как поддержка типовых ORM, где через программный код будет управление объектами СУБД, плюс поддержка sql-скриптов (как минимум, там будет код процедур и т.п.), плюс широкие гибкие возможности для операций, плюс генерация скриптов, и т.д.

Да, это хорошая идея, мечта, но возможно уже для какого-то другого инструмента/фреймворка...

Vladimir BaskakovМаксим,а Вы под какой сервер БД разрабатываете?
а то вот есть такое.
http://ru.wikipedia.org/wiki/Oracle_SQL_Developer
- халявное, плагинорасширяемое.....

Oracle SQL Developer изначально поддерживает работу с Oracle Database, существуют плагины, обеспечивающие подключение из среды к другим системам управления базами данных, в частности, реализован доступ к IBM DB2, Microsoft Access, Microsoft SQL Server, MySQL, Sybase ASE, Teradata Database[1].

Oracle.
Девелопером как раз и пользуюсь, обычная ИДЕ со всеми минусами, которые здесь были описаны, эйфории не испытываю (немного работал с Тоадом и PSD, но там еще все хуже), поэтому последнее время все больше отдаю предпочтение текстовику (vim/jedit) + sqlplus, но чтобы полностью перейти пока скилов не хватает.

Petro123- ну а у тебя вывалится 4000 файлов? Уж проще назвать по имени модуля-прекфикс. Раз БД не поддерживает пакеты.

С файлами приятнее и естественнее работать, причем существует много специализированных инструментов для работы с текстом.


Petro123- учитывай, что хранимки Должны принадлежать модулю. А таблицы не обязаны (таблица Города).
Т.к. у вас крайности....то мы всё делаем очень гибко и настраиваемо....то наоборот - жёстко задано по папкам.
А это ключевой вопрос.
Разбиение по папкам это только один из вариантов. Сейчас пытаюсь сделать механизм для описания структуры, т.е. модуль "ЗП" находится в таких то файлах, в таких то папках, в текстовых блоках таких то и т.д. Не знаю насколько это будет практично, но попробовать стоит.

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

Согласен, схемы, пакеты и прочие радости это здорово, но не во всех СУБД имеются, так же они не поддерживают того (о чем не раз говорили здесь) что один объект может принадлежать нескольким схемам. Так же нет возможности организовать иерархическую структуру объектов/модулей.
Так же не будем забывать (о чем я уже не раз писал), что по мимо предопределенных объектов (tables, views, procedures etc) могут быть еще пользовательские объекты, т.е. что то специфичное, и это далеко не редкость.
Особенно если приходится иметь дело с EAV, в котором несколько тысяч типов объектов (классов).


PSV100Но я хочу сказать, что ты опять не дооцениваешь IDE. В том же IBExpert есть понятие "проектов" внутри БД, где в каждом проекте можно задать свой состав объектов (плюс имеется "быстрый" фильтр для поисков), распределять проекты по разработчикам, он может вести историю модификации структуры БД (и много чего ещё). Через эти проекты вполне неплохо можно организовать "модульность", особенно учитывая потенциал у IBEScript для "программирования". Конечно, назвать IBExpert общим случаем в рамках всех IDE-DB как-то нельзя, но основное, чего хочу выразить, это то, что и на IDE при необходимости можно реализовать относительно (!) "гибкий" функционал, который может меньше нагибать, чем возня с исходниками. Те же ER-модели на общем глобальном уровне не выкинешь. Кому-то действительно удобно работать через них в соответствующих проектах, где-то корпоративные формальности и пр. Если делать реинженеринг, формировать схемы на основе БД, то обычно их всё равно шлифовать напильником, вполне м.б. проще их сначала создавать и потом "исполнять" (тот же IBExpert чего-то рисует, если не ошибаюсь, то ранее указанный SchemaSpy тоже как-то генерит схемки вроде бы через Graphviz, примеры его использования можно подсмотреть в org-mode, например, здесь).

IBExpert отличная вещь, может если бы что то похожее было для Oracle я бы и не стал заморачиваться.
Но он заточен под конкретную СУБД.
Есть еще серьёзнейшие, проверенные и уважаемые решения такие как TOAD и PSD, но лично мне они не подходят, можно сказать личная несовместимость, хоть убей, хотя с каждым из них я пробовал работать, пробовал заставить себя, но безрезультатно.


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

На счет выкидывания IDE я ничего не говорил, и отказываться от них я не призываю. И сам их использую и буду использовать.
Кстати, никто не запрещает из ИДЕ открыть исходник из СКВ и работать с ним, причем многие (правда не все) плюшки при этом сохранятся. Никто не мешает накатить нужные пакеты/процедуры на текущую рабочую базу и работать во строенном редакторе, а потом слить их обратно.
Кстати есть одна интересная ИДЕ , ксати на базе vim'а, работающая в текстовом режиме, и использующая в качестве sql-экзекутора старый добрый sqlplus. Правда ее "рубиновость" многих отталкивает. Можно открывать файлы-исходники, можно воспользоваться встроенным "выковыривателем" кода и править на живую, ну и тут же настраиваемый автокомплит и все плагины вима.


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


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

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

Хотя, с другой стороны, я и сам до конца не уверен, в необходимсоти, в обоснованности и т.д. это просто сейчас пребываю на волне позитива, но боюсь это не надолго ))
Вариант с ГУИ всем хорошо известен, его минусы и плюсы, а вот подход с обратной стороны, со стороны исходников достаточно мало освещен, и о нем возможно только догадываться. Вот и было бы здорово попробовать его на деле, так сказать в бою, ну а потом уже с чистой совестью и практически обоснованно сказать: "да это не то, потомучто возникли такие то и такието неразрешимые трудности", и вернутсья в лоно ГУИ ИДЕ. Так сказать исследовательский интерес.


PSV100И, кстати, всё таки работать с 4000+ файлами то же не очень так, даже при наличии а-ля goto в Sublime, i-do и пр. многообразие в эмаксе, CtrlP в виме и т.д. Лично я собираюсь уйти от этой практики, стараться собирать объекты по подмодулям (в т.ч. и "текстовые перемещения" будут больше перенесены внутри файла).

Про 4000 файлов я опять же ничего не говорил. Теоретически все эти объекты можно поместить в один файл, ну или в несколько, разбив по модулям, уровням, слоям и т.д. А вот ИДЕ (по крайней мере, с которыми я работаю) такого предложить не могут: раз 4000 объектов, то получи их все в дереве, выковыривай и целься мышкой по маленькому значку, чтобы начать редактирование. Можно использовать навигацию по названию, набрав первые буквы, но опять же его (название) нужно помнить и отфильтровывать от похожих.


Остался как минимум один не рассмотренный вопрос - это возможность скриптования, автоматизации и интеграции с другими инструментами, чем ГУИ не могут похвастаться, да наверное и не должны, т.к. цели у них другие.

Vladimir Baskakovтак а зачем эйфория. Это же не косяк, чтобы настроение улучшать. Оно же кучу подсказок дает, код автоформатирует, макросы клавиатурные. Сниппеты. Код фолдит. С оракловой справкой интегрируется и работает.
Но это уже кому как и когда удобно, если разработка пакета/процедуры/триггера, то конечно удобно, но если мне нужно по быстрому таблицу накидать тестовую или чего нибудь подправить, накатить на несколько баз, запустить тесты и т.д. и т.п., то тут подойдет что-нибудь полегче. Т.е. вопрос предпочтений.

Vladimir BaskakovЛучше извлекать максимум пользы из отлаженного инструментария, полностью изучив и задействовав все его возможности, и смирившись с некоторыми недостатками, чем городить велосипедарищще, где плюшек будет в итоге намного меньше, а багов и ограничений - существенно больше.
Ну отлаженный инструмент он опять же у каждого свой (вспомните знаменитый баян про Т.Кайта, sqlplus и vim).
Ну и плюс планируемый велосипедарищще все таки не для работы с текстом предназначен, это не текстовый редактор, он может достать вам исходный код для редактирования, сохранить его в нужное место и т.д.

Basil A. SidorovМаксим НС файлами приятнее и естественнее работать... пока их не требуется группировать по разным критериям.

Вот с этим могут быть проблемы, но не больше чем в гуи иде.