Est-ce une mauvaise pratique de stocker des fichiers volumineux (10 Mo) dans une base de données?

188

Je crée actuellement une application Web qui permet aux utilisateurs de stocker et de partager des fichiers, d'une taille allant de 1 à 10 Mo.

Il me semble que le stockage des fichiers dans une base de données ralentira considérablement l’accès à la base de données.

Est-ce une préoccupation valable? Est-il préférable de stocker les fichiers dans le système de fichiers et d'enregistrer le nom de fichier et le chemin d'accès dans la base de données? Existe-t-il des meilleures pratiques relatives au stockage de fichiers lorsque vous travaillez avec une base de données?

Je travaille en PHP et MySQL pour ce projet, mais le problème est le même pour la plupart des environnements ( Ruby on Rails , PHP , .NET ) et des bases de données (MySQL, PostgreSQL ).

B Seven
la source
9
Question connexe sur DBA.SE: Fichiers - dans la base de données ou non?
Nick Chammas
11
Surpris que personne n'ait publié la recherche MS effectuée sur ce problème (pour SQL Server 2008): To BLOB ou not To BLOB: Stockage d'objets volumineux dans une base de données ou un système de fichiers
Date limite:
2
grand est une quantité relative, je (et beaucoup d’autres probablement) ne le voit pas 10MBaussi grand dans un système moderne.
27
Ceci est sujet selon la FAQ - il s'inscrit dans les puces "modèles de conception" (antipatterns slash) et "architecture logicielle". Pourquoi était-il fermé?
Izkata
21
Je ne vois pas de vague dans la question telle qu'elle est maintenant. Je ne sais pas pourquoi c'était fermé.
Reinierpost

Réponses:

139

Raisons en faveur du stockage de fichiers dans la base de données:

  1. La cohérence ACID, y compris l'annulation d'une mise à jour, ce qui est compliqué lorsque les fichiers sont stockés en dehors de la base de données. Cela ne doit pas être passé sous silence. La synchronisation des fichiers et de la base de données et la possibilité de participer à des transactions peuvent s'avérer très utiles.
  2. Les fichiers vont avec la base de données et ne peuvent en être orphelins.
  3. Les sauvegardes incluent automatiquement les fichiers binaires.

Raison contre le stockage de fichiers dans la base de données:

  1. La taille d'un fichier binaire diffère selon les bases de données. Sur SQL Server, lorsque vous n'utilisez pas l'objet FILESTREAM, par exemple, il s'agit de 2 Go. Si les utilisateurs ont besoin de stocker des fichiers plus volumineux (comme un film, par exemple), vous devez passer à travers des étapes pour que cette magie se concrétise.
  2. Augmente la taille de la base de données. Un concept général à prendre à cœur: le niveau de connaissances requis pour gérer une base de données augmente proportionnellement à sa taille.C'est-à-dire que les grandes bases de données sont plus compliquées à gérer que les petites bases de données. Le stockage des fichiers dans la base de données peut rendre la base de données beaucoup plus grande. Même si, disons, une sauvegarde complète quotidienne aurait suffi, avec une base de données plus grande, vous ne pourrez peut-être plus le faire. Vous devrez peut-être envisager de placer les fichiers dans un groupe de fichiers différent (si la base de données le permet), modifiez les sauvegardes pour séparer la sauvegarde des données de la sauvegarde des fichiers, etc. Aucune de ces choses est impossible à apprendre, mais ajoute de la complexité à la maintenance, ce qui entraîne des coûts pour l'entreprise. Les grandes bases de données consomment également plus de mémoire lorsqu'elles essaient de stocker autant de données que possible dans la mémoire.
  3. La portabilité peut être un problème si vous utilisez des fonctionnalités spécifiques au système, telles que l' FILESTREAMobjet SQL Server, et si vous devez migrer vers un autre système de base de données.
  4. Le code qui écrit les fichiers dans la base de données peut être un problème. Une entreprise pour laquelle j'ai consulté il n'y a pas si longtemps, a récemment connecté une interface Microsoft Access à son serveur de base de données et a utilisé la capacité d'Access pour télécharger "n'importe quoi" à l'aide de son contrôle Ole Object. Plus tard, ils ont changé pour utiliser un contrôle différent qui reposait toujours sur Ole. Beaucoup plus tard, quelqu'un a changé l'interface pour stocker le binaire brut. Extraire ces objets Ole était un nouveau niveau d'enfer. Lorsque vous stockez des fichiers sur le système de fichiers, aucune couche supplémentaire n'est impliquée pour envelopper / ajuster / modifier le fichier source.
  5. Il est plus compliqué de servir les fichiers sur un site Web. Pour le faire avec des colonnes binaires, vous devez écrire un gestionnaire pour diffuser le fichier binaire à partir de la base de données. Vous pouvez également le faire même si vous stockez des chemins de fichiers, mais vous n'êtes pas obligé de le faire. Encore une fois, l'ajout d'un gestionnaire n'est pas impossible, mais ajoute à la complexité et constitue un autre point d'échec.
  6. Vous ne pouvez pas tirer parti du stockage en nuage. Supposons qu'un jour, vous souhaitiez stocker vos fichiers dans un compartiment Amazon S3. Si ce que vous stockez dans la base de données sont des chemins de fichiers, vous avez la possibilité de les changer en S3. Autant que je sache, cela n'est possible dans aucun scénario avec aucun SGBD.

OMI, considérer que le stockage des fichiers dans la base de données est ou non "mauvais" nécessite davantage d'informations sur les circonstances et les exigences. La taille et / ou le nombre de fichiers seront-ils toujours petits? Ne prévoyez-vous pas utiliser le stockage en nuage? Les fichiers seront-ils servis sur un site Web ou un exécutable binaire, comme une application Windows?

En général, mon expérience a montré que le stockage des chemins est moins coûteux pour l'entreprise, même en tenant compte du manque d'ACID et de la possibilité d'orphelins. Cependant, cela ne signifie pas qu'Internet ne soit pas légion et que le manque de contrôle ACID ne tourne pas rond avec le stockage de fichiers, mais cela signifie en général que cette solution est plus facile à créer, à comprendre et à maintenir.

Thomas
la source
Pourquoi ne pouvez-vous pas utiliser les CDN? Il s’agit d’un scénario compatible avec pratiquement tous les CDN dont j’ai entendu parler.
Billy ONeal
@BillyONeal - Vous ne pouvez pas utiliser un CDN et stocker le fichier dans la base de données. À moins que vous ne soyez d'accord avec la duplication, vous ne pouvez pas avoir les deux.
Thomas
3
Euh, tout l'intérêt d'un CDN est la duplication. Les CDN mettent simplement en cache la cible d'une adresse Web. La seule condition requise est qu'un hôte HTTP serve le contenu et que le contenu change rarement. (Comment le CDN est-il supposé dire où vous avez tiré cette image?)
Billy ONeal,
3
@BillyONeal - Cependant, je pense que c'est un mauvais choix de mots de ma part et j'ai ajusté ma réponse. Plus précisément, si vous souhaitez utiliser le stockage en nuage (et peut-être utiliser un CDN avec votre stockage en nuage), vous ne pouvez pas le faire de manière native avec la solution de stockage de base de données. Vous devez écrire une routine de synchronisation pour extraire les fichiers de la base de données, puis les envoyer à votre fournisseur de stockage en nuage.
Thomas
@BillyONeal - D'une certaine manière, votre commentaire était la meilleure réponse. Vous pouvez bénéficier de tous les avantages du stockage de base de données, mais aucun des problèmes.
B Seven
89

Dans de nombreux cas, c'est une mauvaise idée. Cela va gonfler les fichiers de la base de données et causer plusieurs problèmes de performances. Si vous collez les gouttes dans une table avec un grand nombre de colonnes, c'est encore pire.

Pourtant! Certaines bases de données, telles que SQL Server, ont un type de colonne FILESTREAM. Dans ce cas, vos données sont en réalité stockées dans un fichier séparé sur le serveur de base de données et seul un identifiant du fichier est enregistré dans la table. Dans ce cas, je ne vois pas beaucoup de raisons de ne pas conserver les données sur le serveur SQL. Les fichiers sont automatiquement inclus dans la sauvegarde du serveur, et la base de données et les fichiers ne sont jamais désynchronisés. Le problème avec la suggestion de Tony de stocker les noms de fichiers est que la base de données et le système de fichiers peuvent ne plus être synchronisés. La base de données affirmera qu'un fichier existe lorsqu'il a été supprimé sur le disque. Si un processus modifie la base de données puis se bloque, les fichiers et la base de données ne correspondront pas (c.-à-d. Aucun ACID avec des fichiers en dehors d'une base de données).

Timothy Baldridge
la source
21
Je ne suis pas d'accord avec la déclaration `Si un processus modifie la base de données et qu'il se bloque, les fichiers et la base de données ne correspondront pas.` Si vous enveloppez l'ensemble du processus dans une transaction (créez un fichier, validez le fichier, mettez à jour la base de données) et envoyez des messages d'erreur quand quelque chose ne va pas, il est assez facile de les synchroniser.
briddums
3
Je suis avec briddums à ce sujet: envisager un scénario: stocker le fichier sur le système de fichiers (sans supprimer l'ancien), mettre à jour la base de données, en cas de suppression de l'ancien fichier, lors de la suppression du nouveau fichier. Dans le pire des cas, si le processus est interrompu, vous avez un fichier orphelin. Mais vous avez toujours les fichiers référencés par DB dans la version correcte.
vartec
2
Autres problèmes potentiels liés à la méthode File / DB: 1) vous devez effectuer des mises à jour en copie sur écriture. Si votre processus se bloque lors d'une mise à jour, le statut de la base de données sera annulé, pas le fichier. 2) Faire cela nécessite alors une sorte de ramasse-miettes de l'ancien fichier. 3) Tout stocker dans la base de données signifie que les versions de la base de données et des fichiers sont synchronisées après les sauvegardes. Restaurez votre base de données dans son état il y a 2 semaines ... maintenant, quel est le contenu des fichiers à cette époque?
Timothy Baldridge
3
@briddums - Nope, puisque SQL Server s’intègre directement dans le système de fichiers et gère ces fichiers pour le compte du système d’exploitation. Je ne les ai pas utilisées moi-même, mais la documentation donne l’impression que FILESTREAM et ses descendants, FileTables, vous offrent le meilleur des deux mondes: les fichiers sont étroitement liés à la base de données et les données associées (vous permettant de gérer vos données de manière centralisée) sans alourdir le contenu. base de données.
Nick Chammas
1
Je suis d'accord avec Nick. Nous avons remplacé notre système Disk + DB par des colonnes FILESTREAM et nous n'avons jamais regardé en arrière. C'est vraiment agréable de pouvoir relier des fichiers à d'autres tables via des FK. Vous pouvez donc dire "chaque personne doit être associée à un ou plusieurs documents HR", ou quelque chose comme ça.
Timothy Baldridge
35

Oui, c'est une mauvaise pratique.

Impact sur les performances de la base de données:

  • si vous utilisez une SELECTcolonne BLOB, vous aurez toujours un accès disque, tandis que sans BLOB, vous aurez une chance d'obtenir des données directement à partir de la RAM (la base de données à haut débit sera optimisée pour s'adapter aux tableaux dans la RAM);
  • la réplication sera lente, le délai de réplication élevé, car il devra pousser BLOB vers les esclaves. Un délai de réplication élevé entraînera toutes sortes de conditions de concurrence et d'autres problèmes de synchronisation, à moins que vous n'en teniez explicitement compte;
  • Les sauvegardes / restaurations de bases de données prendront beaucoup plus de temps;

Avantage de vitesse - aucun ! Bien que certains systèmes de fichiers plus anciens ne gèrent pas correctement les répertoires contenant des millions de fichiers, la plupart des systèmes modernes ne rencontrent aucun problème et utilisent en fait le même type de structures de données que les BD (généralement les arbres B). Par exemple, ext4 (système de fichiers Linux par défaut) utilise Htree .

Conclusion: cela gênera les performances de votre base de données et n'améliorera pas les performances de récupération des fichiers.

, Puisque vous aussi parler de l' application Web - service de fichiers statiques directement à partir de système de fichiers en utilisant webserver moderne, qui peut faire sendfile()syscall est énorme amélioration de la performance. Ceci n'est bien sûr pas possible si vous récupérez des fichiers de la base de données. Considérons par exemple ce point de référence montrant que Ngnix fait 25 000 req / s avec 1 000 connexions simultanées sur un ordinateur portable bas de gamme. Ce type de charge ferait frire n'importe quel type de DB.

vartec
la source
6
+1 Laissez votre serveur Web faire ce qu’il fait de mieux, en servant des fichiers à partir du disque. Ne le faites pas demander à PHP, car PHP devra demander à MySQL, etc.
deizel
3
Quand les programmeurs apprendront-ils que la performance n'est pas tout ce qui compte?
reinierpost
2
@reinierpost: lol. probablement lorsque nous aurons des majors des arts libéraux ;-)
vartec
1
@BillyONeal: pourquoi supposez-vous que vous devez avoir le même serveur pour le contenu statique et dynamique? En ce qui concerne la synchronisation des fichiers sur les serveurs, il existe des outils spécialement conçus à cet effet, beaucoup plus efficaces que les bases de données. Utiliser une base de données comme serveur de fichiers revient à essayer d’enfoncer un clou avec un tournevis.
vartec
1
@BillyONeal: Je suis d'accord pour dire qu'il existe des "solutions" pour résoudre ce problème. J'ai vu pas mal de configurations PHP amateurs avec des images en MySQL. Cependant, dans une telle configuration, une base de données ne prendra jamais en charge les BLOB à trafic élevé.
vartec
18

Je serais pragmatique à ce sujet et suivrais le principe "ne pas optimiser pour le moment". Définissez la solution qui a du sens pour le moment et que vous avez les ressources de développement à mettre en œuvre correctement. Il y a beaucoup de problèmes potentiels . Mais ceux-ci ne deviennent pas nécessairement de vrais problèmes. Par exemple, ce ne serait probablement pas un problème si vous avez 100 utilisateurs. Cela pourrait être un problème si vous avez 100 000 ou 10 000 000 utilisateurs. Mais dans ce dernier cas, il devrait y avoir une base pour plus de ressources de développement pour traiter toutes les questions.

Mais stocker les données dans la base de données vous évite de traiter d'autres problèmes, par exemple, où les fichiers doivent-ils être stockés, comment doivent-ils être sauvegardés, etc. Comme vous écrivez une application Web, ce serait une très bonne idée pour des raisons de sécurité. pour vous assurer que le processus hébergeant l'application n'a pas d'accès en écriture au système de fichiers, vous devez donc configurer le serveur de sorte que ce processus dispose d'un accès en lecture / écriture au dossier dans lequel les données sont stockées.

Personnellement, je choisirais de stocker les données dans la base de données, mais je m'assurerais que les BLOBS ne sont pas lus tant qu'ils ne sont pas nécessaires, c'est-à-dire qu'aucun "SELECT * FROM ..." n'est exécuté sur les tables contenant des blogs. Et je m'assurerais que la conception facilite le déplacement des données de la base de données vers le système de fichiers si vous rencontrez des problèmes de performances. Par exemple, stockez les informations sur le fichier dans une table de fichiers distincte , gardant ainsi les informations du fichier à l'écart des autres entités commerciales.

En supposant que vous ayez une classe File pour représenter un fichier lu dans la base de données, l'impact de son déplacement ultérieur sur le codage sera minime.

Pete
la source
C'est une excellente suggestion. Ne commencez pas à résoudre des problèmes que vous n'avez pas.
Heavy
16

Microsoft a publié un livre blanc à ce sujet il y a quelques années. Il se concentre sur SqlServer, mais vous pouvez y trouver des informations intéressantes:

BLOB ou pas BLOB? Stockage de gros objets dans une base de données ou un système de fichiers?

Une version très concise de leur conclusion est la suivante:

Lors de la comparaison du système de fichiers NTFS et de SQL Server 2005, les serveurs BLOB de moins de 256 Ko sont gérés plus efficacement par SQL Server, alors que NTFS est plus efficace pour les BLOB de plus de 1 Mo.

Je vous recommanderais de rédiger de petits tests pour votre cas d'utilisation particulier. Gardez à l'esprit que vous devez vous méfier des effets de cache. (J'ai été stupéfait la première fois que j'ai obtenu des vitesses de sauvegarde sur disque qui semblaient avoir des débits plus élevés que physiquement possible!)

Benjol
la source
4
Vous devez savoir que NTFS commence à se comporter de manière très aléatoire lorsque vous mettez plus de ~ 100 000 fichiers dans un seul répertoire. L'accès aux fichiers ralentit un peu (au moins un ordre de grandeur) et les opérations d'ouverture de fichiers échouent (apparemment) de manière aléatoire. J'ai expérimenté cet effet sur les systèmes Windows 2008 et Windows 7. Lorsque j'ai redistribué des fichiers entre plusieurs répertoires, tout est revenu à la normale. Je ne sais pas si la situation s'est améliorée depuis.
Ferruccio
11

La sagesse conventionnelle de stocker des fichiers en dehors de la base de données pourrait ne plus être valable. Par principe, je privilégierais l’intégrité au détriment de la vitesse, et avec un SGBD moderne, vous pouvez avoir les deux.

Tom Kyte semble être d' accord :

Je ne connais aucun avantage à stocker des données que je souhaite conserver pendant longtemps en dehors d'une base de données.

Si c'est dans la base de données je peux

assurez-vous qu'il est géré professionnellement

sauvegardé

récupérable (avec le reste des données)

sécurisé

évolutif (essayez de mettre 100 000 documents dans un seul répertoire, maintenant, mettez-les dans un tableau - lequel "met à l'échelle" - ce n'est pas le répertoire)

Je peux facilement restaurer (flashback)

J'ai un verrouillage

J'ai lu la cohérence ...

Branko Dimitrijevic
la source
8

Oui.

Si vous servez un fichier à partir de votre système de fichiers, votre serveur Web peut utiliser un code du noyau tel que sendfile () sous BSD ou Linux pour copier le fichier directement dans le socket. C'est très rapide et très efficace.

Servir des fichiers en dehors de la base de données signifie que vous devez copier les données du disque du serveur de base de données dans la mémoire du serveur de base de données, puis de la mémoire du serveur de base de données vers le port réseau du serveur de base de données, puis du processus réseau vers le processus de votre serveur Web, puis de nouveau vers le serveur. connexion réseau sortante.

Sauf si vous avez une très bonne raison de ne pas le faire, il est toujours préférable de servir des fichiers statiques à partir du système de fichiers.

Evan P.
la source
C'est vrai, mais je ne vois pas où l'utilisateur indique dans la question qu'il servira des fichiers statiques à partir de la base de données. Cela peut très bien être des fichiers dynamiques ou des fichiers téléchargés par l'utilisateur qui, s'ils sont stockés sur le système de fichiers séparé de la base de données, doivent maintenant être synchronisés et avoir un processus de sauvegarde / restauration séparé.
maple_shaft
1
Si j'ai bien compris, la question concerne la fourniture de fichiers téléchargés par l'utilisateur. "Je crée actuellement une application Web qui permet aux utilisateurs de stocker et de partager des fichiers [...]. Il me semble que stocker les fichiers dans une base de données [...]". Je ne pense pas que ce soit vraiment pratique de faire des vidages de base de données avec beaucoup de blobs de plusieurs mégaoctets dans la base de données. Aussi: oui, il est difficile de gérer des fichiers; la synchronisation, l'archivage, sont tous plus difficiles. Cependant, ce n'est pas beaucoup plus difficile, et sacrifier les performances en ligne pour enregistrer quelques lignes dans votre script de sauvegarde nocturne est une grave erreur.
Evan P.
5

Le célèbre Tom Kyte a écrit qu’ils (Oracle) utilisaient la base de données Oracle comme serveur de fichiers et que cela fonctionnait parfaitement, même plus rapidement que le système de fichiers normal, avec une transaction complète, sans perte de performances et avec une sauvegarde unique.

Oui, mais attention, ils sont le producteur de la base de données Oracle. Pour tout autre utilisateur, il existe des problèmes de coûts. L'utilisation d'une base de données commerciale telle qu'Oracle pour le stockage de fichiers est tout simplement inefficace.

Cependant, avec PostgreSQL par exemple, vous pouvez simplement exécuter une autre instance de base de données uniquement pour le stockage d'objets blob. Vous avez alors un support transactionnel complet. Mais la transposition coûte de l’espace DB. Il est nécessaire que la base de données stocke plusieurs instances de blob pour plusieurs transactions simultanées. Sous PostgreSQL, c'est le plus pénible, car cette base de données stocke les doublons de blobs créés pour une transaction, même s'ils ne sont plus nécessaires, jusqu'à la fin du processus VACUUM.

Avec le stockage de système de fichiers, par contre, vous devez faire très attention lorsque quelqu'un modifie le fichier, car la transaction peut être annulée et la copie du fichier doit être conservée jusqu'à ce que l'ancienne version ne soit plus visible.

Dans le système où les fichiers sont uniquement ajoutés et supprimés, et où l'accès transactionnel aux fichiers n'est pas un problème, le stockage du système de fichiers sera à mon humble avis le meilleur choix.

Marin danubien
la source
Bonjour, quand vous dites "utiliser ... Oracle pour le stockage de fichiers est tout simplement inefficace", que se passe-t-il si nous utilisons déjà Oracle pour stocker d’autres données que des fichiers? Sera-t-il toujours rentable?
Xiao Peng - ZenUML.com
RE: "vous devez faire très attention lorsque quelqu'un modifie le fichier" ... en tant qu'ancien administrateur de base de données Oracle, je dois suggérer que les fichiers volumineux soient conservés en dehors de la base de données et que vous ne les autorisiez jamais à être modifiés. Les gens font des fautes. Le seul moyen pratique de gérer la restauration (annulation) de ces fichiers consiste à implémenter un système de copie sur écriture. Toutes les versions sont donc maintenues et archivées. Les plus anciennes peuvent être déplacées vers un stockage distant, post-traitées pour regrouper de petites modifications dans une archive, etc.
DocSalvager
5

Il est généralement préférable de stocker de grands objets BLOB dans une table séparée et de conserver une référence de clé étrangère à l'objet BLOB dans votre table principale. De cette façon, vous pouvez toujours extraire le fichier de la base de données (vous n’avez donc pas besoin de code spécial) et vous évitez les problèmes liés aux dépendances externes à la base de données (synchronisation de la base de données et du système de fichiers, etc.), mais vous n’engagez que de la surcharge si vous vous connectez explicitement à cette table (ou effectuez un appel séparé). 10Mo n'est pas très volumineux, la plupart des bases de données commerciales modernes n'auront pas de problème. La seule raison pour laquelle je stocke un fichier dans le système de fichiers est la réduction de la bande passante de la base de données. Si votre base de données doit mélanger un grand nombre de ces fichiers, vous devrez peut-être fractionner la charge de travail et ne stocker qu'un descripteur de fichier. Ensuite, vous pouvez avoir un appel séparé pour charger le fichier depuis un autre serveur,

RGT
la source
4

Vous pourriez rencontrer certains de ces problèmes:

  • Faire une opération SELECT *qui implique la rangée avec le gros blob prend très longtemps, même si vous n’avez pas besoin du blob (Bien sûr, vous devriez faire un select spécifique, mais parfois les applications sont écrites comme ça)
  • Faire une sauvegarde peut prendre beaucoup plus de temps. En fonction de vos besoins, vous devrez peut-être verrouiller vos tables pendant la durée de la sauvegarde. Par conséquent, vous voudrez peut-être limiter votre temps de sauvegarde.
  • La restauration prendra également beaucoup plus de temps.
  • Si vous manquez d'espace, vous devez trouver un moyen (peut-être de déplacer l'ensemble de la base de données sur un nouveau serveur) pour résoudre ce problème. En stockant les fichiers sur le système de fichiers, vous pouvez toujours monter un autre disque dur et définir des liens symboliques.
  • Rechercher dans un fichier pour le débogage ou d'autres informations n'est pas aussi facile. Cela inclut également les scripts qui n'ont peut-être pas accès à la base de données, mais qui nécessitent des informations provenant de différents fichiers.

Bien sûr, vous bénéficiez également d'avantages:

  • Sauvegarde des données et des fichiers, ils sont synchronisés
  • Supprimer le fichier sans que la base de données sache n'est pas possible
  • Vous n'êtes pas obligé de lire le fichier à partir du disque mais vous pouvez le faire en une seule instruction SQL
  • Vous pouvez télécharger la base de données, inclure le dump dans votre environnement de développement et avoir toutes les dépendances à cet endroit.

Personnellement, je ne le fais pas car je trouve les inconvénients beaucoup plus lourds que les avantages. Mais comme indiqué ci-dessus, cela dépend totalement de votre cas d'utilisation, etc.

Sgoettschkes
la source
1

Certains systèmes de gestion de contenu Enterpirse, tels que SiteCore, utilisent une base de données pour stocker les données de page et une autre base de données pour stocker des fichiers. Ils utilisent MS SQL Server.

šljaker
la source
Comment cela répond-il à la question posée?
moucher
Si vous faites quelques recherches, vous découvrirez que SiteCore est l’un des systèmes de gestion de contenu d’entreprise les plus populaires. SiteCore prend en charge un grand nombre d'utilisateurs simultanés et évolue assez bien. Par conséquent, le stockage de fichiers dans une base de données séparée n'est pas une mauvaise pratique si vous le faites correctement.
Joueur
1

Pour la mise en œuvre pratique, voici ce qui peut vous préoccuper:

Bénéfices:

  1. Tout le contenu du fichier est définitivement synchronisé avec votre table. Comme indiqué ci-dessus, la sauvegarde des données est tout à fait pratique car vous n'avez pas besoin de les synchroniser avec le système de fichiers.
  2. À partir du codage, vous pouvez obtenir le contenu du fichier directement à partir d’une sélection SQL.
  3. À partir d'une requête, vous pouvez même filtrer explicitement le contenu du fichier ou sa taille à partir d'une instruction SQL.

Inconvénients:

  1. Comparée à une base de données dont la structure est sémantiquement identique mais ne stocke pas le contenu du fichier, votre base de données a tendance à consommer beaucoup plus de mémoire lorsque vous effectuez une requête.
  2. La sauvegarde automatique peut causer des problèmes de performances, mais pas beaucoup. Imaginons que votre serveur de base de données sauvegarde toutes les 6 heures et que vos bases de données stockent des fichiers de 10 Mo par enregistrement. Ce scénario n'est pas ce que vous voulez.
PataoEngineer Tao
la source