Hi all,
I'm a fan of having the processing done by a user
different than the owner of the data.
Am I alone ?
For example, we're on a datawarehouse system where the
data owner is DWH. The etl tool repository owner is
TOOL_POWERMART and the reporting tool repository owner
is TOOL_BOWEBI. The etl
: Schema organization |
|
Hi all,
I'm a fan of having the processing done by a user
different than the owner of the data.
Am I alone ?
For example, we're on a datawarehouse system where the
data owner is DWH. The etl
i try to play by the same rule as you.
but if i can't then i put the ddl triggers on the tables owned by the
schema owner, which keeps at least the strucutures from being altered.
joe
paquette stephane wrote:
Hi all,
I'm a fan of having the processing done by a user
different than the
A couple of other reasons for this approach:
When you create a DAD in Oracle Application Server, you can choose to store
the password in the config file. On version 3.02 it is in unencrypted form
and is optional. On 4.x it's encrypted and mandatory (unless you cheat and
remove the password
paquette stephane wrote:
Hi all,
I'm a fan of having the processing done by a user
different than the owner of the data.
Am I alone ?
For example, we're on a datawarehouse system where the
data owner is DWH. The etl tool repository owner is
TOOL_POWERMART and the reporting tool
So what your DDL triggers are doing. And if they do not allow DDL to work
how you can execute DDL - disabling these triggers?
Alex Hillman
-Original Message-
Sent: Thursday, July 05, 2001 8:00 AM
To: Multiple recipients of list ORACLE-L
i try to play by the same rule as you.
but if i
yeppers, if you want to prevent ddl on tables when you are
required to give out the schema owner password, you put those triggers on all of
the objects. This assumes the user logging does NOT have alter any
trigger. The triggers are owned by a separate userid and look like
this(besides you
ya gotta love them new triggers in 8i.
I used a similar scheme to keep duhvelopers
from changing the passwords on common
development accounts, because they would
promptly forget them and call the DBA.
Jared
On Thursday 05 July 2001 09:21, JOE TESTA wrote:
yeppers, if you want to prevent
