为什么数据库版本控制不像应用程序版本控制那么重要？
我最近开始在我的所有项目 VB.NET 代码中使用 Kiln 源代码管理，我不知道没有它我是如何管理的！
我一直在为我的所有存储过程、UDF 等寻找数据库源代码控制。但是，我发现可用于数据库版本控制的功能并不像用于我的 Web 文件的那样多。
为什么数据库版本控制不像我的 Web 文件那么重要？当然，数据库中的所有编程都与代码隐藏文件和 .aspx 文件中的代码一样重要吗？
I've recently started using Kiln Source Control for all my projects VB.NET code, and I don't know how I managed without it!
I've been looking for a database source control, for all my stored procedures, UDFs etc. However, I've found that there is not as much available for database version control as there is for my web files.
Why is database version control not considered as important as my web files? Surely all the programming in my database is just as important as the code in my code-behind and .aspx files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
版本控制数据库对象很重要！
然而，也许它并不被认为那么重要，因为有些人仅仅将数据库视为帮助他们的工具？并且外部工具（通常）不受版本控制。
我发现很难管理的一件事是发布过程。现在我们使用连接到 svn 的 Red Gates 源代码控制。当发布时，我们对其余代码执行相同的操作：从一个分支合并到另一个分支。然后为了部署它，我们使用 sql Compare 在合并的修订版和实际数据库之间创建一个差异脚本。除了一些小怪癖和初学者错误之外，我认为这在没有停机时间（故意;））并且具有高速开发过程（大量发布）的环境中效果很好。
Version controlling database objects IS important!
However, maybe it isn't considered as important because some people see a database merely as a tool that assists them? And external tools (normally) aren't version controlled.
One thing I've found hard to manage is the release process. Right now we're using red gates source control connected to svn. When it's time for release we do the same as with the rest of the code: Merge from one branch to the other. Then to deploy it we use sql compare to create a diff script between the merged revision and the actual database. Aside from some minor quirks and beginners mistakes I think this works well in a environment where there is no downtime (purposefully ;)) and which has a high speed development process (lots of releases).
您可以在版本控制系统中维护数据库工件。
版本控制系统用于工件的版本控制，工件可以是程序代码或数据库。我们使用相同的 VC 来编写代码和数据库。
You can maintain your database artifacts in your version control system for same.
Version control system is for versioning of artifacts and Artifacts can be Program code or database. We used same VC for code and database.
VCS 旨在存储文本版本。它们可以存储二进制文件，但效率较低。而且DB状态本身不是文本，甚至不能直接存储为二进制。不过您可以存储 SQL 代码。
一种解决方案是存储完整的数据库转储（SQL 或二进制），另一种解决方案是存储将一个数据库状态更改为下一个数据库状态的 SQL 脚本序列。第二种方法可以在某些环境中自动化，称为迁移。如果你想要一个数据库有一个单独的特定的VCS，你可以认为迁移工具就是这样的VCS。
还有一些工具可以比较两个数据库状态并生成能够将第一个状态更改为第二个状态的差异。
VCS are designed to store versions of text. They can store binaries but it is less efficient. And the DB state itself is not a text and can't even be directly stored as a binary. You can store the SQL code though.
one solution is to store a full DB dump (SQL or binary), another - to store sequences of SQL scripts that change one DB state to the next one. The second approach can be automated in some environments and is there called migrations. if you want a separate specific VCS for a DB, you can think that migration tools are such VCS.
There are also tools that can compare two DB states and produce a diff that is able to change the first state to the second.
我想这取决于您是否将数据库更改（如模式更改、wRAR 提到的迁移）作为源代码存储库的一部分、通过使用其他工具以 sql 脚本或其他格式的形式进行管理，或者您是否考虑这一点作为数据库管理，并使用传统的备份/恢复方法来做到这一点。
根据我迄今为止的经验，虽然我不会认为数据库管理不那么重要，但与实际的代码更改相比，它发生的频率确实非常低。您的情况显然不同，但脚本文件和数据库工具的组合应该可以解决这个问题。
I suppose it depends on whether you manage the database changes (like schema changes, migrations as mentioned by wRAR) as part of source code repository, in the form of sql scripts or other formats through the use of other tools, or do you consider this as database administration, and do that using traditional methods of backup/restore.
In my experience so far, although I wouldn't consider database management as any less important, it does happen on a very low frequency as compared to actual code changes. Your case is clearly different, but a combination of script files and database tools should take care of that.
这就是现实。
数据库版本控制（即 DDL、DML，甚至是应用程序具有基本功能所需的必要参考数据的数据）与版本控制下的所有其他应用程序资产一样重要。 数据库永远不应该处于任何特殊的例外情况，即认为其资产（对象和必要的参考数据）不受版本控制是可以接受的。 曾经。
那么为什么会这样呢？简单的。保持简单管理这些资产的工具链并不总是符合标准（对于 SQL Server，在 Visual Studio 2008 之前，它没有随 Microsoft 的第一方工具一起提供），并且工具链因供应商而异- 按供应商计算。当这些工具链存在缺陷时，除非组织采取措施弥补该缺陷，否则该缺陷仍然存在。这是技术债务，当简化此操作的工具不存在或需要将第三方工具集成到开发工作流程中时，一些组织由于时间或（遗憾的是）技能而没有优先考虑它。
最糟糕的是试图将旧项目置于版本控制之下，因为除了向业务出售该价值之外，您还必须同时让每个人都与您一起踢球和尖叫。我不会不同意业务可能有更紧迫的直接需求，但将数据库资产置于版本控制之下需要在该列表中的某个位置，即使它的优先级较低。
没有任何借口。在这个问题上，我已经与足够多的项目经理、数据架构师、甚至首席信息官/首席技术官进行了斗争——我什至明确指出，我正在从事的每个项目都必须让批评者退出。 它需要完成，如果不这样做，则需要有一个业务同意的时间表来完成它。那些反对的人需要被枪杀，幸存者需要再次被枪杀。
Here's the reality.
Database version control -- that is to say DDL, DML, and even data for necessary reference data required for an application to have basic functionality - is as important as all other application assets under version control. Databases should never be under any special exception where it is considered acceptable for their assets (objects and necessary reference data) to not be under version control. Ever.
So why have they been? Simple. The toolchains to keep managing those assets simple haven't always been up to snuff (in the case of SQL Server, prior to Visual Studio 2008 it wasn't shipped with first-party tools from Microsoft), and the toolchains differ on a vendor-by-vendor basis. When those toolchains are deficient, unless the organization steps up to cover that deficiency, that deficiency remains. It's technical debt, and some organizations do not prioritize it due to either time or (sadly) skill, when the tools to make it easy don't exist or require integrating third-party tools into the development workflow.
The worst is trying to bring older projects under version control, since you have to bring everyone kicking and screaming with you all at once, in addition to selling that value to the business. I won't disagree that there may be more pressing immediate needs of the business, but getting database assets under version control needs to be somewhere on that list, even if it's a lower priority.
There's no excuse. I've fought more than enough project managers, data architects, and even CIOs/CTOs on this -- I've even made it a point to have detractors kicked off of every project I'm working on. It needs to be done, and if it's not there needs to be a timeline that the business will agree to in which it will be done. Those who argue against it need to be shot in the face, and survivors need to be shot again.