MySQL数据库设计帮助

请原谅这个基本的问题，但我对数据库设计领域的新认识常常让我陷入困境

我有一个网站，不断增长的家庭信息。在开始的时候，我有一个项目，我正在描述，一切都很好。该项占用了一条记录，有34列（现在我回头看了很多）属于它的描述性数据。随着我越来越深入这方面，我看到许多开发人员将数据（在实际情况下）分解成不同的表

我现在有了与原始项相关的其他表，但在描述原始项时并不总是需要这些表，所以我将它们分解，这样就不会不必要地查询它们

无论如何，我有一个新的项目，我一直试图组织这是一个用户。用户表有典型的列，如用户名、电子邮件、上次登录、关联图像的路径等。这些用户一直在发表评论，我将其保存在另一个表中，该表包含与用户及其评论项目相关的ID列

现在。。。我正在将强制用户配置文件页面添加到站点。我应该创建另一个只包含基本配置文件数据的表，还是在原始用户表中使用配置文件数据附加现有用户记录？我在想，如果我要添加“从站点删除我”功能，内务管理可能是一件痛苦的事情，因为我必须运行一些东西，以杀死其他表中的用户记录、用户配置文件记录以及与该用户ID相关的任何其他数据

基本上，我要问的是，我应该继续使用这种“粒度”设计方法——将所有内容分解为基本部分，还是将它们整合到更大的表中？我看到一些例子，如果用户删除了他们的帐户，我会留下一堆不相关的数据。例如，原来的项目是餐厅。。。如果我制作一个表来记录对餐馆的“访问”，其中包含餐馆ID和用户ID，如果用户或餐馆被从网站上删除，这个“访问”表将有一堆无用的记录，说“用户45访问了不存在的餐馆”或“用户21访问了不存在的餐馆”

我希望我在这里有意义。。。我只是想知道，随着时间的推移，这些“垃圾”数据的出现是否正常

多谢各位， Rob

删除“相关”数据是应用程序生命中正常、健康的一部分。事情就是这样。你只需要这样做，就像你刷牙或整理床铺一样。不要让两三个删除查询影响表的结构。它们没有那么贵，老实说，如果你觉得这太痛苦，那你就错了：）

---

如果您使用的是InnoDB表，您可以研究它，它将为您处理一些清理工作

如果您愿意，您将能够更轻松地做出这些决策。

一般来说，如果所有数据都与同一逻辑实体（同一“事物”）相关，那么它应该放在同一个表中。把一张桌子分成两张，只是为了让桌子更小，这通常不是一个好主意。这取决于您正在做什么，它可能使查询更快，也可能不会使查询更快，并且会引入不必要的复杂性。让我解释一下

它是否能加快查询速度取决于数据的性质和使用方式。如果您有一些非常大的字段，如“rambling_comments varchar（5000）”或类似的字段，并且很少使用，那么将其拆分为一个单独的表，以便“main”表中剩余的字段相对较小，确实可以使您的查询更快，原因相当明显，即现在要读取的数据更少。但是，如果您想拆分的字段的大小适中，并且您经常需要来自两个表的数据，那么只使用一个表的查询不会获得太多的收益，而同时使用两个表的查询现在需要进行联接，这通常比读取更大的记录更昂贵

但是分解表肯定会使程序更加复杂。现在您必须跟踪哪些数据在哪个表中。您将不断检查该字段是否位于Item_Descriptive_数据表或Item_Stock_数据表或其他任何内容中。你可能会在某个时候迷失方向，并意外地将同一个字段放入两个表中。（或者更糟的是，你会认为这是一个好主意，并故意这么做。）然后你就有了冗余的、可能相互矛盾的数据

每次需要跨表的数据时，都必须进行连接。您可能会造成一个或多个表中的记录可能不存在。比如，如果您将用户表分为User_Main和User_Profile，并且您需要两个表中的数据以便进行连接，那么如果User_Profile中有一条记录，而User_Main中没有相应的记录，会发生什么情况？您必须添加代码来检查这种可能性并处理它。哦，愉快地说“那永远不会发生，不用担心”是一种非常危险的态度：不管它不应该发生，迟早会发生，如果你不优雅地处理错误，你可能会有一个真正的混乱

---

简言之，出于性能原因分解表通常是一种过早的优化。如果你发现你有一些真正的性能问题，那么看看表，看看你是否应该去规范化效率。但不要为了避免某一天可能发生的问题而开始破坏数据库

谢谢Soctt。。。。我会给你们一个积分，因为我想整个问题都是非常主观的，并且与上下文相关。我会调查f k c.抓到杰伊了。谢谢我想更容易将表变大并在以后断开。在更高级的情况下，可以使用非规范化或稀疏表。通常是出于性能原因。