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.
INVOICE_STATUS_CANCELLED, INVOICE_STATUS_PENDING, INVOICE_STATUS_HOLD
or whatever.
The main trouble with my approach is that there is nothing stopping a
programming error like
invoice.setStatus(PURCHASE_STATUS_HOLD)
other than the naming convention. Enums should certainly help here.
Have I missed the point of what you were asking?
Ari
-------------------------->
ish
http://www.ish.com.au
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
This archive was generated by hypermail 2.0.0 : Wed Jan 16 2008 - 15:50:11 EST