*** 1,6 ****
IBM has announced plans to release its Java-based SQL database
! engine "CloudScape" as an open source tool named "Derby". This
! page offers a comparison of Derby and SQLite.
*Zero-Administration*
--- 1,26 ----
IBM has announced plans to release its Java-based SQL database
! engine {quote: "CloudScape"} as an open source tool named "Derby". This
! page offers a comparison of Derby and SQLite. Additional information
! about Derby/CloudScape is available at
! http://www-306.ibm.com/software/data/cloudscape/.
!
! The information provided on this page was initially written based
! on a reading of the on-line documentation of Derby. Though th
! information is believed to be correct, the author is not a Derby
! expert and may have misunderstood parts of the documentation. If
! you find errors, you are encouraged to fix them.
!
! *Fundamental Differences*
!
! The basic idea behind Derby appears to be that it reads the entire
! database into memory and parses it into various Java data structures. All
! database I/O occurs on the in-memory image. When the database is closed,
! all the data is written back to disk. Thus the disk image is really just
! a serialization of the in-memory database representation.
!
! SQLite, on the other hand, operates directly from disk. It reads only
! those parts of the database file that it needs in order to carry out the
! requested operations.
*Zero-Administration*
***************
*** 15,27 ****
*SQL Language Support*
Derby supports all of SQL92. SQLite only supports a subset of SQL92,
! though the supported subset is very large.
! *Executable Size*
! The footprint of SQLite is less than 250KB. The footprint for Derby
is about 2000KB or about 8 time larger.
*Concurrency*
SQLite allows multiple simultaneous readers and a single writer.
--- 35,54 ----
*SQL Language Support*
Derby supports all of SQL92. SQLite only supports a subset of SQL92,
! though the supported subset is large and covers the most commonly used
! parts of SQL92.
! *Memory Utilization*
! The code footprint of SQLite is less than 250KB. The code footprint for Derby
is about 2000KB or about 8 time larger.
+ Derby appears to require that the entire database image be stored in
+ memory. SQLite keeps most the database image on disk and only loads into
+ memory that portion of the database that it is actualy using. One therefore
+ expects that the run-time memory requirements for SQLite will be much
+ smaller.
+
*Concurrency*
SQLite allows multiple simultaneous readers and a single writer.
***************
*** 37,45 ****
*Database File Size*
No data is currently available on the relative sizes of the database files
! for SQLite and Derby.
*Speed*
No data is currently available on the relative speed of SQLite and
! Derby database engines.
--- 64,83 ----
*Database File Size*
No data is currently available on the relative sizes of the database files
! for SQLite and Derby. One can guess that since a Derby database is a
! serialization of internal data structures that it is somewhat smaller than
! an SQLite database, primarily because the on-disk image of a Derby database
! does not need to support random access
*Speed*
No data is currently available on the relative speed of SQLite and
! Derby database engines. One can guess that after initialization Derby
! runs faster than SQLite since Derby is operating entirely out of memory.
! On the other hand, Derby should be very slow to initialize since it must
! read and parse the entire database file. In the balance, one would expect
! Derby to be faster in situations where a program opens a database and
! then use that database extensively for a long period of time, whereas
! SQLite would be expected to be much faster when the program opens a
! database, does one or two quick operations, then immediately closes the
! database again.
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|