带数据库的桌面应用程序 - 如何处理数据检索？
想象一下，有一个桌面应用程序 - 可以最好地描述为用户插入/查看记录的记录保存 - 依赖于包含大型对象的数据库后端' 层次结构和属性。数据检索应该如何处理？
是否应该在启动时加载所有数据并将其存储在相应的类/结构中以供以后操作，或者是否仅在需要时检索数据，并将其存储在模拟类中/结构，然后重用，而不是再次询问数据库？
据我所知，前一种方法需要使用更大的内存部分，并且启动时可能需要等待时间（如果显示启动屏幕，情况还不错），而后者可能会使用户在处理过程中遇到延迟，因为数据检索，并且需要对数据库执行一些昂贵的查询，其结果和/或支持数据结构一旦使用很可能没有任何用处*。
有件事告诉我，解决方案在于深入分析，这将导致基于最常用的数据混合上面列出的两种方法，但我非常有兴趣阅读您对此主题的想法、技巧和现实生活经验。
为了便于讨论，我正在考虑 C++ 和 SQLite。
谢谢！
*假设您可以对类/对象执行更快的操作，而不必在数据库上执行复杂的查询。
编辑
一些其他详细信息：
- 无法并发访问数据，这意味着只有 1 个用户处理本地存储的数据。
- 数据的发送取决于人为所做的更改 - 即频率较低。对于从数据库读取数据来说，这不一定是正确的，我可以预期在大量读取中会有几个峰值，而我希望速度更快。
- 我最担心的是用户在显示复杂记录时感到缓慢（因为这必须从数据库读入）。
Imagine to have a Desktop application - could be best described as record keeping where the user inserts/views the records - that relies on a DB back-end which will contain large objects' hierarchies and properties. How should data retrieval be handled?
Should all the data be loaded at start-up and stored in corresponding Classes/Structures for later manipulation or should the data be retrieved only at need, stored in mock-up Classes/Structures and then reused later instead of being asked to the DB again?
As far as I can see the former approach would require a bigger memory portion used and possible waiting time at start-up (not so bad if a splash screen is displayed), while the latter could possibly subject the user to delays during processing due to data retrieval and would require to perform some expensive queries on the database, whose results and/or supporting data structures will most probably serve no purpose once used*.
Something tells me that the solution lies on an in-depth analysis which will lead to a mixture of the two approaches listed above based on data most frequently used, but I am very interested in reading your thoughts, tips and real life experiences on the topic.
For discussion's sake, I'm thinking about C++ and SQLite.
Thanks!
*assuming that you can perform on Classes/Objects faster operations rather than have to perform complicated queries on the DB.
EDIT
Some additional details:
- No concurrent access to the data, meaning only 1 user works on the data which is stored locally.
- Data is sent back depending on changes made humanly - i.e. with low frequency. This is not necessarily true for reading data from the DB, where I can expect to have few peaks of lots of reads which I'd like to be fast.
- What I am most afraid of is the user getting the feeling of slowness when displaying a complex record (because this has to be read in from the DB).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用延迟加载和数据映射器（第 165 页）模式。
Use Lazy Load and Data Mapper (pg.165) patterns.
我认为这个问题取决于太多变量，无法给出具体答案。您首先应该考虑的是需要从数据库读取多少数据到应用程序中。此外，您多久将该数据发送回数据库并请求新数据？另外，用户会同时处理数据吗？如果是这样，最初加载数据可能不是一个好主意。
编辑后，我想说最好将数据保留在数据库中。如果您将以相对较低的频率访问它，则没有理由在启动时加载或以其他方式尝试将其缓存在您的应用程序中。当然，只有您最了解您的应用程序，并且应该决定可以预先加载哪些位以提高性能。
I think this question depends on too many variables to be able to give a concrete answer. What you should consider first is how much data you need to read from the database in to your application. Further, how often are you sending that data back to the database and requesting new data? Also, will users be working on the data concurrently? If so, loading the data initially is probably not a good idea.
After your edits I would say it's probably better to leave the data at the database. If you are going to be accessing it with relatively low frequency there is no reason to load up or otherwise try to cache it in your application at launch. Of course, only you know your application best and should decide what bits may be loaded up front to increase performance.
您可能会考虑使用用户中间服务器（WCF），它将包含内存中数据库的缓存数据，这样用户就不必每次都访问数据库。此外，由于它只是所有用户的一个访问点，如果有人更改/添加记录，您也可以更新缓存。静态数据可以每 x 小时（例如每小时）重新加载一次。它仍然可能不是最好的选择，因为数据需要从服务器编组到客户端，但如果可以的话，您可以使用 netTcp 绑定，它既快又小。
You might consider to user intermediate server (WCF) that will contain cached data from the database in memory, this way users don't have to go every time to the database. Also since it is only one access point to for all users if somebody changes/added record you can update cache as well. Static data can be reloaded every x hours (for example every hour). It still might not the best option, since data needs to be marshaled from Server to the Client, but you can use netTcp binding if you can, which is fast and small.