Discussion :

[rambc]

Bonjour,
quel est votre expérience en terme de gestion de BDD sous Python ? Que vaut SQLAlchemy ?

[tyrtamos]

Bonjour rambc,

Je pratique à haute dose sqlite3, et j'en suis très satisfait.

Bien que sa syntaxe soit limitée à SQL92, il est très puissant en fonctionnalités et en rapidité. Je l'utilise dans un programme avec plusieurs milliers d'articles, une quinzaine de tables, des contraintes de clés étrangères, des triggers, etc... On peut d'ailleurs ajouter des fonctions Python: tris selon le dictionnaire français, recherches de mots approchants, etc...

Avec PyQt4, on peut visualiser les tables (QTableView) et les modifier. On peut aussi visualiser les tables temporaires crées avec des SELECT. Au sein d'un programme en cours d'exécution, on peut donc (et c'est ce que je fais), écrire un script SQL d'extraction de la base dans un QTextEdit, et obtenir la visualisation du résultat! Il ne reste plus qu'à programmer l'exportation en fichier .csv pour transmettre ces résultats à Excel.

Attention: sqlite3 n'est pas un serveur! il est très adapté pour les bases de données liées à un programme et sans accès concurrents. En cas d'accès concurrents, j'aime bien PostgreSQL (je le préfère à MySQL) qui, lui, est un serveur.

Cerise sur le gâteau, il supporte très bien cx_freeze ce qui, avec PyQt4, permet de créer un programme graphique performant et autonome. Avec un installeur (innosetup sous Windows, mise en paquet sous Linux), l'utilisateur ne saura même pas que c'est du Python...

Vis à vis de SQLAlchemy: j'en ai entendu beaucoup de bien, mais je préfère pour l'instant la solution classique. D'autant plus qu'un numéro de version <1.00 m'inquiète toujours un peu sur la maturité du produit. J'essaierai un de ces jours.

[wiztricks]

quel est votre expérience en terme de gestion de BDD sous Python ? Que vaut [URL="http://www.sqlalchemy.org/"]SQLAlchemy

Si on entend par "gestion de BDD" interfacer un SGDB relationnel (sqlite, postgres, mysql,...) avec un programme Pyhon, la plupart offre des "drivers" conforme à la DB API Python dont sqlite3 est une sorte d'implémentation de référence de la DB API.

Comme vous semblez aimer Qt, vous pouvez, comme suggéré par Tyrtamos utiliser QtSql. Il a l'intérêt de définir comment s'interfacer avec les autres objets Qt... Mais on est là dans la facilité d'utiliser Python (plutôt que C++) pour programmer avec le framework Qt.

SQLAlchemy n'est pas un SGDB-R mais un ORM (à la Hibernate du monde Java). Il peut être utilisé avec tout SGDB-R qui propose un driver conforme à la "DB API" et qui a été intégré à SQLAlchemy.

Ce travail d'intégration permet d'utiliser SQLAlchemy comme une "super" DB API. On peut coder ses requêtes SQL dans un langage indépendant du SGDB.
Ca permet de commencer avec Sqlite puis de continuer avec PostgresSQL ou autre modulo quelques ajustements côté performances.
Nota, c'est pour cela que je le préfère à une utilisation "directe" du sqlite3 livré en standard.

Les fonctionnalités d'un ORM sont simples pour la mise en correspondance les instances d'une classe avec les lignes d'une table: SQLAlchemy construit alors pour vous tout ce qu'il faut pour interfacer les "classes" avec le SGDB.

Cà se complique lorsqu'il faut rendre compte des relations entre les "tables" et les exprimer côté "classes": héritage, many to many, one to many,...
La difficulté étant que les associations entre l'univers des objets d'un langage POO sont orthogonales avec celles construites entre les "relations" (tables) d'un SGDB-R.
SQLAlchemy propose des solutions mais il faut avoir une bonne connaissance des deux mondes pour comprendre le contexte dans lequel une "solution" sera meilleure qu'une autre et les bonnes "options" à mettre en œuvre.

Cette "complexité" ne s'applique pas aux "petites" applications auxquelles vous voulez ajouter une fonction de persistance méritant d'être supportée par un engin plus costaud que pickle/shelve. Plutôt que de coder vous même la relation entre les relations et les classes à partir de requêtes SQL, autant utiliser SQLAlchemy qui le fait pour vous "assez bien".

Souvent j'ai a ajouter des fonctionnalités à une application existante.
Elle n'est pas écrite en Python. Mais dispose déjà d'un schéma, de données et de son SGDB-R. Si le schéma est bien construit, SQLAlchemy est capable de construire le DAO de façon automatique en découvrant relations et associations existantes. Ce n'est pas si mal pour un début et en travaillant sur de l'existant, on évite la "complexité" d'une conception de bout en bout.

SQLAlchemy est incontournable pour tout projet qui doit:
- être indépendant du SGDB: pour proposer au client le SGDB connu par ses admins.
- supporter des migrations de schéma lors des évolutions applicatives,
- réaliser une fonction de persistance des objets de l'application,
- ...
Mais on n'est plus dans ce cas à coder un "prototype" ou un "proof of concept" réalisable par une ou deux personnes en quelques milliers de lignes.

- W

[rambc]

Merci pour ces infos, je vais donc me tourner vers SQLAlchemy pour préparer le futur même si ce sera moins immédiat que d'utiliser SQL3.

[Alliaël]

Bonjour,

une petite question supplémentaire pour ceux utilisant déjà SQLAlchemy, la surcouche Elixir ( http://elixir.ematia.de/trac/wiki ) est elle intéressante ?

Elle n'est visiblement plus dev depuis un moment, mais est elle abouti et permet elle un vrai confort ? Ou s'agit il simplement d'une petite couche pas vraiment utile.

[wiztricks]

une petite question supplémentaire pour ceux utilisant déjà SQLAlchemy, la surcouche Elixir ( http://elixir.ematia.de/trac/wiki ) est elle intéressante ?

Elle n'est visiblement plus dev depuis un moment, mais est elle abouti et permet elle un vrai confort ? Ou s'agit il simplement d'une petite couche pas vraiment utile.

C'est une sur-couche utile puisqu'elle permet de décrire les tables du SGDB sous la forme de classes Python et de faire l'économie du passage par le "mapper". Ces fonctionnalités d'Elixir ont été intégrées dans SQLAlchemy (Declarative Extension) depuis un certain temps déjà.

- W