RE: Separate Schemas for Data and Application?

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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jeff C Sent: Tuesday, April 08, 2014 4:12 AM
To: oracle-l_at_freelists.org
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.

--
http://www.freelists.org/webpage/oracle-l