title: What place in TFS should I put my database project in?
body: <p>Have looked through the other questions and can't see a clear answer to this.</p>
  
  <p>We are a small development team, working on what could be described as 3 separate front-office 'applications' (OnlineOrders via asp web, TradeManagement winforms app, ASP.NET ReportingSuite).  </p>
  
  <p>However for better or worse, each of these apps share one central SQL2005 database, let's call it MainDB.  They all use the same Orders table structure, the Users, the Accounts etc., pretty much 80% of the objects are used in some way by each of the apps.</p>
  
  <p>In TFS, I had thought that each of these 3 apps as being seperate Projects, with the Work Item tracking, reporting etc that would give us.  Seemed to work fine getting our 'code based' Solutions created.</p>
  
  <p>Now I'm trying to see how I can get the MainDB database into TFS Source Control.  I can't see an obvious way to do this.  </p>
  
  <p><strong>Question is</strong>:
  Am I supposed to create a database project for MainDB, export the schema into scripts in the project, and add that database project into each Solution, inside each TFS Project?  </p>
  
  <p>Or should I have a separate TFS Project just for my database project?  And a developer would have to open both the MainDB database TFS Project and (eg) the TradeManagement TFS Project open to develop a new feature (as most new features will involve some db changes too)?  Seems very heavy handed.  </p>
  
  <p>Or is it common to just have one massive TFS Project, called 'Everything', and within that have feature branches for the code projects, and a database branch for the database, and any other projects that might use the MainDB database?   (in the img, assume MainDB scripts are in the 'Database' folder)</p>
  
  <p><img src="https://i.stack.imgur.com/96qmj.png" alt="alt text"></p>
  
  <p>etc.  Man, I am confused.    Codeplex seems to point to keeping it simple by putting all solutions inside on big single solution.  Is that sustainable?</p>
  
  <hr>
  
  <p>Thanks for the responses, really great.</p>
  
  <p>The idea of treating the database as an API is interesting, it is really like that.  The database is populated from numerous sources, some internal, some external, some apps get data out that was input via another app.  Controlling it as an API that each app dips in and out of is a very helpful analogy, thanks for that.  </p>
  
  <p>The cost of having no support for dependencies is a concern, but I think we can be disciplined enough to do our branching in an orderly manner.  The branching of the app codebase is likely to be more involved than the database - we really just want the database under source control in some way to satisfy Sarbannes-Oxley audit requirements.   </p>
  
  <p>I will have to think some more on this.  </p>
  
  <p>The horizontal partitioning of the db isn't something I'd considered.  It feels like too much of the database objects are shared to be able to chop it into horizontal blocks - we'd have the same objects (tables/sprocs etc) in several blocks which I think would confuse us further.</p>