Discussion :

[moulette85]

Bonjour,

Je développe sous Delphi, mais ma question penche plus pour une question de SQL, j'ai donc posté ici. Si c'est mal posté, merci de faire suivre le post

En fait, j'ai une table RECEPTION reliée a une table PLAT_MANGE via une table association"COMPOSER" (association 1,n de chaque côté).

Sous Delphi, j'ai la possibilité de supprimer une réception via son "REC_CODE". Quand je fais cela, le code va supprimer les tuples de la table association "COMPOSER" dont REC_CODE est celui qui est supprimé, et va ensuite supprimer la réception dans la table "RECEPTION" selon le code suivant :

Code :

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

1
2
delete from composer where rec_code='lareceptionsupprimée';
delete from reception where rec_code='lareceptionsupprimée';

Jusqu'ici, tout va bien
Le truc, c'est que si on a par exemple, 5 réceptions d'enregistrées de 1 à 5 d'après leur REC_CODE, et qu'on supprime la réception 3. Dans la table on va avoir 1,2,4,5 en clé primaire. Mon ajout fonctionne sur un

Code :

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

select count(*) from reception

et lors de l'ajout, compte le nombre de tuples et ajoute la réception "count(*)+1". Donc si on a 4 réception 1,2,4,5 et qu'on en ajoute une, il va vouloir ajouter la réception 5. Voilà pour l'explication.

Je voudrais donc décaler mes tuples après la suppression via un simple

Code :

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

1
2
update composer set rec_code=rec_code-1 where rec_code>'lareceptionsuppr';
update composer set rec_code=rec_code-1 where rec_code>'lareceptionsuppr'

Seulement, ya tjs un prob de violation de clé primaire dans une table ou dans une autre, alors je sais plus quoi faire.... Si qqun a une idée :/ Merci d'avance

[phili_b]

Est-ce une bonne chose de vouloir "récuperer" un identifiant qui n'est plus utilisé surtout si c'est une clé primaire ? C'est une mauvaise idée. Bonjour l'angoisse pour que cet identifiant soit bien propagé et surtout je ne vois pas l'interêt.

En plus en cas de crash de la base et donc de récupération des données, ou en cas de sauvegarde, ou encore d'archivage differentiel comment démeler les anciens identifiants plus utilisés de ceux réutilisés.

Si vraiment c'était nécessaire il vaut mieux laisser cette pk telle qu'elle est et éventuellement rajouter une colonne ayant une contrainte unique. C'est cette colonne que tu renuméroterais (avec ton update) simplement pour son affichage sans toucher aux contraitres d'intégrité. Les pk et les fk resterait telle qu'elles sont. La colonne en question rajoutée n'existerait que dans la "table maitresse" mais n'existerait pas dans les sous table.
Si vraiment tu voulais faire ce que tu demandes il faudrait utiliser des transactions pour être sûr de garder l'intégrité, rajouter des lignes avec ton nouvel identifiant renuméroté, propager ces nouveaux identifiants, et seulement ensuite supprimer les identifiants anciens. Un cauchermard inutile et encore je résume la méthode.

edit:
rajouté dans le post : souligné

[moulette85]

Bah sinon, quand j'ajoute, ça va déconner...

[phili_b]

Bah sinon, quand j'ajoute, ça va déconner...

J'ai réedité sans savoir que tu avais répondu. Relis mon message réédité mais en particulier je dis

Les pk et les fk resterait telle qu'elles sont. La colonne en question rajoutée n'existerait que dans la "table maitresse" mais n'existerait pas dans les sous table.

donc dans ce cas cela ne va pas déconner car la mise à jour ne se ferait que dans la "table maitresse" donc pas de problème de mise à jour des sous-tables ni de problème de fk, ni de mise à jour de pk.

[soazig]

Pour résoudre ton problème au lieu de faire un

select count(*) from reception

Tu peux faire un

Code :

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

select Max(REC_COD) as Dernier_rec_cod  from reception

Comme cela tu auras le numéro de ta dernière clé.

Néanmoins cette façon de faire est dangereuse, surtout en cas de multi-utilisateur, lit donc l'article suivant :
http://sqlpro.developpez.com/cours/clefs/
Le plus souvent les SGBD intègre un système spécifique pour gérer les clés auto-incrémentées. C'est ce système qu'il est préférable d'utiliser.

a+
soazig

[moulette85]

Merci pour vos réponses rapides. Je me suis renseigné, et au final, il vaut mieux utiliser les clés autoincrémentées.

J'ai donc refait toute ma table en mettant des IDENTITY(1,1) sur toutes mes clés primaires, comme ça, je n'ai plus ce genre de problèmes.

Merci bcp !