Avantages et inconvénients de l'utilisation de sqlite3 par rapport à l'implémentation d'une table personnalisée

Question

J'ai remarqué qu'une partie importante de mon code (pur Python) concerne les tables. Bien sûr, j'ai class Table qui supporte la fonctionnalité de base, mais je finis par y ajouter de plus en plus de fonctionnalités, telles que les requêtes, la validation, le tri, l'indexation, etc.

Je me demande si c'est une bonne idée d'enlever mon class Table, et refactoriser le code pour utiliser une base de données relationnelle régulière que je vais instancier en mémoire.

Voilà ma façon de penser à ce jour:

1. Performance des requêtes et indexation améliorerait mais la communication entre le code Python et le processus de base de données séparée pourrait être moins efficace que entre les fonctions Python. Je suppose que c'est trop frais, donc je devrais aller avec sqlite qui vient avec Python et vit dans le même processus. I espérons cela signifie que c'est un gain de performance pure (au prix d'une définition SQL non standard et de fonctionnalités limitées de sqlite). Avec SQL, j'obtiendrai des fonctionnalités beaucoup plus puissantes que je ne voudrais jamais me coder moi-même. On dirait un avantage évident (même avec sqlite). Je n'aurai pas besoin de déboguer ma propre implémentation de tables, mais les erreurs de débogage dans SQL sont difficiles car je ne peux pas mettre de points d'arrêt ou imprimer facilement l'état intermédiaire. Je ne sais pas comment juger de l'impact global de la fiabilité de mon code et du temps de débogage.

2. Le code sera plus facile à lire, car au lieu d'appeler mes propres méthodes personnalisées, j'écrirais SQL (tout le monde qui a besoin de maintenir ce code connaît SQL). Cependant, le code Python à traiter avec la base de données pourrait être plus laid et plus complexe que le code qui utilise Python pur class Table. Encore une fois, je ne sais pas quel est le meilleur équilibre.

Une correction à ce sujet ou quoi que ce soit d'autre que je devrais penser?

Answer 1

SQLite ne s'exécute pas dans un processus distinct. Vous n'avez donc pas de frais généraux supplémentaires d'IPC. Mais le surcoût IPC n'est pas très important, en particulier sur, par exemple, les sockets UNIX. Si vous avez besoin de plusieurs écrivains (plus d'un processus/thread écrit dans la base de données simultanément), le surcoût de verrouillage est probablement pire, et MySQL ou PostgreSQL fonctionnerait mieux, surtout si vous travaillez sur la même machine. Le SQL de base supporté par ces trois bases de données est le même, donc l'analyse comparative n'est pas si pénible.

Vous n'avez généralement pas à faire le même type de débogage sur les instructions SQL que vous le faites sur votre propre implémentation. SQLite fonctionne, et est déjà assez bien débogué. Il est très peu probable que vous deviez déboguer "OK, cette ligne existe, pourquoi la base de données ne la trouve-t-elle pas?" et traquer un bug dans la mise à jour de l'index. Le débogage de SQL est complètement différent du code de procédure, et ne se produit réellement que pour des requêtes complexes. En ce qui concerne le débogage de votre code, vous pouvez assez facilement centraliser vos appels SQL et ajouter du traçage pour consigner les requêtes que vous exécutez, les résultats que vous obtenez, etc. L'interface Python SQLite peut déjà avoir ceci (pas sûr, je utilise normalement Perl). Il sera probablement plus facile de simplement faire de votre classe Table existante un wrapper autour de SQLite.

Je recommande fortement de ne pas réinventer la roue. SQLite aura beaucoup moins de bugs et vous fera gagner beaucoup de temps.(Vous voudrez peut-être aussi jeter un coup d'œil sur le passage récent de Firefox à l'utilisation de SQLite pour stocker l'historique, etc. Je pense qu'ils ont obtenu des accélérations assez significatives.)

un peu plus rapide que toute implémentation pure de Python.

Answer 2

Si vous travaillez dans une base de données, utilisez une base de données, si ce n'est pas votre cas, alors ne le faites pas. En utilisant des tables, c'est comme si vous étiez. Je recommanderais d'utiliser un ORM pour le rendre plus pythonique. SQLAlchemy est le plus flexible (bien que ce ne soit pas strictement un ORM).

Answer 3

Vous pouvez essayer de créer un wrapper sqlite avec la même interface que votre Table de classe, afin de garder votre code propre et d'obtenir les performances sqlite.