SQLite n'est-il pas un peu sous-estimé? [fermé]

15

Avant de poser la question, permettez-moi d'abord de décrire mes réflexions sur SQLite.

Il se trouve que j'aime les outils petits, rapides et, surtout, qui n'ont que les fonctionnalités vraiment nécessaires. C'est pourquoi j'aime SQLite et j'aime un peu moins MS-SQL.

Par exemple: MS-SQL peut avoir beaucoup plus de fonctionnalités, d'évolutivité, etc., etc., mais il peut également être difficile à installer si vous n'avez pas de chance. Bien sûr, je ne dis pas qu'une installation difficile est une raison pour ne pas choisir une base de données particulière.

Ne me comprenez pas mal: MS-SQL est un produit de haute qualité. Je suis très expérimenté avec MS-SQL; Je comprends très bien le produit en tant que professionnel. Je le préfère juste moins dans certaines circonstances où ce n'est pas vraiment nécessaire (= pas beaucoup d'utilisateurs, <10-15).

Quelle quantité de fonctionnalités d'une base de données utilisez-vous vraiment? D'après mon expérience, c'est souvent juste le SQL normal (SELECT, INSERT et UPDATE).

J'aime SQLite. Est fascinant rapide. Il est extrêmement facile à "installer". Je pense que SQLite peut faire plus que ce qu'il prétend. Pourquoi ne l'utiliser que pour des applications mono-processus / mono-utilisateur? Après tout: peu d'applications accèdent constamment à une base de données.

Par exemple: considérons une application ERP avec, disons, 15 utilisateurs. Pourquoi SQLite ne peut-il pas être utilisé pour cela? Avouons-le: dans mon expérience professionnelle, la plupart du temps, les utilisateurs de ce type d'application accéderont à la base de données pendant environ 5 à 10% du temps total d'utilisation de l'application. Dans les 90 à 95% restants, ils regardent simplement les informations à l'écran, saisissent les données dans une grille / formulaire et lorsqu'ils enregistrent leur entrée, cela ne représente pas plus d'une seconde de temps dans la base de données. Fe: 1,5 minutes de temps d'entrée contre 1 seconde de temps d'économie.

Si le fichier de base de données SQLite est verrouillé pendant le "temps d'économie", les autres utilisateurs qui doivent accéder à la base de données attendent simplement, mais ils ne le remarquent pas car le temps d'attente sera très petit (inaperçu). Dans le code, il suffit de gérer le temps "occupé" possible de la base de données, pour éviter les exceptions, mais ce n'est pas difficile à faire.

Un gars, qui doit penser la même chose que moi, a même construit une solution client-serveur pour SQLite: SQLitening . Cela m'a rendu plus convaincu que je ne me trompais peut-être pas.

Bien sûr, il existe des applications gourmandes en bases de données où SQLite ne convient pas. Mais comme j'y pense maintenant, de nombreuses applications multi-utilisateurs, si elles ne dépassent pas 15 utilisateurs environ, devraient très bien fonctionner avec SQLite.

Beaucoup de nos clients ne dépensent pas beaucoup en matériel, donc je rencontre souvent un serveur unique avec tout (Exchange, SQL (s), clients, etc.) et à cause de cela, ils sont presque "à bout de souffle". Si je pouvais livrer un produit qui n'a pas de configuration système élevée, mon client serait content. SQLite n'ajoute aucun poids (du moins pas beaucoup), MS-SQL le fait. Je ne choisirais donc pas SQLite car il est gratuit, bon marché ou facile à installer. Je le choisirais pour des raisons pratiques / techniques.

FYI: Dans ma profession, nous vendons des produits (personnalisés et standard, principalement liés à l'ERP) à des clients où, en moyenne, pas plus de 5-6 personnes utiliseront le produit. Il existe quelques exceptions, mais pas plus de 10 à 15 utilisateurs.

La question est: ai-je raison de penser que je peux utiliser SQLite pour certaines applications multi-utilisateurs comme l'exemple que je décris? Y a-t-il des inconvénients techniques que je devrais connaître? Quelles sont vos expériences (négatives ou positives) qui m'aideront à faire le bon choix?

Mise à jour: veuillez ne pas voir cela comme un jugement négatif sur d'autres bases de données. Ce sont surtout des produits fins. Je partage juste mes pensées ici et je suis intéressé par vos opinions à ce sujet.

database database-development
la source
9
Désolé, mais en ajoutant "Ai-je raison?" ne transforme pas une diatribe en question.
pdr
1
@pdr: Pourquoi considérez-vous cela comme une diatribe? Je ne juge pas négativement MS-SQL ou d'autres bases de données; ce sont surtout des produits fins. Je partage juste mes réflexions et je suis intéressé à entendre les opinions des autres programmeurs. Ni plus ni moins.
3
Il n'y a pas de question là, seulement une recherche de validation. De la FAQ: "Vous ne devez poser que des questions pratiques et fiables basées sur les problèmes réels auxquels vous êtes confronté. Les questions ouvertes et bavardes diminuent l'utilité de notre site et repoussent les autres questions de la première page." programmers.stackexchange.com/faq
pdr
1
@pdr: Je comprends cela, mais je voulais honnêtement poser une question ici. Peut-être que je n'étais pas clair, j'ai donc reformulé la question.
4
Choix de la base de données, optimisation du code, client, serveur ou application Web, ce sont tous des domaines à considérer et les avantages et les inconvénients doivent être discutés sur une plateforme comme celle-ci. Pour moi, une diatribe est plus quand quelqu'un refuse catégoriquement de trouver une qualité de rachat dans une technologie particulière.
JeffO

Réponses:

8

Il y a beaucoup d'exemples où SQLite est abondant. L'utilisateur, le service ou l'entreprise le dépassent rarement (nous n'en entendons pas autant parler parce que personne n'appelle un programmeur si l'application fonctionne très bien.) Vous pouvez faire la même argumentation pour un fichier MS Access (Windows) ou SQL Server Compact Edition (une certaine installation est requise). Ils sont tous assez bons pour une application locale car vous n'avez pas à vous soucier autant de la sécurité du fichier.

Dans un scénario multi-utilisateurs sur un réseau local, le fichier va dans un dossier partagé qui devra être accessible à tous les utilisateurs - la sécurité des appels. Une maintenance simple ou tout changement de structure de table comme des sauvegardes ou l'ajout d'une colonne vont empêcher d'autres utilisateurs d'y accéder. Hier soir, la sauvegarde n'a pas fonctionné car quelqu'un a oublié de quitter l'application. Que se passe-t-il lorsque vous souhaitez effectuer une sauvegarde en milieu de journée? Tout le monde rationalise le fait qu'ils n'ont pas besoin de sauvegardes pendant la journée en raison des limites techniques de leur base de données. À un moment donné, l'installation de SQL Server Express / autre équivalent sur votre serveur nécessitera une configuration initiale et une configuration de sécurité, est plus complexe à l'avance, mais peu de maintenance sera nécessaire.

Il y a toujours le souci d'évolutivité / de suringénierie. Même si le nombre d'utilisateurs ou la quantité de données est toujours gérable, quelqu'un a toujours l'idée d'utiliser les données en direct sur un intranet ou une autre interface de site Web / navigateur. Les bases de données de fichiers présentent des problèmes. Il suffit d'une seule personne qui souhaite accéder au fichier de données via un VPN (l'application est installée sur son ordinateur portable) pour vous poser un problème de «mise à l'échelle». Vous pouvez créer l'application pour permettre aux utilisateurs déconnectés qui peuvent se synchroniser à leur retour. Cela ne semble pas valoir la peine pour les utilisateurs occasionnels absents du bureau.

JeffO
la source
Vous pouvez faire le même argument pour SQL Server Compact Edition, mais pas pour une base de données MS Access. Les bases de données Access sont traitées comme s'il s'agissait d'une véritable base de données, mais fonctionnent plus comme des fichiers partagés. Ils sont une solution fragile; SQL Server Compact est en fait une alternative meilleure, plus rapide et plus fiable qui fonctionne toujours avec les interfaces d'accès. Je soupçonne que SQLite est beaucoup plus durable qu'une base de données Access, même s'il s'agit techniquement d'une solution de fichiers partagés.
Robert Harvey
@RobertHarvey - Nous avons des demandes commerciales où MS Access est une solution suffisamment bonne (c'est-à-dire meilleure qu'Excel) depuis 10 ans. Quand un accord majeur est conclu, nous devons avoir quelque chose de opérationnel. Les utilisateurs avancés possédant des compétences d'accès sont beaucoup plus faciles à trouver et à exploiter. La fonctionnalité doit être disponible à une certaine date, mais nous avons la chance que l'évolutivité, les performances, la croissance des données et la sécurité n'aient jamais été un facteur. Mettre à niveau Access, c'est maintenant une autre histoire.
JeffO
Ne vous méprenez pas; Je pense que l'accès est génial. Mais SQL Server Compact serait mon exigence minimale pour toutes les nouvelles applications Access où les utilisateurs partagent des données.
Robert Harvey
@RobertHarvey - Je vais devoir examiner cela. Merci
JeffO
12

Je pense que c'est génial à utiliser lorsque vous avez besoin d'une base de données "interne". Autrement dit, une base de données avec laquelle votre application / code interagira, mais qui ne sera pas directement liée à la raison principale pour laquelle votre application existe. Au lieu d'utiliser d'énormes mappages en mémoire ou des gestionnaires de cache, vous pouvez également utiliser une telle base de données par exemple. J'en ai un exemple très concret, car je l'ai récemment utilisé dans les cas de test JUnit / DBunit où je devais me connecter à une base de données, effectuer certains travaux, lire des données et tout effacer à la fin. Comme il vous suffit de créer un fichier vide pour créer la base de données , c'était assez facile à faire.

Une autre utilisation que je vois: quand vous n'avez qu'un seul utilisateur. Oui, c'est possible, pensez par exemple à "Firefox" ou "Opera" :-)

De plus, sur le site Web SQLite, ils sont très honnêtes à ce sujet et donnent des raisons de ne PAS L'UTILISER (voir le paragraphe "Situations où un autre SGBDR peut fonctionner mieux")

ps: lié aux commentaires sur Sql Server Express, oui il doit être "installé". Et j'ai eu du mal à le mettre à jour personnellement (j'ai dû supprimer manuellement certaines clés de registre liées à la version précédente afin de pouvoir installer le 2008 R2). Cependant, si vous souhaitez comparer SQLite à une base de données développée par Microsoft, regardez Sql Server Compact Edition , que vous n'avez pas besoin d' installer (voir "Déploiement basé sur des fichiers privés").

Jalayn
la source
J'ai regardé CE, mais il semble que SQLite soit meilleur / plus rapide / plus facile. Je ne sais pas avec certitude, je n'ai pas suffisamment utilisé / testé CE pour être sûr.
5

Par exemple: considérons une application ERP avec, disons, 15 utilisateurs. Pourquoi SQLite ne peut-il pas être utilisé pour cela?

Très peu d'applications ont autant d'utilisateurs que jamais. Et pour tout ce qui voit plus d'utilisateurs et une manipulation des données plus complexe, l'utilisation de SQLite est complètement hors de question pour des raisons de performances en raison du modèle de verrouillage simple "une opération d'écriture à la fois".

Disons que vous avez 100 utilisateurs, chacun travaillant pendant 60 secondes à remplir un formulaire, puis à le soumettre. Vous devez donc traiter environ 1,6 transaction par seconde. Le modèle de données est complexe et l'enregistrement d'un formulaire implique la lecture et l'écriture dans de nombreuses grandes tables, peut-être même en communiquant avec un système différent, de sorte que chaque «formulaire de soumission» entraîne une transaction qui prend 2 secondes. Mais SQLite ne peut pas traiter les transactions simultanément, cela signifie donc qu'il ne peut traiter que 0,5 transactions par seconde. Oups.

«Peut être pénible à installer» n'est pas une bonne raison de décider contre un élément critique de l'infrastructure. En outre, il existe d'autres moteurs de base de données parmi lesquels choisir, dont au moins deux (MySQL et Postgres) sont gratuits et n'ont pas les limitations de concurrence de SQLite. Ils peuvent même être plus faciles à installer que MS-SQL.

Michael Borgwardt
la source
Je comprends et je suis d'accord. Mais dans ma profession, je n'ai vraiment pas de clients qui utilisent nos produits (standard et personnalisés, principalement liés à l'ERP) avec plus de 10 personnes. En moyenne, c'est même 5-6 utilisateurs. Je reformule ma question.
4
@Marcus V: La question est la suivante: si un client a beaucoup grandi et trouve que l'application que vous avez créée devient incroyablement lente à utiliser, et vous lui dites que la raison en est que le SGBD ne peut pas gérer autant d'utilisateurs, et il demande " pourquoi n'avez-vous pas utilisé un meilleur SGBD ", comment pensez-vous que la réponse" ceux-ci sont difficiles à installer "serait reçue? Je peux vous dire quelle serait ma réaction: je pense que "c'est un amateur. J'ai besoin de trouver quelqu'un d'autre pour écrire mon logiciel".
Michael Borgwardt
Tu as raison. Je ne pense pas que vous le pensiez de cette façon, mais je peux vous assurer que je ne suis pas un amateur. J'utiliserai certainement de "vrais" systèmes SGBD si la situation le demandait. Nos produits sont autorisés pour un certain nombre d'utilisateurs. Je ne développerais en utilisant SQLite que si je sais que le nombre d'utilisateurs est relativement faible (<10-15). Si le client dépasse une limite, ce qui dans notre base de clients ne se produira pas bientôt, nous pouvons toujours les convertir relativement rapidement / simplement dans une autre base de données. Ce n'est pas sorcier;). Sur la base de vos remarques, j'ai reformulé la question pour la rendre plus claire.
L'utilisateur qui pleure pour avoir dépassé l'application a probablement été informé des limites de l'utilisateur, mais a choisi d'opter pour la voie la moins chère. Tout va bien pour la configuration initiale, mais comment seront-ils heureux quand vous devrez leur facturer des frais supplémentaires pour l'installation sur le nouveau serveur, alors qu'ils auraient pu copier un fichier?
JeffO
1
@Jeff O: Je suppose que vous avez mal compris mes intentions. Je ne choisis pas SQLite car il est gratuit, bon marché et / ou facile à installer. Je ne le choisirais que parce qu'il est petit, rapide et convivial. C'est donc principalement pour des raisons pratiques / techniques. Beaucoup de nos clients ne dépensent pas beaucoup en matériel, donc je rencontre souvent un serveur unique avec tout (Exchange, SQL, etc.) et à cause de cela, ils sont presque "à bout de souffle". Si je pouvais livrer un produit qui n'a pas de configuration système élevée, mon client serait content. SQLite n'ajoute aucun poids, MSSQL le fait.
4

Je pense que SQLLite est excellent pour le développement d'applications, sa plus grande force est qu'il n'a pas besoin d'être installé sur le client.

Cependant, ne sous-estimez pas non plus SQL Server Express, c'est une excellente base de données gratuite avec la plupart des fonctionnalités du serveur SQL ordinaire avec seulement une limitation de la taille de la base de données (qui est difficile à dépasser) avec la possibilité d'utiliser les excellents outils de la normale serveur SQL.

Le plus gros inconvénient, c'est que vous devez l'installer, mais je ne suis pas certain de cette partie, peut-être un moyen de le contourner maintenant

Homde
la source
2
Tu as raison. MS-SQL Express est un produit de grande qualité. C'est juste que je le trouve un peu gonflé et que j'utilise trop de ressources. De nos jours, les PC / serveurs ne posent aucun problème. Je suis une personne juste et vieille école qui pense toujours qu'un matériel plus puissant ne signifie pas que je devrais négliger / gaspiller des ressources si je peux l'éviter. Moins c'est mieux ...;).
2
la base de données avec les moteurs de base de données peut optimiser l'accès en mettant en cache sa mémoire plutôt qu'en lisant / écrivant à partir de disques. Mais je ne suis pas sûr des performances des
bases de
1
@sarat: Afaik SQLite utilise intensivement les caches mémoire.
2

Je ne considère pas SQLite comme une base de données sérieuse si vous traitez avec quelques Go de données toutes les heures. Il devient douloureusement lent et réduit les performances de l'ensemble de l'application. Désolé, mais je ne suis pas d'accord avec votre fascination pour SQLite :-)

Geek
la source
1
Je respecte votre opinion. Je suis juste un homme pratique. Quand je choisis un outil, je le choisis parce que je pense que c'est la décision la plus réaliste / pratique. Je ne suis pas fasciné par SQLite, mais j'admire la façon dont ils ont réussi à mettre autant dans un paquet si petit, efficace et rapide. Comme je l'ai mentionné dans ma question: si MS-SQL est un meilleur outil pour un travail particulier, je choisirais simplement cela. Mais, comme je l'ai expliqué, à de nombreuses reprises, je crois vraiment que SQLite convenait parfaitement.
Cette quantité d'utilisation de données est un gros si.
JeffO
@Jeff O: D'accord. Je ne choisirais SQLite que si le nombre d'utilisateurs est relativement faible (<10-15) et que la quantité totale de données n'est pas élevée. D'après notre expérience, la taille totale de la base de données est souvent de 300 à 400 Mo et presque jamais> 1 Go.
1

Le problème avec les bases de données est qu'elles ont tendance à accumuler de plus en plus de données. Le choix d'une base de données légère présente un risque que votre outil ne s'adapte pas correctement.

quant_dev
la source