| SGreen@unimin.com 2005-09-27, 9:23 am |
| --=_alternative 004B827B85257089_=
Content-Type: text/plain; charset="US-ASCII"
Neven Luetic <Neven.Luetic@hanse.net> wrote on 09/27/2005 09:35:04 AM:
>
>
> 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
user1@xx.xx.xx.xx;
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 user1@xx.xx.xx.xx;
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?
>
>
> 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.
--=_alternative 004B827B85257089_=--
|