What place in TFS should I put my database project in?

Question

Have looked through the other questions and can\'t see a clear answer to this.

We are a small development team, working on what could be described as 3 separate front-of

Answer 1

In this case I'd put database project into separate project and just reference it from other projects.

IMHO if your database (either single instance of database or just common database schema) is shared between multiple project, then you need to treat your database schema (or at least large parts of it) as an interface exposed to those project. This interface/API needs to be change controlled and versioned independently to any single project. So database becomes an external dependency to all of those projects, just as any shared library or server.

Now. You are using TFS. There comes a cost of having separate projects in TFS. TFS has its branching model based on single namespace with project tree. That requires a lot of care and discipline or you would mess up merges etc.

Add to that complete lack of support for dependencies between projects. If you want to change-control dependencies between projects you have to either branch a project as a subproject of dependent project (with all branching and merging tracking problems I mentioned above) or teach your build system to get the right versions from TFS all the time (which I find scary).

Notice that project 'Everything' will not help if each of its parts needs to be released/versioned separately. You mentioned 'feature branches' for subprojects, etc. It is going to be an even worse mess than separate projects which, at the very least, are explicit. If you all openly agree to maintain common database project, there will be no surprise later when you discover you need to negotiate each change to it among all your other project teams.

So, in the end, it's your decision. Are all the projects involved separate enough to version them as separate projects or not. Are they going to diverge or not. Do you want or need them to diverge at all? Is it worth the cost of additional work involved?

---

And on a completely different level. All you are talking about is partitioning your code base vertically into layers--here comes database project (with database schema etc), here data access, here business logic, etc....

Have you considered partitioning horizontally into domain level blocks, each block complete and backed up by its database schema. Your project would depend not just on common database schema but on one or more shared modules. And each of them would bring its own part of database scripts.

I'm just thinking here. I'm not really sure if that would be better or if it would even work out in practice. Anyone can share his or her opinion?