Discussion :

[Daz77]

Bonjour à vous,

L'intitulé de ma question est claire mais je vais d'abord vous parler du contexte pour que vous ayez le plus d'éléments possible.
Je suis étudiant en informatique et dans mon temps libre je fais partie d'un club de football américain dans la région parisienne.

J'aimerai créer une application qui permettrai de créer les cahiers de jeux de mon équipe. Le cahier de jeux dans le football américain c'est la liste de toutes les formations et de tous les jeux jouer par l'équipe. Petit à petit j'avance sur l'application mais je bloque sur un point, la base de données. Plus précisément je bloque sur les tracés, un tracé c'est une course que doit réaliser un joueur. Voilà un exemple :



Pour les courses rectilignes avec ou sans angle j'avais une idée pour les conserver en base de données (et encore j'ai un doute) mais je bloque sur les courses comportant des arrondis comme les courses partant du joueur F ou H. La forme de la course est très importante dans le football américain je dois donc la conserver de la manière la plus précise qu'il se doit. J'avais opter comme SGBD PostGIS qui est une base de données spatiale. Grâce aux formes géométriques présentes dans cette base de données je me suis dis que cette base de données aurait pu faire l'affaire mais j'ai peur d'utiliser quelque chose de trop poussée pour ce que je veux réaliser.

Si vous avez des conseils soit sur un meilleur SGBD soit sur PostGIS je serai ravis d'en discuter avec vous.

Merci d'avoir pris le temps de me lire.

[CinePhil]

Votre problème tient peut-être davantage à la modélisation des données que sur le choix du SGBR.

D'après votre schéma, une course est un trajet d'un point A à un point B.
Ce trajet peut être découpé en segments droits ou courbes.
Pour le segment droit, c'est simple : le point de départ et le point d'arrivée sont suffisants.
Pour le segment courbe, il faut en plus une sorte de "direction" de la courbe. "Vers la droite" ou "Vers la gauche" est peut-être suffisant ?

Voilà l'idée générale pour les courses. À vous de compléter pour les positions de départ, l'assemblage de tout ça dans ce que vous appelez "jeu" et "cahier"...

On peut vous aider à modéliser dans le forum ALM / Schéma.

Bon courage !

[escartefigue]

J'ai plutôt l'impression qu'il s'agit de stocker
- Soit des fonctions pour les trajectoires (et donc les paramètres de ces fonctions)
- Soit la successions des coordonnées d'une trajectoire, plus simple, mais plus gourmand en données à stocker si les trajectoires sont complexes (plusieurs changements d'angle...)
- Eventuellement des images pour les représentations à un instant "t" des différentes trajectoires à effectuer
- Des scénarios (combinatoires de différentes trajectoires)

On peut supposer que la vitesse de déplacement et les variations de vitesse sont également très importantes : il faut que tel joueur arrive a tel point via telle trajectoire avant que tel autre joueur arrive à tel autre point via telle autre trajectoire... donc notion de temporalité

Du coup ce n'est pas tant la BDD qui risque d'être complexe mais surtout l'application qui va l'exploiter

[Daz77]

Alors pour répondre à CinePhil non l'information concernant la direction n'est pas importante car le trajet peut s'effectuer soit à gauche soit à droite, donc une fois que j'ai le trajet dans la base de données si je veux le faire du coté opposé j'ai juste à faire une symétrie axial. Pour l'assemblage entre les joueurs et les trajets j'ai mon idée en tête.

Pour escartefigue alors :

• 1- La solution de fonction m'a été proposé par un de mes amis mais le problème avec cette solution est que un des modules de l'application permettrait aux utilisateurs de dessiner leur trajet ( une sorte de paint ). Dans ce cas, l'utilisation des fonctions est beaucoup trop compliqué.
• 2- C'est la solution que j'avais en tête et celle la qui concerne le sujet. Dans le cas de trajet simple comme la expliqué CinePhil stocker le point de départ, d'arrivé et celui des angles est possible. Par contre pour les trajets en courbes est ce que je dois stocker tous les pointes du trajet ? Si oui ça implique beaucoup de point à stocker comme vous l'avez dit et c'est pourquoi je me poser la question quelle base de données choisir pour stocker tous ces points et surtout pour les récupérer facilement derrière.
• 3- Les images, je pense ne me permettront pas de réaliser ce que je souhaite.

Pour finir les éléments liés à la vitesse ne m'intéresse pas dans mon cas.

Merci pour vos réponses.

[StringBuilder]

L'intérêt d'une base spatiale, c'est avant tout de pouvoir effectuer des calculs en masse sur les données stockées dans la base.

Ici, j'ai l'impression que vous souhaitez "seulement" stocker les données, mais pas de faire des calculs/traitements dessus.

Ainsi, les types forme apportés par une base spatiale ne me semblent clairement pas apporter grand chose.

J'imagine qu'une modélisation "classique" sous forme de graph, ou même plus simplement, sous forme d'un flux XML ou même CSV pourrait parfaitement faire l'affaire.

Donc le facteur "spatial" ne doit pas entrer en ligne de compte pour le choix du SGBD.
Prenez celui sur lequel vous êtes le plus à l'aise, ou celui sur lequel vous souhaitez apprendre le plus.

En gratuit :
Je vous recommande chaudement Microsoft SQL Server (Express), qui dispose d'un support natif des types spatiaux, mais aussi XML, et surtout est un SGBD très agréable à utiliser.
Oracle XE est aussi bien, mais je connais moins. Plus complexe à mettre en place et à administrer.
PostGreSQL est un très bon outil. Moins évolué que les deux cités précédement.
MySQL : oubliez

[CinePhil]

non l'information concernant la direction n'est pas importante car le trajet peut s'effectuer soit à gauche soit à droite, donc une fois que j'ai le trajet dans la base de données si je veux le faire du coté opposé j'ai juste à faire une symétrie axial.

Ce que je voulais dire, c'est que si je suis le coureur et que je dois entamer une courbe pour relier le point d'arrivée, vais-je partir vers la droite ou vers la gauche pour faire ma courbe. Si je ne vais ni à gauche, ni à droite, mon segment de trajet est alors rectiligne.
Par exemple, sur votre schéma, F ne court pas tout droit vers X mais par une courbe vers la gauche par rapport à la trajectoire rectiligne. H fait également une courbe vers sa gauche pour rejoindre son point d'arrivée.

Dans le cas de trajet simple comme la expliqué CinePhil stocker le point de départ, d'arrivé et celui des angles est possible. Par contre pour les trajets en courbes est ce que je dois stocker tous les pointes du trajet ?

D'après vos explications, l'orientation "vers la droite" du coureur ou "vers la gauche" serait suffisante.
On peut imaginer une entité type Segment munie de la propriété "orientation" qui pourrait prendre les valeurs D (droite), C (centre), G (gauche).

MCD :
point -0,n----débuter----1,1- segment -1,n----composer----1,n- trajet
|--------0,n----finir----------1,1-------|

Tables :
te_point_pnt (pnt_id, pnt_coord_x, pnt_coord_y...)
te_segment_sgt (sgt_id, sgt_id_point_depart, sgt_id_point_arrivee, sgt_orientation...)
te_trajet_trj (trj_id, trj_nom...)
tj_trj_composer_sgt_tcg (tcg_id_trajet, tcg_id_segment, tcg_ordre...)

[SQLpro]

Pourquoi pas le spatial ? Il va permettre de dessiner automatiquement les coubes d'après les info stockéers en base. Depuis la version 2012 de SQL Server ou 2 de PostGis / Postgresql, il y a les circular string et autres compound curve...
Cela permet de faire rapidement toutes les projections, translations....

A +

[Daz77]

L'intérêt d'une base spatiale, c'est avant tout de pouvoir effectuer des calculs en masse sur les données stockées dans la base.

Ici, j'ai l'impression que vous souhaitez "seulement" stocker les données, mais pas de faire des calculs/traitements dessus.

Ainsi, les types forme apportés par une base spatiale ne me semblent clairement pas apporter grand chose.

C'est exactement çà. Je ne fais que du stockage et je me posais la question de l'apport des bases spatiales.

Ce que je voulais dire, c'est que si je suis le coureur et que je dois entamer une courbe pour relier le point d'arrivée, vais-je partir vers la droite ou vers la gauche pour faire ma courbe. Si je ne vais ni à gauche, ni à droite, mon segment de trajet est alors rectiligne.

En effet je n'avais pas pensé à cela. Mon problème était plus un problème de modélisation que de base de données vu comme cela.