I see no advantages to separating the databases, and several downsides.

• You’re forced to guess in advance what data will never change and which might change. Such guesses are virtually always wrong in some way.
• Additional programming and configuration overhead for dealing with two database connections rather than one.
• JOINs between data from the different sources are likely to be much less efficient than they would be in-database.
• Two different namespaces for tables mean that you run the danger of name collisions without the system warning you, promoting subtle misunderstandings on the part of the developers (even yourself).

As far as I know, it’s not a common practice.

Based on how much your static information is really static you can consider other options to decide where store the data, instead using a database.

For example, if the static data never change you can consider to use a Constants class:

public static class Constants{

     public const int MyConstantValue = 10;

}

The advantage of this technique is to be able to use the intellinse because it’s stored in an object.

var foo = Constants.MyConstantValue;

Another option is to use a simple file. For instance, usually with .Net Framework applications you can create an App.Config file where you can store values with a key:

<configuration>
 <appSettings>
    <add key="Setting1" value="Value1" />
    <add key="Setting2" value="Value2" />
 </appSettings>
</configuration>

I use for example the App.Config to store the Connection Strings to the external datasources (like the Database connection string).

Generally, it’s a good idea to store a static data in the database when you think it’s for most of the time a constant information, but you want to able to change it if you need it.

I see no advantages to separating the databases, and several downsides.

• You’re forced to guess in advance what data will never change and which might change. Such guesses are virtually always wrong in some way.
• Additional programming and configuration overhead for dealing with two database connections rather than one.
• JOINs between data from the different sources are likely to be much less efficient than they would be in-database.
• Two different namespaces for tables mean that you run the danger of name collisions without the system warning you, promoting subtle misunderstandings on the part of the developers (even yourself).

As far as I know, it’s not a common practice.

Based on how much your static information is really static you can consider other options to decide where store the data, instead using a database.

For example, if the static data never change you can consider to use a Constants class:

public static class Constants{

     public const int MyConstantValue = 10;

}

The advantage of this technique is to be able to use the intellinse because it’s stored in an object.

var foo = Constants.MyConstantValue;

Another option is to use a simple file. For instance, usually with .Net Framework applications you can create an App.Config file where you can store values with a key:

<configuration>
 <appSettings>
    <add key="Setting1" value="Value1" />
    <add key="Setting2" value="Value2" />
 </appSettings>
</configuration>

I use for example the App.Config to store the Connection Strings to the external datasources (like the Database connection string).

Generally, it’s a good idea to store a static data in the database when you think it’s for most of the time a constant information, but you want to able to change it if you need it.