Discussion :

[Momodedf]

Bonjour,

Un nom de topic étrange pour un besoin qui ne l'est pas moins ^^
(dur dur de trouver des bon mot clef sur google ....)

Alors voilà, j'aimerais (à la création de ma table) créer un champ auto incrémenté (bon jusque là c'est tout con).
Le probleme c'est que je voudrais que chaque nouvel enregistrement prenne l'id 1 et donc que les autres id soient tous incrémenté.

[sebdu]

tu as essayé de faire un update de tous les enregistrements en mettant id = id+1 et ensuite d'insérer l'id 1
pour ça il faudrait pas d'auto incrément

[nounetmasque]

La technique proposée fonctionnera avec un trigger !

Par curiosité, pourquoi utiliser un auto-increment inversé ?

[sebdu]

La technique proposée fonctionnera avec un trigger !

Par curiosité, pourquoi utiliser un auto-increment inversé ?

d'accord avec toi pour l'auto incrément inversé, par contre je ne le ferais pas forcément avec un trigger (un peu de code avant l'insert remplace amplement le trigger que je n'ai jamais utilisé faut que j'apprenne)

[nounetmasque]

un peu de code avant l'insert remplace amplement le trigger

Il me semble qu'un trigger sur un évenement before insert évitera une bidouille puisque le but est de mettre à jour des champs en fonction du paramétrage de ton trigger. Dans cet exemple, avant chaque insertion dans la table, il faudra incrémenter toutes les colonnes.

[Momodedf]

tu as essayé de faire un update de tous les enregistrements en mettant id = id+1 et ensuite d'insérer l'id 1
pour ça il faudrait pas d'auto incrément

Bien sur mais c'est un peut lourd je me demande si ça va pas ramer un peut quand le nombre d'enregistrement sera important (100k enregistrement par exemple).

En fait j'esperais qu'il y ait cette fonctionalité via phpmyadmin

Par curiosité, pourquoi utiliser un auto-increment inversé ?

Wahh la classe, auto-incrément inversé rentre déjà dans le jargon

En fait je créé des statistiques assez souvent (plusieurs fois par jour) et j'aimerais les stoquer.
Mais il me faut recuperer la derniere statistique enregistrée, ça aurait été facile comme ça, le dernier enregistrement aurait toujoours été celui à l'id 1.


PS : chéquoi un trigger ?

[sebdu]

Il me semble qu'un trigger sur un évenement before insert évitera une bidouille puisque le but est de mettre à jour des champs en fonction du paramétrage de ton trigger. Dans cet exemple, avant chaque insertion dans la table, il faudra incrémenter toutes les colonnes.

d'accord avec toi sur le fait que ce soit une bidouille mais les anciennes versions de mysql n'ont pas les triggers et ça m'a sauvé de la misère plus d'une fois
sinon je suis pour le trigger qui sera sans doute plus performant que la bidouille

[sebdu]

PS : chéquoi un trigger ?

c'est ça

[Momodedf]

Hum visiblement les trigger ne sont implémentés qu'à partir de MySQL 5.0.

Vu que le server prod ne posser que la version 3.23 je pense que je vais opter pour la bidouille ...

EDIT : merci pour le lien sebdu

[jeremya]

En fait je créé des statistiques assez souvent (plusieurs fois par jour) et j'aimerais les stoquer.
Mais il me faut recuperer la derniere statistique enregistrée, ça aurait été facile comme ça, le dernier enregistrement aurait toujoours été celui à l'id 1.

Avec un auto-incrément inversé, à chaque fois que des données sont insérés dans la table, tous les enregistrements seront mis à jour (incrémentation de 1).
Tu fais cela pour gagner du temps lors de l'accès aux données (tu ne récupère que le dernier enregistrement).
Cependant, les insertions de données seront plus lentes (UPDATE avant INSERT).

Je suppose que tu insères des données plus souvent que tu n'y accèdes.
Dans ce cas, ne perds-tu pas plus de temps à l'insertion des données que tu n'en gagnes lors de l'accès aux données ?

[Momodedf]

Non j'y accede plus souvent que je ne met à jour.

Je lis environ 20 fois par jour et j'écris 3 à 4 fois par jour.

[nounetmasque]

Si tu veux récupérer le dernier enregistrement de ta base, je ne te conseille pas un auto-increment inversé et ceci pour les mêmes raisons que celles exposées par jeremya.
Par contre une requette de ce style devrait convenir et ceci avec des tables de 100k enregistrements (pense à placer un index sur ton id ).

Code :

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

1
2
3
4
 
SELECT * 
FROM maTable t1, (SELECT max(id) FROM maTable ORDER BY id) t2
WHERE t1.id = t2.id

Je te laisse le soin d'adapter cette requette à ton besoin.

[Momodedf]

Je savais même pas qu'on pouvait mettre une subquery dans la clause from .....
J'avais pas pensé à la fonction MAX c'est vrai ....

Je pense que je vais faire ça :

Code :

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

1
2
3
4
SELECT *
FROM my_table
WHERE id =  (SELECT MAX(id)
                   FROM my_table);

Merci bien

[nounetmasque]

Même si le sujet est considéré comme résolue, je tiens à préciser que l'exécution d'une requette est plus rapide si tu mets ton select dans ton from et non dans ton where.
De plus ce type de sous-requette ne doit pas être gérée avec ta version de MySQL.