Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Storing trailing zeros in mantissa

Re: Storing trailing zeros in mantissa

From: <ctcgag_at_hotmail.com>
Date: 01 Aug 2003 16:20:21 GMT
Message-ID: <20030801122021.888$dk@newsreader.com>


"Jim Kennedy" <kennedy-down_with_spammers_at_no-spam.comcast.net> wrote:
> Noons is correct. Jeff, the difference is purely one of display and not
> one of actual percision.

You and Norm clearly are not scientists! The difference between 10.2 and 1.02e1 is purely one of display, the difference between 10.2 and 10.20 is not, they differ in the number of significant digits. The fact that Oracle (nor any other RDBMS or programming language I'm aware) does not support this does not mean it isn't real. We're left with the options of either storing them as varchar2 (Ugh ugh), or using two columns, one for the number and one for the precision (Ugh) (or, one for the number in numeric form, and one the number in string form).

> If you are using an interface (eg oci, odbc,
> etc.) tp retrieve this data it will come back as a number and the added 0
> wouldn't make sense.

Wouldn't make sense to whom, to oci and odbc, or to the end user? It would make sense to me!

10.2 is somewhere around 10.15 to 10.25, whereas
10.20 is somwhere around 10.195 to 10.205 and
10.2000 is somewhere around 10.19995 to 10.20005
(of course, the last wouldn't be allowed with the given column definition.)

> (it is a number) In sqlplus you will see it
> depending upon how you have set your formatting to be, but that has
> nothing to do with what the number is.(eg put in a number 10.12345432123
> and you will probably get back a displayed number that displays less
> percision, but if you use oci etc. you will retrieve the full percision
> of the number. You can have the display display more decimals if you set
> the numeric format to be larger.) In short, if your other program wants
> strings (and not numbers) then I would still store the number as a
> number, but just do a to_char(myColumn,formatMask) to get it to "look
> right".

The problem is that what "looks right" is the number of decimals that were there, including trailing zeros, when the number was stored. Unless that information is stored, then there is no way to reconstruct what "looks right". If every value stored in a column has the same real-world precision, then it can be hard-coded as you suggest. But if each row can have a different number of sig figs beyond the decimal, which seems to be the case, then that information needs to be stored in some auxilliary manner.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service              New Rate! $9.95/Month 50GB
Received on Fri Aug 01 2003 - 11:20:21 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US