Re: maximum number of columns per table

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Thu, 22 Jul 2004 18:04:06 -0700
Message-ID: <1090544672.307395@yasure>

Joel Garry wrote:

> Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1090377898.272706_at_yasure>...
>

>>Joel Garry wrote:

>
>
>

>>>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.

>
>
> Actually, I agree with you 99.999%. But this .001% is a substantial
> part of my income, and I suspect, many others. :-)
>
> And from a practical standpoint, [useful] tables never exist in
> isolation. There is bound to be an existing
> software/hardware/business process infrastructure - apart from
> complete business process reengineering, which may or may not make
> sense (and has a bad rep just now), and what one might call greenfield
> software.
>
> ...
>
>

>>>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

>
>
> An excellent rant, Daniel. Some of the old formal design
> methodologies start with the desired output. Even RAD style iterative
> methodologies tend to have some part where you present things to the
> customer and say "is this what you want?" Of course, with the latter,
> the customer may say "well, I want a spreadsheet." Happens to me all
> the time, and I share your opinions about Excel. Are we to be
> starving artists holding on to our ideals or skilled craftsmen selling
> out for our families? (My answer is generally to present the correct
> solution, then do what the customer says he wants me to. Those
> decisions are management's purview, not mine.)
>
> What seems to be at odds here is whether someone is sitting down at a
> blank screen and arbitrarily designing a table with 1000 columns.
> That would likely be bad design. Can we really conclude that from the
> OP? I don't think so, because there is other software involved, it is
> not a greenfield. Design can't, shouldn't say the output is always
> for a printer.
>
> jg
> --
> @home.com is bogus.

My feeling is that one should alwasy approach a project from the standpoint of maximum ethics. Meaning I will present to you (the customer) what, in my "expert" opinion is the correct answer.

Then if you, or your management, after being properly advised ask me to take your money to do something stupid ... and it is not immoral or illegal ... open your checkbook because my boat needs new sails. The one exception is that I think far too many employees suffer under abusive conditions when they should be putting out their resumes and moving on.

It is my responsibility to tell you (the customer) the right thing to do. It is not my responsibility to throw myself in front of a moving train: No matter how stupid the engineer.

Daniel Morgan Received on Thu Jul 22 2004 - 20:04:06 CDT