Joining tables in different mySQL databases on same server, different instances
We have an application that uses two instances of mysql, running on two different ports on the same server, say 4510 and 4511. Table "A" has transaction details and a user number, Table "B" (on 4511) has user details. I need to simply join the two tables to provide all of the transaction details and the associated user name. Apparently if these two databases were on the same mysql port, this would be pretty simple. However, I'm not sure how to make it work in this case.
The only thing I've found so far relates to using a federated storage engine and federated table. Is this the correct (only?) way to do what I need to do?
The only thing I've found so far relates to using a federated storage engine and federated table. Is this the correct (only?) way to do what I need to do?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The only downside to the scripted approach is that the final, joined data exists within the scope of the application that did the joining, so that might be good or bad depending on your goals.
ASKER
Is there a downside to using the Federated Storage Engine?
ASKER
virastar,
Thanks. That may be closer, I'm not sure. The end result of that solution is (apparently) to grant access between the databases, but doesn't say how that is to be done, nor how to actually do a query between the two once permission is granted.
Thanks. That may be closer, I'm not sure. The end result of that solution is (apparently) to grant access between the databases, but doesn't say how that is to be done, nor how to actually do a query between the two once permission is granted.
@virastar - that article uses the intermediate programming/scripting language approach that I mentioned, but pushing the data back into temp tables is likely slower than just using the in-memory data.
@clbrownjr - Aside from initial setup, no, there's no real downside. On the backend, it's technically doing the same thing - it's just using the MySQL client as the intermediate piece instead of a separate application. If you're good with enabling the federated storage, then it should be a fine solution.
Just to set expectations, remember that no matter what you do, you're dealing with two different, separately-optimized tables, so the solution will always be slower than using a single instance containing both tables.
@clbrownjr - Aside from initial setup, no, there's no real downside. On the backend, it's technically doing the same thing - it's just using the MySQL client as the intermediate piece instead of a separate application. If you're good with enabling the federated storage, then it should be a fine solution.
Just to set expectations, remember that no matter what you do, you're dealing with two different, separately-optimized tables, so the solution will always be slower than using a single instance containing both tables.
ASKER