Re^3: DBD::SQLite tuning

in reply to Re^2: DBD::SQLite tuning
in thread DBD::SQLite tuning

I understand all of that. You were asking "Why is this slow?" (which is the necessary precursor to "How do I make this faster?"). I replied "Commits are implied to be slow in SQLite."

I suspect that you are using SQLite correctly, but not for its intended purpose. It's like using Oracle for an online forum or BDB for a data warehouse. You could do that, but it wouldn't be recommended as best.

The person who claimed Foo is Nx faster than Bar is correct, for his/her needs. And, for your needs, Bar is Nx faster than Foo. We've all seen situations where a semi-tuned MySQL 4.1 database on a single CPU blew away an tuned Oracle 9.2 database running on a quad-Xeon. Yet, we're not going to claim that MySQL 3.x is faster than Oracle in all situations.

For your usage, BDB is clearly better. SQLite is probably better than BDB if the following is true:

Reads * LargeNumber >= Writes
Reads involve complex queries
Different reads may use different indices

Otherwise, it's probably best to use BDB.

Of course, I'm still wondering why SQLite is good when embedded MySQL exists. (Though the weird license is probably part of it ...)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

In Section Seekers of Perl Wisdom