Changes

Jump to: navigation, search

Relational database comparison

2,136 bytes added, 22:43, 22 December 2010
no edit summary
*many "traditional" relational db things are lacking.
*while tools exist they aren't as fleshed out and solid as the mysql ones.
*there may be some limits on size mostly due to ram and rom limts. [http://www.sqlite.org/limits.html Limits In SQLite] Since the whole db doesn't need to be loaded on reads and rights these limits should be far larger than for bsddb.
=MySQL=
*far better tools for management and reporting
*a true enterprise level database capable of handling serious loads
*far more is built into the db. ie auto incrementing fields, stored procedures and on and on. (sqlite may not even have triggers but I can't remember)
*far more extensive user base and support.
*install size (bloat)
*an actual server to setup run and maintain.
** there are tools that can do this automatically though and make things almost none existent for an end user. also the embeddable mysql might be an option.*may be difficult to manage / share multiple databases. more difficult but very do able. maybe not even that difficult. it would should just take some planning. =MySQL Embeded=Needs to be looked at, may be more powerful than sqlite but easier for end users than full mysql = Comparing BSDDB to SQLite = A sqlite shelve interface for Python:http://bugs.python.org/issue3783 From http://www.sqlite.org/cvstrac/wiki?p=SqliteCompetitors:SQLite versus Berkeley DB: <pre> Berkeley DB (BDB) is just the data storage layer - it does not support SQL or schemas. In spite of this, BDB is twice the size of SQLite. A comparison between BDB and SQLite is similar to a comparison between assembly language and a dynamic language like Python or Tcl. BDB is probably much faster if you code it carefully. But it is much more difficult to use and considerably less flexible.  On the other hand BDB has very fine grained locking (although it's not very well documented), while SQLite currently has only database-level locking. -- fine grain locking is important for enterprise database engines, but much less so for embedded databases. In SQLite, a writer gets a lock, does an update, and releases the lock all in a few milliseconds. Other readers have to wait a few milliseconds to access the database, but is that really ever a serious problem?</pre>   A company that justifies a switch from BSDDB to SQLite; see http://www.tribler.org/DatabaseMigration: Oracle's description of BSDDB; see http://www.oracle.com/database/docs/Berkeley-DB-v-Relational.pdf. Excerpt: <pre>Berkeley DB Offers APIs, not Query Languages  Berkeley DB was designed for software developers, by softwaredevelopers. Relational database systems generally provide SQL accessto the data that they manage, and usually offer some SQL abstraction,like ODBC or JDBC, for use in applications.</pre> What BSDDB is not: http://pybsddb.sourceforge.net/ref/intro/dbisnot.html [[Category:Developers/General]]

Navigation menu