I have an application which consists of a couple thousand different object types, which represent items in a game. Each type has unique variables that need to be saved to disk. From a DB perspective, bigints, and text (ex: datetime would be converted to unix time stamp and so on).

Currently, all this data is serialized into one big string and is put into a text field. There are about 4 tables that consist of the major object types (Item, Mobiles, etc) but each of these type have many children types There are a few other fields such as the serial of the item, the type, and other "system" info.

I need to rewrite my code which handles the saving process, and this rewrite will make it possible to actually save all the values in their own independent fields. Some of these types could easily have 100 fields. Is there a point where there are just too many fields in a table? Am I better off just keeping it as it is? I would keep the 4 tables and they would just have every field to handle the various types, so a lot of them would be blank. Am I better off breaking it into a table per type (we're talking thousands of tables here)

Just wondering what you think would be more efficient, leave it as is, as a large serialized string or actually separate into separate fields. Also should I keep the 4 tables or have a table per object type?

This app is coded in C#. The SQL portion currently works fine, so I'm thinking of sticking with what I have, I just need to change the preprocessing portion that is unrelated to SQL, but figured while I'm there I could change the way it saves to SQL too.