Discussion :

[grunk]

Bonjour à tous,

J'ai une table qui se constitue comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CREATE TABLE `licences` (
 
  `id` int(6) NOT NULL auto_increment,
 
  `numSerie` int(11) NOT NULL,
 
  `societe` int(11) NOT NULL,
 
  `type` smallint(6) NOT NULL,
 
  `hd` varchar(200) NOT NULL,
 
  `cm` varchar(200) NOT NULL,
 
  PRIMARY KEY  (`id`),
 
  KEY `societe` (`societe`,`type`),
 
  KEY `soc_fk_prd` (`type`)
 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

J'aimerais que le champs numSerie s'incrémente seul , mais et c'est là ou je ne sais pas faire, en fonction de type.
C'est à dire que si type =1 mon autoincrément peut être à 5 mais si si type = 2 il pourra être a 250.
Le but là derrière serait de ne pas avoir à faire un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT MAX(numSerie) WHERE type=x

avant de faire l'insert.

Si jamais il n'ya pas de solution , comment garantir que le numSerie récupéré par le SELECT est le bon et qu'il n'ya pas eu un nouvel enregistrement entre le select et l'insert ?

[qi130]

Une table ne peut avoir qu'une seule colonne auto-incrémentée (gérée par MySQL).

En plus, vue les spécificités de l'incrément, je te suggère de regarder du coté des triggers.

[grunk]

Merci pour ta réponse,

En fait mon problème est le suivant :

- Je dois récupérer le dernier numéro de série
- Je l'incrémente de 1 pour calculer une clé coté php
- si cette clé est bonne je fait un insert dans la table avec le numér ode série précédemment incrémenter.

Le problème d'un triggeur sur l'insert est qu'il ne me garentie pas qu'entre le calcul de clé et l'insert un nouveau numéro n'a pas été rentré.

Je suis entrain de regarder les LOCK TABLES WRITE , ca me semble pas mal :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 LOCK TABLES licences WRITE
SELECT MAX()....
# Calcul de ma clé coté PHP
UNLOCK TABLES
INSERT INTO ....

Qu'en pensez vous ?

[Xunil]

Je pose la question, à quoi servirait d'avoir un n° de série et en même temps un id ?
Ils sont tous les 2 uniques donc, y'a doublon.

[grunk]

Je pose la question, à quoi servirait d'avoir un n° de série et en même temps un id ?
Ils sont tous les 2 uniques donc, y'a doublon.

Mon id est effectivement unique mais le numéro de série ne l'ai qu'en fonction du type.
C'est à dire que pour le type 1 j'ai les numéros de séries 1,2,3,4,5,6 (et les id 1,2,3,4,5,6) mais pour type ==2 j'ai les numéros de séries 1,2,3,4,5,6 mais les id 7,8,9,10,11,12. Le but étant simplement de ne faire qu'une table pour tout mes numéros de séries plutôt que X tables en fonction du nombre de type(produit).

Après je suis pas responsable de la façon dont sont gérés les numéros de séries ^_^

[Maljuna Kris]

Saluton,

Mon id est effectivement unique mais le numéro de série ne l'ai qu'en fonction du type.
C'est à dire que pour le type 1 j'ai les numéros de séries 1,2,3,4,5,6 (et les id 1,2,3,4,5,6) mais pour type ==2 j'ai les numéros de séries 1,2,3,4,5,6 mais les id 7,8,9,10,11,12.

Peut-on en conclure que le couple série-type constitue un index UNIQUE, et laisser de côté l'id AUTOINCREMENT ?

[Sivrît]

Merci pour ta réponse,

En fait mon problème est le suivant :

- Je dois récupérer le dernier numéro de série
- Je l'incrémente de 1 pour calculer une clé coté php
- si cette clé est bonne je fait un insert dans la table avec le numér ode série précédemment incrémenter.

Le problème d'un triggeur sur l'insert est qu'il ne me garentie pas qu'entre le calcul de clé et l'insert un nouveau numéro n'a pas été rentré.

Je suis entrain de regarder les LOCK TABLES WRITE , ca me semble pas mal :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 LOCK TABLES licences WRITE
SELECT MAX()....
# Calcul de ma clé coté PHP
UNLOCK TABLES
INSERT INTO ....

Qu'en pensez vous ?

Ça me semble très lourd. Le "SELECT MAX" n'est pas tout à fait innocent car il va dépendre du type. Et surtout un "LOCK TABLE" interdit toute concurrence.

En toute logique il faudrait des séquences, que MySQL ne gère pas. A la main ça donne une table dans le genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE TABLE `sequences` (
  `name` char(10) NOT NULL,
  `nextvalue` int(11) NOT NULL,
   PRIMARY KEY  (`name`)
)

Ici, on en aura déjà une pour chaque type.

Ensuite on récupère la valeur suivante avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
SELECT nextvalue FROM sequences WHERE name=xxx FOR UPDATE;
UPDATE sequences SET nextvalue=nextvalue+1 WHERE name=xxx;

Idéalement, on fait immédiatement un "commit" pour ne pas verrouiller la séquence plus que nécessaire (et éviter les deadlock). Ça implique qu'en cas de rollback il y aura un trou dans la numérotation, mais c'est généralement acceptable, et c'est de toute façon le comportement de "AUTO_INCREMENT".

Évidemment, InnoDb de rigueur