Normalization Question

[TonyBuffkin]

I have been asked to work on a project that involves the construction
and eventual implementation of a database to handle a potentially large
amount of data.



Many of the specifics are yet to be determined, however, one of the
major thought processes is that the database should be composed of one
main table that would contain, at the least, 1,600 fields.



I have tried, with my limited knowledge of databases, to explain to the
person in charge of this project that without normalization of data
across multiple tables, problems are imminent. Unfortunately, I am
still new enough at this that I don't have a list of valid arguments to
support my theory.



I was hoping that you could help me out with this. If you can give
me some insight into problems that may be forthcoming, I would
appreciate it.



I appreciate anything that you can share with me, and I thank you in
advance for your time.

 

[TC]

(snip)

Many of the specifics are yet to be determined, however, one of the
major thought processes is that the database should be composed of one
main table that would contain, at the least, 1,600 fields.

If you really mean fields" (not "records"), that will be a *baaaad* thought
process - and impossible, anyway!

Start with:
http://support.microsoft.com/support/kb/articles/Q100139.ASP

HTH,
TC

 

[SF]

I have developed similar database for construction of sub-projects.
Basically you must have 4 main areas

1 - General Project Information consist of ProjectID, Project Name,
Location, Estimated Cost, Beneficiary, Project Type (road, School or
Hospital)
2 - Status: Indication or record when project was received, evaluate
(appraised), apporved...
3 - Project Components: store possible components name and other info
related to each project and details components that list raw materials to be
used (eg cement, sand )
4 - Unit Cost database: This was mainly table of cost of all construction
materials that use the calculation of the components


SF

 

[Mike Sherrill]

I have been asked to work on a project that involves the construction
and eventual implementation of a database to handle a potentially large
amount of data.
Ok.

Many of the specifics are yet to be determined, however, one of the
major thought processes is that the database should be composed of one
main table that would contain, at the least, 1,600 fields.

What makes that opinion a thought process?

I have tried, with my limited knowledge of databases, to explain to the
person in charge of this project that without normalization of data
across multiple tables, problems are imminent. Unfortunately, I am
still new enough at this that I don't have a list of valid arguments to
support my theory.

Why are y'all trying to design a database to handle a large amount of
data by engaging people who don't know how to design a database?
Doesn't this sound like a risky way of doing business? Don't most
business people try to *minimize* the risk of failure rather than
*guarantee* failure?

I was hoping that you could help me out with this. If you can give
me some insight into problems that may be forthcoming, I would
appreciate it.

Start with defining the *real* problem.

 

[TC]

(snip)

Why are y'all trying to design a database to handle a large amount of
data by engaging people who don't know how to design a database?
Doesn't this sound like a risky way of doing business? Don't most
business people try to *minimize* the risk of failure rather than
*guarantee* failure?

I can't comment on the OP's situation. But in many cases, I think the
thought process is this. "Why should I stick my head above the parapet by
paying $10 today, when I could just pay $1 today? If problems arise
tomorrow, I'll worry about it then. Or I'll just blame the person I hired to
do the work."

Associated with this is a lack of inter-management accountability. Manager A
says to uber-manager B, "That guy I hired was an idiot. He stuffed it up,
we'll have to get someone else." Uber-manager B, having benefited from
manager A's various cost-cutting exercies, is reluctant to stir manager A's
pot; so he seldom says: "So why did you hire him? How can you assure me that
this will not happen again?"

Then everyone subsides back into their copy of "How To Manage Your
Manager" - except for the poor, underqualified slob who was silly-enough to
take the work on, in the first place!

TC