 | |
question on relationships
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
question on relationships -
08-04-2011
, 02:21 PM
#2
| |||
| |||
|
|
We have a database that was split and has a backend on the server. I asked why there were no relationships in it. they said that it was not needed because the form to subforms were set up with it. Should the backend have relationships set up just like it was before it was backended? |
as referential integrity, cascading updates, cascading deletes, etc.
There also may be performance improvements in letting the back end
relationships do some of the filtering and grouping.
--
Bob Q.
PA is y I've altered my address.
#3
| |||
| |||
|
|
sparks <sparks (AT) home (DOT) com> wrote in news:g6sl37l8bqph4h0klhispivhdghg9aer3a (AT) 4ax (DOT) com: We have a database that was split and has a backend on the server. I asked why there were no relationships in it. they said that it was not needed because the form to subforms were set up with it. Should the backend have relationships set up just like it was before it was backended? The back end needs relationships if there are constraints imposed, such as referential integrity, cascading updates, cascading deletes, etc. There also may be performance improvements in letting the back end relationships do some of the filtering and grouping. |
#4
| |||
| |||
|
|
We have a database that was split and has a backend on the server. I asked why there were no relationships in it. they said that it was not needed because the form to subforms were set up with it. Should the backend have relationships set up just like it was before it was backended? |
in the tables, then, no, there don't need to be any relationships
defined in the back end (that's the only place that matters --
relationships in the front end don't do anything).
But if, say, you have an invoice and invoice detail tables, you MUST
have a relationship defined. Exactly how you define it is up to you
(with or without CASCADE DELETE, for instance), but in the real
world, an invoice detail can't exist without a parent invoice, so
you shouldn't allow that in your invoice detail table.
Relationships of this sort should NEVER be left to the application
level, because they are not part of the application, but part of the
logical structure of the data itself. The data itself should stand
by itself and maintain its own integrity, rather than depending on
an application to maintain its integrity and consistency. Always do
RI at the engine level when it's possible (and some pretty
widely-used databases DON'T support it, i.e., MySQL with standard
MyISAM tables).
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#5
| |||
| |||
|
|
We have a database that was split and has a backend on the server. I asked why there were no relationships in it. they said that it was not needed because the form to subforms were set up with it. |
Quote:
|
Should the backend have relationships set up just like it was before it was backended? |
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.