Group the parameters by categories and create a table for each of them, placing a record where the columns would have the value of each parameter of the category, that record could be changed at any time.

     

But in this case I was a little bothered to have independent tables with a single record in each one in a relational database (Microsoft SQL Server). Could this be considered a bad practice by evading the concept of relationship?

Not every table needs to have a relationship.

Can you say why it is bad practice? I can not. It looks like invention. It seems to be just a taste.

I'd rather not even separate everything into categories, I'd do them on the table itself. But it depends on the case.

Have you thought about keeping track of changes? Then each change would be a line. I'm not saying I need it, but it might be more useful than you think.

  

Create a single table with two columns (varchar on the two columns), one for the parameter name (unique in the table) and one for the value. This table would play the role of my Web.config and I could fetch the parameters by name.

     

This solution smells really bad to me! Because I can not type the different values of the parameters and I may have problems with a possible future bank migration, or if someone deletes the data.

This is so good that you even have a normal way to do it .

If you have problems with type create a column with it to decide what to do.

Just like you can have a column indicating which category it belongs to.

If you keep change history, it may be more interesting to do so.

But to be honest I prefer the first one, this is a case I would adopt if I had certain requirements that I do not usually have.

  

I thought if there could be some solution, such as NoSql for example, generating a file with data in the JSON structure that could store different types of parameters, and can be changed at any time by users.

Use another NoSQL database just because of this? This solution is terrible.

Why do you need JSON? I see no reason. For the categories? In most cases these parameters could be flat .

Current versions of SQL Server support JSON natively , the old ones can use a VARCHAR to store the JSON. Give a little more work a little.

Other solutions

You can put it in a file too, no matter what the format. I'd rather go into the database, but I see no reason why this would work worse than the DB unless you have some restriction on accessing the files directly.

In theory, you can even continue to use web.config and have it read to make changes to the application. You can control whether the application restart or not .

Not all requirements may have been reported. There may be a reason not to use one of the above solutions.

I propose the solution "4":

Use the Database already in the application, create a table with all parameters, with name and value, and in the value field, as String, you can use objects in JSON format too, / p>

If you need to know the type, add one more field to it, and in the routine that reads the parameters, interpret this field and parse the string for the desired type.

In case of missing parameter, consider assuming a default value if the field is not found in the table or is invalid.

  

I may have problems with a possible future bank migration, or if someone else deletes the data

You would also have problems if someone erases the data of users, customers, sales ... so that is not a reason against this approach.