Quel est le meilleur moyen de sauvegarder et de récupérer des fichiers binaires avec Oracle 10g?

Question

Je suis sur le point d'implémenter une fonctionnalité dans notre application qui permet à l'utilisateur de "télécharger" un document PDF ou Microsoft PowerPoint, que l'application mettra ensuite à la disposition des autres utilisateurs dans un visualiseur (afin qu'ils ne puissent pas "télécharger" dans le sens "Enregistrer sous ..").

Je sais déjà comment enregistrer et récupérer des informations binaires arbitraires dans des colonnes de base de données, mais comme il s'agira d'une fonctionnalité couramment utilisée de notre application, je crains que cette solution ne conduise à des tables de base de données extrêmement volumineuses (car nous savons qu'un de nos clients vouloir mettre la vidéo dans des documents PowerPoint).

Je sais qu'il existe un moyen de créer un objet "répertoire" dans Oracle, mais existe-t-il un moyen d'utiliser cette fonctionnalité pour stocker et récupérer des fichiers binaires enregistrés ailleurs sur le serveur de base de données?

Ou suis-je trop paranoïaque à propos de la taille de la base de données?

(pour être complet, notre application est .Net WinForms utilisant les pilotes CoreLab / DevArt OraDirect.Net pour Oracle 10g)

Answer 1

Quelques options: vous pouvez placer la colonne BLOB dans son propre espace de table, avec ses propres caractéristiques de stockage; vous pouvez stocker les objets BLOB dans leur propre table, liée à l'autre table par une colonne ID. Dans les deux cas, comme vous l'avez suggéré, vous pouvez définir la colonne en tant que fichier BFILE, ce qui signifie que le fichier réel est stocké en externe à partir de la base de données dans un répertoire. Ce qui pourrait être une préoccupation, c’est que les fichiers BFILE LOB ne participent pas aux transactions et ne sont pas récupérables avec le reste de la base de données.

Tout cela est décrit dans la référence SQL d'Oracle 10gR2, chapitre 2, à partir de la page 23.

Answer 2

Je suppose que cela dépend de ce que vous considérez comme extrêmement important.

Cela dépend vraiment du cas d'utilisation. Si les documents ne sont que rarement consultés, il serait judicieux de les insérer dans la base de données (avec l’avantage d’obtenir des sauvegardes "gratuites", par exemple avec la base de données).

Si ce sont des fichiers qui vont être consultés encore et encore, vous feriez peut-être mieux de les mettre directement sur le disque et de ne stocker que l'emplacement, ou même = "http://fr.wikipedia.org/wiki/MogileFS" rel = "nofollow noreferrer"> MogileFS

Personne ne pourra vous répondre par oui ou par non.

Answer 3

Vous pouvez utiliser un type de colonne LOB normal et définir les paramètres de stockage de ce champ afin qu'il se trouve sur un espace de table séparé. Créez un espace de table quelque part qui puisse gérer des quantités énormes de données et vous en minimiserez l'impact.

Pour être vraiment très paranoïaque à propos de l'utilisation du disque, vous pouvez également compresser le tablespace en le marquant comme tel. Quelque chose dans le genre de:

CRÉER UN ESPACE TABLES   binary_data1 FICHIER DE DONNÉES   une_emplacement_san STOCKAGE PAR COMPRESSE PAR DEFAUT (...)

Answer 4

D'après mon expérience, un simple champ VARCHAR2 contenant le nom de fichier des pièces jointes constitue une solution plus simple et plus efficace. La taille du système de fichiers est beaucoup plus facile à gérer que la taille de la base de données.

Answer 5

Les données doivent vivre quelque part, qu'elles soient internes à la base de données ou que vous stockiez simplement un lien vers un chemin de fichier accessible au serveur (serveur), vous continuez de mâcher de l'espace.

Je viens d'utiliser des champs LOB simples dans le passé, cela semblait bien fonctionner. Si vous conservez au moins les données dans la base de données, vous réduirez au minimum vos tracas de sauvegarde. Vous aurez peut-être beaucoup de données à sauvegarder, mais lorsque vous les restaurerez, tout sera là. La division du fichier binaire signifie que vous risquez de casser la base de données ou de perdre des données si vous ne faites pas attention à ce que vous sauvegardez.

Answer 6

Une raison de ne stocker que le lien ou un ID pouvant être utilisé pour le créer est que le stockage que vous utilisez habituellement pour les bases de données Oracle est plutôt coûteux. Si vous avez beaucoup de fichiers volumineux, il est généralement beaucoup plus économique de les placer sur un tableau de disques moins coûteux.