How far is inter-module dependency preferred ? or is it a big no no ?
DBAsupport.com Forums - Powered by vBulletin
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: How far is inter-module dependency preferred ? or is it a big no no ?

  1. #1
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796

    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."

    Amar's Blog  Get Firefox!

  2. #2
    Join Date
    Jul 2001
    Location
    Slovenia
    Posts
    422
    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

  3. #3
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796
    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."

    Amar's Blog  Get Firefox!

  4. #4
    Join Date
    Jan 2002
    Location
    Up s**t creek
    Posts
    1,525
    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!

  5. #5
    Join Date
    Jul 2001
    Location
    Slovenia
    Posts
    422
    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

  6. #6
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796
    Originally posted by TomazZ
    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
    Naaa, that won't happen as my design managers are too good and very experienced . I have been working with few of them for last 3 years (in previous very successful projects) and i know they are damn good enough to take care of these problems. Any ways lets see how things come up .

    Thanks for all your replies.
    Amar
    "There is a difference between knowing the path and walking the path."

    Amar's Blog  Get Firefox!

  7. #7
    Join Date
    Dec 2002
    Location
    Bangalore ( India )
    Posts
    2,434
    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"

  8. #8
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796
    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."

    Amar's Blog  Get Firefox!

  9. #9
    Join Date
    Jul 2001
    Location
    Slovenia
    Posts
    422
    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

  10. #10
    Join Date
    Dec 2002
    Location
    Bangalore ( India )
    Posts
    2,434
    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
  •  



Click Here to Expand Forum to Full Width