On Mon, 13 Dec 1999 [EMAIL PROTECTED] wrote:
> old Berkeley DB files into SQL database. Trying to have a program able to
> handle both will lead to *very* hairy code.
Yes, it probably would be very hairy.
> No, the semantic is too different. In fact you could easily emulate
> Berkeley DB behaviour with SQL database. But that's not why you want a SQL
> database. You want to benefit from its versatility and ease of use. The
> nightmare will be to continue Berkeley DB compatibility while adding
> functionalities using SQL facilities. How do you emulate
> select * from table where value < 20 and string like "%foo" with Berkeley DB ?
> Surely you can, but at the expense of many lines of code.
Personally I worry about this. I think that while many people want to see
a SQL backend, there shouldn't be a dependency on installing SQL. The
Berkeley DB is fairly lightweight, installed on many systems already, and
fairly robust.
Yes, I agree that you don't want to emulate Berkely DB behavior with a SQL
database. However, we have much of the code for advanced features like
ANDs and ORs and LIKE in the code already. Moving to SQL would simplify
it, but should we just throw out this code?
(My answer would be "no, we should see what features from SQL we would
*need* and think about how hard those would be for Berkeley DB with what
we have now.")
-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
