Good reasons NOT to use a relational database?

Question

Can you please point to alternative data storage tools and give good reasons to use them instead of good-old relational databases? In my opinion, most applications rarely use the full power of SQL--it would be interesting to see how to build an SQL-free application.

Answer 1

Plain text files in a filesystem

• Very simple to create and edit
• Easy for users to manipulate with simple tools (i.e. text editors, grep etc)
• Efficient storage of binary documents

---

XML or JSON files on disk

• As above, but with a bit more ability to validate the structure.

---

Spreadsheet / CSV file

• Very easy model for business users to understand

---

Subversion (or similar disk based version control system)

• Very good support for versioning of data

---

Berkeley DB (Basically, a disk based hashtable)

• Very simple conceptually (just un-typed key/value)
• Quite fast
• No administration overhead
• Supports transactions I believe

---

Amazon's Simple DB

• Much like Berkeley DB I believe, but hosted

---

Google's App Engine Datastore

• Hosted and highly scalable
• Per document key-value storage (i.e. flexible data model)

---

CouchDB

• Document focus
• Simple storage of semi-structured / document based data

---

Native language collections (stored in memory or serialised on disk)

• Very tight language integration

---

Custom (hand-written) storage engine

• Potentially very high performance in required uses cases

---

I can't claim to know anything much about them, but you might also like to look into object database systems.

Answer 2

CAP theorem explains it succinctly. SQL mainly provides "Strong Consistency: all clients see the same view, even in presence of updates".

Answer 3

You can go a long way just using files stored in the file system. RDBMSs are getting better at handling blobs, but this can be a natural way to handle image data and the like, particularly if the queries are simple (enumerating and selecting individual items.)

Other things that don't fit very well in a RDBMS are hierarchical data structures and I'm guessing geospatial data and 3D models aren't that easy to work with either.

Services like Amazon S3 provide simpler storage models (key->value) that don't support SQL. Scalability is the key there.

Excel files can be useful too, particularly if users need to be able to manipulate the data in a familiar environment and building a full application to do that isn't feasible.

Answer 4

BTree files are often much faster than relational databases. SQLite contains within it a BTree library which is in the public domain (as in genuinely 'public domain', not using the term loosely).

Frankly though, if I wanted a multi-user system I would need a lot of persuading not to use a decent server relational database.

Answer 5

Custom (hand-written) storage engine / Potentially very high performance in required uses cases

http://www.hdfgroup.org/

If you have enormous data sets, instead of rolling your own, you might use HDF, the Hierarchical Data Format.

http://en.wikipedia.org/wiki/Hierarchical_Data_Format:

HDF supports several different data models, including multidimensional arrays, raster images, and tables.

It's also hierarchical like a file system, but the data is stored in one magic binary file.

HDF5 is a suite that makes possible the management of extremely large and complex data collections.

Think petabytes of NASA/JPL remote sensing data.

Answer 6

In some cases (financial market data and process control for example) you might need to use a real-time database rather than a RDBMS. See wiki link