Re: Separate Schemas for Data and Application?

From: Toon Koppelaars <toon.koppelaars_at_rulegen.com>
Date: Tue, 8 Apr 2014 08:47:42 +0200
Message-ID: <CAA9w=EspH-Q8JYzu1MyFNEWcCVxF+qEhmEvJW29kfu=b-TimVg_at_mail.gmail.com>



I prefer an architecture that enables me to clearly identify the 'entry points' of the (UI) application into the dbms. Ideally I would like three schemas:

1 - Application owner schema with all the tables and stored pl/sql that is not directly accessed by the application. 2 - API schema. This schema has all the objects that are accessed by the UI application.
3 - UI application connect schema.

Schema 2 would have private synonyms to objects referred in schema 1. And also the necessary object privileges granted from schema 1 to schema 2.

Schema 3 has private synonyms to objects in schema 2 + the necessary object privileges granted from schema 2.

On Mon, Apr 7, 2014 at 10:11 PM, Jeff C <backseatdba_at_gmail.com> wrote:

> 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.
>
>
>

-- 
Toon Koppelaars
RuleGen BV
Toon.Koppelaars_at_RuleGen.com
www.RuleGen.com
TheHelsinkiDeclaration.blogspot.com

(co)Author: "Applied Mathematics for Database Professionals"
www.rulegen.com/am4dp-backcover-text

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Apr 08 2014 - 08:47:42 CEST

Original text of this message