Gassen: But the problem is that I would have to add the look up table for both the app database along with reporting.
Clyatt: TheRealGent: If it is offline reporting system why the hell you are bringing up that argument about the extra execution time required for the join?
Kosco: And by reporting, I dont mean data warehouse.
Clyatt: TheRealGent: You can create that extra table only on the server used for reporting can’t you?
Clyatt: TheRealGent: You can create it as temporary table can’t you?
Manzi: Salle, but then how to maintain it? How would you do that?
Clyatt: TheRealGent: Maintain what exactly?
Clyatt: TheRealGent: You have java enum don’t you?
Redo: Salle, sooo you propose that every time a value is added to the enum, it now has to be added to the column enum I know, you’d like to scrap that, and then let the DBA know to add that as a new value in the lookup table as well, which btw, has to only be on certain select slaves?
Clyatt: TheRealGent: Do you have this java enum in your reporting app which works offline and does not disturb the productiopn system?
Clyatt: TheRealGent: No I propose that you don’t use any ENUM at all and then the life of both Java developers and DBA will be much easier :
Clyatt: TheRealGent: Not ENUM at the server side that is
Clyatt: Database server if you wonder what server I am talking about
Clyatt: TheRealGent: So your reporting app does not have the enum so it does not know the list of possible values. Is that what you are saying?
Clyatt: TheRealGent: So everytime it has to prepare that report it must: 1 SELECT . from information_schema; 2 p**** the returned string to extract the possible values; *before* sending the SELECT . GROUP BY . which will produce the final result?
Cowdrey: If the java developers were smart enough, they would have pre-loaded the status data from the database table, either in the form of a java enum, which is more flexible than most think, or some other structure. Having multiple independent copies is a very bad idea.
Dalrymple: TheRealGent: and if they didn’t know how to use a java enum like this, they could have used any other structure.
Lepetich: TheRealGent: It’s basically not static data. Don’t ever treat it like that.
Dewitz: Well, if I understand what you’re saying correctly – you don’t understand how Java Enums work. Or most statically typed language enumerations. And what you’re saying now essentially just killed off their entire appeal and usefulness when writing application code.
Aboulahoud: So sure, throw it in a map. Or some other non static data structure. But now you’re in a situation similar to string properties: which is a ****ty situation to be in.
Dadds: TheRealGent: Correct. Just make sure there’s only one source of the data, not two or more.
Aloisi: TheRealGent: You currently have the worst case, two sources of the data.
Gloor: That’s the one thing you absolutely must avoid.
Mcpeake: The java application can not be the source, in any way, for this data, unless you’re willing to have the java application automatically update the database at any restart to sync the data. That brings up all sorts of problems. The best approach is to make the database the source of the data and let the java app pre-load on startup.
Arguilez: Xgc, that is not possible with enumerations.
Pribyl: And NOT with an enu, since you have that SQL requirement.
Lowden: Sure. Let’s ***ume it will be an lk table. But I’m still going to require an enum in the codebase.
Pingleton: TheRealGent: Correct. enum is the wrong java construct to use with non-static data, even though there is a way to approach that with an enum as a partial source of the data.
Koep: So now that’s two places to maintain. But this is the best situation, and I will always choose it for this reason: best place to protect your data is at the DDL. Bottom line. Period. But in addition to that, there’s just no way I will use strings in the codebase if there’s a predefined set of values in the DB That it can accept.
Hummer: The enumerations provide lots of benefit for handling various cases in the code.