base de données, objets 3D, stocker des nombres

Le
Pascal
Bonjour,

Je commençais à réfléchir à une solution pour stocker des donné=
es
cristallographique. En simplifiant, c'est des coordonnées 3D qui
forment des lignes et/ou polygones , des distances et des angles.

Je me demande si un sgdb classique serait le mieux. Je me suis rappelé
des extensions GIS, ça ressemble à mon problème sauf que c'est de la
2D. Existe t-il quelque chose de similaire en 3D ?

Autre question, j'ai des valeurs à stocker, elles sont de ce genre:
2.1254+/-0.0001
2.1254+/-0.0011
2.125+/-0.025

Je ne connais pas leur précision à l'avance et elle est différente
suivant les valeurs. Je connais juste leut incertitude. De quelle
manière je pourrai les stocker ?

Pascal
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrick Mevzek
Le #21920711
Le Sun, 25 Oct 2009 16:06:50 +0100, Pascal a écrit:
Je me demande si un sgdb classique serait le mieux. Je me suis rappelé
des extensions GIS, ça ressemble à mon problème sauf que c'est de la 2D.
Existe t-il quelque chose de similaire en 3D ?



Si j'en crois
http://www.postgis.org/documentation/manual-1.4/ch07.html
http://www.postgis.org/documentation/manual-1.4/ch08.html#PostGIS_3D_Functions
il y a plein de choses relatives à la 3D en GIS/PostGIS...

Autre question, j'ai des valeurs à stocker, elles sont de ce genre:
2.1254+/-0.0001
2.1254+/-0.0011
2.125+/-0.025

Je ne connais pas leur précision à l'avance et elle est différente
suivant les valeurs. Je connais juste leut incertitude. De quelle
manière je pourrai les stocker ?



Cela dépend de quelle manière vous avez besoin de travailler avec
après.
Car si c'est juste un problème de stockage, 2 champs feront l'affaire,
l'un pour la valeur (selon les cas, un entier, un flottant ou
un numeric() avec une précision suffisante pour gérer
toutes vos précisions réelles et un peu de marge, l'autre pour la précision.

En PostgreSQL, vous pouvez créer un type "composite", l'équivalent d'une
structure en C, qui encapsulerait vos 2 éléments.
Cf http://www.postgresql.org/docs/8.4/static/rowtypes.html

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
Pascal
Le #21920681
Le 25 Oct 2009 15:36:29 GMT,
Patrick Mevzek
Le Sun, 25 Oct 2009 16:06:50 +0100, Pascal a écrit:
> Je me demande si un sgdb classique serait le mieux. Je me suis
> rappelé des extensions GIS, ça ressemble à mon problème sauf que
> c'est de la 2D. Existe t-il quelque chose de similaire en 3D ?

Si j'en crois
http://www.postgis.org/documentation/manual-1.4/ch07.html
http://www.postgis.org/documentation/manual-1.4/ch08.html#PostGIS_3D_Func tions
il y a plein de choses relatives à la 3D en GIS/PostGIS...



Après lu à droite et à gauche. C'est pas ce qu'il y a de mieux à mon
cas. Il faut que je me fasse un prototype en SGBDR classique pour voir.


> Autre question, j'ai des valeurs à stocker, elles sont de ce genre:
> 2.1254+/-0.0001
> 2.1254+/-0.0011
> 2.125+/-0.025
>
> Je ne connais pas leur précision à l'avance et elle est différente
> suivant les valeurs. Je connais juste leut incertitude. De quelle
> manière je pourrai les stocker ?

Cela dépend de quelle manière vous avez besoin de travailler avec
après.
Car si c'est juste un problème de stockage, 2 champs feront l'affaire,
l'un pour la valeur (selon les cas, un entier, un flottant ou
un numeric() avec une précision suffisante pour gérer
toutes vos précisions réelles et un peu de marge, l'autre pour la
précision.



Avec un entier, c'est pas possible. Reste un flottant ou numeric.


En PostgreSQL, vous pouvez créer un type "composite", l'équivalent
d'une structure en C, qui encapsulerait vos 2 éléments.
Cf http://www.postgresql.org/docs/8.4/static/rowtypes.html




En effet. Dommage MySQL ne le supporte pas.

Merci,
Pascal
Publicité
Poster une réponse
Anonyme