Storing "dynamic" data

A

Arokh

Centurion
Joined
Apr 11, 2006
Messages
124
Hi

I need to store "dynamic" data, which simply means:
Some fields might be not used or maybe a new datafield is added.

So if I create a class with every single field which might be needed,
I will most likely end up having a class where many fields are unused.

To counter this issue I've been using a somewhat custimized Dictionary(of String, Object) so I can use the Key in a Path like manner.
For example:
"File\Hash\CRC" => "6c2f28d3"
"File\Path" => "C:\"
etc...

I've been wondering if there are some other approaches to solve this problem.
 
[I hope I'm understanding correctly]

Have you ever tried XML Serialization? When it creates the XML for you, it will leave out XML tags for Reference-Type objects if they are left null. The drawback is that any Value-Type objects will remain with some default value (ie: Int always uses 0).

Hope this helps!

~Derek
 
I'm currently using Binary Serialization since XML Serializaion doesn't support the Dictionary class.

What I'm more interested in is the structure where the data is saved in than how it is saved.

Would you prefer a class where all fields are predefined although some fields might never get used or
would you use a class like a dictionary where you can dynamically add "variables"?
If you prefer the later, how do you store them?

OffTopic:
Is the deserialization & serialization faster in XML-Serialization then in the Binary one?

I'm currently de/serializing ~6200 entries of the same class and it takes about 2 seconds to deserialize.
 
I think that having a class with all the defined variables would be easier if you were to hand it off to another programmer, but it really depends on how your dictionary class works; I've never actually worked with a class based off of the dictionary before.

As for XML Serialization VS Binary Serialization:

InformIT suggests Binary is faster.
(http://www.informit.com/articles/article.aspx?p=29457&seqNum=3)

15 Seconds did an actual test and said Binary Serialization was 1,000% faster and Binary Deserialization was 380% faster.
(http://www.15seconds.com/issue/020903.htm)

So you're going to definitely have your advantage from using your Binary. I had misunderstood what you meant in the original post, I thought you wanted to be able to view everything. The advantage of XML Serialization would be if you planned on handing over the saved file for someone else to work with. Binary Serialization is .NET-Based, I believe.. so your PHP developers and Java Buffs wouldn't be able to do anything with it.

~Derek
 
Roughly how many properties are you looking at and how many of them would be used in a typical object? If there are a great deal of 'optional' properties then it may be worth considering a different approach.

Would it be possible to group related properties into classes of their own? e.g. a file class could expose a path property and a crc property. These could then be properties of the parent object - this would give a more obvious grouping of properties and still provide compile time validation of the syntax. e.g. variable.File.Path type of syntax.

If there isn't a common set of properties then you may find defining one or more interfaces that group the properties into a logical group and then having one or more classes that implement the relevant interfaces.

Without knowing more about the system and existing design though it is quite difficult to be sure what would work best, relying on runtime interpretation of strings might not be the best solution though.
 
There may be more than 40 properties.

Basically I took the solution you suggested.
I grouped the needed properties and the rarely used ones are stored into the disc.
In addition I created a property which can automatically get the information from the disc if needed.
Hence the creation of this topic: http://www.xtremedotnettalk.com/showthread.php?t=101403 :D

Since the serialized array of those object was getting rather big (80mb),
this also solved another problem, deserializing should go much faster now too.
 
Back
Top