遗留数据库 - 我应该使用 NHibernate 吗？
我陷入了涉及复合键的遗留数据库的困境，并且没有空间修改数据库。
问题似乎是密钥的一部分也用于每个外键。 因此，如果我有这样的表 A 和 B：
A
- 公司 (PK)
- aId (PK)
- someMoreInfo
B
- 公司 (PK, FK)
- bId (PK)
- aId (FK)
- someOtherInfo
表 B 中的公司字段是表 B 的 PK 并使用我尝试的所有操作都导致我遇到映射中的重复列异常。
所以这不是一个“我该怎么办”的问题（好吧，如果你有一个解决方案 - 如果这只是我的想象并且没有真正的问题，那么我会认为自己很幸运......）而是一个“你觉得这是吗”对的问题。
- 是否可以使用 nhibernate 访问这样的数据库（好吧，除了在没有引用的情况下映射所有表 1:1 之外）
- 您认为这是一个好主意吗？
- 鉴于我的情况，有哪些替代方案（即是否有任何 O/R-Mapper 擅长于此）？
顺便说一句：这是同样的问题，并且一个我的复杂场景在这里。
I am stuck with a legacy database involving composite keys and there is no room to modify the db.
The problem seems to be that one part of the key is also used for each foreign key.
So if I have tables A and B like this:
A
- company (PK)
- aId (PK)
- someMoreInfo
B
- company (PK, FK)
- bId (PK)
- aId (FK)
- someOtherInfo
The company field in table B is PK for table B and used for ther FK to table A. All the things I tried lead me to Repeated column in mapping exceptions.
So this is not a 'how do I' question (well, if you have a solution - go ahead I'd consider myself lucky if this is just my imagination and there is no real problem…) but a 'do you feel this is right' question.
- could it be possible to acces a db like this using nhibernate (well, apart from mapping all tables 1:1 without references)
- do you feel it is a good idea?
- what are the alternatives given my circumstances (i.e. Are any O/R-Mappers good at this)?
BTW: This is the same problem, and one of my complex scenarios is here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不知道如何解决您遇到的特定外键重叠主键问题，但我会说，对于我尝试过的 ORM，NH 最有可能与您的遗留模式兼容；事实上，这是 NH 最大的设计目标之一。所以我认为 NH 是正确的，而且与大多数其他 ORM 相比，您更有可能在其中找到答案。
I don't know how to solve the particular foreign-key-overlaps-primary-key issue you have, but I will say of the ORMs I've tried, NH is the most likely to be compatible with your legacy schema; in fact, it's one of NH's biggest design goals. So I'd say NH is right, and you're more likely to find an answer in it than you are with most other ORMs.