JPA查找表设计
我遇到了设计困境,希望你们能帮助我解决这个问题。
问题: 我的应用程序有大约 15 个查找表,每个表都有代码和值属性。我想知道创建这些查找表的最佳设计方法是什么。
我脑子里有几个解决方案
- 有一个抽象超类(例如BaseLookupTable)和代码 和 value 属性,然后创建 15 个扩展此类的专用查找类。或者
- 为 15 个查找表中的每一个创建枚举类型。
如果你们能帮助我选择一个解决方案(即使是我没有提到的解决方案)以及这样做的原因,我将不胜感激。
干杯, 苏曼斯
I have a design dilemma at my hands and am hoping you guys could help me out with this.
Problem:
I have about 15 lookup tables for my application each with code and value attributes. I was wondering what would be the best design approach for creating these lookup tables.
I had couple of solutions in my mind
- Having one abstract superclass (say BaseLookupTable) with the code
and value properties and then go about creating the 15 specialized lookup classes extending this class. or - Create enum type for each of the 15 lookup tables.
If you guys could help me pick a solution (even ones not mentioned by me) along with reasons for doing it would be much appreciated.
Cheers,
Sumanth
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我会选择选项 1,因为枚举在您的代码中是固定的。如果您想向查找表添加选项,只需将其插入数据库即可。使用枚举,您需要重新编译您的应用程序。
I would go for option 1, since enums are fixed in your code. If you want to add an option to your lookup-table you only have to insert it in your database. With enums you need to recompile your application.
我认为通用的 JPA 基类没有那么多用处。
假设您没有对公共键/值接口进行建模,那么为什么不将具体语义编码到查找表列名称中,例如 role_name、status_code 等?
不确定您是否也使用 DB ENUM,例如 MySQL ENUM。我假设这是下一段(这是 MySQL 特定的)。其他 DBMS(例如 PostgreSQL)具有非冗余 ENUM,因此以下内容可能并不真正适用于您的情况:
MySQL ENUM 无论如何都不能应用于所有情况。如果查找值是单值并且基本上仅从一个表/实体引用,则应使用 MySQL ENUM。我的策略是,如果从多个其他表引用值或者查找表需要多个属性,则添加一个单独的查找表。请注意,在数据库中使用相同的 ENUM 定义会增加冗余。使用 MySQL ENUM 可以为您节省一个表、一个联接和一些关系。请记住,DB ENUM 的值应尽可能保持静态。如果需要更改,请再次使用查找表。
老实说,这不是一个简单的话题,我必须分享我对这个话题的看法,尽管这包括 MySQL 的细节。
I don't think a common JPA base class has that much use.
Assuming you don't model a common key/value interface, then why not encode the concrete semantics into the lookup table column names, e.g. role_name, status_code, etc.?
Not sure if you're using DB ENUMs also, e.g. MySQL ENUMs. I assume this for the next paragraph (it's MySQL specific). Other DBMSs like PostgreSQL have non-redundant ENUMs, so the following might not really apply to your situation:
MySQL ENUMs cannot be applied in every situation anyway. You should use MySQL ENUMs if the lookup values are single-valued and are basically referenced from one table/entity only. My policy is to add a separate lookup table if the values get referenced from more than one other table or the lookup table needs more than one attribute. Note, that using the same ENUM definition in the DB adds redundancy. Using MySQL ENUMs saves you a table, a join, and some relationships. Keep in mind the DB ENUM's values should be as static as possible. If they need to change, use a lookup table again.
It's not an easy topic honestly and I had to share my view on the topic, even though this includes MySQL specifics.