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