代码之家 › 专栏 › 技术社区 › Stimy

在数据库中保存客户可配置数据的方法有哪些?

data-modeling database-design tsql sql-server sql

Stimy · 技术社区 · 15 年前

我正在寻找在关系数据库中持久化客户可配置数据的方法(在我的例子中是SQL Server 2000)。

例如,假设您有一个标准的订单输入应用程序,您的客户在其中输入他们想要购买的产品。除了对您和客户都很重要的字段(itemID、cost等),您还希望允许客户只输入与它们相关的信息,并为它们保留这些信息(以便以后检索报告或发票或其他内容)。您还希望这些“客户字段”的标签由客户配置。因此,一个客户可能有一个名为“发票号”的字段,另一个客户可能有两个名为“发票号”和“发票日期”等字段。

我可以想出一些方法来做到这一点。您可以有一个CustomerFields表,其中包含一些与每个事务相关的合理数量的varchar字段,然后是另一个表clientCustomerFields,其中包含有关客户使用的字段数、字段名等的元数据。或者,您可以使用XML来持久化客户数据,这样就不必担心填充x个字段,您仍然需要一些表来描述客户的元数据(可能通过XSD)。

做这种事情有什么标准的方法吗?

5 回复 | 直到 9 年前

Remus Rusanu 9 年前

你应该阅读 Best Practices for Semantic Data Modeling for Performance and Scalability . 这正是链接中白皮书提出的问题。

Matt Wrock 15 年前

我使用的一个策略是:

客户字段
菲尔菲尔德
角鲨目
字段名

客户交易字段值
-交易记录ID
菲尔菲尔德
-字段值

ConcernedOfTunbridgeWells 15 年前

一般来说,我建议不要使用不透明的XML块将面向字段的数据存储在关系数据库中。

最好的解决方案是在应用程序中设置一些“用户”字段和配置,以设置如何使用和显示这些字段。如果字段是varchar,则空字段的开销相当小,每个字段的IIRC大约为1字节。虽然这看起来不雅,而且字段数量有限,但查询和填充最简单,这使得它成为最快的。一种选择是使配置不受字段数量的限制,如果需要,只需运行一个脚本来添加更多的字段。
另一种选择是让“编码”表挂起用户可配置字段的实体。它有“实体ID”、“字段类型”和“字段代码”列,其中“字段类型”列表示实际内容。特别的缺点是,它使查询速度变慢,因为它们必须多次针对该表进行联接。

实际上,我已经看到(1)和(2)都在同一个系统上使用。供应商最初从(2)开始,但后来发现这是ARSE中的一个难题,随后应用程序上的子系统使用(1)。这种方法上的改变是由痛苦的经历证明的。

针对XML blob的主要攻击是它们不是数据库模式中的第一类公民。DBMS不能单独对blob执行引用完整性,它不能索引blob中的各个列,从blob查询数据更复杂,报告工具可能不支持。此外,blob的内容对于系统数据字典是完全不透明的。任何试图从系统中提取数据的人都依赖于应用程序的文档来了解内容。

JamesEggers 15 年前

除了您自己的建议之外,另一种方法是查看ASP.NET中的配置文件提供程序系统(假设在此基础上有一个MS技术堆栈)。您可以扩展profilebase以包含2个表示用户定义键的数组,以及另一个表示相应值的数组。此时,sqlprofileProvider将处理此类的存储和检索,并创建profileBase对象的实现。最终,这将类似于在Web应用程序项目而不是网站项目(使用不同的构建管理器)中尝试使用ProfileProvider系统。

efleming 15 年前

我在过去做过这个工作,并使用了用户定义字段的概念。我将为基本类型创建四个表:

udfcharacter-id-int,order_id-int,value-varchar(4000)
udfnumber-id-int,order_id-int,value-float
udfdatetime-id-int,order_id-int,value-datetime
udftext-id-int,order_id-int,value-text

然后我会有一个表描述字段及其类型:

customfield-id-int、customer_id-int(链接到customer表)、fieldtype-'udfcharacter、udfnumber等'、name-varchar和其他元信息

对字段的响应将进入UDF表。这些字段将基于CustomField表显示在页面上。我们的系统可能更复杂,需要更多的tbales,但这似乎可以工作。