[MySQL] Comment effacer simplement la dernière entrée ?

[SuperPJ]

Salut à tous,

Existe-t-il un moyen en une seule requête d'effacer la dernière entrée d'une table ?

Pour l'instant je fais via PHP :

SELECT MAX(id) as maxid FROM table;
DELETE FROM table WHERE id='$maxid';

... mais ca nécessite 2 requêtes SQL donc ce n'est pas très optimal.


J'ai donc essayé plein de trucs mais rien ne marche :

=> DELETE FROM table WHERE id=MAX(id);
=> DELETE FROM table WHERE id=LAST(id);
=> DELETE FROM table ORDER BY id DESC LIMIT 1;

error ... error ... error :evil:
à noter que la version MySQL de mon hébergeur ne reconnait pas non plus les SubQueries.

Que faire :cry: ?

 

[spidetra]

DELETE  FROM table
         ORDER BY `id` desc
         LIMIT 1

normalement ça marche
http://dev.mysql.com/doc/refman/4.1/en/delete.html

 

[SuperPJ]

Oui ça le devrait mais apparemment mon hébergeur utilise une version trop vieille de MySQL
Nous sommes sous la version 3.23.58

 

[spidetra]

Nous sommes sous la version 3.23.58

Ha oui, quand même, désolé pour toi :!:
Il est pas capable de faire un upgrade de sa version de MySQL, ton hébergeur ?

 

[spidetra]

...

 

[spidetra]

...

 

[SuperPJ]

J'espère bien ! Je viens de lui poser la question sur notre forum interne ...

En effet, je ne vois pas l'intérêt de tourner sous de vieilles versions alors que les plus récentes nous permettent d'optimiser nos requêtes et donc de décharger leurs serveurs ... en ce moment je suis souvent obligé de faire plusieurs requêtes qui n'en nécessiteraient qu'une seule si nous étions à jour cela dit faut voir s'ils n'upgradent pas à cause de problèmes d'incompatibilité qui feraient planter certains vieux scripts PHP faits sous MySQL-3.2 ...

 

[DreamJap]

Il me semble que les versions de MySQL latest sont compatible avec les anciennes du moins avec les scripts PHP.

 

[TOMHTML]

fais gaffe quand même PJ, si tu as mis un ID avec incrémentation à chaque nouvelle entrée
car si tu supprime l'entrée n°10, il ne te reste plus que l'entrée n°9 et les précédentes, mais si tu ajoute une nouvelle entrée elle sera numérotée n°11 et pas n°10, malheureusement

méfie toi donc, petit scarabé

 

[spidetra]

précédentes, mais si tu ajoute une nouvelle entrée elle sera numérotée n°11 et pas n°10, malheureusement

et pas n° 10.... heureusement !

 

[SuperPJ]

si tu ajoute une nouvelle entrée elle sera numérotée n°11 et pas n°10, malheureusement

méfie toi donc, petit scarabé

Moi aussi je pensais comme toi mais renuméroter les IDs à chaque suppression(s) ralentirait à fond MySQL

Et puis l'autre raison c'est que l'ID est souvent utilisé pour identifier de façon unique un client. Imagine tu es le client Adsense n°123456 et que Google vient de supprimer le client n°123455 parce qu'il passait son temps à cliquer sur ses bannières . Si SQL renumérotait les IDs, tu prendrais alors la place du client banni et bye bye tes revenus Adsense

 

[spidetra]

Si SQL renumérotait les IDs, tu prendrais alors la place du client banni et bye bye tes revenus Adsense

Normalement, c'est gérer par les règles d'intégrité référentielle ( on delete cascade, on update cascade ) ou par des triggers.
ce qui commence à être pris en compte dans MySQL 5.0
donc normalement pas de risque pour tes revenus adsense

Les ID auto-incrément se sont là que pour identifier de manière unique un enregistrement, ils n'ont "pas de sens" dans une DB.
donc c'est vraiment pas grave, s'il y a des trous, et c'est bc plus simple à gérer. Si MySQL reprenait le n° 10, il faudrait être sûr d'avoir des devs en béton.


C'est plus grave pour les champs qui auraient un sens :
Ex n° de facture pour une comptabilité

Le fisc aime pas trop voir des trous dans les séries de n° de facture, et donc là la gestion doit être plus fine.

 

[SuperPJ]

Ha oui, quand même, désolé pour toi :!:
Il est pas capable de faire un upgrade de sa version de MySQL, ton hébergeur ?

Je viens d'obtenir cette réponse de mon hébergeur : "il n'est pas prévu de les migrer car la procédure de migration ne garantit pas une compatibilité à 100% et certains sites ne fonctionneraient plus".

Voili voilou

 

[TOMHTML]

et certains sites ne fonctionneraient plus".

moins d'une dizaine à tout casser
franchement si le site fonctionne avec cette version de php, ça fonctionne assurément avec la version supérieure ! Quelques fonctions seraient devenues désuettes mais elle fonctionneraient toujours je pense, non ?

 

[SuperPJ]

A priori je suis de ton avis TOMHTML, surtout pour une application aussi sensible et aussi répandue que MySQL. Mais bon c'est la réponse qui m'a été donnée par l'hébergeur !

En tout cas si tu veux une version récente de MySQL je te conseille pas mon hébergeur ah t'es déjà chez eux ? Je me demande qui est le lascar qui te l'a conseillé jrigole

 

[spidetra]

Je viens d'obtenir cette réponse de mon hébergeur : "il n'est pas prévu de les migrer car la procédure de migration ne garantit pas une compatibilité à 100% et certains sites ne fonctionneraient plus".

on peut lui conseiller une autre option à ton hébergeur.... changer de métier