Redian新闻
>
MS SQL Server数据库更新
avatar
MS SQL Server数据库更新# Database - 数据库
b*g
1
正在寻找一个SQLServer数据库更新的程序,要求是软件发布更新过的数据库=>用户下载=
>程序自动将用户端的数据库更新为新版本的数据库。
我知道SQLServer可以记录数据库更改的脚本,在软件发布时发布更新的脚本,但是1、用
户端数据库可能有不同的版本;2、程序员修改数据库时,可能会忘记存更改脚本。
所以,我希望在发布时,只发布最新的空数据库,更新程序能够比较用户数据库和最新数
据库的不同(这种程序我有),自动修改用户端数据库;或者比较两者,把旧数据库的数
据导入到新数据库里。请教大侠哪种办法可行,或者还有其它办法?
多谢!
avatar
s*n
2
Don't understand 脚本,呵呵.
I have done similar things that can be summarized as follows:
1. Database keeps its current version in a table
2. The upgrading program checks the version number
3. Based on the version number, the program runs a series of scripts
to perform the upgrade
4. The program updates the database version
Based on the above, you should be able to keep the upgrading program as
static, and only ship scripts to the users. We also use naming conversion
such as upgrade2_1.sql to ind

【在 b******g 的大作中提到】
: 正在寻找一个SQLServer数据库更新的程序,要求是软件发布更新过的数据库=>用户下载=
: >程序自动将用户端的数据库更新为新版本的数据库。
: 我知道SQLServer可以记录数据库更改的脚本,在软件发布时发布更新的脚本,但是1、用
: 户端数据库可能有不同的版本;2、程序员修改数据库时,可能会忘记存更改脚本。
: 所以,我希望在发布时,只发布最新的空数据库,更新程序能够比较用户数据库和最新数
: 据库的不同(这种程序我有),自动修改用户端数据库;或者比较两者,把旧数据库的数
: 据导入到新数据库里。请教大侠哪种办法可行,或者还有其它办法?
: 多谢!

avatar
b*g
3
多谢你的回帖,不过,你的方法正是我不想用的方法,发布脚本的方法有以下缺点:
1、数据库版本信息(Version number)需要一定的维护,任何错误的版本信息都可能造成
数据库更新的失败。(举例来说,由于某种原因,一系列脚本中的一个没有成功执行,而
版本号被更新为最新版本,这个用户的数据库就无法正常运行,而版本号已经更新,没有
执行的脚本再也不会被执行。)错误情况的几率可能很小,但是考虑的到几万、几十万用
户下载你的更新脚本,出错的几率哪怕只有1%,也是不能接受的。再说,我只是举了一
个出错的可能,如果还有其它出错的情况,出错的几率就会成倍增长。
2、发布的脚本如何生成也是一个问题。一种方法是,每次修改数据库,都保留SQLServer
自动生成的脚本,最后积累起来打包发布。这种方法虽然简单,但开发人员的任何疏忽(
比如忘了存脚本,存错的地方,打包时忘了加),都是致命的,如果两个版本之间,数据
库修改了十次,忘记存一次都不能生成完整的更新脚本。另一种方法是,保留每次发布的
数据库,下次发布时,比较新数据库和上次保留的版本,生成脚本。这种方法的代价是,
必须保留上个版本,另外生成的

【在 s******n 的大作中提到】
: Don't understand 脚本,呵呵.
: I have done similar things that can be summarized as follows:
: 1. Database keeps its current version in a table
: 2. The upgrading program checks the version number
: 3. Based on the version number, the program runs a series of scripts
: to perform the upgrade
: 4. The program updates the database version
: Based on the above, you should be able to keep the upgrading program as
: static, and only ship scripts to the users. We also use naming conversion
: such as upgrade2_1.sql to ind

avatar
s*n
4
You can minimize the errors by the following:
1. wrap the upgrade in a transaction
2. ask user the backup the database before upgrade
3. check for errors, report, and abort without updating the versoin number
4. writing upgrade scripts in a way that it can deal with partial upgrades
You don't have to do all of the above, but some combination of a few.
However, if there is possibility that sb. other than the application and
upgrading program could screw up the table/data in any way, the best prog

【在 b******g 的大作中提到】
: 多谢你的回帖,不过,你的方法正是我不想用的方法,发布脚本的方法有以下缺点:
: 1、数据库版本信息(Version number)需要一定的维护,任何错误的版本信息都可能造成
: 数据库更新的失败。(举例来说,由于某种原因,一系列脚本中的一个没有成功执行,而
: 版本号被更新为最新版本,这个用户的数据库就无法正常运行,而版本号已经更新,没有
: 执行的脚本再也不会被执行。)错误情况的几率可能很小,但是考虑的到几万、几十万用
: 户下载你的更新脚本,出错的几率哪怕只有1%,也是不能接受的。再说,我只是举了一
: 个出错的可能,如果还有其它出错的情况,出错的几率就会成倍增长。
: 2、发布的脚本如何生成也是一个问题。一种方法是,每次修改数据库,都保留SQLServer
: 自动生成的脚本,最后积累起来打包发布。这种方法虽然简单,但开发人员的任何疏忽(
: 比如忘了存脚本,存错的地方,打包时忘了加),都是致命的,如果两个版本之间,数据

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。