1. APEX and SmartDB Step-by-Step

2. Anton Nielsen Vice President – Insum anielsen@insum.ca Formerly
President, C2 Consulting
Technical Directory, Oracle
Consultant, Coopers and Lybrand (now PWC)
Captain/Scientist, US Air Force

3. Agenda
What is the Thick Data Paradigm?
Goals Related to APEX in this Paradigm
A Recipe for Implementing the Thick Data Paradigm with APEX
Drawbacks
Discussion

4. Overview PL/SQL Application to APEX
Bryn Llewellyn discussed merits of PL/SQL and the “thick database” approach
Later rebranded as SmartDB
Toon Koppelaars set up focus on performance gains
Application to APEX
My focus is applying this concept to Oracle APEX
Consider the apex.oracle.com blueprints
Full Text: In July 2016, Bryn Llewellyn published "Why use PL/SQL?," an Oracle white paper expounding upon the virtues of the thick database approach--focusing on the benefits of data integrity. Toon Koppelaars has a similar presentation that focuses on the performance gains of the thick database. 
Both presentations provide specific recommendations targeted to the Java and mid-tier centric development communities. Most of these recommendations apply to APEX applications as well. This presentation will provide specific guidance on applying them in APEX.

5. Goals
Correctness (and Security)
Performance
Ease of Development
Ease of Maintenance
Instantiating the Thick Database Paradigm to Ensure these Goals are Met

6. Recipe - Ingredients Thought and Planning At Least Two Schemas
One Workspace (with its own schema)
Tables
Simple Views or Editioning Views
Logic in PL/SQL packages
Views with Instead Of Triggers*
Patience
*We will have a lot of discussion on this.
This could be a choose your own adventure presentation.

7. Step 1: Consider Multi-User Concurrency (MUC)
Optimistic vs Pessimistic Locking
Will front end developers be responsible for managing (MUC)?
How will you ensure correctness?
For our example we will use an Object Version Number (OVN) column

8. Step 2: Store the Data Create a schema to hold data: GLOC_DATA
Create tables, indexes, sequences, triggers*
Name tables TABLE_NAME_RT
DEPARTMENT_RT
EMPLOYEES_RT
Front End developers will never interact with the _RT tables
Back End developers will never interact with the _RT tables
This schema is the domain of a good DBA
*If you like triggers. These may belong on the next slide.
CREATE TABLE  "DEPARTMENT_RT" 
   ( "ID" NUMBER, 
"DEPT_NAME" VARCHAR2(256) NOT NULL, 
"DEPT_LOCATION" VARCHAR2(256), 
"OVN" NUMBER NOT NULL, 
CONSTRAINT "DEPARTMENT_RT_PK" PRIMARY KEY ("ID")
  USING INDEX  ENABLE
   ) /
CREATE table "EMPLOYEE_RT" (
    "ID"             NUMBER NOT NULL,
    "EMP_NAME"       VARCHAR2(256) NOT NULL,
    "DEPARTMENT_ID" NUMBER NOT NULL,
    "SALARY" NUMBER NOT NULL,
    "OVN"            NUMBER NOT NULL,
    constraint  "EMPLOYEE_RT_PK" primary key ("ID") )
ALTER TABLE "EMPLOYEE_RT" ADD CONSTRAINT "EMPLOYEE_RT_FK" 
FOREIGN KEY ("DEPARTMENT_ID")
REFERENCES "DEPARTMENT_RT" ("ID")
create sequence "GLOC_SEQ"
start with 1
increment by 1
cache 20
nocycle
noorder
/   

9. Step 3: Consider Edition Based Redefinition (EBR)
If using EBR, for each table create an editioning view.
If not using EBR, for each table create a standard view.
For my example I will create standard views.
Discussion — Should EBR be in the same schema as the data?
create view department as 
  select * from department_rt /
create view employee as 
  select * from employee_rt

10. Step 4: Create Schema for Logic
Create a schema for database (pl/sql) developers: GLOC_LOGIC
Grant select on VIEWS (EVs) with grant option* to GLOC_LOGIC
Grant insert, update, delete on VIEWS (EVs) to GLOC_LOGIC
Grant select on sequences GLOC_LOGIC
Create private synonyms for DATA objects (optional)
*The grant option will be used to allow front end developers access to data
Note: Take care to use CREATE OR REPLACE on views going forward. Do NOT drop and recreate as synonyms become invalid.
create synonym department for GLOC_data.department /
create synonym employee for GLOC_data.employee
create synonym GLOC_seq for GLOC_data.GLOC_seq

11. Step 5: Create Logic Discussion: Table APIs
Beyond TAPIs: Consider “Give everyone in IT a 5% raise”
Consider triggers vs API logic (see insert code)
   l_id  number := p_id;
   begin
      if l_id is null then
        l_id := GLOC_seq.nextval();
      end if;
Logic should be created in the LOGIC schema
You can’t directly use APEX TAPIs in the LOGIC schema. You can create in DATA, download search and replace, and run in LOGIC schema.

12. Data Storage Objects (Tables, Indexes)
Schema Design (so far) 
Grants to Views/EVs
Select grants with grant option
Grants to Sequences
LOGIC
APIs
DATA
Views (CRUD) or EVs
Data Storage Objects (Tables, Indexes)

13. Step 6: Create Workspace (Finally!)
Create APEX Workspace in another schema: GLOC
As GLOC_LOGIC
grant execute on GLOC_tapi to GLOC;
Demonstrate: grant select on employee view;
Create synonyms as GLOC (optional)
synonyms for GLOC_logic APIs;
synonyms for GLOC_logic views
Note: GLOC could be completely unaware of GLOC_DATA, but the APEX builder will show the views as owned by GLOC_DATA
grant execute on GLOC_tapi to GLOC;
grant select on employee to GLOC;
grant select on department to GLOC;
create synonym GLOC_tapi for GLOC_logic.GLOC_tapi;
create synonym department for GLOC_logic.department;
create synonym employee for GLOC_logic.employee;

14. Security should be implemented at multiple levels
A Word About Security
Security should be implemented at multiple levels
Multiple Schemas
Logic defined in packages in the database
Access restricted to packages & Views
SQL Injection, Post Data Tampering, etc.
You can not rely on browsers and front end developers to secure your data
apex banner comments example
/Users/anton/Documents/oracle/oware/apex/builder/f4000.sql
the runtime where clause

15. Schema Design APEX Workspace Packages Related to UI Only Logic APIs
CRUD Grants to Select Views*
Grants to APIs
*We will replace this with a different approach in a subsequent step (don’t really do this!)
Logic
APIs
Grants to Views/EVs
Select grants with grant option
Grants to Sequences
DATA
Views (CRUD) or EVs
Data Storage Objects (Tables, Indexes)

16. Step 7: Make the Workspace Work
At this point, the workspace is functional, but lacks features
What works
Reports
Forms Based on APIs owned by GLOC_LOGIC
Interactive Grids with Select Only
What doesn’t work
Interactive Grids with Insert, Update or Delete
Anything that references a ROWID
Forms based upon a table or view (automated DML operations)
Discuss why these don’t work—and why we do NOT want them to work.

17. Step 7: Make the Workspace Work (ctd)
As the LOGIC user, Create Views with instead of triggers
create view employee_crud as select * from employee /
create or replace trigger employee_crud_bi_intrg
instead of insert on employee_crud
begin
  GLOC_tapi.ins_employee( p_id  => null
                          , p_emp_name => :NEW.emp_name
                          , p_department_id => :NEW.department_id
                          , p_salary =>   :NEW.salary);
                          
end; 
create or replace trigger employee_crud_bu_intrg
instead of update on employee_crud
begin
  GLOC_tapi.upd_employee( p_id  => :NEW.id
                          , p_emp_name => :NEW.emp_name
                          , p_department_id => :NEW.department_id
                          , p_salary =>   :NEW.salary
                          , p_ovn   => :NEW.ovn);
                          
end; 

18. Step 7: Make the Workspace Work (ctd)
Unfortunately! In order to allow the GLOC user to insert, update and delete into the new CRUD views, with “instead of” triggers, the GLOC_LOGIC user must have grant option.
Also, “instead of” triggers disappear when view is recreated
GLOC_DATA must grant with grant option.
GLOC_LOGIC grants select, insert, update, delete on _CRUD to GLOC
grant select, insert, update, delete on employee to GLOC_logic with grant option;
grant select, insert, update, delete on department to GLOC_logic with grant option;

19. Schema Design (revised)
APEX Workspace
Packages Related to UI Only
Grants to Views with Instead of Triggers
Grants to APIs 
Logic
APIs
Grants to Views/EVs
Select grants with grant option
Grants to Sequences
DATA
Views (CRUD) or EVs
Data Storage Objects (Tables, Indexes)

20. Recap
If you are satisfied with APEX features that don’t require Automated DML or updatable Interactive Grids, you can stop at “select”
If you want additional APEX automation, create views with Instead Of triggers that exercise the logic in your APIs 

21. Some things still don’t work
Unfortunately…
Some things still don’t work 
Add row in Interactive Grids requires PK to be set in the IG
Returning Value in Automated DML
ROWIDs
You can’t use the “returning” clause with a view with an Instead Of trigger
You can’t add a ROWID column, named ROWID, to a view
Demo & Discussion

22. Discussion What is the value in separating schemas?
Data
Editioning  Views
Logic
Presentation / Workspace
Do views with Instead Of triggers encourage bad practices?
When are the trade-offs just not worth it?
When would you create tables just for the presentation layer?
Do these require similar levels of “correctness”?
APEX doesn’t use multiple schemas, why should we?
Update employee_crud set salary = salary * 1.05 ends up with “slow by slow” processing.