[JDBC]problème avec mes id

Version imprimable

28/09/2005, 18h05
Hydre

[JDBC]problème avec mes id

mes clés primaires sont en auto-incréments. Par exemple j'ai 3 enregistrements. ca donne 1,2,3 :D mais si j'efface le 3eme et que j'en crée un nouveau, il aura l'id 4 alors qu'il devrait avoir le 3... comment régler ce problème ?

[ Modéré par SEMPERE Benjamin ]
Ajout d'un tag dans le titre
:arrow: Les Règles du Forum
28/09/2005, 18h11
Jfrancois57

Mettre du code c'est plus simple pour les réponses
28/09/2005, 18h11
NGY

1- Quel est le rapport avec Java ?

2-

Citation:

mais si j'efface le 3eme et que j'en crée un nouveau, il aura l'id 4 alors qu'il devrait avoir le 3

Qui a dit que ce devait être 3 ?

3- Si tu veux un comportement "sur-mesure", alors tu n'as qu'une solution : programme-le ! (c'st valable pour tous les langages).

Citation:

Envoyé par Jfrancois57

Mettre du code c'est plus simple pour les réponses

voila un insert

Code:

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
  public int insertLieu(Lieu l) {
    int idxRet = -1;
    String sql = "INSERT INTO t_lieu (l_npa, l_ville) " +
        "VALUES ('" + l.getL_npa() + "', '" + l.getL_ville() +"')";
    int nbrRec = dbc.executeSQL(sql);
    if (nbrRec == 1) {
      // recherche de l'index
      String rsql = "SELECT l_id FROM t_lieu WHERE l_ville = '" + l.getL_ville() +
          "' AND l_npa = '" + l.getL_npa() + "'";
      ResultSet rs = dbc.createResultSet(rsql);
      try {
        if (rs != null) {
          rs.next();
          idxRet = rs.getInt(1);
        }
      }
      catch (SQLException se) {
        dbc.showListSqlExceptions(se);
      }
      try {
        if (rs != null) {
          rs.close();
        }
      }
      catch (SQLException se) {
        dbc.showListSqlExceptions(se);
      }
    }
 
    return idxRet;
  }

28/09/2005, 18h59
Hydre

Citation:

Envoyé par NGY

1- Quel est le rapport avec Java ?

2-

Citation:

mais si j'efface le 3eme et que j'en crée un nouveau, il aura l'id 4 alors qu'il devrait avoir le 3

Qui a dit que ce devait être 3 ?

3- Si tu veux un comportement "sur-mesure", alors tu n'as qu'une solution : programme-le ! (c'st valable pour tous les langages).

ben se serait mieux que se soit 3, sinon au bout d'un moment ca fera de très gros id
28/09/2005, 23h32
dlemoing

Citation:

Envoyé par Hydre

ben se serait mieux que se soit 3, sinon au bout d'un moment ca fera de très gros id

Et que fais tu de l'unicité de ton identifiant qui doit te servir à identifier un enregistrement unique.
Exemple 1 :
- l'utilisateur 1 enregistre 1 ligne dans ta table et récupere l'id 3
- l'utilisateur 1 enregistre 1 ligne dans ta table et récupere l'id 4
- l'utilisateur 2 supprime l'enregistrement avec l'id 4
- l'utilisateur 2 enregistre 1 nouvelle ligne et récupère l'id 4
- l'utilisateur 1 fait une recherche sur l'id 4 et ne comprend pas pourquoi il ne reconnait pas son enregistrement...la clé primaire ne remplit pas son role : identifier un enregistrement unique.

Exemple 2 :
- tu enregistres 1 ligne dans ta table, tu récuperes l'id 3
- tu enregistres 1 ligne dans ta table, tu récuperes l'id 4
- tu supprimes l'enregistrement avec l'id 3
- tu enregistres 1 nouvelle ligne...qu'est ce que tu attends ? 3 ou 5 ?

Tout ca pour dire que ce que tu cites comme étant un problème n'en est pas un en réalité. Et l'approche est la même dans les différentes bases (champs avec auto-incrémentation, séquences, pseudo-séquences...)
29/09/2005, 09h22
tomca

Sinon, si c'est vraiment ce que tu veux faire...plutôt que d'utiliser un auto-increment, tu lance une petite requete genre : select MAX (id) from ma_table
Un fois ton résultat récupéré, ben t'ajoute 1...
Par contre, question perf c'est pas le top...
29/09/2005, 09h25
Alwin

Citation:

Envoyé par tomca

Sinon, si c'est vraiment ce que tu veux faire...plutôt que d'utiliser un auto-increment, tu lance une petite requete genre : select MAX (id) from ma_table
Un fois ton résultat récupéré, ben t'ajoute 1...
Par contre, question perf c'est pas le top...

SURTOUT PAS ;)
Ne jamais faire ceci
Les commits des transactions en cours vont te générer des doublons sinon

exemple: 2 enregistrements ds la base respectivement PK 1 et 2.
Un utilisateur ajoute un 3 ème enregistrement et un second utilisateur en fais de même, il récupère aussi une PK à 3 tant que le premier utilisateur n'as pas commité son insert !
29/09/2005, 09h28
tomca

Effectivement...
Enfin, moi je me sert de ca pour faire du traitement de donnée, et je suis certain d'être le seul a bosser sur la table...donc ca fonctionne...
Mais tu as raison, j'avais pas pensé au multi-utilisateur...
29/09/2005, 09h47
Tiaps

Salut,

Ca pourrait marcher si une seule méthode s'occupe de récupérer le max et d'enregistrer et que cette méthode est synchronized?
29/09/2005, 10h04
Alwin

non, le problème de viens pas de ton process java mais de la base de données !
En gros, il te faut écrire une procédure stockée synchronized et ça, je sais même pas si c'est du domaine du faisable :)
29/09/2005, 12h14
NGY

Oui, c'est un problème de BD uniquement, de conception plus précisémentUn "bon" identifiant ne doit pas servir à autre chose que d'identifier de façon unique une ligne dans la table.
En voulant absolument "boucher" les trous dans la séquence, on donne un nouveau rôle à l'identifiant.
Un numéro de séquence ne fait qu'augmenter et une suppression dans la table générera forcément un "trou" ... et alors ?!

Si tu veux conserver un numéro d'ordre dans les lignes de la tables, il faut ajouter une colonne et la gérer toi-même.
29/09/2005, 13h19
CheryBen

J'ai fait le même constat récemment, mais ça ne vient pas du code, ça vient simplement du système de gestion de base de données.

Pour voir quand la base explosera j'ai fait un petit calcul :

- estimation du nombre d'enregistrement que j'ai par an (100 par jour * 365)
- maximum de l'identifiant, c'est un int, 2 147 483 647.

Ensuite une petite division 2 147 483 647 / (100*365), et voila, ma base explosera dans environ 58 000 ans :lol: , amuse toi à faire pareil et ça m'étonnerait que tu arrives à la limite avant quelques années :wink: