blocks|key|5061428|text|一种快速的解决方案是为数据创建某种类型的校验和，而客户端一开始只要求这样做。如果相同，则不需要更多数据，该部分是最新的。如果数据发生变化，那么sum也会发生变化，客户端将获得新的sum以及新的数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5061429|每次只传输这些数据听起来应该比你所有的数据都少。|5061430|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A quick solution would be to create a checksum of some sort for the data, and the client only asks for that at first. If that is the same, then no more data is required, that part is up to date. If the data changes, the sum changes, and the client gets the new sum along with the new data.

Transferring only that every time sounds like it should be less than all of your data.

blocks|key|5061481|text|如果您的数据很少更改，您可以使用sql触发器来设置等同于"updated“标志-然后简单地在任何其他客户端-服务器通信中利用该标志。如果您将insert/update/delete触发器添加到所有半静态表和一个watchdog表中，则应该可以执行此操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5061482|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If your data rarely changes, you can use an sql trigger to set the equivalent of an "updated" flag - and then simply piggyback that flag on any other client-server communication. If you add insert/update/delete triggers to all semi-static tables, and one watchdog table, you should be good to go.

blocks|key|1240802|text|不确定数据集可能是什么样子的，但是如何计算数据集上的类似SHA256的散列，并将该散列存储在客户端和服务器上。然后，在从服务器获取之前，只获取散列，并与客户端上的本地散列进行比较。如果散列匹配，则使用本地存储的数据集。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1240803|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Not sure how the data sets might look but how about calculating a Hash like SHA256 over the data set and storing that hash on the client and the server. Then before a fetch from the server, fetch only the hash and compare with local hash on the client. If the hash match then use the locally stored data set.

blocks|key|5061450|text|您可以保留一个SQL表函数或视图或其他轻量级的东西，这些函数或视图可能对给定的一组对象具有水印或其他指示符，这些对象可能会报告修订ID或0，1表示更改，然后只刷新那些需要更新的对象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5061451|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You might keep a SQL table function or view or something else lightweight which might have a watermark or other indicator for a given set of objects which might report a revision ID or a 0 for unchanged, 1 for changed, and then refresh only those objects which need updating.

blocks|key|5061511|text|我认为最好的方法是创建一个单独的表来跟踪数据。该表将只包含表名的列表，以及该表最后一次修改的时间。然后，您将创建一个触发器，每当在该表上发生插入/更新/删除操作时，该触发器将更新字段。当客户端想要检查数据时，您将检索数据并从该表中获取日期并将其存储。下一次客户端需要数据时，只需在该表中查找表名，获取日期并将其与您拥有的表名进行比较。如果数据库中的值较大，则是时候从服务器获取数据了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5061512|这种方法唯一的缺点是，对于表中的任何更改，您将转到数据库并再次检索所有数据，即使更改不会影响特定的SQL查询。如果您的数据不经常更改，这应该不会有太大影响。|5061513|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think the best approach would be to create a separate table to keep track of data. The table would just contain a list of table names, and the last time that table was modified. Then you would create a trigger that would update the fields whenever an insert/update/delete happened on that table. When the client wanted to check for data, you would retrieve the data and get the date from that table and store it. The next time the client needs the data, just look for the table name in that table, get the date and compare it to the one you had. If the one in the database is greater, it's time to fetch from the server.

The only downside to this approach is that for any change in a table, you will go to the database and retrieve all the data again, even if the change doesn't affect your specific SQL query. This shouldn't really matter too much if you data does not change often.

blocks|key|3593158|text|如果应用程序本身可以判断是否对数据进行了更新，那么请求延迟缩放可能是最简单的选择。当应用程序启动时，请求数据，然后在最小刷新延迟后再次请求。如果数据未更改，则将请求之间的刷新延迟增加一倍。当没有检测到任何变化时，继续加倍延迟(可能有最大限制)，然后您就可以开始了。这是一种减少服务器负载的常见模式，并且很容易实现客户端，而无需更改您的模式或web服务。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3593159|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If the application itself can tell whether there's been an update to the data, request delay scaling may be the simplest bet. When the application starts, request the data, then request again after your minimum refresh delay. If the data has not changed, double the refresh delay between requests. Continue doubling the delay when no changes are detected (possibly with a maximum constraint) and you're set to go. This is a common pattern to reduce server load, and is very easy to implement client side without changes to your schema or web service.

blocks|key|3593211|text|每当要缓存的数据库或表发生更改时，都必须维护一个时间戳。如果有相关的表，或者在相似的时间范围内更改的表，您可以将它们分组到共享相同时间戳的系列中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3593212|当你想要数据的时候，你必须首先询问时间戳。如果没有更改，则使用缓存的数据。如果它已经改变，请求新的数据，更新您的缓存，并递归地请求所有祖先数据的时间戳。|3593213|校验和不起作用，因为它们可能会发生冲突，而您无论如何都必须请求最新的数据来检查冲突。旧的/+changed标志不起作用，因为你不知道数据什么时候被改变的，它可能在你之前的时间戳之前。每次更改后始终增加且从不减少的版本ID也将有效。|3593214|如果您使用的是HTTP服务，则GET+HEAD代码将只返回RESTful头，其中可能包含时间戳。如果您的web服务不包含时间戳，则必须定义返回时间戳的新时间戳。|3593215|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

You must maintain a timestamp of whenever the database or table you want to cache changes. If there are related tables, or ones which change on a similar timeframe, you can group them into families which share the same timestamp.

Whenever you want data you must first ask for the timestamp. If it hasn't changed, use the cached data. If it has changed, ask for the fresh data, update your cache, and ask for the timestamp of all ancestral data recursively.

A checksum doesn't work because they can collide and you'll have to ask for the fresh data anyway to check for collisions. An old/changed flag won't work because you won't know when the data was changed, it could have been before your previous timestamp. A version ID that always increases after every change and never decreases will also work.

If you're using a RESTful web service the GET HEAD code will return you only the HTTP header, which can include a timestamp. If your web service does not include timestamps you will have to define new ones that return them.

I'm working on a winform app that will be used by groups in the US and overseas that replaces an existing app built with older technologies.

Performance of the old app overseas is pretty slow due to excessive calls back to the database server in the US, so I'd like to cache as much stuff on the client as possible. 

What is the best way to cache data for things that don't change very often - but may? How do I keep the data from getting stale without pulling it entirely on each load?

Strategy for keeping semi-static data fresh

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在开发一个winform应用程序，它将被美国和海外的团体使用，取代用旧技术构建的现有应用程序。由于对美国数据库服务器的过多调用，旧应用程序在海外的性能相当缓慢，因此我希望在客户端缓存尽可能多的内容。什么是缓存数据的最好方法，用于不经常更改但可能更改的数据？我如何防止数据变得陈旧，而不是在每次加载时完全拉出它？

问保持半静态数据新鲜的策略
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问保持半静态数据新鲜的策略EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问保持半静态数据新鲜的策略
EN