Hi Graeme,
I'm not trying to say that SQLite is better than Firebird. In fact I use
FB for larger database usage. What I was trying to say is that SQLite
has it's place and worth. I replied due to you thinking that SQLite was
half-baked and Michael saying that it is sloppy. I'm not trying to
flame, only present my view since I know that SQLite could be usefull to
pp out there.
Now to the issue of speed. We had a program that was written in DOS that
kept a record of all occurances in the customers equipment. I used a
homemade DB that recorded around 20K records per day. Last year we
upgraded part of the program to Windows and the DB was part of the
upgrade. I used firebird at first. When the program started the first
time at a client, it would convert the last 24 months worth of data. It
was taking around 80 minutes to convert one month. Before the project
was finished a decision was made to use SQLite. After converting we
discovered that the conversion of the DB took only around 50 minutes
with SQLite. I have made no query tests. This was purely writing to the
DB. By the way, the DB has 6 tables and 4 of the tables 8 indexes.
Querying is and was blazing fast in both DB's, I never compared.
- SQLite is easier to use. It's especially nice to be able to deploy
your app and easily create the DB at run-time.
We do this too (deployment and run-time creation) with Firebird - no
problems at all.
Hmm, maybe I haven't researched enough. I can create tables, but never
managed to create the DB. Maybe it has to do with Zeos that throws an
exception when I enable it without having a valid firbird DB. But I
would like to know how to do this
- SQLite is made for SINGLE application access. So my pascal program
will always read/write the expected types.
The same database application can easily switch between Firebird
Embedded and Firebird RDBMS - thus you have a great upgrade path to a
full blown multi-user system, if you application becomes more popular
and needs to scale upwards.
True, and for this and many other things firebird is far superior. But
often I don't have the need for this.
- Firebird embedded does not work in virtual machines when the DB is on
a network mapped drive. I have tested VMWare, Virtual Box and Virtual
> PC. (This can also be a plus since I use this fact to inhibit one of
> my apps to be run from a virtual box.)
I can't comment on this, but I can't see why not, if you for example
under Windows map the network share to a permanent drive letter. We
have done this with MS Access (.mdb database) for years. And MS Access
is a local database only system too. The other point being, if you
database needs to live on a remote location, why not simply switch to
Firebird RDBMS server - get the full multi-user treatment for free.
Already answered by someone else. Rats, there goes my virtual machine test.
- SQLite can be embedded without needing to distribute a DLL. (Although
I no longer use this feature)
I'd rather go with too much features (though I don't see why this is a
problem, just don't use those features), and a database that keeps
your data (integrity) in check.
Data integrity is not an issue. SQLite has no problems there. They are
simply not orthodox and you can (if you want to) access a number field
as text or try to access a text field as an integer. But you don't have to.
Andreas
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
