Question

At the moment we record a users last 20 media views so that they can have a brief history page of what they’ve looked at recently.

To do this we insert the media ids into a table.

To keep the table a small size it’s currently only 20 items per user so before inserting the row we check to see how many history ids they currently have in there, if it’s less than 20 then we just insert the new row, if it’s more than 20 then we have to select the last row and delete it before the new row can be inserted.

$historyResult = mysql_query("SELECT id FROM mediatable WHERE userId = $userId ORDER BY id ASC");

if(mysql_num_rows($historyResult) >= 20)
{
    $historyResult = mysql_query("SELECT id FROM mediatable WHERE userId = $userId ORDER BY id ASC LIMIT 1");
    $historyRow = mysql_fetch_row($historyResult);
    mysql_query("DELETE FROM mediatable WHERE id = '$historyRow[0]'");
}

mysql_query("INSERT INTO mediatable (userId, mediaId) VALUES ($userId, $mediaId))");

I’m now converting the site to more modern code and will be using pdo queries, my quesiton is:

Is the above a good way to approach this or should I use another method such as a MySQL trigger on insert?

Answer 1

If you are really interested in maximum speed, there’s also the extremely performant option of not checking how many rows are there in the first place and having a cleanup operation prune them in the background. Whenever you want to insert a new row, simply do so directly. Whenever you fetch the most recent rows to display, use LIMIT 20.

A garbage collector process can run independently of this as often as you want it to, looking for users with more than 20 history records and deleting the oldest appropriately. This way you have a guaranteed lower bound for recent history items (provided they have been created at some point) and an unlimited but quite low in practice amount of old history records awaiting pruning. You can decide on the collection frequency as you prefer.

On the other hand, if it’s not absolute performance that you are after then a check from PHP should be fine — provided that you change it to do SELECT COUNT(*) FROM mediatable WHERE userId = $userId when looking how many ids already exist. This way it’s also easier by far to modify your retention strategy down the road.

Update: Garbage collection strategies to consider

1. Scheduled GC: Collection happens periodically, most likely on a fixed schedule. Typically this is implemented as a cron job or scheduled task, depending on OS. Advantages include reliability and the option to use historical data to significantly decrease the standard deviation of items waiting to be pruned. Additionally, cleanup is not associated with (and should not block) any one user request; this eliminates the (typically rare) occasion where a user has to wait for GC to be completed before their content becomes available.
2. Probabilistic GC: Collection is triggered randomly. Your application specifies a set of actions that can trigger GC (e.g. creating a new history item) and a probability for GC to be triggered whenever any action in the set occurs; collection can happen as part of processing the action, or the collector can be a separate process that is launched on demand. The most significant advantage is that no setup external to your application is required, which may not be as important if your app is not meant to be widely distributed. Adjusting the GC probability while taking into account the mean number of triggering actions per unit of time allows you to target (albeit coarsely) a desired interval between successive collections.