为各种类型的联系人设计表格
今天，我的系统中有三个联系人来源：
- 系统用户
- 地址簿
- CRM 系统
它们存储在不同的表中。我正在从内部 ORM 解决方案切换到 nhibernate，并且 nhibernate 获得了很好的继承支持。因此，我正在考虑以下操作：
- 创建一个包含所有常用字段的基表
- 使用特定字段+指向基表行（base_user_id 或类似字段）的链接为每个联系人类型（系统、地址簿、crm）创建一个表。 地址簿、CRM）。
这种解决方案的好处是同步每个源要容易得多。将地址簿中的用户导入到 CRM 系统中，只需创建一个 CRM 表并将其链接到基表中的用户即可。修改地址簿中的用户会自动在 CRM 中进行修改。
它还可以轻松添加其他来源并保持所有内容同步。
我的问题是：你能看出这样的解决方案有什么问题吗？
Today I got three sources of contacts in my system:
- Users of the system
- An addressbook
- A CRM system
Those are stored in different tables. I'm switching to nhibernate from an inhouse ORM solution and nhibernate got great inheritance support. I'm therefore considering to following:
- Create a base table with all common fields
- Create one table per contact type (system, addressbook, crm) with specific fields + a link to the base table row (base_user_id or similar).
addressbook, crm).
The great thing with such solution is that it's a lot easier to sync each source. Importing a user from the addressbook to the CRM system is simply to create a CRM table and link it to the user in the base table. Modifying the user in the addressbook automatically modifies it in the CRM.
It will make it easy to add other sources too and keep everything in sync.
My question is: Can you see any problems with such solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
加入打野会出现问题，导致性能问题。数据库不需要此配置，并且当强制此配置时，数据库会变慢。
数据库老手经常批评 ORM 的原因是它（至少从我们的角度来看）是倒退的，将类层次结构持久化到数据库的效率远低于设计表然后修复的效率。类代码位于它们之上。
为什么不直接创建反映高效设计的类呢？
Join jungles will be a problem, leading to performance issues. The database does not need this configuration, and will be slower when this configuration is forced upon it.
The reason database veterans will often criticize ORM is that it is (at least from our point of view) backwards, the persistence of a class hierarchy to a database is far less efficient than designing the tables and then fixing class code on top of them.
Why not just create classes that reflect a design that is efficient as-is?
每个层次结构使用一个表更简单，但它放弃了 2 个功能：
。我更喜欢每个层次结构一个表而不是每个子类一个表，因为我喜欢将它们全部放在一个表中的简单性。
Using one table per hierarchy is simpler, but it gives up 2 capabilities:
I've tried both. I prefer table-per-hierarchy over table-per-subclass because I like the simplicity of having them all in one table.