4 ms·
"We can replace the timestamp with the primary key for the “recentness” calculation". Very different properties, not a great replacement.
by mooneater 10y ago
"We can replace the timestamp with the primary key for the “recentness” calculation".
Very different properties, not a great replacement.
- Jarred 10y agoYeah. If you wanted to delay making posts visible but create them in advance, they wouldn't have the same ranking as though they were just posted. You'd have to create them at the exact time you'd want them to start being displayed in order for the desired ranking to be correct.
- jsjohnst 10y agoThe example was a social media site like Instagram, not a blog, which doesn't allow future posting. If you have different design constraints than the given example, obviously the implementation will need to adjusted to the new requirements.
- jsjohnst 10y agoCare to expand on that?
- czep 10y agoI definitely agree that there may be some unexpected consequences of using the primary key in this way. It certainly won't behave like a timestamp and could distort the function outputs. Would it be possible to substitute the integer count of seconds since epoch (or some other arbitrary base timestamp) and use that instead? Then you'd still have an immutable function to satisfy the index, but also you'd preserve valuable information about the relative time intervals between posts.
- deleted 10y ago[deleted]
- majewsky 10y agoNo problem, just add a bot that creates a post every second, so that the pace of the primary key approximates that of the timestamp. /s