Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Sqlite vs Metakit

265 views
Skip to first unread message

Tony

unread,
Oct 28, 2005, 12:54:41 AM10/28/05
to
I want to make a small database application with Tcl. I think Sqlite
and Metakit are good enough for my project. But is there any
performance test or comparison between them? I tried a little script to
test both of them, which looks like the following:

Sqlite:
while {[gets $fd line] >= 0} {
......
db1 eval {INSERT INTO t1 VALUES($i, $match, $x, $y)}
incr i
}

Metakit:
while {[gets $fd line] >= 0} {
......
mk::row append db.t1 no $i ch $match code1 $x code2 $y
incr i
}

Finally, I added 25236 records into these data files. I found Metakit
data file finished quickly, yet Sqlite data file was growing bigger and
bigger slowly after the script quit. Is Metakit better or I did
something wrong.
Thanks for any answers.

Tony

Torsten Reincke

unread,
Oct 28, 2005, 3:22:54 AM10/28/05
to
> I want to make a small database application with Tcl.
> I think Sqlite and Metakit are good enough for my project.
> But is there any performance test or comparison between them?

It depends a bit on the version of sqlite you use. Since sqlite 3 there
is no significant difference in performance as far as I could see in my
tests.

> Is Metakit better or I did
> something wrong.

You cannot generally say which is better. I would base the decision on
what you need in terms of functionality. If you want sql and easy join
capabilities, you should go for sqlite, but if you only want storage of
large amounts of data and perhaps just simple and fast tabular access
then metakit might be the better choice. I have often started with
metakit first and then switched to sqlite in my projects, when I
realized I needed complex query capabilitites on the data. Note
however, there are extensions for metakit providing sql-like queries,
though slower then.

Torsten

Arjen Markus

unread,
Oct 28, 2005, 3:43:09 AM10/28/05
to
Metakit has been designed to store timeseries and the like. It is very
flexible if you need to rearrange tables a lot - like combining columns
from different tables into one new table. It is also very suitable - by
design - for retrieving data in the order they went into the table
(quite useful for timeseries).

SQLite on the other hand is very suitable, as Torsten says, for
complicated queries. One thing to note is that inserting or updating
data into a SQLite database is best done via transactions: this means
that committing the data is concentrated in a few places, rather than
after each insertion/update. That makes quite a performance difference.

Regards,

Arjen

Torsten Reincke

unread,
Oct 28, 2005, 5:13:57 AM10/28/05
to
> One thing to note is that inserting or updating
> data into a SQLite database is best done via transactions:
> this means that committing the data is concentrated in a few
> places, rather than after each insertion/update.
> That makes quite a performance difference.
>
> Regards,
>
> Arjen

Oh yes, I forgot. Thanks Arjen for this hint. Tony, this will be much
faster:

Sqlite:
db eval begin


while {[gets $fd line] >= 0} {
......
db1 eval {INSERT INTO t1 VALUES($i, $match, $x, $y)}
incr i
}

db eval commit


Torsten

Ramon Ribó

unread,
Oct 28, 2005, 5:55:26 AM10/28/05
to

Hello,

inserts in sqlite are quite fast into a transaction: from 20000 to
120000
insert per seconds (of course, depends on what you are inserting and on
what
computer).

But the nicest capability in sqlite are the selects (to query the
data). They
can be really, really fast, specially with an adequate use of indexes.

The thing to consider is that you need to learn a new language SQL.
But, as you
know, learning new things is never bad for the health.

Regards,

Ramon Ribó

En Fri, 28 Oct 2005 11:13:57 +0200, Torsten Reincke
<rei...@typoscriptics.de> escribió:

--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com ram...@compassis.com
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 46

Tony

unread,
Oct 28, 2005, 6:19:26 AM10/28/05
to
Torsten and Arjen,
Thank you for so quick answers! Well, can I make a analogy that Sqlite
seems like Oracle (but lite and fast), and Metakit seems like DBase IV.
I have tried the way as Torsten showed. The result proves Sqlite can
perform as fast as Metakit. Thanks again!
Regards.

Tony

Tony

unread,
Oct 28, 2005, 6:32:14 AM10/28/05
to
Ramon,

I know a little of Sql. I think it's not difficult to learn the new
syntax, but the difficulty is Sql operations needs skills for best
performance, isn't it?

Regards,

Tony.

Pa_McClamrock

unread,
Oct 28, 2005, 6:45:38 AM10/28/05
to
On Oct 28, 4:55 am, Ramon Ribó?wrote:

> The thing to consider is that you need to learn a new language SQL.
> But, as you know, learning new things is never bad for the health.

Well, hardly ever--but wasting time, while trying and failing to learn
new things, can be bad for the health! Is there some good
documentation, tutorials, etc. (with SQLite or elsewhere) that makes it
possible to learn SQL very efficiently?

David McClamrock

David N. Welton

unread,
Oct 28, 2005, 7:47:51 AM10/28/05
to
Ramon Ribó wrote:

> The thing to consider is that you need to learn a new language SQL.
> But, as you
> know, learning new things is never bad for the health.

But once you learn SQL, you can use it for other databases as well...
say you decide you need a 'big' database - you can transfer most of your
knowledge to postgresql or oracle or whatever, modulo the peculiarities
of that implementation.

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

Torsten Reincke

unread,
Oct 28, 2005, 8:38:07 AM10/28/05
to
> I know a little of Sql. I think it's not difficult to learn the new
> syntax, but the difficulty is Sql operations needs skills for best
> performance, isn't it?

There is a FAQ here:

http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html

Although not written for Tcl, you will find the essentails there to
make your sqlite commands fast. Sometimes it's only the order of the
tables involved in a query, that make the difference ...

Torsten

Ramon Ribó

unread,
Oct 28, 2005, 9:10:38 AM10/28/05
to

Tony,

Another advantage of sqlite is that it follows quite closely
the SQL standard. So, it should be very easy to get you introduced.

The main differences are that sqlite is more liberal in the column
type (you can insert a text in an integer column) than other databases.
Also, it does not support advanced features like foreign constraints
and so on.

In practice, most people consider the manifest typing as a good thing,
except in edge cases like sorting and integer-real confusion, and the
implemented SQL should be enough for most database users.

Related to the performance, you need to be an expert, capable of
understanding
the sqlite opcodes, only if you really need to take most of complex
queries.
For many uses scenarios, it is only necessary to add an index to the column
that you will use in the "where" or the "order by" clause.

Finally, there is an sqlite mailing list that is very useful for
understanding
the library in detail.

Ramon Ribó

--

Donal K. Fellows

unread,
Oct 31, 2005, 10:32:05 AM10/31/05
to
Torsten Reincke wrote:
> Sqlite:
> db eval begin
> while {[gets $fd line] >= 0} {
> ......
> db1 eval {INSERT INTO t1 VALUES($i, $match, $x, $y)}
> incr i
> }
> db eval commit

Even better is this:

db transaction {


while {[gets $fd line] >= 0} {
...

db eval {INSERT INTO t1 VALUES($i,$match,$x,$y)}
incr i
}
}

Why is that better? Simply because the code works without you needing to
understand whether you are currently in a transaction or pollute your
code with baroque [catch] statements everywhere. It's just more Tcl-ish!

Donal.

0 new messages