Conseils généraux nécessaires - Comment implémenter les pièces jointes de fichiers d'enregistrement dans ASP.NET?

Question

J'ai une application qui aura environ 25 000 enregistrements lorsque l'importation de données initiale est terminée. Ces enregistrements auront chacun 1 à 3 «pièces jointes» associées (.doc, .pdf, etc.). Quelqu'un peut-il me donner des conseils sur la façon de mettre en œuvre cette fonctionnalité? Plus précisément, où stockez-vous les fichiers et comment les organiseriez-vous?

Je suis réticent à les stocker directement dans la base de données, car cela entraînerait une énorme base de données. Est-ce que cela semble être une préoccupation valable? Si oui, je ne pense pas que je voudrais voir jusqu'à 100 000 fichiers dans un seul dossier non plus.

Answer 1

Je ferais une base de décision sur ce que vous voulez faire avec eux par la suite.

Les tailles ne sont pas vraiment un problème, et les chiffres ne le sont pas non plus. NTFS dépasse 2^32 entrées de fichier, donc 100k ne va pas transpirer. Et les frais généraux de SQL ajouteront peu à la valeur de 200 Go de données, donc il est peu probable que l'espace sera un facteur décisif. Les mêmes arguments que nous avons toujours sur si vous devez stocker dans le DB (verrouillage, attributs indexables/interrogeables, ACID, DB sécurité, sauvegarde/récupération connue, etc.) par rapport au système de fichiers (plus simple, légèrement plus petit, bien connu, peut se déplacer vers le stockage externe facilement, etc.) vont être le facteur décisif.

Answer 2

Il y a un groupe de personnes qui grincent des dents à la notation de stocker des fichiers dans une base de données. Si vous êtes l'une de ces personnes, vous pouvez adopter une approche similaire à celle ci-dessous.

Créer une table qui a stocké tous les fichiers associés à un enregistrement. Pour chaque fichier, créez une clé unique (j'utilise GUID) pour stocker dans cette table avec d'autres métadonnées de fichiers (nom de fichier, taille, emplacement, utilisateurs, dates, etc.). Stockez les fichiers sur le serveur.

Ceci vous permet d'avoir une source d'interrogation rapide pour les fichiers et vous permet également de déplacer des dépôts si vous en avez besoin.

Answer 3

Si vous pouvez utiliser SQL Server 2008, il dispose de la fonctionnalité "FILESTREAM". Vous pouvez définir une colonne comme type FILESTREAM et stocker le fichier sur le système de fichiers (peut-être sur un périphérique NAS). Vous pouvez ensuite soit lire les données vous-même pour les transmettre aux appelants, soit donner aux appelants le chemin du système de fichiers vers le fichier et les laisser le lire.

Answer 4

Stockez-les sur le système de fichiers. (Je pourrais pointer vers des centaines de publications pf avec le même conseil, et par expérience, vous êtes mieux à long terme, même si les fichiers sont petits pour commencer.)

Configurer un dossier que l'application Web a lire/écrire l'accès à et créer une page qui permet aux utilisateurs de télécharger dans ce dossier dans n'importe quelle structure logique est logique. En ce qui concerne la structure db, j'aurais une table séparée pour les attachements de fichiers avec une clé étrangère pointant vers l'enregistrement principal auquel ils sont associés.