Question

From Objective-C i’m used to Reference Counting / Retain Counting (same thing). I love this concept, and it’s plain simple.

So I thought, why not apply this to a database? The problem is:

Imagine these tables: users, photos. A user can own a photo, a user can like a photo of himself or someone else, and a user can recommend a photo. In any case there’s a reference created to the photo.

Now the big problem is: Lets say I want to get rid of any photo that belongs to nobody anymore. So a photo that is not owned by any user, is not liked by any user, and is not recommended by any user, has to be deleted. I have no idea how to do that with the plain database functionality 😉 well, maybe some hundred joins? I don’t know. Database noob.

So the idea I’d like to verify from DB experts: Imagine I add a reference_count field to every table which can be referenced (requires some thought upon setup, of course). As soon as I define a relationship from any table_a to any table_b, and table_a is supposed to be the parent or master (strong reference), I increase the reference_count of the linked row by 1.

Let’s say 150 users like a photo and one owns it. So it’s reference_count is 151. Now the owner gives it up but 150 others still scream “oh nooo, no no no!! it’s ours! we like it so muuucch!!”. The system looks once every midnight through all these tables and attempts to delete every row which has a reference count of 0. So after some days, the users get bored of it and remove their “I like it” flag. Every time this happens, the reference_count gets reduced by 1. At the end, it’s 0, and the next midnight when everyone is asleep, a cron job deletes it.

Of course, it must be configurable, because it must not always be the case that the photo has to get deleted after nobody references that anymore. I would solve this by setting it’s reference_count initially to 1, not 0.

This means of course a lot of additional db calls, I guess. So what do you think? Or are there better solutions for that?

Answer 1

You can do just the following:

DELETE
FROM    photos
WHERE   id NOT IN
        (
        SELECT  photo_id
        FROM    photos_users_like
        )
        AND id NOT IN (
        SELECT  photo_id
        FROM    photos_users_made
        )
        AND id NOT IN (
        SELECT  photo_id
        FROM    photos_users_recommended
        )

If you index your photo_ids in all tables, the NOT INs will be optimized by MySQL so that the predicates will return FALSE when the engine finds but a single matching record in the corresponding tables and there will be no need in reference counts.