@Ter Rowan: Stocker les liens dans la BDD ne me semble pas être de l'optimisation, c'est seulement un changement d'approche. Passer d'une table de liens à 4 (ou 6) colonnes supplémentaires dans la table des cases peut être vu comme de l'optimisation, mais ce n'est pas de la bidouille pour autant: la table de liens représente des relations type "*" (0 ou plus), alors que les colonnes représentent plutôt des relations "N", avec N fixé à l'avance (6 dans ton cas, 4 dans le mien), ou "0..N" si on autorise la valeur "NULL" à la colonne.
Tout dépend si on considère le lien entre les cases comme étant une entité à part (en ce cas, table supplémentaire obligée), ou comme faisant partie de l'entité "case" (ajout de nouvelles colonnes possible).
Si les liens peuvent être ajoutés et retirés sans limite, alors il faut passer par une table de liens.
Si les liens sont limités à 0..N, avec N fixé au lancement du jeu (ou N très peu évolutif), alors ajouter N colonnes est négociable, tant que N n'est pas "trop" grand.
@Argorate: En fait, j'aurai pu me passer de ce champ "Id": au lieu d'ajout 4 colonnes IdVoisinN, j'aurai pu ajouter 8 colonnes IdVoisinNx et IdVoisinNy, mais la flemme l'a un peu emportée ^^ Autant considérer que l'objet "case" est identifié par un champ "id" et non plus par ses coordonnées "x,y" (ce qui, en un sens, autorise potentiellement deux cases à se superposer, aka à avoir les mêmes coordonnées x,y).
"estCotiere" est un champ de cache. "IdVoisinN" est un champ de structure.
Avant, cela revenait à stocker la structure de la carte dans le PHP et à considérer que la BDD stocke les cases noires d'un échiquier.
Après, avec IdVoisinN, cela revient à stocker un graphe dans la BDD et ses liens (dommage que MySQL ne stocke pas certaines "tables" comme des graphes).
C'est donc plus simple au sens où idVoisinN n'a pas besoin d'être mis à jour quand les données de la BDD changent, alors que "estCotiere" devra être changé si une autre case est noyée sous la mer par exemple.
Le précalcul n'est maintenant plus nécessaire, car le calcul direct est suffisamment rapide.
Données spatiales
Le test avec les données spatiales n'est pas concluant du tout (d'autant que l'extension spatiale n'est pas disponible sur MySQL en mutualisé chez OVH). J'ai tenté de:
Merci pour votre aide à tous
Je vais surement en avoir d'autres dans ce goût-là à vous soumettre
Tout dépend si on considère le lien entre les cases comme étant une entité à part (en ce cas, table supplémentaire obligée), ou comme faisant partie de l'entité "case" (ajout de nouvelles colonnes possible).
Si les liens peuvent être ajoutés et retirés sans limite, alors il faut passer par une table de liens.
Si les liens sont limités à 0..N, avec N fixé au lancement du jeu (ou N très peu évolutif), alors ajouter N colonnes est négociable, tant que N n'est pas "trop" grand.
@Argorate: En fait, j'aurai pu me passer de ce champ "Id": au lieu d'ajout 4 colonnes IdVoisinN, j'aurai pu ajouter 8 colonnes IdVoisinNx et IdVoisinNy, mais la flemme l'a un peu emportée ^^ Autant considérer que l'objet "case" est identifié par un champ "id" et non plus par ses coordonnées "x,y" (ce qui, en un sens, autorise potentiellement deux cases à se superposer, aka à avoir les mêmes coordonnées x,y).
"estCotiere" est un champ de cache. "IdVoisinN" est un champ de structure.
Avant, cela revenait à stocker la structure de la carte dans le PHP et à considérer que la BDD stocke les cases noires d'un échiquier.
Après, avec IdVoisinN, cela revient à stocker un graphe dans la BDD et ses liens (dommage que MySQL ne stocke pas certaines "tables" comme des graphes).
C'est donc plus simple au sens où idVoisinN n'a pas besoin d'être mis à jour quand les données de la BDD changent, alors que "estCotiere" devra être changé si une autre case est noyée sous la mer par exemple.
Le précalcul n'est maintenant plus nécessaire, car le calcul direct est suffisamment rapide.
Données spatiales
Le test avec les données spatiales n'est pas concluant du tout (d'autant que l'extension spatiale n'est pas disponible sur MySQL en mutualisé chez OVH). J'ai tenté de:
- Créer une colonne "geometrieCase" de type "POLYGON" (géométrique)
- Remplir cette colonne avec la forme de chaque case
- Poser un index spatial sur la colonne
- Récupérer les cases côtières via TOUCHES() dans la clause WHERE
Merci pour votre aide à tous
Je vais surement en avoir d'autres dans ce goût-là à vous soumettre