考虑在数据库中有一个名为的表users和一个名为 的表wallets。除其他外，用户拥有 0 个、1 个或多个钱包。这种关系是一对多的，这意味着钱包有一个指向用户的外键。
现在问题如下：在为一个人构建结构或类时，我看到了两种可能性：
1）用户没有钱包的迹象。有一个函数将用户作为参数并获取钱包数组。
2）用户拥有一个包含钱包的数组作为成员，并且在创建对象/结构时获取钱包。
我认为第一种方法可能更好，因为它更加模块化——在第二种方法中，即使用户没有钱包，用户也依赖于钱包。不过，我不确定哪种方法更好，所以我正在寻找两种方法的比较。
在应用程序级别，您可能有这样的用户类型（Go 表示法）：
type User interface {
Wallets() []Wallet
}
在下方，有一个数据库，在您的情况下是 SQL。想一想，通过查看您的应用程序，这不应该是显而易见的。
对依赖关系的假设超出了它们以接口契约的形式所保证的范围，从而不可逆地耦合了组件。
这意味着如果您通过数据库的模式对应用程序进行建模，那么您做错了，因为您的整个应用程序现在与所述数据库紧密耦合，并且对其任何部分的任何更改都会产生巨大的、不可预测的影响。
一个常见的解决方案是使用所谓的ORM 层，它位于数据库驱动程序和实体模型之间。它将处理以下内容：
除其他事项外。
PS：这个答案适用于静态和动态类型的语言。