When should I make this direct recording at the bank?
What are the situations?
I know I can save the image path to the bank.
When should I make this direct recording at the bank?
What are the situations?
I know I can save the image path to the bank.
In addition to cost being higher as mentioned, one must take into account several factors:
There are several strategies for scaling a system both in terms of availability and volume. Basically these strategies consist of distributing them on several different servers and redirecting the user to each of them according to some criteria. The details vary from implementation, such as: data update strategy, redundancy, distribution criteria, etc.
One of the great difficulties in managing files outside BD is that we now have two distinct data sources that need to be always in sync.
From the safety point of view, there is actually little difference. If a hacker can compromise a server, it can read both the files written to disk of your system and the files of the database system. If this question is critical, an alternative is to store the encrypted data.
However, whenever I did the best solution type analysis, the use of the file system has always been to a great advantage.
It's not wrong ... most developers avoid doing this, as usually the cost of database space is often much larger than the cost of storage.
So the ideal is that you use storage to store large masses of data, and the relational database to store structured data.
But imagine that you do not do this, and that you always use a local database ... in this case, you can store in the database, that will not make a difference. But still, I think it would be easier to write in the form of a file ... using the very language it is using. This is usually a much easier operation than saving in the bank.
With this strategy of writing to storage and referencing using a path, you will have to manage integrity manually ... which can also prove to be quite difficult:
delete the files when the associated record no longer exists
Ensure that the file is not deleted as long as there is a record pointing to it
Ensure the atomicity of creating a record along with the file
You can write image bytes directly to the database when your concerns do not include:
However, saving the image path to the database can lead to certain difficulties in managing backups, restores, and access permissions.
In short , the best practice depends on the characteristics of your application and your operational needs, taking into account the database used, the file system, and the data request flow. >
In addition to what everyone mentioned here, it is interesting to write to the database when you need to ensure the integrity of the data record with the image / file as well as decrease the surface of access to images on a file system.
For example: When a record in the base can never exist without an associated image. For example 3x4 photo of an identity or a radiography and its award, etc ...
This decision should be based primarily on nonfunctional analysis of your solution.
You can save the images to the database without problem. Here in the service we have a bank of 1.5T, with 95% being of images. But it is necessary to check the reason for this decision. In my case, safety is a priority. Do a study on security, network, amount of access, file manager for your purpose. From experience, if possible, only record the path as it says and store it on disk. Depending on the size of your database, these images will be much worse than managing backups and replications than on disk.
I have already made a system that synchronized image with the respective data in the bank, saving the filename of the image in a field varchar of the bank and saving the image with the code of the registry in the bank to relate.
It is perfectly possible to synchronize image file with database, however this depends much more on the knowledge of the programmer than on the technology applied - it is not a ready business and to this day I have not yet heard of any project ready for that. All the image bank systems I've come across do not use a bank to store the images, but storage.
One thing that makes work difficult is creating an own mechanism for indexing images, which is important for sorting and searching images in a very efficient and flexible way (if you need to, of course). But I think in general this part is done through the database itself (a table can already serve as an indexer). I stumbled a lot in this part and found that here in Brazil we hardly find enough information to produce this type of system. It is necessary to understand even the proper file system to create an indexing file, as there will be a limit on file size ...