Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The requirements that are going to make the difference are the so-called "nonfunctional" requirements: capacity, reliability, throughput (and response time), availability, and security; this along with the software's own issues, like how easily it's available, how hard it will be to maintain software based on it, and so forth.</p> <p>Oracle is very fast, very robust, very well supported, and very expensive.</p> <p>MySQL is a good general choice with used widely. It can be configured for high availability and reliability (through mirroring and master-slave), it's well understood by a lot of programmers, and integrates well into a lot of platform software like Grails, Rails, and JBoss. </p> <p>Derby is good because it's very platform independent and a lot of people read Java easily.</p> <p>SQLite is fast, lightweight, and more or less native on Macs.</p> <p>... and so on.</p> <p>First, figure out what nonfunctional requirements are important, then choose a DBMS.</p> <p><strong>Update</strong></p> <p>Okay, following up your comment.</p> <p>With those numbers, let me ask first why a separate RDBMS at all? That's 1000 rows -- consider simply storing them in-memory, say in a collection of Collections that you serialize. </p> <p>If you really need a DB, say because you're using Rails, then you're not challenging ANY RDBMS -- it may be hard to choose because you're in a domain where <em>all</em> the choices are perfectly good. If so, then pick the one that's easiest to use and easiest to support, which is <em>probably</em> but not certainly MySQL, just because everyone uses it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload