| 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: Universal database interface?
... 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.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On
Behalf Of Powell, Mark D
Sent: Sunday, April 17, 2005 19:25
To: Oracle-L_at_freelists.org
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?
-----Original Message-----
From: Mark W. Farnham [mailto:mwf_at_rsiz.com]
Sent: Saturday, April 16, 2005 9:17 PM
To: Powell, Mark D; Oracle-L_at_freelists.org
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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Powell, Mark D
Sent: Wednesday, April 13, 2005 9:23 AM
To: Oracle-L_at_freelists.org
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Mladen Gogala
Sent: Tuesday, April 12, 2005 10:54 PM
To: jkstill_at_gmail.com
Cc: jonathan_at_gennick.com; Oracle-L_at_freelists.org
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,=
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
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Sun Apr 17 2005 - 15:22:48 CDT
 |
 |