views on DB Linking
Printed From: Web Wiz Forums
Category: General Discussion
Forum Name: Database Discussion
Forum Description: Discussion and chat on database related topics.
URL: https://forums.webwiz.net/forum_posts.asp?TID=12832
Printed Date: 30 March 2026 at 1:50pm
Software Version: Web Wiz Forums 12.08 - https://www.webwizforums.com
Topic: views on DB Linking
Posted By: dj air
Subject: views on DB Linking
Date Posted: 04 December 2004 at 5:53pm
|
hiya, can i have your views on linking databases, Access of course.. im using SQL but for clients they may be using Access. i have my login manager and am intergrating it into the Forum, is it best to just have them both in the same Database or linking ok. im just wondering regarding the hosting, IE. how much more processing and ram etc. a lot more, or do hosts not really like this. any views at all are welcome. you can find out more details about the intergration here with a demo link http://forums.webwiz.net/forum_posts.asp?TID=1 2519&PN=1 |
Replies:
Posted By: dpyers
Date Posted: 05 December 2004 at 9:08am
|
I think it depends upon what you're thinking of as criteria for best.
If it's performance, both Access d's need to be loaded into memory so there's some additional overhead there. IIRC, the link index is also a separate memory load - but I might be wrong about that.
If it's maintainability/usability/ease of integration, keeping your app as separate as possible is probably the way to go so linking would be preferred. Also allows your app to integrate with more than just one other app/db. ------------- 
Lead me not into temptation... I know the short cut, follow me. |
Posted By: dj air
Date Posted: 05 December 2004 at 9:45am
|
cheers, the application is seperate entirely, the forum/login manager update each other using the User_code(s) as the identifier. so they are really 2 different apps, the cookie checks the UserCode, and as both db are the same they have the same users and userCodes (validation). all ive been doing is MODing the forum to use update/delete/INSERT INTO queries. didn't want to use a seperate DB Connection so thats why i thought about linking/ in the same database. SQL version is fine as you just need different table names, and as SQL goes its cabable of both in a DB. |