[module] intermédiaire en base de donnée et dictionnaire

Bonjour, dans le cadre du developement de mon projet (herdelia), j'avais besoin d'un systeme permettant de stocké des données a la manière d'une base de donnée mais en beaucoup plus simple, et possédant plus de possibilité, j'ai donc coder un module sans prétention, que j'offre a qui veut bien l'utiliser ^^

Petites explications :
Ce module permet de stocker des tableaux a deux dimensions, possédant des index de n'importe quel type (entier, string etc...)
a la manière d'une base de donnée.

Les + par rapport a un dictionnaire.

Possibilités de "chercher" une valeur, contrairement au dictionnaire, a la manière d'un has_key() pour un dictionnaire, la méthode find() de mon module retourne les index dans une liste de liste.

Ca permet aussi de stocker plus de donnée, et de mieux les organiser quand dans un dictionnaire, utile quand on doit stocké et rangée un certains nombre de donnée dans la mémoire vive sans pour autant avoir envie ou besoin d'une base de donnée.

Le modules possède quelques méthodes de base, si certaines personnes sont intéressé pour en rajouter, même si c'est distribué sans license (je trouve pas ca nécessaire vu le peu de travail que ca a demandé), qu'il se sente libre de modifier ce qui lui plait et de le redistribuer.

Comme dit précedemment ce n'est pas particulierement super optimiser, ca tourne et ca peu être utile.

Méthodes disponibles :

add_c() => ajouter une colonne
add_l() => ajouter une ligne
put() => ajouter une entrée aux indexs donnés.
get() => récupérer une entrée
find() => chercher une entrée (retournes les index, dans une lsite de liste)
copy() => copier une entrée dans une autre
aff() => affiche l'entrée dans la fenetre système
find_i() => verifier si un index existe (retourne si c'est une ligne ou une colonne)

Je suis ouvert a tout commentaire !
Merci ^^

Voilà le lien :

http://www.megaupload.com/?d=M8KNESLP

Désolé pour le lien mégaupload :/

salut,

Bon alors j ai quelques détails technique et de conception a te dire.

Déjà je ne comprends pas trop cette obsession a faire un tableau proche de ceux des base de données sans avoir les avantage de ces derniers (possibilités de requêtes, performances élevé,...).
En effet aujourd'hui les genres font de plus en plus d'ORM pour profiter du monde objet des langages avec une source de donnée relationnel.
Mais ici on semble faire l'inverse, ramener les vieux tableaux dans le monde objet.
En effet personnellement j'aurai tout simplement utiliser un tableau d'objet (chaque objet représentant une ligne et chaque attribut représentant un entré de la colonne), a la rigueur si tu veux une recherche approfondi sur les objet on aurai pu encapsuler ca dans une classe et rajouter une méthode find() qui irai chercher dans les attributs des objets.
Sinon en cas de réél besoin de tableau comme dans les base de données avec de puissantes methode de recherche j’aurai utilisé sqlite avec une base stocké en mémoire et un coup de sqlobject par dessus à la rigueur.

Sinon d’un point de vue implémentation il y a quelques problèmes.
Déjà au niveau formalisme : les commentaires ne s’écrivent pas comme ca en python.
Il faut mettre """ """ au début de chaque membre (module, classe, …)
Ya des normes de notation assez importante comme la notation des classe avec des majuscule (MyClass, pas myclass)
Ensuite au niveau notation des variables c assez souvent illisible.
En général on ne met pas de type dans le nom de la variable et surtout pas que le type (comme le dicco et dico qui se suivent, ind_l et ind__l, berk !!) mais on doit le décrire en quelque mot. Sinon par exemple le dico_ref_l n’aurai pas été plus lisible en écrivant simplement "lines" ?
A cause de cette illisibilité je n ai pas poussé la lecture à fond, c’est vraiment un élément important dans le cas de partage de code.
Ensuite j ai vu certaines chose inutile :

Code:

---

1 2	a = 0 for a in self.dico_ref_c.keys() :

---

Inutile d’initialisé a il va prendre toutes les valeurs des clefs.
Je n’ai pas bien compris l’utilisation de 2 dictionnaires pour les colonnes et les lignes …
En effet tu utilise comme ligne un int que tu transforme en string et que tu incrémente a chaque fois … je ne vois pas bien l’intérêt de ce genre de clef dans un dictionnaire dont le principe est d’avoir un clef pertinente. Dans ce cas autant utiliser un tableau de tableau qui sera toujours organisé sur des clefs d’int ascendante dans les colonnes et les lignes, les manipulations dans la suite aurai été BEAUCOUP plus simple et cela aurai fait gagner un paquet de ligne de code.
Je trouve les utilisation de globals() partout archi degueulasse et encore une fois peu lisible.
Si on parle des perf, je pense qu’il y a un gouffre de performance un peu partout :
- L’utilisation massive de dictionnaire la ou il ne faut pas (les dictionnaires avec comme index des int qui s’incrémente)
- L’utilisation massive de global()[str]
- L’enchainement des " a " + " b " + " c " + … dans la création des strings (au lieu d’utiliser des format)

Sinon inutil de faire :

Code:

---

1 2	dicco = [self.dico_ref_l[a], self.dico_ref_c[b]] dico.append(dicco)

---

autant faire

Code:

---

dico.append([self.dico_ref_l[a], self.dico_ref_c[b]])

---

Bon voila j’espère que tu prendra pas mal la critique et bon courage pour ton jeu ;)

Citation:

---

Déjà je ne comprends pas trop cette obsession a faire un tableau proche de ceux des base de données sans avoir les avantage de ces derniers (possibilités de requêtes, performances élevé,...).
En effet aujourd'hui les genres font de plus en plus d'ORM pour profiter du monde objet des langages avec une source de donnée relationnel.
Mais ici on semble faire l'inverse, ramener les vieux tableaux dans le monde objet.
En effet personnellement j'aurai tout simplement utiliser un tableau d'objet (chaque objet représentant une ligne et chaque attribut représentant un entré de la colonne), a la rigueur si tu veux une recherche approfondi sur les objet on aurai pu encapsuler ca dans une classe et rajouter une méthode find() qui irai chercher dans les attributs des objets.
Sinon en cas de réél besoin de tableau comme dans les base de données avec de puissantes methode de recherche j’aurai utilisé sqlite avec une base stocké en mémoire et un coup de sqlobject par dessus à la rigueur.

---

L'interêt était surtout de pouvoir avoir un tableau clair et contenant des données plus facielemnt récupérable en vu de leurs nombres que dans un dictionnaire sans utiliser du sql.

Citation:

---

Sinon d’un point de vue implémentation il y a quelques problèmes.
Déjà au niveau formalisme : les commentaires ne s’écrivent pas comme ca en python.
Il faut mettre """ """ au début de chaque membre (module, classe, …)

---

Les triples guillements sont utilisés pour faire de la doc, j'ai fait une doc a côté c'est pour cela que je n'ai pas mis les triples paires de guillemets.

Citation:

---

Ya des normes de notation assez importante comme la notation des classe avec des majuscule (MyClass, pas myclass)
Ensuite au niveau notation des variables c assez souvent illisible.

---

Mouai mouai les normes de notations des classes hein... c'est un peu arbitraire, mais il est vrai que c'est la norme et que je ne l'ai pas respecté ^^
Pour le nom des variables, quand j'ai commencé a developper cette classe , ce n'étais pas dans le but de la partager donc je n'ai pas vraiment fait d'efforts de syntaxe.

pour l'initialisation de la variable a, comme je fait aussi du C et du java j'ai été pris de doute sur si il fallait l'initialiser ou pas, dans le doute je l'ai initialisé.

Citation:

---

Je n’ai pas bien compris l’utilisation de 2 dictionnaires pour les colonnes et les lignes …
En effet tu utilise comme ligne un int que tu transforme en string et que tu incrémente a chaque fois … je ne vois pas bien l’intérêt de ce genre de clef dans un dictionnaire dont le principe est d’avoir un clef pertinente. Dans ce cas autant utiliser un tableau de tableau qui sera toujours organisé sur des clefs d’int ascendante dans les colonnes et les lignes, les manipulations dans la suite aurai été BEAUCOUP plus simple et cela aurai fait gagner un paquet de ligne de code.

---

L'interêt c'est de pouvoir agir sur le tableau, aussi bien avec les numéro qu'avec les noms des index. Ensuite il fallait bien que je signale quelle index correspondait a quelle ligne ou quelle colonne.

Citation:

---

Dans ce cas autant utiliser un tableau de tableau qui sera toujours organisé sur des clefs d’int ascendante dans les colonnes et les lignes, les manipulations dans la suite aurai été BEAUCOUP plus simple et cela aurai fait gagner un paquet de ligne de code.

---

Tu ne peut pas utiliser un tableau de tableau, car si l'utilisateur rajoute une colonne, tu va faire un append() sur tous tableaux présent dans le tableau ?
bref, ca aurait poser des problme plus compliqué a résoudre.
J'ai utiliser ce type de structure, car elle est maléable et permet de pouvoir facilement faire ce qu'on veut avec, contrairement a un tableau de tableau ou toutes manipulations s'avère plus compliqués.

Citation:

---

L’utilisation massive de dictionnaire la ou il ne faut pas (les dictionnaires avec comme index des int qui s’incrémente)

---

effectivement j'aurais put utiliser des listes, pour les indexs, c'est resté des dictionnaire car au début il n'y en avait qu'un qui avait des clé de la forme '2.l' ou '3.C', et je n'ai pas voulu tout rechanger.

Citation:

---

L’utilisation massive de global()[str]

---

Je n'avais pas vraiment le choix ^^ Le seuls moyen de déclarer des variables a nomenclature dynamique c'est globals() ou locals(), j'aurais difficilement put faire autrement. Tu me dirais que j'aurais put utiliser des listes, mais la encore c'est beaucoup plus facile et pratique de manipuler des variables qu'une liste qui risque de changer constamment.

Citation:

---

Bon voila j’espère que tu prendra pas mal la critique et bon courage pour ton jeu

---

Tes critiques sont les bienvenues ^^ et merci :p

Bonjour,

Perso, je suis assez d'accord avec Anthyme : pourquoi éviter sql et les bases de données relationnelles ? le sql est très facile à maîtriser et les SGBD-R sont nombreuses, de la plus simple à la plus compliquée. Sans compter qu'ODBC (ou JDBC) permet des accès très faciles...

Quand à l'installation elle-même, il suffit de déployer EasyPHP ou WAMP5 pour disposer automatiquement d'une belle base MySQL, par exemple... 5 mn chrono sans rien y connaître ou presque.

Pourquoi ré-inventer la roue ?

Bonjour,
à ce sujet
Comment pourrais je faire pour visualiser sous un tableau en wx une base sqlite.

Avant de savoir que cela existait, J'ai refait une classe avec des requètes (c'est pénible) et du wx un peu comme slade

Mais je voudrais savoir quel ORM utiliser.
J'ai commencé à SQLALCHEMY, je vois qu'il y a SQLOBJET je me demande du coup ce qui est le plus adapté et pérenne (dans la forêt de lib existante...)
Merci de votre réponse.

Citation:

---

Bonjour,

Perso, je suis assez d'accord avec Anthyme : pourquoi éviter sql et les bases de données relationnelles ? le sql est très facile à maîtriser et les SGBD-R sont nombreuses, de la plus simple à la plus compliquée. Sans compter qu'ODBC (ou JDBC) permet des accès très faciles...

Quand à l'installation elle-même, il suffit de déployer EasyPHP ou WAMP5 pour disposer automatiquement d'une belle base MySQL, par exemple... 5 mn chrono sans rien y connaître ou presque.

Pourquoi ré-inventer la roue ?

---

Je fait du sql depuis un certain temps, le probleme n'est pas l'apprentissage ou le temps d'installation mais la lourdeur. Je developpe un mmorpg et je ne vais pas déployer une base de donnée du côté client pour stocker une liste d'objets un peu grosse.
Comme dit dans le titre l'interêt c'est de proposer une solution intermédiaire.

SQL est intéressant quand il y a une certaine masse de donnée a stockés et que ces données doivent resté dans le temps. Ma classe permet des méthodes similaire a SQL pour de plus petites structures et qui doivent resté en mémoire vive car elles ne sont pas forcément statique, et n'ont pas forcément besoin d'être stocké sur du long terme.

Citation:

---

Envoyé par alexdevl

Bonjour,
Mais je voudrais savoir quel ORM utiliser.
J'ai commencé à SQLALCHEMY, je vois qu'il y a SQLOBJET je me demande du coup ce qui est le plus adapté et pérenne (dans la forêt de lib existante...)
Merci de votre réponse.

---

Il y en a 3 qui se detache vraiment :

sqlalchemy : le plus puissant mais également le plus complexe a utiliser
sqlobject : le plus facile a utiliser dans les lib cliente mais un peu leger vis a vis des 2 autres
django orm : mon preféré car vraiment efficace simple et permet de faire totalement une croix sur le SQL apres il est surtout bien intégré dans le framework django il est integrable dans d'autre application mais il faut passer par des variable d'environements pour definir la base, utilisateur, ...

moi jte conseil celui de django

ok merci