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

Also: * Embedded scenarios - Where usually it is required to use something smaller then a full fledged RDBMS. Db4o is an ODB that can be easily used in such case. * Rapid or proof-of-concept development - where you wish to focus on the business and not worry about persistence layer

Answer 2

K.I.S.S: Keep It Small and Simple

Answer 3

Matt Sheppard's answer is great (mod up), but I would take account these factors when thinking about a spindle:

1. Structure : does it obviously break into pieces, or are you making tradeoffs?
2. Usage : how will the data be analyzed/retrieved/grokked?
3. Lifetime : how long is the data useful?
4. Size : how much data is there?

One particular advantage of CSV files over RDBMSes is that they can be easy to condense and move around to practically any other machine. We do large data transfers, and everything's simple enough we just use one big CSV file, and easy to script using tools like rsync. To reduce repetition on big CSV files, you could use something like YAML. I'm not sure I'd store anything like JSON or XML, unless you had significant relationship requirements.

As far as not-mentioned alternatives, don't discount Hadoop, which is an open source implementation of MapReduce. This should work well if you have a TON of loosely structured data that needs to be analyzed, and you want to be in a scenario where you can just add 10 more machines to handle data processing.

For example, I started trying to analyze performance that was essentially all timing numbers of different functions logged across around 20 machines. After trying to stick everything in a RDBMS, I realized that I really don't need to query the data again once I've aggregated it. And, it's only useful in it's aggregated format to me. So, I keep the log files around, compressed, and then leave the aggregated data in a DB.

Note I'm more used to thinking with "big" sizes.

Answer 4

I would strongly recommend Lua as an alternative to SQLite-kind of data storage.

Because:

• The language was designed as a data description language to begin with
• The syntax is human readable (XML is not)
• One can compile Lua chunks to binary, for added performance

This is the "native language collection" option of the accepted answer. If you're using C/C++ as the application level, it is perfectly reasonable to throw in the Lua engine (100kB of binary) just for the sake of reading configs/data or writing them out.

Answer 5

There was a RAD tool called JADE written a few years ago that has a built-in OODBMS. Earlier incarnations of the DB engine also supported Digitalk Smalltalk. If you want to sample application building using a non-RDBMS paradigm this might be a start.

Other OODBMS products include Objectivity, GemStone (You will need to get VisualWorks Smalltalk to run the Smalltalk version but there is also a java version). There were also some open-source research projects in this space - EXODUS and its descendent SHORE come to mind.

Sadly, the concept seemed to die a death, probably due to the lack of a clearly visible standard and relatively poor ad-hoc query capability relative to SQL-based RDMBS systems.

An OODBMS is most suitable for applications with core data structures that are best represented as a graph of interconnected nodes. I used to say that the quintessential OODBMS application was a Multi-User Dungeon (MUD) where rooms would contain players' avatars and other objects.

Answer 6

Try Prevayler: http://www.prevayler.org/wiki/ Prevayler is alternative to RDBMS. In the site have more info.