Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 6 sur 6
  1. #1
    Membre Expert

    Inscrit en
    décembre 2006
    Messages
    2 252
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 2 252
    Points : 1 280
    Points
    1 280

    Par défaut Quel module pour les bases de données ?

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

  2. #2
    Expert Confirmé
    Avatar de tyrtamos
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    2 185
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 2 185
    Points : 3 724
    Points
    3 724

    Par défaut

    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.
    Ne rien ranger permet d'observer la loi universelle d'entropie: l'inévitable convergence vers le chaos...
    Mes recettes python: http://www.jpvweb.com

  3. #3
    Expert Confirmé Sénior
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    4 748
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 4 748
    Points : 7 160
    Points
    7 160

    Par défaut

    Citation Envoyé par rambc Voir le message
    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
    Architectures Post-Modernes

  4. #4
    Membre Expert

    Inscrit en
    décembre 2006
    Messages
    2 252
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 2 252
    Points : 1 280
    Points
    1 280

    Par défaut

    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.

  5. #5
    Membre du Club
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 43
    Points : 49
    Points
    49

    Par défaut

    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.

  6. #6
    Expert Confirmé Sénior
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    4 748
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 4 748
    Points : 7 160
    Points
    7 160

    Par défaut

    Citation Envoyé par Alliaël Voir le message
    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
    Architectures Post-Modernes

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •