-
How far is inter-module dependency preferred ? or is it a big no no ?
Hi all,
Recently i was having a discussion with my development team and design managers regarding one of our application module (say in schema MNT) which seems to have a child table refering to a parent table in different application module (say schema PCH). (We have seperated the application modules into their individual schemas) . Since our construction hasn't started yet, its still in HLD phase, we have the change to fix it.
What i wanted to know is, what will be the impact of having a child and a parent in different application modules (schema) ??
I was thinking that the interdependency should take place at the application level not on the database level.
Any way im not so sure, your thoughts please.
Amar
"There is a difference between knowing the path and walking the path."
-
If both schemas are in the same database, I don't see any problem in implementing a foreign key on database.
I would do it on database level.
Application logic should of course implement this constraint as well.
What I mean is, application should be designed in a way that it will not try to violate this constraint and get "integrity constraint violated" errors.
Tomaž
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools" - Douglas Adams
-
Agreed.
Being a database guy, i dont see any problem, except that it would restrict portability in the sense that tomorrow if the client wants to keep the application modules in seperate databases depending upon how critical the apllication is.
But the design gurus say that this is not considered as a good design, what ever dependency exists should exist in the application, should not be database bounded. Since im not a designer so don't understand what they talk about.
Any way would appreciate if i knew what designers at your shops have to say about this.
Amar
"There is a difference between knowing the path and walking the path."
-
We have a similar architecture here in two of our largest applications, I can see no problem with this approach providing the applications have similar demands.
Personally I feel that if the user community of the applications is vastly different or the type (OLTP, DSS, DW etc) of application is different then it's best to maintain seperate databases.
Another option of course is to replicate just the dependant objects.
HTH
Jim
Oracle Certified Professional
"Build your reputation by helping other people build theirs."
"Sarcasm may be the lowest form of wit but its still funny"
Click HERE to vist my website!
-
Originally posted by adewri
But the design gurus say that this is not considered as a good design, what ever dependency exists should exist in the application, should not be database bounded.
How are they advocating it?
Well, then you have to make sure nobody can get in except through application.
Even better, make it available for everybody to corrupt the data, even give lessons to end users how to use sqlplus, then wait for dependency violating data to emerge, and enjoy drinking coffee while looking the designers sweat repairing the data
Tomaž
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools" - Douglas Adams
-
Amar
"There is a difference between knowing the path and walking the path."
-
I would go with the approch of the designers, I think they got a point.
Performance wise, it hardly matters if Tables ( Parent & Child ) are in same schema or different.
But, if you look as a appl & to design properly, i see 2 reasons why I prefer this approch
* You gotta pretty good flexibility in restricting access if you see at application level or at end user level.
* Better I/O by assigning defualt TS & files located on diff disks, this is only applicable if End user/developers are allowed to create structures as they dont have rather I can say have fairly less knowledge about db design in terms of TS and so.
funky...
"I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."
"Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"
-
Originally posted by abhaysk
* Better I/O by assigning defualt TS & files located on diff disks, this is only applicable if End user/developers are allowed to create structures as they dont have rather I can say have fairly less knowledge about db design in terms of TS and so.
This does not matter in any way whether i follow what designer say or not as i already mentioned that we have modules seperated into seperate schemas... and each schema will have their own set of tablespaces based on table sizes. We have seperated out the schema such that they can be deported on seperate databases also.
Amar
"There is a difference between knowing the path and walking the path."
-
Originally posted by abhaysk
* You gotta pretty good flexibility in restricting access if you see at application level or at end user level.
What do you mean?
Tomaž
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools" - Douglas Adams
-
Originally posted by adewri
i already mentioned that we have modules seperated into seperate schemas... and each schema will have their own set of tablespaces based on table sizes.
This is what i intended to say,
had u all tables in one schema & allowed devlopers to create structures, and they as devlopers least bothered about TS, Storage and so will only mess up the things.
Better if Child and Parent in diff schemas when you know the amount of data to be in these tabs, you woud have assigned defualt TS with appropriate storage.
Abhay.
funky...
"I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."
"Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|