我知道使用字段关系可以更新或删除相关表中的数据。当我创建依赖于组织员工的用户表结构时，我使用了这种方法。当组织的员工离开时，他会自动从用户表中删除。但我对另一面感兴趣。假设有一个表 peoples，其中所有流行数据都是姓名、性别、出生年份、SNILS、护照、保险单，以及残疾群体、电话号码、电子邮件等数据。假设可能有更多字段，并且其中可能有也可能没有数据，就像相同的电话号码、电子邮件或残障群体一样。创建单独的表（例如电话）并根据人员 ID 建立连接是否有意义？将所有数据存储在一张表中的优点和缺点是什么？因为，例如，在选择电话时，在任何情况下都需要将它们组合成分隔字符串（例如;）或数组。然后你还可以使用“;”记下一个人的电话号码。并且不必费心连接并创建额外的表。
我完全理解当客户端->订单和其他之间存在连接时，当在属于一个客户端的大量数据行上建立连接时，但是如果一个字段只能有一小部分值该怎么办，这可以完美地适应同一个 varchar 字段吗？
我同意我的同事的观点，我们需要了解数据标准化，以便了解它是什么以及它的用途。这个问题很长，描述了一个相当抽象的情况。
DBA 有自己的创建数据源的方法；它倾向于压缩并提高访问性能，但这只是问题的一方面。我想说，对数据源进行建模始终是性能、灵活性和可预测性之间的权衡。我认为，如果前两个概念不应该引起任何特殊问题，那么最后一个概念也许值得解释。描述表结构的数据模式实际上告诉我们数据处理所需的所有信息；这些数据可以被认为是可预测的；它们的处理不需要任何旨在识别结构的额外逻辑。基本模式严格对应于我们应用程序抽象的类分解（一般意义上）。如果实体不多并且预先知道它们的描述，那么这将是理想的解决方案。然而，当事先不知道实体的所有属性，没有明确定义组合它们的规则，并且可以在没有预定义的分类规则的情况下添加实体本身时，有很多选择。在这种情况下，使用了各种技术来放弃清晰的结构（将结构从模式转移到数据）。反模式的应用
EAV，使用JSON字段可以存储任意数据，但需要额外的成本来分析结构。在此版本中，JSON是面向未来的，并且在PostgreSQL中得到原生支持。您可以将电话号码列表保存为JSON字段，使用标准方法比使用您的版本更容易;。还有JSON可以被视为包含结构和数据的部分自记录数据。如果我们相信结构（数据模式）可以像数据本身一样表示，而不是我们通常意义上的模式，那么我们就会选择构建超级模式。例如，PostgreSQL 本身的一组固定系统表允许您描述任何数据库的任意数据模式。就我个人而言，我更喜欢这个选项。我使用此解决方案来描述工程系统中的复杂数据以获取监管参考信息，非常成功，因为这种方法使我能够区分结构数据和数据本身，从而通过将苍蝇与肉排分离来优化性能并提高可预测性，可以这么说，同时还有一个静态方案。概念构建者事实上，在寻求妥协的过程中，我们试图找到一种选择，其缺点不会妨碍我们在既定的时间范围内实现预期的结果，因为成本很少会吓跑任何人。