Sam Tregar wrote:
> On Tue, 19 Sep 2000, Glenn Linderman wrote:
>
> > They are different. Neither is a mistake.
>
> How do you explain the fact that every SQL book I've ever seen has
> included copious text on problems concerning NULL?
I'm not sure what SQL books you've seen. The standard treatise on SQL 92, Jim
Melton's "SQL: A Complete Guide", doesn't seem to include copious text on problems
concerning NULL.
> Why do so many RDBMs
> implement NULL differently?
Please give examples of RDBMS's and how they implement NULL differently. There is
an ANSI/ISO standard for SQL prescribing the behavior of NULL. If you are speaking
of the interfaces supplied to allow other languages to deal with NULL because they
don't support the concept in the same way as SQL, tha problem results because of
the other languages not supporting NULL. Perl could get a leg up here by
supporting it. I cannot comment further until I see more details about your claim
that they are implemented differently.
> If you can't agree that NULL was a mistake
> you must at least realize that it's difficult for most programmers to
> understand.
I will go as far as to admit that a programmer that has never learned the SQL
language is unlikely to be familiar with the ramifications of supporting NULL...
it's semantics affect many different operators. If they jump to a conclusion that
NULL is "kind of like Perl undef" (or any other concept which has different
semantics altogether), then they will have difficulties each time they discover one
of the semantics of NULL that doesn't fit their assumption that NULL is the "kind
of like" that other concept. I recommend that programmer's learn a whole concept
before using it. I have had no particular difficulty grasping the NULL concept,
but I'm a sample of one, which has no statistical significance.
> > > Perhaps you could show an example using DBI where having NULLs mapped to
> > > undef is actually a problem?
> >
> > If one (you wouldn't, I suspect) wanted to write expressions in Perl that had
> > the same semantics as expressions in SQL, which could come in handy for
> > further manipulating data obtained from SQL, then mapping NULLs to undef
> > doesn't make that easier.
>
> That's not an example.
No, it's a general statement of a class of problem which is difficult to solve
without the concept of NULL.
> What you just described is actually a bad idea.
If your data must come from separate databases, and you need to further manipulate
it, it is actually an extremely good idea, that would allow Perl to fill an
extremely useful niche.
> If you want to program in SQL you know where to find it.
Yes, I do. Inside each database. But it is more difficult to access one database
from inside another. The support for such is varied and spotty, and not
standardized.
> Your code will
> be faster if it runs in the SQL server and you'll have the full "power" of
> SQL in your hands, NULLs and all.
The performance may vary, depending on which database, and whether the data is
accessible. Not all databases implement a procedural language today, although the
latest standard prescribes one, so it is coming.
> Do you want to do pointer arithmetic in Perl with data you get from C
> programs too?
No. Pointers are only useful inside the program that creates them. I must say
that's one aspect of Perl's pack/unpack that I don't understand: the "p" an "P"
codes... I would guess that they are only useful for the boundary code to help
convert C data into Perl data, because perl is implemented in C?
> > It is not a problem if all you do with DB data is retrieve and/or store. It
> > is only a problem if you want to do DB style manipulations of the data.
>
> Perl does not do "DB style" manipulation of data.
No, but modules written in Perl do want to do "DB style" manipulation of data.
This would be much simplified is Perl supported NULL.
> Adding NULL won't change that, you'll still be missing all that relational jazz
> that makes
> SQL actually usefull - various flavors of joins, grouping, limiting,
> indexing, etc. And no, I'm not suggesting that we add them.
You wouldn't. But adding modules that do joins, grouping, and other reporting
based on data from multiple databases would mesh nicely with the other reporting
applications Perl can already perform. I'll be glad to suggest that we add such
modules, although probably not to core, although someone has RFCd the idea of
making the core module set bigger and mentioned DBI as an example, so maybe such
modules would fit with that.
> > The semantics of NULL neither require nor desire warnings.
>
> There's the problem. It's not just my problem, it's a problem for a large
> portion of the users of SQL. NULLs just slide on by, masquerading as real
> values but behaving like invaders from another dimension.
That's not a problem. That's the definition of NULL semantics. If you wish to
maintain a mental block about the usefulness and validity of NULL semantics, feel
free. But there's no need for you to stop other people that find such semantics
useful to be able to use them.
> > If you want warnings, use strict and undef.
>
> Under your plan DBI would be modified to return NULLs, right? How would I
> "use strict and undef" then?
I'm not the author of DBI, but I would recommend this. If Perl adds NULL, and DBI
isn't modified, I'd write wrappers to convert DBI interfaces and convert undef to
NULL, as needed. If Perl adds NULL, and DBI is modified to return NULL for NULL,
instead of returning undef for NULL, then if you persist in your mental block, you
could write similar wrappers to convert NULL to undef, and use strict, and get
those semantics instead.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
