L'utilisation d'un serveur de base de données a-t-elle un sens si l'application ne fait que des choses localement?
J'ai vu des applications qui sont essentiellement des logiciels d'application qui s'exécutent localement sur le système (donc ils n'ont pas beaucoup de communication sur le réseau). Ces applications semblent dépendre des serveurs de bases de données pour stocker leurs données.
Un exemple d'application est Amarok (un lecteur de musique populaire sous Linux). Je ne sais pas s'ils le font toujours, mais je me souviens qu'il y avait un moment où l'installation d'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 SQL embarquée plus petite comme sqlite? Je parle de logiciels d'application en général, pas nécessairement amarok (c'était juste un exemple). Existe-t-il des situations où l'utilisation d'un serveur de base de données est logique par rapport à une base de données intégrée?
SQLite offre un assez bon aperçu de quand l'utiliser ou non vs alternatives:
https://www.sqlite.org/whentouse.html
Cette ligne récapitulative capture extrêmement bien le cas d'utilisation SQLite:
SQLite n'est pas en concurrence avec les bases de données client/serveur. SQLite est en concurrence avec fopen ().
L'article développe longuement sur ce point. Il contient également une section intitulée "Situations où un SGBDR client/serveur peut mieux fonctionner". En résumé, ce sont:
- Applications client/serveur : plusieurs utilisateurs sur un réseau.
- Sites Web à volume élevé : soit intensifs en écriture soit suffisamment intensifs en lecture pour nécessiter un partage.
- Ensembles de données très volumineux : plus grands que ce qui peut être raisonnablement stocké sur un disque.
- Haute concurrence : en particulier les écritures simultanées.
Même pour un seul système avec un seul utilisateur, un "vrai" serveur de base de données est logique:
- Il utilise un langage familier ( SQL ). SQLite utilise SQL, mais certaines bases de données intégrées (par exemple base de données d'objets , NoSQL ) n'utilisent pas SQL. Ceux-ci ont tendance à avoir une courbe d'apprentissage plus élevée car ils sont moins courants.
- Il fournit l'intégrité référentielle, les contraintes, les déclencheurs, etc. que des produits tels que SQLite peuvent ne pas fournir ou du moins ne pas fournir en totalité.
- En ciblant un véritable multi-utilisateur, ACIDE base de données réseau conforme, l'application a la possibilité de travailler dans un scénario mono-utilisateur/poste de travail unique, ou en multi -utilisateur, application hébergée utilisant la même base de code .
- 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. Bien qu'il soit possible de le faire avec de nombreuses bases de données intégrées de divers types, les gens peuvent être plus familiers avec ces outils du monde de la base de données C/S.
Le principal inconvénient est d'installer et de maintenir le logiciel du serveur de base de données, 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 facilitent la tâche: j'ai PostgreSQL et MySQL en cours d'exécution sur mon système Linux. J'ai installé des applications qui s'y sont connectées avec peu ou pas d'interaction de ma part.
Je pense que cela a à voir avec l'inertie.
Amarok est basé sur XMMS qui date de 1997. Pour avoir des capacités de base de données bonnes, il fallait utiliser un serveur, car il était tellement plus puissant que les solutions basées sur des fichiers, qui n'avaient en aucun cas de bonnes capacités de base de données.
La popularité prochaine et croissante des bonnes bases de données locales embarquées comme SQLlite est quelque chose d'assez récent.
La caractéristique de discrimination la plus importante est simultanéité.
Si vous n'avez qu'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'objets) est généralement OK.
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 seule écriture à la fois, dans toute la base de données, tout comme la plupart des autres solutions intégrées. Et si vous avez même 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.
De nombreuses autres réponses parlent de la simultanéité comme un avantage, mais aussi puisque la base de données s'exécute en tant que serveur, la base de données peut exécuter des tâches sans avoir besoin de l'application en cours d'exécution. Il peut s'agir de maintenance, de sauvegardes, de synchronisation avec un autre serveur ou de toute tâche planifiée.
Si vous pensez que votre application peut se transformer en application client/serveur, vous pouvez commencer par utiliser un SGBDR dès le début au lieu de le porter plus tard.
Je n'ai aucune idée si l'exemple donné en profite ou non.
À moins que vous exécutiez un système intégré avec une mémoire et un processeur faibles, je ne pense pas que l'exécution d'un serveur en arrière-plan vous fasse du mal.
L'exécution locale d'un serveur de base de données est correcte. La base de données est destinée à accéder aux données et à les manipuler. L'accès au réseau est un plus, qui peut être nécessaire ou non. Il existe des outils d'ingénierie et scientifiques qui permettent cela.
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 des données et de l'espace d'application global, des exigences de gestion des accès, de l'investissement que vous prévoyez pour la maintenance des données, de l'urgence du prototype requis, de votre situation dans la courbe d'apprentissage, etc.
Si vous souhaitez assurer une base de données étroitement intégrée à une application qui ne nécessite pas d'accès à partir d'autres applications, créer des îles de base de données intégrée. La mise en œuvre de Mozilla Firefox Web Storage avec SQLite pourrait être donnée à titre d'exemple.
Si vous avez besoin d'encore plus d'efficacité avec des données limitées, une sélection de conception de bases de données en mémoire est préférable.
D'un autre côté, si plusieurs applications exécutent plusieurs requêtes sur les mêmes données et que cela nécessite une meilleure structuration du stockage des données pour optimiser les performances, un SGBD centralisé est requis. Je le préférerai absolument pour la recherche scientifique, quand elle nécessite une énorme quantité de données et où le temps de réponse aux requêtes aura un impact considérable sur l'expérience globale de l'utilisateur.
Pour le cas d'Amarok, je suppose que c'était une sélection de SGBD open source à l'époque, avant de choisir le chemin des bases de données intégrées.
S'il y a une définition de système spécifique à portée de main, il sera plus facile de peser les inconvénients et les avantages.
V/r, Umut