--- jolz <[EMAIL PROTECTED]> wrote:
> > > 1. Actually it isn't true for all databases that transaction will
> > > speed up as much as SQLite does.
> >
> > So are you suggesting to not use transactions?
>
> In SQLite transactions are needed. In other databases, if there is no
> speed gain, there is no reason to use transactions (unless logic of
> application needs it).
The way I see it, there's no harm in using a transaction as it will
be faster on all databases (to varying degrees).
> > Batches are quite efficient. Just try to keep your batch sizes
> > reasonable. With 50,000 to 100,000 rows per batch, memory will not
> > be an issue.
> >
> > The SQLiteJDBC implementation reuses a single prepared statement
> > just as a programmer might do manually.
>
> Exactly. Just as a programmer might do manually. There is no speed
> gain using batch. So there is no reason to use more memory (100,000
> rows with only 3 int columns is above 1MB opposed to few bytes without
> a batch).
If you're already using java, a memory hungry programming language,
(with typical process memory usage already 4 times greater than an
equivalent C/C++ program) a few megs of additional RAM usage on modern
machines is insignificant. If you're using java in an embedded
environment, sure, I can see your point. But I'd recommend using C
in such an environment anyway.
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo!
FareChase.
http://farechase.yahoo.com/
--~--~---------~--~----~------------~-------~--~----~
Mailing List: http://groups.google.com/group/sqlitejdbc?hl=en
To unsubscribe, send email to [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---
