Serializing vs Database

Question

I believe that the best way to save your application state is to a traditional relational database which most of the time its table structure is pretty much represent the data model of our system + meta data.

However other guys in my team think that today it's best to simply serialize the entire object graph to a binary or XML file.
No need to say (but I'll still say it) that World War 3 is going between us and I would like to hear your opinion about this issue.

Personally I hate serialization because:

1. The data saved is adhered only to your development platform (C# in my case). No other platforms like Java or C++ can use this data.
2. Entire object graph (including all the inheritance chain) is saved and not only the data we need.
3. Changing the data model might cause severe backward compatibility issues when trying to load old states.
4. Sharing parts of the data between applications is problematic.

I would like to hear your opinion about that.

Answer 1

You didn't say what kind of data it is -- much depends on your performance, simultaneity, installation, security, and availability/centralization requirements.

• If this data is very large (e.g. many instances of the objects in question), a database can help performance via its indexing capabilities. Otherwise it probably hurts performance, or is indistinguishable.

• If your app is being run by multiple users simultaneously, and they may want to write this data, a database helps because you can rely on transactions to ensure data integrity. With file-based persistence you have to handle that yourself. If the data is single-user or single-instance, a database is very likely overkill.

• If your app has its own soup-to-nuts installation, using a database places an additional burden on the user, who must set up and maintain (apply patches etc.) the database server. If the database can be guaranteed to be available and is handled by someone else, this is less of an issue.

• What are the security requirements for the data? If the data is centralized, with multiple users (either simultaneous or sequential), you may need to manage security and permissions on the data. Without seeing the data it's hard to say whether it would be easier to manage with file-based persistence or a database.

• If the data is local-only, many of the above questions about the data have answers pointing toward file-based persistence. If you need centralized access, the answers generally point toward a database.

My guess is that you probably don't need a database, based solely on the fact that you're asking about it mainly from a programming-convenience perspective and not a data-requirements perspective. Serialization, especially in .NET, is highly customizable and can be easily tailored to persist only the essential pieces you need. There are well-known best practices for versioning this data as well, so I'm not sure there's an advantage on the database side from that perspective.

About cross-platform concerns: If you do not know for certain that cross-platform functionality will be required in the future, do not build for it now. It's almost certainly easier overall to solve that problem when the time comes (migration etc.) than to constrain your development now. More often than not, YAGNI.

About sharing data between parts of the application: That should be architected into the application itself, e.g. into the classes that access the data. Don't overload the persistence mechanism to also be a data conduit between parts of the application; if you overload it that way, you're turning the persisted state into a cross-object contract instead of properly treating it as an extension of the private state of the object.

Answer 2

It depends on what you want to serialize of course. In some cases serialization is ridicilously easy.

(I once wrote kind of a timeline program in Java, where you could draw en drag around and resize objects. If you were ready you could save it in file (like myTimeline.til). On that momenet hundreds of objects where saved, their position on the canvas, their size, their colors, their innertexts, their special effects,...

You could than ofcourse open myTimeLine.til and work further.

All this only asked a few lines of code. (just made all classes and their dependencies serializable) and my coding time took less than 5 minutes, I was astonished myself! (it was the first time I used serialization ever)

Working on a timeline you could also 'saveAs' for different versions and the 'til' files where very easy to backup and mail.

I think in my particular case it would be a bit idiot to use databases. But that's of course for document-like structures only, like Word to name one.)

My point thus first : there are certainly several scenarios in which databases wouldn't be the best solution. Serialization was not invented by developers just because they were bored.

1. Not true if you use XMLserialization or SOAP
2. Not quite relevant anymore
3. Only if you are not carefull, plenty of 'best practices' for that.
4. Only if you want it to be problematic, see 1

Of course serialization has besides the speed of implementation other important advantages like not needing a database at all in some cases!