RE: Universal database interface?
- From: "Powell, Mark D" <mark.powell@xxxxxxx>
- To: Oracle-L@xxxxxxxxxxxxx
- Date: Sun, 17 Apr 2005 13:24:35 -0400
As far as I am concerned a zero length string should be treated as NULL.
Strings are actully C language constructs. Just pointers to a storage
location. If there is no data at that location then the value is unknown or
non-existent. Isn't the definition of NULL, unknown?
What happens if you compare two empty strings? If stringA represents a
person's name and stringB represents an event can the two strings ever
logically be equal?
-- Mark D Powell --
-----Original Message-----
From: Mark W. Farnham [mailto:mwf@xxxxxxxx]
Sent: Saturday, April 16, 2005 9:17 PM
To: Powell, Mark D; Oracle-L@xxxxxxxxxxxxx
Subject: RE: Universal database interface?
You don't actually have to have procedures in the database (or even a
database) on the heterogeneous enabled server.
For each logical unit of work (LUW), you define an arguments list. Something
on the remote host receives the transmission hands it off for processing,
and tells you whether it succeeded and optionally returns a stream of data
in designated chunks, and your handshakes to "gimme more" or "enough
already."
Now of course it is very convenient if the database can handle procedures,
and implementing an Oracle service handler once would cover a most systems,
but if you lived within the datatypes common to Oracle and some other system
then you can define a logical data language (LDL), and logical data language
transforms (LDLXFORM) to generate the storage management on each remote
system, whether PL/I, Cobol, SQL/DS, VSAM, HISAM, DB2, RAMIS, INFORMIX,
SYBASE, or Oracle. Of course you'll need to be really careful if some of the
systems support null values in character storage and some interpret zero
length strings as nulls. Usually that means you have to swallow and agree to
interpret zero length strings as nulls. If you use Oracle in your support
list, that is the case unless you implement an elaborate system to know
which zero length strings actually are supposed to be empty strings and
which zero length strings are intended to represent NULLs.
(An unfortunate confusion of C null strings with the Null value, and there
was far too much data extant and programming complete in Oracle before
anyone important at Oracle groked the difference.)
Last time I wrote one of these interfaces to handle multiple databases
(1985-86), it was before serial communications were routinely clean, so is
is embedded with communications calls to DaTaPaSS so it would be far too
confusing to post.
Besides, even though DTSS was disbanded a long time ago, I think someone
still might own the rights. Possibly whoever recently bought Tally Systems,
which was a spinoff of DTSS.
Anyway, if someone really wants to invest in doing something like this, I
know I have a lot of notes that were my private property from the proposal
phase. They really do cover all the key issues, including some that are
somewhat obsolete (like terse instructions sets, and storing the queries on
the server to be referenced by number) due to the huge advances in
communications speed and automated error detection and correction.
Here is the problem: Oracle covers so many bases so well now that I doubt it
will ever be profitable to construct such a generic system.
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Powell, Mark D
Sent: Wednesday, April 13, 2005 9:23 AM
To: Oracle-L@xxxxxxxxxxxxx
Subject: RE: Universal database interface?
I think Tom Kyte of asktom fame wrote a response on this topic that said if
he was going to design a database independent application he would write a
web interface without any SQL calls. Instead all SQL would be encapsulated
in procedure calls that pass back cursors. This was you just write a
database specific procedure for each port: Oracle, DB2, SQL Server, etc....
Naturally this makes any database without stored procedures a non-choice for
the product.
I kind of like this design idea.
IMHO -- Mark D Powell --
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Mladen Gogala
Sent: Tuesday, April 12, 2005 10:54 PM
To: jkstill@xxxxxxxxx
Cc: jonathan@xxxxxxxxxxx; Oracle-L@xxxxxxxxxxxxx
Subject: Re: Universal database interface?
On 04/12/2005 08:11:41 PM, Jared Still wrote:
> ----
> "Many developers are happy to trade runtime performance for
> cross-platfor=
m=20
> portability."
>=20
> Maybe the developers are happy, because performance is the DBA's
>problem,=
=20
> right?
> ----
Spoken like a true architect! I welcome the standards and "database
independent applications". Those are the things that enable me to earn my
salary. Here is the law of Mladen: application that starts as a database
independent will have to become Oracle specific in order to achieve an
acceptable level of performance. My favorite toys are Object-Relational
Mappers (ORM), recently a genuine hit among Java duhveleopers. Allegedly,
they'll transform a relational query into a Java object which will then be
passed through BZZZTYIKL or some other abbreviation resembling Vogon poetry,
which will do an indescribable magic and, in particular, generate an
acceptable user interface. To attain sub-hour web response, I ended up
writing a ton of PL/SQL procedures implementing those "queries". When
application was finished, it was database independent, provided that the
database was supporting PL/SQL, external tables, BFILE fields, function
based indexes and UTL_SMTP package. That is my kind of unified approach and
my kind of database independence!
--=20
Mladen Gogala
Oracle DBA
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
