|
|
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
Обычно в литературе рекомендуется хранить код ХП и прочего в системе контроля версий типа Source Safe. Кто-нибудь так делает? Какие собственно реальные преимущества это имеет перед обычным бэкапом базы вместе с соответствующим релизом проекта? Как например поступать если изменилась схема базы? Или что делать с наполнением базы метаданными... В общем не вижу не одного повода использовать SS для работы с БД... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 03:58 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenfordВ общем не вижу не одного повода использовать SS для работы с БД... А зря Коллега... Подумайте внимательно - любой код проходит ступени "мачуризации" (ну или выдержки) : разработка, тестирование, интеграция, внедрение, использование, устаревание... Абсолютно любой кусочек кода... Для этого и придуманы устройства контроля ... ну типа SS... Чем по-вашему SQL код лучше? Или хуже? ... То что администраторы делают свертки (ну или бэкапы) разве влияет на выдержку кода? Если они сделали - так только ведь того кода который занесен в текущий сет. А если не сделали? а уже 25 человек знают что этот (точно этот- v.12.1.12.111 , а не v. 11.1.1.23 который сейчас есть) код уже был в базе данных.... И все классы и методы работали с ним, а не с (хммм )- прошлой версией ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 04:16 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenfordОбычно в литературе рекомендуется хранить код ХП и прочего в системе контроля версий типа Source Safe. Кто-нибудь так делает? Мы весь код храним в TFS - от самой простой записки до полной бинарной конструкции.. И разделены все они по своим полочкам - вот системный код, вот код базы данных, вот сервиса приложений, клиента, подключений, ETL, сборки, проекта, конструкции... и так далее.. Не делайте никаких скидок ни одному кусочку кода - и поймете что так будет гораздо проще... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 04:23 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
конечно хранить код сам по-себе лучше в SS, тут я не спорю, но проблема в том, что помимо кода в БД есть масса других вещей типа схемы и метаданных. Как обрабатывать ситуацию, когда изменились таблицы и в БД влиты данные для работы системы (не тестовые данные конечно, а метаданные, например список типов продукции и тп). Если предположим создается сборка каждый день, то нет ничего сложного в бэкапе базы вечером и сохранения в SS именно бэкапа, а не отдельных ХП и функций, разве не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 04:24 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenford...когда изменились таблицы и в БД влиты данные для работы системы (не тестовые данные конечно, а метаданные, например список типов продукции и тп). Вы знаете в чем различие DDL от DML, Коллега? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 04:26 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
знаю, но вы не ответили на вопрос. Т.е. вы создаете все эти скрипты, верно? Как в таком случае происходит откат на одну из предыдущих версий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 04:31 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenfordзнаю, но вы не ответили на вопрос. Т.е. вы создаете все эти скрипты, верно? Как в таком случае происходит откат на одну из предыдущих версий? Каждая версия имеет свой индивидуальный статус, все объекты - прежде всего, a данные должны быть синхронизированы отдельно. например нам надо восстановить систему на версии 1.12.1, а текущая версия 1.14.5. У нас есть бэкап данных версии 1.12.1; 1.12.2; 1.12.3; 1.13.1;.... 1.14.5 . Eсли между верcией 1.12.1 и 1.14.5 прошло 4 года... Как Вы думаете чем это поможет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 04:39 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
в смысле? Если надо восстановить версию четырехлетней давности, то с бэкапом я ее восстановлю за минуту. А что делать, если нет бэкапа, а только скрипты - даже не представляю. И почему данные должны храниться отдельно от структуры (если вы это имели ввиду). Я-же специально указал, что речь идет о метаданных системы, хотя на самом деле и некоторые тестовые данные не помешают ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 05:55 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenfordОбычно в литературе рекомендуется хранить код ХП и прочего в системе контроля версий типа Source Safe. Кто-нибудь так делает? Какие собственно реальные преимущества это имеет перед обычным бэкапом базы вместе с соответствующим релизом проекта? Как например поступать если изменилась схема базы? Или что делать с наполнением базы метаданными... В общем не вижу не одного повода использовать SS для работы с БД... Да, мы делаем, своих программистов сразу заставлял все DDL заливать в Starteam. Преимущества - 1) Всегда есть под рукой текущий текст UDF, View, Stored Procedure и т.д. 2) Упрощение параллельной разработки По поводу хранения бекапов, о котором Вы так настаиваете ниже. Представим абсолютно реальную ситуацию (с которой мы, в частности, сталкиваемся): Программист 1 работает над какой-то частью БД, а программист 2 - над другой. У каждого - локальный экземпляр БД. Что будет, если программист 2 захочет посмотреть, как работает его часть с учетом изменений, сделанных программистом 1, если он восстановит себе бекап программиста 1? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 09:23 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
Edkonst2008 Да, мы делаем, своих программистов сразу заставлял все DDL заливать в Starteam. Преимущества - 1) Всегда есть под рукой текущий текст UDF, View, Stored Procedure и т.д. 2) Упрощение параллельной разработки По поводу хранения бекапов, о котором Вы так настаиваете ниже. Представим абсолютно реальную ситуацию (с которой мы, в частности, сталкиваемся): Программист 1 работает над какой-то частью БД, а программист 2 - над другой. У каждого - локальный экземпляр БД. Что будет, если программист 2 захочет посмотреть, как работает его часть с учетом изменений, сделанных программистом 1, если он восстановит себе бекап программиста 1? в смысле хочет посмотреть на незакомиченные изменения? Есть-же общей центральный сервер, куда проводяться изменения, когда они готовы. Опишите пожалуйста что вы делаете для отката версии проекта на некоторое количество релизов назад ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 10:00 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenford wrote: > Обычно в литературе рекомендуется хранить код ХП и прочего в системе > контроля версий типа Source Safe. Кто-нибудь так делает? Думаю, так делают все здравомыслящие люди. Какие > собственно реальные преимущества это имеет перед обычным бэкапом базы > вместе с соответствующим релизом проекта? Любые, которые только ты придумаешь. Вообще, хранимые процедуры -- это обычный код, и место ему -- в VCS. В том же самом, где и код клиента, и код пром. звеньев, и структура БД. Как например поступать если > изменилась схема базы? Или что делать с наполнением базы метаданными... > В общем не вижу не одного повода использовать SS для работы с БД... См. мою первую строчку ответа. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 10:50 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenford в смысле хочет посмотреть на незакомиченные изменения? Есть-же общей центральный сервер, куда проводяться изменения, когда они готовы. Опишите пожалуйста что вы делаете для отката версии проекта на некоторое количество релизов назад Да, именно. Общий центральный сервер обновляется при передачи сборки в тестирование. Речь-то идет не о том, когда изменения готовы, а когда изменения еще делаются. Для отката версии есть view на любую сборку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 10:52 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenford wrote: > конечно хранить код сам по-себе лучше в SS, тут я не спорю, но проблема > в том, что помимо кода в БД есть масса других вещей типа схемы и > метаданных. Как обрабатывать ситуацию, когда изменились таблицы и в БД > влиты данные для работы системы (не тестовые данные конечно, а > метаданные, например список типов продукции и тп).' Храни ВСЁ в VCS. В одном, естественно. > Если предположим создается сборка каждый день, то нет ничего сложного в > бэкапе базы вечером и сохранения в SS именно бэкапа, а не отдельных ХП и > функций, разве не так? Ну, можно конечно и дампы баз хранить в VCS, толко как бы накладуха большая, и удобства никакого нет. Два дампа не сравнишь. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 11:02 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
Подниму тему. Т.е. хранение БД в системе контроля версий происходит следующим образом: создается скрипт всей базы вместе с ХП, функциями и метаданными и сохраняется в таком текстовом виде. В таком случае непонятно следующее: во-первых есть-ли такие инструменты, которые могут заскриптовать все обьекты в БД, включая данные в таблицах (метаданные для проектируемой системы). Во-вторых, подобное скриптование может происходить не каждый раз, когда что-то поменялось (уж сильно этот скрипт здоровый получается), а только предположим раз в день. Т.е. это означает, что в истории не будет сохранено кто именно изменил определенную ХП или таблицу. И собственно, чем подобное скриптование отличается от бэкапа? Если мне сильно надо найти изменения между 2 бэкапами, так я могу накатить бэкап, заскриптовать интересующую часть и сравнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2010, 10:52 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
stenford, Обычно скриптуются все отдельные объекты в базе. генератор такого скрипта будет зависеть от поставщика вашей базы данных. Универсальным я бы назвала SYBASE PowerDesigner - поддерживает 40+ версий различных поставщиков. Данные - чаще всего - это генерированные INSERT () - нужны только для инициации базы. В Текущих значениях - обычно пишутся скрипты на изменение какого либо объекта (или группы) - и изменений данных к нему (ним). Если Вам трудно представить себе что это - попользуйте трайл от SYBASE , Quest или RedGate ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2010, 16:22 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
Тоже заинтересовал данный подход. Можете примерно объяснить структуру Вашего хранилища (VCS)? С исходниками приложений все понятно, для каждого приложения можно создать свое хранилище, всякие (trunk, branch, tags), но приложение состоит из модулей, которые правятся отдельно и по объему не сравнятся с plain-дампом БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2010, 18:21 |
|
||
|
Хранить код БД в Source Safe
|
|||
|---|---|---|---|
|
#18+
Чугада, если "plain-дамп" - это схема БД без наполнения таблиц, то его тоже можно/нужно (подчеркнуть "нужно" :) хранить, также как нужно хранить некоторые бинарные сборки исходников клиента или сервера приложений. Но, кроме того, схему БД точно также можно "развалить" на сущности, как и "приложение [, которое] состоит из модулей, которые правятся отдельно и по объему": хранимые процедуры, взгляды, схемы таблиц (которые тоже можно развалить на поля, индексы, ограничения, триггера). Осталось только организовать правильную идеальную удобную структуру каталогов, в которой хранить схему, препарированную на исходники сущностей. Чугада модулей, которые ... по объему не сравнятся с plain-дампом БД. Согласен. Только в другую сторону. У меня типичный дамп схемы БД - 20 МБ (500 таблиц, 2000 ХП), а вот исходников (pas + dfm ) - 10 000 штук (140 МБ)... . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2010, 15:57 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=36552187&tid=1542765]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
175ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
| others: | 241ms |
| total: | 532ms |
| 0 / 0 |
