06-03-2014, 03:21 PM
Parce que pour la détection des côtes, je n'ai pas besoin de plus. Je suis déjà à 165Mo en mémoire (ah, la terrible optimisation de la mémoire en PHP :p), si je rajoute d'autres données, (en remplaçant la valeur entière par un tableau correspondant aux données de la ligne SQL) je dépasserai facilement le giga...
Finalement, j'ai opté pour:
Le résultat est rapide (quelques secondes), sans exploser la taille en mémoire pour le PHP.
J'aurai pu insérer les "IdVoisinN" dans une table séparée (type "IdCase1", "IdCase2", symbolisant deux cases voisines) mais étant donné que je n'ai que 4 voisins pour chaque case, une table supplémentaire aurait été plus lourd à gérer.
En pratique, le goulot d'étranglement qui fait exploser la durée du traitement vient de l'indexation (x,y) (ou (y,x) dans mon cas): l'utilisation de deux arbres binaires (BTREE) comme le fait MySQL n'est absolument pas optimisé pour la recherche des voisins d'une case.
Par curiosité, je vais tenter d'utiliser le format spatial de MySQL. Je vous rapporterai les résultats
Finalement, j'ai opté pour:
- Ajouter un identifiant unique "id" à chaque case (au lieu d'utiliser le couple (x,y) comme clef primaire)
- Ajouter 4 colonnes IdVoisin1, IdVoisin2, IdVoisin3, IdVoisin4 à la table des cases
- Insérer, dans ces colonnes IdVoisinN, l'identifiant des voisins de la case (donc, la case Id=1 en (x=1,y=1) se voit associer IdVoisin1=721 correspondant à la case (x=0,y=2))
- Utiliser les jointures dans la requête SQL suivante:
UPDATE `cases` `case0`
LEFT JOIN `cases` `case1` ON (`case1`.`id`=`case0`.`idVoisin1`)
LEFT JOIN `cases` `case2` ON (`case2`.`id`=`case0`.`idVoisin2`)
LEFT JOIN `cases` `case3` ON (`case3`.`id`=`case0`.`idVoisin3`)
LEFT JOIN `cases` `case4` ON (`case4`.`id`=`case0`.`idVoisin4`)
SET `case0`.`mer`=1
WHERE
`case0`.`mer`=0
AND `case0`.`altitude`<=0
AND (
`case1`.`mer`=1
OR `case2`.`mer`=1
OR `case3`.`mer`=1
OR `case4`.`mer`=1
)
Le résultat est rapide (quelques secondes), sans exploser la taille en mémoire pour le PHP.
J'aurai pu insérer les "IdVoisinN" dans une table séparée (type "IdCase1", "IdCase2", symbolisant deux cases voisines) mais étant donné que je n'ai que 4 voisins pour chaque case, une table supplémentaire aurait été plus lourd à gérer.
En pratique, le goulot d'étranglement qui fait exploser la durée du traitement vient de l'indexation (x,y) (ou (y,x) dans mon cas): l'utilisation de deux arbres binaires (BTREE) comme le fait MySQL n'est absolument pas optimisé pour la recherche des voisins d'une case.
Par curiosité, je vais tenter d'utiliser le format spatial de MySQL. Je vous rapporterai les résultats