reconciling apex and the thick database paradigm · reconciling apex and the thick database...

Copyright © 2017, Oracle and/or its affiliates. All rights reserved.

Reconciling APEXand the Thick Database Paradigm

@BrynLite

Product Manager for PL/SQL and EBR at Oracle HQ

Not known for my brevity.Having trouble squeezing my own views—not necessarily my employer's—into 140 chars.Or, for that matter, 60 minutes.

Spring 2017


Introductoryremarks


• Discussion with

– Niels de Bruijn & Joel Kallman at DOAG

– Toon Koppelaars

– Steven Feuerstein, Dan McGann, et al

– Cary Millsap

–Marc Sewtz & Dan McGann (yesterday)

– etc., etc...

• The “commit in PL/SQL is bad” twitter storm—October 2016

• The Gerald Venzl, Tim Hall, et al “old farts brigade” accusation


Setting the scope


• Developers write software for a huge variety of purposes

• We need to set the scope for our discussion

• The best way is to think of a modern app like Moovit


Agenda


The case for implementing all business logic inside the database

- Modular design principles applied to applications backed by Oracle Database

- What is SQL, and how do you make it happen?

- The “hard shell” paradigm

- PL/SQL’s unique specific features for making SQL happen

Myth busting

- Data rules can be enforced by code outside of the database

- You can save database CPU and improve scalability by implementing business logic outside the database

- You can rely on robotically generated SQL

- You can change code in the database without application downtime

- There’s no tooling for PL/SQL

- You can’t provide each developer with a private sandbox for PL/SQL development

1

2


Setting the scene


• Large software systems must be built from modules. A module hides its implementation behind an interface that exposes its functionality. This is computer science’s most famous principle.



• For applications that use an Oracle Database, the database is the persistence module. The tables and the SQL statements that manipulate them are the implementation details. The interface is expressed with PL/SQL.




• Developers and end-users of applications built this way are happy with their correctness, maintainability, security, and performance.




• Developers and end-users of applications built this way are happy with their correctness, maintainability, security, and performance.

• But when developers follow the NoPlsql paradigm, their applications have problems in each of these areas and end-users suffer.


And yet…

Number of Programming Jobs Ranked by Language (Dice.com data) Summer 2015www.codingdojo.com/blog/8-most-in-demand-programming-languages-of-2015/


Modular design principles applied to applications backed by Oracle Database


what are the modules?


business functions matter


table designs can change


responsibility needs authority


encase the database in a hard shell


the framework alternative


NoAnything


What is SQL?

How do youmake it happen?


a SQL statement describes its intended effect


you need an if-then-else language to make SQL happen


how good is it at doing SQL?


where does it run?


The hard shellparadigm


commit

insert

delete

update

select


commit

insert

delete

update

select

sN

s5

s2

s4

s7s3

s1

s6


commit

insert

delete

update

select

ORDS

sN

s5

s2

s4

s7s3

s1

s6


-- primitive anonymous block statement

begin Pkg.Bulk_Insert(:Rows); end;


PL/SQL’s uniquespecific featuresfor making SQL happen


procedure p(Lo in t.c3%type, Hi in t.c3%type) is

begin

for r in (

select t.c1, t.c2

from t

where t.c3 between p.Lo and p.Hi

order by 1)

loop

Buffer_Row_For_Display(r.c1, r.c2);

end loop;

end p;


SELECT T.C1, T.C2

FROM T

WHERE T.C3 BETWEEN :B2 AND :B1

ORDER BY 1



begin

for r in ( -- cursor implicitly openedselect t.c1, t.c2

from t


order by 1)

loop


end loop; -- cursor implicitly closedend p;



begin

for r in (

select t.c1, t.c2

from t


order by 1)

loop


end loop;

end p; bulkification


native dynamic SQL – expressive – rarely needed


no make: the promise brought by static dependency tracking


every single artifact that implements the business functionsis in one managed universe: the Oracle Database


metadata for everythingstatic definitions

run-time behaviorhomogeneously available via SQL and PL/SQL

for mechanical analysis





DBA_Objects, DBA_Source, DBA_Procedures,DBA_Arguments, DBA_Identifiers, DBA_Dependencies,

DBA_Tables, DBA_Indexes, DBA_Constraints,DBA_Views, DBA_Sequences, DBA_Triggers,...





v$Sql, DBMS_Xplan, DBMS_Hprof,....


everything you’d ordinarily expect as a programmerSQL Developer, GUI debugging

compiler warnings (bad SQL aware)conditional compilation tests package globlals

and so on...


DeployingPL/SQL code changeswith zero downtime:EBR is the key


Oracle E-Business Release 12.2 does it


Salesforce.com does it


American Express does it


and so can you!


Empoweringeach developerto provisiontheir own databases


PDBs as sandboxes – snapshot clone


provisioning app with PL/SQL API from SQL*Plus or APEX


trash a test database and then

re-instate it in its pristine starting state

in minutes


difference in kind

becomes difference in degree


“Oracle Database Development Engineer” job role now well-defined


can: schema design, SQL (incl. execution plans), PL/SQL


need not know: RMAN, Data Guard, RAC deployment, etc


Conclusion


an application whose data isn’t persisted and retrieved correctlyis worthless

“it’s the data, stupid!”




protect your data inside a hard PL/SQL shellselect, insert, update, delete come only from PL/SQL

it’s the time-honored way




protect your data inside a hard PL/SQL shellselect, insert, update, delete come only from PL/SQL

it’s the time-honored way

performance and security matter toothe thick database paradigm ensures these


And now,stepping out of rôle,let’s look at somereal codereally running…


Internet-facing self-service app to manage your bank account

• Tables:– Account_Kinds– Account_Holders– Accounts– Transactions

...and so on...

• Business function: Transfer funds internally– insert a row into Account_Kinds– Honor the rules:

“can’t go into the red”“can’t xfer more than threshold amount in a calendar month”...and so on..


Switch to demo

reconciling apex and the thick database paradigm · reconciling apex and the thick database...

Documents