Je me demandais quelle est la meilleure façon de stocker des utilisateurs de télécharger des images comme un avatar, etc., en utilisant PHP et MySQL? Où devrais-je commencer? Et y a-t-il un bon article à ce sujet? P>
7 Réponses :
Voici un Exemple de stocker l'image en binaire sur une base de données MySQL. Je ne suis pas trop sûr s'il y a des avantages ou non à cela. Je laisserai cela pour quelqu'un d'autre commenter. p>
Une autre façon de le faire est de stocker l'emplacement de l'image dans une colonne et de la questionner pour référencer. p>
Oui, je conseillerais contre cela, à moins d'une raison quelconque, les images doivent être sécurisées. En faisant de cette façon, l'image doit d'abord être extraite de la base de données, puis le binaire est traité. Cela augmentera la charge sur le serveur PHP ainsi que le serveur MySQL. Votre deuxième conseil est meilleur; Stockez l'image dans un dossier d'images utilisateur, peut-être les nommer avec UNIQID (), puis référence à l'URL relative dans la DB.
Si j'étais vous, je voudrais simplement enregistrer l'image quelque part dans votre répertoire de sites, puis enregistrer le lien vers l'image dans MySQL, si vous souhaitez vraiment l'enregistrer dans une base de données, je le lirais dans une chaîne puis base64_encode (), puis enregistrez-la dans la base de données. P>
Il y a toutes sortes de petits problèmes auxquels vous ferez face en les stockant dans une base de données, vous devrez créer des scripts pour les faire écho à ECT, et que le serveur et la charge de la base de données seront considérablement augmentés. Si j'étais vous, je stockais simplement la référence. P>
Je suggère d'avoir une table où vous stockez des données utilisateur telles que le nom d'utilisateur, prénom. Dans cette table, créez un champ appelé quelque chose comme "Avatar" dans lequel vous pouvez stocker une référence de fichier. P>
Assumer que vos avatars utilisateur sont stockés dans: htdocs / images / avatars / Et l'utilisateur Apikot a l'avatar "avatar.jpg" stocké à nouveau son utilisateur dans la base de données, vous pouvez ensuite compiler l'URL suivante lors de la génération d'une étiquette d'image: "/htdocs/images/avatars/avatar.jpg". P>
Créer un champ de type BLOB et insérez le résultat de fichiers_get_contents ($ imagefile) p>
"meilleur" dépend de ce que votre objectif est. P>
Les deux principales méthodes principales de stocker des images téléchargées par l'utilisateur sont soit mettre le contenu binaire dans la base de données comme une blob, soit en stockant les images sur le lecteur quelque part et mettre une entrée dans la base de données indiquant quelle image appartient où. P >
Placer les images de la base de données présente l'avantage de ne nécessitant aucune sorte d'autorisations de système de fichiers sur le serveur Web et supprime toutes sortes de problèmes de synchronisation si vous servez le site de plusieurs serveurs WebsserVers. Cependant, au fil du temps, il rend votre base de données énorme et si vous ne concevez pas vos tables correctement, il peut absolument tuer vos performances et votre évolutivité. p>
Stockage des images Comme le fichier du système de fichiers présente l'avantage supplémentaire de la récupération extrêmement rapide et efficace, car les serveurs Web sont très bons pour servir des fichiers statiques. P>
édité pour ajouter strong> p>
Si vous décidez de stocker du contenu du fichier dans la base de données, ne le mettez absolument pas dans une table à laquelle il faut accéder rapidement. Si, par exemple, vous avez une table "utilisateurs" qui est recherchée sur presque chaque pageView, alors cette table est pas em> l'endroit pour mettre votre contenu de fichier. Au lieu de cela, créez une table distincte de "images" ou "fichiers" contenant le fichier et les méta-informations associées. p>
Mettre beaucoup d'octets par rangée dans une table rend cette table très lente à travailler avec. Vous ne voulez pas ce genre de chose dans des tables qui voient une utilisation intensive. P>
Si vous allez utiliser une base de données, c'est une très bonne idée. Et pour alléger la charge sur la table d'images, en utilisant MemCache pour mettre en cache les images aideraient également.
Corollaire: Si votre contenu de fichier doit être consulté rapidement, ne le stockez pas dans la base de données.
Les images doivent vraiment être stockées sur le système de fichiers pour quelques raisons: P>
Proxies de proxyation et de modification si modifiée - Les demandes Web: b> Apache peuvent traiter si des en-têtes HTTP modifiés pour vous et renvoient une réponse 304, et c'est à propos des meilleures performances que vous pouvez obtenir . Les procurations et procurations postées par les Squid inverse sur les FAI tenteront de tirer parti de cela. P> li>
Numérisation du virus: b> Si vous autorisez tous les téléchargements de fichiers, Serks essaiera de télécharger des trucs effrayants pour voir si elles peuvent casser votre site. Ce n'est pas déraisonnable de vouloir exécuter Clamav ou similaire contre vos téléchargements pour voir s'il y a des problèmes à pied. Vous ne voudriez pas organiser votre base de données si vous vouliez numériser les enregistrements de logiciels malveillants. P> li>
Schéma Simplicity: B> Si vous autorisez les téléchargements de fichiers, vous devez également ajouter des métadonnées sur le type MIME, la taille du fichier, la hauteur et la largeur. Si le fichier lui-même ne correspond pas au type MIME dans la table, vous devez coder un SELECT dans la table et le diffuser dans Thumb-clouage: b> Les téléchargements d'images utilisateur sont susceptibles de devoir être cloués au pouce, ce qui est souvent beaucoup plus facile à faire de manière asynchrone à la demande Web réelle. Ce n'est vraiment pas amusant quand il s'agit bien de l'utilisateur tente de télécharger un fichier de photoshop de 150 Mo de photoshop qui leur est donné par son photographe professionnel, et votre instance Apache se passe à OOM lorsque vous essayez de charger la bibliothèque ImageMagick dans l'espace mémoire du workier Web. Cela n'échappe vraiment pas aux travailleurs Apache. Créez une file d'attente de travail / un travail cron en dehors de Apache pour gérer ce travail. P> LI>
La corruption de table: b> WOW, vous ne voulez pas vraiment paralyser tous les avatars utilisateur si votre fichier d'index MySQL est bougé et que vous devez effectuer une réparation de table hors ligne sur cette table. < / p> li>
sauvegarde et restauration: b> Vous ne voulez pas vraiment verrouiller une grande table avec MySqldump. L'utilisation de RSYNC vous fera gagner beaucoup de temps et vous donnera beaucoup plus de flexibilité. Les tables sont généralement restaurées une table entière, des tables de temps ne sont pas typiquement sauvegardées en pièces plus petites. P> Li>
ul> / usr / bin / fichier code>. Il peut être beaucoup plus simple de shell_exec ("/ usr / bin / path / path / to / mumble") code>. P> li>
créer un nouveau répertoire sur votre serveur pour chaque utilisateur avec l'ID utilisateur étant le nom du répertoire et enregistrer les images de l'utilisateur à l'intérieur. Chaque fois que vous souhaitez afficher l'image de l'utilisateur:
<img src="<path>/users_images/<user_id>/thumb.gif" />