在应用程序更新时更新部分数据库
我正在使用 C++ (Qt) 和 SQLite 开发一个应用程序。该应用程序安装了包含一些记录的预定义数据库。用户可以用自己的记录扩展数据库。我想知道如何实现应用程序的更新，即当安装新版本的应用程序时，我想删除数据库中的旧核心（预定义）记录，并替换（插入）新记录。出现这些问题：
- 我是否应该使用两个具有相似架构的数据库，一个可供用户修改，第二个是只读预定义数据库（因此应用程序更新只是将新的预定义数据库复制到旧数据库上）？
- 或者我应该在数据库中有一列关于作者（应用程序或用户）的列，并以某种方式（以及如何？）在更新时删除旧的应用程序记录并插入新记录？
有什么想法吗？谢谢
I'm developing an application with C++ (Qt) and SQLite. The app is installed with predefined database filled with some records. User has the ability to extend the database with his own records. I'm wondering how to achieve update of the app, i.e. when new version of app is being installed, I want to remove the old core (predefined) records in the database, and replace with (insert) the new ones. These questions arise:
- Should I use 2 databases with similar schema, one modifiable for user and second read-only predefined one (so the app update would be just copying new predefined database over old one)?
- Or should I have a column in database about the author (app or user), and somehow (and how?) on update delete old app records and insert new ones?
Any ideas? Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
还有第三种变体：
这极大地简化了查询（与第一个变体相比），并且您没有大多数记录不需要的额外列（我认为）。
如果您不需要额外的桌子，我会说采用第二种方案。第一个会迫使您执行两次查询并
UNION它们。这对我来说听起来不对。There's a third variant:
This greatly simplifies queries (compared to the first variant) and you don't have the extra column which you don't need for most of the records (I think).
If you don't want the extra tables, I'd say do the second variant. The first one would force you to do your queries twice and
UNIONthem. That just doesn't sound right to me.好问题。我会选择第二种选择，因为我们在这里做了类似的事情。
另一种可能性是对数据库中的数据进行分类，这样您就可以知道该记录是系统的一部分还是来自用户（例如，通过使用关键字或值范围）。尽管此解决方案不需要额外的表或列，但它更难理解和维护，因为它为数据库记录赋予了隐藏的含义。
Good question. I would go for the second option, since we did something similar here.
Another possibility would be to classify the data in the database, so you could know if the record is part of the system or is from the user (by using keywords or range of values, for example). Although this solution does not require additional tables or columns, it is much harder to understand and maintain, since it gives hidden meaning to the database records.