Re: Enum best practices

From: Aristedes Maniatis (ar..sh.com.au)
Date: Wed Jan 16 2008 - 15:49:25 EST

  • Next message: Kevin Menard: "Re: Enum best practices"

    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