983170 wrote:Are you sure that he said "database" and not "schema"?
Views should be created somewhere else, not in the production database.
* Less risk of accidentally damaging real production db objects & data if working in Oracle as a user with these rightsI'm not sure that I understand. What "damage" is being referred to?
* Keep site-defined objects separate from the vendor-defined objectsIf we're talking about a packaged application, it makes good sense that you shouldn't be creating objects that are owned by schemas that are delivered by the vendor. In the same way that you shouldn't create objects that are owned by schemas that Oracle delivers (i.e. SYS and SYSTEM), it generally makes sense to create any custom objects in a separate schema so that you don't create problems in the future when the vendor delivers an upgrade script. If the vendor decides that it wants to create a view in the future that happens to use whatever name you choose, you don't want the upgrade script to fail because your view already exists in the same schema.
When asked "how do you use the views in other database, say, the training database, to work on the base tables which are on theIf you create a database link in database A that points to database B, you can create a view in A that references objects in B. It makes no sense to create a view in the training database that points to the production database. If this is a production object, it should exist in the production database. Probably in a schema in the production database other than the one that the vendor uses to own the application's objects.
production?" He gave the following suggestion. I am not sure if the traindb user can execute the view in another.
As the my_schema user, create the view in your custom schema:
create view my_schema.my_view as select ... from mydb.table1 etc.; Have the my_schema user grant access on the view:
grant select on my_schema.my_view to my_traindb_user;