老师您好，数据库设计的时候似乎还有一种流行的说法是不使用任何外键，外键约束要在业务层做逻辑判断，这种说法合理码？

使用关联查询（SQL Join）是一种常见的数据库查询操作，用于将两个或多个表中的相关数据联接在一起。关联查询可以帮助我们在数据库中进行复杂的数据分析和查询，尤其是当数据被分散存储在多个表中时。 然而，有些情况下，避免或减少关联查询可以提供一些性能上的优势。以下是一些可能导致架构师提出不使用关联查询的观点的情况： 数据库性能优化：在某些情况下，使用关联查询可能会导致较高的查询成本，特别是当表的大小很大或关联条件复杂时。在这种情况下，通过避免关联查询，可以减少查询的执行时间和资源消耗，提高数据库的性能。 数据库设计简化：有时，将数据分散存储在多个表中可能导致复杂的数据库结构。对于某些特定的业务需求和查询场景，如果能够通过重新设计数据模型或者使用冗余数据来避免关联查询，可能可以简化数据库的设计和维护。 水平扩展和分布式数据库：在一些大规模应用中，为了实现水平扩展和分布式处理，数据可能会被分布在多个物理节点或分片中。在这种情况下，跨节点的关联查询可能会导致较高的网络开销和性能下降。通过避免关联查询，可以减少跨节点的数据传输，提高分布式数据库的性能。 需要注意的是，不使用关联查询并不适用于所有情况。关联查询是一种非常强大和灵活的查询操作，可以处理复杂的数据关系。在大多数情况下，使用适当的索引和优化查询语句，数据库引擎可以有效地执行关联查询，并提供高性能的结果。 因此，是否使用关联查询需要根据具体的业务需求、数据模型和性能要求来评估。架构师在特定的上下文中提出不使用关联查询的建议，可能是基于特定的优化目标和约束条件。在实际应用中，需要综合考虑各种因素，并进行性能测试和评估，以确定最佳的数据库设计和查询策略。

领域建模这些也没有，上来一天直接交付系统？

不用join怎么做连表的属性排序？

不join，怎么设计呢？

任何两张表都不join? 没看懂，比如我这里有个实验平台，要查询每个同学所在的实验组的名称，这个只能做user表里写一个group_id,不做join,难道再每个同学在Group表里再单独查询吗？

一个候选人简历，多次面试，很自然就会想到简历一张表，评估一张表，通过候选人ID相关联，并表处理并不会节约很多开发时间，不是很理解这个设计呢

如果不用join的，又要保证数据一致性选择。那就要在代码做大量的join操作，这个开发效率太低了吧。逻辑删除会破坏主键的唯一性，还会有数据爆炸的风险，这个怎么回避呢

对于后续增加的字段，以及数据表结构，如何拆分呢？

沙发