英文:
Separating vs merging objects made from database tables in static languages
问题
考虑到数据库中有一个名为users的表和一个名为wallets的表。用户可以拥有0个、1个或多个钱包，这是一对多的关系，也就是说钱包有一个指向用户的外键。
现在的问题是：在构建一个表示用户的结构体或类时，我看到有两种可能性：
-
用户没有钱包的迹象。有一个函数，它以用户作为参数，并将获取一个钱包数组。
-
用户有一个成员，该成员是一个包含钱包的数组，并且在创建对象/结构体时获取钱包。
我认为第一种方法可能更好，因为它更模块化 - 在第二种方法中，用户即使没有钱包也依赖于钱包。
不过，我不确定哪种方法更好，所以我正在寻找对这两种方法的比较。
英文:
Consider that in the database you have a table called users and a table called wallets. Among other things a user has 0, 1 or more wallets. The relation is one to many, meaning that the wallet has a foreign key pointing at the user.
Now the question is the following: When building a struct or a class for a person I see two possibilities:
-
The user has no sign of wallet. There is a function which takes a user as arguments and will fetch an array of the wallets.
-
The user has as a member which is an array containing the wallets and the wallets are fetched when the object / struct is created.
I think that the first approach may be better, since it's more modular - in the second one the users depend on the wallets, even if the user has no wallets.
Still, I am not sure which approach is better so I am looking for a comparison of both approaches.
答案1
得分: 1
在应用程序层面上，你可能会有一个像这样的用户类型（Go语言表示）：
type User interface {
Wallets() []Wallet
}
在更底层，有一个数据库，你的情况下是SQL。但是通过查看你的应用程序，这一点不应该是显而易见的。
对于超出接口合约所保证的依赖关系，做出假设会使组件之间产生不可逆的耦合。
这意味着，如果你根据数据库的模式来建模应用程序，那么你就错了，因为你的整个应用程序现在与该数据库紧密耦合，对其任何部分的任何更改都会产生巨大而不可预测的影响。
一个常见的解决方案是使用所谓的ORM层，它位于数据库驱动程序和实体模型之间。它会处理以下事项：
- 钱包应该如何以及何时被获取？
- 钱包的信息在数据库中的哪个位置存储？
- 当你删除一个用户时，是否应该同时删除钱包？
等等。
PS：这个答案适用于静态类型和动态类型的语言。
英文:
On the application level you might have a user type like this (Go notation):
type User interface {
Wallets() []Wallet
}
Far beneath, there's a database which in your case is SQL. That should not be obvious by looking at your application, thought.
Making assumptions about dependencies beyond what they guarantee in the form of interface contracts couples the components irreversibly.
That means that if you model your application by your database's schema you're doing it wrong because your entire application is now tightly coupled to said database and any change to any part of it will have a big, unpredictable impact.
A common solution is to use a so called ORM layer, which sits between your database driver and entity models. It will take care of stuff like:
- how and when should the wallets be fetched?
- where in the database is a wallet's information stored?
- when you remove a user, should the wallet also be deleted?
among other things.
PS: This answer applies to both, statically and dynamically typed languages.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论