Moura: But that just seems like spurious joins to slow down my queries :

Clyatt: TheRealGent: With separate table 2 means mere INSERT INTO status_table;

Clyatt: TheRealGent: With EUNM 2 means ALTER TABLE MODIFY your_enum

Truelove: TheRealGent: Is your requirement spurious?

Clyatt: TheRealGent: Do***enting separate table is also much easier and clear

Decos: Idk why it feels like overkill for a simple status x

Clyatt: TheRealGent: Not to mention that if you have separate table with all allowed statuses you only need *single* step when adding new status. INSERT .

Lougee: Salle, naw, you’d want to update the code base.

Clyatt: TheRealGent: Java app can check this table so nothing needs to be modified at the java code

Hanser: Salle, that would entail using a String field. Which your code then becomes stringly typed ****.

Vanorsdol: TheRealGent: Before you entered any data into this table, how did you know which status values were valid?

Clyatt: TheRealGent: Are you asking for sane solution or you are asking for crazy way to workaround badly written client app? :

Golab: TheRealGent: That’s not something a database can use.

Niceswander: Xgc, well we’re not using PL/SQL. Not sure what you’re getting at here.

Trefry: TheRealGent: From the database perspective, no query can use a java enum in the logic.

Clyatt: TheRealGent: You have same constraint at two different places and you consider that maintainable?

Penland: Xgc, if you’re trying to write a query against it, you can just check the table’s DDL and have your statuses.

Beckworth: Salle, I consider it necessary.

Dahline: TheRealGent: and is this easy in a query?

Clyatt: TheRealGent: enum in Java and another enum in the database so you need to keep them in sync any time someone changes something. Ditch either one of the two

Starek: TheRealGent: Don’t copy data. Normalization 101.

Clouser: Salle, are you even a dev? Seriously though.

Scarset: TheRealGent: You asked the question. Don’t attack a correct answer just because you don’t like it.

Fenley: TheRealGent: Do you have an alternative you like? If so, stop asking here.

Taula: TheRealGent: If there were an easy way to treat an enum like a table, that would be one solution. But you would still need to use an outer join, something you seem to not want to do.

Clyatt: TheRealGent: You can check the table DDL with SHOW CREATE TABLE and p**** it to find the possible ENUM values, but what makes you believe this is better than separate table with all statuses and possibly a foreign key constraint in your existing table which takes care of enforcing the list better than ENUM does?

Cabarcas: TheRealGent: It’s the only practical / acceptable solution.

Strebe: Xgc, no, one of my previous messages was me asking if I could use the information schema to do exactly that.

Voelkel: Salle, that’s far worse. The query now has to be maintained as well.

Jaus: TheRealGent: Well, information_schema tends to be slow. That’s one reason you might avoid it in normal use.

Clyatt: TheRealGent: Even if you can use some table from information_schema that would still require a join against that table

Brendel: TheRealGent: and you still need the join.

Raub: TheRealGent: It’s one of the reasons I really don’t like enums. It’s just an ugly construct if you can’t treat them directly like tables.

Clyatt: TheRealGent: I am still waiting for any single reason why ENUM’status1′, ‘status2’, . ‘status3’ could be any better with separate table including the possible do***entation issues

Pontbriand: So instead of asking why not, just create the table that should have been used to begin with.

Stoneback: I’m not against using joins cause they’re joins. Adding an LK table would mean that all application queries would contain these joins to do simple things like look ups. Unless cached