Есть ли какая-нибудь возможно однозначно идентифицировать копию БД. Поясню что я имею в виду: Есть БД (1), потом её бекапят и востанавливают под тем же именем по тому же пути, на той же машине что и (1), причём (1) уже убита. Или востанавливают бекап на другой машине с тем же путём что и (1). Вот можно ли как-то отличить базы (1) и (2)?
Здравствуйте, xdeltax, Вы писали:
X>Есть ли какая-нибудь возможно однозначно идентифицировать копию БД. Поясню что я имею в виду: Есть БД (1), потом её бекапят и востанавливают под тем же именем по тому же пути, на той же машине что и (1), причём (1) уже убита. Или востанавливают бекап на другой машине с тем же путём что и (1). Вот можно ли как-то отличить базы (1) и (2)?
Т.е. отличить? Ты хочешь сделать так, чтобы каждая копия БД, сделанная из бэкапа была уникальна? Ну... можно написать процедуры для бэкапа/восстановления, которые будут заодно в специальную таблицу вставлять GUID, например. Подойдет?
MC>Т.е. отличить? Ты хочешь сделать так, чтобы каждая копия БД, сделанная из бэкапа была уникальна? Ну... можно написать процедуры для бэкапа/восстановления, которые будут заодно в специальную таблицу вставлять GUID, например. Подойдет?
Ага что-то вроде этого. Только у нас нет возможности контролировать процесс бекапа/рестора или атача/детача БД. Следовательно процедурки для записи в спец таблицы отпадают. Нужно что-то чтобы пользователь об этом даже не догадывался. Более подробно опишу суть проблемы, может поможет:
Есть система, которая работает с двумя БД, которые абсолютно одинаковы по структуре, и вся разница лишь в количестве данных, т.е. одна, которая меньшая — используется для работы, а другая, которая на порядок больше служет чем-то вроде хранилища. Так вот, если ничайно попутать местами базы (не туда подключиться), то система начинает делать винегрет из баз (короче их просто нельзя путать). Что бы дать системе, холть какие-то шансы на жизнь, в маленькой базе была заведена специальная запись в служебной таблице. По сути, это лишь временное решение, потому что большая база делается следующим образом: берётся маленькая и клонируется... следовательно поле-флай оказывается в ней и опять происходит винегрет...
Мне кажется, Ваша проблема решается по другому. Насколько я понимаю, данные попадают в основное хранилище автоматизированно. Ну так пусть только тот, "программный модуль" (сервис репликации, джоб или клиентская прога), который производит синхронизацию, имеет право на работу с основным хранилищем. А у остальных пользователей надо эти права отобрать. Или я что-то недопонял? Или нет возможности применять "административные" средства?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, xdeltax, Вы писали: X>>В том то и дело что нет возможности
MC>А что можно делать? Просто, зная список разрешенного, легче предложить вариант.
В общем дело обстоит так: мы предоставляем ПО, которое работает с БД, но администрирование и настройку делают уже пользователи. И мы их не можем обязать делать настройку серверов как нам надо. Им же в свою очередь что-то делать просто лень. По-этому и хочется сделать так, чтобы они даже не о чём не догадывались, и в то же время, чтобы не были перепутаны базы
Здравствуйте, xdeltax, Вы писали:
MC>>Т.е. отличить? Ты хочешь сделать так, чтобы каждая копия БД, сделанная из бэкапа была уникальна? Ну... можно написать процедуры для бэкапа/восстановления, которые будут заодно в специальную таблицу вставлять GUID, например. Подойдет?
X>Ага что-то вроде этого. Только у нас нет возможности контролировать процесс бекапа/рестора или атача/детача БД. Следовательно процедурки для записи в спец таблицы отпадают. Нужно что-то чтобы пользователь об этом даже не догадывался. Более подробно опишу суть проблемы, может поможет: X>Есть система, которая работает с двумя БД, которые абсолютно одинаковы по структуре, и вся разница лишь в количестве данных, т.е. одна, которая меньшая — используется для работы, а другая, которая на порядок больше служет чем-то вроде хранилища. Так вот, если ничайно попутать местами базы (не туда подключиться), то система начинает делать винегрет из баз (короче их просто нельзя путать). Что бы дать системе, холть какие-то шансы на жизнь, в маленькой базе была заведена специальная запись в служебной таблице. По сути, это лишь временное решение, потому что большая база делается следующим образом: берётся маленькая и клонируется... следовательно поле-флай оказывается в ней и опять происходит винегрет...
Это конечно не ответ на Ваш вопрос, но я бы порекомендовал сменить архитектуру "большой" базы и сделать ее полноценной data warehouse.
Здравствуйте, kuj, Вы писали:
kuj>Это конечно не ответ на Ваш вопрос, но я бы порекомендовал сменить архитектуру "большой" базы и сделать ее полноценной data warehouse.
Здравствуйте, xdeltax, Вы писали:
X>В общем дело обстоит так: мы предоставляем ПО, которое работает с БД, но администрирование и настройку делают уже пользователи. И мы их не можем обязать делать настройку серверов как нам надо. Им же в свою очередь что-то делать просто лень. По-этому и хочется сделать так, чтобы они даже не о чём не догадывались, и в то же время, чтобы не были перепутаны базы
Тут сложно что-либо сказать. Разве что попробовать предоставлять скрипт настройки. Все же, при неправильном использовании можно что угодно поломать.
Здравствуйте, Mr.Cat, Вы писали:
MC>Тут сложно что-либо сказать. Разве что попробовать предоставлять скрипт настройки. Все же, при неправильном использовании можно что угодно поломать.
Нашёл временное решени, может и приживётся: дата создания файла mdf Т.к. всегда пользуются разворачиванием БД из бекапа, то вероятно поможет. А скорее всего сделаю две записи в бд:
1. Хеш по дате создания mdf 2.
2. Хеш по всей остальной доступной информации (имя бд, путь к файлам и т.п.)
Т.к. всегда пользуются разворачиванием БД из бекапа, то вероятно поможет. А скорее всего сделаю две записи в бд: 