ams51 Posté 17 Février 2005 Partager Posté 17 Février 2005 Bonjour, J'ai une table MySQL sur laquelle je place des données toutes les 5minutes. En 2 jours elle devient énorme et ça me pose des problèmes (vue qu'elle doit tourner 24/24 toute l'année). Je voudrais effacer tous les anciens enregistrements et ne garder que les 50000 derniers.... j'ai peur de faire une boulette et de faire l'inverse de ce que je veux... rq : je peux mettre un champ $id qui s'incrémente à chaque enregistrement... mais je pense que ce compteur devienne rapidement trop grand. Est ce qu'il y a une solution miracle ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dan Posté 17 Février 2005 Partager Posté 17 Février 2005 Salut ams51, Quels sont les champs que tu as dans cette table ? As-tu un timestamp? Lien vers le commentaire Partager sur d’autres sites More sharing options...
ams51 Posté 17 Février 2005 Auteur Partager Posté 17 Février 2005 Les champs : $nom, $date, $time ,$data1, $data2, $data3... $date et $time sont la date et l'heure d'enregistrement. il peut y en avoir plusieurs identiques car je peux faire plusieurs enregistrements simultanés. Les autres champs sont du texte ou des chiffres. Comme je l'ai dit je peux mettre un compteur ($id) mais en dernier recours C'est quoi un timestamp ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dan Posté 17 Février 2005 Partager Posté 17 Février 2005 Le timestamp est un format Unix/mySQL qui permet d'identifier l'heure précise de l'insertion. Le format est différent car dans la plus grande précision (14), mySql le représente sous la forme YYYYMMDDHHMMSS. Comme les valeurs sont stockées sous forme d'entier non signé et représentent le nombre de secondes depuis le 1er janvier 1970, à 0H GMT (the epoch) elles ne pourront pas contenir de dates passé l'année 2037 Mais si tu enregistres plusieurs valeurs simultanément, le timestamp risque de ne pas être unique. J'avais compris que tu créais un enregistrement toutes les 5 minutes. Dan Lien vers le commentaire Partager sur d’autres sites More sharing options...
Anonymus Posté 17 Février 2005 Partager Posté 17 Février 2005 1/ Un conseil, fais une copie de la base, et teste ta requète sur une base en local. 2/ Le problème, c'est que tu n'as pas d'identifiants à tes tables. Tu ne peux comparer un champ avec l'autre, pour avoir l'ordre par exemple. 3/ Les champs 'date' ne sont pas forcément valables pour ce genre de manipulations. De plus, on ne sait pas sous quelles formes ils se présentent (DDMMYYYY, ou YYMMDD, ..) 4/ Mets un champ id si tu veux éviter tout problème. 5/ Ensuite, les requètes ressembleront à ceci : En premier : select id from table order by 1 desc limit 0,5000 Là, tu récupères le dernier id (last_id) Puis : delete from table where id<last_id Voilà. Lien vers le commentaire Partager sur d’autres sites More sharing options...
ams51 Posté 17 Février 2005 Auteur Partager Posté 17 Février 2005 Merci... je vais donc mettre le champ id Lien vers le commentaire Partager sur d’autres sites More sharing options...
Ex-floodeur Posté 18 Février 2005 Partager Posté 18 Février 2005 Comme les valeurs sont stockées sous forme d'entier non signé et représentent le nombre de secondes depuis le 1er janvier 1970, à 0H GMT (the epoch) elles ne pourront pas contenir de dates passé l'année 2037 on fera comment en 2037 alors ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dan Posté 18 Février 2005 Partager Posté 18 Février 2005 D'ici là on sera plus que probablement passée aux systèmes 64 bits de base. Mais en attendant, les sytèmes Unix/Linux n'avaient pas à craindre le bug de l'an 2000 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant