1.1w+
社区成员
6.8w+
社区内容
- 主页
MS SQL Server 2005该升级了吗？如何进行数据库的梳理工作？
背景：
1.系统是10年前开始自主开发的系统（BS，ASP）。当前的数据库是MS SQL Server 2005（应该是从2000升级上来的）。
问题：
1.表很乱，有700个表吧，不过估计有20%甚至更多是没有用的。
2.没有数据字典，表和字段命名中英文混杂，看不懂。
3.很多地方没有外键约束，导致了数据库里面有很多错误数据。
4.现在数据库里面大量的存储过程，触发器，很多视图，然后有很多SQL效率低下，经常导致系统动不了了。
想法：
1.重新架构和实现系统。
2.反正是做新系统，老的系统先不要去动了。用SQL Server的新版本建立新的数据库。
3.逐步去梳理一个个的表。通过程序把旧的数据库里面的数据导入新的数据库。
难题：
1. 新的数据库和原来那个旧的数据库，如何去做数据同步（实时）。
这个思路有没有问题？应该如何去解决这个难题。
1.系统是10年前开始自主开发的系统（BS，ASP）。当前的数据库是MS SQL Server 2005（应该是从2000升级上来的）。
问题：
1.表很乱，有700个表吧，不过估计有20%甚至更多是没有用的。
2.没有数据字典，表和字段命名中英文混杂，看不懂。
3.很多地方没有外键约束，导致了数据库里面有很多错误数据。
4.现在数据库里面大量的存储过程，触发器，很多视图，然后有很多SQL效率低下，经常导致系统动不了了。
想法：
1.重新架构和实现系统。
2.反正是做新系统，老的系统先不要去动了。用SQL Server的新版本建立新的数据库。
3.逐步去梳理一个个的表。通过程序把旧的数据库里面的数据导入新的数据库。
难题：
1. 新的数据库和原来那个旧的数据库，如何去做数据同步（实时）。
这个思路有没有问题？应该如何去解决这个难题。
...全文
dyf0130 2013年04月25日
....现在数据库里面大量的存储过程，触发器，很多视图，然后有很多SQL效率低下，经常导致系统动不了了.....
因为有 触发器 这个地雷,基本上 B方案：保持数据库结构不变 就被否决了
轻舟已过万重山 2013年04月25日
现在老系统是决定了要用新的技术架构来做实现，因为10年前做的这个系统有较多的问题，已经不能满足现在业务上，性能上，安全上的要求。并且大家都认为重构不显示，所以新的技术架构会采用，新系统是要做的了。
问题就剩下：
做新的技术架构，用A方案：新的数据库，B方案：保持现有数据库不动。
A方案：用新的数据库
好处：根据现有的业务需求，整理业务模型，设计的数据库，肯定更加合理，干净，规范，可以有更好的规划。
坏处：在新的系统没有完成之前，时间跨度太大，如何保证新的数据库和旧的数据库中数据的同步？因为等不到新的系统开发好了再一次性做数据迁移。
B方案：保持数据库结构不变
好处：不存在数据需要同步的问题，对同时使用和维护的旧系统基本没有影响。
坏处：所有人都认为旧的数据库系统结构，关系，主键，外键，字段等等都不合理。在这样一个不合理的数据库结构上做新的技术架构，普遍认为效果会不好。
如何决策？
Q315054403 2013年04月22日
开发新系统，测试，导入旧系统测试，完成后再交割。。不需要实时同步
seusoftware 2013年04月21日
新系统做出来，确定没问题了，做一次割接，老系统的数据什么的一次斩断关系。
怎么确定新系统没有问题？
1. 可以通过老系统的数据，在新系统做测试；
或者
2. 可以用新版本的程序把部分用户用到新数据库上；
hgwyl 2013年04月21日
其实按照楼主所说，升级数据库是不必要的——个人认为
先确定目的：为什么要升级数据库？
——感觉是楼主为了提高程序处理业务流程的效率、速度、标准性
——问题并不是出现在“数据库的版本”。
——而是出现在“程序与数据库的不规范”。
另外一个方面
700个表；表字段及其多。
——这种情况下，你打算去重做这个系统吗？确定不会遇到阻力？
——不要说领导签字同意，大的企业或者单位，这没用。出现问题背黑锅的还是改动的人。
好好地做优化吧。
1、程序方面的优化
2、数据库优化
最后多嘴提醒一点：你真的认为人家开发的时候没有做数据库字典吗？稍微思考一下。
轻舟已过万重山 2013年04月20日
整理数据字典是需要的啦。
现在旧数据库，一个表动则100多个字段，冗余也是很厉害。
更是坚定了新系统需要重启一个新的数据库的决心。
新系统也不是短时间能简历起来的，准备一步步来。但这个时候，新旧老个系统，老个数据库，里面的数据交换，同步，很麻烦。
不知道如何解决。
zbdzjx 2013年04月18日
1、先整理好旧系统的表、视图、存储过程、触发器……相关内容，去掉一些不用的。
2、分析好新系统中的表。
3、确定好旧系统与新系统中表及列的对应关系。
4、写个程序，能够一次将旧系统的资料全部导入到新系统中。
5、准备好测试，就先跑一遍程序，将旧系统资料导入到新系统中。
6、新旧两个系统同时跑，对比测试。
7、一段时间后，如果没问题，停掉旧系统。
8、如果有问题，更改问题。如涉及到表或列，与要相应修改程序，保证能够将旧系统的资料全部导入到新系统中。
9、最终测试完成，根据情况，如果新系统中的内容有问题，可以全部删除掉，用上面的程序再跑一遍，将旧系统的资料全部导入到新系统中。
發糞塗牆 2013年04月18日
先重整数据字典再做其他
叶子 2013年04月18日
先梳理业务关系，建立新系统，把旧系统的数据往新系统同步，等到旧的系统数据同步好后，直接使用新系统。
Mr_Nice 2013年04月18日
建议直接升级到2008 R2 性价比比较好。2012按核收费，确实有点坑。
另外，既然是新建程序，建议还是直接从业务着手，按照现有业务处理，进行重新设计。
原表的相关数据，建议新程序稳定后，进行数据整理转接工作。同时做同步，需要双向进行验证，而且由于业务不同可能造成混乱的局面，尽量减少旧系统与新系统之间的交互，可限制问题在单一库上，比较容易排查。
两个程序肯定是要并行一段时间的，这个期间，人工投入会加倍，尽量增加前期的测试，可缩短这个过程。
以上经验，参考