在SQL Server中分解大型表更好吗？

Question

我正在设计一个金融应用程序，保存许多证券的报价。每个证券的历史数据可以是成百上千万的报价(可能有成百上千种不同的证券)。

是将每个证券的报价放在一个单独的表中更好，还是可以使用一个大表？

如果我使用一个表，我将需要提供symbol+time的唯一键以防止重复引用，而使用多个表将要求我只对时间列使用一个列键。

谢谢

顺便说一句，我问这个是因为我开始使用实体框架，似乎我不能在不添加ADO.NET的情况下使用它在运行时创建表，因此我需要提前知道我需要哪些表(因此我不能为新的证券添加新表)。还是我全搞错了？

Answer 1

表可以通过存储进行partitioned，但这可能不符合您的兴趣：

虽然分区可以提供很大的好处，但它增加了对象实现的管理开销和复杂性，这可能是一种负担，而不是收益。具体地说，您可能不希望对小表或当前满足性能和维护要求的表进行分区。前面提到的销售场景使用分区来减轻移动行和数据的负担-在决定是否实现分区时，您应该考虑您的场景是否有这种负担。

此外，如果您的目标是将数据分隔到单独的文件组(最终是磁盘组/阵列)中，则可以使用存储系统(组中包含多个驱动器的SAN LUN、分散负载的多个驱动器的RAID阵列)来实现相同的目标。

如果您的存储空间足够并且代码很紧凑，那么您的应用程序使用一个表就可以了。

Answer 2

使用过程化生成的表总是一个不好的主意。如果您的系统在实现其目标上花费的时间太长，也许您应该考虑使用OLAP Cube --毕竟，这就是设计它们的目的。

Answer 3

您应该可以使用单个表以及适当的索引和约束选择。

您可以对表进行分区，但这样做的主要用途不是为了性能，而是为了管理，因为这允许您以滚动的方式删除旧数据并添加新的数据分区。除了时间之外，这可能对您没有什么用处；您不太可能按股票代码进行分区-我不确定这在管理分区方面有什么优势。

我可能会考虑将聚集索引设置为ticker (可能是ticker表中的int代理，也可能只是ticker)和time。

在这样一个简单的数据模型中，它与维度模型几乎没有区别，但是如果您想要阅读数据仓库性能的维度建模，这可能会很有用，特别是使用正交的日期维度和时间维度的功能/缺点。如果您的数据是intraday，则可能需要使用单个datetime列。