Take the 2-minute tour ×

We are developing a customized caching solution that will use a SQL Server database to store cached objects. The hosting environment of the application does not provide an "in-memory" cache such as memcached or app fabric so we must use a SQL Server database.

While most of the cached objects will be simple types (int, string, dates, etc) we will need to also store more complex types such as DataSets, DataTables, generic collections and custom classes.

I have very little experience with the .NET's native serialization and deserialization but I figure we will have to serialize the objects into some form (binary, xml, JSON, etc) to store it in the database and then deserialize it when we pull it out of the database. I would like to have some expert opinions on what the the "some form" should be.

We are using JSON.NET to serialize data into JSON for various AJAX requests. My initial thought was to serialize the cached data into JSON to store it in the database. However, I wanted to get a few opinions as to what would be best for performance and data integrity.

share|improve this question
ASP.NET has built-in caching support. Have you tried that? –  Andomar Feb 23 '13 at 18:57
@Andomar - the hosting environment the site is on uses a round robin type of configuration for load balancing and the host doesn't support AppFabric or offer any type of memory caching. The situation is more or less the developers verses the hosting environment in terms of making the best out of what we have. –  Chason Arthur Feb 26 '13 at 16:32

3 Answers 3

up vote 6 down vote accepted

All three of the serialization options you mentioned (binary, json or XML) are valid choices for a serialization format. There are many other serialization formats but the three you mentioned are the most common. As to choosing between the three, here are some of the considerations:

  1. If you store your data in a binary format in the database, it is not human readable if if you ever want to look at it via using Sql Server Management Studio or via a text editor. You would have to write some sort of deserialization tool if you wanted to manually peruse the data.

  2. Binary format will likely result in serialize objects have the smallest size, followed by json, with XML being the largest. As far as the actual size differences, that will vary with your data structures.

  3. As far as performance, binary serialization may be faster than json or XML. However, you would have to benchmark this with your data to see what the differences are.

  4. I think there are excellent .net libraries and BCL support for all three of the format types, so any choice should be doable.

So your choice would depend upon which factors are most important to you: CPU utilization, disk storage space, human readability, and/or personal preference.

We have used json extensively for serialization of our objects for storage in a database , using JSON.Net and we like it a lot. It is handy sometimes to manually view the data via SSMS, and json is significantly more compact for our data than XML.

share|improve this answer
But you can't really query JSON in SSMS whereas you can query XML. I'd prefer XML despite being larger. –  Icarus Feb 23 '13 at 19:13
Good point, @Icarus. If you want to take advantage of all of the advanced XML querying functionality in SQL Server, you should serialized to XML, especially if you can tolerate the additional storage size. –  Joe Alfano Feb 23 '13 at 19:30
Thank you for your help. We will take all of your points into consideration. Best. –  Chason Arthur Feb 25 '13 at 13:29

I won't repeat Joe's answer as he is dead on. I want to add that Binary Serialization does increase the complexity if you upgrade the classes. It is manageable but it takes a little work, and requires you to dig into the binary serializer. Where as with a text based approach you could migrate the data using other options (XML you could run XSLT's on it for example)

share|improve this answer
Thanks Josh for that point on binary serialization. If you go with binary serialization, you'd definitely have to consider that maintenance over the full support lifetime of your app –  Joe Alfano Feb 24 '13 at 23:35
@JoeAlfano Yep, I'm stuck with some binary serialized object graphs which are persistent entities. Talk about a pain....but I've managed to version them change object names and types and migrate them... –  JoshBerke Feb 25 '13 at 14:53

The cache must be small and fast, and I like to be more specific about what to use.

I suggest the protobuf-net is the same that SO use, I use it, and the speed together with the size is really good. At least on my tests is the smaller and faster.

We use it for the same reason (for cache), after we have try other serializations libraries, this was the faster and smaller in result. Now in a cache schema you do not actually need to see with your eyes whats is inside because is not a setup that you may need to change something because you did not fix yet the function for that.

If you like to see whats on the cache object you can make a simple function that prints it.

share|improve this answer

Your Answer


