我们有许多来自网络服务的项目；每个项目包含未知数量的属性。我们将它们存储在具有以下架构的数据库中。
物品
- 物品ID
- 物品名称
属性
- 属性ID
- 属性名称
- 属性值
- 属性值类型
- 传输时间
- ItemID [fk]
属性表变得非常大，因为它存储了每个项目的属性，每次调用 Web 服务时。我的问题是：我们应该在什么时候停止向 Properties 表添加新记录，并根据传输时间归档旧的 Property 记录？什么时候属性表变得太大，查询时间太长？有经验法则吗？
谢谢。
【问题讨论】：
标签： sql-server performance optimization
我认为这没有黄金法则。尽管规范化会导致性能显着下降，但您的架构已非常规范化。
需要考虑的几个因素：
- 使用场景
- 服务器硬件规格
- 数据库操作的性质（例如，读多于写？插入而不更新？）
对于您的情况，如果属性的数量不超过特定数量，则单个锯齿形表可能会更好，也可能不会。 （我可能会因为这个声明而被激怒：P）
归档策略还取决于您的业务需求/要求。您可能需要提升硬件以满足该需求。
【讨论】：
我不确定 MS SQL Server，但大多数数据库似乎都有分区表的方法。也就是说，从许多较小的表中创建一个虚拟表，并根据一些简单的规则在它们之间划分数据。
这对于像这样的基于时间的数据非常有用。将表格划分为一天或一小时等时间段。然后每个时间段添加一个新的表分区并删除最旧的表分区。比现在执行 DELETE WHERE time
或者，与其丢弃最旧的，不如将其存档，或者只是让它占据空间。只要您的查询始终指定日期范围，查询就只能使用最合适的子表。
【讨论】：
没有经验法则
一些想法：
【讨论】：
根据您拥有的特定“属性类型”的数量，观察模式可能会有所帮助。
在您的示例中：
Item = Subject,
Property = Observation,
PropertyName = ObservationType.Name,
PropertyValueType = ObservationType.IsTrait
这样您就不会在每条记录中重复 PropertyName 和 PropertyValueType。根据您的应用程序，如果您可以在应用层缓存ObservationType 和Subject，那么插入功能也会得到改善。
- 测量和特征是类型
观察。测量是一种
数字观察，如高度。
特征是描述性观察，
喜欢颜色。
【讨论】：