0

Say I am building a website that uses two different types of data :

  • Static : information that will hardly change, like movie awards or world countries names (I want fast access so no external API)
  • Dynamic : information entered by users

I have not written a single line of code yet. My static db is more likely to be quite large but will not change overtime. As for the dynamic db I have no idea yet but I might need scalability.

Should I use different databases in the long run ? Is it common practice to do so ?

  • 2
    The static data examples aren't as static as you think they are. – Pieter B Jul 24 '14 at 12:33
  • Correct, edited. By "static" I mean very few changes overtime. – vanna Jul 24 '14 at 12:39
3

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).
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.