Database Reference
In-Depth Information
select e.empno,
e.ename,
d.dept_name,
d.location
from #OWNER#.emp e,
JOEY.dept d
where e.deptno = d.deptno
The
#OWNER#
substitution variable would be resolved to your “parse as” schema
(
DOUG
), and the join would work correctly as long as the correct privileges were in
place.
Note
Because the grants that allow the select from the
JOEY
schema are put in
place at the database level, it isn't necessary to associate the
JOEY
schema to your
workspace. You only need to associate a schema to a workspace if you'll be using it as
the “parse as” schema for an application in that workspace or need to access the schema
objects directly from within the SQL Workshop.
A Final Word on Workspaces
As you have learned, an APEX instance can have many workspaces. But how many
workspaces should there be? The answer isn't straightforward.
Unless you're in a very small organization with very few apps, you probably
shouldn't have only one workspace. On the other hand, you probably shouldn't create a
new workspace for every new application you code, either.
There are a couple schools of thoughts on this, but we tend to think in terms of ap-
plication suites. If a number of applications are performing similar tasks against the
same underlying data sets and are aimed at the same target set of users, then they
would probably do well in the same workspace.
The key is to use your judgment and try to keep things easy to develop and main-
tain. There is nothing worse than logging in to a workspace to find you have to page
through tens or even hundreds of apps to find the one you want to work on.
A Tour of the APEX Modules
