Geoff Hutchison wrote:
>
> 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...)
fraid I don't have a good example, that was just off the top of my head,
you could be right, I don't know too much about the Berkeley stuff
> For what it's worth, Google, the only large-scale saerch engine to open up
> details on its backend, does not use SQL.
good poing
> > 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.
Switch is way too harsh of a word, since you guys have obviously spent a
ton of time geting berkeley to work really well( and I do mean really,
some of the search times that I've seen are damn fine) there is no way
that one could just scrap it (or logically even think of scraping it)
for a new backend that is just being talked about right now.
> > 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?
2 sets of a small set of files, with the configure script writing the
make file to use the right ones. actually I don't know how small it
might be, anything that touches the DB classes as they stand right now
is what I'm thinking of, but mind you I've only spent 20 minutes or so
browsing/grepping the code for the DB stuff, maybe ifdefs would work
well, we will have to wait untill I can sit down and get my hands dirty
I guess.
I've got time this weekend hopefully to take a better look, then time
off before and after new years, so barring any major Y2K problems we'll
know more by then.
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
