At 01:41 PM 5/5/2006, sheeri kritzer wrote:
The best way to do it is NOT to make new codes. If they're giving you
codes, use theirs -- why make up a new system if you don't have to?
[...]
Well, I made up my own codes before I knew I had to import data from
somewhere else. I was quite happy with the single binary char approach
until I had to import data from an oracle db. It definately would be
easier for me to translate the new coded field into single chars during the
import than it would be for me to re-do all the coded fields I have so far.
But I was thinking that since I have to do something with this 5-char coded
field, it might be a good time to overhaul the whole coded field system I
invented.
In fact, I would not gain clarity by using the 5-char codes that have been
imposed upon me. Freshman='10'. Sophomore='20'. There's even a '00' code
and a '05' for some status less than Freshman.
Somebody suggested (via private email I think) that I use enum. I had
mentioned in my original message that I didn't want to do that because some
of the coded fields allow end-users to add/remove codes. But he pointed out
that that could be done via alter table commands. That's kind of scary to
me. I dunno.
Another problem with the enum approach is getting the possible values into
a select list on a web page. I've seen people say they parse the output
from a show table command. That seems breakable to me. What if version 7
of mysql adds a space somewhere. Or reorders the columns.
So I still don't know how I want to handle this problem. Right now I'm
leaning toward translating the 5-char codes to 1-char codes and sticking
with what I've got. If somebody had given me a dramitcally better way to
handle coded fields than what I'm already doing, I might have been willing
to re-write everything. But right now, I'm leaning more toward the "if it
ain't broke, don't fix it" theory.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
