Sites Web à usage interne: existe-t-il une preuve convaincante contre SQLite?

De nombreux frameworks Web, tels que Flask ou Django, utilisent SQLite comme base de données par défaut. SQLite est convaincant car il est inclus dans python, et la surcharge administrative est assez faible.

Cependant, la plupart des sites de production publique à fort trafic finissent par utiliser une base de données plus lourde: mySQL, Oracle ou postgresql.

Les questions :

Assumer:

• Le trafic du site est modéré et un accès simultané en lecture / écriture à la base de données se produira
• Nous utiliserons SQLAlchemy avec des verrous d'écriture SQLite (bien que ce commentaire me rende un peu nerveux)
• La base de données contiendra peut-être 60 000 enregistrements
• Les structures de données ne nécessitent pas de fonctionnalités avancées trouvées dans des bases de données plus lourdes

Existe-t-il un argument convaincant contre la concurrence SQLite pour les sites Web qui servent d'outils d'entreprise internes à trafic modéré? Si tel est le cas, quelles conditions entraîneront des problèmes d'accès concurrentiel pour SQLite ?

Je recherche des causes profondes spécifiques connues, au lieu de la peur générale / du doigt non justifié.

Je recommande de lire la réponse officielle à votre question, Utilisations appropriées pour SQLite . Plus précisément, les «Situations où un autre SGBDR peut mieux fonctionner» avertissent que SQLite ne prend pas en charge l'écriture simultanée:

SQLite prend en charge un nombre illimité de lecteurs simultanés, mais il n'autorisera qu'un seul écrivain à tout instant. Dans de nombreuses situations, ce n'est pas un problème. Chaque application fait son travail de base de données rapidement et continue, et aucun verrouillage ne dure plus de quelques dizaines de millisecondes. Mais certaines applications nécessitent plus de simultanéité, et ces applications peuvent avoir besoin de rechercher une solution différente.

Du point de vue de la pertinence, j'ai tendance à voir SQLite comme un format de fichier très sophistiqué qui prend en charge les requêtes SQL. J'aurais tendance à éviter SQLite si je voulais séparer ma base de données de mon application web, car elle n'est pas optimisée pour ce cas. En bref, SQLite n'est pas suffisamment évolutif pour être utilisé dans certains scénarios, donc les personnes qui gèrent des sites Web qui espèrent devenir un jour populaires peuvent être mieux en commençant par quelque chose d'évolutif, plutôt que d'aller avec SQLite et d'être ensuite obligées de changer.

Cela étant dit, SQLite convient probablement à la plupart des sites Web internes; les sites Web généralement internes ne nécessitent pas le même niveau de simultanéité et d'évolutivité.

En mettant mon chapeau de directeur informatique, je vois quelques no-gos ici:

• Risque de corruption des données. Peut-être plus perçu que réel, mais en fin de compte, il s'agit d'une base de données de type de fichier non transactionnel qui n'a pas beaucoup, sinon aucun recours à de mauvaises écritures, en plus de demander si vous avez une sauvegarde récente. En parlant de ça. . .
• Comment puis-je sauvegarder cette chose? D'une certaine manière, je sais que j'en ai un bon exemplaire. De préférence sans mettre l'application hors ligne.
• Comment sécuriser l'accès à la base de données? Ma compréhension générale est que SQL Lite n'en a pas en dehors de l'accès au système de fichiers, ce qui est un début décent, mais pas le tout-en-un. Surtout pour les applications Web où vous voudrez peut-être plus d'autorisations graduées que DBA ou rien.

Du point de vue du développeur, je pense qu'il est important de savoir pourquoi SqlLite est la valeur par défaut - c'est parce qu'il est facile et qu'il fonctionne bien. Si vous "vendez" une plate-forme à de nouveaux développeurs, il est essentiel de lancer une application Web fonctionnelle avec un minimum de bruit. Et devoir se lever et configurer correctement un serveur de base de données serait un obstacle majeur à éviter.