管理与代码库相关的重要运行时业务逻辑
我正在开发一个项目，该项目最终会将大量应用程序信息以记录的形式存储在数据库中。在本例中，它是数据视图的配置：
- 显示/隐藏哪些网格列
- ，应用于每个网格视图
- 列的默认过滤器，标题
- 排序
- ，小计
- ...
此信息是应用程序并且对其功能至关重要。管理员会大量更改数据，因此它不是静态的，并且每次数据更改时都必须部署新版本的应用程序是不合适的。
问题是，这些数据应该存储在哪里？它肯定会存在于数据库中，因为这就是它的访问方式，但我觉得它也需要与版本控制的代码库一起保存< /strong> 因为它是应用程序功能的一个组成部分。以前有人处理过这样的问题吗？你最后做了什么？
I'm working on a project which will end up have a lot of application information stored in the form of records in a database. In this case, it's the configuration of data views:
- which grid columns to show/hide
- default filters to apply to each grid view
- column titles
- sorting
- subtotaling
- ...
This information is a big part of the value of the application and is essential to it's function. The data will be altered by admins a fair amount, so it's not static and it wouldn't be appropriate to have to deploy a new version of the app every time the data changes.
The question is, Where should this data be stored? It will definitely live in the database because that's how it's accessed, but I feel like it needs to also be kept with the version controlled codebase because it's an integral part of functioning of the application. Has anyone dealt with an issue like this before? What did you end up doing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该以与存储当前版本的架构定义相同的方式存储它。我会将条目导出为插入语句，并将文件与所有其他文件一起保存在源代码管理中。
You should store it the same way you store the schema definition for your current version. I would export the entries as insert statements and save the file in source control along with all others.
由于这将位于您应该进行备份的数据库中（每 15 分钟或半小时对数据库进行夜间备份，并进行事务日志备份），因此我认为您不会丢失数据。确保您的数据库管理员知道如何将数据恢复到单独的数据库，以便您可以在需要恢复表时仅从该数据库复制表。
或者，您可能需要一个触发器来存储对审计表中数据的所有更改。然后，如果需要，您可以使用审核表取回数据（但仍然进行备份！）
Since this will be in a database that you should be making backups of (nightly backups of the database with transaction log backups every 15 minutes or half an hour), I don't think you will lose the data. Make sure your dbas know how to restore the data to a separate database so you can copy only the table over from that database if need be to recover the table.
Alternatively, you may want a trigger which will store all changes to the data in an audit table. Then you can use the audit table to get the data back if need be (but still do the backups!)