On May 5, 2005 20:03, Dave Rolsky wrote:
> The set _is_ data!
Sure, just as a procedure is data itself. This is data:
sub sum { return shift + shift; }
What's the difference between code and data eh? Is this data?
sub closure {
my $data = shift;
return sub data { return $data; }
}
Where is the distinction between data and not data?
... ok, now that we got the argument "this is data" out of our way, let's
focus on why one would want to put a particular kind of data in a DBMS or
not. The whole purpose of a DBMS is *quick retrieval*. That's it. Otherwise,
you might just as well use flat unindexed files.
Is there any gain in putting the recursion function in the DBMS? No. It's just
as slow as doing it in the application. Moreover, it's bad design-wise
because the DB server is optimized for doing DBMS stuff, not for doing
application-stuff. And the hoops one must jump through to store the recursion
procedure in the DBMS should be a clear warning to anyone wondering if it's a
good idea to do so.
> But generally speaking, storing sets as scalar data in the DBMS is totally
> legit. The fact that these sets can be infinite certainly makes things
> harder, but it doesn't mean that it shouldn't be done.
It's the whole point. Storing an infinite set in a DBMS means that you can't
index it. The DBMS loses its appeal because then it's not any faster than
doing the search in the application. See above.
What you're doing when creating views is in fact storing *functions* in the
DBMS. They also must be serialized somehow, so that the server can put them
on disk. In the end, it's equivalent.
> I do wonder how hard it would be to at least implement a _finite_ set as a
> first class data type. In Postgres, Perl is one of the languages you can
> use for server side programming. I haven't tried implementing a data type
> in Perl, but now I'm quite curious.
I think it would be best to have a high-level abstraction of a set stored in a
dabase not on the DB side but on the application side. Let the DB server
handle the data, and let the application handle the logic. It's easier,
pragmatic, and you can do it in less than half an hour.
> - Bound the set at some ridiculously far future date (y3k) and store that
> bounded set.
That's partly what I did in Chronos (chronoss.sf.net). However, I was dumb at
that time and for me "ridiculously far future" was 5 years. *doh!* ;)
--
Simon Perreault <[EMAIL PROTECTED]> -- http://nomis80.org
