[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MySQL et OO.org_base: problèmes avec requêtes pluri-tabulaires

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
Reply to: