On 1/16/08 3:49 PM, "Aristedes Maniatis" <ar..sh.com.au> wrote:
> 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.
That's largely what I'm trying to avoid. I don't want a bunch of integer
values that have no meaning without the corresponding Java code. I suppose
SQL comments are one way to go or external documentation, but each has its
own set of downsides.
>
> 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.
Correct. I think they enhance clarity in most cases as well.
>
> Have I missed the point of what you were asking?
>
I'm not sure. I may not have been clear enough to start. Do my above
comments help elucidate any?
-- Kevin
This archive was generated by hypermail 2.0.0 : Wed Jan 16 2008 - 17:32:46 EST