是否有一些关于 SQL 表太大的硬性规则?
我们以名称/值对格式存储 SCORM 跟踪数据,每个用户每门课程可能有 4-12 行,由于有数百门课程和数千名用户,这将是一件坏事吗?
神奇的数字是数十亿。在您获得数十亿行数据之前,您根本不会谈论太多数据。
算一算。
每门课程每个用户 4-12 行,......数百个课程和数千个用户?
400,000 到 1,200,000 行。假设每行 1000 个字节。
那是 400Mb 到 1.2Gb 的数据。您可以在 Apple 商店以 299 美元的价格购买 100Gb 驱动器。您可以轻松地将超过 299 美元的可计费时间花在那些不再重要的细节上。
在您获得 1Tb 数据(1,000 Gb)之前,您根本谈不上太多数据。
我个人有 5000 万行的生产表,这与我听说的相比很小。您可能需要通过分区来优化您的结构,但是在您在您的环境中测试您的系统之前,您不应该浪费时间这样做。你所描述的是非常小的恕我直言
我应该补充一下,我使用的是 SQL Server 2000 和 2005,每个 DBMS 都有自己的大小限制。
100(课程)* 1000(用户)* 10(记录)只有一百万。这是低端,但一个像样的数据库应该可以处理它。
听起来很可疑的是名称/值对。这将限制您正确索引事物的能力,这对于良好的性能至关重要。
没有硬性规定,但有一种硬性和快速的方法来获得数字。
编写一个程序,用与实际数据的预期形式大致近似的虚拟数据填充您的表(例如,相似的规律性、字符、模式等)。使用带有虚拟数据的实际查询对其运行性能测试,逐渐增加行数在表中,可能以 1000 或 10000 行为步长。
当查询性能(例如每秒完成的查询)变得不可接受时,您将拥有“太大”的行数。
我曾经研究过一个 Web 表单系统,其名称/值对表中有超过 3 亿行。许多表单每次提交的表单超过 300 行。性能实际上并不算太差,但它是一个完整的 PITA 查询!我的 sql 编写能力在这次演出的整个生命周期中肯定有所提高。
但是恕我直言,如果您有任何发言权,请摆脱它以支持标准规范化表。
并不真地。这完全取决于您的业务需求,您必须购买支持您估计的行数的产品。
不,关于表中可以有多少行并没有真正的硬性规定,这在很大程度上取决于行中有多少数据,以及数据可以被索引的程度。
对您所说的数字进行快速估计会得出数千万行。这当然不是太多,但如果你不小心,它可能会成为一个问题就足够了。
也许表格可以标准化?是否经常出现相同的名称,以便您可以将名称放在单独的表中并使用表中的 id?
我不认为这里真的有限制,但是驱动空间。但是请在小的时候添加好的索引,因为当表很大时,添加索引需要更长的时间。另外,如果您有错误的索引,查询会随着它的增长而变慢,并且当确实没有任何问题时人们会抱怨,但是没有索引是很糟糕的。
我曾在数据库上工作过,我们试图创建包含 2B 行数据的表——这不起作用,我们达到了 500M 并重新设计。使用如此大的表的最大问题之一是删除所需的时间——我经常看到将旧记录存档然后从主表中删除的方法。如果表足够大,在重建索引时删除将运行数小时。
不知道截断在哪里,但直觉表明表格 > 10M 行可能太大了。我们的方法是按日期对数据进行分区,因此我们最终得到了一个包含一周数据的表,另一个是几个月的汇总表,另一个是多年的汇总表——这在 DataWarehousing 中很常见。顺便说一句,这是在 SQL 7.0 上,想知道数据库是否更擅长这种类型的东西?
你的问题提出的问题多于答案。
我已经建立了一些存储 SCORM 数据的数据库,而且我从来不需要像你建议的那样使用标签/值系统。
您要记住的一件事不是表中的行数,而是表的大小(以字节为单位)。简单地:
表大小 = 行大小 (avg) * 行数
要问的问题是,“多大的桌子太大了”?