原谅这个基本问题，但我对数据库设计领域的新见感让我经常陷入困境。
我的网站在信息家庭方面不断发展。一开始我有一种我描述的项目，一切都很顺利。那个项目占据了一个记录，并且有34列（现在很多我回头看）归因于描述性数据。随着我越来越多地了解这些内容，我发现许多开发人员将数据（如果可行的话）分解为不同的表格。
我现在已经有了与原始项目相关的其他表格，但在描述原始项目时并不总是需要这些表格，所以我将它们分解出去，以免被不必要地查询。
无论如何，我有一个新项目，我一直在尝试组织一个用户。用户表具有典型的列，如用户名，电子邮件，last_login，相关图像的路径等。这些用户一直在制作评论，我在另一个表中包含了包含与用户及其所在项目相关的ID的列正在评论。
现在......我正在将强制性用户个人资料页面添加到网站。我是否应该创建另一个仅包含基本配置文件数据的表，或者在原始用户表中附加包含配置文件数据的现有用户记录？我想如果我要添加一个“从站点中删除我”功能，家务可能会很痛苦，因为我必须运行杀死用户记录，用户配置文件记录以及与其他用户ID关联的任何其他数据的东西。表。
基本上我要问的是，我应该继续使用这种“细化”的设计方法 - 将所有内容分解为必要部分，还是将它整合到更大的表中？我看到一些情况，如果用户删除了他们的帐户，我将留下一堆不相关的数据。例如，原始项目是餐馆...如果我创建一个表来记录餐馆的“访问”，包含餐馆ID和用户ID，如果用户或餐馆从网站上删除，这个“访问”表将有一堆无用的记录说“用户45访问了不存在的餐馆”或“餐馆21被不存在的用户访问过”
我希望我在这里有意义......我只是想知道随着时间的推移最终得到这个“垃圾”数据是否正常。
非常感谢， 罗布
答案 0 :(得分：2)
删除“相关”数据是应用程序生命中正常，健康的一部分。这就是发生的事情。你必须这样做，就像你刷牙或铺床一样。不要让两个或三个DELETE查询影响表的结构。它们并不那么贵，老实说，如果你觉得这太痛苦了，那你就错了：）
如果你正在使用InnoDB表，你可以查看foreign key constraints，它会为你完成一些清理工作。
答案 1 :(得分：2)
如果你learn about normalization，你将能够更轻松地做出这些决定。
答案 2 :(得分：1)
通常，如果数据都与同一个逻辑实体相关 - 相同的“事物” - 那么它应该放在同一个表中。为了保持表格更小，将一个表分成两个通常不是一个好主意。根据您正在做的事情，它可能会或可能不会使查询更快，并且会带来不必要的复杂性。让我解释一下。
是否使查询更快取决于数据的性质以及如何使用它。如果你有一些非常大的字段，比如“rambling_comments varchar（5000）”或者其他一些，很少使用它，那么将它分成一个单独的表，以便“主”表中剩下的内容相对较小，这确实可以使你的查询速度更快，因为现在有更少的数据需要读取。但是如果您想要突破的字段大小适中，并且您经常需要来自两个表的数据，那么仅使用一个表的查询不会获得那么多，而现在使用这两个表的查询需要进行连接，这通常比阅读更大的记录更贵。
但是分解你的表肯定会使你的程序变得更复杂。现在，您必须跟踪哪个表中的数据。您将不断检查该字段是否在Item_Descriptive_Data表或Item_Stock_Data表中或其他任何内容。你可能会在某些时候失去踪迹，并且不小心将同一场放入两张桌子。 （或者更糟糕的是，你会认为这是一个好主意并且故意这样做。）然后你就会有冗余且可能相互矛盾的数据。
每次需要跨越表的数据时，都必须进行连接。您可能会创建一个或多个表中的记录可能不存在的可能性。就像，如果你将User表分成User_Main和User_Profile，并且你需要来自两个表的数据以便你进行连接，如果User_Profile中有一条记录而User_Main中没有相应的记录会怎样？您将不得不添加代码来检查可能性并处理它。噢，快乐地说“那永远不会发生，不用担心它”是一种非常危险的态度：不管它是不是支持发生，迟早会发生，如果你不优雅地处理错误，你可能真的很乱。
简而言之，出于性能原因而拆分表通常是不成熟的优化。如果您发现自己有一些真正的性能问题，那么请查看表格，看看是否应该对效率进行非规范化。但是，不要只是为了避免可能在某天发生的问题而开始破坏数据库。