Обновить
Комментарии 29
> При этом исходный код приложения нигде не хранится. [...] Как вы думаете, это нормальная ситуация? Думаю, что нет.

Почитайте про Smalltalk и Lisp image.
Почитал, но пока не могу понят к чему вы клоните, ткните пожалуйста в ссылку если не сложно
Lisp image — это способ распространения/запуска/линковки/бутстрапа софта. Исходный код хранится в виде текстовых файлов.
Сам как раз размышляю над этой проблемой. Исходные коды скриптов и софта у нас под контролем версий, но много хранимых процедур в БД. И их изменение идет «на живую». Что, естественно, никому не нравится. Так что за советы спасибо — пришлись в тему.
Что мешает и хранимые процедуры хранить в идемпотентных скриптах?
Незнание того что это такое и как это использовать. :)
идемпотентный оператор равен сам себе будучи возведённым в любую натуральную степень

в данном случае, идемпотентный скрипт сколько бы раз ни выполнился, результат будет такой же, как если бы он выполнился ровно один раз
В таком случае есть дополнительная проблема — отсутствие информации о том, как такие скрипты пишуться.
ну, в качестве примера такой программы могу привести менеджеры пакетов linux, например, dpkg

1. используется блокировка: нельзя запустить одновременно две копии программы
2. первым делом после входа в критическую область программа проверяет, что ей нужно сделать/доделать, и делает только это. в процессе выполнения операций, естественно, запоминает, какие действия уже сделаны, а какие ещё нет

например, если пакет уже установлен, нам об этом так и скажут, поэтому безопасно выполнять несколько раз подряд dpkg -i package.deb
Понятно. Я думал, вы имеете ввиду какой-то универсальный движок для таких скриптов. Вручную все это, конечно, можно написать.
А разве сейчас схемы и миграции для них не являются чем-то обычным?
На мой взгляд, дело в той IDE, которую используете, и корпоративном стиле.

Например, для MySQL в своих проектах я использую MySQL Workbench — он делает выгрузку в один create script с дополнительной возможностью генерации alter script на его же основе. Этот скрипт лежит в папке data под управлением svn и используется всеми разработчиками для создания своей локальной версии проекта.

На работе коллеги, работающие с Oracle организовывают работу примерно как вы описали — один объект в одном файле, и все файлы лежат опять же в svn. Используется PL/SQL Developer.
Согласен, стили разные, IDE разные — гавная идея статьи была в том, чтобы работать именно с кодом БД. Разные визуализаторы, генераторы альтеров это здорово, но использовать их стоит только как вспомогательные средства, а не как основной инструмент для разработки, не задумываясь что вообще творится с кодом.
Согласен, но не только для тех, кто работает с ораклом. Вообще БД, как и исходники проекта, обычно постоянно изменяется и эти изменения нужно как то накатывать. Используют различные подходы от самописных инструментов, механизмов, библиотек до каких-либо готовых решений, например liquibase. Смысл один — версионирование БД, т.е. последовательное накатывание скриптов с запоминанием некой метаинформации об выполненных скриптах (версия, чексумма, автор и т.д.) иногда с возможностью откатить скрипты.
У себя на проекте сейчас используем liquibase, БД — MySQL, до этого в другом проекте использовались raw-changelog-и и свой инструмент. Считаю этот функционал must-have частью для большинства порядочных и уважающих себя проектов.
Аналогия БД с исходным кодом на java или другим языком — неверная. Вернее, эти две вещи имеют разную мощность абстракции. Код на java — это по сути метаданные, в то время как БД — это метаданные ПЛЮС данные. В этом вся разница и вся сложность: нельзя просто менять (накатывать, откатывать, мерджить и т.д.) метаданные, без оглядки на привязанные к ним данные.

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

На самом деле, генератор diff продакшен- и дев-БД — не такая плохая идея, как кажется, если генератор поддерживает ручную коррекцию в середине процесса. Например, если ему можно в середине сказать, что вот это — не 2 операции «удалить колонку + добавить колонку», а на самом деле 1 операция «переименовать колонку». Вообще, таких деструктивных (опасных) операций в diff-е не так уж и много, даже если полностью запретить ему их генерировать (заставляя всегда их прописывать вручную), большой беды не будет. Удаление в метаданных БД — очень редкая операция, как и переименование.
Полностью согласен.
Но есть и решения, которые предлагают вместе с ведение версионности метаданных вести и версионность самих данных. Как по мне, так это уже геморрой наживать.
Конечно, все зависит от организации выполнения программы или проекта.
Например, в своей работе мы храним исходный код (именно код, а не DDL) в SVN. Структура БД в модели. Если изменяется структура БД, то изменения делаются в модели. Затем с помощью скриптов, полученных из модели автоматически, полуавтоматически или вручную (кому как удобно или в зависимости от изменений), вносятся изменения на тестовую или боевую БД.
«Структура БД в модели» — это конечно удобно, нарисовал, выгрузил, накатил, но есть вопрос: например описание оператора CREATE TABLE в документации Oracle занимает несколько листов (это только операторы, без комментариев), наврядли какой либо визуальный инструмент предоставит функционал, позволяющий воспользоваться всеми возможностями. Т.о. получится пользоваться только той частью функционала, к которой приспособлен инструмент (IDE, генератор, моделер и т.д.)
«наврядли какой либо визуальный инструмент предоставит функционал, позволяющий воспользоваться всеми возможностями»

Пока не встречал таких проблем. Да и не думаю, что в этом действительно есть какая-то проблема. Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры. Какие здесь могут быть разночтения? К тому же никто не мешает особенности все же хранить в виде отдельных скриптов. Просто соотношение таких исключений к общему количеству таблиц в БД будет, имхо, мизерным.
«Пока не встречал таких проблем. Да и не думаю, что в этом действительно есть какая-то проблема.»

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

> «есть какая-то проблема»
Был такой issue в предыдущем проекте — база изначально жила в Power Designer, из которой генерился DDL. Надо было добавить deferred constraints, которых не было по умолчанию предусмотрено в IDE. В итоге пришлось копаться в шаблонах, из которых PD генерил код или искать еще какой-то workaround. Чуть позже, когда количество костелей к IDE подобралось к критической отметке, PD был заброшен. Так что проблема существует, факт.

> «Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры»
На самом деле, у всех IDE что мне встречались, которые позволяют моделировать структуру и писать код — есть куда большая беда, они в отсутствии живой базы не способны этот код отвалидировать. Так что существование dev-инстанса (или несколько шире — нескольких окружений разработки) как места разработки «на живую», с последующим внесением кода в репозитарий, мне представляется несколько более удобным вариантом.

А подход, когда структуры генерятся из IDE, а обвязка цепляется из отдельных текстовых файлов выглядит еще более разбродной. Хотя тут конечно же вопрос силы воли сопровождающего.
Полностью с вами согласен
Доверять код (серьезной большой) базы визуалке это дело последнее, ну а если у вас 5 таблиц на мускуле, то пожалуйста
про «версионность данных» я ничего не говорил, это отдельная большая тема.
Это я к том, что написал DmitryKoterov:
нельзя просто менять (накатывать, откатывать, мерджить и т.д.) метаданные, без оглядки на привязанные к ним данные.
«Аналогия БД с исходным кодом на java или другим языком — неверная.» — может не верно выразился, я проводит аналогию в плане отношения разработчиков к исходному коду БД, для многих его как будто и не существует.
Использовать генератор форм и прочие визуальные фичи (в java например) часто считается дурным тоном (программист сам должен следить за своим кодом), а вот в БД пожалуйста — понажимали на кнопки в любимой IDE, выгрузили полученные скрипты и готово.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.