Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
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

2 Answers 2

up vote 3 down vote accepted

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).
share|improve this answer
    
Good points, thank you. –  vanna Jul 24 '14 at 12:45

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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