Как программно проверить, создать и обновить структуру таблиц SQL?

Question

Сценарий:

У меня есть приложение (C #), которое ожидает базу данных SQL и имя входа, которые устанавливаются пользователем. После подключения он проверяет наличие нескольких таблиц и создает их, если они не найдены.

Я хотел бы остановиться на этом, имея возможность добавить в эти таблицы столбцы, если я выпущу новую версию программы, основанную на новых столбцах.

Вопрос:

Каков наилучший способ программной проверки структуры существующей таблицы SQL и создания или обновления ее в соответствии с ожидаемой структурой?

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

Критерий:

Вот некоторые из моих ожиданий и добровольных правил:

• Более новые версии программы могут больше не использовать определенные столбцы, но они будут сохранены для целей регистрации данных. Другими словами, столбцы не будут удалены.
• Существующие данные в таблице должны быть сохранены, поэтому таблицу нельзя просто удалить и создать заново.
• Во всех случаях новые добавленные столбцы допускают нулевые данные, поэтому для заполнения старых записей используются нулевые значения по умолчанию.

Пример:

Вот пример таблицы (потому что наглядные примеры помогают!):

id  datetime         sensor_name  sensor_status  x1    x2    x3    x4
1   20100513T151907  na019        OK             0.01  0.21  1.41  1.22
2   20100513T152907  na019        OK             0.02  0.23  1.45  1.52

Затем в новой версии я могу добавить столбец x5. «x -колонки» - это все столбцы хранения данных, которые принимают ноль.

Edit:

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

Answer 1

Общее решение, которое я вижу, - хранить в вашей базе данных информацию о версии. может быть, действительно маленький столик:

CREATE TABLE DB_PROPERTIES (key varchar(100), value varchar(100));

тогда вы можете добавить строку:

    key | value
version | 12

Тогда вы можете просто создать скрипт обновления sql (или набор скриптов), который обновляет БД с версии 12 до версии 13.

declare v  varchar(100)
select v=value from DB_PROPERTIES where key='version'
if v ='12'
    #do upgrade from 12 to 13
elsif v='11'
    #do upgrade from 11 to 13

...and so on

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

Answer 2

Это очень неприятная функция, которую вы думаете о реализации.я бы посоветовал против этого и вместо этого рассмотрел бы изменения сценариев с помощью стороннего инструмента, такого как Sql Compare от Red Gate: http://www.red -gate.com / products / SQL_Compare / index.htm

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

Другой способ решения этой проблемы заключается в перепроектировании базы данных с использованием модели EAV: http://en.wikipedia.org/wiki/Entity-attribute-value_model (Pivotsдинамически добавлять строки, таким образом, никогда не меняя структуру. У нее есть свои проблемы, но она очень гибкая.)

(Чтобы использовать инструмент сравнения, вам понадобится копия всех ваших версий БД и создание сценариев сравнениякоторый вышел бы и выполнялся с новыми выпусками и обновлениями. Это огромная путаница, которую нужно поддерживать. EAV - это путь к подобной вещи. Он ошибочно воспринимается как недостаток производительности как традиционной структуры БД.но я использовал его несколько раз с большим успехом.На самом деле, у меня есть HAVAA-совместимая EAV db (Sql Server 2000), которая была в производстве более шести лет с несколькими из таблиц EAV, содержащих десятки или миллионы строки это все еще идет сильный без большого замедления. Конечно, мы не делаем тяжелую отчетность противчто дб.Для отчетов у нас есть экспорт, который объединяет данные в реляционную структуру.)

Answer 3

Попробуйте Microsoft.SqlServer.Management.Smo
Это набор классов C #, которые предоставляют API для объектов базы данных SQL Server.
Microsoft.SqlServer.Management.Smo.Table имеет коллекцию столбцов, которая позволит вам запрашивать и манипулировать столбцами. Веселитесь.

Answer 4

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

Предлагаемая структура дочерней таблицы

ЧТЕНИЯ ID int Тип чтения varchar (10) Reading_Value int

Тогда данные в таблице будут выглядеть так:

ID Reading_type Reading_value 1 х 1 2 1 х 2 3 1 х 3 1 2 x1 7