Conception de base de données MySQL - Stockage des images - Table unique ou plusieurs tables

Question

Je travaille actuellement dans un produit où différents types d'images comme des images de produits, des images de profil utilisateur, logo, etc. sont là. J'ai besoin d'une base de données avec de bonnes performances de requête.

J'ai deux conceptions de DB en tête.

OPTION 1. - Stockage toutes les images dans une seule table avec id, titre, url_full, url_thumb, statut et champ d'horodatage

Avantages

1. Je peux utiliser seul fichier ImageModel à insérer supprimer/mettre à jour les données. Il n'y aura donc pas de logique multiple pour le stockage d'images. C'est juste une logique unique, "stocker dans une seule table". Donc, chaque fois que l'image doit être sauvé, je peux appeler la méthode de ImageModel

Inconvénients

1. S'il y a beaucoup d'images de produits et moins d'images de l'utilisateur, l'interrogation de l'image utilisateur devient lente en raison au grand nombre de produits.

OPTION 2. - Stockage différents types d'images dans différentes tables avec id, titre, url_full, url_thumb, statut et champ d'horodatage

Avantages

1. Augmentation du nombre de dossiers dans une section n'affectera pas la vitesse de requête d'autres

Inconvénients

1. doit écrire des fichiers de modèle séparés/fonctions pour chaque type d'image.
2. Chaque fois qu'une image doit être stockée, le type doit être spécifié.

Ma question est, qui est la meilleure approche. Est-ce que les avantages et les inconvénients sont une préoccupation réelle. S'il y a d'autres avantages/inconvénients, veuillez les énumérer. Ou s'il y a d'autres conceptions de Dieu db, s'il vous plaît suggérer.

S'il vous plaît répondre basé sur le scénario pratique où il y a beaucoup de produits et d'utilisateurs.

Answer 1

Cela a commencé comme un long commentaire, j'ai donc décidé de le poster comme une réponse. Stocker différents types d'images dans différentes tables me semble être une mauvaise idée. D'abord, comment cette conception va-t-elle évoluer si, par exemple, de nouveaux types de catégories apparaissent plus tard? Seriez-vous capable de gérer l'ajout d'un nombre arbitraire de nouvelles tables d'images? De plus, l'interrogation de toutes les images nécessiterait une série de jointures ou d'unions, ce qui pourrait être coûteux.

Vous avez mentionné l'avantage suivant un schéma de la table d'images multiples:

Augmentation du nombre d'enregistrements dans une section ne sera pas affecter la vitesse de requête d'autres

Si vous utilisez une seule image table avec un index sur la colonne type, puis augmenter le nombre d'enregistrements d'un type n'augmentera pas nécessairement l'interrogation des images d'un second type. Et voici un inconvénient à une seule table d'image que vous avez donné:

S'il y a beaucoup d'images de produits et moins d'images utilisateur, l'interrogation de l'image utilisateur deviendra lente en raison du grand nombre de produits.

Il est vrai que l'ajout d'enregistrements ralentira généralement l'interrogation. Cependant, avoir un index approprié sur le type devrait grandement diminuer ce problème.

Une table d'image unique avec des indices appropriés semble beaucoup mieux.

Answer 2

Comment livrerez-vous les images? Si c'est par <img src=http:...> alors il n'y a qu'une réponse: des fichiers séparés. Oui, les vignettes peuvent être effectuées par d'autres mécanismes, tels que la conversion en base64 et l'inclusion dans la balise img. Ce pourrait être le meilleur si vous avez beaucoup de vignettes sur la page. Mais avoir les vignettes dans le même tableau que les colonnes que vous interrogez pourrait être mauvais pour la performance. Nous devons donc voir les requêtes et le schéma de la table (tel qu'il se présente jusqu'à présent). "Bonne performance de requête" - S'il vous plaît nous montrer les requêtes;