RE: Separate Schemas for Data and Application?
- From: "Chitale, Hemant K" <Hemant-K.Chitale@xxxxxx>
- To: <backseatdba@xxxxxxxxx>
- Date: Tue, 8 Apr 2014 13:32:51 +0800
Three separate database accounts might be overkill.
Oracle's EBusiness Suite does separate the Code account (APPS, which has
Views, Packages, Procedures) from the Data accounts (FND, GL, AP, AR, FA
etc). The application connects as the Code account (APPS) after user
authentication using it's own Users table and user passwords. All
operations (query and DML) are done using the Code account (APPS). When
DDL (CREATE TABLE, ALTER TABLE etc) needs to be executed, the
application or patch utilities connect as the Data accounts (FND, GL, AP
etc) to execute the DDL and then GRANTs back to the Code account (APPS).
Most custom implementations that I've seen use a single database account
for data and code. I prefer the EBusiness Suite mode.
Note : I keep calling these accounts "accounts" and not schemas so as
to differentiate the account from the actual schema (objects) that may
or may not be owned by the account.
Hemant K Chitale
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jeff C
Sent: Tuesday, April 08, 2014 4:12 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Separate Schemas for Data and Application?
I wanted to know what everyone's opinion is on separating schemas. Like
having a data only schema, a code only schema and then a schema the
application logs into and executes code from the app schema. Or do you
put all data and code in a single schema and then a separate schema for
the application to run as?
Also do you implement table API's? If you do then this probably
nullifies a lot of these options.
Let me know what you do.
Thanks.
This email and any attachments are confidential and may also be privileged. If
you are not the intended recipient, please delete all copies and notify the
sender immediately. You may wish to refer to the incorporation details of
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
https://www.sc.com/en/incorporation-details.html.
Other related posts:
