db comparer

← →
картман © (2010-12-22 17:03) [0]

посоветуйте, плиз, чтобы могла сравнивать базу с резервной копией

← →
Sergey13 © (2010-12-22 17:08) [1]

А чего там сравнивать то?

← →
картман © (2010-12-22 17:10) [2]

объекты

← →
Sergey13 © (2010-12-22 17:31) [3]

> [2] картман © (22.12.10 17:10)
> объекты
Что объекты?

Что хоть за СУБД?

← →
Jeer © (2010-12-22 17:36) [4]

dbf :)
Судя по посту об АдынСы

← →
картман © (2010-12-22 17:40) [5]

> Jeer © (22.12.10 17:36) [4]

неа - SQL Server 2005. Это вопросики для разных проектов)

> Что объекты?

я наверное не так понял [1]: одна версия лежит в резервной копии, а другая - собсна БД - искать отличия в них надо, а не только БДv1 vs БДv2

← →
Sergey13 © (2010-12-22 17:52) [6]

> [5] картман © (22.12.10 17:40)
> я наверное не так понял [1]:

Наверное да. В БД есть таблицы, в таблицах есть записи, есть прцедуры и другая всякая фигня. Каков критерий сравнения? Совпадение структуры или идентичность всех записей в них?
Просто смысл сравнения разных БД (допустим у разработчика и клиента) мне понятен. А вот смысл сравнения со своей копией, которую сам же и делаешь мне не очень понятен.

← →
картман © (2010-12-22 18:00) [7]

> А вот смысл сравнения со своей копией, которую сам же и
> делаешь мне не очень понятен.
>

совпадение структуры. Не с копией. Вчера сделали бэкап - v1. Сегодня структура поменялась - v2. v1 - файл резервной копии, v2 - БД. Нужно сравнить v1 с v2, не восстанавливая v1.

← →
vuk © (2010-12-22 18:04) [8]

to Sergey13 © (22.12.10 17:52) [6]:

> А вот смысл сравнения со своей копией, которую сам же и
> делаешь мне не очень понятен.

Смысл вполне даже имеется, если предположить, что разработка ведется не на живой БД, а на отдельной и иногда нужно синхронизировать эти БД по составу объектов. У нас для этого используется AdeptSQL Diff. Но это сравнение не с резервной копией, а именно с другой БД.

← →
Jeer © (2010-12-22 18:10) [9]

Не знаю инструментов сравнения живой базы с бекап-ами.
Может и есть, но не попадались.

Мне кажется проще развернуть на второй тестовой БД и сравнивать, да хоть через ErWin.

← →
картман © (2010-12-22 18:13) [10]

> Не знаю инструментов сравнения живой базы с бекап-ами.
> Может и есть, но не попадались.

точно есть - сам делал, да вот подзабыл чем((

> Мне кажется проще развернуть на второй тестовой БД и сравнивать,
> да хоть через ErWin.

ну, в крайнем случае да

← →
картман © (2010-12-22 18:13) [11]

> сам делал

сравнивал

← →
картман © (2010-12-22 18:17) [12]

> не на живой БД, а на отдельной и иногда нужно синхронизировать
> эти БД по составу объектов

да, все так.

← →
Sergey13 © (2010-12-23 11:48) [13]

> [8] vuk © (22.12.10 18:04)
> Но это сравнение не с резервной копией, а именно с другой БД.
Так я про это и писал.

> [6] Sergey13 © (22.12.10 17:52)
> Просто смысл сравнения разных БД (допустим у разработчика
> и клиента) мне понятен.

Но вот сделать бекап и тут же сравнивать его с оригиналом...
ИМХО если структура поменялась - надо делать свежий бекап. 8-)

> [12] картман © (22.12.10 18:17)
> > не на живой БД, а на отдельной и иногда нужно синхронизировать
>
> > эти БД по составу объектов
>
> да, все так.

Тогда при чем тут резервные копии? Промышленная база не является резервной копией для базы разработчика. Как и наоборот. 8-)

Для ИБ ИБЭксперт хорошо сравнивает СТРУКТУРУ баз. Для МССКЛ не знаю. Но
http://www.google.ru/search?hl=ru&source=hp&q=ms+sql+compare+database&aq=8&aqi=g9&aql=&oq=ms+sql+compa&gs_rfai=
выдал больше миллиона ссылок.

← →
картман © (2010-12-23 13:14) [14]

> Тогда при чем тут резервные копии?

издеваешься? Притом, что одна из версий БД лежит в *.bak-файле(ну как еще мне назвать этот файл?) и восстанавливать я ее не хочу.

> выдал больше миллиона ссылок.

хде там указано, какая из них может то, что мне нужно?

ладно, нашел уже.

← →
Sergey13 © (2010-12-23 14:18) [15]

> [14] картман © (23.12.10 13:14)
> издеваешься?

Да ни чуть. Просто я уже запутался.
> Вчера сделали бэкап - v1. Сегодня структура поменялась - v2. v1 - файл резервной копии, v2 - БД. Нужно сравнить v1 с v2, не восстанавливая v1.
V1 - это вчерашнее состояние той же базы которая сегодня V2? Т.е. ты пытаешься вычленить то, что сам сегодня делал ("Сегодня структура поменялась")?

> ладно, нашел уже.

Не находишь, что весьма недурно было бы огласить результат для "будущих поколений"?

← →
картман © (2010-12-23 22:18) [16]

RedGate SQL Toolbelt, платный... но есть на rutracker.org , значит можно)))

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

> Т.е. ты пытаешься вычленить то, что сам сегодня делал

да!

> Sergey13 © (24.12.10 09:14) [17]
>
> > [16] картман © (23.12.10 22:18)
> > да!
>
> ИМХО проще записывать. 8-)

да я пытаюсь, все пытаюсь...

to Sergey13 © (24.12.10 09:14) [17]:

> ИМХО проще записывать. 8-)

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

> "Записывать" тут не только не проще, но и вообще не поможет.

почему не поможет?

> [19] vuk © (24.12.10 12:29)

Да я представляю зачем и как делается сравнение БД. Меня в данном конкретном случае смутило, что исходная информация - бекап. Если учесть, что он делается (должен) каждый день (а то и не раз), то смысла в этом действии я не вижу. Ну если только ведется детальный лог бекапов и они хранятся вечно. Но все равно это какой то ректальный способ по моему получится.
Если надо обслуживать и дорабатывать промышленные БД, то (при недоступности ее онлайн) держится или ее копия или вводится понятие версий БД или что-то вроде этого. ИМХО

to картман © (24.12.10 12:37) [20]:

> почему не поможет?

Потому, что, например, на таблицы нужно "записывать" скрипты модификации структуры.

to Sergey13 © (24.12.10 14:37) [21]:

> Меня в данном конкретном случае смутило, что исходная информация
> - бекап.

Собственно, меня тоже. Проще иметь восстановленную из него копию.

2картман ©

Первичным является процесс проектирования/изменений структуры DB.
Вот эти изменения и надо хранить в историческом плане, а бекапы привязывать к версии DB каким угодно способом.

db comparer Найти похожие ветки