|
|
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Собственно задача - сабж. Кто чем пользуется (и пользуется ли)? Задача с одной стороны тривиальна: 1. периодически отслеживать изменение объектов БД (очень желательно "пообъектно"). Т.е. знать когда именно появилась/изменилась/удалилась конкретная сущность в БД, при этом: * по таблицам само собой есть желание контролировать как появление самих таблиц, так и изменение их структуры (новые поля, модификация полей, удаление полей) * по процедурам - контролировать текст процедур на изменение * по индексам - контролировать состав индексов и т.д. Может есть что-то реально полезное в этой области? Пока склоняюсь к написанию своей структуры в БД, которая периодически будет делать SnapShot и сравнивать его с уже существующим, фиксируя различия и привязывая их к определенной версии/изменению и т.п. Но есть желание ознакомиться с существующим модельным рядом велосипедов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 09:57 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Запрещаете ddl на базе разработчикам, и заливаете изменения только через выполнение скриптов в триггере git-а на push в общий репозиторий (master ветка). Тестировать - остается только на локальной базе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 11:16 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Гхостик, это само собой и так сделано. Но никоим образом не облегчает контроль версионности объектов, а именно поиск когда какое изменение было сделано в структуре объектов сводится к банальному поиску по тексту скриптов в репозитории, что, мягко сказать, не совсем удобно и не всегда тривиальная задача. Задача именно оперативного контроля и возможности поиска. Т.е. грубо найти когда было добавлено поле в таблицу, или изменена процедура, почему и зачем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 11:55 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83Кто чем пользуется (и пользуется ли)? Лично я пользуюсь CVS в котором хранится образцово-показательный скрипт создания всей БД и скрипты апгрейда версий. Ковыряться в БД "наживо" - запрещено. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 12:00 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, а с точки зрения визуализации и удобства использования? Интеграции может быть с СВН или другой системой контроля версий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 12:10 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83Задача именно оперативного контроля и возможности поиска. Т.е. грубо найти когда было добавлено поле в таблицу, или изменена процедура, почему и зачем. Именно для этого мне служит архив почтовой рассылки checkin-ов. Простой текстовый поиск легко находит точный коммит, а стало быть его автора и комментарий. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 12:21 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83Интеграции может быть с СВН или другой системой контроля версий? CVS это и есть система контроля версий. Причём, на мой взгляд, гораздо лучшая чем SVN. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 12:31 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83никоим образом не облегчает контроль версионности объектов, а именно поиск когда какое изменение было сделано в структуре объектов сводится к банальному поиску по тексту скриптов в репозиторииМожно же искать не по текущему состоянию, а по истории изменений (коммитам), а в коммите уже и дата, и разработчик есть, и номера багов в примечании если регламент на это есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 12:38 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovКовыряться в БД "наживо" - запрещено. как запретили? всегда же кто-нибудь залезет если срочно нужно что-то оптимизировать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 15:39 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Wizandrкак запретили? Административно. Ну и grant/revoke тоже никто не отменял. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 15:52 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Правильно изменения делать, конечно, не способом 'срочно нужно что-то оптимизировать', а через систему контроля версий. Там же должны быть ссылки на баги/изменение функционала и т.п. документы, объясняющие причины изменений в схеме. Для контроля изменений уже внутри базы можно использовать Liquibase, или просто табличку типа dbconfiglog в которую каждый DDL скрипт должен записывать номер релиза и комментарий к изменениям в версии схемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2014, 22:15 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83Собственно задача - сабж. Кто чем пользуется (и пользуется ли)? ... Но есть желание ознакомиться с существующим модельным рядом велосипедов... Зачем?! Во всех нормальных SQL СУБД существует лог транзакций. По ним вы всегда можете отследить кто, что и когда делал. Кроме того лог транзакция позволяет "откатить" БД на определенную дату. Единственное, что не может лог транзакций это отменить единичное изменение. Только все до определенного состояния. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 06:59 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
mad_nazgulВо всех нормальных SQL СУБД существует лог транзакций. По ним вы всегда можете отследить кто, что и когда делал. Покажите мне: как из лога транзакций вытащить кто и зачем добавил в определённую таблицу определённое поле примерно полгода назад? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 11:44 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
On 05.08.2014 10:57, Mikle83 wrote: > Кто чем пользуется (и пользуется ли)? сейчас как бы храним в SVN модель БД в виде SDesigner, и скрипты всех объектов там же. Ранее (другая работа) использовали ErWin + ModelMart. > * по таблицам само собой есть желание контролировать как появление самих > таблиц, так и изменение их структуры (новые поля, модификация полей, > удаление полей) > * по процедурам - контролировать текст процедур на изменение ПРоцедуры -- это вообще тривиально, это обычный код, он в SVN лежит. И всё. > * по индексам - контролировать состав индексов > и т.д. Всё остальное можно тоже расценивать, как обычный код. Но это неинтересно, тогда вся задача решается тривиально. > Может есть что-то реально полезное в этой области? Есть. Обычно стоит бешеные бабки и неудобно. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 13:26 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
On 05.08.2014 13:31, Dimitry Sibiryakov wrote: > CVS это и есть система контроля версий. Причём, на мой взгляд, гораздо > лучшая чем SVN. Странно такое слышать. CVS -- редкостное говно. А SVN -- это CVS, но сделанный по-человечески. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 13:28 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
MasterZivА SVN -- это CVS, но сделанный по-человечески. Остаётся только гадать откуда росли руки этих человеков, которые сделали 1) Размер рабочей копии в два раза больше чем у CVS 2) Отсутствие сжатия данных, передаваемых по сети 3) Локальное сравнение двух старых ревизий 4) Выдачу ошибки при исчезновении файла вместо получения с сервера его чистой копии Очевидно, они никогда не видели проектов больше мегабайта и отдельных файлов больше пары килобайт. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 13:37 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83Задача с одной стороны тривиальна: 1. периодически отслеживать изменение объектов БД (очень желательно "пообъектно"). Т.е. знать когда именно появилась/изменилась/удалилась конкретная сущность в БД, при этом: Назначить ответственного и бюрократизировать изменения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 15:45 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovmad_nazgulВо всех нормальных SQL СУБД существует лог транзакций. По ним вы всегда можете отследить кто, что и когда делал. Покажите мне: как из лога транзакций вытащить кто и зачем добавил в определённую таблицу определённое поле примерно полгода назад? "Кто" сказать смогу, "зачем" скзать тоже смогу если напишут комментарий к таблице. Главное чтобы логи были и их не shrink'нули ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 15:56 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
mad_nazgulГлавное чтобы логи были и их не shrink'нули Сколько места займут логи за полгода на Вашей БД? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 15:59 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83Собственно задача - сабж. Кто чем пользуется (и пользуется ли)? ... Пока склоняюсь к написанию своей структуры в БД, которая периодически будет делать SnapShot и сравнивать его с уже существующим, фиксируя различия и привязывая их к определенной версии/изменению и т.п. 1. Для таблиц - не пользовались. Для анализа хватало скриптов на изменение - банальный текстовый поиск в скриптах, правда с использованием регулярных выражений, поскольку форматирование скриптов было неуправляемо. 2. Для процедур и взглядов: - предоставили инструмент из приложения, который сохранял автора, дату изменения и новое тело, прежде чем обновить в БД. Поскольку изменения структуры БД могли производиться как через приложение так и скриптами, добавили фишку: если в истории последний текст не совпадал с текущей версией в БД, в историю сначала сохранялся текст текущей версии в БД а потом уже создавалась новая версия... - дали возможность вызвать сравнивалку текста для любых двух версий. Не обеспечивало полноты истории, но добавляло удобства для сопровождающих программистов. Для повышения полноты истории можно было бы устроить тот самый периодический снепшот. Но: вместо " периодически делать снапшот" лучше делать снепшот структуры до и после применения скрипта - так можно установить автора, более точное время изменения структуры и получить ссылку на сам скрипт изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 16:19 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
MasterZivсейчас как бы храним в SVN модель БД в виде SDesigner, и скрипты всех объектов там же. 1.1. SDesigner - это что именно? 1.2. То есть всегда есть версия модели, соответствующая моментам до и после применения очередного скрипта на БД? MasterZiv> Может есть что-то реально полезное в этой области? Есть. Обычно стоит бешеные бабки и неудобно. Так как называется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 16:32 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
АнатоЛойвместо " периодически делать снапшот" лучше делать снепшот структуры до и после применения скрипта - так можно установить автора, более точное время изменения структуры и получить ссылку на сам скрипт изменений. Да, тоже прибился к этому варианту. Есть утилита, обеспечивающая накат всех изменений из репозитория. Перед накатом каждой фичи формируется "снимок" и сравнивается с "эталоном". Если есть отличия - они помещаются в архив с пометкой "Изменения без прирвязки к фиче", читай "кто-то влез руками и сделал - найти и наказать". Затем снятый снимок принимается за эталон и уже после наката фичи производится еще один "снимок" - и уже его дифф с эталоном привязывается непосредственно к фиче. Есть ненулевая (но оч. малая) вероятность, что кто-то во время деплоя изменит структуру руками и этом изменение уйдет в архив с привязкой к фиче. Всем спасибо - понял одно. Нормального "велосипеда" в этой области нет - нужно свой собирать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 16:37 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Sergei.AgalakovПравильно изменения делать, конечно, не способом 'срочно нужно что-то оптимизировать', а через систему контроля версий. Там же должны быть ссылки на баги/изменение функционала и т.п. документы, объясняющие причины изменений в схеме. Для контроля изменений уже внутри базы можно использовать Liquibase, или просто табличку типа dbconfiglog в которую каждый DDL скрипт должен записывать номер релиза и комментарий к изменениям в версии схемы. Думал в направлении таблички и скриптов, но основные моменты, которые заставили отказаться от этой идеи: а) регламентация жесткая по использованию блока записи в таблицу. б) если никак не регламентировать/не структурировать сами комменты - будет бардак полный в) отслеживать изменения не совсем тривиальная задача. Как делать поиск по объекту? Полнотекстовый поиск по коменту к изменению? Да ну его... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 16:45 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
Mikle83Думал в направлении таблички и скриптов, но основные моменты, которые заставили отказаться от этой идеи: а) регламентация жесткая по использованию блока записи в таблицу. б) если никак не регламентировать/не структурировать сами комменты - будет бардак полный в) отслеживать изменения не совсем тривиальная задача. Как делать поиск по объекту? Полнотекстовый поиск по коменту к изменению? Да ну его... Пункт в) решается вышеупомянутым Liquibase. Остальные 2 пункта - не совсем понятно, что имеется ввиду, но описать ЗАЧЕМ сделано изменение, кроме разработчика, просто некому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 18:06 |
|
||
|
Контроль версионности схемы БД
|
|||
|---|---|---|---|
|
#18+
HoBTIDОстальные 2 пункта - не совсем понятно, что имеется ввиду, но описать ЗАЧЕМ сделано изменение, кроме разработчика, просто некому. Да ладно. ЗАЧЕМ - должен был описать аналитик/архитектор в соответствующем требовании на разработку. Само собой есть система учета требований и есть желание линковать изменение на требования в итоге (что в принципе и получилось). Разработчик может для себя сделать комменты, но дублировать ТЗ в коментах - да ну его... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 11:25 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38712745&tid=1540826]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
25ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 124ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...