Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian MySQL et OO.org_base: problèmes avec requêtes pluri-tabulaires

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

10 réponses
Avatar
Bernard
Bonsoir à tous,

Je dispose d'une base MySQL comprenant environ 90 champs et 25000
éléments (lignes), connectée à OpenOffice.org_base via JDBC. Cette base
comporte une douzaine de champs "lieux", sous forme de codes INSEE. J'ai
par ailleurs une table de correspondance codes_INSEE => noms_localités.

Faire afficher, par une requête OO_base, le contenu de la table
principale avec les noms des localités d'un des champs "codes_lieux",
n'a pas posé de problème: relation jointure créée entre les deux tables.
La requête s'est exécutée en à peu près une minute.

Le problème, il commence dès qu'il est question de faire afficher les
noms des localités, non plus d'un seul et unique champs "localité", mais
de plusieurs (localité naissance, localité décès...). Avec deux tables,
çà déconne déjà un maximum, comme décrit ci-après:

Ma première tentative fut de mettre deux tables sur le bureau de la
requête, puis de créer deux liens entre les deux tables: l'un des champs
de la table des correspondances des codes lieux était relié à deux des
champs de la table principale. Lancement de la requête => une demi heure
après, çà patinait toujours, alors je n'ai eu d'autre choix que de faire
un #killall -KILL mysqld pour en sortir.

J'ai pensé que les deux liens depuis un même champs d'une des tables,
c'était la cause du problème. Alors j'ai créé une troisième table, copie
de la table de correspondance des codes_lieux, mais avec un nom et des
noms de champs différents. Et à partir de là, j'ai donc fait usage des
trois tables et donc dans chaque table il y avait un seul lien avec deux
champs différents de la table principale. Même résultat, et obligation
de #killall -KILL mysqld pour en sortir après une demi heure ou à peu près.

Alors, pour en avoir le coeur net, j'ai recommencé avec une base
beaucoup plus petite, c'est à dire, la même base d'où j'avais effacé
24000 des 25000 lignes, n'en laissant qu'un millier.

Et là, le processus avec les trois tables et les deux liens, a
fonctionné, après - tout de même - près de dix minutes d'attente.

Non seulement une telle attente est intolérable, et décourage toute
tentative avec une base de taille "normale", mais encore, j'ai constaté
une autre anomalie:

Ne s'affichent que les lignes pour lesquelles LES DEUX CHAMPS codes
lieux sont renseignés ; celles pour lesquelles un seul champs est rempli
ne s'affichent pas ! J'espérais que ma requête - concernant les deux
champs - afficherait toutes les lignes, quitte à laisser vides les
champs 'codes lieux' non remplis.

Il convient de préciser que, dans ma table principale, le premier champs
'localités', celui ayant fait l'objet du premier essai, est rempli pour
chacun des enregistrements (lignes) de la table, alors que les autres
champs 'localités' sont souvent vides, renseignés seulement dans
certains cas.

Il est donc clair que je n'ai pas adopté la bonne méthode.

Merci d'avance pour vos lumières...

--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4D0D2A0C.3060004@teaser.fr
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Basile Starynkevitch
On Sat, 18 Dec 2010 22:39:24 +0100
Bernard wrote:

Bonsoir à tous,

Je dispose d'une base MySQL comprenant environ 90 champs et 25000
éléments (lignes), connectée à OpenOffice.org_base via JDBC. Cett e base
comporte une douzaine de champs "lieux", sous forme de codes INSEE. J'ai
par ailleurs une table de correspondance codes_INSEE => noms_localité s.





Je ne suis pas expert en MySQL, mais je sais que l'indexation y est
determinante. As tu bien créé des indexes? Voir
http://dev.mysql.com/doc/refman/5.1/en/create-index.html

Faire afficher, par une requête OO_base, le contenu de la table
principale avec les noms des localités d'un des champs "codes_lieux",
n'a pas posé de problème: relation jointure créée entre les deux tables.
La requête s'est exécutée en à peu près une minute.

Le problème, il commence dès qu'il est question de faire afficher les
noms des localités, non plus d'un seul et unique champs "localité", m ais
de plusieurs (localité naissance, localité décès...). Avec deux t ables,
çà déconne déjà un maximum,



Ta base est petite, elle tient en mémoire. Dans ma compréhension
[très partielle] des choses, une jointure devrait bien se passer. Et si
ça tient en mémoire et si c'est convenablement indexé, je pourrais
imaginer une réponse assez rapide.... (intuitivement, j'imaginerais en
quelques secondes, car ça serait peut-être du O(n log n) avec n autour
de 25000).


Si tu t'interesses à la généalogie (moi pas), tu pourrais peut-être
regarder GeneWeb http://pauillac.inria.fr/~ddr/GeneWeb (c'est codé par
quelqu'un de compétent dans un langage puissant, Ocaml).

Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Michel OLTRA
Bonjour,


Le samedi 18 décembre 2010, Bernard a écrit...


Je dispose d'une base MySQL comprenant environ 90 champs et 25000
éléments (lignes), connectée à OpenOffice.org_base via JDBC. Cette
base comporte une douzaine de champs "lieux", sous forme de codes
INSEE. J'ai par ailleurs une table de correspondance codes_INSEE =>
noms_localités.

Merci d'avance pour vos lumières...



Je ne sais pas si c'est une lumière, mais tu pourrais peut-être
organiser ta base différemment, si j'ai bien compris :

- une table personne(id_personne#, nom_personne, autres champs...)
- une table evenement(id_evenement#, nom_evenement)
les évènements étants naissance, décès…
- une table des localite(code_insee#, nom_localite)
- une table des relations entre les évènements, personnes et localités
evenement_personne(id_personne#, id_evenement#, code_insee)

Dans cette dernière table tu n'as droit qu'à un seul lieu par couple
(personne/évènement). Je ne sais pas si c'est toujours valide (mais ça
l'est pour une naissance ou un décès !).

Tu rechercherais alors les localités par sous-requête en associant la
personne (son id), l'évènement (par son id), et la localité (par son
code insee). La recherche pourrait se faire sur le nom de la personne (à
indexer si 25000 personnes) et le nom de l'évènement.

--
jm

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bernard
Basile Starynkevitch wrote:
On Sat, 18 Dec 2010 22:39:24 +0100
Bernard wrote:


Bonsoir à tous,

Je dispose d'une base MySQL comprenant environ 90 champs et 25000
éléments (lignes), connectée à OpenOffice.org_base via JDBC. Cette base
comporte une douzaine de champs "lieux", sous forme de codes INSEE. J'ai
par ailleurs une table de correspondance codes_INSEE => noms_localités.






Je ne suis pas expert en MySQL, mais je sais que l'indexation y est
determinante. As tu bien créé des indexes?


Oui, j'ai bien des index pour chacune de mes tables. J'ai bien remarqué
que, sans index, même lorsqu'il s'agit, après l'ouverture d'une table
de, disons, 100,000 lignes, de faire afficher les lignes de la première
à la dernière, çà demande quelques secondes s'il y a un index, et
plusieurs minutes dans le cas contraire.

Voir
http://dev.mysql.com/doc/refman/5.1/en/create-index.html


Faire afficher, par une requête OO_base, le contenu de la table
principale avec les noms des localités d'un des champs "codes_lieux",
n'a pas posé de problème: relation jointure créée entre les deux tables.
La requête s'est exécutée en à peu près une minute.

Le problème, il commence dès qu'il est question de faire afficher les
noms des localités, non plus d'un seul et unique champs "localité", mais
de plusieurs (localité naissance, localité décès...). Avec deux tables,
çà déconne déjà un maximum,




Ta base est petite, elle tient en mémoire. Dans ma compréhension
[très partielle] des choses, une jointure devrait bien se passer.


Elle se passe bien, et rapidement, s'il n'y en n'a qu'une seule... Au
dela, c'est problèmatique !

Et si
ça tient en mémoire et si c'est convenablement indexé, je pourrais
imaginer une réponse assez rapide.... (intuitivement, j'imaginerais en
quelques secondes, car ça serait peut-être du O(n log n) avec n autour
de 25000).


Si tu t'interesses à la généalogie (moi pas), tu pourrais peut-être
regarder GeneWeb http://pauillac.inria.fr/~ddr/GeneWeb (c'est codé par
quelqu'un de compétent dans un langage puissant, Ocaml).



Si c'est bien Daniel de Rauglaudre qui a codé Geneweb (c'est
l'initiateur de ce logiciel), je le connais un peu.

Cordialement.




--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
François Boisson
Le Sat, 18 Dec 2010 22:39:24 +0100
Bernard 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

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bernard
François Boisson wrote:
Le Sat, 18 Dec 2010 22:39:24 +0100
Bernard 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`

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
bruno
On 20/12/2010 22:58, Bernard wrote:
François Boisson wrote:
Le Sat, 18 Dec 2010 22:39:24 +0100
Bernard 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bernard
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 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
herve
Imaginez supprimer un enregistrement ID 8. La valeur de l'auto-incrément
n'est heureusement pas égale au nombre d'enregistrements.

Le 24/12/2010 23:42, Bernard a écrit :
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 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
bruno
On 25/12/2010 09:37, herve wrote:
Imaginez supprimer un enregistrement ID 8. La valeur de l'auto-incrément
n'est heureusement pas égale au nombre d'enregistrements.

Le 24/12/2010 23:42, Bernard a écrit :
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 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










Bonjour et joyeux Noël,

Comme le dit Hervé, l'effacement d'enregistrement ne change rien au
niveau de l'auto-increment. Les champs auto-increment ne font
qu'augmenter, pour garantir l'unicité. Mais un count() retournera bien
le nombre réel d'éléments dans la table.

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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bernard
herve wrote:
Imaginez supprimer un enregistrement ID 8. La valeur de
l'auto-incrément n'est heureusement pas égale au nombre
d'enregistrements.


Dans mon ignorance, je supposais que si... Merci, ainsi qu'à Bruno,
d'avoir éclairé ma lanterne. Et Joyeuses Fêtes !

Le 24/12/2010 23:42, Bernard a écrit :
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 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/