我正在寻找关于在关系数据库中保存客户可配置数据的方法的一些想法(在我的例子中是SQL Server 2000)。
例如,假设您有一个标准订单输入应用程序,您的客户输入他们想要购买的产品。除了对您和客户都很重要的字段(itemID,成本等)之外,您还希望允许客户输入仅与其相关的信息并为其保留(以便以后检索报告或发票或其他) 。您还希望客户配置这些“客户字段”的标签。因此,一个客户可能有一个名为“发票编号”的字段,另一个客户可能有2个字段,名为“发票编号”和“发票日期”等...
我可以想到几种方法来做到这一点。您可以拥有一个customerfields表,其中包含与每个事务相关的一些合理数量的varchar字段,然后是另一个表clientcustomerfields,其中包含有关客户使用的字段数,字段名称等的元数据。或者您可以使用XML来保留客户数据,所以你不必担心填写X#字段,你仍然需要一些表来描述客户元数据(可能通过XSD)。
有没有标准方法可以做这类事情?
答案 0 :(得分:3)
您应该阅读Best Practices for Semantic Data Modeling for Performance and Scalability。这正是链接中白皮书所解决的问题。
答案 1 :(得分:2)
我使用的一种策略:
customer_fields
- field_id
- cusomer_id
- field_name
customer_transaction_field_values
- transaction_id
- field_id
- field_value
答案 2 :(得分:1)
作为概括,我建议不要使用opaque XML blobs在关系数据库中存储面向字段的数据。
最佳解决方案是在应用程序中设置一些“用户”字段和配置,以设置如何使用和显示这些字段。如果字段是varchars,则空字段的开销相当小,IIRC每字段大约1个字节。虽然这看起来不那么优雅并且具有有限数量的字段,但查询和填充是最简单的,这使得它最快。一种选择是使配置与字段数量无关,只需运行一个脚本,以便在需要时添加更多字段。
另一个选择是让“编码”表挂起用户可配置字段的实体。它具有“实体ID”,“字段类型”和“字段代码”列,其中“字段类型”列表示实际内容。特别的缺点是它会使查询变慢,因为它们必须多次连接这个表。
我实际上已经看到在同一系统上使用了(1)和(2)。供应商最初从(2)开始,但后来发现它很痛苦,应用程序的后续子系统转到使用(1)。这种方法的改变是出于痛苦的经历。
针对XML blob的主要攻击是它们不是数据库模式中的一等公民。 DBMS本身不能对blob强制实施参照完整性,它无法索引blob中的各个列,并且从blob查询数据更复杂,报告工具可能不支持。此外,blob的内容对系统数据字典完全不透明。任何试图从系统中提取数据的人都需要依赖应用程序的文档才能深入了解内容。
答案 3 :(得分:0)
除了你自己的建议,另一种方法是在ASP.net中查看Profile Provider系统(假设有一个MS技术堆栈)。您可以扩展ProfileBase以包含表示用户定义键的2个数组和相应值的另一个数组。此时,SqlProfileProvider将处理此类存储和检索,并创建ProfileBase对象的实现。最终,这与您尝试在Web应用程序项目中使用ProfileProvider系统而不是Web站点项目(使用不同的构建管理器)类似。
答案 4 :(得分:0)
我过去曾这样做,并使用了用户定义字段的概念。我会为基本类型创建四个表:
然后我会有一个表格来描述字段及其类型:
CustomField - id - int,customer_id - int(链接到customer表),fieldType - 'UDFCharacter,UDFNumber等',name - varchar和其他元信息
对字段的响应将在UDF表中进行。字段将根据CustomField表显示在页面上。我们的系统可能更复杂,需要更多的tbales,但这似乎可行。