Re: Separate Schemas for Data and Application?
- From: Toon Koppelaars <toon.koppelaars@xxxxxxxxxxx>
- To: backseatdba@xxxxxxxxx
- Date: Tue, 8 Apr 2014 08:47:42 +0200
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@xxxxxxxxx> 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@xxxxxxxxxxx
www.RuleGen.com
TheHelsinkiDeclaration.blogspot.com
(co)Author: "Applied Mathematics for Database Professionals"
www.rulegen.com/am4dp-backcover-text
Other related posts:
