Bonjour,
J'aimerais savoir comment réorganiser mes données de ma Bd si je supprimes une donnée.
Exemple: je supprimes ma donnée ayant le Id 2, j'aimerais que mes données suivantes change de id (la Id 3 devienne la #2, la id 3, la #4, etc).
Merci
Version imprimable
Bonjour,
J'aimerais savoir comment réorganiser mes données de ma Bd si je supprimes une donnée.
Exemple: je supprimes ma donnée ayant le Id 2, j'aimerais que mes données suivantes change de id (la Id 3 devienne la #2, la id 3, la #4, etc).
Merci
un identifiant doit rester unique et attaché à un seul objet.
donc si vous avez besoin d'une autre information, vous devez la stocker dans un champ que vous rajoutez dans la table.
Présentement j'affiche un div et je lui donne une position en fonction que ce soit un Id pair ou impair. Si je supprimes une donnée, dans mon affichage il y aura un vide. C'est pour éviter le vide que je veux réorganiser les id.
si c'est de la présentation, ce n'est pas une donnée donc ça n'a pas sa place dans la table.
vous pouvez faire des effets alternées 1 sur 2 en css, regardez là :
https://developer.mozilla.org/fr/doc...CSS/:nth-child
Bonjour
1er point : la sémantiqueCitation:
Envoyé par eiffel-mtl
Dans une base de données, la réorganisation est une opération consistant à défragmenter les espaces physiques de stockage des données et des index.
Pour les pages de données, il s'agit de les ranger selon la séquence de rangement définie par l'index cluster
Pour les pages d'index, il s'agit de les ranger selon l'ordre des colonnes de l'index
Aucune des deux opérations ne modifie les valeurs de quelque colonne que ce soit dans les tables !
2e point : le rôle d'un identifiant
Cette expression de besoin est archi récurrente, elle est symptomatique de la méconnaissance du rôle d'un identifiant.Citation:
Envoyé par eiffel-mtl
Un identifiant au niveau conceptuel, qui devient clef primaire au niveau SQL n'a pour fonction que de permettre d'identifier de façon certaine une ligne particulière dans une table.
Les caractéristiques d'une clef primaire sont d'être unique, stable, non "nullable" et irréductible.
- Unique : comme son nom l'indique, chaque valeur ne peut exister qu'une seule fois
- Stable : la valeur d'une PK (clef primaire) se propage dans les tables associées au travers des contraintes d'intégrité
- Non "nullable" : la valeur est obligatoire, aucune PK ne peut être marquée "null"
- Irréductible : une sous-partie de la PK ne peut suffire à garantir l'unicité.
Dans votre demande, c'est le 2e point, la stabilité, qui pose problème : si l'on s'amusait à modifier les valeurs d'identifiants pour satisfaire une envie de valeur consécutives et sans trou (ce qui ne sert strictement à rien), on mettrait à jour toutes les valeurs de clefs étrangères (FK) associées.
Ce qui, avec le phénomène de cascade, peut engendrer des millions, voire des milliards de mises à jour inutiles et mettre à plat la base de données.
Tout ça pour quoi ?
Par ailleurs, je rappelle que la valeur d'un ID ne préjuge en rien de son ordre d'arrivée dans la table, il est tout à fait possible que l'identifiant de valeur 100 ait été inséré dans la base de données après celui de valeur 150. Eh oui, c'est possible, et ce pour plusieurs raisons.
Bref, ce type de préoccupations est un mauvais débat, il ne faut jamais tenter de boucher les trous ou de reséquencer les identifiants.
Si vous voulez attribuer un numéro unique et sans trou pour un besoin particulier, utilisez la fonction ROW_NUMBER(), elle est faite pour ça !
EDIT : J'ai profité de ce topic pour créer un billet dans mon blog, vous y trouverez des explications plus détaillées sur les identifiants
C'est ICI