Добавление столбца программным способом в базу данных SQL Server

Question

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

Стороннее приложение создает файлы, которые представляют этикетки принтера, сгенерированные пользователем. Эти файлы меток напрямую ссылаются на поля источника ODBC. Каждая строка таблицы представляет продукт, который заполняет поля метки. (Итак, внутри этих файлов есть прямые ссылки на имена столбцов таблицы.)

Приложение ASP.NET позволяет пользователю создавать / обновлять данные для этих полей, на которые ссылаются метки, путем добавления или редактирования определенной строки, представляющей продукт.

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

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

Answer 1

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

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

Answer 2

Один из вариантов, который я считаю, состоит в том, чтобы использовать таблицу KVP для хранения динамических «столбцов» (как впервые упомянул Митч), объединить таблицу продуктов с таблицей KVP на основе идентификатора продукта, а затем повернуть результаты, чтобы получить все динамические столбцы в наборе результатов.

---

РЕДАКТИРОВАТЬ: что-то вроде этого:

Подготовка:

create table Product(ProductID nvarchar(50))

insert Product values('Product1')
insert Product values('Product2')
insert Product values('Product3')

create table ProductKVP(ProductID nvarchar(50), [Key] nvarchar(50), [Value] nvarchar(255))

insert ProductKVP values('Product1', 'Key2', 'Value12')
insert ProductKVP values('Product2', 'Key1', 'Value21')
insert ProductKVP values('Product2', 'Key2', 'Value22')
insert ProductKVP values('Product2', 'Key3', 'Value23')
insert ProductKVP values('Product3', 'Key4', 'Value34')

Получить:

declare @forClause nvarchar(max),
        @sql nvarchar(max)

select @forClause = isnull(@forClause + ',', '') + '[' + [Key] + ']' from (
    select distinct [Key] from ProductKVP /* WHERE CLAUSE */
) t

set @forClause = 'for [Key] in (' + @forClause + ')'

set @sql = '
select * from (
select 
    ProductID, [Key], [Value]
from (
        select k.* from 
        Product p
        inner join ProductKVP k on (p.ProductID = k.ProductID)
        /* WHERE CLAUSE */
    ) sq
) t pivot (
    max([Value])' +
    @forClause + '
) pvt'

exec(@sql)

Результаты:

ProductID   Key1      Key2      Key3      Key4
----------- --------- --------- --------- -------
Product1    NULL      Value12   NULL      NULL
Product2    Value21   Value22   Value23   NULL
Product3    NULL      NULL      NULL      Value34

Answer 3

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

«Гибридный» подход обоих может быть интересен.

Сохраняйте значения, которые вы хотите запросить, в выделенных столбцах, а остальные оставляйте в виде большого двоичного объекта XML (MS SQL имеет приятные функции даже для запросов внутри XML) или, в качестве альтернативы, в пакете KVP. Лично мне действительно не нравятся KVP в БД, потому что вы больше не можете создавать специфичные для логики приложения индиксы.

Еще один подход - вообще не моделировать конкретные столбцы. Вы создаете общие таблицы «пользовательских атрибутов», такие как: Attribute1, Attribute2, Attribute3, Attribute4 (для требуемого типа данных и т. Д.). Затем вы добавляете метаданные в свою базу данных, которые описывают, что означает AttrX для определенного типа метки принтера.

Опять же, это действительно зависит от того, как вы хотите использовать эти данные в конце.

Answer 4

Один риск - стол становится слишком широким. Я имел обыкновение поддерживать ужасное приложение, которое добавляло 3 столбца «автоматически», когда новые значения были добавлены в некоторый XML (по какой-то причине он думал, что все будет строкой, датой или числом - отсюда и создание 3 столбцов).

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