Aller au contenu

PHP/MYSQL MyAdmin


oleum

Messages recommandés

Bonjour,

Je suis un nullos en php.

J'ai une table "imagelist" comprenant 6 champs dont un champ "id".

Ce champ id correspond à un chiffre indexant une photo.

A chaque fois que j'ajoute une photo à mon album, cette photo prends l'id = dernier id+1.

J'ai donc plusieurs photos et donc id allant de 1 a 985 par exemple pour 985 photos dans mon album.

A cause d'une migration/fusion et pour éviter un prôblème de redondance je dois changer les id de chaque image suivant :

id = id + X (X étant un chiffre , par exemple 1000).

Quel serait la requète à inserer dans PHPMyadmin afin d'effectuer cette operation automatiquement pour chaque image et donc id ( mise à jour de tous les champs id de la table ) ?

En vous remerciant par avance pour la pertinence de vos réponses.

Cordialement,

Sté.B

Lien vers le commentaire
Partager sur d’autres sites

je pense tout simplement à

UPDATE ma_table SET mon_id = X + mon_id

(attention X + mon_id ne doit pas dépasser la valeur max (ex : 127 pour un tinyint))

Je te conseil d'utiliser autre chose pour garantir l'unicité de ta table qu'un séquentiel.

Pourquoi pour des photos ne pas établir la clé primaire avec l'ip de l'uploader, le nom di fichier et la date de dépot par exemple (si l'on considère que que quelqu'un ne peut pas déposer plusieurs fichiers portant le même nom à un instant donné)

M'enfin bonne chance :=)

Lien vers le commentaire
Partager sur d’autres sites

Merci pour la rapidité, je pense que cela devrait passer avec ta réponse.

le champ est un int(20) donc cela me laisse le champ libre je pense :transpi:

Que signifie garantir l'integrité de ma table?

En fait , il ne s'agit pas d'un prôblème de sémaphore.

J'ai plusieurs album photos de la même marque sur des pages perso differentes de 100Mo chez free.

Ayant récemment un compte a 1Go , je veut tout centraliser sur le même espace perso. Seulement vu que page perso differentes = meme numero d'id pour les differentes images et impossible de tout mettre sur le même compte de 1Go à moins de changer l'id et de faire une recup des tables pour pouvoir les remonter sur l'espace de 1Go.

Voilà le pourquoi du comment ...

En tous les cas re-merci pour ta réponse rapide et constructive.

cordialement,

Sté.B

Lien vers le commentaire
Partager sur d’autres sites

plus précisément je voulais dire garantir l'unicité de la table = tous les enregistrements ont une clé différentes des autres.

Dans ton architecture c'était OK sauf qu'utiliser un "séquentiel" = suite 1,2,3 etc... comme clé primaire (identifiant), c'est chercher les problèmes en cas de refonte des données (comme c'est ton cas).

exemple :

tu as fait :

Une photo est unique et est identifiée par un numéro

j'aurais fait :

Une photo est unique et est identifiée pour 1 utilisateur donnée (par exemple son IP), à un moment donné et pour un nom de fichier donné. (sous entendu pas possible pour un utilisateur d'uuploader 2 photos portant le meme nom a un instant donné)

Le plus important dans l'histoire :

Pour choisir une clé primaire il faut se dire (a mon avis) :

"Comment puis-je identifier de manière unique mon enregistrment avec les champs que j'ai déjà choisi de mettre dans la table" (i.e. sans les clé autoincrémentables).

Il est clair que cette approche et plus propre conceptuellement parlant mais qu'elle atteint vite ses limites (compliquée à faire et à mettre en oeuvre souvent). C'est pourquoi on utilise la facilité avec des "séquentiel" ou "champs autoincrement" ou séquence etc. ...

Par exemple ici, il est déjà discutable de choisir ta solution ou la mienne.

Les deux se valent, c'est une histoire de conception, comment tu interpretes par rapport ce que tu dois faire et comment tu va le traduire une base de données.

Ces explications (enfin plutôt mon avis) données sur la question, je suis surtout très heureux d'avoir pu aider quelqu'un ! on a tous besoin d'aide :-) :transpi:

Bon travail pour la suite :-) et si tu sais, partage :transpi:

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...