Is it wrong to write byte of images in the database?

In addition to cost being higher as mentioned, one must take into account several factors:

• Data volume : For a low volume of data there may be no problem. On the other hand, for mass storage of data the database is practically unfeasible. Ask Facebook or Google if they would use bank. Facebook, for example, uses a custom file system to make access even quicker and lessen the overhead per file required by traditional file systems.
• Clustering : One advantage of the database is if your system runs on multiple servers, everyone will have uniform access to the files. However, using a drive on the network to store the files.
• Availability : Will your system have lots of hits? This can overwhelm a traditional database. On the other hand, your HTTP server can use low-level file system access routines to send the stream of data to the client.
• Scalability : If volume or availability demand increases, can you add more capacity to the system? It is much easier to split files between different servers than to distribute records from one table to more servers.
• Flexibility : backing up, moving files from one server to another, doing some processing on the stored files, all this is easier if the files are in a directory. If you deploy in a client environment, the files on the disk do not make it impossible for you to receive copies of the database for testing. Try asking your client to send terabytes of data for you to review if there is a problem with the database.
• Read and write overhead : The computational cost to write to and read data from the database is greater than to read and write directly to a file.

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:

• Bank space (due to high cost)
• Access speed

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 ...