管理应用程序数据库的流行最佳实践是什么？
一种选择是使用 sql 脚本来创建空表，并从硬编码选项开始。（说出所有地点或职业类型）。在升级过程中，您知道里面有什么，没有什么，所以在服务器上运行一个 sql 脚本来添加列和任何新数据。
另一种是以编程方式执行此操作，每次服务器运行时 - 它检查数据库是否存在，如果不存在，则创建它。在添加新列的过程中，会有代码检查此架构中是否存在某个列，如果不存在，则添加我选择的默认值，以及任何应该需要的新数据。
我的约束是：
- 如果出现任何问题，应该能够盲目地恢复备份。
- 最少的人工干预
- 我计划在添加表和列的情况下全天候运行它：首先升级 SQL 数据库，然后升级相应字段的应用程序代码。删除表/列：首先降级应用程序，然后降级 SQL 数据库。
- 我没有使用 ORM。
我在这里是否遗漏了我应该添加到约束中的东西？请阐明与答案相关的推理。
另外，我希望，由于我要求的是有约束力的答案以及来源和推理，所以这不算是基于意见的问题。
编辑：在 Added constraint(3) 中响应评论。
多年来，我已经积累了几点。
像这样的项目总是有风险的——每多出 9 个，你就可以加 0 个！
我的意思是，为了从（比方说）99% 的可靠性提高到 99.9%，您必须将成本乘以 10。
尽可能减少面向网络的数据。始终在您最不忙的时间执行升级。
正在运行的服务器上的 DDL 很困难。
为了升级顺利进行 -始终将字段列表放入 SQL 中，切勿选择或插入超过绝对必要的次数。
即 SELECT f1, f2, f3... FROM tab1....（不是SELECT * FROM tab1）和
INSERT INTO tab1 (f1, f2, f3) VALUES ( not INSERT INTO tab1 VALUES(f1, f2...fn)
恕我直言，对您的场景来说最好的事情是有某种复制场景。非常了解 RDBMS 的 HA 功能。在这里查看我的回答（它适用于 MySQL，但一般原则适用于任何系统）。
通常情况下，Master 被复制到 Slave。
在切换时间，Halt Slave。升级奴隶。旧奴隶成为新主人。旧主人成为新奴隶。
测试，测试，再测试！
祝你好运。