Vecteurs / Coordonnées et MySQL

[Xenos]

Salut à tous !

Une question sur laquelle j'hésite me vient: comment stocker un vecteur dans une BDD MySQL?

Par vecteur, j'entends des coordonnées (on pourrait dire stocker un point géométrique) comme (x,y,z).

Après un rapide tour d'horizon (sur le web), j'ai plusieurs pistes:

1 • Stocker une version sérialisée du vecteur ("x, y, z" par exemple), et la parser; je n'aime pas du tout cette solution (impossible de calculer facilement la norme du vecteur par exemple), une DB n'étant pas un simple stockeur de strings

2 • Stocker le vecteur sous la forme d'un POINT si l'extension MySQL Geometry est active; mais les points sont en 2D uniquement.

3 • Stocker chaque coordonnée dans une colonne (INT x, INT y, INT z); cela pollue un peu ma structure (si on a plusieurs vecteurs dans une table, celle-ci gonfle vite en nombre de colonnes), mais cela me semble pas trop mal

4 • Stocker, dans une table dédiée, l'id du vecteur, le numéro de coordonnée et sa valeur (INT id_vector, INT/ENUM id_coord, INT value); là, c'est plutôt élégant (on peut stocker tous les vecteurs dans une seule table, et s'y référer), on n'a pas de limite de dimensions (stocker un vecteur 3D requière d'insérer 3 lignes, stocker un vecteur 32D requiert d'insérer 32 lignes, aucun changement de structure), et on peut facilement faire des calculs.


J'hésite donc entre la 3e (dont j'avais plutôt l'habitude) et la 4e (que je viens de découvrir). Quoiqu'une solution mixte, comme stocker les vecteurs 3D dans une table à part sous la forme INT id, INT x, INT y, INT z, me semble encore meilleure (je vais probablement partir là-dessus).

[edit]5e solution (sur laquelle je partirai pour des vecteurs; pour de la géométrie 2D, je partirai plutôt sur la 2e):
5 • Créer une table par type de vecteur (2D, 3D...) et stocker les coordonnées en colonnes (Vecteur2d (INT id, DOUBLE x, DOUBLE y) ; Vecteur3d (INT id, DOUBLE x, DOUBLE y, DOUBLE z)). C'est souple, cela évite d'avoir des colonnes en trop dans les tables utilisatrices (1 colonne avec l'id du vecteur, plutôt qu'une colonne par coordonnée), mais cela ajoute une jointure.


Vous avez choisi quelle solution vous, pour stocker vos vecteurs 2D/3D/4D... ?

[Thêta Tau Tau]

Les SGBD disposent d'outils pour la SIG donc gèrent efficacement les index 2D. Les fonctions déjà faites permettent de gagner en temps de dev (recherche des points proches, dans une boite, dans un polygone...). C'est ce que j'utilise (avec mongodb mais ça reviens au même en SQL).

Après si tu veux des vecteurs en 3D et que ton SGBD les gèrent pas la 3ème solution me semble la meilleure.

Je vois pas trop d'intérêt à la 4ème, ça reviens au même que la 3ème mais avec une jointure en plus. Si tu as besoin de stocker des vecteurs de différente taille c'est effectivement ce qu'il faut faire, mais en a tu vraiment besoin?

[Sephi-Chan]

Quand j'avais eu besoin de ce genre de choses j'avais utilisé l'extension PostGIS de PostgreSQL mais je suppose que MySQL doit proposer des fonctionnalités similaires.

[Xenos]

Oui, MySQL propose l'extension OpenGIS, mais non, apparemment, pas de 3D chez eux (et comme je risque de virer à de la 4D après... ^^). L'avantage des fonctions géométriques est certain pour des points/formes, pour des vecteurs, c'est plus délicat: un vecteur est-il dans un polygone, c'est une question étrange.

Oui, la 3e solution me semble aussi un peu lourde pour rien (si les dimensions pour un même vecteur diffèrent, il doit y avoir un soucis de conception!).
En revanche, cela m'a aiguillé sur une autre alternative: stocker le vecteur dans une table à part, avec 1 colonne par coordonnée.
L'intérêt est alors de dépolluer la table utilisatrice, et d'éviter de la répétition de code: si je dois créer une colonne par dimension pour chaque vecteur (*_x, *_y, *_z), cela finit par faire beaucoup. Centraliser tous les vecteurs 3d dans une table est alors plus pratique (et les tables utilisatrices n'ont plus qu'une colonne, l'id du vecteur). Cela rajoute une jointure, mais le coût machine me semble négligeable face au gain humain (d'autant que sémantiquement, c'est plus proche de ce qu'on cherche à faire, j'en veux pour preuve qu'un changement de FLOAT vers DOUBLE sera très simple et n'impactera qu'une seule table).

[niahoo]

Comment comptes-tu te servir de ces vecteurs ?

[Ter Rowan]

n'y connaissant rien en fonction sgbd au départ j'aurais dit la 3, avec éventuellement une réflexion pour la 5 en terme d'optimisation si tu as des vecteurs de dimensions différentes

seulement après réflexion la 4 pourrait etre pas mal vu ton cerveau compliqué


en effet, si jamais tu te retrouves avec un vecteur (a voir a quoi ca sert) qui est à n dimension et que.. suite à un événement quelconque (modification de ton jeu, évolution du système associé, lié à un choix utilisateur) tu dois réduire le nombre de dimension ou l'augmenter, tu n'auras rien à faire (pas a supprimer un vecteur de la table "n D" pour en créer un dans la table "n+1 D" par exemple

mais comme dit niahoo faudrait surtout savoir ce que tu en fais de ces vecteurs

[Xenos]

Dans l'état actuel des choses, ce sont des positions, des vitesses et des accélérations d'unités, d'où le fait que stocker, dans la table des unités, (x y z) pour chacune de ces trois infos me semble lourd. J'ai déjà les propriétés des unités, qui occupent une bonne quinzaine de colonnes, si j'en rajoute 9 qui ne représentent en fait que 3 données, cela me semble pesant et peu pratique; d'autant que je n'aurai pas forcément besoin de ces trois vecteurs à chaque fois que je lis les infos d'une unité.

Mon cerveau compliqué (eheh ^^) n'a pas encore de cas à N dimensions où N serait variable (d'un vecteur à l'autre, ou variable dans le temps, aka ajouter/retirer des dimensions à la volée), mais cela pourrait faire des jeux assez terribles !

[niahoo]

Pour des tests j'avais stocké des tuples en base. Ce qui fait que tu peux stocker N values dans une seule colonne. Pas sûr que MySQL permette ce genre de trucs par contre. Mais si chaque unité à les trois vecteurs, tu peux faire un type composite et tout mettre dans une seule colonne, comprenant une position, une vitesse dirigée en 3D et une accélération. J'y connais rien en physique dynamique mais j'ai pas l'impression qu'une accélération nécessite un vecteur non plus.

Pour stocker des positions, je ne comprends pas pourquoi tu as besoin d'un vecteur.

Si tu dois faire beaucoup de code SIG PostgreSQL sera beaucoup plus sympa.

[Xenos]

Il n'existe pas de typage pour des tuples MySQL (pas que je connaisse en tous cas, ni que je n'ai trouvé). S'en rapprocheraient les bricolages comme stocker, dans un INT, x+1000*y+1000²*z en supposant que x y et z soient entre 0 et 999, mais ce n'est pas applicable au vu des bornes de mes vecteurs (chaque coordonnée du vecteur position peut largement dépasser le milliard; voire être en FLOAT) ni au niveau sémantique (c'est un peu de la sérialisation, en INT au lieu d'en String).

Point de vue physique/maths, une position n'est rien de plus qu'un vecteur . Ecrire la position (x y z), c'est comme écrire le vecteur position (x y z). La vitesse est la dérivée de ce vecteur position: la vitesse est donc elle-même un vecteur. De même, l'accélération est la dérivée du vecteur vitesse: c'est donc aussi un vecteur.


Position en bleue, vitesse en rouge, accélération en vert; ici, l'accélération est toujours verticale vers le bas (gravité), dans mon cas, l'accélération peut être quelconque (car l'unité a ses propres moteurs/réacteurs qui peuvent pivoter).



Passer à PostgreSQL, pourquoi pas, mais l'opération risque d'être lourde, sachant que je n'ai pas de calcul de forme géométrique (points dans des polygones par exemple), mais uniquement du calcul vectoriel (qui ne me pose aucun soucis de fond à coder). Je ne suis même pas sûr que les SQL privés d'OVH le permettent (à vérifier).

[niahoo]

Ok pour la comparaison point/vecteur, mais le type SQL Point permet de faire des requêtes sympa dessus, notamment grâce aux index spatiaux ! C'est pour cela que je disais ça. Trouver le type le plus proche de la donnée réelle est toujours intéressant.

Bon c'est sûr avec MySQL c'est pas gagné.

Effectivement pour l'accélération je viens de lire un peu dessus, il s'agit d'un vecteur, ça a l'air même assez coton comme concept