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 us

Answer 1

One good reason not to use a relational database would be when you have a massive data set and want to do massively parallel and distributed processing on the data. The Google web index would be a perfect example of such a case.

Hadoop also has an implementation of the Google File System called the Hadoop Distributed File System.

Answer 2

There are a large number of ways to store data - even "relational databse" covers a range of alternatives from a simple library of code that manipulates a local file (or files) as if it were a relational database on a single user basis, through file based systems than can handle multiple-users to a generous selection of serious "server" based systems.

We use XML files a lot - you get well structured data, nice tools for querying same the ability to do edits if appropriate, something that's human readable and you don't then have to worry about the db engine working (or the workings of the db engine). This works well for stuff that's essentially read only (in our case more often than not generated from a db elsewhere) and also for single user systems where you can just load the data in and save it out as required - but you're creating opportunities for problems if you want multi-user editing - at least of a single file.

For us that's about it - we're either going to use something that will do SQL (MS offer a set of tools that run from a .DLL to do single user stuff all the way through to enterprise server and they all speak the same SQL (with limitations at the lower end)) or we're going to use XML as a format because (for us) the verbosity is seldom an issue.

We don't currently have to manipulate binary data in our apps so that question doesn't arise.

Murph

Answer 3

G'day,

One case that I can think of is when the data you are modelling cannot be easily represented in a relational database.

Once such example is the database used by mobile phone operators to monitor and control base stations for mobile telephone networks.

I almost all of these cases, an OO DB is used, either a commercial product or a self-rolled system that allows heirarchies of objects.

I've worked on a 3G monitoring application for a large company who will remain nameless, but whose logo is a red wine stain (-: , and they used such an OO DB to keep track of all the various attributes for individual cells within the network.

Interrogation of such DBs is done using proprietary techniques that are, usually, completely free from SQL.

HTH.

cheers,

Rob

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

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

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