Discussion :

[nponzo]

Bonsoir,

je ne suis pas sure de suivre tout en fait. désolé mais j'apprends beaucoup en ce moment et je veux être sure de ne pas me mélanger les pinceaux.

si je comprends bien,il est important d'avoir une clé auto incrémentée qui soit clé primaire et ne pas utiliser les clés multichamps s'il arrive que les enregistrement des clés soient modifiées ?

mais dans mon cas, lors de l'absorption d'une commune par une autre,
l'enregistrement de la commune absorbée disparait tout simplement de la table commune. cela pose-t-il un problème ?

76655 absorbe 76375 :

COMMUNE

Code :

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

1
2
3
num_insee,                num_insee
76655         ==>        76655 
76375

au fait, désolé pour l'insertion de tables dans les balises codes, mais je ne suis pas très doué pour la mise en forme, je ne sais pas insérer des tableau. un jour je serais intelligent !!!

76375 est supprimé, il n'y a pas de mise à jour.

dans la table section, il y a de nouveau enregistrement avec le même code insee mais l'ensemble des champs nouvellement créés ne seront pas modifiés (je crois).

SECTION

Code :

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

1
2
3
4
Num_insee , num_section              Num_insee , num_section   
76655     ,   0000A            ==>   76655     , 0000A
76375     ,   0000A                  76655     , 3750A

la clé primaire (multichamps) ne fait pas l'objet d'une modification (ni num_insee ni num_section) c'est la création d'un nouvel enregistrement et la suppression d'un autre(?). car la géométrie à changée (?).
cela pose-t-il problème ?

dans la table parcelle :

PARCELLE

Code :

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

1
2
3
4
5
Num_insee , num_section , num_parcelle , num_parcelle_mere
76655     , 0000A       , 0027         , 0027                     
76655     , 0000A       , 0027F1       , 0027                   
76655     , 0000A       , 0027F2       , 0027

mais pour les parcelles, si je décide de mettre à jour le champs num_parcelle de la manière suivante :

Code :

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

1
2
3
Num_insee , num_section , num_parcelle , num_parcelle_mere
76655     , 0000A       , 0998         , 0027                   
76655     , 0000A       , 0999         , 0027

là ça pose un problème car ma clé à été modifiée et ne respecte pas le caractère invariant d'une clé primaire. c'est bien ça ?

et si au lieu de mettre à jour, je crée de nouveaux enregistrements ?
ça me donnera ça, n'est-ce pas ?

Code :

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

1
2
3
4
5
6
Num_insee , num_section , num_parcelle , num_parcelle_mere
76655     , 0000A       , 0027         , 0027                     
76655     , 0000A       , 0027F1       , 0027                   
76655     , 0000A       , 0027F2       , 0027
76655     , 0000A       , 0998         , 0027                   
76655     , 0000A       , 0999         , 0027

Je suppose que dans le cas d'une petite base, ça n'est pas gênant car les clés ne sont pas modifiés et ça respecte leur caractère invariant. mais s'il y a des millions d'enregistrements, on duplique la géometrie des parcelles et là ça devient énorme ?

en conclusion, il vaut mieux que je mette une clé primaire auto incrémentée et une clé alternative multichamps ? car si ma clé primaire se répercute dans plusieurs table c'est pas top ?

voilà pour ce soir, ça sera tout, je vous remercie de répondre à mes questions qui peuvent sembler naïves .

à bientôt j'espère car c'est très enrichissant.


nicolas.

[nponzo]

Bonsoir,

visiblement, ce n'est pas très malin ce que j'ai posté,
veuillez excuser le débutant qui est en moi.

je comprends l'utilité des numéros automatiques pour que le système gère lui même les modifications et pour la répercutions dans les autres tables d'une info qui à changé.

mais pour les tables issues d'associations, ça peut-être compliqué lors de l'insertion des données? non ?