Discussion :

[chekkal]

Bonjour à tous,

J'ai une application pour supérette, et à chaque nouvelle vente une incrémentation du numéro de ticket est effectuée de la manière suivante:

Code :

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

1
2
 
select max(ticket) from vente

la méthode marche très bien jusqu'au la table arrive à 300 000 lignes là ça commence à devenir lent et à 500 000 ligne ça devient encore plus lent. Je ne sais pas s'il ya une méthode plus efficace d'incrémentation

[Barbibulle]

Oui d'une il faut utiliser un générateur qui est le seul moyen en multiposte d'avoir un numéro unique.
Mais si vous êtes en monoposte et préférez utiliser le max(ticket) (qui est une mauvaise pratique) il faut absolument que ticket soit indexé (soit c'est la clé primaire soit il y a un index unique).
Sinon max(ticket) oblige firebird à balayer tous les enregistrements de la table pour trouver le plus grand....

[SergioMaster]

Bonjour,
Un autre SQL pourrait faire l'affaire , toujours si TICKET est un index

Code :

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

1
2
3
SELECT FIRST 1 TICKET FROM VENTE ORDER BY TICKET DESC 
--ou 
SELECT TICKET FROM VENTE ORDER BY TICKET DESC ROWS 1

mais la SEQUENCE (ou GENERATEUR), traité de plus dans un TRIGGER est vraiment la meilleure solution

[chekkal]

Bonjour,

Le probléme du génerateur c'est qu'il incrémente la valeur de ticket sans prendre en considération si le ticket est validé ou non ou même supprimé, et comme ça il ya plus de concordance entre le numéro ticket du génerateur et le numéro ticket phisique.Par contre la solution proposé par @sergio peut faire l'affaire, il faut voir maintenant est-ce qu'elle prend plus de temps que la méthôde max

[Barbibulle]

Bonjour,

Le probléme du génerateur c'est qu'il incrémente la valeur de ticket sans prendre en considération si le ticket est validé ou non ou même supprimé, et comme ça il ya plus de concordance entre le numéro ticket du génerateur et le numéro ticket phisique.Par contre la solution proposé par @sergio peut faire l'affaire, il faut voir maintenant est-ce qu'elle prend plus de temps que la méthôde max

La méthode max ou un order by seront équivalentes et nécessitent toutes les deux la création d'un index.

Le générateur va créé des trous dans le cas d'un ticket non validé. Mais ca peut faire l'objet d'une gestion séparée.
Vous êtes forcément en monoposte sinon vous auriez eut des problemes avec max().

[chekkal]

Vous êtes forcément en monoposte sinon vous auriez eut des problemes avec max().

Non, j'utilise max aussi en réseau et ça marche très bien a part la lenteur

[Barbibulle]

Non, j'utilise max aussi en réseau et ça marche très bien a part la lenteur

Oui ça fonctionne jusqu'à ce que ça ne fonctionne plus.

C'est comme traverser une route sans regarder s'il y a des voitures. Sur une route peu passante vous traverserez sans problème (même s'il y a un risque). La plupart du temps vous traverserez ça ne veut pas dire que c'est une bonne pratique...

[Artemus24]

Salut à tous.

C'est le cas typique de la gestion des paramètres d'une application.
Pour ce faire, j'utiliserai une table de nom 'parametres' dédiée à ce genre de problème.
Sachant que chaque paramètres est identifié par le rang dans la table.
Ainsi id=5 signifie, par convention, que c'est le dernier numéro du ticket.

Dans un premier temps, je lis la table afin de récupérer la dernière valeur du ticket. Genre :

Code :

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

select val from parametres where id = 5;

Je fais ensuite un : num = ticket + 1.

Puis je mets à jour la table 'parametres', en venant écraser 'ticket' par la valeur de 'num'. Genre ;

Code :

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

update parametres set val = :num where id=5;

Voilà pour le principe et cela est très performant, car tu lis qu'un seul enregistrement.

Je suis d'accord avec Barbibulle, il est nécessaire dans les solutions proposées, d'avoir un index.

Hormis ce que je propose, il n'y a pas de solutions performantes pour ce genre de problème.

@+

[Barbibulle]

@Arthemus24

Ta solution comporte les mêmes risque de collision.

Si deux caisses demandent un numéro de Ticket simultanément elles risquent d'avoir le même numéro.

La réponse de Firebird à ce genre de problème et également pour les identifiants uniques s'appel un Générateur.

[chekkal]

C'est pas être prétentieux, mais depuis que je suis sur ce forum j'expose toujours des cas existantes(pratiqué), ce problème je l'ai eu chez l'un de mes clients qui à une grande surface avec 15 caisses(poste client) et pour remédier à tous les problème de confrontation de plusieurs poste sur le même ticket, je rafraichi automatiquement la base de données

Code :

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

1
2
3
4
 
bd1.connected:=false;
bd1.connected:=true;
///en suite j'execute la commande max

[SergioMaster]

Et après ton client se plaint de la lenteur !

le générateur, la norme préfère que l'on dise la séquence, n'a pas obligatoirement a être le numéro du n° du ticket !

La méthode max ou un order by seront équivalentes et nécessitent toutes les deux la création d'un index.

j'avais bien indiqué toujours si TICKET est un index

ce trigger par exemple utilisera la séquence pour avoir un numéro unique et récupérera le dernier numéro de ticket+1 à la manière d'Artemus24
Attention : écrit sans filet , SELECT INTO non testé

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
22
 
CREATE GENERATOR GEN_VENTE_ID;
CREATE TABLE VENTES (NUMEROVENTE DECIMAL(18,0) NOT NULL,
                              NUMEROTICKET DECIMAL(18,0) NOT NULL,
                              ....
                              );
ALTER TABLE VENTES ADD CONSTRAINT  PK_VENTES PRIMARY KEY(NUMEROVENTE); -- index
CREATE UNIQUE INDEX IDX_TICKET ON VENTES (NUMEROTICKET);                                    -- index 
 
SET TERM ^ ;
CREATE TRIGGER TICKET_BI FOR VENTES ACTIVE
BEFORE INSERT POSITION 0
AS
DECLARE VARIABLE tmp DECIMAL(18,0);
BEGIN
  IF (NEW.NUMEROVENTE IS NULL) THEN
   BEGIN 
     SELECT COALESCE(NUMEROTICKET,0) +1  FROM VENTES WHERE NUMEROVENTE=GEN_ID(GEN_VENTE_ID, 0) INTO NEW.NUMEROTICKET;
     NEW.NUMEROVENTE = GEN_ID(GEN_VENTE_ID, 1);
   END
END^
SET TERM ; ^

pour renforcer encore la vitesse d'exécution du SELECT un index en ordre descendant et forcer un PLAN pourrait même être envisageable

[EDIT] testé mais pas en multi postes, cette solution présente l'avantage d'être mise en place dans une base existante assez facilement
pour mon test mono poste, base vide, j'ai fait quelques inserts de la manière suivante :
INSERT INTO VENTES VALUES (NULL,5); -- répétés 7 fois
résultat :

1 5
2 6
3 7
4 8
5 9
6 10
7 11

Constation : à quelque chose erreur est bonne, il n'était pas prévu que je mette quoique ce soit dans le INSERT mais n'ayant pas d'autres champs dans la table VENTE et trouvant un INSERT INTO VENTES VALUES (NULL,NULL) un peu nul, c'est le moins que l'on puisse dire, je voulais voir ce qui pouvait se passer dans ce cas ! je m'attendais à ce que les valeurs des numéros de tickets soit de 1 à 7 mais non mon SELECT est à revoir le COALESCE ne fonctionne pas ! (pourquoi d'ailleurs ?)

je m'en sors en rajoutant IF (NEW.NUMEROTICKET IS NULL) THEN NEW.NUMEROTICKET=1; après le SELECT
bien sur j'aurais simplement pu faire INSERT INTO VENTES VALUES(NULL,1) mais c'est moins drôle

[alanglet]

Bonjour,

Dans un premier temps, je lis la table afin de récupérer la dernière valeur du ticket. Genre :

Code :

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

select val from parametres where id = 5;

Je fais ensuite un : num = ticket + 1.

Puis je mets à jour la table 'parametres', en venant écraser 'ticket' par la valeur de 'num'. Genre ;

Code :

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

update parametres set val = :num where id=5;

Ça, c'est ce que je faisais il y a 15-20 ans avec des tables Paradox. Mais il ne faut pas oublier dans ce cas de "poser un verrou" sur la table parametres juste pour le temps de l'opération, sans cela il y a risque de collision avec un autre utilisateur. Jamais essayé, mais il me semble qu'il est possible de le faire avec Firebird en paramétrant une transaction spécialement pour ça.
Les trous dans les numéros de commande! Ça a toujours été l'objet de querelles avec les comptables. Je n'ai jamais su si c'était une obligation légale ou un simple moyen de contrôle...

André

[Barbibulle]

Les trous dans les numéros de commande! Ça a toujours été l'objet de querelles avec les comptables. Je n'ai jamais su si c'était une obligation légale ou un simple moyen de contrôle...

Le droit à l'erreur ça existe, vous tiendriez un facturier dans un cahier à la main. Même en faisant très attention, à un moment donné il y a aura une erreur, ce n'est pas pour autant qu'il faut masquer la ligne, ou refaire le cahier...

Une facture ou ticket numéroté qu'on "annule" il suffit d'avoir prévu une colonne "annulation" ou bien gérer une table des numéros annulés. Le destinataire de la facture/ticket c'est tout simplement la poubelle.

[SergioMaster]

Bonjour,

Les trous dans les numéros de commande! Ça a toujours été l'objet de querelles avec les comptables. Je n'ai jamais su si c'était une obligation légale ou un simple moyen de contrôle...

Dans les numéros de commande là je pense que les comptables sont pointilleux et confondent avec les numéros de factures pour ces derniers cela semble être une obligation légale du moins je le pense : les contrôles fiscaux sont très pointilleux à ce sujet
il m'a même été demandé de mettre avoir et facture dans la même suite .
par exemple 2015-1 facture
2015-2 facture
A2015-3 Avoir
2015-4 facture
etc...
alors qu'avant je numérotais les avoirs et les factures dans des séquences différentes

[alanglet]

Ah! les comptables qui font tous les jours des sommes à la main pour vérifier que l'informatique ne s'est pas trompée...
Pour en revenir au problème du numéro unique sans trou dans la suite, la solution de la table "parametres" peut être utilisable en bloquant les accès pendant la lecture et la mise à jour. Avec Firebird ceci devrait pouvoir être fait dans une transaction particulière ayant les options:
LockRead
LockWrite
Wait pour attendre que la table soit libérée si un autre utilisateur fait la même manip (très courte).
Si quelqu'un a essayé...

André

[SergioMaster]

Ah! les comptables qui font tous les jours des sommes à la main pour vérifier que l'informatique ne s'est pas trompée...

et qui nous font tout un plat en cas d'écart de 1 cent !
mais n'oublions pas dans comptable il y a table

Avec Firebird ceci devrait pouvoir être fait dans une transaction particulière ayant les options:
LockRead
LockWrite
Wait pour attendre que la table soit libérée si un autre utilisateur fait la même manip (très courte).
Si quelqu'un a essayé...

jamais essayé, la technique que j'ai proposé étant un trigger donc une transaction je pense qu'elle sera fiable. Cependant je n'ai pas d'environnement pour faire des tests poussés (deux postes dont l'un comme serveur c'est peu) et il me faudrait faire un programme simulant des insertions (bah c'est faisable mais bon déjà pas mal que je propose une solution non ?)

[alanglet]

Bonsoir,

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
22
 
CREATE GENERATOR GEN_VENTE_ID;
CREATE TABLE VENTES (NUMEROVENTE DECIMAL(18,0) NOT NULL,
                              NUMEROTICKET DECIMAL(18,0) NOT NULL,
                              ....
                              );
ALTER TABLE VENTES ADD CONSTRAINT  PK_VENTES PRIMARY KEY(NUMEROVENTE); -- index
CREATE INDEX IDX_TICKET ON VENTES (NUMEROTICKET);                                    -- index 
 
SET TERM ^ ;
CREATE TRIGGER TICKET_BI FOR VENTES ACTIVE
BEFORE INSERT POSITION 0
AS
DECLARE VARIABLE tmp DECIMAL(18,0);
BEGIN
  IF (NEW.NUMEROVENTE IS NULL) THEN
   BEGIN 
     SELECT COALESCE(NUMEROTICKET,0) +1  FROM VENTES WHERE NUMEROVENTE=GEN_ID(GEN_VENTE_ID, 0) INTO NEW.NUMEROTICKET;
     NEW.NUMEROVENTE = GEN_ID(GEN_VENTE_ID, 1);
   END
END^
SET TERM ; ^

Vous allez dire que je pinaille, mais cette méthode ne me semble pas exempte non plus du risque de collision. Si 2 utilisateurs insèrent quasi-simultanément un enregistrement dans la table VENTES, peut-il être garanti que le premier aura exécuté la ligne 19 (celle qui incrémente le générateur) avant que le second exécute aussi la ligne 18? On aurait alors 2 fois le même NUMEROTICKET.
De plus, il faudrait que les transactions permettent de voir au plus vite les modifications exécutées, sinon la ligne 18 pourrait retourner NUMEROTICKET=null si la ligne avec le dernier NUMEROVENTE=GEN_ID(GEN_VENTE_ID, 0) n'est pas encore visible.

André

[Artemus24]

Salut à tous.

Ta solution comporte les mêmes risque de collision.

Si deux caisses demandent un numéro de Ticket simultanément elles risquent d'avoir le même numéro.

Je suis d'accord avec toi, mais c'est un autre problème. Et c'est pourquoi, on a inventé le transactionnel !
Et rien ne t'empêche aussi de verrouiller ta table lorsque tu veux faire une opération dessus, pour être le seul à intervenir.
Et je n'ai jamais dit que c'était ce qu'il fallait faire. J'expose juste une idée qui me semble logique.

Mais voilà, est-ce que chekkal sait utiliser le mode transactionnel avec FireBird ?

La question de chekkal est comment accéder le plus rapidement à la dernière valeur d'un incrément.
Sa solution est de passer par un 'select max(ticket) from vente'.

Sous MySql, on utilise un 'auto_increment' pour constituer la 'primary key' (la colonne 'id') lorsque l'on veut attribuer un numéro séquentiel croissant. Exemple sous MySql :

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
22
23
24
25
select * from test3
--------------
 
+----+-----+-------+
| id | num | val   |
+----+-----+-------+
|  1 |  15 | bleu  |
|  2 |  21 | rouge |
|  3 |   3 | vert  |
|  4 |  17 | bleu  |
|  5 |  75 | bleu  |
|  6 |   9 | bleu  |
|  7 |  12 | rouge |
+----+-----+-------+
--------------
SELECT AUTO_INCREMENT as last_id
FROM INFORMATION_SCHEMA.TABLES
WHERE table_name = 'test3'
--------------
 
+---------+
| last_id |
+---------+
|       8 |
+---------+

La récupération de la dernière valeur de cet auto incrément est instantanée. Est-ce que cela existe sous FireBird ?

@+

[Barbibulle]

La récupération de la dernière valeur de cet auto incrément est instantanée. Est-ce que cela existe sous FireBird ?

Oui c'est ce que je proposais : Les générateurs.

Les générateurs sont hors transaction.

[Artemus24]

Salut à tous.

ce trigger par exemple utilisera la séquence pour avoir un numéro unique et récupérera le dernier numéro de ticket+1 à la manière d'Artemus24

Ce trigger, c'est pour automatiser la recherche du dernier numéro de ticket et de faire un 'ticket <-- ticket +1'.
Mais pourquoi insérer une nouvelle ligne à chaque fois ?

Ça, c'est ce que je faisais il y a 15-20 ans avec des tables Paradox.

Je te rassure, moi aussi mais sous gros système ibm. Je trouve cela un lourdingue, mais bon, l'idée est bonne, mais pas la façon de l'appliquer.

Mais il ne faut pas oublier dans ce cas de "poser un verrou" sur la table parametres juste pour le temps de l'opération, sans cela il y a risque de collision avec un autre utilisateur.

Oui, mais ça, c'est un autre problème.

Ah! les comptables qui font tous les jours des sommes à la main pour vérifier que l'informatique ne s'est pas trompée...

Excellente ! Mais tu n'es pas très loin de la vérité.

et qui nous font tout un plat en cas d'écart de 1 cent !

Mais si le trou est de 1 million, c'est tout à fait normal.

@ Barbibulle : Merci pour l'info. Et comme tu le sais, je ne suis pas encore opérationnel avec FireBird. As-tu un exemple à donner ?

@+