Is it necessary to record the image paths in the database when it is associated with a unique item?

Question

In my web application, there are several classes whose instances need an image (i.e., photo). Each of these instances can have only one image. Currently, my implementation is that when user creates a new instance, I keep the name of the uploaded file as it is, and record it in the ImageUrl field of the associated table.

I feel like this is unnecessary. I can just rename the image with the unique url of the associated instance, and I can implement the programming logic accordingly. For example, if a user's id is 145, then I can record it with this name: profilephoto_145. Later, when I need to display the user's photo, all I need will be the id of the user. If user uploads a new file, I can just overwrite the existing file with the same name.

I wonder if this makes sense assuming each instance will have one associated image, and there will be no need to keep track of the previous files. What is the common approach for this? Should I keep the full path for each image and keep their original names, or should I implement this renaming files with ID?

Answer 1

I can just rename the image with the unique url of the associated instance, and I can implement the programming logic accordingly. For example, if a user's id is 145, then I can record it with this name: profilephoto_145.

Yes, you can do that. The general search term for this kind of thing is "tight coupling" or "coupling and cohesion". The concept applies in lots of different areas of software development.

Your underlying idea is that you'll always store one profile photo per user, and you'll store it by concatenating "some kind of path" and "profilephoto_" and user's id. The main problem is that any change to that idea requires changing source code. And changing source code has ripple effects.

The common alternative is to store the image file's name in a database. In this case, most changes to that underlying idea would require only a database update.

Programmers who have been around a while cringe a little when people start using words like always and never. Because we know that, given enough time, statements that use always and never with respect to software are always never true.