6

I have some configuration values for an asp.net web app. They will be maintained by a system admin once the system goes live. Should I store these values in the database or in a config file? Is there a best practice for this sort of thing?

Aaron Palmer
  • 8,912
  • 9
  • 48
  • 77

7 Answers7

8

It's easy and convenient to create a robust interface to edit the values in the database.

It's less easy to create a good one for the config file.

So I would usually you want to store everything which you would like your users/administrators to be able to edit later in the database. Everything which only needs to be touched during serious changes like re-installation etc is better off in the config file.

Ilya Kochetov
  • 17,988
  • 6
  • 44
  • 60
  • Ilya, I believe it's not that simple. You are talking about extra pages, testing, security management. Did I mention testing? That takes time, effort and money. I would argue the config file has the "easy" and "convenient" advantages. You want the database option when: 1. administrators won't have access to the config file 2. There are multi-level security roles 3. The settings must be read by other applications, not just this ASP.NET application. In other words, in larger and more sophisticated situations, the config file is not sufficient. When it *is* sufficient, use it. What am I missing? – Concrete Gannet Dec 14 '12 at 01:15
3

I would always recommend database simply because you can build an Admin UI relatively easy and audit all changes with similar ease. Although you can accomplish the same with changes to a file, the database route with some sort of a Admin control area is always preferable. Especially when you want to know who changed what when.

Also in our environment, changing a config file if there was an error, involves the entire change management process approvals/etc., which is pretty painful. So if you take the time to incorporate configuration settings in a database I think it will work out better in the long run. Just my $0.02.

Ta01
  • 31,040
  • 13
  • 70
  • 99
  • Agreed, if auditing is essential, that's a reason for the database. If your change management process is different just because the conceptual information is stored in a file compared to a database, that process is flawed. – Concrete Gannet Dec 14 '12 at 01:16
1

I prefer a text config file, .ini style or XML style for these two reasons:

1 - You can put comments in the text file.

2 - Text editors have an "undo" command.

Corey Trager
  • 22,649
  • 18
  • 83
  • 121
0

Depending on the context of the config information, you could choose to leave it in the web.config or you could create maintenance tables for it in the database. I would typcially keep things more backend specific, like connection strings, ftp locations, usernames/passwords(for the application, not user permissions) in the web.config though.

I normally keep more relative information that relates to the information in the database rather than the application itself, in the database.

This is all loosely based though and not always the case.

thismat
  • 2,096
  • 17
  • 24
  • Updating the web.config causes IIS to recycle the site. – Aaron Palmer Oct 29 '08 at 20:55
  • Like I said, all depends on the context. – thismat Oct 29 '08 at 20:58
  • 1
    It is true that when you change the config file, the application reacts straight away. The next hit sees new and not old behaviour. It is *not* true that IIS recycles. ASP.NET uses the NTFS File Change notifications, so it is informed when the contents of the file change. That's much lighter weight than recycling IIS. – Concrete Gannet Dec 14 '12 at 01:02
0

I prefer to avoid databases if I can and I don't need the performance. If you need/have a database then I would say put as much as you can in one place. One thing to manage.

kenny
  • 21,522
  • 8
  • 49
  • 87
0

I think databases are a great place for configuration values for distributed applications where you want a users settings to be available to them no matter which computer they use.

Configuration values stored in files are very useful for computer specific configurations (such as if you use a mapped drive to identify a location and every user may have a different mapping, like a CD/DVD drive for instance).

If you don't already have a database for the application you're developing though, it might be overkill to have a database exclusively for application configuration.

Ian Andrews
  • 106
  • 8
0

I prefer a text .ini file. They are easy to edit, and easy to move around when your application moves around. Here's an example Setting class that you may find useful.

Community
  • 1
  • 1
Protagonist
  • 1,121
  • 1
  • 8
  • 12
  • Protagonist, I don't understand why you would do this at all. In principle, ini files and config files are similar: simple text files that can be modified with a text editor, Notepad is enough. The difference with config files is extensive support in the .NET Framework in the System.Configuration and System.Web.Configuration namespaces. So config files give you the virtues of the ini file idea, plus extensive infrastructure support. The *only* advantage I can see for ini files is a subjective opinion that the ini is more readable for human beings. Just practice reading XML! – Concrete Gannet Dec 14 '12 at 01:05