开发者

enum vs typeId in hibernate

开发者 https://www.devze.com 2023-03-19 04:13 出处:网络
I\'m implementing a datab开发者_如何学Pythonase table like the following: Do_Something ------------

I'm implementing a datab开发者_如何学Pythonase table like the following:

Do_Something
------------
Id
Name
Frequency

Frequency can only be 1 of 3 values at the moment; immediate, daily or weekly. So I can implement the Frequency field as a String, in which case the hibernate mapping would be a simple easy enum. However, as easy as the code implementation is, it seems ugly and inefficient on the database side with hundreds of thousands of Strings. So maybe I had a frequency table:

Frequency
---------
Id
Value

And now I have the Do_Something.Frequency field as a foreign key to this table. Now I have to hardcode the preset frequencyIds in my code to make querying the Do_Something table easier to deal with. I'm not sure how much use the Frequency table will have aside from within the Do_Something table. Maybe in the future other tables will make use of it...

So the question is, do I make frequency a simple enum in code and in the db as a String, or make frequency an enum in code that gets translated to and from a frequency_id in the db or make frequency constants in code that match the various possible frequency ids in the db?


So it boils down to whether you want to keep Frequency normalized or not. There is a lot written about it but my take is that unless you expect regular changes in values of Frequency, there is not much need for complexity of extra table.

I would consider enum with some additional display name and well established string names. That would give you a chance to rename presentation name if needed without changing database. For example:

IMMEDIATE("Immediate"),
DAILY("Daily"),
WEEKLY("Weekly")

Drawback is that if you ever decide to change those enum values you will have to migrate database. But from practical standpoint, why would you ever want to rename them?

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号