*** 1,8 ****
! 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 the
--- 1,10 ----
! IBM has released 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 CloudScape is available at
!
! http://www-306.ibm.com/software/data/cloudscape/ ,
!
! and Derby at
!
! http://incubator.apache.org/derby/index.html .
The information provided on this page was initially written based
on a reading of the on-line documentation of Derby. Though the
***************
*** 12,36 ****
*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*
! Both SQLite and Derby offer zero-administration, embeddable SQL database engines
! that store all data in a single cross-platform disk file.
*Host Language Support*
SQLite is written in ANSI-C. It supports bindings to dozens of language,
! including Java. Derby is only available to applications written in Java.
*SQL Language Support*
--- 14,35 ----
*Fundamental Differences*
! Previously it said here that Derby reads the entire database into memory and parses it into various Java data structures, that is wrong. It works very much like a traditional database.
!
! So, I'm not sure what this part really should contain.
!
! *Overall*
!
! Both SQLite and Derby operates directly from disk. Only parts of the database file(s) that are needed in order to carry out the requested operations are read.
*Zero-Administration*
! Both SQLite and Derby offer zero-administration, embeddable SQL database engines. SQLLite stores all the data in a single cross-platform disk files, wheras Derby uses several files.
*Host Language Support*
SQLite is written in ANSI-C. It supports bindings to dozens of language,
! including Java. Derby is written in Java, provides JDBC access, local access (embedded) or remote access (tcpip), using JDBC, DRDA or ODBC drivers.
*SQL Language Support*
***************
*** 43,83 ****
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.
! Mutiple processes can have the database open simultaneously. Derby
! only lets a single process open the database at one time.
*Crash-Resistance*
An SQLite database will survive a program crash or even a power failure.
! With Derby, if you pull the power plug at the wrong instant, you risk
! corrupting the database. (Someone please verify this.)
*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.
--- 42,67 ----
The code footprint of SQLite is less than 250KB. The code footprint for Derby
is about 2000KB or about 8 time larger.
*Concurrency*
SQLite allows multiple simultaneous readers and a single writer.
! Mutiple processes can have the database open simultaneously.
!
! Derby can operate in two modes, either as simply embedded when it is available only to once process through direct JDBC connection, or that single process can act as a server taking connections from several clients. Derby has upgradable row-level locking, so high simultanious concurrency without much contention can be achived.
*Crash-Resistance*
An SQLite database will survive a program crash or even a power failure.
! Same for Derby, as it provides transaction logging, recovery.
*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.
!
! Their query operation is similar in function, relative speed of different queries depend on cache-utilization, query plan optimization and implementation.
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|