J'ai été embauché pour aider à écrire une application qui gère certaines informations pour l'utilisateur final. Il est destiné à gérer quelques mégaoctets d'informations, mais aussi à gérer les images numérisées en pleine résolution. Ce projet devrait-il utiliser une base de données, et pourquoi ou pourquoi pas?Quelle est l'importance d'une base de données dans la gestion de l'information?
Une question "Devrais-je utiliser un outil donné?" revient à demander exactement ce que vous voulez faire. Vous devriez vous demander - "Est-ce que je veux écrire mon propre stockage pour ces données?"
La plupart des applications Web sont écrites sur une base de données car la plupart des bases de données prennent en charge de nombreuses fonctionnalités «gratuites» - vous pouvez avoir plusieurs serveurs Web. Vous pouvez utiliser des outils standard pour éditer, vérifier et sauvegarder vos données. Vous pouvez avoir une solution de stockage robuste avec des transactions.
Ma réaction viscérale est "pourquoi pas?" Une base de données va fournir un cadre pour stocker des informations, avec toutes les fonctions d'entrée/sortie/optimisation fournies dans un format documenté. Vous pouvez utiliser une solution côté serveur ou une base de données locale telle que SQLite ou la version locale de SQL Server. Dans les deux cas, vous disposez d'un cadre de gestion de données robuste et documenté.
This post devrait vous donner la plupart des opinions que vous avez besoin de stocker des images dans la base de données. Voulez-vous dire aussi "dois-je utiliser une base de données pour les autres informations?" ou vous posez simplement des questions sur les images?
Notre CMS stocke toutes les images de chèques que nous traitons. Il utilise une base de données pour les métadonnées et permet au système de fichiers de gérer les images numérisées. Une base de données simple comme SQLite semble appropriée - elle vous permettra de stocker des métadonnées de fichiers d'une manière transactionnelle cohérente. Ensuite, stockez le chemin d'accès à chaque image dans la base de données et laissez le système de fichiers faire ce qu'il fait de mieux: gérer les fichiers.
SQL Server 2008 a un nouveau type de données construit pour les fichiers dans la base de données, mais avant que BLOB était le moyen de stocker des fichiers dans la base de données. À petite échelle, ça marcherait aussi.
La base de données ne vous aidera pas beaucoup à traiter les données d'image elle-même, mais tout ce qui gère un tas d'images va avoir des méta-données sur les images que vous allez traiter. Selon les méta-données et ce que vous voulez en faire, une base de données peut être très utile avec cela. Et juste parce que la base de données ne vous aide pas beaucoup avec les données d'image, cela ne signifie pas que vous ne pouvez pas stocker les images dans la base de données. Vous les stockez dans une colonne BLOB d'une base de données SQL.
Si la quantité de données est faible ou installée sur de nombreuses machines clientes, il se peut que vous ne souhaitiez pas l'en-tête d'une base de données.
Est-il prévu d'être installé sur de nombreuses machines d'utilisateurs? L'ajout de la surcharge de s'assurer que vous pouvez exécuter n'importe quel moteur de base de données que vous choisissez sur une application installée par le client n'est pas optimal. Étant donné que la quantité de données est petite, je pense que XML serait adéquat ici. Vous pourriez Base64 encoder les images et les stocker comme CDATA.
L'application sera-t-elle exécutée sur un serveur? Si vous avez des utilisateurs simultanés, les bases de données ont des concepts pour gérer ces scénarios (transactions), ce qui peut être utile. Et les données d'image numérisées seraient appropriées pour un BLOB.
Une base de données est destinée à gérer de gros volumes de données et est supposée vous donner un accès rapide pour lire et écrire ces données malgré leur taille. En termes simples, ils gèrent l'échelle pour l'échelle de données que vous ne voulez pas traiter. Si vous n'avez que quelques utilisateurs (des centaines?), Vous pouvez tout aussi bien gérer les données sur disque (disons XML?) et gardez les données en mémoire. Les images ne doivent clairement pas entrer dans la base de données, donc la question est combien de données, ou pour combien d'utilisateurs maintenez-vous cette instance de base de données?
Si vous souhaitez disposer d'un moyen structuré pour stocker et récupérer des informations, une base de données est certainement la voie à suivre. Il rend votre application plus souple et plus puissante, et vous permet de vous concentrer sur l'application réelle plutôt que sur des incidents comme essayer d'écrire votre propre système de stockage.
Pour les applications individuelles, SQLite est génial. Il s'intègre bien dans une application en tant que fichier; pas besoin d'un mastodonte DRBMS entier.
Il y a beaucoup de facteurs à cela. Mais, étant une weenie de base de données, je me tromperais du fait d'avoir une base de données. Cela rend la vie plus facile quand les choses changent. et les choses vont changer. En fonction des images, vous pouvez les stocker sur le système de fichiers ou les blober et les placer dans la base de données (non pris en charge dans tous les SGBD). Si les fichiers sont très petits, je les bloberais. Si elles sont grandes, alors je les garderais sur le système de fichiers et les gérerais vous-même.
Il ya tellement de SGBD gratuits ou bon marché qu'il n'y a vraiment aucune excuse pour ne pas en utiliser un. Je suis un mec SQL Server, mais si votre application est aussi simple, alors la version gratuite de mysql devrait faire l'affaire. En fait, il y a des trucs sympa là-dedans.
Vous ne devez pas stocker d'images dans la base de données, comme c'est le consensus général here.
Le système de fichiers est beaucoup mieux à stocker les images que votre base de données.
Vous devez utiliser une base de données pour stocker des méta-informations sur ces images, telles qu'un titre, une description, etc., et simplement stocker une URL ou un chemin vers les images.
Quand il s'agit de stocker des images dans une base de données, j'essaie de l'éviter. Dans votre cas de ce que je peux rassembler de votre question il y a une possibilité pour un nombre substantiel d'images assez grandes, donc je serais probablement fort opposé à cela.
S'il s'agit d'une application Web j'utiliserais une base de données pour une recherche rapide et l'indexation des images en utilisant des mots-clés et d'autres paramètres. Ensuite, avoir une colonne pointant vers l'emplacement de l'image dans un système de fichiers si possible avec une sorte de structure de dossier pour aider à réduire davantage le temps de chargement de l'image.
Si vous avez besoin d'une plus grande sécurité en raison de la disponibilité du répertoire (partage réseau) et que l'application est locale, vous devez probablement prendre la bonne décision et stocker les images dans la base de données.