Re: how to group synonyms ?

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1069957611.8448_at_yasure...
| mcstock wrote:
|
| > "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
| > news:1069919723.866398_at_yasure...
| > | Billy Verreynne wrote:
| > |
| > | > "mcstock" <mcstockspamplug_at_spamdamenquery.com> wrote in
| > | >
| > | >
| > | >>i highly recommend public synonyms for applications
| > | >
| > | >
| > | > Arrgghhh!!! No!! Never!!
| > | >
| > | >
| > | >>-- coding the schema
| > | >>name with the object creates maintenance and portability problems
| > | >
| > | >
| > | > BULL!!
| > | >
| > | > Do *NOT* use public synonyms as a crutch like that. It is nothing
but
| > | > a quick and dirty method that lacks. Period.
| > | >
| > | > Take security, access control and scope into proper consideration
and
| > | > then DO IT CORRECTLY!!
| > | >
| > | > --
| > | > Billy
| > |
| > | I'm with Billy on this one. There is no valid reason I can think of
for
| > | public synonyms beyond DUAL and others created by Oracle. And I'd even
| > | take issue with a few of theirs if I thought anyone would listen.
| > |
| > | --
| > | Daniel Morgan
| > | http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
| > | http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
| > | damorgan_at_x.washington.edu
| > | (replace 'x' with a 'u' to reply)
| > |
| >
| > thanks for the feedback, polite and otherwise...
| >
| > i can see that there may be some valid points behind Billy's, shall we
say,
| > observation, but a little more articulation on specific problems would
be
| > helpful
| >
| > i've never ran into problems with my recommended approach -- and i don't
see
| > any security issues except the ability for adhoc users to read the
public
| > synonym definitions for objects that they would otherwise not know to
exist.
| > please elaborate if visibility of these object is the issue
| >
| > scope is considered in this approach (standard application prefixes
covers
| > that).
| >
| > basically, i view public synonyms in the same light as OS, Java, and
Apache
| > path and virtual directory settings -- all in pretty common usage
| >
| > it seems like the perceived issues are actually addressed by proper use
of
| > roles
| >
| > from a project development and testing standpoint, i've seen lots of
| > problems with explicitly naming the schema owner -- from limitations in
| > testing (all test environments must use the same schema names, hence
each
| > test environment requires its own instance) to customer DBAs insisting
on
| > changing schema names (which i don't advocate, but it happens in the
real
| > world all too often), to code reusability (can't plug code and tables
from
| > one project into another project)
| >
| > daniel's argument (basically) in favor of oracle's usage of public
synonyms
| > actually supports the use of non-oracle public synonyms. if i'm
developing
| > with good standards, i will quickly have common code and objects (i.e.
| > subsystems) used across multiple applications and/or subsystems (i.e.,
| > called from code existing in, or running under, multiple schemas). if
it's
| > not (totally) evil for oracle to create public synonyms for widely used
| > objects, why object to the same practice for commonly used non-oracle
| > objects?
| >
| > if public synonyms are that troubling, or if some actual problems can be
| > identified, then an alternate approach would be requiring each user to
have
| > appropriate private synonyms in order to run the application -- but that
| > seems a bit overkill, yet it preserves the schema-independence that i've
| > found to be extremely useful
| >
| > -- Mark Stock
|
| My major concern would be security. If someone doesn't need to know
| something exists it is a bad habit to allow them information about
| schema and object names.
|
| It is so simple to use non-public synonyms to do the same thing I'd
| suggest for the few minutes it would take to write a script to create
| the regular synonyms ... good development practice should win out over
| the lazyman's approach.
| --
| Daniel Morgan
| http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
| http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
| damorgan_at_x.washington.edu
| (replace 'x' with a 'u' to reply)
|

well that's more specific.

agree with the use of private syns, don't see the need to classify a difference of opinion as 'lazy'

now, what about plugging the ALL_USERS hole?

• Mark Stock