reversing java to c enum style mapping

[Arne Vajhøj]

It is not my desire to claim that it is universal. It is my desire to
talk about how to design databases a) specifically for Java, and b) in a
way that reduces fragility. Even if the access language were C, I would
still suggest that one avoid using INTEGER as the database type for an
enum.

You could but it would be a burden for the programmers.

Arne

 

[Lew]

Java picked an approach to enums that were significantly different
from C/C++/C#.

They did not want Java enums to be camouflaged ints.

Perhaps they reasoned that using ints would be too fragile.

 

[Lew]

You could but it would be a burden for the programmers.

Awwww. Poor programmers - they might actually have to earn their paychecks.

More seriously, it is also a burden on programmers when the fragility of using
an integer representation hurts maintainability.

 

[Lew]

Unless the database allow constraints on range, then the database
can not enforce the range.

A FK to another table can in most databases.

Likewise if the FK is a string.

 

[Arne Vajhøj]

Perhaps they reasoned that using ints would be too fragile.

A well known person with the same last name as you
most certainly did not like the "camouflaged ints".

But other languages seem to survive their enum
implementation.

It is not something that often causes problems.

So the Java enums seems to be a great solution to
a non existing problem.

Arne

 

[Arne Vajhøj]

Awwww. Poor programmers - they might actually have to earn their
paychecks.

More seriously, it is also a burden on programmers when the fragility of
using an integer representation hurts maintainability.

But does it ?

Considering that the use of int in databases for things that
does not have int semantics is so widely used as it is.

Arne

 

[Lew]

But does it ?

Considering that the use of int in databases for things that
does not have int semantics is so widely used as it is.

And is a huge source of controversy in the database world. There are those
who strongly excoriate such usage.

I have been following for a few years the argument about the use of INTEGER
surrogate keys in databases. The most balanced viewpoint seems to be that
it's sometimes a useful hack for performance, but that care must be taken not
to expose such keys to the domain logic and that there is a downside to them.
Like everything else in software engineering, it seems that there are
compromises to make in the design decision regarding ints without int semantics.

 

[Martin Gregorie]

Likewise if the FK is a string.

That's not so easy unless you're going to enforce, say, alphabetic
ordering on the names, but the usage of the names has a different
ordering. The obvious example where there's a definite ordering thats
unconnected with the name sport order is *nix logging level priorities,
where ERROR also implies all less serious reporting levels, e.g. WARNING,
NOTICE, INFO and DEBUG but excludes the more serious ones (EMERGENCY,
ALERT, CRITICAL).

 

[Martin Gregorie]

My recollection for the enum approach though was that it only actually
yielded an integer. The DB didn't return a string, just an int. You
had to assume on the client side that you knew what string to use for
what int.

I can see a positive demerit - lack of portability. I use PostgresQL, but
would not use its enums because that would make the application non-
portable to Derby or H2.

Similarly, I do use sequences, which are fairly commonly implemented but
accept that would require a rewrite if my code needed to be ported to
MySQL, which only has auto-incrementing columns.