Algorithm 分页算法实现辅助

我正在编写一个分页算法，但我对实现的最佳方法有点困惑。我读过关于使用偏移量的文章，以及如果发布新内容的问题。另一种选择是使用seek方法

那么，我真正想要实现的是什么呢？我相信你们中的一些人可能听说过Tinder。加载应用程序时，会出现一组卡片。卡片上写满了你喜欢或不喜欢的其他用户的信息。我假设在第一次调用中完成了一个具有检索用户限制的简单查询。然而，在用户刷了几次之后，该应用程序会拨打越来越多的电话。我想做类似的事情。这是我当前的设置

应用程序的Psuedo代码：

1) Lets say I have choose to load 10 cards initially.
2) User keeps swiping 
3) When a user has 3 more cards left my app makes another call to the API and gets 10 more cards.
4) Repeat from step 2.

在API端（而不是应用端）的逻辑方面，我面临一些问题

我认为我的第一个解决方案是使用一个临时表来存储已加载的用户。一旦用户喜欢/不喜欢某个人，该条目就会从该表中删除。这个逻辑的问题是，假设一个用户最初加载10张卡，然后只刷5张，然后离开应用程序。现在我有5个用户存储在临时表中，该表不会为用户加载，因为它已经加载，并且没有任何操作。另外还有额外的开销

所以我的问题是，创建一个API的最佳方法是什么，它允许我在不重复的情况下加载卡。我认为一次加载一个（对服务器的调用太多）不是很有效。最后一点注意：我不是直接从users表中获取。我将用户放入一个算法中。该算法将生成一组10个用户

---

如果你通过了这篇长文章，我道歉。我只是想让你知道，我已经诚恳地试图想出一个解决方案，只需要一点推动。

我认为这可以在SQL sevel（例如，伪SQL）更容易地解决

您可以选择来源未看到的前10名用户。每当他看到喜欢/不喜欢的目标时，都会在like中添加一个新行。最好发送10个类似的结果，并在请求下一个10行时在同一个API调用中批量插入这10行。如果你想要更积极的缓存，那么你需要在应用程序端进行过滤

我想我的第一个解决方案是有一个临时表 存储已加载的用户。一旦用户喜欢/不喜欢 person，该条目将从该表中删除这个问题是什么 逻辑是，假设用户最初加载10张卡，然后刷卡 只有5和离开应用程序现在我有5个用户存储在临时数据库中 无法为用户加载的表，因为它已被 已加载，但未执行任何操作。另外还有额外的开销

我想强调的是，在您当前的解决方法问题中，“离开应用程序”和“没有任何行动”

如果用户离开应用程序时你真的做了些什么呢

我的意思是，为了避免这个问题，你能（从临时表中）删除他没有看到的其余5条临时记录吗

通过阅读你所有的描述，你似乎可以通过这样做来解决它

---

我希望这会有所帮助。

我可以这样做，但仍然会留下额外的开销问题。如果我有十万用户呢？我将有太多的I/O到数据库和服务器，所以这会成为一个问题。@BhavikP。我知道你写道这是一个“不在应用程序端”的问题。但是，是否可以执行您的解决方案（+我的帖子建议删除其余项目），但将临时数据存储在客户端（应用程序）中，而不是将其保存在服务器中？因为我们讨论的是10张卡，如果您将其存储在每个客户机中，可能不会产生额外的开销问题。或者这根本不是一个选择？嗯，我可以试试。我想我可能需要像Giovanni Azua建议的那样，向服务器发送最后检索到的列表的缓存。这是按照你的建议进行的还是你的方法是其他的？这仍然会产生重复的问题。此查询不显示用户喜欢/不喜欢的人，但用户不喜欢/不喜欢的人呢？例如，我是一个用户（用户id 5453）。该应用程序加载10。当我到达第八个人时，应用程序会再加载10个。API只知道我喜欢/不喜欢7个人，而不是第8、第9或第10个人。因此，第8位第9位和第10位的人可能会再次被加载，因为在类似的表格中，第8位第9位第10位第9位第10位第8位第9位第9位第10位第8位第9位第10位第8位第9位第10位第8位第9位第9位第10位第8位第9位第9位第10位第10位第8位第9位第9位第9位第10位第10位第8位第。比如说，当我加载这10个用户时，你认为我应该立即将这10个id放入like表中，还是只在用户喜欢/不喜欢时才将其放入like表中？如果我马上把它放好，当用户离开应用程序时，我将有空条目。管理数据会变得很混乱，因为我必须处理空条目。我想我可能需要使用其他解决方案（在请求下一个10行时，在同一个API调用中批量插入这10行）

1) User started the app and the API fetched initial 10 cards. When it comes
time for step 3, just making another call based on whom the user has
liked/disliked can load duplicates of the remaining 3 cards
2) If I choose to use offset, new users will mess up the pagination as a 
duplicate will be loaded.

create table user (PK ID id, VARCHAR(20) name, etc)

create table like (ID source FK user$id, ID target FK user$id, bool liked)

-- my current app user is id=5453
select top 10 
from user 
where id not in (select id 
                 from like 
                 where source=5453)