Solution miracle anti-doublon

Version imprimable

08/04/2008, 10h56
Gueritarish

Solution miracle anti-doublon
Bonjour,

Alors que j'explique un peu mon appli... Je parse un fichier XML pour pouvoir insérer en base de donnée les paramètres présent dans les balises. Par exemple :
Code:

1 2 3 4 5 <balise mere> <balise fille [attributs]> parametres </balise fille> </balise mere>
Bon, le parsing du fichier se passe très bien. Ensuite, ce qu'il faut savoir, c'est que je travaille sur des fichiers assez volumineux (de l'ordre de 500 000 lignes :aie:). J'utilise SAX pour parser le fichier (normal).
Donc, mon soucis serait de vérifier la présence de doublon dans les paramètres à insérer en base... Sans faire de SELECT, et sans utiliser trop de mémoire 8O
C'est pour ça que je mets "solution miracle".
Pour l'instant, ma méthode consiste à partir du postulat que les balises devraient être ordonnées et donc j'utilise un Set que je ré-initialise quand je change de groupe de balises. Puisque j'utilise un Set, il n'y a pas de doublon à l'ajout. Donc, je regarde si le groupe de paramètres a été ajouté ou pas.

J'espère avoir été clair. Sinon, n'hésitez pas à demander des précisions. :mrgreen:

Voilà, je suis réceptif à vos idées/conseils/propositions/canard laqué...
++
Gueritarish
08/04/2008, 11h53
Seb19

Citation:

Envoyé par Gueritarish

Donc, mon soucis serait de vérifier la présence de doublon dans les paramètres à insérer en base... Sans faire de SELECT, et sans utiliser trop de mémoire 8O

Bonjour, et pourquoi ne pas mettre une contrainte d'unicité sur les paramètres au niveau de la base de données. Il te suffiera ensuite de gérer le code retour du double insert.
08/04/2008, 11h56
Gueritarish

Citation:

Envoyé par Seb19

Bonjour, et pourquoi ne pas mettre une contrainte d'unicité sur les paramètres au niveau de la base de données. Il te suffiera ensuite de gérer le code retour du double insert.

Le problème c'est que je n'ai pas le droit de toucher à l'architecture des tables dans la base de donnée...
08/04/2008, 12h51
Seb19

Dans ce cas, tu pourrais peut être utiliser une Hashtable dans laquelle tu stockerais tes données avant l'insertion en base, avec les méthodes containsValue et containsKey pour éviter les doublons.
08/04/2008, 12h55
Gueritarish

Citation:

Envoyé par Seb19

Dans ce cas, tu pourrais peut être utiliser une Hashtable dans laquelle tu stockerais tes données avant l'insertion en base, avec les méthodes containsValue et containsKey pour éviter les doublons.

En fait, c'est ce que je faisais, mais je me retrouve avec un OutOfMemoryError à la 15 000ème requêtes d'ajout de balise du même "groupe" en base ...
C'est pour ça que j'étais passé par les Set... Mais bon, ça marche pas non plus.

En tout cas, merci de tes réponses ^^

++
Gueritarish
08/04/2008, 13h07
Tommy31

Tu devrais utiliser un set, dans lequel tu stockes non pas la valeur mais l'empreinte (hash) de cette valeur. Ce qui te fera gagner de la mémoire.

Reste à gérer les faux positifs lors d'une collision. Là, à moins de recourir à un select...
08/04/2008, 14h23
Gueritarish
En fait, je suis pas sur que ta solution puisse marcher... Puisque je mets les paramètres récupérés dans une HashMap qui est du style :

Code:

{mere.fille.attribut = att; mere.fille.fille_nest = parametres}

dans l'exemple suivant :
Code:

1 2 3 4 5 <balise mere> <balise fille [attributs]> <balise fille_nest>parametres</balise fille_nest> </balise fille> </balise mere>
Donc, même si les paramètres sont les mêmes, les Map seront différentes, et auront une empreinte différentes.. :cry:

Voilà, ++
Gueritarish
08/04/2008, 16h30
shaun_the_sheep

Tu utilises quel type de bdd ?

une solution pourrait être l'utilisation de table sql temporaire libre à toi de mettre la clé sur la contrainte d'unicité voulu et c'est transparent en bdd (tout au moins sur oracle).
08/04/2008, 16h32
Tommy31

J'en viens à converger vers le même type de solution. Si le stockage mémoire est impossible, alors recourir a un mécanisme de persistance on disk.
08/04/2008, 16h35
shaun_the_sheep

on peut même aller plus loin en utilisant un procedure sql stocké et la c'est le serveur de bdd qui bosse en plus.
08/04/2008, 16h38
tchize_

Comme suggéré plus haut: tu tiens un Set qui ne contient que des Hash de chaque fille (à toi de coder la fonction de hash correctement pour qu'elle soit indépendant de la mère). Tu peux ainsi associer à chaque row un entier de 64bits (long). Ca te fait normalement 18446744073709551616 possibilité. Si tu as 500.000 entrées, les probabilités d'une fausse collision sont de 1 sur 3.16E13, soit très faibles :) (calcul à la louche!). L'occupation mémoire serait, si on imagine que les donnée de gestion dans le hashset sont d'une centaine d'octet par entrées, plus ou moins 50M. En cas de match dans le set, il te faudra inévitablement controller la db pour voir si il ne s'agit pas d'un faux positif.
08/04/2008, 16h42
Gueritarish

Le truc c'est que je peux vraiment pas touché à la base de donnée.. Rien de rien. Je peux insérer dans champs dans certaines tables, et c'est tout...
D'où mon penchant pour une solution "miracle" qui n'utiliserait pas trop de mémoire, pas de code sur la base de donnée...mais qui m'empêcherait d'essayer d'insérer des doublons...

Bon, ça tient du vodoo et de la magie noire, mais sans arriver au sacrifice humain, je le sais bien :aie:
Mais bon, il me faudrait trouver une solution...

Pour l'instant, c'est une solution pas très élégante que j'ai "trouvé"... Je fais l'INSERT quand même et j'ai une SQLException : violate primary key constraint (un truc dans ce goût là...)
Et donc, l'ajout ne se fait pas :mrgreen:
Mais c'est pas du tout élégant

Voilà, ++
Gueritarish qui fait la dance anti-doublon-de-la-pluie
08/04/2008, 16h47
tchize_

Citation:

Envoyé par Gueritarish

Pour l'instant, c'est une solution pas très élégante que j'ai "trouvé"... Je fais l'INSERT quand même et j'ai une SQLException : violate primary key constraint (un truc dans ce goût là...)
Et donc, l'ajout ne se fait pas :mrgreen:
Mais c'est pas du tout élégant

Et en quoi c'est pas élégant, çà a été suggéré plus haut par Seb19, de mettre une contrainte d'unicité. Tu as dit que c'était pas possible. Mais si elle est déjà la sur ta table, ton problème ne se pose pas, ton gestionnaire de DB s'occupe des contraintes, comme un grand, c'est sont boulot. Toi tu catche l'erreur et tu passe au suivant :/

Tu te rends compte qu'on est là occupé de te proposer des solutions en supposant qu'il n'y a pas de contrainte d'unicité formelle dans le schéma (oubli du designer ou que sais-je) et que tu ne peux pas en rajouter, donc que tu dois checker faire toi même le boulot que ferais la DB?? Alors que finalement non seulement le problème n'existe pas, mais en plus on t'avais servir la solution de base la plus standard et tu a dit que 'était 'impossible' ??

Bref donc, ton problème n'existe pas
08/04/2008, 16h53
Gueritarish

Euh... au temps pour moi :oops:

Désolé tout le monde.
Je pensais à quelque chose de plus "propre", mais effectivement, je dois dire que j'ai pas trop réfléchi à cette solution là. Je dois avouer que je suis pas trop expert DB :?
Encore une fois mea culpa.

Et merci à tout le monde pour m'avoir proposé des solutions... :oops:

++
Gueritarish qui s'excuse encore une fois