Bill.
Because I am part time at this programming, I sometimes miss all the ramifications of normalizing my database. I have tried to normalize it (and understand the purpose) and have been somewhat successful but am not where I need to be. When it comes to history, are you saying it is better to have multiple tables with just that one common field therefore eliminating the need for schema changes? So as the company asks for new fields, I just create a new in most cases small table (as far as number of columns are concerned) and the new data is entered there. So the history before the new table just doesn't show that information (instead of a bunch of nulls because I added it to a large history table). In this illustration, then it is just updating the forms and reports to draw from a new table. Am I reading what you folks are saying correctly? James Belisle Making Information Systems People Friendly Since 1990 ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Bill Downall Sent: Wednesday, February 22, 2012 10:27 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Too relational? It's nice to see Professor Wills here! You know a topic like this would get him going. Bill, in my mind, a basic reason to normalize fully is to create a database that is least likely to need either schema changes or awkward exception-handling down the road. If you do not normalize, and you provide room for 3 phone numbers, some day you will have to put the fourth phone number in the comments, or change the schema to allow for 4 phone numbers. Schema changes are expensive, because all forms and reports and procedures and eeps and views and rules and triggers and applications that relate to that data may have to be changed, too, and cannot be done by users through "settings", but have to be done by programmers. Putting the data in the "wrong" place like the comments means people won't find that data with a normal search or query. There are other good reasons to normalize, like not "wasting" columns that are usually blank, and not having to search three or five columns instead of one (For example, to determine what customer might have sent us an incomplete or garbled fax message or credit card transaction where all we know is that their address is "345 Main Street"). But avoiding future expensive schema changes is the main one. Bill On Wed, Feb 22, 2012 at 11:02 AM, Wills, Steve <[email protected]> wrote: "Too relational" is a state that is rarely achieved, IMHO. I think your issue/question often and I like the direction of your thinking. I guess that thinking about such makes me a little "twisted" to some. I also own my own barcode-scanner - well enough about my predilections!
