数据层应用程序项目是否会取代 Visual Studio 数据库版本中的数据库项目？
我只是稍微熟悉数据层应用程序的功能以及数据库项目在 Visual Studio 数据库版本中的功能。
这两种不同的数据库版本控制解决方案是否重叠？或者数据层应用程序功能是否完全取代了使用 Visual Studio 数据库版本和数据库项目的需要？
I'm only slightly familiar with the features of Data Tier Applications and what Database Projects did in the Database Edition of visual studio.
Are these two different overlapping solutions for database version control? Or does Data Tier Application functionality replace outright the need to use visual studio database edition and database projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
DAC 提供了一个应用程序模型，可以用作开发人员和 DBA 之间的接口。开发人员编辑模型，DBA 从模型进行管理/部署。例如，一旦构建或提取了模型，就可以将其部署到多个服务器。
将 .dacpac 想象为 .exe。开发人员构建一个 .exe 并将其交给某人。此时，如果开发人员不必担心 .exe 运行在哪里，那就太好了，因为 .exe 内部是一致的 - 它要么运行，要么不运行。为什么开发人员需要担心专门针对 2008、2005 或 Azure？只需开发应用程序模型，让 DAC 处理其余的事情...
拥有此部署工件还提供了一些新功能。示例包括版本化部署、确定自上次部署或升级以来是否有人更改了数据库的能力、在不同目标服务器中创建相同数据库的能力。
您是否喜欢管理各种数据库的升级脚本库？如果可以在任何时间点构建或捕获（提取）数据库的整个状态，那不是很好吗？
VS 2010 中的数据库应用程序项目混搭将在即将发布的以数据库为中心的开发工具中得到解决。投资 dbschema 或 DAC 不会影响前向兼容性。
DAC provides an application model which can be used as an interface between developers and DBAs. The developer edits the model, the DBA manages/deploys from the model. For example, once the model is built or extracted, it can be deployed to multiple servers.
Imagine the .dacpac as an .exe. The developer builds an .exe and hands it off to someone. At this point, it would be nice if the developer doesn't have to worry about where that .exe runs because the .exe is internally consistent - it either runs or it doesn't. Why should the developer need to worry about targetting 2008, 2005, or Azure specifically? Just develop the app model and let DAC take care of the rest...
Having this deployment artifact also provides some new capabilities. Examples include versioned deployments, the ability to determine if someone has changed the database since the last deployment or upgrade, the ability to create the same database in different target servers.
Do you like having to manage a library of upgrade scripts for your various databases? Wouldn't it be nice if the entire state of your database could be built or captured (extracted) at any point in time?
The database application project mashup in VS 2010 will be resolved in an upcoming release of database-centric developer tools. Investing in dbschema or DAC wont affect forward compatibility.
目前，数据库项目和数据层项目之间的区别在于部署点。如果您想创建 dacpac，您可以使用数据层项目。如果您想创建 .dbschema 和 sql 迁移文件，您可以使用传统的数据库项目。
据我所知，数据层应用程序预计将在未来的 SQL Azure 部署中发挥重要作用。
除非您专门关注 SQL Azure，否则我现在会使用数据库项目。这完全取决于您想要实现的目标。可能是 SQL 源代码控制（由我工作的红门公司）更适合你的需求。
Right now the difference between Database Projects and Data Tier Projects is at the point of deployment. If you want to create a dacpac, you'd use the Data Tier Project. If you want to createa .dbschema and sql migration file, you'd use the conventional Database Project.
As far as I'm aware, Data Tier Applications are expected to be important in future for SQL Azure deployment.
Unless you're specifically looking at SQL Azure, I'd use Database Projects for now. It all depends on what you're trying to achieve. It could be that SQL Source Control (by Red Gate, the company I work for) is more suited to your needs.
我相信 Visual Studio 数据库项目是针对开发人员的。
数据层应用程序面向 DBA。请参阅此博客了解细节。
I believe Visual Studio database projects are targeted at developers.
Data Tier Applications are targeted at DBAs. See this blog for details.