Discussion :

[first racing]

Bonjour,

Ma requete est de la forme :

Code :

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

1
2
3
4
5
6
7
8
SELECT name, path, `date` 
FROM photos as pp 
where not exists (
  select `Nom du fichier` 
  from `photo info` 
  where `photo info`.`Nom du fichier` = pp.name 
    and `photo info`.`Date Archivage` = pp.`date` 
    and `photo info`.`Path Recadre` = pp.path)

Pour 5000 photos identique à une dizaine près, il faut prés un quart d heure ...
Cela devient long d'avancer pour les incohérences ;
- fichier déplacer
- supprimer
- modifier ...

Je me demandais si y avait pas un moyen d'aller plus vite.

Faut il recoder en php la boucle de recherche des nouveaux fichiers non repertorier ?

J ai vu une redaction de la forme
AND champ NOT IN (SELECT champ FROM table )
Mais y a pas de réponse sur cette astuce ...
Et mon serveur a planter ... Bref ...

Merci du coups de main

[SQLpro]

1) NOT EXISTS sera plus rapide que NOT IN
2) MySQL est connu pour avoir un optimiseur assez mauvis et en particulier pour le cas de sous requêtes ou les vues.
A part rajouter massivement de la RAM, et du disque (inutile de rajouter de la CPU, MySQL ne sait pas paralléliser !!!), je vous conseillerais donc de passer plutôt sur du PostGreSQL, bien plus optimisé pour ce genre de chose, et qui plus est gratuit !

A +

[first racing]

Mais faire une procedure de comparaison suivant la structure avec des order by dans les tables jumelles ...
Ca n'a pas l'air compliqué...
Mais du coups c est peut etre une amelioration dans la clause not exists ???
Y a pas de commentaires dans ma litterature ...

[CinePhil]

Tes tables sont-elles indexées ?

Tu peux remplacer NOT EXISTS par une jointure externe et tester le NULL mais en principe NOT EXISTS est plus rapide.

[first racing]

Tes tables sont-elles indexées ?

Tu peux remplacer NOT EXISTS par une jointure externe et tester le NULL mais en principe NOT EXISTS est plus rapide.

Non, c 'est juste une bdd de fichiers photos, copie d une structure de répertoires oganisés en thèmes ( Famille Vacance ou autres... ).

Ajouter 250 photos apres un WE par exemple, c est long y a des erreur de classement du coups: la tante Pierrrette ou Blanchette...

En gros pas d'index compatible...

Le nom, la date de creation du fichier et le chemin sont les seules clauses unicités selon moi ...

Pour le moment, je voulais créer la table image des repertoires et puis me comtenter d une comparaison sur les speudo clefs
mais je crois qu il faut prevoir une reduction des données soit par repertoires soit directement fichier par fichier ...

J aurais bien voulu voir une courbe en fonction du nombre d enregistrement...

Merci pour l astuce null d ailleurs je l ai deja lu.