C#, SQL: Storing arbitrary user data in a database as serialized binary

Question

Would you consider it bad practice to store various user data in a database as serialized binary? Is it a good, bad or really ugly idea?

I'm talking about pretty much arbitrary things, like the last splitter distance on a form, the last value in a search text box, prevously selected checkbox indexes, et cetera. Things that should be remembered that is not critical if it is forgotten.

I kind of like it since I would then only need one table with for example four columns: userid, source, key and value. And if I create a nice wrapper class to save and load values to this table things could work pretty nicely. For example I wouldn't have to fix the database whenever a new kind of setting comes in to play.

It would of course not work with searching and ordering and things like that, but that wouldn't be needed anyways since you would only access those key value pairs directly from their index (user id + source + key). The columns would also not be human readable, but again that wouldn't really be a problem. The data would be data that could be cleared out without much problems.

Any feedback on this idea? Is it an awful one? Is it a good one? Have you done something similar?

Answer 1

Since you are not searching, it would not be a bad idea - it is a opaque container for miscelaneous user data, and as you said it doesn't contain any critical information. And you are correct, you don't need to change the database to support a new configuration of settings.

Answer 2

Hi Svish,

I have just remembered that i have read regarding the ASP.NET 2.0 Profile API.

Let me quote from the MSDN

The ASP.NET profile feature associates information with an individual user and stores the information in a persistent format. Profiles allow you to manage user information without requiring you to create and maintain your own database. In addition, the ASP.NET profile feature makes the user information available using a strongly typed API that you can access from anywhere in your application.

You can store objects of any type using profiles. The profile feature provides a generic storage feature that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner.

Regards,

hadi teo

Answer 3

I use this all the time, because our objects are very customized per client / installation. This way I can add & remove properties without having to update the database.

I need about 200-300 properties per row. I have found that this approach gives me good flexibility.

I always include version number in my binary structure. So I know what data I can retrieve from it.

On some sub-object I also include the typename, so I can store objects from an inheritance tree. (I hope you understand what I mean).

Answer 4

It would be better if you go for XML serialization and not binary serialization. As in the former case, you need not take extra care for backward compatibility as your class evolves over the time.

Answer 5

Just wanted to add in a contrarian voice to the discussion:

By putting in serialized objects, you lose visibility to the data (obviously), but you also make it platform dependent. By keeping things in relational tables, data now can be read by any client you choose. If, in the future, you decide to change (or even just add a different one) then you lose the ability to reuse that same data. Keep the client and the data separate.