Serializing vs Database Serializing vs Database database database

Serializing vs Database


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.


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!


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.