Neven Luetic <[EMAIL PROTECTED]> wrote on 09/27/2005 09:35:04 AM: > > > Within a single server, you only need one copy of a table in one > > database. When you need data from it, just use the table's > > fully-qualified name and it won't matter which other database you are > > currently in (assuming that the account you are using has at least > > SELECT rights for the "master table" > > > > USE mysql; > > SELECT * From user; > > > > CREATE DATABASE testme; > > USE testme; > > SELECT * from mysql.user; > > If this is possible/feasible, depends on some issues concerning handling > of authentication inside the underlying webapplication.
OK, an example that's a little more concrete... Let's say that your "master" table is in the database "CommonData". So I could run a query (from within CommonData) like this: SELECT * from masterdata WHERE color='blue'; or from any other database on the same server like this: SELECT * from CommonData.masterdata WHERE color='blue'; Now, let's say that application1 logs-in to the database server as user1, application2 logs-in as user2 but each uses a separate "working" database (app1 uses `carpentry` while app2 uses `painting`). In order to allow user1 into the `carpentry` database, you probably issued a GRANT similar to this: GRANT SELECT, INSERT, UPDATE, DELETE ON `carpentry`.* TO [EMAIL PROTECTED]; where xx.xx.xx.xx is the IP address of the server hosting application1. All you need to do is to grant SELECT permission to user1 on CommonData.masterdata like this: GRANT SELECT ON `CommonData`.`masterdata` TO [EMAIL PROTECTED]; That way each application will be able to login as itself and connect to their default database but still have access to your master data. Make sense? > > > Now to keep the table in sync between servers, use replication or the > > Federated storage engine. Remember that, outside of NDB, replication > > is only one-way! Even "circular" replication only happens in one > > direction around the circle and has some important limitations. The > > Federated storage engine is part of v5.0. > > Replication is not an option, as the servers are already replicated for > backup reasons, but partly onto other servers (not "circular"), so > adding replication for this problem would create slaves with several > masters. Cool. > > Thank You > > Neven > > Your're welcome :-) Shawn Green Database Administrator Unimin Corporation - Spruce Pine PS. Always CC: the list on all responses. That way everyone can learn from the conversation.