Quelle est la meilleure façon de déterminer quand il convient d'utiliser une base de données?

J'ai commencé ma carrière en programmation dans le développement web en utilisant PHP et MySQL. Je me suis habitué à utiliser db pour le stockage de la plupart des données dynamiques ainsi que certaines données de réglage / paramètres. Parfois, il y avait beaucoup de données tandis que d'autres fois, les entrées dans les tableaux étaient peu nombreuses. Pour moi, cela semblait tout simplement naturel et, autant que je sache, c'est plus ou moins une approche acceptable dans le développement Web. (Corrigez-moi si j'ai tort, s'il-vous plait...)

Je plonge dans les applications de bureau maintenant et mon inclination naturelle est à nouveau d'utiliser une base de données pour stocker beaucoup d'informations qui seront générées par l'utilisation de l'application. Cependant, pour autant que je sache, je ne vois pas les applications (que j'utilise) utiliser un db très souvent. [EDIT: Il a depuis été souligné qu'il s'agissait d'une hypothèse erronée dans la mesure où de nombreuses applications utilisent des dbs légers intégrés dans le programme lui-même.] Quelle est la raison de cela? À quel moment est-il approprié d'utiliser une base de données? Existe-t-il des normes à ce sujet? Quelles sont également les raisons de NE PAS utiliser de base de données pour développer une application de bureau?

si votre application est orientée document, stockez les choses dans un fichier document

si votre application traite de données plus structurées, trop pour un seul document (comme un document XML), utilisez une base de données

Un système de base de données est traditionnellement considéré comme un service relativement lourd - que vous ne vouliez pas nécessairement installer sur chaque machine cliente. J'ai en fait été dans des situations (développement d'applications GUI de bureau où beaucoup de données devaient être enregistrées) où un vrai système DB aurait été une solution "idéale" - mais parce qu'à l'époque, les seules bases de données disponibles étaient relativement lourdes, nous avons opté pour des fichiers de données plats.

Malgré l'existence de bases de données plus légères ces jours-ci, il s'agit toujours d'un argument valable contre les bases de données côté client. Imaginez une petite application de bureau simple (par exemple, un simple jouet ou jeu de bureau) qui doit stocker quelques dizaines de réglages et paramètres. Il semble beaucoup plus difficile de faire installer MySQL à une personne juste pour exécuter votre application.

Avec le développement Web, le serveur est naturellement un back-end, où avoir une base de données est une évidence. par exemple. Les utilisateurs n'ont pas à s'inquiéter d'installer une base de données de leur côté.

Les applications de bureau conservent leur état pendant leur exécution. Alors que le développement Web ne fonctionne généralement pas. Ainsi, même si vous devrez peut-être stocker un paramètre utilisateur dans une base de données entre les chargements de page, dans une application de bureau, vous les gardez simplement en mémoire. Cela réduit considérablement le besoin de tels types de stockage persistant. Lorsque vous souhaitez stocker les préférences entre les utilisations, vous pouvez les enregistrer toutes dans un fichier ou les placer quelque part comme le registre Windows.

Cela étant dit, les systèmes de base de données sont beaucoup utilisés dans les applications de bureau. Bien avant le Web, les applications de bureau ont été connectées aux SGBD. Principalement pour les applications qui ne sont pas basées sur des documents. Bien que ces jours-ci, avec la meilleure disponibilité des moteurs légers, vous voyez les lignes un peu floues. Par exemple, j'utilise les bases de données SQLite comme documents dans quelques-unes de mes applications.

Vous voudrez peut-être examiner les bases de données légères qui ne nécessitent pas de service de base de données en cours d'exécution. Par exemple, sur le front de Microsoft, il y a SQL Server Compact , qui est gratuit, ne nécessite qu'un seul fichier pour la base de données et certaines DLL ajoutées à votre application, et du point de vue du développeur, se comporte de la même manière qu'un "vrai" SQL Server.

Je suis certain qu'il existe des options similaires sur d'autres plateformes.

Sur les applications Web, il est important de stocker tout état persistant sur un stockage centralisé. Étant donné que l'application Web est généralement le premier goulot d'étranglement, il est important de pouvoir simplement la distribuer sans avoir à se demander quelle copie contient les données (le principe `` Rien partagé ''). Pas seulement une base de données, mais les memcachedsystèmes de files d'attente sont là pour la même raison.

Les applications de bureau n'ont pas le même objectif d'évolutivité. En règle générale, la plupart des données sont stockées localement sur chaque poste de travail. Le partage des données est un problème différent dans la plupart des cas. Cela élimine une grande raison d'utiliser une base de données.

Les applications GUI peuvent également avoir des documents complexes qui peuvent être traités comme un réseau complexe d'objets en mémoire. La normalisation de la structure dans un schéma de base de données relationnelle peut ajouter une complexité importante au problème, il est parfois plus facile de simplement sérialiser le tout en un seul bytestream. De nombreux cadres OOP incluent des fonctionnalités rien que pour cela.

Pourtant, rendre les documents stockés lisibles avec des outils en dehors de l'application principale est un grand avantage dans de nombreux cas, donc soit en utilisant des formats lisibles par l'homme (XML, JSON, YAML, etc.), soit un fichier zip fusionnant plusieurs éléments plus simples deviennent de plus en plus plus commun.

Dans le même esprit, l'utilisation d'une bibliothèque de bases de données embarquables (BDB, Tokyo Cabinet, SQLite, MS-SQL * server Compact, etc.) est une autre excellente approche.

Les bases de données peuvent être excessives, mais elles ne le sont généralement pas . Les programmes très simples n'en ont tout simplement pas besoin. Si votre document peut se charger en mémoire en un temps record et y rester sans problème, vous n'en avez pas vraiment besoin pour de nombreux programmes.

Par exemple, considérez:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Eh bien, c'est trop simpliste, mais c'est évidemment trop. Il n'y a aucun intérêt à avoir ce niveau de gestion des données pour "Hello World"

Habituellement, la règle générale que j'utilise est d'utiliser une base de données si vous avez de nombreux ensembles de données, en particulier s'ils sont uniques ou d'utiliser une base de données si la quantité de données est plutôt massive. Les bases de données en général sont associées à certains frais généraux, mais il y en a beaucoup qui n'ont pas vraiment grand-chose. Les petites bases de données légères en mémoire, par exemple, sont parfois utiles pour les petits projets nécessitant un traitement, une planification ou de nombreuses modifications dynamiques des données.

Il existe différents styles de codage, plusieurs fois il n'y a rien de mal avec une base de données, mais la plupart d'entre nous n'iront pas «aussi loin» pour les tâches de base. Il y a encore d'autres fois où la bonne base de données offrirait des avantages en termes de performances. Essayez de comprendre en particulier les différences quant à l'emplacement des données, à leur durée et à leurs modifications au cours de leur durée de vie.

L'utilisation d'une base de données est toujours la bonne chose et avec les implémentations SQLite pour pratiquement tous les langages qui n'en utilisent pas, c'est juste une mauvaise prise de décision de conception. La seule raison de ne pas en utiliser un est si vous faites de la programmation intégrée ou un autre type de programmation sans application. Interroger des données et des paramètres avec un langage déclaratif comme SQL est beaucoup plus naturel que de parcourir des fichiers plats ou d'autres objets en mémoire avec une syntaxe impérative. De plus, il sépare proprement les opérations de données des autres codes d'application, ce qui à long terme rend le code plus modulaire et plus facile à gérer.