access2009eg
Sep 20 2011, 05:36 AM
What is the importance of using relationships between tables
Alan_G
Sep 20 2011, 06:13 AM
Hi
It's how relational databases are designed to work............
Maybe you could expand on your question a bit more so we can give you a more specific answer
jleach
Sep 20 2011, 06:50 AM
For one, it optimizes the data storage and retrieval processes. More importantly though, it maintains data integrety be relating peices of data.
In theory, it would be possible to write a database application with no relationships defined between tables (though you'd still have "on the fly" ones: joins in query statements, etc), but it'd be slow, clunky and prone to a lot of garbage in/garbage out (not to mention a ton more work required on your part).
You might boil to down to say it's the main entity of normalization enforcement.
Cheers,
GroverParkGeorge
Sep 20 2011, 08:56 AM
The best analogy I have come with with over the years is to talk about it in terms of a language, the language of database design. Put simply, you have nouns, adjectives and verbs.
Tables are the nouns; they are the "things" the database is about.
Fields are the adjectives; they describe the things the database is about.
Relationships are the verbs; they describe how things work in the database.
Try to imagine recording a sales transaction without using any verbs. Try to assign a student to a class without using any verbs. It is almost nonsensical to do either.
Even if you "pretend" that the verbs are not there, by not defining the relationships, you can't create a working database without them.
I have seen databases that did not bother to identify relationships. They rely on code to ensure records go in the right places. It can be done. Like everything else, though, there is a cost to it. All that extra code that must be added to handle data integrity. And it will still go bad, IMO, sooner or later.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.