Bonjour,

Mon problème est simple (?) : je souhaite que l'ID d'une table s'incrémente de 7 au lieu de 1, pour obtenir une suite comme 7,14,21,28,35,42....

Je pensais obtenir ce résultat avec ALTER TABLE 'matable' AUTO_INCREMENT=7 mais là évidemment j'obtiens le point de départ de l'incrémentation soit 7 et ensuite la liste redevient 8,9,10,11,12...

D'abord, est-ce que celà est possible et si oui (j'espère) pouvez-vous m'indiquer la solution SVP ?

Eventuellement existerait-il une autre méthode que l'auto-incrément pour obtenir une liste aléatoire ?

Merci d'avance pour votre aide précieuse.

ND

Bonjour

Ce n'est pas vraiment possible ou alors ca touche toutes les tables.

SET auto_increment_increment=7;

Quel est le but de ta demande ? Une cle est une cle, globalement ton seul soucis c'est qu'elle soit unique et identifie ta ligne, peu importe sa valeur, qu'il y ait des trous etc

Donc explique-nous pourquoi tu voudrais faire ca, il y a surement une maniere plus simple et elegante de faire ca.

Bonjour,

Merci de vos réponses.

La table concernée est la table "orders" de prestashop.
Contrairement aux factures dont les N° doivent se suivre légalement, les commandes peuvent avoir un N° aléatoire.
Mon but est que les N° de commandes ne se suivent pas, quelle que soit la méthode.

Comme c'est le N° ID qui est repris comme N° de commande, c'est bien entendu celui-là que je voulais modifier.
Maintenant, si celà doit interférer sur toutes les tables, c'est autre chose.

Si vous avez une méthode pour arriver à ce résultat, je suis preneur. Une clé à la fin du N°, un suffixe ou autre...

J'attends vos suggestions avec impatience.

Merci d'avance

ND

Crée une colonne à part avec éventuellement un trigger pour définir le numéro dans un BEFORE INSERT et ne touche pas à l'incrémentation de ta clé primaire. Considère les clé primaires comme des données système et laisse le système les gérer. Par ailleurs, il n'est pas du tout recommandé d'utiliser les clés primaires comme des données « signifiantes » dans une application.

Pense aussi à long terme. Aujourd'hui, ta règle de gestion est une incrémentation par pas de 7 : suppose que l'an prochain la règle évolue ou change complètement : imagine à partir de là les conséquences que ça peut avoir au niveau de ton code et de la cohérence des données, surtout pour ne pas perdre les informations sur l'historique des données avant le changement : une superbe galère en perspective.

Mon but est que les N° de commandes ne se suivent pas, quelle que soit la méthode

Quelle idée bizarre... encore un truc d'utilisateur.
La solution est de demander aux utilisateurs de définir la règle et de programmer cette règle. Je te conseille de conserver un numéro auto incrément pour la gestion technique et un numéro "à la con" pour les utilisateurs.

Merci de vos retours.

Le problème est que Prestashop utilise cette clé comme N° de commande. A moins de réinventer le programme....

Je ne vois pas non plus trop l'intérêt de la chose, apparemment une question de "sécurité".

Si quelqu'un avait déjà eu à résoudre ce problème ou équivalent, et pouvait m'indiquer les solutions "simples" possibles.

Je pense que çà ne vaut pas la peine d'engendrer une programmation compliquée.

Merci à tous

Le problème est que Prestashop utilise cette clé comme N° de commande.

C'est possible, ça reste tout de même une mauvaise pratique.

Il me semble qu'il existe un forum Prestashop, tu devrais peut-être poser ta question là-bas parce que la demande n'est pas ordinaire, pas vraiment hors norme après tout une entreprise peut vouloir avoir son propre système de numérotation de commandes, mais ce n'est pas courant, et qu'ils seront probablement mieux placés que PHPFrance pour te donner une piste de solution.

Au départ je pensais qu'une requête SQL allait régler mon problème, c'est pourquoi je me suis adressé aux pros...

Il est vrai que le système de numérotation est simplissime.

J'ai posté évidemment sur le forum Prestashop, jusqu'ici sans résultat.

Je vais laisser ouvert un peu on ne sait jamais.

Merci

SELECT *, (id * 7) AS id FROM ...

Hophop.

Je ne vois pas non plus trop l'intérêt de la chose, apparemment une question de "sécurité".

Lol. C'est du genre "plutôt que de faire sécuriser, on va se débrouiller pour que les gens de devinent pas facilement les numéros".
Moui, et celui que essaye une 10aine de numéros, il a le droit au jackpot ?

C'est plutôt "commodité" que "sécurité".

Mais plus je suis dessus plus je trouve çà intéressant.

Quand on a de multiples petites commandes chaque jour et que beaucoup peuvent avoir le même montant, on réduit les risques d'erreurs en cas de réclamation ou autres. Les références données ne sont pas toujours fiables, il est donc plus facile de déceler l'erreur.

Vous l'avez compris je ne suis pas codeur, c'est pourquoi, si vous pouviez m'indiquer la requête complète, ce serait parfait.

Merci

Ben, moi je ne connais pas l'appli, pas les requêtes, pas la structure, donc je donne une piste intéressante qui "simule" un auto increment de 7 en multipliant les ids naturels par 7