enum type, sort, restrict, use

[awebguynow]

After reading that enum column is very efficient, I'm determined to use
it where I can.
Does anyone have WebApp experiences, that make life easier.

I can see applications for US states, phone types, order types, etc.
but for example
in a contact manager business phone types may differ than personal
phone types
ie:
work
home
cell
247
pager
day
eve

I guess this column type is best used with a mutually exclusive,
defined, stable set of choices, and can be difficult to use otherwise.

[awebguynow]

btw, is there anyway to select all the possible values of an enum, to
create a <select><option>.... list ?

[Bill Karwin]

"awebguynow" <i_****@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

After reading that enum column is very efficient, I'm determined to use
it where I can.
That's not a good reason to use a data structure. A scalar variable is more
"efficient" than an array, but would you use a scalar where you need an
array?
I guess this column type is best used with a mutually exclusive,
defined, stable set of choices, and can be difficult to use otherwise.
Correct. I would use enum only for fields where the list of values is by
definition immutable. The only one that comes to mind is defining an enum
of male/female for a non-nullable Gender column.

In most cases where I see people misusing enums, it would be better to have
an additional table containing the valid values, and where you would have
used an enum, instead use a foreign key. The reason is that in most cases
of misuse of enums, it's because the set of values are likely to change
during the lifetime of the application. It's very easy to change the values
by adding a row to a lookup table, but it's awkward and risky to adjust your
enum definition every time this happens.
is there anyway to select all the possible values of an enum, to
create a <select><option>.... list ?

If you use a lookup table instead of an enum, it's very easy to get the list
of valid values.

Regards,
Bill K.