Discussion :

[Nonoleplongeur]

Je reviens sur le sujet car il me semble avoir mal compris certains points au risque même de paraître ridicule, tant pis !

Sur certains fichiers, je gère mes identifiants manuellement et de façon exceptionnelle quand cela s’impose, sur d'autre de façon automatique, méthode qui a ma préférence par excès de prudence...

Parmi les outils de maintenance proposés dans le centre de contrôle hyperfileSQL, vérifier les index, ré-indexer, réviser les index, je pensais qu'il était possible de recalculer en quelque sorte la valeur de mes identifiants et que cet outil magique se chargerait de remettre à jour la valeur de mes clés attribuées et associées pour les autres tables liées.

Car à force de suppression sur de gros ensemble d'enregistrement, mon premier identifiant peut avoir pour valeur 20000. Dans ce cas, la gestion manuelle me semble s'imposer. Mais alors que faire de ces vides béants entre deux enregistrements générés par des suppressions successives ?

Donc, je pense avoir zappé une notion qui m'échappe notamment sur les index. Donc, j'aimerais bien comprendre et savoir comment vous parvenez à gérer ce problème de maintenance…

Si vous connaissez de bon bouquins sur la maintenance d'une BDD, n'hésitez pas à m'en parler !

Merci d’avance pour vos lanternes !

[Bowen]

Si tu parles bien des identifiants automatiques des fichiers HF, il n'y a pas vraiment de crainte à avoir.
Par défaut, l'identifiant est un numérique sur 4 octets (8 si besoin).
4 octets, ça te fait 2^64 ID possibles
(soit 18 446 744 073 709 551 616, ou 2 milliards de milliards)

Pour la ré-indexation, ça ne fait pas tout à fait ce que tu pensais.
La liste de tes identifiants est entièrement ré-écrite dans un "index".
Sur Hyperfile, c'est très facile à voir, ce sont les fichiers .NDX.
La ré-indexation ne touche pas aux identifiants automatiques, elle ne fait que ré-organiser les fichiers .NDX.
Il n'existe pas de programme faisant un traitement comme tu attendais, (remettre tous les numéros à suivre) et ça n'aurait d'intérêt que si arrivais au bout des identifiants automatiques (ce qui ne doit jamais arriver, avec 2^128 possibilités si l'identifiant est sur 8 octets).

Bref, laisse la gestion automatique des identifiants en place, ça ne sert à rien de vouloir remplacer ce système.
(et c'est assez compliqué à faire correctement)

[klbsjpolp]

La réflexion de Bowen est bonne mais pas ses chiffres.

4 octets = 4 X 8 = 32 bits => 2^32 possibilités = 4 294 967 296
8 octets = 8 X 8 = 63 bits => 2^64 possibilités = 18 446 744 073 709 551 616

Pour avoir un nombres sur 128 bits, il faudrait un identifiants sur 16 octets.

[Bowen]

Effectivement, je crois que je me suis un peu emballé avec ma calculette...
Mais ça reste quand même très au delà des proportions atteintes par la plupart des applications (même sur 4 octets).

[Nonoleplongeur]

Merci beaucoup pour vos réponses ! J'avais compris qu'il se passait quelque chose en arrière plan notamment avec les index et les fichiers .NDX. Mais effectivement je n'ai jamais regardé ce qu'il s'y trouve.

Donc il va falloir que je me fasse à l'idée de conserver mes trous béants et augmenter la taille de mes identifiants lorsque je les gère moi même...

Alors peut être que les index qui se trouvent dans les fichiers .NDX sont recalculés lors d'une ré indexation, enfin j'imagine.

Quant à programmer moi même le re calcule de mes identifiants, je trouve aussi cette solution compliquée et qui pose le problème de la maintenance lors d'une modification de la base avec de nouvelles liaisons ou de nouvelles clés...

J'en profite pour vous demander, en gestion automatique, si les fichiers NDX se réinitialisent seuls si je les supprime pour remettre à zéro certaines tables de ma base ?

Merci encore

[Bowen]

Les fichiers NDX ne se recrééent pas seuls, il faut les recréer par le code. (je ne sais plus l'instruction, ça doit être HRéindexequelquechose)

Mais ne crois pas que supprimer les .NDX, ou faire une ré-indexation fera repartir tes comptages d'identifiants. Il fera seulement une ré-organisation interne du fichier .ndx.

ça ne sert à rien d'autre que d'avoir des temps d'accès plus rapides.
(pour comprendre, ça correspond un peu à une défragmentation de disque, on replace les données cote à cote et dans le bon ordre pour accélérer les lectures)

[Nonoleplongeur]

ok merci pour les précisions ! Je note !