Stockage d'image dans la base de données directement ou sous forme de données base64?
La méthode habituelle pour stocker des images dans une base de données consiste à convertir l'image en données base64 avant de stocker les données. Ce processus augmentera la taille de 33%. Alternativement, il est possible de stocker directement l'image en tant que BLOB; par exemple:
$image = new Imagick("image.jpg");
$data = $image->getImageBlob();
$data = $mysqli->real_escape_string($data);
$mysqli->query("INSERT INTO images (data) VALUES ('$data')");
puis affichez l'image avec
<img src="data:image/jpeg;base64,' . base64_encode($data) . '" />
Avec cette dernière méthode, nous économisons 1/3 de l'espace de stockage. Pourquoi est-il plus courant de stocker des images au format base64 dans des bases de données MySQL?
MISE À JOUR: Il existe de nombreux débats sur les avantages et les inconvénients du stockage d'images dans des bases de données, et la plupart des gens pensent que ce n'est pas une approche pratique. Quoi qu'il en soit, ici, je suppose que nous stockons l'image dans une base de données et que nous discutons de la meilleure méthode pour le faire.
Pro base64: la représentation codée que vous gérez est une chaîne plutôt sûre. Il ne contient ni caractères de contrôle ni guillemets. Ce dernier point aide contre les tentatives d’injection SQL. Je ne m'attendrais à aucun problème à ajouter simplement la valeur à une chaîne de requête SQL "codée à la main".
Pro BLOB: le logiciel de gestion de base de données sait à quel type de données il doit s’attendre. Il peut optimiser pour cela. Si vous stockiez base64 dans un champ TEXT, il pourrait essayer de construire un index ou une autre structure de données, ce qui serait vraiment agréable et utile pour des données texte "réelles" mais inutile et une perte de temps et d'espace pour les données d'image. Et c'est la représentation la plus petite, en nombre d'octets.
Je soutiens que les images (fichiers) ne sont généralement pas stockées dans une base de données encodée en base64. Au lieu de cela, ils sont stockés sous leur forme binaire brute dans une colonne (ou un fichier) binaire (blob).
Base64 n'est utilisé que comme mécanisme de transport, pas pour le stockage. Par exemple, vous pouvez incorporer une image codée en base64 dans un document XML ou un message électronique.
Base64 est également convivial. Vous pouvez encoder et décoder à la volée (sans connaître la taille totale des données).
Bien que base64 convienne au transport, ne stockez pas vos images codées en base64 .
Base64 ne fournit aucune somme de contrôle ni aucune valeur d'aucune valeur pour le stockage.
L'encodage Base64 augmente les besoins en stockage de 33% par rapport au format binaire brut. Cela augmente également la quantité de données à lire du stockage persistant, qui reste généralement le principal goulot d'étranglement de l'informatique. Il est généralement plus rapide de lire moins d'octets et de les encoder à la volée. Si votre système est lié au processeur au lieu de IO, et que vous exportez régulièrement l'image en base64, envisagez de la stocker en base64.
Les images en ligne (images codées en base64 incorporées au format HTML) constituent elles-mêmes un goulet d'étranglement: vous envoyez 33% de données en plus par fil et le faites en série (le navigateur Web doit attendre les images en ligne avant de pouvoir télécharger la page) HTML).
Si vous souhaitez toujours stocker des images codées en base64, assurez-vous, quoi que vous fassiez, de ne pas stocker de données codées en base64 dans une colonne UTF8, puis de les indexer.
Je recommande de regarder des bases de données modernes comme NoSQL et aussi d’être d’accord avec le post de user1252434. Par exemple, je stocke quelques fichiers PNG <500 Ko en base64 sur ma base de données Mongo avec les données binaires définies sur true sans aucun impact sur les performances. Mongo peut être utilisé pour stocker des fichiers volumineux tels que des vidéos de 10 Mo, ce qui peut permettre de gagner beaucoup de temps lors de la recherche de métadonnées pour ces vidéos, voir stockage d'objets et de fichiers volumineux dans mongodb