On Mon, Oct 10, 2005 at 06:24:55PM -0300, Mart?n Marqu?s wrote:
> El Lun 10 Oct 2005 16:42, Jim C. Nasby escribi?:
> > >
> > > Couldn't these features be mostly added as a 'MySQL Compatibility add-on'?
> > > For instance, the enum type you list above ... ?
> >
> > There's issues with doing that. I know one problem is that you currently
> > can't pass parameters in when you define a column in a table, which you
> > need to be able to do for an enum.
> >
> > But like I said, if we want to improve migration we should find out
> > where the users have pain and concentrate on that. That was actually the
> > context of the enum discussion. I threw enum out as an example and
> > everyone latched onto it, missing the overall point of trying to improve
> > migration from MySQL.
>
> The enum data type is just useless in most cases, and most MySQL programmers
> use enum as a way to store booleans. Nothing more, and nothing less.
>
> Just yeasterday somebody was asking about what to do with a field defined as
> CHAR(2) loaded with 'Si' and 'No' (Yes and No in spanish). Ofcourse, when I
> told him about boolean, and the posibility of easily transforming the bool
> variable into a 'Si' or 'No' chain using CASE. Now the problem is that these
> people don't know about the diferent data types, and what's worst, some don't
> have a clue on good database design.
>
> In my years of database programmer I have had to migrate a par of systems
> working on MySQL, and I have to say that whenever I saw an enum data type, I
> turned it to a boolean, and it allways would have been the best idea in the
> first hand (ofcourse, the original programmer couldn't do so, as MySQL didn't
> have the boolean data type).
>
> I know that enum could be used in a lot of other ways, but for what I see,
> everybody uses it as a replacement for boolean.
Interesting, though Bugzilla used it for a bunch of stuff until they
decided to support databases other than MySQL. The plan is to eventually
just store an int that points back to a parent table (ie: the right way
to do it...)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
