Re: maximum number of columns per table

Joel Garry wrote:

>>There is just about no excuse for having more than 50 columns in a table.
>>
>>If you think otherwise I would suggest you take a class on relational
>>database architecture and normalization.
>>
>>Daniel Morgan

I would call that an obscenity not an excuse. But that's another issue.

   It can be argued that
> a spreadsheet is quite relational - rows and columns, and that's it.

Not by anyone that ever spent more than one hour in a class on "What is a relational database" unless they were asleep.

> Normalization is another matter, of course. What I've found is there
> are some cases where it makes sense to put things together with lots
> of rows and columns, and then let the user do what they want.

I can only think of two:

1. Management ordered you to do so.
2. Sloth

   Of
> course, a tool comes with the package they are using that allows fast
> conversion from a relational query involving many tables to Excel that
> makes this a lot more sensible than programming from scratch. Doing
> this with proper design and programming would cost 100 times more than
> necessary. Not including changing working business processes to
> artificially constrain output to a normalized model. I don't think
> you would try to sell that, you would just say "this is ridiculous"
> and go do something else... right?

Most likely correct if I understand your meaning.

> But I think Jonathan really put his finger on it with the
> machine-generated idea, it is not the db's place to put an artificial
> limit on number of columns.
> Just as Excel shouldn't place an artificial limit on number of rows.
> Your argument of bad design is backwards - design should lead where it
> leads.
>
> jg

The limit on the number of columns has nothing to do with the database. It has to do with the width of a piece of paper run through a printer.

<RANT>
What I mean by that is that all of this is focusing on getting the data into the database rather than getting it back out. Developers traditionally take the self-serving attitude that they will make it easy to store the data now and let the report writers that come along later figure out how to get it back out.

So how many times does a row get inserted into a database? Once.

And how many times is the row reported on from inside the database? Many.

The efforts are generally just passing the buck from those most technically qualified to those less well qualified. And it not something of which developers should be proud though for some reason they are.
</RANT>

Daniel Morgan Received on Tue Jul 20 2004 - 21:44:34 CDT