Est-il judicieux d’utiliser un serveur de base de données si l’application ne fait que localement?

J'ai vu des applications qui sont essentiellement des logiciels d'application qui s'exécutent localement sur le système (elles n'ont donc pas beaucoup de communication sur le réseau). Ces applications semblent dépendre des serveurs de base de données pour stocker leurs données.

Amarok (un lecteur de musique populaire sous Linux) est un exemple d'application. Je ne sais pas s'ils le font toujours, mais je me souviens qu'il fut un temps où installer Amarok signifiait que vous deviez installer un serveur MySQL et le faire fonctionner en arrière-plan tout le temps.

Quel est l'avantage d'utiliser un serveur pour le stockage local par rapport à l'utilisation d'une solution Embedded SQL plus petite comme sqlite? Je parle de logiciel d'application en général, pas nécessairement amarok (ce n'était qu'un exemple). Existe-t-il des situations dans lesquelles l’utilisation d’un serveur de base de données a du sens par rapport à une base de données intégrée?

SQLite offre un assez bon aperçu du moment de l’utiliser ou non par rapport aux alternatives:

https://www.sqlite.org/whentouse.html

Cette ligne de résumé capture extrêmement bien le cas d'utilisation de SQLite dans mon expérience:

SQLite ne concurrence pas les bases de données client / serveur. SQLite est en concurrence avec fopen ().

L'article se développe longuement sur ce point. Il comporte également une section intitulée "Situations dans lesquelles un SGBDR client / serveur peut mieux fonctionner". En un mot, ils sont:

• Applications client / serveur : plusieurs utilisateurs sur un réseau.
• Sites Web volumineux : vous pouvez soit écrire intensivement, soit lire suffisamment pour exiger un sharding.
• Très grands ensembles de données : plus gros que ce qui peut être raisonnablement stocké sur un disque.
• Concurrence élevée : notamment les écritures concurrentes.

Même pour un système unique avec un seul utilisateur, un "vrai" serveur de base de données a du sens:

1. Il utilise un langage familier ( SQL ). SQLite utilise SQL, mais certaines bases de données incorporées (par exemple , base de données objet , NoSQL ) n'utilisent pas SQL. Celles-ci ont tendance à avoir une courbe d'apprentissage plus longue car elles sont moins courantes.
2. Il fournit une intégrité référentielle, des contraintes, des déclencheurs, etc. que des produits tels que SQLite peuvent ne pas fournir ou du moins ne pas fournir totalement.
3. En ciblant une véritable base de données réseau conforme à ACID multi-utilisateurs, l'application peut opérer dans un scénario utilisateur unique / poste de travail unique ou en tant qu'application hébergée multi-utilisateurs utilisant la même base de code .
4. L’utilisateur a la possibilité d’examiner les données hors ligne à l’aide d’outils standard (par exemple, SQL Developer, MySQL Workbench, SQL Server Management Studio), de charger ou de sauvegarder des données à l’aide de ces outils, etc. Il est toutefois possible de le faire avec de nombreuses bases de données intégrées. types, les gens sont peut-être plus familiarisés avec ces outils du monde des bases de données C / S.

Le principal inconvénient est d'installer et de maintenir le logiciel du serveur de base de données, ce qui est un peu complexe pour les utilisateurs non techniques (et même pour de nombreux utilisateurs techniques). Les systèmes d'exploitation tels que Linux rendent cela plus facile: PostgreSQL et MySQL s'exécutent sur mon système Linux. J'ai installé des applications qui s'y sont accrochées avec très peu d'interaction.

Je pense que cela a à voir avec l'inertie.

Amarok est basé sur XMMS, datant de 1997. Pour disposer de bonnes capacités de base de données, vous deviez utiliser un serveur, car il était bien plus puissant que les solutions basées sur des fichiers, qui ne possédaient en aucun cas de bonnes capacités de base de données.

La popularité à venir et la popularité croissante de bonnes bases de données intégrées locales telles que SQLlite sont quelque chose d'assez récent.

La fonctionnalité discriminante la plus importante est la concurrence .

Si vous avez une seule application qui s'exécute dans une instance pour l'utilisateur, la solution intégrée (qu'il s'agisse de sqlite ou d'un stockage d'objet) est généralement correcte.

Toutefois, si plusieurs instances doivent manipuler la base de données simultanément, vous devez disposer d'un serveur pour la synchroniser. SQLite n'autorise qu'une écriture à la fois, dans l'ensemble de la base de données, de même que la plupart des autres solutions intégrées. Et si vous avez plusieurs applications, vous aurez probablement besoin de spécifications de contraintes plus détaillées que les solutions intégrées ne permettent généralement pas non plus.

La plupart des autres réponses parlent de la simultanéité comme un avantage, mais comme la base de données est exécutée en tant que serveur, la base de données peut exécuter des tâches sans que l'exécution de l'application ne soit nécessaire. Il peut s'agir de maintenance, de sauvegardes, de synchronisation avec un autre serveur ou de n'importe quelle tâche planifiée.

Si vous pensez que votre application peut se transformer en application client / serveur, vous pouvez commencer par utiliser un SGBDR à partir du début au lieu de le transférer ultérieurement.

Je ne sais pas si l'exemple donné tire parti de ceci ou non.

À moins que vous n'utilisiez un système embarqué avec peu de mémoire et de ressources processeur, je ne pense pas que faire fonctionner un serveur en arrière-plan vous fasse du mal.

L'exécution d'un serveur de base de données localement est acceptable. La base de données est conçue pour accéder aux données et les manipuler. L'accès au réseau est un plus, qui peut être nécessaire ou non. Certains outils techniques et scientifiques le font.

Supposons que vous utilisez des données, sur une application locale. Pourquoi ne devriez-vous pas utiliser une base de données? par opposition à quoi?

Cela dépend de votre abstraction de données et de votre espace applicatif global, des exigences en matière de gestion des accès, de l'investissement que vous envisagez pour la maintenance des données, de l'urgence du prototype requis, de votre position dans la courbe d'apprentissage, etc.

Si vous souhaitez garantir une base de données étroitement intégrée à une application ne nécessitant pas d'accès depuis d'autres applications, créez des îlots de base de données intégrée. L'implémentation de Mozilla Firefox Web Storage avec SQLite peut être donnée à titre d'exemple.

Si vous avez besoin d'efficacité supplémentaire avec des données limitées, une sélection de conception de bases de données en mémoire est préférable.

D'autre part, si de nombreuses applications exécutent plusieurs requêtes sur les mêmes données et qu'il est nécessaire de mieux structurer le stockage des données pour optimiser les performances, un SGBD centralisé est requis. Je le préférerai absolument pour la recherche scientifique, lorsque cela nécessite une grande quantité de données et que le temps de réponse à la requête affectera considérablement l'expérience globale de l'utilisateur.

Pour l’affaire Amarok, j’imaginais que c’était une sélection de SGBD à code source ouvert à ce moment-là, avant qu’ils choisissent le chemin des bases de données incorporées.

Si vous avez une définition spécifique du système, il sera plus facile de peser le pour et le contre.

V / r, Umut