数据模型，多对多与多对一关系
我有两种类型的帐户（客户和提供商），我选择单表策略进行持久化。客户创建订单（one2many），提供商以拍卖方式对订单进行投标（多对多关系，因为他可以对许多订单以及其他提供商进行投标）。我的问题是，是否有可能同时拥有这些关系？因为从逻辑上讲它是可行的。但 MDA 代码生成器不喜欢它。如果是这样，我可能会遇到这个数据模型的缺点。
提前致谢。
I have two types of accounts (customer and provider), I chose the single-table strategy for persistence. Customer creates Orders (one2many) and provider bids on the orders in auction style (many2many relationship, because he can bid on many orders as well as other providers). My question is, is it possible to have these relationships simultaneously ? Because logically it can work. But MDA code generators don't like it. If so, what drawbacks I could come across with this datamodel.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
缺点是您无法在数据库中强制帐户表中的 accountID 和出价表中的 accountID 之间的引用完整性（我假设它代表对订单出价的提供商的 accountID）因为并非所有 accountID 值都是允许的。
但是，不要放弃帐户的单表解决方案，这很可能是解决您问题的正确方案（我不能肯定地说不完全理解提供商和客户之间的关系）。要两者使用单表解决方案并允许引用完整性，您需要执行以下操作：
从帐户中删除 isProvider 和 isCustomer。
添加两个新表“提供商”和“客户”。每个表都有一个 accountID 列，它既是该表中的主键，又是返回原始帐户表的外键。
将提供商或客户特有的帐户中的任何其他列迁移到相应的表中。
现在，订单表中的 accountID 应该是客户的外键，而不是帐户的外键。同样，Bids 中的 accountID 列成为 Providers 而不是 Accounts 的外键。
提供了帐户的关系完整性和单表存储。
The disadvantage is that you can't enforce referential integrity in the database between the accountID in the accounts table and the accountID in the bids table (which I assume represents the accountID of the provider bidding on the order) because not all accountID values are allowable.
But, don't give up on the single-table solution for accounts, which may well be the correct one for your problem (I can't say for sure not completely understand the relation between providers and customers). Here's what you need to do to both use the single table solution and allow referential integrity:
Remove isProvider and isCustomer from Accounts.
Add two new tables Providers and Customers. Each table will have an accountID column which is both the primary key in that table and a foreign key back to the original account table.
Migrate any additional columns from Accounts that are unique to either Providers or Customers into the appropriate table.
Now, the accountID in the Orders table should be a foreign key into Customers, not Accounts. Similarly, the accountID column in Bids becomes a foreign key into Providers rather than Accounts.
Relational integrity and single-table storage for accounts is provided for.
“我选择单表策略是为了持久化”——在我看来，这实际上并不是将它们结合起来的好理由。客户和提供商是根本不同的动物。
您遇到麻烦的事实清楚地表明您很可能以错误的方式做事 - IT 行业中的大多数事情都是如此（可能还有生活本身，但您不需要我在这方面劝说）。
我会将它们分成不同的表来解决这个特定的问题。
如果您确实希望共享部分数据，您可以将常见的内容放在另一个表中，并从客户和提供商表中引用它。
如果单个实体既可以是客户又可以是提供商，您可能需要这样做 - 在这种情况下，您可能希望两个不同的表条目共享相同的信息（例如余额、声誉等）。
"I chose the single-table strategy for persistence" - that's actually not that good a reason for combining them, in my opinion. Customers and providers are fundamentally different beasts.
The fact that you're having troubles is a clear indication that you're most likely doing it the wrong way - that's true of most things in the IT industry (and probably life itself but you don't need me proselytising on that).
I would separate them out into different tables to resolve this particular problem.
If you really want part of the data to be shared, you could put the common things in yet another table and reference it from the customers and providers tables.
You may want this if a single entity can be both a customer and provider - in that case, you would want the two different table entries to share the same information (such as balance, reputation and so on).