Bonsoir Bruno, bonsoir à tous,
Je me suis provisoirement détourné du problème originel, pour aborder
une urgence plus actuelle.
Pour en finir provisoirement avec le précédent souci, je dirai que
j'ai fait plusieurs essais avec des scripts PHP, d'où il est apparu
qu'en utilisant un 'INNER JOINT' pour le premier joint, et des 'LEFT
JOINT' pour les suivants, j'obtenais les resultats recherchés, dans
des temps que je qualifierai de "normaux". Je ne sais pas encore
comment obtenir les mêmes résultats via OO_base, mais je ne tarderai
sans doute pas à trouver.
Par ailleurs, j'ai voulu faire un script PHP pour ajouter des lignes à
l'une de mes tables. Et là, j'ai observé de sérieuses anomalies.
Depuis OO_base, il est possible de créer des tables ; c'était même
jusqu'ici ma façon privilégiée de créer des tables. Mais je me suis
aperçu qu'il était impossible de créer des tables avec des champs
d'index qui soient 'auto increment'. Créer un champs d'index dans une
table via MySQL, oui, mais pas moyen de rendre ce champs 'auto
increment' ! Ceci ne m'avait qu'à moitié surpris, étant donné que
j'avais déjà, via Google et autres recherches, vu passer des
commentaires où il était fait état de cette anomalie. Bon, qu'à cela
ne tienne, j'ai créé une table en language MySQL:
mysql > CREATE TABLE matable (
ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Champs1 TEXT,
Champs2 TEXT,
....................,
ChampsN TEXT);
Query OK...
Puis je l'ai vérifiée et remplie sous OO_base, renommant certains
champs, modifiant les caractéristiques d'autres champs, mais ne
changeant rien à ID (le champs de la clef primaire).
Ceci étant fait, j'ai fait usage de mon script nouvellement créé pour
l'ajout de données dans la dite table.
Et voici le résultat constaté :
Les données s'ajoutent bien... Mais, une fois les données ainsi
ajoutées, si l'on fait le choix de les effacer (sous OO_base) pour
re-tester d'autres données, l'index ID ne tient pas compte des
effacements. Ainsi, j'en suis à 12075 lignes. Après deux ajouts via
mon script PHP, l'index s'est automatiquement incrémenté à 12077.
J'efface les deux nouvelles entrées dans la table (effaçage via
OO_Base), et je fais l'essai d'ajouter autre chose. C'est alors que
l'index repart à partir de 12078, alors qu'il aurait dû reprendre à
12076. Ma table présente alors une numérotation continue de 1 à 12075,
après quoi l'ID passe directement à 12078 !
Merci de m'éclairer sur les conséquences prévisibles d'une telle
anomalie, eventuellement comment la traiter.
bruno wrote:
On 20/12/2010 22:58, Bernard wrote:
François Boisson wrote:
Le Sat, 18 Dec 2010 22:39:24 +0100
Bernard <bdebreil@teaser.fr> a écrit:
[...]
Il est donc clair que je n'ai pas adopté la bonne méthode.
En fait il faudrait qu'une fois la requête édité avec le frontal
d'openoffice,
tu bascules en édition MySQL et que tu donnes la requête elle même, tu
peux
même la copier et la coller directement dans mySQL pour voir si la
difficulté
vient de l'interface (je n'y crois pas) ou de la complexité de ta
requête
(j'ai ramené de 1/4h à 1/10s une requête juste en mettant une
indexation
correcte).
François Boisson
Ci-après, voici le code SQL généré par ma requête et les liens que j'ai
créés via OO.org_base :
SELECT `bapt_juil2010_complet`.`ID`,
`bapt_juil2010_complet`.`Code_lieu_acte`,
`bapt_juil2010_complet`.`Lieu_acte`, `Codes_lieux`.`Code_lieu`,
`Codes_lieux`.`Nom_localite`, `Codes_lieux`.`Paroisse`,
`bapt_juil2010_complet`.`JJ_acte`, `bapt_juil2010_complet`.`MM_acte`,
`bapt_juil2010_complet`.`AAAA_acte`,
`bapt_juil2010_complet`.`Prenom_enfant`,
`bapt_juil2010_complet`.`Nom_enfant`,
`bapt_juil2010_complet`.`Nom_pere`,
`Codes_lieux_orig_pere`.`Code_lieu`,
`Codes_lieux_orig_pere`.`Nom_localite_orig_pere` FROM
`mabase`.`Codes_lieux` AS `Codes_lieux`,
`mabase`.`bapt_juil2010_complet` AS `bapt_juil2010_complet`,
`mabase`.`Codes_lieux_orig_pere` AS `Codes_lieux_orig_pere` WHERE
`Codes_lieux`.`Code_lieu` = `bapt_juil2010_complet`.`Code_lieu_acte`
AND
`Codes_lieux_orig_pere`.`Code_lieu` =
`bapt_juil2010_complet`.`Code_lieu_acte`
Bonjour,
Dans ton cas tu devrais utiliser les jointures, car c'est plus optimisé
(voir http://sqlpro.developpez.com/cours/sqlaz/jointures/#LII-B)
De plus, la table bapt_juil2010_complet devrait être citée en premier
car c'est elle qui sert de 'pivot'
As-tu indexé les champs suivants?
`Codes_lieux`.`Code_lieu`
`Codes_lieux_orig_pere`.`Code_lieu`
`bapt_juil2010_complet`.`Code_lieu_acte`
Ci-dessous ta requête avec des jointures :
SELECT `bapt_juil2010_complet`.`ID`,
`bapt_juil2010_complet`.`Code_lieu_acte`,
`bapt_juil2010_complet`.`Lieu_acte`, `Codes_lieux`.`Code_lieu`,
`Codes_lieux`.`Nom_localite`, `Codes_lieux`.`Paroisse`,
`bapt_juil2010_complet`.`JJ_acte`, `bapt_juil2010_complet`.`MM_acte`,
`bapt_juil2010_complet`.`AAAA_acte`,
`bapt_juil2010_complet`.`Prenom_enfant`,
`bapt_juil2010_complet`.`Nom_enfant`,
`bapt_juil2010_complet`.`Nom_pere`, `Codes_lieux_orig_pere`.`Code_lieu`,
`Codes_lieux_orig_pere`.`Nom_localite_orig_pere` FROM
`mabase`.`bapt_juil2010_complet` AS `bapt_juil2010_complet`
LEFT JOIN
`mabase`.`Codes_lieux` AS `Codes_lieux`
ON
`Codes_lieux`.`Code_lieu` = `bapt_juil2010_complet`.`Code_lieu_acte`
LEFT JOIN `mabase`.`Codes_lieux_orig_pere` AS `Codes_lieux_orig_pere` ON
`Codes_lieux_orig_pere`.`Code_lieu` =
`bapt_juil2010_complet`.`Code_lieu_acte`
En espérant que cela accélère un peu les choses.
Bruno