Im creating a "settings" functionality of sorts, unique per "account"

Ideally I'd create a new table, FK it with the Accs table with each Setting variable being a column

But im also inclined to just turn it into a JSON and not bother with N columns for it specially since arrays are involved in the settings

Could version it to ensure that if Settings change on code-level, old accs with old settings dont get fucked up

Now this is a pet project so im free to experiment, not bound by high level design documents

What do y'all prefer/recommend? JSON<->Settings Obj or plain old Table/column with FKs

Sounds like the perfect use case for a no-sql db.

Settings stored as json all the way. It's not like you'll be using the data outside of the context of the user record, so I don't see a need to make a dedicated table.

@Lensflare hmm .-. true, but a separate NoSQL just for settings seems like an overkill
If I do use It, will need to find more things to delegate to it

@cuddlyogre mhm, unless eventually I make it "organisation controlled selective-settings" but that's for another day

You have another option. If it is truly random data you likely don't have to be able to query on the values.
Then you can store it in your language native serialized format in a blob/binary column

@hjk101 Had to look it up if it's even possible ._. Apparently is https://stackoverflow.com/questions... damnn
I wonder if it's more CPU work to turn this binary into actual C# object vs deserialsing it from varchar/JSON-type

seems more apt for more complicated object types that wont need to be queried, will try to benchmark to see what's the break-even point

@azuredivay don’t do premature optimization ^^
Go for the simplest approach

Yeah I just wanted to give you the option because it's often easier or feels more correct.
If you have postgres there is jsonb but then that is not really standard sql. If that doesn't matter and json serialisation is simple and correct that might be the best option. Especially if the front-end or other consumer just needs it in json format (and perhaps even produces the JSON) you don't need to do anything with it at all and can just pass it on as is.

With PHP for example you have the whole array vs object stuff and there are a few other situations where JSON leads to information loss. Is that is the issue you really want your native language serialisation if possible.

Even if I wanted to support org defined settings I'd still use json, you can patch a json document with another. I hear good things about graph DBs, maybe if I were using something that supports that type of querying (postgres does but the ORMs I know don't) then it would be worth investigating actually expressing the tree structure of JSON in the DB. With regular SQL though, no chance.

We have a dedicated table with settings as columns... So that's probably the wrong way to do it