数据库设计:一个大表还是单独的表?

从一张大桌子开始,然后用2008年的 表分区 适当情况下的能力, .

数据仓库应该很大(线索就在名称中)。两千万行按仓储标准算是中等,不过六亿行可以算是大行。

要记住的是,如此大的表有不同的物理,像黑洞。所以调整它们需要一套不同的技术。另一件事是,数据仓库的用户必须了解他们正在处理大量的数据,因此他们不能期望每一个查询都有亚秒(甚至亚分钟)的响应。

分区是很有用的,特别是如果您有明确的界限,比如在您的案例中,客户。您必须知道分区可能会降低跨越分区键粒度的查询的性能。所以这不是一颗银弹。

分片 . 此外,数据库模式可以或多或少地规范化。规范化模式有单独的表,表之间有关系,并且数据不重复。

我假设你的数据库正常化了。在SQLServer中,处理在单个表上引用的数据量应该不是问题;我认为你需要做的是检查你的索引。

另一个选择是Dan Lindstedt的DataVault方法。这是一个有点复杂,但为您提供了充分的灵活性。

http://danlinstedt.com/category/datavault/

在一个正确设计的数据库中,这并不是一个庞大的记录量,SQLServer应该可以轻松处理。

一张分开的桌子通常是最好的选择。试图维护独立的独立客户表在时间和精力上都是非常昂贵的,而且更容易出错。

如果遇到性能问题,还可以检查当前查询。如果没有适当的索引(例如,是否索引了外键字段?),查询将很慢;如果没有可搜索的查询,则查询将很慢;如果使用相关子查询或游标,则查询将很慢。您返回的数据是否比striclty需要的多?如果您在生产代码中的任何地方都选择了*,那么就去掉它,只返回所需的字段。如果使用的视图调用调用视图的视图,或者使用的是EAV table,则会出现此级别的性能问题。如果您允许一个框架自动生成SQl代码,那么很可能查询性能很差。记住探查器是你的朋友。当然,你也可能有一个硬件问题,你需要一个相当大的专用服务器的数量记录。在你的网络服务器或一个小盒子上运行它是行不通的。

我建议您需要聘请一位具有性能调优经验的专业dba。这是很复杂的事情。应用程序程序员设计的数据库在获得大量用户和记录时往往表现不佳。数据库的设计必须考虑到数据的完整性、性能和安全性。如果你不这样做的话,拥有它们的变化确实很小。

分道扬镳绝对是一件值得研究的事情。我有一个数据库,有两个表切分。每个表包含大约3000-3500万条记录。此后,我将其合并到一个大表中,并分配了一些好的索引。到目前为止,我还没有分区这个表,因为它的工作是一种享受,但我会记住分区。我注意到一件事,与数据被切分时相比,那就是数据导入。现在速度变慢了,但我可以接受,因为导入工具可以重新编写;(o)

我认为基于所提供的信息,使用NOLOCK的建议是不合理的。NOLOCK意味着您将从查询中得到不准确和不可靠的结果(脏读和虚读)。在使用NOLOCK之前,您需要确保这不会对您的客户造成问题。

这是一张单人平桌(没有特殊型号)吗?通常在数据仓库中,您要么有一个标准化的数据模型(至少是第三种标准形式-通常在实体关系模型中),要么有维度数据(Kimball方法或变体-通常是在一组星中具有关联维度表的事实表)。

在这两种情况下,索引在很大程度上发挥了作用,分区也可以在让查询在非常大的数据集上执行方面发挥作用(但分区通常不是关于性能,而是关于能够快速添加和删除分区的维护),但这实际上取决于聚合的顺序和查询的类型。

一张桌子,然后担心性能。也就是说,假设您为每个客户收集完全相同的信息。这样,如果您必须添加/删除/修改列,那么您只能在一个位置进行操作。

保留一个表—2000万行并不是很大,客户也不是那种可以轻松“归档”的表,搜索多个表以找到客户的做法并不值得(SQL在B树搜索方面可能比您自己的发明更有效)

如果存在常见查询,还可以创建补充表,其中包含已计算的历史信息的详细信息。