|
|
Posted by Gert-Jan Strik on 06/12/07 16:58
Jeff Kish wrote:
>
> On Fri, 8 Jun 2007 21:07:04 +0000 (UTC), Erland Sommarskog
> <esquel@sommarskog.se> wrote:
>
> >Jeff Kish (kishjjrjj@charter.net) writes:
> >> the data represents coordinates on images that can vary vastly in
> >> scale and precision.
> <snip>
> >> one page might vary from -1.234565 to 1.3234343 in extents, placing
> >> all coordinates in that range, and another might be a different type
> >> of image and range from -10245 to 10245.
> >
> >Could you have coordinates that are 1E12 or 1E-12 as well? I would
> >expect that is after all some practical limit. In this case you could use
> >something like decimal(20,10). Or may be varchar is an alternative? I
> >would definitely avoid float.
> >
> thanks.
> so avoid float because it is a non exact storage and that makes it dubious for
> part of a key, or is it just because floats are inherently bad in a pk for
> performance reasons?
Dubious for (part of) a key. See below
> >Yet an alternative is some roll-your-own decimal. That is, you would
> >save the coordinates as integer, and you would store the scale separately,
> >possibly in a table with the page as key.
> I really would like to/need to stay with some standarad / built in type.
> I'll take a peed at the decimal... maybe I can make due with them.
> why are they better than floats for the pk cols?
The potential problem with floats is their inexact nature. Depending on
your hardware the value may differ (slightly). This can cause problems
when moving to a different server (which you might have to do if there
is a hardware problem).
Because of that you basically should not use them for keys.
HTH,
Gert-Jan
> regards
> Jeff
> Jeff Kish
Navigation:
[Reply to this message]
|