Discussion :

[Lotendan]

Salut à tous,

Je bosse sur un gros projet et actuellement j'ai deux possibilités pour le faire.
Je me demandais quelle était la méthode la plus efficace parmi les deux suivantes. Par efficace, j'entends la plus rapide, la plus pythonnique et dont le code est facile d'entretien si j'ai besoin de retoucher les scripts d'ici un an ou deux.

Je vais vous proposer deux méthodes et je vous demanderai de justifier pourquoi celle-ci et pas l'autre (S.V.P.)

------------------------------------------------------------------

Mon programme permet de lister des objets qui ont chacun jusqu'à 14 caractéristiques (nom, couleur, forme, ...) dont 6 sont obligatoires et 8 sont facultatives. C'est-à-dire que celles qui sont obligatoires sont utilisées souvent par le programme, et les autres le sont plus rarement. Je créé un programme qui permet d'ajouter un objet avec ces caractéristiques (en obligeant l'utilisateur à saisir au moins les 6 principales), d'éditer ces caractéristiques, de supprimer un objet, et de formater ces données pour les afficher dans une fenêtre.

Première Méthode :
Utilisation d'une base de données. On utilise le module sqlite3 pour stocker les données dans 15 colonnes (une colonne pour le INTEGER PRIMARY KEY) grâce à leur nom.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
import sqlite3
 
def ajouter_objet(caracteristiques): 
#caracteristiques est un tuple qui contient les données dans l'ordre
# et qui sont issues d'une interface graphique non représentée ici 
#pour simplifier, et qui permet à l'utilisateur de saisir les données dont
#les 6 premières sont obligatoires, et les 8 autres facultatives
 
    db = sqlite3.connect("database.db")
    db.execute("INSERT INTO objets VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)", caracteristiques)
    db.commit()
    db.close()
 
def modifier_objet():
    [...]
def supprimer_objet([...]):
    [...]
 
def montrer_objet(nom):
    db = sqlite3.connect("database.db")
    c = db.execute("SELECT * FROM objets WHERE nom=?", (nom,))
    Informations_Objets(c.fetchone()) #Formate puis affiche
        #les données grâce à une interface graphique en wxPython

Cette méthode est celle que j'utilise habituellement, mais avec 15 colonnes et des tuples à rallonge, on se perd assez vite.


Deuxième méthode :
Utilisation d'une base de données et de la sérialisation des classes. On utilise les modules sqlite3 et (c)Pickle. La base de données comporte 3 colonnes, une pour l'index INTEGER PRIMARY KEY, une autre pour le nom de l'objet et la troisième nommée "serial" pour stocker une classe perso sérialisée sous forme de string. Pour afficher les données formatées, on utilise des Get.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
import sqlite3
import cPickle
 
class Objet:
    def __init__(self, nom, couleur, forme, ...):
        self.nom = nom
        self.couleur = couleur
        self.forme = forme
        [...]
 
    def GetColour():
        return self.colour
 
    def SetColour(couleur)
        self.couleur = couleur
 
    [...]
    [...]
#-----------------------------------------------------
 
def ajouter_objet(objet):
    #On a recueilli les informations provenant de l'interface graphique
    #de saisie des données et on a réalisé des Setxxx() pour construire
    #l'objet grâce à la classe ci-dessus. Puis, on transmet l'objet à la 
    #fonction ajouter_objet.
 
    serial = cPickle.dumps(objet)
 
    db = sqlite3.connect("dabatase.db")
    c = db.cursor()
    db.execute("INSERT INTO objets VALUES(?,?,?)", (c.lastrowid,
                     objet.GetName(), serial)
    db.commit()
    db.close()
 
[...]
 
def montrer_objet(nom):
    db = sqlite3.connect("database.db")
    c = db.execute("SELECT * FROM objets WHERE nom=?", (nom,))
    c.fetchone()
    objet = cPickle.loads(c[2])
    Informations_Objet(objet)

A vous de me dire si la seconde méthode est meilleure, ou si je dois continuer d'utiliser ma méthode habituelle.
Et, n'oubliez pas de justifier votre choix svp

Merci beaucoup !

Lotendan

[wiztricks]

Salut

J'ai un problème de vocabulaire!

Qu'appelez vous 'objet' une classe de... ou des instances de...
Combien de classes, combien d'instances? Est ce que la BDD se justifie à cause de la variabilité de?

Il semble que l'identité de vos 'instances' soit construite sur les 'noms': deux noms différents = des instances différentes et clé potentiellement utilisable.

Les "objets" ne sont à priori pas partagés entre les utilisateurs de l'application. - rien ne le dit sinon que dans le cas contraire, j'utiliserais autre chose que SQLite

Cette méthode est celle que j'utilise habituellement, mais avec 15 colonnes et des tuples à rallonge, on se perd assez vite.

Ne vous ai-je pas suggéré de regarder Elixir?
Un ORM est ce qui permet de transformer un 'objet' python en lignes de tables d'un SGDB... et réciproquement. Pourquoi ne pas utiliser cela plutôt que des solutions qui essaient de faire cela en moins bien?
- W

[Nico_tournai]

Bonjour,


je rebondis sur le conseil de l'utilisation d'élixir.
Tout le monde vante apparemment l'utilité des orm comme sqlalchemy.
Ma curiosité a été éveillée et je fais des recherches sur ce point, et il semblerait qu'il n'ait pas aisé de trouver de la doc (hormis sur le site de sqlalchemy) ou un tutoriel clair.
Peut on me guider vers quelques liens intéressants (anglais je me débrouille mais en francais ce serait pas plus mal pour mieux comprendre les principes).
Ou alors me dire en quelques lignes les avantages par rapport à l'utilisation de db-api.
J'ai commencé dernièrement un mini projet en pyqt avec accés au BDD avec les outils internes sql à pyqt. peut être que l'utilisation d'un de ces fameux orm serait plus avantageux (bien que ca tourne bien) pour distinguer le Gui des data comme le MVC le préconise.

[kango]

bonjour,

plutôt que le couple bdd - orm, pourquoi ne pas utiliser directement une base de données objet comme zodb ?

[wiztricks]

Salut,

bonjour,

plutôt que le couple bdd - orm, pourquoi ne pas utiliser directement une base de données objet comme zodb ?

Oui en effet.

De toutes façons s'il y a peu de collections et peu de membres, la technologie importe peu: celle que vous maîtrisez fera l'affaire.

Si on change de registre (en taille), on a d'autres problèmes:
- performances,
- évolutions,
- ...
et une base de donnée SQL peu (ou pas) aider: dommage de s'en passer.

La question serait plutôt quelles sont les technologies côté "persistance" qui permettent de développer rapidement une application plutôt OO sans trop sacrifier performances et évolutions "le cas échéant".

Personnellement, je pense qu'un ORM répond (partiellement) à ce type de besoin car la séparation entre "données" et applications reste techniquement "nette" même si fonctionnellement l'ORM les gomme un peu.

Une autre vue des choses pourrait être...

1. objet <--//--> persistance
2. objet <-----> collection //<----> persistance

Entre l'objet utilisé par l'application et l'état qui en a été sauvé, il y a un hiatus noté "//".

Une "base de données objet" apporte une solution "toute faite", au cas 1, pour associer objet et persistance avec une dépendance probablement similaire au Pickle de l'objet ou a coller l'ensemble des attributs dans les colonnes d'une table.

Un ORM permet de séparer les deux mondes, cas 2, et donc d'adresser les différents problèmes avec les outils et les personnes appropriés à chaque domaine si nécessaire.

Quelle sera la technologie qui à fonctionnalité équivalente (çà fait la même chose) offrira le plus d'ouvertures pour un ticket d'entrée équivalent (le temps d'apprendre à l'utiliser correctement sur de petit projets)?
- W

[Lotendan]

Salut,

Merci wiztricks de la réponse

Ne vous ai-je pas suggéré de regarder Elixir?

Non, vous ne me l'avez pas suggéré à moi mais je l'ai lu en effet quelque part dans ce forum Ceci dit, ayant beaucoup de choses à faire en ce moment, je n'ai pas eu le temps d'y jeter un oeil.

Un ORM est ce qui permet de transformer un 'objet' python en lignes de tables d'un SGDB... et réciproquement. Pourquoi ne pas utiliser cela plutôt que des solutions qui essaient de faire cela en moins bien?

Je ne savais pas qu'un ORM permettait de faire cela. A vrai dire, je ne m'y suis jamais vraiment intéressé. Je viens d'aller voir les pages SQLAlchemy et Elixir et j'avoue que cela peut être TRES intéressant pour mon projet !!
J'ai commencé à essayer d'installer SQLAlchemy sous Vista (une véritable horreur !! Surtout avec toutes les autorisations (alors que je suis administrateur)) et j'ai finalement réussi. J'ai également téléchargé Elixir et je l'ai installé avec easy_install.

Pourtant, j'obtiens ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
>>> from elixir import *
 
Traceback (most recent call last):
  File "<pyshell#0>", line 59, in <module>
    from elixir import *
ImportError: No module named elixir

Est-ce normal ?
Je précise que j'ai déjà sqlite3 installé sur ma version de python (je ne sais pas si cela a à voir ici)

Si j'ai bien compris, il est donc préférable d'utiliser des bases de données Elixir plutôt que des bases de données sqlite3 bêtes et méchantes pour de gros projets ?

Édit : pour Nico. En cherchant pour Elixir, j'ai vu un module qui s'intégre a SQLAlchemy et qui semble faire un lien entre SQL, Qt et l'ORM. Ce module s'appelle Camelot et a l'air très bien. Personnellement, en tant qu'utilisateur de wxPython, cela ne m'interessait pas. Bonne chance !

Merci beaucoup

Lotendan

[wiztricks]

Salut,

Est-ce normal ?

Ben non mais comme je ne joue pas avec Vista, pas facile de vous aider.
Precisez la version de Python et celle d'Elixir au cas où.

easy_install Elixir installe sqlalchemy qui s'appuie sur SQLite par défaut.
Pour les autres bases de données, il faut installer le "driver" (dbapi).

Si j'ai bien compris, il est donc préférable d'utiliser des bases de données Elixir plutôt que des bases de données sqlite3 bêtes et méchantes pour de gros projets?

Je dirais Elixir pour les petits projets et sans doute SQLAlchemy pour les gros. La différence est "subtile".

• Elixir est un ORM de type 'Active Record': une instance <-> une ligne comme dans le cas (1).
• SQLAlchemy est un Data Mapper (cas 2).

Elixir est plus facile à mettre en œuvre que SQLAlchemy.
La base de donnée peut rester SQLite3 ou être PostgreSQL/MySQL/...
Vous ne travaillez plus directement avec DBAPI (mais cela ne l'interdit pas), vous pouvez oublier un temps SQL (mais vous pourrez optimiser certaines requêtes avec du SQL si nécessaire), ...

Citation:
Un ORM est ce qui permet de transformer un 'objet' python en lignes de tables d'un SGDB... et réciproquement. Pourquoi ne pas utiliser cela plutôt que des solutions qui essaient de faire cela en moins bien?

Je ne savais pas qu'un ORM permettait de faire cela. A vrai dire, je ne m'y suis jamais vraiment intéressé. Je viens d'aller voir les pages SQLAlchemy et Elixir et j'avoue que cela peut être TRES intéressant pour mon projet !

C'est ce qu'ORM veut dire.
Je pense que cela peut être intéressant pour tous les projets...
Reste à se faire un peu violence pour apprendre que çà existe et les utiliser.
- W

[Nico_tournai]

Il faudra donc que je potasse plus longuement sur le sujet.
Il serait dommage de passer à côté des avantages d'un orm pour un projet qui s'y prête bien.
Comme vous le conseillez, je commencerai d'abord par de minis-projets (le tout est de trouver le temps après les heures de travail et vie de famille..)

Pour le moment, je vais essayer d'imprimer discrètement au boulot la doc du site sqlalchemy.
Ca va me promettre quelques maux de tête tout ceci!

Merci d'avoir pris du temps et d'avoir répondu clairement.

[wiztricks]

Salut
Pour les tutoriels sur SQLalchemy et Elixir, ce qu'on trouve sur les sites ne sont pas si mal. Vous avez le bouquin "Essential SQLAlchemy, 1st Edition" qui est pas mal bien qu'ancien.

QT est, à mon sens, un cas particulier: il crée un environnement complet et intégré pour accéder aux bases de données (et à n'importe quoi d'autre). Je ne sais pas s'il est facile/utile d'ajouter un ORM "en plus".

Si on reprend le problème de départ, je le reformulerais de la façon suivante: l'application travaille avec une "collection" de membres identifiés par leur nom. Et on souhaite que les différents membres soient 'persistants'.
Nous avons une articulation entre l'application et la "collection": créer, mettre à jour, détruire un membre et une articulation entre la "collection" et la fonction de persistance.

En disant cela nous avons séparé l'utilisation par l'application des membres de la collection et les fonctionnalités de stockage/lecture des "membres" par la collection.

Si l'application comporte une seule collection, peu de membres et pas de partage, et un accès direct aux membres (pas de recherche sur la valeur d'attributes autres que la clé) pickle est largement suffisant. De plus, si on ajoute/supprime des attributs, la mécanique "fonctionnera" sans autre changement qu'une migration éventuelle des anciens objets dans le nouveau format.
Et si on a très peu de membres, a-t-on besoin d'une BDD?

Si l'application comprend plusieurs collections, beaucoup de membres, des attributs à sauvegarder au fur et à mesure de leur mise à jour, des relations entre les membres des différentes collections,... il va probablement falloir refaire ce qu'un ORM fait déjà: dommage.

Ou alors me dire en quelques lignes les avantages par rapport à l'utilisation de db-api.

db-api permettra d'avoir un accès direct aux membres et un chargement/sauvegarde "à la demande".

Un ORM vous apportera en plus:
- l'indépendance vis à vis du SGDB,
- ne pas avoir à écrire de SQL pour réaliser les transferts,
- la possibilité de sauvegarder les membres mis à jours plus ou moins automatiquement,
- ...

En gros, vous écrivez et testez moins de lignes de code et si vous devez faire évoluer l'application l'ORM vous propose des interfaces prêtes à l'emploi pour créer les tables, mettre en correspondances les lignes des tables avec les membres de la collection.

Si vous n'avez pas l'habitude d'utiliser ce genre de techno, commencer avec un petit projet est une bonne idée (à condition de pouvoir prendre le temps d'apprendre) surtout si elle est appelée à intégrer d'autres collections, des relations, ...
- W

[Lotendan]

Salut à tous !

Après quelques efforts et quelques bidouillages dans tous les sens, j'ai réussi à installer Elixir sans easy_install. J'ai supprimé tous les composants setuptools à la main, puis j'ai décompressé bêtement le fichier OGG d'Elixir dans mon répertoire Python, et tout fonctionne.

Elixir fonctionne très bien et s'avère être parfaitement adapté à mon projet !

Merci wiztricks

[wiztricks]

Désolé que l'installation d'Elixir ait été aussi laborieuse.
J'en suis d'autant plus surpris que je l'ai installé sur différents OS sans soucis avant l'installation de drivers des bases données.
Ils n'ont rien à voir avec SQLAlchemy/Elixir, mais Python ne vient qu'avec SQLite... Ce qui n'est déjà pas si mal...
Pour les autres, la "toolchain" de compilation est parfois difficile à finaliser.
- W
PS: J'appelle "toolchain" l'environnement GNU/AutoTools ou autre qui permet de construire des binaires via ./configure, make,...

[Antoine_935]

Je me permets de poster une petite note personnelle concernant les ORMs.
Ils sont très pratiques, c'est indiscutable. Néanmoins ils peuvent avoir des effets néfastes.

Par exemple, les ORMs poussent à faire des queries en « tout objet ». On se retrouve alors à lancer 15 requêtes via l'ORM là où une seule requête bien pensée aurait résolu le souci.

Autre exemple, les ORMs ne parlent jamais de ce qu'on appelle les « vue » (CREATE*VIEW). Or c'est quand même quelque chose de bien pratique, qui peut raccourcir pas mal le code, et réduire plusieurs requêtes à une seule que le dbms a pu optimiser.

Qui plus est, les ORMs découragent l'usage des fonctions, procédures et triggers. C'est pourtant bien utile pour réduire le traffic de données entre le dbms et l'application. Ça a en tout cas des effets sur les performances, et parfois même sur la sécurité (moins d'infos qui transitent sur le réseau). Et d'ailleurs, je trouve plus simple de modifier des données automatiquement avec un trigger que par 36 manipulations objets.


Bref, les ORMs c'est mignon, mais à mon sens ça ne vaut pas un développement « Thick Database ». Je trouve qu'il faut les réserver au simples opérations de CRUD.

[wiztricks]

Salut,

Bref, les ORMs c'est mignon, mais à mon sens ça ne vaut pas un développement « Thick Database ».

Absolument, développer son modèle de données SQL et passer par des procédures stockés pour accéder aux données est le MUST.

Le hic est qu'il faut connaitre SQL et le langage de programmation, ce qui fait souvent beaucoup trop pour des projets développés en perruque ou sous la forme de "prototypes". Et sont le lot de beaucoup de projet Python.

Je trouve qu'il faut les réserver au simples opérations de CRUD.

Des ORM de type Data Mapper comme SQLAlchemy (ou Hibernate) n'empêchent pas d'écrire du SQL pour certaines ou toutes les requêtes qui correspondent aux "classes" de persistance.

Cette possibilité est en général passée à la trappe car il est moins risqué de multiplier les systèmes des serveurs d'applications et de répartir la charge que de trouver les expertises qui pourront peut-être remettre du jus dans une application développée, il y a des années sur un coin de table.

Pour résumer...

Les gros projets, peuvent s'offrir les expertises qui vont bien... Et en général préfèreront des langages compilés à Python.

Pour tout petit projet qui a une opportunité de devenir grand ou de durer, l'ORM permet d'intégrer plus de fonctionnalités plus vite et plus sûrement...
I.e. de le viabiliser ou lui donner plus de chances de devenir "grand".

- W
PS: Expliquer à un client qu'il prend de 'gros risques' en sous estimant les expertises et les ressources à affecter à un projet avait du sens lorsque les patrons avaient une vision dans la durée et non seulement des résultats mensuels/trimestriels à sortir....
La réalité des risques sera assumée par les successeurs (ou les générations futures).