There's a lot of opinion about storing BLOBs in a database and I wonder if there is any actual investigation or figures on the matter.
We have an application that stores images related to various entities such as user (their profile picture) and event (a photo of the event taking place). The application database table stores a file name such as 1234joesmith.png
in a column called image
and the our server-side code forms a complete URL from that to return to the front end, such https://ourapp.com/uploads/users/1234joesmith.png
. (This is obviously a security risk and I will be dealing with that problem separately.)
This I am sure has been done to avoid placing BLOBs in the database and slowing-down access to it. However, it precludes an architecture where we have multiple server-side instances with a load-balancer or other redundancy middleware, all using the same database (which could then be an AWS database instance, for example).
My suspicion is that the advice to keep BLOBs out of the database is based on old technology and is obsolete. For example, a mysql table row is limited to a total of 4kb, but BLOBs and TEXTs do not count towards that total, except that each such column adds a fixed few bytes only. Clearly then the BLOBs and TEXTs are stored indirectly and not placed inline in the table row. Obviously therefore the designers of mysql have considered the matter of storing BLOBs and will have minimised any overhead, so that it is not significantly different from filesystem access (I suspect).
So my question: where are the figures, the actual figures? and not hand-wavy "I would have thought" speculations, which I can make as well as the next person.