Comment amener la coordination entre le système de fichiers et la base de données?

Question

Je travaille sur un projet de gestion de fichiers en ligne. Nous stockons des références sur la base de données (serveur sql) et fichiers les données sur le système de fichiers.

Nous sommes confrontés à un problème de coordination entre le système de fichiers et la base de données lorsque nous téléchargeons un fichier et également en cas de suppression d'un fichier. Nous créons d'abord une référence dans la base de données ou stockons les fichiers sur le système de fichiers. Le problème est que si je crée d'abord une référence dans la base de données et que je stocke ensuite un fichier sur le système de fichiers, mais que des fichiers sont stockés sur le système de fichiers, la référence de ce fichier est créée. base de données mais aucune donnée de fichier n'existe sur le système de fichiers.

S'il vous plaît donnez-moi une solution comment faire face à une telle situation. J'en ai vraiment besoin.

Ce cas se produit également pendant la suppression d'un fichier?

Answer 1

Traitez les deux événements (gestion de la référence et gestion du fichier) comme une transaction unique. Si l'un des deux échoue, retirez l'autre. Ensuite, vous devriez avoir du mal à entrer dans une situation où les deux ne sont pas synchronisés. Il est plus facile de restaurer les opérations de base de données que les opérations du système de fichiers.

Answer 2

L'accès au système de fichiers n'est en effet pas transactionnel. Vous devrez simuler une transaction distribuée tout ou rien: si la validation dans la base de données échoue, supprimez le fichier sur le système de fichiers. Inversement, si l'écriture d'un fichier échoue, la transaction de base de données de rollback (Ce sera un peu plus compliqué, mais c'est une ébauche).

Notez que cela peut devenir compliqué quand un fichier est mis à jour. Vous devez d'abord le copier, de sorte que si la transaction de base de données échoue après avoir écrasé le fichier, vous pouvez toujours restaurer l'ancienne version du fichier. Si vous voulez faire cela dépend du niveau de la robustesse que vous souhaitez. Essayez d'appliquer toutes les manipulations à travers votre application (créer, écrire, supprimer des fichiers). Si vous ne pouvez pas faire cela et que vous ne pouvez pas empêcher un fichier d'être directement accessible sur le système de fichiers (et peut-être supprimé), je ne vois pas d'autre moyen que de synchroniser périodiquement la base de données avec le système de fichiers. l'entrée dans la base de données. Vous pouvez créer un travail qui exécute chaque X minute pour cela.

Je suggère également de stocker un hachage (par exemple MD5) du fichier dans la base de données. Prenez un peu de temps pour le calculer, mais cela m'a été extrêmement utile pour détecter des problèmes, par ex. si le fichier est renommé sur le système de fichiers par erreur mais pas dans la base de données. Cela permet aussi d'effectuer périodiquement un contrôle d'intégrité, pour vérifier que rien n'a été foutu.

Si cette approche n'est pas suffisante (par exemple, vous voulez qu'elle soit plus robuste), je ne vois pas d'autre moyen que de stocker le binaire dans la base de données en LOB. Ensuite, ce sera vraiment transactionnel et sûr.

Answer 3

Une vieille question que je sais, mais au profit d'autres lecteurs:

En fonction de vos systèmes d'exploitation, vous pourrez peut-être utiliser transactionnelles TxF

http://msdn.microsoft.com/en-us/magazine/cc163388.aspx

Answer 4

FILESTREAM a été introduit dans SQL Server 2008 pour résoudre ce problème.

Cependant, il vient avec son propre ensemble de implementation challenges.