Question

我已经接管了需要重写的ASP.NET应用程序。我需要复制的此应用程序的核心功能修改了从第三方软件通过ODBC访问的SQL Server数据库。

第三方应用程序创建表示用户生成的打印机标签的文件。这些标签文件直接引用ODBC源的字段。表格的每一行代表一个填充标签字段的产品。（因此，在这些文件中直接引用表的列名。）

ASP.NET应用程序允许用户通过添加或编辑代表产品的特定行来创建/更新标签引用的这些字段的数据。

它还允许偶尔添加新字段......它实际上在核心表中创建了一个由标签引用的新列。

我担心：我以前从未以编程方式更改现有表的列。现有的应用程序似乎处理这个功能很好，但在我在新的应用程序中盲目地做同样的事情之前，我想知道这样做有什么样的陷阱，如果有的话...并且如果有任何明显的选择

Answer 1

当向表中添加过多列时会出现问题，如果考虑性能，则必须小心（覆盖索引不适用，因此可能会执行昂贵的书签查找）。

另一个替代方案是键值对结构：Key Value Pairs in Database design，但它也存在陷阱，你最好创建新列，正如你所建议的那样。（KVP适合设置）

Answer 2

我认为一个选项是使用KVP表存储动态“列”（如Mitch首先提到的），根据产品ID将产品表与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

一个风险是桌子太宽了。我曾经维护过一个可怕的应用程序，当新值添加到某些XML时，它会“自动”添加3列（由于某种原因，它认为所有内容都是字符串的日期或数字 - 因此创建了3列）。

还有其他一些技术，比如序列化BLOB或以不同的方式设计表格可能有所帮助。

Answer 4

这在很大程度上取决于您要对这些表运行的查询。 KVP的主要缺点是更复杂的查询可能变得非常低效。

两者的“混合”方法可能很有趣。

将要查询的值存储在专用列中，将其余值保留在XML blob中（MS SQL具有很好的功能，甚至可以在XML中查询），或者在KVP包中。就个人而言，我真的不喜欢DB中的KVP，因为你不能再建立特定于应用程序逻辑的indix了。

另一种方法是根本不对特定列进行建模。您可以创建通用的“自定义属性”表，例如：Attribute1，Attribute2，Attribute3，Attribute4（用于所需的数据类型等）然后，您可以将元数据添加到数据库中，以描述AttrX对特定类型的打印机标签的含义。< / p>

同样，它实际上取决于你最终如何使用这些数据。

以编程方式将列添加到SQL Server数据库

4 个答案: