Je commen=E7ais =E0 r=E9fl=E9chir =E0 une solution pour stocker des donn=E9=
es
cristallographique. En simplifiant, c'est des coordonn=E9es 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=E9
des extensions GIS, =E7a ressemble =E0 mon probl=E8me sauf que c'est de la
2D. Existe t-il quelque chose de similaire en 3D ?
Autre question, j'ai des valeurs =E0 stocker, elles sont de ce genre:
2.1254+/-0.0001
2.1254+/-0.0011
2.125+/-0.025
Je ne connais pas leur pr=E9cision =E0 l'avance et elle est diff=E9rente
suivant les valeurs. Je connais juste leut incertitude. De quelle
mani=E8re je pourrai les stocker ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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_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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
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
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Pascal
Le 25 Oct 2009 15:36:29 GMT, Patrick Mevzek a écrit :
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
Le 25 Oct 2009 15:36:29 GMT,
Patrick Mevzek <pm-N200910@nospam.dotandco.com> a écrit :
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
Le 25 Oct 2009 15:36:29 GMT, Patrick Mevzek a écrit :
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
