Marc Britten wrote:
>
> I don't think that throwing out the old code is the way to go, however
> my thoughts with moving to SQL is
>
> a) it should be faster, with a good SQL backend it should improve
> caching etc.
This depends upon the size of the search database.
For a smaller site that uses Ht://Dig, an SQL backend will surely be
slower than a direct DB access method since you have much more overhead
with process communication and such.
Basically Ht://Dig is designed for such smaller web sites (e.g. homes of
small or medium sized companies) which often do not need an SQL backend
for other purposes. This would also make the setup of Ht://Dig for such
sites more complex.
> b) easier to integrate the same db w/ other tools, no need to port
> something w/ SQL to a different backend.
This is basically true. But there are some traps inside - not all SQL
engines have the same features or are as SQL92 compliant as others.
Some engines limit the size of the SQL transfer actions which makes
storing a larger document very depending upon the server used by the
Ht://Dig frontend.
> 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.
Ht://Dig has (afaik) no limitations for its use.
MySQL has a restricted licence.
I can see some disadvantages for the use of Ht://Dig in focussing on a
specific SQL server - especially one that has a restricted licencing
policy.
You may also want to keep an eye out for other platforms and therefore
need to support SQL engines on those, too.
> 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. this will keep the files clean of a bunch of ifdefs n whatnot, and
> 10 or however many extra source files shouldn't brake anybody's storage
> budget.
Such an abstraction layer should be very generic and provide interfaces
to
multiple SQL engines as well. Maybe there is a way to borrow from
PHP/Zend
code?
And these are not the only changes neccessary to move to a SQL backend,
but
you also have to modify the behaviour of the Ht://Dig configuration,
which
now is defining directories and files but should be naming SQL databases
and
tables in case an SQL backend is configured.
> Andrew Scherpbier wrote:
> >
> > I think that this is the right way to approach this subject: Why do
> > people want to use a SQL backend?
> > Please correct me if I am wrong, but it seems to me that some folks just
> > want SQL because they a) are familiar with it or b) already have a SQL
> > database setup.
> > What really needs to be described is the specific requirements that will
> > force ht://Dig to move to an SQL database backend.
> > Without that specification, the choice of moving to a SQL backend is
> > silly and a waste of time and energy.
It might make Ht://Dig better suitable for large scale applications than
it is now. As Marc pointed out, an SQL backend is able to increase the
performance of Ht://Dig both with indexing and with searching the index.
It might also help adding concurrent indexing/searching (i.e. searching
a database that is constantly updated), which is sure good to have on a
large search site. For smaller sites however, it would just be an
overkill.
just my 2cc,
Torsten
--
InWise - Wirtschaftlich-Wissenschaftlicher Internet Service GmbH
Waldhofstra�e 14 Tel: +49-4101-403605
D-25474 Ellerbek Fax: +49-4101-403606
E-Mail: [EMAIL PROTECTED] Internet: http://www.inwise.de
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
