See how the fates their gifts allot For A is happy...... B is not Yet B is worthy, I dare say, Of more prosperity than A Is B more worthy? I should say He's worth a great deal more than A. ----- Original Message ----- From: [email protected] To: RBASE-L Mailing List Sent: Monday, August 09, 2010 9:52 AM Subject: [RBASE-L] - Database design question
I would like some feedback or thoughts about a database design scenario. I currently have two databases, both used in a manufacturing production floor environment. I had originally made two separate databases as they were un-related operationally and thus reduced the chance that if one database went "down", it would not effect the other. Being a production system, effecting many people, jobs, operations, etc., it is imperative that down time does not happen or at least is kept to a bare minimum. Both these databases see fairly high volume of user access. Both writing and retrieving data. However, Database "B" now needs to obtain and write information to a table in Database "A". It will do so frequently, many times per hour by several operations at random times. So in essence, the two databases will be "connected" 100% of the time. So the question is... do I now merge both databases into one or keep them separate and use an ODBC connection between "A" and "B". Since "B" now needs data from "A", the original purpose of being separate is now gone.... I.E. If "A" goes down, so will "B". I ask this as I assume that an ODBC connection is not as efficient as a direct database access. Does not an ODBC connection have to call up a session of RBASE as well, even if both databases are in RBASE? What are thoughts on keeping all the data in one DB versus the two? (Database size will not be an issue in this case) Thank you, -Bob
