我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我通过编写脚本输出所有对象(表定义、索引、存储过程等)来源控制数据库模式。但是,至于数据本身,只需依赖定期备份。这确保了所有的结构更改都被正确的修订历史记录捕获,但不会在每次数据更改时给数据库带来负担。
其他回答
数据库本身?没有
创建它们的脚本,包括静态数据插入、存储过程等;当然可以。它们是文本文件,它们包含在项目中,像其他东西一样签入和签出。
当然,在理想情况下,您的数据库管理工具可以做到这一点;但你必须遵守纪律。
是的,当然。每当有更改时,我们生成PostgreSQL模式的转储并签入。它已经救了我们很多次,而我才上任几个月。
Visual Studio中的新数据库项目提供了源代码控制和更改脚本。
他们有一个很好的工具,可以比较数据库,并可以生成一个脚本,将一个数据库的模式转换为另一个数据库,或者更新一个数据库中的数据以匹配另一个数据库。
db模式被“分解”以创建许多许多小的.sql文件,每个DDL命令一个描述db。
+tom
附加信息2008-11-30
作为一名开发人员,我在过去的一年里一直在使用它,我真的很喜欢它。它可以很容易地比较我的开发工作和生产工作,并生成用于发布的脚本。我不知道它是否缺少dba在“企业级”项目中所需要的特性。
因为模式被“分解”到sql文件中,所以源代码控制可以正常工作。
One gotcha is that you need to have a different mindset when you use a db project. The tool has a "db project" in VS, which is just the sql, plus an automatically generated local database which has the schema and some other admin data -- but none of your application data, plus your local dev db that you use for app data dev work. You rarely are aware of the automatically generated db, but you have to know its there so you can leave it alone :). This special db is clearly recognizable because it has a Guid in its name,
VS DB项目在将其他团队成员所做的DB更改集成到您的本地项目/相关DB方面做得很好。但是您需要采取额外的步骤,将项目模式与本地dev db模式进行比较,并应用mods。这是有道理的,但一开始似乎很尴尬。
DB项目是一个非常强大的工具。它们不仅生成脚本,而且可以立即应用它们。请确保不要用它破坏您的生产数据库。;)
我真的很喜欢VS DB项目,我希望在我所有的DB项目中使用这个工具。
+tom
RedGate很棒,当数据库发生变化时,我们会生成新的快照(一个小的二进制文件),并将该文件作为资源保存在项目中。每当我们需要更新数据库时,我们使用RedGate的工具包来更新数据库,并且能够从空数据库创建新的数据库。
RedGate也制作数据快照,虽然我个人没有使用过,但它们同样强大。
Sadly, I've seen more than one team developing PL/SQL programs (stored procedures in Oracle) - sometimes ten thousands LOC - just by editing the code in TOAD (a database tool), without even saving the source to files (except for deployment). Even if the database is backuped regulary (wouldn't take that for granted, though), the only way to retrieve an old version of a stored procedure is to restore the whole database, which is many GB large. And of course sometimes concurrent changes in one file lead to loss of work, when more than one developer works on the same project.