[tigershark]

If you use an hammer to kill a mosquito obviously it's a bad idea. The hammer is useful to put a nail in the wall. In my current job I introduced a configuration store based on serialization. Obviously, instead of storing everything in a blob, I created a table with some generic string id columns and a generic key that is an object serialized in JSON and a value that is the configuration object serialized in JSON. In this way I can have the best of both worlds, a generic configuration store that is also indexed on the string ids and searchable on the generic key.

[mattmanser]

The article is not talking about config files, which is one of the few valid reasons to do this, as with a config file you're almost always going to just want the whole thing once at initialization.

And even then, only if there's loads of config values. If you've only got 5 or 10, that solution is bad.

The article is implicitly talking about business objects.

[tigershark]

I never mentioned config files. The article explicitly states: "A good example of this optional nature of data is user preferences – you only really need to store the settings that differ from the default values." User settings is a good candidate for a configuration object in the configuration store that I built. The primary id will be the user id, the secondary id the machine name (if the system needs to support different configurations on different machines) and the rest will be a CLOB containing the JSON serialized user configuration.

[jb613]

> and a value that is the configuration object serialized in JSON

It all depends on the data, but if it's not simple, then serialized JSON values would generally incur performance hit for search operations. Breaking out the data into separate columns could be better indexed.

[tigershark]

No, there is no whatsoever performance hit because the identifiers are in separate columns in the same table, and they can be indexed normally. There will be a performance hit if for some future requirement all the ids column are exhausted, they start using the generic key with complex serialized objects AND they want the generic key to be searchable. At that point they can simply add another id column if it is really necessary.