C# - Serializing vs Database

Question

Hi Guys, I belive 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 its best simply serialize the entire object graph to a binary or xml file. No need to say (but still i'll say it) that world war 3 is going between us and i would like to hear your opinion about this issue.
Personaly 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 inheritence 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,
Thanks,

Adi barda

Answer 1

See this Stackoverflow posting for a commentary on the applicability of XML vs. the applicability of a database management system. It discusses an issue that's quite similar to the subject of the debate in your team.

Answer 2

You have some good points. I pretty much agree with you, but I'll play the devil's advocate.

1. Well, you could always write a converter in C# to extract the data later if needed.

2. That's a weak point, because disk space is cheap and the amount of extra bytes we'll use costs far less than the time we'll waste trying to get this all to work your way.

3. That's the way of the world. Burn the bridges and require upgrades. Convert the data, or make a tool to do that, and then no longer support the old version's way of doing it.

4. Not if the C# program hands off the data to the other applications. Other applications should not be accessing the data that belongs to this application directly, should they?

Answer 3

For transfer and offline storage, serialization is fine; but for active use, some kind of database is far preferable.

Typically (as you say), without a database, you need to deserialize the entire stream to perform any query, which makes it hard to scale. Add the inherent issues with threading etc, and you're asking for pain.

Some of your other pain points about serialization aren't all true - as long as you pick wisely. Obviously, BinaryFormatter is a bad choice for portability and versioning, but "protocol buffers" (Google's serialization format) has versions for Java, C++, C#, and a lot of others, and is designed to be version tolerant.

Answer 4

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!

Answer 5

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 6

Just make sure you have a component that handles saving/loading state with a clean interface to the rest of your application. Then whatever choice you make for persistence can easily be revisited later.

Serializing an object graph to a file might be a good quick and dirty initial solution that is very quick to implement.

But if you start to run into issues that make a database a better choice you can plug in a new version with little or no impact on the rest of the application.

Answer 7

Yes propably true. The downside is that you must retrieve the whole object which is like retrieving all rows from a table. And if it's big it will be a downside. But if it ain't so big and with my hobbyprojects they are not, so maybe they should be a perfect match?