MySQL数据库设计帮助

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

如果使用innodb表,可以查看 foreign key constraints 这会帮你清理一下。

如果你 learn about normalization .

一般来说,如果所有数据都与同一个逻辑实体(同一个“事物”)相关,那么它应该位于同一个表中。把一张桌子分成两张,只是为了让桌子变小,这通常不是一个好主意。根据您所做的工作,它可能会加快查询速度,也可能不会加快查询速度,并且会带来不必要的复杂性。让我解释一下。

它是否使查询更快取决于数据的性质和使用方式。如果您有一些非常大的字段,如“rambling ou comments varchar(5000)”或类似的字段,并且很少使用它,那么将其拆分为单独的表,以便“main”表中的剩余内容相对较小,这确实可以使您的查询更快,这是非常明显的原因,因为现在需要读取的数据更少。但是,如果您要分解的字段的大小适中,并且您经常需要来自两个表的数据,那么只使用一个表的查询就不会获得那么多,而同时使用这两个表的查询现在需要进行连接,这通常比读取更大的记录要昂贵。

但是分解表无疑会使程序更加复杂。现在您必须跟踪哪些数据在哪个表中。您将不断检查该字段是否在项目描述数据表或项目库存数据表中或其他内容中。你可能会在某一点上迷失方向,不小心把同一个字段放进了两张表中。(或者更糟的是,你会认为这是一个好主意,并故意这么做。)然后你就有了多余的、可能相互矛盾的数据。

每次需要跨表的数据时都必须进行联接。您可以创建一个或多个表中的记录可能不存在的可能性。例如,如果您将用户表拆分为用户主配置文件和用户配置文件,并且您需要来自这两个表的数据来进行联接,那么如果用户配置文件中有一条记录,而用户主配置文件中没有相应的记录,会发生什么情况?您将不得不添加代码来检查可能性并处理它。哦,轻松地说“那永远不会发生,不必担心”是一种非常危险的态度:不管它不应该发生,它迟早会发生,如果你不优雅地处理错误,你可能会有一个真正的混乱。

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