Re: avoid to create public synonyms

"Andrew" <ahuntertate_at_icimail.com> schrieb im Newsbeitrag news:b165f5d8.0411091054.726db836_at_posting.google.com...
> "Dietmar Brueckmann" <Dietmar.Brueckmann_at_lycos.de> wrote in message
news:<2vbjkoF2j8hemU1_at_uni-berlin.de>...

> From a management aspect your DBA is correct. Creating one (1)
> public synonym per table and managing access through roles is much
> more manageable than creating Private synonyms for each user. What
> exactly are you trying to prevent/ allow for your users? If you need
> to dynamically determine what the users should have access to look at
> Virtual Private Databases(VPD) / Fine Grained Access Control(FGAC) on
> OTN
>
> If security is your concern check the following white paper. It does
> not directly address this but may give you some more ideas.
>

http://www.oracle.com/technology/deploy/security/oracle9i/pdf/9ir2_checklist .pdf
>

I've looked at this papers - thanks.

But my simple problem is to avoid modifing my aplications-SELECT/INSERT etc. for testcase:

Testdata for me

   SELECT * from A_TEST_SCHEMA.A_TABLE;

and for production:

   SELECT * from A_SCHEMA.A_TABLE;

I'd like to write everytime:

   SELECT * from A_TABLE;
to prevent me for making mistakes in modifying SQL-strings.

For that I need synonyms. In using public synonyms I'd be afraid of mixing "hot" data to my test-schema.
select * from a_table - sees it the table A_TABLE or because of synonym A_SCHEMA.A_TABLE. Possibly I can use "SYS_CONTEXT Function" as shown in one of the articles. But the easy readability of my SQL-statements is the highest important thing.
Thats why I'm thinking I'm going on to generate all private synonyms are necessary.
But I've asked. Thanks for answering me.

Dietmar Received on Wed Nov 10 2004 - 07:39:18 CST