我的数据库设计很差。其中一个最重要的表有11,000多个条目。我们想扩展我们的系统，我想知道这个表是否增长到它的大小的5倍，这会是一个问题吗？它的大小为15360 kB ......如果重要的话。
我正在使用phpMyAdmin，服务器是Fedora Linux盒子（没什么特别的），负载很轻。它几乎存储了我们系统使用的所有内容。
答案 0 :(得分：12)
什么是DBMS？什么服务器？什么负载？什么应用？
此外：11.000记录什么都没有，真的。甚至在MS Access中。 ： - ）
编辑： 所以我假设你使用一个相当新的MySQL和MyISAM表。从理论上讲，您可以继续将表格填入数百万条记录中。根据您使用它们的方式（很多连接/不连接，很多查询/更新/删除/不），您不需要做任何特殊的事情。在桌子上放一个适当的索引，你应该没事。
答案 1 :(得分：8)
我知道您担心在“设计不佳的数据库”中将记录数增加到55.000左右会影响性能。
如果您的系统按预期工作，我认为除非您有一些轻微的性能问题，否则您应该可以使用50.000记录。
正如大多数人所提到的，50k记录与数据库表大小相关的数字非常小，即使没有规范化的数据库，也不存在性能问题。
如果您计划扩展系统的功能，那么也许现在也是查看数据库设计的好时机，否则保持原样应该是合理安全的。
答案 2 :(得分：5)
我认为你没有提供足够的信息让别人给出答案。为什么设计不合理？它没有正常化吗？你没有任何索引吗？这是什么数据库？它运行的操作系统是什么？现在从相关表中查询记录需要多长时间？
答案 3 :(得分：4)
11k条目并不多。 50K也不大。
将索引放在表格上（针对您将在其上运行的查询进行了优化）将获得比您想象的更大的数量的良好性能。
如果设计不够好，你可能会考虑重新设计的成本。
答案 4 :(得分：1)
“设计不佳的数据库”是什么意思？
如果它设计得很糟糕，重新设计它，将信息拖出当前表格，并填充新表格。
如果你担心表现，11000个条目并不大。根据数据库标准，15兆字节的数据库非常小。
答案 5 :(得分：1)
表的大小不是很重要。密钥，索引和关系的设计与设计质量的关系远远大于其中包含的数据的大小。这显然有一些警告;但是在处理性能或设计问题时，优化表的大小几乎是我做的最后一件事。
您可能想要详细解释为什么您认为这是一个设计不佳的数据库，以及您可以（轻松）做些什么来纠正问题。除此之外，您还应详细说明DBMS的类型以及用途（Web应用程序，自定义应用程序，报告等）。
答案 6 :(得分：1)
15MB没什么。 11k行也是如此。我有2 GB以上数据的数据库，有些表包含超过100万行，我认为它介于中小尺寸之间。
答案 7 :(得分：1)
你真的没有提供任何证据来支持你声称这是一个设计糟糕的数据库。是什么让它设计不佳？该表有876列吗？列是Col1，Col2，Col3 ......？它是否使用float和datetime作为复合主键？它很难正常化？我们唯一知道的是它的记录数。
答案 8 :(得分：1)
11K记录通常没有数据库术语。
除了一个表中的记录数外，还有什么能让您认为数据库的设计很差？
答案 9 :(得分：1)
您需要提供有关表结构的更多信息。
一般来说，表中的15,000行会被认为很小，实际上很小，有些设计师可能甚至不会为索引编制索引。
答案 10 :(得分：0)
糟糕的基础将是你最昂贵的错误。如果表格很重要，那么您需要决定修复它的重要性。表中的行数仅影响从中提取内容的速度。但是，如果你的数据库设计开始不好，你的双手将在未来的某些地方被束缚。
答案 11 :(得分：0)
如果您正在谈论SQL Server 2005，请查看SQL Server Profiler并使用Index Tuning向导。
如果您想要额外的性能，某些数据库中还支持将表固定到内存。
答案 12 :(得分：0)
记录的组成可能比表中的记录数多。
在我工作的地方，我们拥有数据库，这些数据库的记录数量达数万或数十万。我们的数据库在很大程度上被认为很小。
答案 13 :(得分：0)
如果您要扩展系统，现在是时候重新设计了。当你拥有11,000条记录而不是1000万条记录时，重新设计的痛苦要小得多。但是，你所说的没有告诉我你需要重新设计。有连接没有任何固有的错误（事实上，一个设计良好的数据库应该有它们）。发布关于结构的一些细节，我们可以帮助您决定是否需要重新设计。
问题可能是您和您的同事根本没有数据库访问经验，也不知道如何有效和轻松地查询它们。或者问题可能是设计不好，没有结构细节，很难说。