高分请教：如何对正式运营的数据库做表结构和存储过程等的更新，详见帖子

2014-09-04 05:30:16 690 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

scsnsjsl_cs_dn 墨衍会员 · AI 创作全网分发关注 + 加入社区

Python电竞舆情分析：从比赛数据到论坛文本的量化拆解在数据驱动的时代，如何从海量、非结构化的网络讨论中提取有价值的信息，已成为舆情分析的核心挑战。自然语言处理与文本挖掘技术为这一难题提供了系统化解决方案，其中情感分析、关键词抽取与数据可视化是关键技术环节。这些技术能够将主观、模糊的社区舆论转化为客观、可量化的指标，广泛应用于品牌监控、市场反馈与赛事分析等场景。以英雄联盟等电竞赛事为例，通过Python工具链对比赛结构化数据与论坛讨论文本进行融合分析，可以清晰洞察粉丝情绪走向、争议焦点与舆论拐点，为战队运营、媒体决策提供数据支撑。本文完整演示了如何利用Pyth 阅读详情

正式数据库已经在运营当中

因为新需求或者修复BUG等原因，导致表结构或者存储过程等发生变化
如何在发布应用新版本的时候，同时对表结构、存储过程做相关的更新

如何保证
1、不影响正式数据库中的数据
2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏
3、如何对修复BUG的变动、新需求的变动做好版本控制

不知道有没有好的流程、或者工具

请不吝赐教，越详细越好，定高分相谢

...全文

Turing Test与Chinese Room：大模型工程化落地的两大核心标尺在人工智能工程实践中，‘智能’并非抽象哲学概念，而是可测量、可干预的系统行为。Turing Test本质是人机不可区分性的统计压力测试，关注交互时长、角色一致性与反事实鲁棒性；Chinese Room则揭示了当前大模型‘语法完备但语义缺失’的架构本质。二者共同指向一个技术共识：真正可靠的大模型系统，必须放弃对拟人化表象的追逐，转向可归因、可协商、可卸载的责任闭环设计。本文基于37个真实NLP项目经验，将这两个思想实验转化为混淆窗口时长、角色锚定强度、Searle验证器等可嵌入CI/CD的工程指标，并提供To 阅读详情

scsnsjsl_cs_dn

MS-SQL Server 34,876 成员 254,635 内容

+ 关注 + 加入社区

切换为时间正序

scsnsjsl_cs_dn 2014-09-10

打赏
举报

多谢

發糞塗牆 2014-09-09

打赏
举报

如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

scsnsjsl_cs_dn 2014-09-09

打赏
举报

引用 6 楼 luckyrandom 的回复:

别去找一劳永逸的三方工具，不现实既然是修改或修正BUG，就得把脚本整理好，以在生产环境部署，偷不了懒能问出这个问题，说明你们没有较专业的DBA支持。。属于技术资源不足

确实是没有专业的DBA，能详细说下你的方案么，多谢

Q315054403 2014-09-09

打赏
举报

引用 7 楼 scsnsjsl_cs_dn 的回复:

[quote=引用 6 楼 luckyrandom 的回复:] 别去找一劳永逸的三方工具，不现实既然是修改或修正BUG，就得把脚本整理好，以在生产环境部署，偷不了懒能问出这个问题，说明你们没有较专业的DBA支持。。属于技术资源不足

确实是没有专业的DBA，能详细说下你的方案么，多谢[/quote] 没有神奇的魔术方案，缺啥补啥。。缺专业的DBA，就应该补缺DBA（当然涉及成本及合适的人选等综合问题）如果真有魔术方案，大把DBA也该退出江湖了

卖水果的net 版主 2014-09-09

打赏
举报

必须事先把要升级的 SQL 语句准备好，等更新的时候，和程序一起发布，最好是把业务停掉。更新前要反复测试，并且要有回退方案。

發糞塗牆 2014-09-09

打赏
举报

引用 10 楼 scsnsjsl_cs_dn 的回复:

[quote=引用 8 楼 DBA_Huangzj 的回复:] 如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

针对第二点： 1、不管是第三方还是自己开发的工具都是通过SQL脚本对正式库做更新吧/ 2、常用的第三方工具有哪些呢[/quote] 通常对SQL Server的更新都是SQL脚本操作，除非一些外部引用。第三方软件，我以前用公司内部开发的，不是外部用的，所以不清楚，现在离开了也没拿到收

道素 2014-09-09

打赏
举报

如果想查找旧的对象都在哪里使用，可以试试： reddate的SQL Search ApexSQL Refactor和Search

scsnsjsl_cs_dn 2014-09-09

打赏
举报

引用 8 楼 DBA_Huangzj 的回复:

如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

针对第二点： 1、不管是第三方还是自己开发的工具都是通过SQL脚本对正式库做更新吧/ 2、常用的第三方工具有哪些呢

scsnsjsl_cs_dn 2014-09-09

打赏
举报

引用 8 楼 DBA_Huangzj 的回复:

如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

第二点都是通过执行更新脚本吧？第三方工具一般有哪些呢?

Q315054403 2014-09-06

打赏
举报

别去找一劳永逸的三方工具，不现实既然是修改或修正BUG，就得把脚本整理好，以在生产环境部署，偷不了懒能问出这个问题，说明你们没有较专业的DBA支持。。属于技术资源不足

KeepSayingNo 2014-09-05

打赏
举报

这个建立在你的数据库都是用脚本归档的前提下，如果是这样，那么你可以针对新增的需求做一些脚本，例如原来的是001版本，然后你可以做个002版本的脚本，这个里面只包含新增脚本，这样的话如果某个地方需要升级，先保证是001版本，再刷002版本的脚本即可，这样也保证了各个地方系统的独立行。

唐诗三百首 2014-09-05

打赏
举报

数据库应分为开发库-->测试库-->发布库-->正式库.. 开发库与测试库不用解释, 发布库是定期拿正式库备份来还原的,其表结构与正式库一致. 当在开发库完成开发及初步测试后,应编写用于发布的SQL脚本,在测试库执行.. 当在测试库完成测试后,用发布的SQL脚本在发布库执行.. 当在发布库执行正常后,用发布的SQL脚本在正式库执行..