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 <bdebr...@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
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4d1521be.3080...@teaser.fr