Bon, on va dire que je radote, que j'en fait des caisses et que je n'ai rien à faire de mes journées, mais j'aimerais juste préciser deux choses (que j'ai juste dit brièvement sur le discord hier).
Par rapport aux INSERTS de la méthode utilisant une représentation avec GEOMETRY :
En fait ça associe la case (x,y) au point de coordonée (x,y) sur le plan.
C'est à dire que les cases sont tracées comme ça :
OOOOO
OOOOO
OOOOO
Alors que, tel que je l'ai compris moi, je pense qu'il faudrait plutôt les tracer comme ça, par exemple :
OXOXO
XOXOX
OXOXO
XOXOX
OXOXO
XOXOX
C'est à dire que, pour l'un des quatre systèmes de coordonnées par offset :
- la case (0,0) est bien associée au point (0,0) et la case (0,2) au point (0,2).
- par contre la case (0,1) est associée au point (1,1) et la case (0,3) au point (1,3)
Et là, on peut clairement voir apparaître des hexagones :
X1X2X
6XOX3
X5X4X
OX1XOX2XO
XOXOXOXOX
6XOXOXOX3
XOXOXOXOX
OX5XOX4XO
Formé par les 6 points : (x-2D,y), (x-D,y-D), (x+D,y-D), (x+2D,y), (x+D,y+D), (x-D,y+D)
Avec D la distance choisie.
Et du coup on peut facilement faire le st_contains.
En revanche, si on reste avec des points alignés, la zone à sélectionner pour le st_contains ne ressemble pas à grand chose, je pense :
X2X3X
16054
XXXXX
(Ici pour un hexagon de distance 1 centré sur le point 0, avec six points 1..6 pour l'un des quatre systèmes de coordonnées par offset.)
Voilà pour mon interprétation ; ou alors je n'ai vraiment pas compris le but de la démarche.
Par rapport aux index et aux perfs :
Avec la méthode cubique, la distance est le max (pas au sens aggregat sql mais au sens greatest sql) des distances sur les 3 axes, qui est aussi la somme des distances divisée par 2.
Si il y a un index sur (x,y,z), alors on peut donc l'utiliser en utilisant des ranges (à la place de abs() dans la clause WHERE, qui bloque l'utilisation de l'index) :
SELECT x, y, greatest(abs(x-xp), abs(y-yp), abs(z-zp)) as distance
FROM TableCase
WHERE x between xpa and xpb
AND y between ypa and ypb
AND z between zpa and zpb;
Avec :
D la distance
(xp,yp,zp) le point central
Et :
xpa = xp - D, xpb = xp + D
ypa = yp - D, ypb = yp + D
zpa = zp - D, zpb = zp + D
Et cette utilisation d'index, justement, c'est quelque chose qu'il sera difficile de faire avec une table de type MaCase(cx, cy) qui contiendrait des coordonnées par offset, car les fonctions SQL à indexer seront plus complexes ; d'où l'intérêt d'utiliser des coordonnées cubiques à la place.
Par rapport aux INSERTS de la méthode utilisant une représentation avec GEOMETRY :
Code :
INSERT INTO geo (cx, cy, pt) VALUES (0, 0, POINT(0, 0));
INSERT INTO geo (cx, cy, pt) (SELECT cx, cy + 1, POINT(cx, cy + 1) FROM geo);
INSERT INTO geo (cx, cy, pt) (SELECT cx, cy + 2, POINT(cx, cy + 2) FROM geo);En fait ça associe la case (x,y) au point de coordonée (x,y) sur le plan.
C'est à dire que les cases sont tracées comme ça :
OOOOO
OOOOO
OOOOO
Alors que, tel que je l'ai compris moi, je pense qu'il faudrait plutôt les tracer comme ça, par exemple :
OXOXO
XOXOX
OXOXO
XOXOX
OXOXO
XOXOX
C'est à dire que, pour l'un des quatre systèmes de coordonnées par offset :
- la case (0,0) est bien associée au point (0,0) et la case (0,2) au point (0,2).
- par contre la case (0,1) est associée au point (1,1) et la case (0,3) au point (1,3)
Et là, on peut clairement voir apparaître des hexagones :
X1X2X
6XOX3
X5X4X
OX1XOX2XO
XOXOXOXOX
6XOXOXOX3
XOXOXOXOX
OX5XOX4XO
Formé par les 6 points : (x-2D,y), (x-D,y-D), (x+D,y-D), (x+2D,y), (x+D,y+D), (x-D,y+D)
Avec D la distance choisie.
Et du coup on peut facilement faire le st_contains.
En revanche, si on reste avec des points alignés, la zone à sélectionner pour le st_contains ne ressemble pas à grand chose, je pense :
X2X3X
16054
XXXXX
(Ici pour un hexagon de distance 1 centré sur le point 0, avec six points 1..6 pour l'un des quatre systèmes de coordonnées par offset.)
Voilà pour mon interprétation ; ou alors je n'ai vraiment pas compris le but de la démarche.
Par rapport aux index et aux perfs :
Avec la méthode cubique, la distance est le max (pas au sens aggregat sql mais au sens greatest sql) des distances sur les 3 axes, qui est aussi la somme des distances divisée par 2.
Si il y a un index sur (x,y,z), alors on peut donc l'utiliser en utilisant des ranges (à la place de abs() dans la clause WHERE, qui bloque l'utilisation de l'index) :
SELECT x, y, greatest(abs(x-xp), abs(y-yp), abs(z-zp)) as distance
FROM TableCase
WHERE x between xpa and xpb
AND y between ypa and ypb
AND z between zpa and zpb;
Avec :
D la distance
(xp,yp,zp) le point central
Et :
xpa = xp - D, xpb = xp + D
ypa = yp - D, ypb = yp + D
zpa = zp - D, zpb = zp + D
Et cette utilisation d'index, justement, c'est quelque chose qu'il sera difficile de faire avec une table de type MaCase(cx, cy) qui contiendrait des coordonnées par offset, car les fonctions SQL à indexer seront plus complexes ; d'où l'intérêt d'utiliser des coordonnées cubiques à la place.