从数据库创建 RSS feed,需要将多少项放入 feed 中以便它们都可能被消耗?

发布于 2024-07-08 08:10:04 字数 258 浏览 9 评论 0原文

我正在从数据库创建多个 RSS 源,以发布职位空缺、志愿者机会和一般链接等内容。 我的问题是,提要中应返回多少项目,以便某人最有可能在阅读器中获得所有项目而没有任何间隙?

选择前 100 名? (显然需要设置 X 时间内估计的提要数量)

选择过去 24、48、72 小时?

如果我通过 Feedburner 运行我的提要,有谁知道他们是否会检查某个时间间隔,以便我可以按照他们的标准创建它,并确保 Feedburner 提要包含所有项目?

I'm creating several RSS feeds from a database to publish things like job openings, volunteer opportunities, and links in general. My question is, how many items should be returned in the feed so that it is most likely that someone will get all the items in their reader without any gaps?

SELECT TOP 100 ? (obviously would need to be set for # of feeds estimated over X time)

SELECT the last 24, 48, 72 hours?

If I run my feed through Feedburner, does anyone know if they check on a certain interval so that I can create it to their standard and be assured that the Feedburner feed will contain all items?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

冷︶言冷语的世界 2024-07-15 08:10:04

嗯,这取决于条目出现的速度。

但我猜测,瞄准最后 48 小时左右的时间是安全的——因为许多用户将运行独立的 RSS 阅读器,需要点击提要来获取当前的内容。 但如果数据太多,那么也许可以限制它。 不过 100 已经很多了。

它还取决于用户如何使用这些数据。 职位空缺可能适合该数量,但如果用户经常看到太多条目进来并取消订阅,他们可能会被淹没。

而且您需要警惕实际 Feed 本身的大小。 一些提要聚合服务设置了诸如 512kb 之类的限制,如果大于该限制,则不会转发它。

Well, it would depend on the rate that entries show up.

But I'd be guessing that aiming for the last 48 or so hours would be safe - seeing as a lot of users would be running stand alone RSS readers that will need to hit the feed to pull down whatever is current. But if that is going to be too much data, then maybe just limit it. 100 would be a lot though.

It would also depend on how the users would consume that data. Job openings would probably work with that volume, but users can get swamped if they're constantly seeing too many entries come in, and unsubscribe.

And you'll need to be wary of the size of the actual feed itself. Some feed aggregation services put a limit like 512kb and won't relay it if it gets bigger than that.

夏雨凉 2024-07-15 08:10:04

如果您首先完成了创建提要的艰苦工作,那么提供查询字符串变量来影响返回的记录。

我最近对基于 Intranet 的 feed 做了类似的事情,例如

feed.asp?d=3&n=100

它返回最近 3 天的 feed,最多包含 100 条记录。

类似地,

feed.asp?d=7 (过去 7 天的所有记录)

feed.asp?n=10 (最后 10 条记录)

然后用户可以调整 feed 以适应他们的情况,因为您通常不可能有一个feed 可以满足所有用户的需求。

虽然这不能帮助您在请求 feed.asp 时使用“默认”值,但它至少允许技术用户根据需要修改提要。 请务必检查查询字符串值,以防止愚蠢/恶意请求。

If you've done the hard work of creating the feeds in the fist place then offer querystring variables to affect what records are returned.

I did something similar recently for an intranet-based feed, like this

feed.asp?d=3&n=100

Which returns the last 3 days worth of feeds with a maximum of 100 records.

Similarly,

feed.asp?d=7 (all records for the past 7 days)

feed.asp?n=10 (the last 10 records)

Then users can adjust the feed to suit their circumstance as you typically can't possibly have one feed that caters for all users' requirements.

While this doesn't help you with your "default" values when feed.asp is requested, it does at least allow techy users to modify the feeds if they so wish. Make sure you check the querystring values too, to prevent silly/malicious requests.

心凉怎暖 2024-07-15 08:10:04

我个人会尽量将其保持在 25 左右以下。 我知道使用 iGoogle 进行 RSS 提要查看的人数正在增加,并且最大显示限制为 9 个条目。 许多其他 RSS 提要显示限制为 10-15 个条目。

我发现 RSS 提要,除非它本质上是一个“包罗万象”的提要,否则通常是对正在发生的事情或可用的内容进行小型、快速的更新。

正如 Madlep 提到的,我也会小心地缩小尺寸。

I personally would try to keep it to something under 25 or so. I know that the number of people using iGoogle for RSS feed viewing is going up, and there is a max display limit of 9 entries there. Many other RSS feed displays are limiting at 10-15 entries.

I find that an RSS feed, unless it is specifically an "all encompassing" feed by nature, is usually a small, quick-hit, update of what is going on or what is available.

As madlep mentioned i would also be careful to keep the size down.

情释 2024-07-15 08:10:04

feedburner 似乎每 5 分钟检查一次,但你也许可以在您的帐户中进行设置。 另一篇论坛帖子似乎表示每 30 分钟一次

feedburner seems to check every 5 minutes but you might be able to set it up in your account. Another forum post seems to indicate it's every 30 minutes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文