john s wolter wrote:
I have an old Clipper DBF type application that has worked well but times
changed and changed long ago. The feature of this DBF, non-GUI, text
oriented, application is that it is mostly a list lookup application with
few DB changes. A separate Admin program does list management. The list is
about 10,000 people long. New requirements justify a rewrite of the
programs. Rewrite environments include Mono's C#, JAVA, Python, C++, et.
al. , all of which appear supported by SQLite bindings.
The Clipper application is very fast at these lookups which are at a
customer service desk where there is a queue of people impatiently waiting
in line. Using an incremental lookup text entry box the list quickly
narrows to just a few entries and then a quick cursor pick chooses the
correct record. Clipper DBF file indexes are a simple key-value and a
pointer into a DBF file's records.
>That is why these lookups are so fast.
A rather wide generalization, don't you agree? There's more to consider.
See this xBase file format
description<http://www.clicketyclick.dk/databases/xbase/format/>.
It is not a RDBMS as some stated in the past.
This is an old argument and perhaps boils down to semantics. The
specification for a true RDBMS are not met, but this is not to say that
it cannot do the job quite well. It does but the relating isn't built
into the Clipper engine. You have to code for it and make sure it's
enforced. The format is dead without something to drive it.
I am of the opinion that full SQL engine's set based extractions are too
slow and may not be suited to an incremental list lookup. However, SQLite
appears on the surface to be potentially faster than the its full SQL engine
peers. I also like the idea of linking a library into the application, that
also looks faster a first blush.
The fact that CA-Clipper applications (and expansions on the theme in
CA-VO) are not prevalent speaks well of newer, stronger, and more
efficient technologies. I worked in Clipper since Nantucket's first
product right through to the present CA-VO. In its day the format was
all we had and it was wonderful. But no transactions, no rollback, and
record/file locking had to be done manually. Horrors if something
crashed. Fun to recover a DBT whose associated DBF became mangled.
Certainly for simple and quick tasks a DBF format still works fine and
Clipper will run on just about any old thing. But I would never (now)
in my right mind use DBF in a production setting, just as I would hold
the same restriction to running a Windows server. There are far better
tools that require less time to develop and give greater all-around
performance. I know that's not what you asked :)
I am wondering if SQLite has features that could be used to make these
lookups just as quick? Can you point me , so to speak, in the correct
direction?
If you see a performance difference - and it's possible - consider what
SQLite does to protect your data and make access so simple. Protecting
data is not build into the DBF format (there are add-ons that will give
you some of this, but at considerable overhead). Plus, all the Clipper
stuff was (and probably still is) proprietary.
Comparing just the lookup method (both use b-tree's I believe) does not
take into account the entire picture.
If you're considering SQLite, you're on the path of a very good choice.
/m
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
