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

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.

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.

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").

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.

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

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 :-)

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.