Как ваш толстый клиент проверяет, совместим ли он с схемой базы данных?

Я разрабатываю приложение с компонентами с толстым клиентом и тонким клиентом. Мы также обновляем нашу базу данных таким образом, чтобы изменения схемы приводили к их собственному номеру версии и могли применяться сценарии изменения. Изменения базы данных, однако, не всегда происходят в шаге с изменениями с толстым клиентом. Да, сегодняшнее изменение базы данных могло бы добавить столбец и потребовать в толстом клиенте, но завтра изменение базы данных может исправить ошибку в хранимой процедуре, которая не требует каких-либо внешних изменений. Как я могу закодировать толстый клиент, чтобы проверить, совместим ли он с конкретной версией базы данных, когда некоторые из них совместимы с обратной связью, а некоторые нет?Как ваш толстый клиент проверяет, совместим ли он с схемой базы данных?

Даже если кто-то заботится, наше приложение .NET интегрируется с SQL Server, но это похоже на вопрос о версии, а не на вопрос о платформе. Если не существует решения для конкретной платформы ...

источник

2010-01-26 flipdoubt

См. Http://stackoverflow.com/questions/115369/do-you-source-control-your-databases. Дубликат http://stackoverflow.com/questions/33638/testing-and-managing-database-versions-against-code-versions –

Также дубликат http://stackoverflow.com/questions/1534579/verify-database-changes -version-control и http://stackoverflow.com/questions/308/is-there-a-version-control-system-for-database-structure-changes и http://stackoverflow.com/questions/257045/managing -the-migration-of-break-database-changes-to-a-database-shared-by-old-v –

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

И разделите версию на два числа (например, мажорная/второстепенная схема). Когда вы меняете схему не в обратном направлении, то вы вносите основную версию. После обратной совместимости вы просто обновляете небольшую версию.

Major используется приложением, чтобы проверить, совместимо ли оно с текущей схемой, а major + minor используется для проверки необходимости или необходимости обновления схемы.

Я думаю, что это решение, которое используется большинством приложений.

источник

2010-01-26 13:09:09 silk

Не могли бы вы принять схему номера основных/младших версий?

Изменение значительного числа означает, что клиенты нуждаются в обновлении, а изменение в младшем числе - нет.

источник

2010-01-26 13:05:29 djna

Таблица «номер версии», которая записывает основную и второстепенную версию, необходима для каждого проекта базы данных. Он должен иметь один ряд. Приложения должны просто запросить его, прежде чем что-либо делать. –

@ S.Lott: Можете ли вы поделиться немного более подробной информацией об этом подходе «номер версии»? –

@Tahir Akhtar: 'CREATE TABLE MY_APPLICATION_VERSION (COMPONENT VARCHAR, MAJOR NUMBER, MINOR NUMBER);' Каждое изменение обновляет эту таблицу текущей версией именованного компонента. Каждое приложение запрашивает это, чтобы получить текущую версию именованного компонента. –

С любым из них номера версий всегда увеличиваются.

Если база данных знает минимальную клиентскую версию, которой она требует, и клиент знает минимальную версию базы данных, которую он требует, это простая проверка, чтобы определить, что требуется для обновления (если что-либо) - теперь, будь вы инкапсулируете логику в сохраненную процедуры или кода, это ваше решение ...

источник

2010-01-26 13:08:30

Как ваш толстый клиент проверяет, совместим ли он с схемой базы данных?

ответ

Смежные вопросы