JDO 最佳实践：将对象作为集合存储在其父级下还是独立存储？
我有一个 User 和 Transaction 类
每个 Transaction 逻辑上都属于一个 User。但我可能需要查询事务的某些子集（例如：使用 Transaction.type=1 返回用户 A 的所有事务）
在 SQL 中，我只维护一个 Transaction.userID将其与 User 表链接的字段。
- 在 JDO 的对象世界中我应该做同样的事情吗？使用指向
User对象 ID 的指针字段单独存储 Transaction 对象？或者我应该只查询适当的 User 对象和 type=1 事务的子查询（例如）？ - 如果我只查询
User对象，我是否也可以只返回给定查询感兴趣的那些Transaction对象（如前面的项目符号示例所示）？
I have a User and Transaction class
Each Transaction logically belongs to a User. But I may need to query for some subset of Transactions (ex: return all Transactions for User A with Transaction.type=1)
In SQL I just maintain a Transaction.userID field that links it with the User table.
- In JDO's world of objects should I do the same? Store Transaction objects separate with a pointer-field to the
Userobject ID? Or should I just query for the appropriate User object and sub-query for transactions with type=1 (for example)? - If I query just for the
Userobject can I also return just thoseTransactionobjects that are of interest for the given query (as in the previous bullets example)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恕我直言，不存在总体上的最佳实践。但是，对于在面向对象的上下文中进行事务的用户，我会将用户建模为具有一个或一组事务，其中每个事务都具有对其用户对象的引用。
通过这种方式，您可以获取用户的所有交易，只需获取用户对象，然后从那里获取交易列表即可。
另一方面，您可以查询仅限于特定类型的特定用户的交易。由于每个事务都与用户对象相关联，因此您始终“免费”获得正确的上下文。
当然，您还应该考虑延迟加载与急切加载之类的设置，具体取决于实体被检索后发生的情况（它们是在进程中使用还是序列化并传输到远程进程等）。
IMHO, there is no such thing as a best practice in general. However, regarding a user with transactions in an object-oriented context, I'd model the user to have a list or set of transactions with each transaction having a reference to its user object.
This way you can either get all transactions of a user, simply by getting the user object and then getting the list of transactions from there.
On the other hand you can query for transactions for a specific user restricted to a specific type. As each transaction has an association to the user object, you always get the right context included "for free".
Of course, you should consider settings like lazy vs. eager loading as well depending on what happens with the entities after they have been retrieved (are they used in-process or are they serialized and transferred to a remote process etc.).