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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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