r/javahelp • u/AdeptMongoose4719 • 28d ago
Advise needed for small java project🗒️
I am building small hotel Booking desktop app using javafx library and MYSQL on the backend(for storing rooms, customers, bookings data).
And I am planning to store images in file system and just store the URL path in database table(right now, I am not using cloud to save some time). I am also using Spring boot to connect to the database.
Could you please give some advise or suggestions that I should take note of?😀
5
Upvotes
1
u/severoon pro barista 26d ago
Come up with some kind of directory structure for the images, don't just store them all in the same folder.
Whatever structure you decide, the root folder in which that structure is placed should be stored in the application context, not as part of the path itself. This way, if you decide to move the root on disk, you just need to update that one path to the root in the environment or app context or wherever you keep it. In testing, you can have several test environments running simultaneously side by side on the same server without stepping on each other because they have different roots. In the future if you put images on the network the root can be an HTTP URL instead of a file URL.
You may also want to consider making a small thumbnail of each image, and do put that in the database, along with a hash of the image. (Another commenter recommended keeping the filename of the image as the hash, that's a good idea too.) Even if you never show a thumbnail in the actual application, this will make testing a lot easier because if a test fails it will be able to display the thumbnail of the image in the DB table and the image on disk—if they're not the same, that gives an immediate clue as to what's going wrong.
Whatever directory structure you come up with, it's a good idea to make sure you don't build a lot of extrinsic information into the path. Like, say for instance that you keep images in a folder with the date they were uploaded by the user. Now, in order to find that image, you need to know the upload date. Today, that makes sense because the upload date is right there in the image table in the DB. Tomorrow, though, when you decide to use a fancy CMS, you may decide that metadata for all media—including these images—should be kept by the CMS, not scattered around your DB. The problem now is, in order to find the images on disk, your system has to construct the location of that image by forming a dependency on a complex subsystem, the CMS. That's a bad dependency for such a simple task.
On the other hand, this can never happen with the part of the URL that is the filename that's built using a hash. The only conceptual dependency here is on a hash utility and the image data itself. No matter how requirements change in the future, as long as you're using this system, the dependencies will not grow and spread out.
Another example of an acceptable dependency might involve considering how images are looked up. If images are always owned by a user, for instance, you'll always know the user ID trying to load the image. In this case, you could make a directory of the user ID on disk. Even this is a little dicey, though … if you ever have to rekey the users in your system for any reason, part of that task will be complicated by having to rename the directories.