Friday, October 27, 2006

Data API -- Data access and process interface

Some other2 reasons to implement Database API
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.
Anything that generates SQL on-the-fly worries me, not just Java. I want to be able to cut and paste the SQL, not try and capture or trace it during a run.

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')

  1. make software components modular
  2. software modules must carry out a very specific task
    (and be very efficient at carrying it out)
  3. each software module should be loosly coupled (to limit dependencies)

No comments: