Je cherche un gestionnaire de bases de données en python pour gérer des bases de quelques miliers d'entrées (donc pas grosses les bases). Un truc du genre mysql mais en python.
Quelqu'un a quelquechose à me recommander ?
Merci pour la traduction ; effectivement, je n'ai plus d'excuses, pour essayer... de lire ce manuel (j'ai commencé).
@-salutations
Michel Claveau
nico
KirkyBase me parait intéressant mais je m'inquiète de la vitesse d'exécution. Et puis, ce n'est pas une absolue nécessité mais j'aimerais que le contenu de la base ne soit pas lisible directement. Je ne parle pas de cryptage mais simplement d'un enregistrement binaire. Ca n'a pas l'air possible avec KirkyBase.
Nicolas
Bien sûr il y a une grosse différence de performance entre les bases en pur Python et les bases écrites dans des langages compilés
J'ai fait des mesures sur une table de 10.000 éléments générés au hasard. Sa structure est la suivante :
name varchar, role varchar, country varchar, speed integer, range integer, began_service varchar, still_flying integer, comment varchar
La requête consiste à rechercher des enregistrements où country = "USA" et began_service < 1945-01-01
Syntaxe : - SQL :
sql = "SELECT name, began_service FROM plane WHERE country='USA' AND began_service < '1945-01-01'" cursor.execute(sql) print len(cursor.fetchall())
- KirbyBase v2.x (en chantier) :
print len ([ r for r in plane if r.country == 'USA' and r.began_service < '1945-01-01' ])
- résultats obtenus : (temps pour exécuter 10 fois la requête, divisé par 10) SQLite : 0,014 seconde MySQL : 0,017 gadfly : 0,285 KirbyBase v2.x : 0,386
Sur cet exemple les bases en Python sont donc 20 à 30 fois plus lentes que SQLite ou mySQL. Gadfly travaille en mémoire, donc est plus rapide que KirbyBase, qui reste sur disque
Cela dit : - la syntaxe de la requête KirbyBase (une "list comprehension") est plus "pythonique" que les requêtes SQL - la requête avec KirbyBase retourne des objets avec des attributs qui ont le nom des champs de la table, ce qui est plus pratique que des listes de champs. On peut convertir les listes en objets pour les autres bases, mais du coup le temps d'exécution se dégrade sensiblement - dans un contexte de programmation web par exemple, 0,4 seconde pour une requête de ce type reste tout à fait acceptable
Un principe de départ de KirbyBase était que la base soit lisible et éditable avec un simple éditeur de texte. Le cryptage des données n'est pas disponible dans la version 1.9 mais il est dans la 2.0 beta 1 (http://www.netpromi.com/files/KirbyBase_Python_2.0_beta_1.zip). La prochaine version sur laquelle je travaille avec Jamey Cribbs l'intègrera aussi, elle devrait sortir en novembre
Evidemment une étape intermédiaire d'encodage / décodage rajoute un peu de temps de calcul
A+ Pierre
Merci beaucoup pour toutes ces informations très intéressantes. Je n'ai plus d'excuses pour essayer. Mon application est perso. J'écris un petit soft pour gérer mes comptes bancaires. C'est pour ça que j'aimerais que la base ne soit pas directement lisible. Mais comme ça reste sur mon PC perso, c'est pas critique. Y a plus qu'à.
Nicolas
KirkyBase me parait intéressant mais je m'inquiète de la vitesse
d'exécution. Et puis, ce n'est pas une absolue nécessité mais
j'aimerais que le contenu de la base ne soit pas lisible directement.
Je ne parle pas de cryptage mais simplement d'un enregistrement
binaire. Ca n'a pas l'air possible avec KirkyBase.
Nicolas
Bien sûr il y a une grosse différence de performance entre les bases en
pur Python et les bases écrites dans des langages compilés
J'ai fait des mesures sur une table de 10.000 éléments générés au
hasard. Sa structure est la suivante :
name varchar, role varchar, country varchar, speed integer, range
integer, began_service varchar, still_flying integer, comment varchar
La requête consiste à rechercher des enregistrements où country = "USA"
et began_service < 1945-01-01
Syntaxe :
- SQL :
sql = "SELECT name, began_service FROM plane WHERE country='USA' AND
began_service < '1945-01-01'"
cursor.execute(sql)
print len(cursor.fetchall())
- KirbyBase v2.x (en chantier) :
print len ([ r for r in plane if r.country == 'USA' and r.began_service
< '1945-01-01' ])
- résultats obtenus : (temps pour exécuter 10 fois la requête, divisé
par 10)
SQLite : 0,014 seconde
MySQL : 0,017
gadfly : 0,285
KirbyBase v2.x : 0,386
Sur cet exemple les bases en Python sont donc 20 à 30 fois plus lentes
que SQLite ou mySQL. Gadfly travaille en mémoire, donc est plus rapide
que KirbyBase, qui reste sur disque
Cela dit :
- la syntaxe de la requête KirbyBase (une "list comprehension") est plus
"pythonique" que les requêtes SQL
- la requête avec KirbyBase retourne des objets avec des attributs qui
ont le nom des champs de la table, ce qui est plus pratique que des
listes de champs. On peut convertir les listes en objets pour les autres
bases, mais du coup le temps d'exécution se dégrade sensiblement
- dans un contexte de programmation web par exemple, 0,4 seconde pour
une requête de ce type reste tout à fait acceptable
Un principe de départ de KirbyBase était que la base soit lisible et
éditable avec un simple éditeur de texte. Le cryptage des données n'est
pas disponible dans la version 1.9 mais il est dans la 2.0 beta 1
(http://www.netpromi.com/files/KirbyBase_Python_2.0_beta_1.zip). La
prochaine version sur laquelle je travaille avec Jamey Cribbs
l'intègrera aussi, elle devrait sortir en novembre
Evidemment une étape intermédiaire d'encodage / décodage rajoute un peu
de temps de calcul
A+
Pierre
Merci beaucoup pour toutes ces informations très intéressantes. Je n'ai plus d'excuses pour essayer.
Mon application est perso. J'écris un petit soft pour gérer mes comptes bancaires. C'est pour ça que j'aimerais que la base ne soit pas directement lisible. Mais comme ça reste sur mon PC perso, c'est pas critique.
Y a plus qu'à.
KirkyBase me parait intéressant mais je m'inquiète de la vitesse d'exécution. Et puis, ce n'est pas une absolue nécessité mais j'aimerais que le contenu de la base ne soit pas lisible directement. Je ne parle pas de cryptage mais simplement d'un enregistrement binaire. Ca n'a pas l'air possible avec KirkyBase.
Nicolas
Bien sûr il y a une grosse différence de performance entre les bases en pur Python et les bases écrites dans des langages compilés
J'ai fait des mesures sur une table de 10.000 éléments générés au hasard. Sa structure est la suivante :
name varchar, role varchar, country varchar, speed integer, range integer, began_service varchar, still_flying integer, comment varchar
La requête consiste à rechercher des enregistrements où country = "USA" et began_service < 1945-01-01
Syntaxe : - SQL :
sql = "SELECT name, began_service FROM plane WHERE country='USA' AND began_service < '1945-01-01'" cursor.execute(sql) print len(cursor.fetchall())
- KirbyBase v2.x (en chantier) :
print len ([ r for r in plane if r.country == 'USA' and r.began_service < '1945-01-01' ])
- résultats obtenus : (temps pour exécuter 10 fois la requête, divisé par 10) SQLite : 0,014 seconde MySQL : 0,017 gadfly : 0,285 KirbyBase v2.x : 0,386
Sur cet exemple les bases en Python sont donc 20 à 30 fois plus lentes que SQLite ou mySQL. Gadfly travaille en mémoire, donc est plus rapide que KirbyBase, qui reste sur disque
Cela dit : - la syntaxe de la requête KirbyBase (une "list comprehension") est plus "pythonique" que les requêtes SQL - la requête avec KirbyBase retourne des objets avec des attributs qui ont le nom des champs de la table, ce qui est plus pratique que des listes de champs. On peut convertir les listes en objets pour les autres bases, mais du coup le temps d'exécution se dégrade sensiblement - dans un contexte de programmation web par exemple, 0,4 seconde pour une requête de ce type reste tout à fait acceptable
Un principe de départ de KirbyBase était que la base soit lisible et éditable avec un simple éditeur de texte. Le cryptage des données n'est pas disponible dans la version 1.9 mais il est dans la 2.0 beta 1 (http://www.netpromi.com/files/KirbyBase_Python_2.0_beta_1.zip). La prochaine version sur laquelle je travaille avec Jamey Cribbs l'intègrera aussi, elle devrait sortir en novembre
Evidemment une étape intermédiaire d'encodage / décodage rajoute un peu de temps de calcul
A+ Pierre
Merci beaucoup pour toutes ces informations très intéressantes. Je n'ai plus d'excuses pour essayer. Mon application est perso. J'écris un petit soft pour gérer mes comptes bancaires. C'est pour ça que j'aimerais que la base ne soit pas directement lisible. Mais comme ça reste sur mon PC perso, c'est pas critique. Y a plus qu'à.
