Database Code in separate Solution from Application Code?

This is more of a best practice question...

Which is best practice for organizing source code and database code?

a. Store source code and database code in separate projects, but in the same solution
b. Store source code and database code in the same project
c. Store source code and database code in separate projects and separate solutions

My thinking is A or B is fine for smaller projects, but when they get large it may be best to allow both the application and database to grow separately? Particuarly C may be the best choice if you use branching?

If you branch your source code, you may not want to merge your database code back at the same time. If you keep source code and database code in the same solution this locks you into a corner.

Thoughts?
Tagged:

Comments

  • Clearly, it depends is the opening statement here.

    I prefer them in the same solution but different projects. Two reasons for this. One, having them in different projects makes it easy to work on them separately as needed and reduces their overall footprint. If you don't need the app code (or the database code) you don't have to have it. Two, because they're in the same solution, you can lable and/or branch them together. It's really important, in my opinion anyway, that what gets released to production from either the database or the app code is marked and labeled together so that you always know which version of which you're deploying. This makes rollbacks, provisioning and oh, so many other processes, safer and more accurate.

    You can absolutely get into a dance around the details, but that's my 1.5 cents worth.
Sign In or Register to comment.