看过其他问题并看不清楚答案.
我们是一个小型开发团队,致力于可以被描述为3个独立的前台"应用程序"(通过asp web的OnlineOrders,TradeManagement winforms app,ASP.NET ReportingSuite).
但无论好坏,这些应用程序中的每一个共享一个中央SQL2005数据库,我们称之为MainDB.它们都使用相同的Orders表结构,Users,Accounts等,每个应用程序都以某种方式使用了相当多的80%的对象.
在TFS中,我曾认为这3个应用程序中的每一个都是独立的项目,包括工作项跟踪,报告等等.似乎工作得很好,我们的"基于代码"的解决方案已经创建.
现在我试图了解如何将MainDB数据库导入TFS源代码控制.我看不出一个明显的方法来做到这一点.
问题是:我是否应该为MainDB创建数据库项目,将模式导出到项目中的脚本中,并将该数据库项目添加到每个TFS项目中的每个解决方案中？
或者我应该为我的数据库项目单独的TFS项目？开发人员必须打开MainDB数据库TFS项目和(例如)TradeManagement TFS项目开放以开发新功能(因为大多数新功能也会涉及一些数据库更改)？似乎非常沉重.
或者只是有一个名为"Everything"的大型TFS项目,并且其中包含代码项目的功能分支,数据库的数据库分支以及可能使用MainDB数据库的任何其他项目？(在img中,假设MainDB脚本位于'Database'文件夹中)
替代文字http://i26.tinypic.com/t7y4bb.png
等人,我很困惑.Codeplex似乎指出通过将所有解决方案放在大单解决方案中来保持简单.这可持续吗？
感谢您的回复,真的很棒.
将数据库视为API的想法很有意思,它就是这样的.数据库来自众多来源,一些内部,一些外部,一些应用程序获取通过另一个应用程序输入的数据.将其作为每个应用程序进出的API控制是一个非常有用的类比,谢谢你.
不支持依赖关系的成本是一个问题,但我认为我们可以足够自律地以有序的方式进行分支.应用程序代码库的分支可能比数据库更复杂 - 我们实际上只是希望源代码控制下的数据库以某种方式满足Sarbannes-Oxley审计要求.
我将不得不考虑更多.
db的水平分区不是我考虑过的.感觉太多的数据库对象被共享以便能够将其切割成水平块 - 我们在几个块中有相同的对象(表/ sprocs等),我认为这会使我们更加困惑.
tfs ×1
