Reasons for & against a Database

Question

i had a discussion with a coworker about the architecture of a program i'm writing and i'd like some more opinions.

The Situation:

• The Program should update at near-realtime (+/- 1 Minute).
• It involves the movement of objects on a coordinate system.
• There are some events that occur at regular intervals (i.e. creation of the objects).
• Movements can change at any time through user input.

My solution was:

• Build a server that runs continously and stores the data internally.
• The server dumps a state-of-the-program at regular intervals to protect against powerfailures and/or crashes.

He argued that the program requires a Database and i should use cronjobs to update the data. I can store movement information by storing startpoint, endpoint and speed and update the position in the cronjob (and calculate collisions with other objects there) by calculating direction and speed.

His reasons:

• Requires more CPU & Memory because it runs constantly.
• Powerfailures/Crashes might destroy data.
• Databases are faster.

My reasons against this are mostly:

• Not very precise as events can only occur at full minutes (wouldn't be that bad though).
• Requires (possibly costly) transformation of data on every run from relational data to objects.
• RDBMS are a general solution for a specialized problem so a specialized solution should be more efficient.
• Powerfailures (or other crashes) can leave the Data in an undefined state with only partially updated data unless (possibly costly) precautions (like transactions) are taken.

What are your opinions about that?
Which arguments can you add for any side?

Answer 1

Databases are not faster. How silly... How can a database be faster than writing a custom data structure and storing it in memory ?? Databases are Generalized tools to persist data to disk for you so you don't have to write all the code to do that yourself. Because they have to address the needs of numerous disparate (and sometimes inconsistent) business functions (Persistency (Durability), Transactional integrity, caching, relational integrity, atomicity, etc. etc. ) and do it in a way that protects the application developer from having to worry about it so much, by definition it is going to be slower. That doesn't necessarilly mean his conclusion is wrong however.

Each of his other objections can be addressed by writing the code to address that issue yourself... But you see where that is going... At some point, the development efforts of writing the custom code to address the issues that are important for your application outweigh the performance hit of just using a database - which already does all that stuff out of the box... How many of these issues are important ? and do you know how to write the code necessary to address them ?

Answer 2

mySQL can now model spatial data.

http://dev.mysql.com/doc/refman/4.1/en/gis-introduction.html

http://dev.mysql.com/doc/refman/5.1/en/spatial-extensions.html

You could use the database to keep track of world locations, user locations, items locations ect.

Answer 3

From what you've described here, I'd say your solution does seem to be the better option. You say it runs once a minute, but how long does it take to run? If only a few seconds, then the transformation to relational data would likely be inconsequential, as would any other overhead. most of this would take likely 30 seconds. This is assuming, again, that the program is quite small.

However, if it is larger, and assuming that it will get larger, doing a straight dump is a better method. You might not want to do a full dump every run, but that's up to you, just remember that it could wind up taking a lot of space (same goes if you're using a database).

If you're going to dump the state, you would need to have some sort of a redundancy system in place, along with quasi-transactions. You would want to store several copies, in case something happens to the newest version. Say, the power goes out while you're storing, and you have no backups beyond this half-written one. Transactions, you would need something to tell that the file has been fully written, so if something does go wrong, you can always tell what the most recent successful save was.

Oh, and for his argument of it running constantly: if you have it set to a cronjob, or even a self-enclosed sleep statement or similar, it doesn't use any CPU time when it's not running, the same amount that it would if you're using an RDBMS.

If you're writing straight to disk, then this will be the faster method over a database, and faster retrieval, since, as you pointed out, there is no overhead.

Summary: A database is a good idea if you have a lot of idle processor time or historical records, but if resources are a legitimate concern, then it can become too much overhead and a dump with precautions taken is better.