On Mon, 13 Dec 1999, Marc Britten wrote:
> a) it should be faster, with a good SQL backend it should improve
> caching etc.
Maybe. Believe it or not, but the Berkely code is pretty good in this
respect. IMHO, higher-level search caching is probably going to have a
greater effect and isn't SQL-related. I'm not discounting this point, but
I've had a hard time coming up with concrete examples where this will
happen. Complex boolean queries is about the biggest speed gain, plus
perhaps phrase searching. I'm probably wrong--give me some good
examples and I'll eat my words!
(Remember that Marcel and Loic's fantastic database wizardry will go
to nothing if we switch to SQL...)
For what it's worth, Google, the only large-scale saerch engine to open up
details on its backend, does not use SQL.
> b) easier to integrate the same db w/ other tools, no need to port
> something w/ SQL to a different backend.
Except we don't even have a good set of tools for working with the db
right now! The problem with the existing Perl scripts isn't that Berkely
is a foreign language (one could argue that it's easier for Perl than
SQL), but they can't decode the data itself.
> don't get me wrong I don't want to scrap the other backend, if people
> are happy w/ it as is, so be it, however people on cosource seem to be
> willing to give 300 dollars for MySQL capabilities by its self.
Granted. And I don't think there is something conceptually wrong with
saying "we'd like to offer flexibility in the backend." But some
people have said "switch to SQL" and I wonder.
> right now my thoughts are to keep 2 different sets of files in the
> source tree, one with Berkeley DB one using the abstraction layer for
> SQL.
I, for one, would be interested in a more detailed description of what
you mean here. Two sets of files sounds a bit like a fork--or do you
mean two copies of a small set of files?
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
