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.
![[Image: graphique_1.jpg]](http://owl-ge.ch/IMG/jpg/graphique_1.jpg)
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).
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).