糟糕的数据库设计 - 我的桌子太大了吗？

Question

我有一个设计糟糕的数据库。 其中一个最重要的表有11,000多个条目。 我们想扩展我们的系统，我想知道这个表是否增长到它的大小的5倍，这会是一个问题吗？ 它的大小为15360 kB ......如果重要的话。

---

我正在使用phpMyAdmin，服务器是一个Fedora Linux盒子（没什么特别的），负载很轻。 它存储了我们系统使用的所有内容。

Answer 1

什么DBMS？ 什么服务器？ 什么负载？ 什么应用？

此外：11.000记录什么都没有，真的。 甚至在MS Access中。 :-)

编辑：所以我假设你使用一个相当新的MySQL与MyISAM表。 从理论上讲，您可以继续将表格填入数百万条记录中。 根据您使用它们的方式（很多连接/不连接，很多查询/更新/删除/不），您不需要做任何特殊的事情。 在桌子上放一个适当的索引，你应该没事。

Answer 2

我知道您担心在“设计不佳的数据库”中将记录数增加到55.000左右会影响性能。

如果您的系统按预期工作，我认为除非您有一些轻微的性能问题，否则您应该可以使用50.000记录。

正如大多数人所提到的，50k记录与数据库表大小相关的数量非常少，即使没有规范化的数据库，也不会出现性能问题。

如果您计划扩展系统的功能，那么也许现在也是查看数据库设计的好时机，否则保持原样应该是合理安全的。

Answer 3

我认为你没有提供足够的信息给某人给出答案。 为什么设计不合理？ 它没有正常化吗？ 你没有任何索引吗？ 这是什么数据库？ 它运行的操作系统是什么？ 现在查询相关表中的记录需要多长时间？

Answer 4

11k条目并不多。 50K也不大。

将索引放在表格上（针对您将在其上运行的查询进行了优化）将允许比您想象的更大的数量的良好性能。

如果设计足够差，你可能会考虑重新设计的成本。

Answer 5

“设计不佳的数据库”是什么意思？

如果它的设计很糟糕，重新设计它，将信息拖出当前表格，然后填充新表格。

如果你担心性能，11000个条目并不大。 按db标准，15兆字节的数据库非常小。

Answer 6

表的大小不是很重要。 密钥，索引和关系的设计与设计质量的关系远远大于其中包含的数据的大小。 这显然有一些警告; 但是在处理性能或设计问题时，优化表的大小是我做的最后一件事。

您可能想要更多地解释为什么您认为这是一个设计不佳的数据库，以及您可以（轻松）做些什么来纠正问题。 除此之外，您还应详细说明DBMS的类型以及用途（Web应用程序，自定义应用程序，报告等）。

Answer 7

15MB没什么。 11k行也是如此。 我有2 GB以上的数据库，有些表包含超过100万行，我认为它介于中小尺寸之间。

Answer 8

你真的没有提供任何证据支持你声称这是一个设计糟糕的数据库。 是什么让它设计不佳？ 该表有876列吗？ 列是Col1，Col2，Col3 ......？ 它是否使用float和datetime作为复合主键？ 它很难正常化？ 我们唯一知道的是它的记录数。

Answer 9

在数据库方面，11K记录通常没什么。

除了一个表中的记录数之外，还有什么能让您认为数据库的设计很差？

Answer 10

您需要提供有关表结构的更多信息。

一般来说，表中的15,000行会被认为很小，实际上很小，以至于某些设计人员甚至可能不会为索引编制索引。

Answer 11

如果您要扩展系统，现在是时候重新设计了。 当你拥有11,000条记录而不是1000万条记录时，重新设计的痛苦要小得多。 但是，你所说的没有告诉我你需要重新设计。 有连接没有任何固有的错误（事实上，一个设计良好的数据库应该有它们）。 发布关于结构的一些细节，我们可以帮助您决定是否需要重新设计。

可能的问题是您和您的同事根本没有数据库访问经验，也不知道如何有效和轻松地查询它们。 或者问题可能是设计不好，没有结构细节，很难说。

Answer 12

糟糕的基础将是你最昂贵的错误。 如果表格很重要，那么您需要决定修复它的重要性。 表中的行数仅影响从中提取内容的速度。 但是，如果你的数据库设计开始不好，那么你的双手将会被困在某些地方。

Answer 13

如果您正在谈论SQL Server 2005，请查看SQL Server概要分析器并使用“索引优化”向导。

如果您想要额外的性能，还可以在某些数据库中支持将表固定到内存。

Answer 14

记录的组成比表中的记录多得多。

在我工作的地方，我们拥有数据库，其中有许多表，其记录数量达数万或数十万。 我们的数据库在很大程度上被认为很小。