Lie*_*oen 5 database architecture forms sharepoint design-patterns
我有一个关于对象视图中的自定义字段的架构问题.假设您有一个用户对象,其中包含一些基本信息,如firstname,lastname,......可供所有客户使用.
现在,我们经常会从客户那里得到一个问题,即为他们的域添加几个典型的自定义字段.我们现在的解决方案是一个xml数据列,其中存储了键值对.到目前为止一切顺利,但现在我们必须找到更具架构性的解决方案.
例如,现在,客户想要一个下拉列表,可以选择其自定义字段的值.我们仍然可以将选定的值存储在xml数据列中,但是我们在哪里存储所有这些下拉值...
我知道在sharepoint中你还可以添加下拉列表等自定义字段,我想知道如何处理这个问题.我想避免为客户创建自定义表,或者有一个包含90列(10个基本,然后每个客户10个)的表,...
你明白了,它应该是通用的,并且能够在将来处理各种问题.
我在想的是一个Table UserConfiguration,其中每个记录都有一个Customer的外键(我们数据库中的Channel),然后是一个FieldName列,一个FieldType列和一个Column列.列值应该是xml类型列,因为对于下拉列表,我们需要添加多个值.此外,每个值都可以附加额外的数据(而不仅仅是名称).另一个问题是如何存储选定的值.我不喜欢在我的数据库中使用外键到xml的想法(在某处读取Azure无法处理这一切).你是否只存储了值的名称(如果值从xml中消失了怎么办?)?
任何文档,关于这类问题的链接也会很棒.我正在尝试找到一种处理数据库中此类问题的设计模式.
我想分两部分回答您的问题:
1)在数据库服务器中实现自定义字段
2)将自定义字段限制为值的枚举
尽管@Simon 引用的问题中讨论了 1) 的常见解决方案,但也许您正在寻找一些关于问题是什么以及为什么我们尚未解决该问题的讨论。
正如另一个问题中所讨论的,没有完美的解决方案。
但这些好处/功能仍然需要在某个地方实现,因此应用程序通常要负责数据完整性和类型安全。
对于这样的情况,人们已经创建了对象关系映射工具,尽管正如 Jeff Atwood所说,即使使用 ORM 也可能会产生比它解决的问题更多的问题。然而,您提到它“应该是通用的,并且能够处理未来的各种问题”——这让我认为 ORM 可能是您最好的选择。
所以,总结一下我的答案,这是一个已知的问题,有已知的解决方案,但没有一个是完全令人满意的(因为它太难了)。选择你的毒药。
要回答(我认为是)问题的第二部分:
正如链接问题中提到的,您可以在数据库中为自定义字段实现实体属性值,然后添加一个额外的表来保存每个字段的合法值实体。那么,EAV 表的属性/值是属性值表的外键。
例如,
CREATE TABLE `attribute_value` ( -- enumerations go in this table
`attribute` varchar(30),
`value` varchar(30),
PRIMARY KEY (`attribute`, `value`)
);
CREATE TABLE `eav` ( -- now the values of attributes are restricted
`entityid` int,
`attribute` varchar(30),
`value` varchar(30),
PRIMARY KEY (`entityid`, `attribute`),
FOREIGN KEY (`attribute`, `value`) REFERENCES `attribute_value`(`attribute`, `value`)
);
Run Code Online (Sandbox Code Playgroud)
当然,这个解决方案并不完美或完整——它只是为了说明这个想法。例如,它使用 varchar,并且缺少type列。另外,谁来决定每个属性的可能值是什么?用户可以随时更改这些吗?