encore un SGBD en mémoire

Méta-MCI wrote:

[encore un SGBD en mémoire]


Bonjour !

Je sais qu'il y en a beaucoup qui existaient déjà.
Mais, ils ne correspondaient pas tout à fait à mes besoins.

Du coup, j'en ai attaqué un. En pur Python (je n'ai testé que sous
windows, mais il n'y a pas de raisons pour que ça ne fonctionne pas sur
d'autres OS).

Ce n'en est qu'au (tout) début. Il reste plein de fonctionnalités à
installer. Et, même, certaines déjà faites ne sont pas encore testées.

Il n'y a pas de doc, mais quatre exemples avec des tout-mini-riquiquis
commentaires.

C'est là : http://www.ponx.org/ponx/chata.htm

Ah, oui ! Il faut Python 2.5.
Il n'y a pas d'installation ; il suffit de copier le module (fichier
chata.py) dans le répertoire de travail.
Il n'y a pas de dépendances (autres que la librairie standard de Python).


Et, maintenant, vous connaissez la musique(*) : à vous de tester.


@-salutations

Michel Claveau



(*) c'est le jour, non ?

Oui.

Et y'a quoi derrière ?

hg

Bonsoir !

C'est juste une petite gestion de fichiers en mémoire.

Mais, avec :
- gestion de plusieurs tables possible
- gestion d'index optionnels
- gestion de jointures entre tables
- sélections simples, mais combinables (avec intersection et union)
- gestion des déclencheurs (simplifiés)

Mais, j'ai encore plein de choses à inclure.

Bonne soirée.

MCI

Re !

Si tu veux savoir quelle est la structure interne, c'est simple :
- les données sont dans un dictionnaire. Seules les données sont
sauvegardées, avec cPickle
- les index sont recréés à la volée, au chargement d'une table
- la structure des tables n'est pas enregistrée ; elle doit être recréée
par script, avant le chargement.
- les sélections font appel au module SET
- les index font appel au modukle BISECT

Voilou.

Re-re !


Le but n'est pas de remplacer Oracle.
Mais, pour tout un tas d'application, on n'a pas forcément besoin de volumes
énormes, ou de gestion des accès simultanés.

J'ai fait un test, avec un petit fichier de 100 000 adresses (réelles). La
place sur disque est légèrement inférieure à 10 Mo (sans compression). Je ne
sais pas quelle est la place occupée en mémoire. Mais, même si elle est
trois fois plus grosse (avec la gestion interne et les index, ça ne ferait
que 30 Mo, pour des machines actuellement livrées avec 1 Go minimum).

Il y a donc de quoi traiter toute une classe d'applications. Et, cela peut
aussi venir en complément de grosses applications, pour lesquelles un vrai
SGBD sera utilisé. Je pense aux dizaines de petites tables "de service",
comme les unités, les monnaies, les codes-pays, les conditions de paiement,
les conditionnements, les tailles, les familles/sous-familles, les mesures,
les codes postaux, etc. que l'on rencontre tous les jours, en gestion.


@+

MCI

[encore un SGBD en mémoire]


Bonjour !

Je sais qu'il y en a beaucoup qui existaient déjà.
Mais, ils ne correspondaient pas tout à fait à mes besoins.

Du coup, j'en ai attaqué un. En pur Python (je n'ai testé que sous windows,
mais il n'y a pas de raisons pour que ça ne fonctionne pas sur d'autres OS).

Ce n'en est qu'au (tout) début. Il reste plein de fonctionnalités à
installer. Et, même, certaines déjà faites ne sont pas encore testées.

Il n'y a pas de doc, mais quatre exemples avec des tout-mini-riquiquis
commentaires.

C'est là : http://www.ponx.org/ponx/chata.htm

Ah, oui ! Il faut Python 2.5.
Il n'y a pas d'installation ; il suffit de copier le module (fichier
chata.py) dans le répertoire de travail.
Il n'y a pas de dépendances (autres que la librairie standard de Python).


Et, maintenant, vous connaissez la musique(*) : à vous de tester.

Tu as absolument besoin que ça soit tout en mémoire ?

Sinon, il y avait Buzhug qui est sympa.
http://buzhug.sourceforge.net/

@-salutations

Michel Claveau



(*) c'est le jour, non ?

Salut !

Sinon, il y avait Buzhug qui est sympa.

Buzhug est très bien. Mais, si je veux travailler sur disque, j'utiliserai
le BDE, SQL-server ou Oracle (c'est ce que je fais déjà, à 90 % avec le BDE,
8 % SQL-server, 2 % Oracle).

Maintenant, pour le travail en mémoire, je pense ariver à quelque chose de
plus facile à utiliser, tout en étant assez complet, fonctionnellement, pour
gérer des applications.

Au passage, j'ai mis en ligne la (nouvelle) version 0.01

@+

MCI

SQLITE ne ferait pas l'affaire ?
il permet de travailler aussi en mémoire, prend en charge le sql en
natif (donc les jointures) etc. ...

[encore un SGBD en mémoire]


Bonjour !

Je sais qu'il y en a beaucoup qui existaient déjà.
Mais, ils ne correspondaient pas tout à fait à mes besoins.

Du coup, j'en ai attaqué un. En pur Python (je n'ai testé que sous windows,
mais il n'y a pas de raisons pour que ça ne fonctionne pas sur d'autres OS).

Ce n'en est qu'au (tout) début. Il reste plein de fonctionnalités à
installer. Et, même, certaines déjà faites ne sont pas encore testées.

Il n'y a pas de doc, mais quatre exemples avec des tout-mini-riquiquis
commentaires.

C'est là : http://www.ponx.org/ponx/chata.htm

Ah, oui ! Il faut Python 2.5.
Il n'y a pas d'installation ; il suffit de copier le module (fichier
chata.py) dans le répertoire de travail.
Il n'y a pas de dépendances (autres que la librairie standard de Python).


Et, maintenant, vous connaissez la musique(*) : à vous de tester.


@-salutations

Michel Claveau



(*) c'est le jour, non ?

Bonjour !


En fait, je veux éviter SQL, pour travailler d'une manière beaucoup plus
naturelle.

Par exemple, je peux utiliser du code du genre :
articlecommande = 'CD10' #déclenche automatiquement le traitement de la
jointure commandes=>articles
prixarticle.value = articleprixunitaire.value
montant.value = quantite.value * prixarticle.value
tablecommande.commit()

Et puis, dans SQL-lite, je ne peux pas mettre une liste, ou un dictionnaire
(ou pire...), dans un champ (ou alors, il faudrait le Pickliser)

Enfin, comme c'est purement Python, les déclencheurs (triggers) se
programment en Python.


@+

MCI

Re !

J'ai quand même fini par faire une page un peu plus conséquente.
C'est toujours là : http://www.ponx.org/ponx/chata.htm

@-salutations

Michel Claveau