我开发了一个工具，它可能有超过一百万个数据需要填写。
目前我设计了 36 列的单表。我的问题是我需要将这些分成多个表还是单个？
如果单身有什么好处和坏处
如果是多个，那么优点和缺点是什么
以及用于提高速度的引擎是什么...
我担心的是一个大型数据库，每天至少有 50000 个查询..
有什么帮助吗？？
问问题
220 次
6 回答
4
是的，您应该规范化您的数据库。一般的经验法则是，如果不是外键的列包含重复值，则应该对表进行规范化。
规范化涉及将数据库拆分为表，并有助于：
- 避免修改异常。
- 最小化数据结构更改的影响。
- 使数据模型更具信息性。
维基百科上有大量关于规范化的信息。
如果您有大量数据并且没有进行规范化，您最终将需要重新设计您的数据库，而这很难追溯，因为它不仅涉及更改访问的任何代码数据库，还将所有现有数据迁移到新设计。
在某些情况下，出于性能原因避免标准化可能会更好，但在做出此决定之前，您应该对标准化有一个很好的了解。
于 2010-12-20T23:47:15.793 回答
1
首先要问自己，您是在重复字段还是字段的属性。您的一张表是否包含应该分开的关系或属性。遵循第三范式......我们需要更多信息来帮助，但一般来说，一张有 36 列的表闻起来像一个 db 屁。
于 2010-12-20T23:49:14.533 回答
0
相关性并不意味着因果关系。
仅仅因为大量的列通常表示糟糕的设计，并不意味着大量的列是糟糕的设计。
如果您有一个规范化模型，您可以存储一个表所需的任意数量的列。
于 2010-12-21T09:39:05.823 回答
0
这取决于！
那一张表是否包含一个“实体”？即所有 36 列属性是一个单一的东西，还是有几个“东西”混合在一起？
如果混合，那么你应该规范化（分离成不同的实体，它们之间有关系）。您应该至少以第三范式(3NF) 为目标。
最佳实践是尽可能地标准化；如果您稍后发现性能问题，则尽可能少地进行非规范化。
于 2010-12-20T23:48:41.070 回答
0
如果你想存储一百万行相同的行，那就去吧。任何体面的数据库都可以应付更大的表。
设计您的数据库以最适合数据（从您的应用程序中看到），启动它，然后再进行优化。您可能会发现性能不是问题。
于 2010-12-20T23:49:50.460 回答
0
您应该根据要存储的数据对数据库进行建模。这称为“规范化”：本质上，每条信息只应存储一次，否则表格单元格应指向包含该值的另一行或表格。例如，如果您有一个包含电话号码的表格，并且一列包含区号，那么您可能会在同一列中拥有多个具有相同值的电话号码。一旦发生这种情况，您应该为区号设置一个新表，并通过引用存储所需区号的行的主键来链接到其条目。
所以而不是
id | area code | number
---+-----------+---------
1 | 510 | 555-1234
2 | 510 | 555-1235
3 | 215 | 555-1236
4 | 215 | 555-1237
你将会拥有
id | area code id | number | area code
---+---------- ---+----------+-----------
1 | 510 1 | 555-1234 | 1
2 | 215 2 | 555-1235 | 1
3 | 555-1236 | 2
4 | 555-1237 | 2
如果以这种方式组织数据，尤其是在处理字符串值或二进制数据时，相同值的出现次数越多，就越有可能节省内存并获得更快的性能。此外，如果区号发生变化，您只需更新单个单元格，而不必对整个表格执行更新操作。
试试这个教程。
于 2010-12-21T00:05:02.740 回答