【问题标题】:Maintaining and updating data over the life of a database在数据库的生命周期内维护和更新数据
【发布时间】:2017-11-23 06:16:46
【问题描述】:

在使用迁移开发后端应用程序时,我相当熟悉随着时间的推移维护数据库架构。例如,添加一个新列意味着创建一个新的迁移文件,该文件最终将在推送到生产环境后应用。

但是,关于一次性数据更新,我有点不清楚。特定客户可能希望对其数据集进行细微更改。随着时间的推移,是否有维护和记录这些特定变化的惯例?

【问题讨论】:

    标签: sql node.js postgresql


    【解决方案1】:

    您的问题不完全符合 SO 规则,因为它并没有真正的事实答案;它相当广泛且基于意见,因此我们可能会获得一些反对票..

    就个人而言,我会像这样管理这些事情:

    • 系统具有直接运行 SQL 的功能,已锁定
    • 支持团队编写 SQL 执行工作,交给客户
    • 客户应用修复/运行 SQL
    • 任何审核、日志记录、备份都是应用更新的系统任务。对迁移采用类似的策略可能是明智的(一个记录什么、何时和为什么的表,因此不会重复更新)

    作为一个设施,如果它是公开的并且是免费的,那么它可能是非常危险的,但是有很多方法可以解决这个问题 - 也许你会为每个客户制作一个 pub/priv 密钥对,然后在你之前加密 sql把它交给客户,系统只会运行解密成功的 sql,所以虽然你的支持团队是 priv 密钥的唯一持有者,但只有他们可以编写可运行的 sql。

    我认为在迁移风格的工作流程中执行此操作并加上源代码控制是不明智或可行的,因为我想不出一种真正好的方法来以某种方式将客户特定的内容与核心代码库分开随着时间的推移,这不会成为管理方面的噩梦

    【讨论】:

    • 我将在以后的帖子中保留有关特定问题而不是意见的问题。感谢您的回复。
    • 我回答基于意见的问题没有问题,因为我通常更喜欢论坛格式而不是 SO 格式,而且我不介意拿起奇怪的 DV 最终它会有所帮助:)这只是一个仅供参考,以防您的问题得到 DV / closevotes。 SO的其他居民更加顽固,我敢肯定,这将像我们这样的人视为乱扔垃圾的恶棍:)
    • 是的,我绝对可以在 SO 周围看到这一点,但再次感谢您的详细回复。有时我只想讨论一个主题,而不是我在 XYZ 框架中遇到的特定问题 :)。
    猜你喜欢
    • 1970-01-01
    • 2018-06-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-02-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多