cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <>
Subject Re: Enum best practices
Date Wed, 16 Jan 2008 20:49:25 GMT

On 17/01/2008, at 2:43 AM, Kevin Menard wrote:

> The best way I've come up with is if the enum maps its values to the  
> PKs of
> the entries in "eval_status" table.  I think this would achieve what  
> I'd
> like, with the downside that referential integrity may be  
> compromised if I
> update one but not the other.
> Is this largely what others are doing?  Or, do you just use VARCHAR  
> columns
> and not worry about the normalization of the DB?

I don't quite understand what advantage you get from the above  
approach rather than just creating a table called  
OrderEvaluationStatus and using regular relations?

For my part, I make a separation between attributes which a user might  
(even theoretically) modify and those which are tied into the  
functioning of the code. If a user might change the data (eg. states,  
postcodes, etc) then it belongs in a separate table. If tied  
instrisically to the code (eg. Invoice.status) then I'd create static  
constants in the Invoice table which point to Integer values for  
database storage. A user shouldn't then be able to create a new  
invoice status even if they have direct access to the database since  
their meaning is heavily tied up in how the code works.  
or whatever.

The main trouble with my approach is that there is nothing stopping a  
programming error like


other than the naming convention. Enums should certainly help here.

Have I missed the point of what you were asking?


Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

View raw message