RE: Universal database interface?
- From: "Lex de Haan" <lex.de.haan@xxxxxxxxxxxxxx>
- To: <mark.powell@xxxxxxx>, <Oracle-L@xxxxxxxxxxxxx>
- Date: Sun, 17 Apr 2005 21:18:38 +0200
... and of course I have to disagree here :-)
Mark, your explanation is probably the reason why Oracle treats the empty string
as a null -- but that doesn't necessarily mean it is the right thing to do!
when compared, two empty strings should be equal. there is no doubt about that.
a null value is not a value (but rather a marker) and it has no data type.
Your question: "If stringA represents a person's name and stringB represents an
event can the two strings ever logically be equal?" is a very valid one, though.
In that case, you are talking about two different domains -- and following the
guidelines of strong typing you cannot compare them in the first place. You may
be able to compare the string representations, but then you must use at least
one CAST operation.
kind regards,
Lex.
---------------------------------------------
Visit my website at http://www.naturaljoin.nl
---------------------------------------------
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Powell, Mark D
Sent: Sunday, April 17, 2005 19:25
To: Oracle-L@xxxxxxxxxxxxx
Subject: RE: Universal database interface?
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
