At 09:14 11/09/2006, you wrote:
On Fri, 8 Sep 2006, Micha Nelissen wrote:
Eduardo wrote:
Here you have some benchmarks (posted in sqlite mail list, so "perhaps"
are biased)
http://sqlite.phxsoftware.com/forums/thread/622.aspx
How 'real-world' is importing 300 thousand records ? Aren't complex
select queries *much* more important ?
Yes, they are. And there sqlite fails miserably. I wrote a series of
articles, comparing several embeddable databases:
sqlite
mysql
firebird
advantage
nexusdb
And while sqlite had very good insert and simple select speeds, the speed
of complex queries (joining 2 tables) was a total disaster.
Well, SQLite has a little optimizer. You must optimize your SQL
commands "by hand" thinking in the way SQLite works, there are lot of
tricks for speed up SQL queries.
Plus, and this is really what killed it for me: it does no type checking.
You can perfectly store a string in an integer field in sqlite; making it
impossible to use properly with TDataset.
It can be done, but you can get weird errors because MyIntField.AsInteger will
raise an exception of some other app stored a string in the integer.
SQLite is typeless, as tcl (the author of sqlite is one of tcl
developers). If you are reading a value from a table i suppouse you
already know what is the table schema, and what datatype is on every column.
I never understood what the big fuss is with sqlite. It's easy, yes,
but not fit for enterprise use.
No, it's not for enterprise use. It's for embedded use on other app,
where that app controls the database. It's not a c/s database engine
and is not designed as one, it was designed for embedded. If you want
to develop a game and need a script language for it, will you use
perl? or visualbasic ;) ? no, you will use a script language designed
as embedded, as lua or even ruby. Perhaps they lacks a lot of
features perl or python has, but it's more less complex to configure,
install, use, etc.... The problem is when someone wants to use sqlite
as oracle, postgresql, db2 etc... replacement, and sometimes someone
ask for "how to do it" in the mail-list.
SQLite isn't easy, it's easy if you don't care about speed, but if
you want to sqeeze all it's power, you must tune it a lot. Usually
you don't generate dynamic queries, you know what queries to do and
must optimize queries and precompile them (so don't need to
parse/optimize), tweak with options, manage carefully threads, all of
it knowing how sqlite works internally.
For example, we use SQLite in an embedded device, all queries are
hand optimized, use a ramdisk for data storage and gigabit ethernet
for I/O. Adding SQLite to the device is a minor change to the
linux.os file to create uclinux.os. All works fine, and system + app
(sqlite included) fits on 512 kB sram, using dram as ramdisk for db
file and temp. Other dbengines must be ported, perhaps will not work
under uclinux and of course, are bigger than sram limit.
Other example, you have a tiny http server (or gopher, or whatever)
in 200KB, and want integrate a database, you can use mysql, but mysql
only is bigger (5-6MB? more?) than the rest of your app, so, do you
really need mysql features? Pollute even more the .dll/.so hell?
Surely not, just add SQLite and compile statically, you'll get a
400-500KB app (one file) and only a database file.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Scientists have shown that the moon is moving away at a tiny yet
measurable distance from the earth every year.
If you do the math, you can calculate that 85 million years ago the
moon was orbiting the earth at a distance of
about 35 feet from the earth's surface. This would explain the
death of the dinosaurs. The tallest ones, anyway.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
