Normalization Question

  • Thread starter Thread starter TonyBuffkin
  • Start date Start date
T

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.
 
Access limits you to 255 fields per table, if by "fields" you mean columns.
And rarely do you see properly designed relational database systems with
tables containing close to that many fields.

"Database Design for Mere Mortals" is a good start, in addition to the link
that Kevin gave you.
 
Hi Scott - Thanks so much !



Tony



Originally posted by Scott McDaniel
Access limits you to 255 fields per table, if by "fields" you mean
columns.
Click to expand...
And rarely do you see properly designed relational database
systems with
Click to expand...
tables containing close to that many fields.

"Database Design for Mere Mortals" is a good start, in addition to
the link
Click to expand...
that Kevin gave you.


Scott McDaniel
Click to expand...
CS Computer Software
www.thedatabaseplace.net
Click to expand...

news:[email protected]"]bforums.com[/url]...
Click to expand...
I have been asked to work on a project that involves the construction
Click to expand...
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
Click to expand...
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
Click to expand...
across multiple tables, problems are imminent. Unfortunately, I am
Click to expand...
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
Click to expand...
me some insight into problems that may be forthcoming, I would
Click to expand...
appreciate it.
I appreciate anything that you can share with me, and I thank you in
advance for your time.
--
Click to expand...
Click to expand...
Posted via
Click to expand...
http://dbforums.com/http://dbforums.com
 
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
 
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

Start with defining the *real* problem. :)
 
(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?
Click to expand...


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