I) Binding Variable, naturally, implicitly.
II) do set based process (100 rows array prefetch by default) to FOR LOOP.
III) debug.f : to Instrument the code
Compulsory PL/SQL APIs
Client application developers would have no direct access to tables. Not even for queries. All access would be provided by PL/SQL APIs (Include database Views).
I like this because:
- It removes the need for triggers as all inserts, updates and deletes are wrapped in APIs. Instead of writing triggers you simply add the code into the API. I loath triggers.
- It prevents people who don't understand SQL writing stupid queries.
All SQL would be written by PL/SQL developers or DBAs, reducing the likelyhood of dodgy queries. - The underlying structure of the database is hidden from the users, so I can make structural changes without client applications being changed.The API implementation can be altered and tuned without affecting the client application.
- The same APIs are available to all applications that access the database. No duplication of effort.
Our concept is "build the data API in the database, you call the data API".
Database API has been layered by different UI technologies over time.
All about API's. The applications don't do table level(select/insert/update/delete) stuff, the apps don't even really *know* about tables.
On top of database schema we have an API that does the data stuff.
In the application we call this API but have our own application logic as well
(only application logic is in the application, data logic is -- well, right where it belongs -- next to the data, waiting for the 'next great programming paradigm to come along')
- make software components modular
- software modules must carry out a very specific task
(and be very efficient at carrying it out) - each software module should be loosly coupled (to limit dependencies)
