firewoodtim@yahoo.com wrote:
> On Fri, 18 Jan 2008 16:01:10 -0800 (PST), ThanksButNo
> <no.no.thanks@gmail.com> wrote:
>
>> On Jan 18, 3:44 pm, firewood...@yahoo.com wrote:
>>> I'm building an application that uses a table containing about 100
>>> fields of data. Approximately half are ints; the other half are
>>> mostly varchar, with a few enums and one text field thrown in. My
>>> question is, is this number of fields poor programming? I could
>>> conceiveably cut back the number of fields by adding some auxiliary
>>> tables. After all, not every field is used in every query. Still,
>>> that would add a lot of complexity to my application and I would like
>>> to avoid it.
>>>
>>> Any advice?
>> There's no way to say if it's "poor programming" without knowlege of
>> what your application is.
>>
>> If you've gone through the standard normalization analysis and this is
>> what you came up with, then so be it. I'd be more concerned about
>> hitting some arbitrary database limit. E.g., Sybase complains if a
>> single row might become too large to fit in a single 2k block.
>
> I haven't had any complaints from MySQL as yet, and the code seems to
> run as fast as I need. It just seemed like an awful lot of fields,
> and I wondered if it was unusual.
>
> I haven't been too concerned with normalization, because breaking the
> set of fields down into specialized tables would mean I would have to
> sacrifice a lot of simplicity in the code. Still, every single SELECT
> call to the db winds up delivering a lot of unnecessary data.
>
> This is a website application that is geared to small businesses, so
> there is little likelihood that the data sets will ever be gigantic.
> I'm really just trying to understand the tradeoff between design
> elegance and practicality in writing the code.

I have learned over the past 25+ years in IT you NEVER say anything like
"There is little likelihood that the data sets will ever be gigantic"
--- because it almost always does....