Re: ENUM type

Jim C. Nasby wrote:

>>
>>Yeah, you're right. But this is only in the case where someone cares
>>about using an int rather than a string type for some performance
>>reason. If they don't mind wasting a few bytes (and it's really only a
>>few bytes per record), then why not just use a check constraint when
>>defining the table (like Chris explains)?
>
>
> Normalization is about a lot more than just saving space in your base
> tables. But since that's the example you used, you a) can't assume it's
> only a few bytes and b) can't assume that those few bytes won't start to
> seriously add up over the span of a few hundred million rows.
>
> Remember: while disk space might be cheap, disk I/O bandwidth costs a
> fortune.
>

First, I doubt there exists a single case in the universe where someone
has 100 million rows of an enum type in MySQL, and they want to convert
to PostgreSQL without redefining their tables.

I would say the separate table is the way I would do it, but as far as a
conversion from MySQL->PostgreSQL, why are we trying to normalize their
tables along the way? Wouldn't the simple solution be the way to get
them started?

Nobody is going to expect that much from a conversion. They get their
app going on PostgreSQL, and slowly start to do things the right way. If
we hide the fact that we're normalizing their data, how does that really
help them?

However, it's fine with me if we do it that way. If there's additional
effort I just don't know whether it's worth it.

Regards,
Jeff Davis