Discussion :

[Larry3406]

Bonjour,

Je travaille peut-être dans un contexte peu répandu : LibreOffice Base avec moteur MySQL JDBC sous Win7 FP.

A force de persévérance j'ai réussi à bâtir un SGDBR de 22 tables (dont le principale avec 10.000 enregistrements) liées par 30 jointures.

Après avoir retiré de nombreux enregistrements de ma table principale, la clé primaire présente de nombreux trous.

Question : comment "défragmenter" la clé primaire en respectant la correspondance avec les clés étrangères utilisées par les jointures.
Autrement dit, comment effectuer une "défragmentation en cascade" ?

[qi130]

Question : à quoi va servir de défragmenter ?

Une clé primaire ne sert qu'à assurer l'unicité dans la table, alors qu'il y ait des trous ou pas, quelle importance

D'autant que de suite après la manip, la base va vivre, il y aura des suppressions, et donc à nouveau des trous

[Larry3406]

Simplement parce que, chez moi, la recherche par numéro d'enregistrement est instantanée, alors que la recherche sur un champ (quand il y en a plus de 10.000) prend un temps certain.

Donc quand le champ ID correspond au n° d'enregistrement, on peut atteindre immédiatement (dans un formulaire, par exemple) un enregistrement dont on connaît l'ID.

Nota : je suis, pour l'instant, le seul utilisateur de la base car je suis en train de la mettre au point.

J'avais une piste

Code :

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

ALTER TABLE "Romans" ALTER COLUMN "Ref Roman" RESTART WITH 1

mais ça me renvoie une erreur de syntaxe :

1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"Ref Roman" RESTART WITH 1' at line 1

[Yanika_bzh]

Simplement parce que, chez moi, la recherche par numéro d'enregistrement est instantanée, alors que la recherche sur un champ (quand il y en a plus de 10.000) prend un temps certain.

Donc quand le champ ID correspond au n° d'enregistrement, on peut atteindre immédiatement (dans un formulaire, par exemple) un enregistrement dont on connaît l'ID.

Vous êtes en train de comprendre l'utilité des index !!
Ne touchez pas à votre clé primaire, qui est une clé technique. Elle vous assure l'unicité. Si vos requêtes prennent du temps, visualisez le plan d’exécution, analysez-le et repérez les malfaçons de vos requêtes (ou de votre modèle de données). Vous aurez les éléments pour remédier à votre problème (création d'index, reformulation de vos requêtes, modification de votre modèle de données,...).

Bon courage

[Larry3406]

... visualisez le plan d'execution, analysez le et reperer les malfacons de vos requetes (ou de votre modele de données).
... modification de votre modele de données,...).

Autant de choses qui me paraissent fort utiles et que je saurai, sans doute, faire un jour.
Pour l'instant je suis débutant et je travaille, comme je le précise à l'origine de la discussion, avec l'interface Base de LibreOffice (qui me libère, provisoirement, d'avoir à apprendre, en plus, le PHP).
Pardonnez-moi d’être novice

Par ailleurs je précise que la clé primaire est indexée par défaut, il me semble, non ?

[Yanika_bzh]

Je ne vous blâme pas du tout d’être novice, mais vous demandez des conseils, nous vous en donnons.
Si votre recherche sur vos "champs" est longue, c'est qu'un index devrait y être posé, cela accélèrerait le processus.

Concernant la clé primaire, elle est effectivement indexée par défaut ce qui explique que vos recherche via ce biais soit très rapide.

Bon courage