| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Wrapping all tables with packages and scalability
I'm familiar with abstraction and Object Oriented design. This is
essentially what you are talking about. I like it, I am just concerned about
scalability. If REF Cursor opening and closing has overhead..., then there
is a concern at the very high end. I talked to some guys building an
application for the government. Its a 7 year life cycle that will be
deployed to 3 million people.( no idea on concrrency, etc... yet estimate is
500 GB database, but that is rough). Nailing down the architecture early is
essential. So these types of decisions could be critical 3-5 years from now.
We use this type of design for our Korn Shell ETL scripts. I like it alot. We have a concept of
Hosts (servers)
Targets (database instances)
Schema ( database schemas)
a .host file for each host, a .target file for each target, and a .schema file for each schema.
They are simply datafiles.
We have host_info, target_info, schema_info scripts that access these datafiles and grep them for information. Sort of like a select. This is very flexible. Since all you have to do is change the datafiles and never touch the operation scripts(_info). However, scaling is not an issue with this.
> It's not new. I worked with some folks 12 years ago who designed "CUD"
> packages in v7.0 PL/SQL. Each package was named "<table-name>_P" and
> consisted of functions named CREATE_ROW, UPDATE_ROW, and DELETE_ROW.
"CUD"
> was derived from the acronym "CRUD", but the "R" for "Retrieve" in that
> acronym was missing because Oracle didn't support REF CURSORs in PL/SQL at
> the time, so "R" was implemented by a layer of database views. Pity the
> poor lady who was tasked with maintaining this library, as she became
known
> as the "CUD Queen"... :-)
>
> Obviously, the concept of functional abstraction dates back to the origins
> of programming languages, and if you think about it, the SQL language
itself
> as well as low-level APIs like "dblib()", ODBC, JDBC, and OCI and
progamming
> languages like Fortran, LISP, and C are all implementations of the
concept.
> Otherwise, we'd all still be programming in assembler...
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sun May 02 2004 - 12:20:49 CDT
 |
 |