Comments 29
> При этом исходный код приложения нигде не хранится. [...] Как вы думаете, это нормальная ситуация? Думаю, что нет.
Почитайте про Smalltalk и Lisp image.
Почитайте про Smalltalk и Lisp image.
Сам как раз размышляю над этой проблемой. Исходные коды скриптов и софта у нас под контролем версий, но много хранимых процедур в БД. И их изменение идет «на живую». Что, естественно, никому не нравится. Так что за советы спасибо — пришлись в тему.
Что мешает и хранимые процедуры хранить в идемпотентных скриптах?
Незнание того что это такое и как это использовать. :)
идемпотентный оператор равен сам себе будучи возведённым в любую натуральную степень
в данном случае, идемпотентный скрипт сколько бы раз ни выполнился, результат будет такой же, как если бы он выполнился ровно один раз
в данном случае, идемпотентный скрипт сколько бы раз ни выполнился, результат будет такой же, как если бы он выполнился ровно один раз
В таком случае есть дополнительная проблема — отсутствие информации о том, как такие скрипты пишуться.
ну, в качестве примера такой программы могу привести менеджеры пакетов linux, например, dpkg
1. используется блокировка: нельзя запустить одновременно две копии программы
2. первым делом после входа в критическую область программа проверяет, что ей нужно сделать/доделать, и делает только это. в процессе выполнения операций, естественно, запоминает, какие действия уже сделаны, а какие ещё нет
например, если пакет уже установлен, нам об этом так и скажут, поэтому безопасно выполнять несколько раз подряд dpkg -i package.deb
1. используется блокировка: нельзя запустить одновременно две копии программы
2. первым делом после входа в критическую область программа проверяет, что ей нужно сделать/доделать, и делает только это. в процессе выполнения операций, естественно, запоминает, какие действия уже сделаны, а какие ещё нет
например, если пакет уже установлен, нам об этом так и скажут, поэтому безопасно выполнять несколько раз подряд dpkg -i package.deb
А разве сейчас схемы и миграции для них не являются чем-то обычным?
Ну, у темной стороны силы есть msdn.microsoft.com/en-us/library/ff678491.aspx
которое как раз все эти три пункта и реализует, и кучей других полезностей :)
которое как раз все эти три пункта и реализует, и кучей других полезностей :)
Занятная штука
Посмотрите еще это
channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV207
channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV207
На мой взгляд, дело в той IDE, которую используете, и корпоративном стиле.
Например, для MySQL в своих проектах я использую MySQL Workbench — он делает выгрузку в один create script с дополнительной возможностью генерации alter script на его же основе. Этот скрипт лежит в папке data под управлением svn и используется всеми разработчиками для создания своей локальной версии проекта.
На работе коллеги, работающие с Oracle организовывают работу примерно как вы описали — один объект в одном файле, и все файлы лежат опять же в svn. Используется PL/SQL Developer.
Например, для MySQL в своих проектах я использую MySQL Workbench — он делает выгрузку в один create script с дополнительной возможностью генерации alter script на его же основе. Этот скрипт лежит в папке data под управлением svn и используется всеми разработчиками для создания своей локальной версии проекта.
На работе коллеги, работающие с Oracle организовывают работу примерно как вы описали — один объект в одном файле, и все файлы лежат опять же в svn. Используется PL/SQL Developer.
Согласен, стили разные, IDE разные — гавная идея статьи была в том, чтобы работать именно с кодом БД. Разные визуализаторы, генераторы альтеров это здорово, но использовать их стоит только как вспомогательные средства, а не как основной инструмент для разработки, не задумываясь что вообще творится с кодом.
Для тех, кто работает с Oracle: vcs + Liquibase.
Согласен, но не только для тех, кто работает с ораклом. Вообще БД, как и исходники проекта, обычно постоянно изменяется и эти изменения нужно как то накатывать. Используют различные подходы от самописных инструментов, механизмов, библиотек до каких-либо готовых решений, например liquibase. Смысл один — версионирование БД, т.е. последовательное накатывание скриптов с запоминанием некой метаинформации об выполненных скриптах (версия, чексумма, автор и т.д.) иногда с возможностью откатить скрипты.
У себя на проекте сейчас используем liquibase, БД — MySQL, до этого в другом проекте использовались raw-changelog-и и свой инструмент. Считаю этот функционал must-have частью для большинства порядочных и уважающих себя проектов.
У себя на проекте сейчас используем liquibase, БД — MySQL, до этого в другом проекте использовались raw-changelog-и и свой инструмент. Считаю этот функционал must-have частью для большинства порядочных и уважающих себя проектов.
Аналогия БД с исходным кодом на java или другим языком — неверная. Вернее, эти две вещи имеют разную мощность абстракции. Код на java — это по сути метаданные, в то время как БД — это метаданные ПЛЮС данные. В этом вся разница и вся сложность: нельзя просто менять (накатывать, откатывать, мерджить и т.д.) метаданные, без оглядки на привязанные к ним данные.
Код хранимок — пожалуйста, можно версионировать. С этим проблем нет. Да вот только этот код жестко привязан к структуре таблиц, триггерам и т.д., которые уже в том же слое абстракции версионировать не получится.
На самом деле, генератор diff продакшен- и дев-БД — не такая плохая идея, как кажется, если генератор поддерживает ручную коррекцию в середине процесса. Например, если ему можно в середине сказать, что вот это — не 2 операции «удалить колонку + добавить колонку», а на самом деле 1 операция «переименовать колонку». Вообще, таких деструктивных (опасных) операций в diff-е не так уж и много, даже если полностью запретить ему их генерировать (заставляя всегда их прописывать вручную), большой беды не будет. Удаление в метаданных БД — очень редкая операция, как и переименование.
Код хранимок — пожалуйста, можно версионировать. С этим проблем нет. Да вот только этот код жестко привязан к структуре таблиц, триггерам и т.д., которые уже в том же слое абстракции версионировать не получится.
На самом деле, генератор diff продакшен- и дев-БД — не такая плохая идея, как кажется, если генератор поддерживает ручную коррекцию в середине процесса. Например, если ему можно в середине сказать, что вот это — не 2 операции «удалить колонку + добавить колонку», а на самом деле 1 операция «переименовать колонку». Вообще, таких деструктивных (опасных) операций в diff-е не так уж и много, даже если полностью запретить ему их генерировать (заставляя всегда их прописывать вручную), большой беды не будет. Удаление в метаданных БД — очень редкая операция, как и переименование.
Полностью согласен.
Но есть и решения, которые предлагают вместе с ведение версионности метаданных вести и версионность самих данных. Как по мне, так это уже геморрой наживать.
Конечно, все зависит от организации выполнения программы или проекта.
Например, в своей работе мы храним исходный код (именно код, а не DDL) в SVN. Структура БД в модели. Если изменяется структура БД, то изменения делаются в модели. Затем с помощью скриптов, полученных из модели автоматически, полуавтоматически или вручную (кому как удобно или в зависимости от изменений), вносятся изменения на тестовую или боевую БД.
Но есть и решения, которые предлагают вместе с ведение версионности метаданных вести и версионность самих данных. Как по мне, так это уже геморрой наживать.
Конечно, все зависит от организации выполнения программы или проекта.
Например, в своей работе мы храним исходный код (именно код, а не DDL) в SVN. Структура БД в модели. Если изменяется структура БД, то изменения делаются в модели. Затем с помощью скриптов, полученных из модели автоматически, полуавтоматически или вручную (кому как удобно или в зависимости от изменений), вносятся изменения на тестовую или боевую БД.
«Структура БД в модели» — это конечно удобно, нарисовал, выгрузил, накатил, но есть вопрос: например описание оператора CREATE TABLE в документации Oracle занимает несколько листов (это только операторы, без комментариев), наврядли какой либо визуальный инструмент предоставит функционал, позволяющий воспользоваться всеми возможностями. Т.о. получится пользоваться только той частью функционала, к которой приспособлен инструмент (IDE, генератор, моделер и т.д.)
«наврядли какой либо визуальный инструмент предоставит функционал, позволяющий воспользоваться всеми возможностями»
Пока не встречал таких проблем. Да и не думаю, что в этом действительно есть какая-то проблема. Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры. Какие здесь могут быть разночтения? К тому же никто не мешает особенности все же хранить в виде отдельных скриптов. Просто соотношение таких исключений к общему количеству таблиц в БД будет, имхо, мизерным.
Пока не встречал таких проблем. Да и не думаю, что в этом действительно есть какая-то проблема. Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры. Какие здесь могут быть разночтения? К тому же никто не мешает особенности все же хранить в виде отдельных скриптов. Просто соотношение таких исключений к общему количеству таблиц в БД будет, имхо, мизерным.
«Пока не встречал таких проблем. Да и не думаю, что в этом действительно есть какая-то проблема.»
Думаю ве зависит от приложения и от того как и какую БД оно использует.
Если база используется в качестве простого хранилища (порой разработчики даже не используют встроенную в БД поддержку ссылочной целостности, обосновывая это выйгрышем в производительности), то само собой и париться не надо.
Так же существуют БД-ориентированные приложения, где большинство логики реализовано именно на стороне базы, которые по максимуму используют возможности своей СУБД.
Думаю ве зависит от приложения и от того как и какую БД оно использует.
Если база используется в качестве простого хранилища (порой разработчики даже не используют встроенную в БД поддержку ссылочной целостности, обосновывая это выйгрышем в производительности), то само собой и париться не надо.
Так же существуют БД-ориентированные приложения, где большинство логики реализовано именно на стороне базы, которые по максимуму используют возможности своей СУБД.
> «есть какая-то проблема»
Был такой issue в предыдущем проекте — база изначально жила в Power Designer, из которой генерился DDL. Надо было добавить deferred constraints, которых не было по умолчанию предусмотрено в IDE. В итоге пришлось копаться в шаблонах, из которых PD генерил код или искать еще какой-то workaround. Чуть позже, когда количество костелей к IDE подобралось к критической отметке, PD был заброшен. Так что проблема существует, факт.
> «Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры»
На самом деле, у всех IDE что мне встречались, которые позволяют моделировать структуру и писать код — есть куда большая беда, они в отсутствии живой базы не способны этот код отвалидировать. Так что существование dev-инстанса (или несколько шире — нескольких окружений разработки) как места разработки «на живую», с последующим внесением кода в репозитарий, мне представляется несколько более удобным вариантом.
А подход, когда структуры генерятся из IDE, а обвязка цепляется из отдельных текстовых файлов выглядит еще более разбродной. Хотя тут конечно же вопрос силы воли сопровождающего.
Был такой issue в предыдущем проекте — база изначально жила в Power Designer, из которой генерился DDL. Надо было добавить deferred constraints, которых не было по умолчанию предусмотрено в IDE. В итоге пришлось копаться в шаблонах, из которых PD генерил код или искать еще какой-то workaround. Чуть позже, когда количество костелей к IDE подобралось к критической отметке, PD был заброшен. Так что проблема существует, факт.
> «Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры»
На самом деле, у всех IDE что мне встречались, которые позволяют моделировать структуру и писать код — есть куда большая беда, они в отсутствии живой базы не способны этот код отвалидировать. Так что существование dev-инстанса (или несколько шире — нескольких окружений разработки) как места разработки «на живую», с последующим внесением кода в репозитарий, мне представляется несколько более удобным вариантом.
А подход, когда структуры генерятся из IDE, а обвязка цепляется из отдельных текстовых файлов выглядит еще более разбродной. Хотя тут конечно же вопрос силы воли сопровождающего.
про «версионность данных» я ничего не говорил, это отдельная большая тема.
«Аналогия БД с исходным кодом на java или другим языком — неверная.» — может не верно выразился, я проводит аналогию в плане отношения разработчиков к исходному коду БД, для многих его как будто и не существует.
Использовать генератор форм и прочие визуальные фичи (в java например) часто считается дурным тоном (программист сам должен следить за своим кодом), а вот в БД пожалуйста — понажимали на кнопки в любимой IDE, выгрузили полученные скрипты и готово.
Использовать генератор форм и прочие визуальные фичи (в java например) часто считается дурным тоном (программист сам должен следить за своим кодом), а вот в БД пожалуйста — понажимали на кнопки в любимой IDE, выгрузили полученные скрипты и готово.
Sign up to leave a comment.
Наболевшее об исходном коде объектов БД