Comma-ify Numbers

Morning all,

Unless you're doing math on it, make it a character
I [respectfully] disagree!

An excellent rule to follow.
For certain values of 'excellent'? :wink:

Ok, I shall explain. I used to write COBOL programs. Numeric fields in
files could be DISPLAY (ie character) or various forms of binary. (COMP,
COMP-N, COMP-SYNC etc).

A number is a number. It makes not a jot of difference whether it is an
ID, a salary, an age or a telephone number - although they do need
special consideration. So, the correct storage for a number is a numeric
data type.

Phone numbers, even in Excel, have leading zeros. They can cause
problems when the STORAGE format 'loses' them. However, the DISPLAY
format must re-create these leading zeros. So, for example, a phone
number such as 0779 666 6166 can still be stored as a numeric data type,
but displayed as to_char(phone_number, '09999999999').

If I really want the 0779 666 6166 format, I can use
NLS_NUMERIC_CHARACTERS and a format of '0999g999g999' instead:

ALTER SESSION set NLS_NUMERIC_CHARACTERS='. '; -- There's a trailing
space there.
SELECT to_char(07796666166, '0999g999g9999') FROM dual;
0779 666 6166
ALTER SESSION set NLS_NUMERIC_CHARACTERS='.,'; -- Or whatever you
normally use/have saved previously.

Ok, much mucking around just to get a phone number to format correctly.
However, what about international phone numbers +44 (0)779 666 6166 and
it becomes obvious, that a phone number isn't actually a number. So,
character data it is and the data input screen will (won't it?) have
proper phone number format validation - if required.

Other than phone numbers, I cannot think of any other numeric data that
should be stored as a character string. Your US style SSNs may be
different, but in the UK our NI Numbers are formatted as AA999999A and
are thus, text. For example WK196163A.

My rule, since my very early COBOL days is "always use the correct data
type for all data" and this implies that a number is a number in the
same way that a data is a date and not a string.

Besides, storing data in the "wrong" format can seriously throw the CBO
off the best path.

Cheers,
Norm. [TeamLastDayAtWorkBefore2010]

Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else. We have checked this email and its attachments for viruses. But you should still check any attachment before opening it. We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes. If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk

Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.

We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.

If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk

Hi Bob,

I realise that many people may not be interested in
achieving what I'm after, and I agree it would likely be
implemented as an option. But please, I'm more interested in
whether it's possible than whether it would interest anyone
else. It may not be what you want, but please just post a
response a reply if it's relevant to the question.

Well, as far as I'm concerned, I tend to use TO_CHAR() to format my data
as I want it. It's very useful to not bother when retrieving dates and
times - thanks to Toad's options which automagically formats those for
me, but usually, I don't need my numbers formatting all too often.

Now, having said that, I do agree that numeric columns with
comma-separators is a good idea - sometimes I'm trying to look at a
number and my old eyes lose their place as I'm looking at a stream of
digits. The comma's make things easier.

So, yes, I'm interested but equally, when I'm selecting, I usually
format those columns I really want, so I can also live without it.

How's that for a fence sitter!

Cheers,
Norm. [TeamT]

Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else. We have checked this email and its attachments for viruses. But you should still check any attachment before opening it. We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes. If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk

Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.

We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.

If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk

Morning all,

Norm!

Unless you're doing math on it, make it a character
I [respectfully] disagree!

But your argument seems to be only peripherally or semantically different,
if at all? (yes, I'm feeling wordy this AM)

As far as the OP's request of permanent spreadsheet-style formatting, I
think it's enticing, but I'm hesitant to say I'd be for it. Date and
Timestamp formatting is a given and is consistent across all tables,
schemas, and databases. It's therefore easily identified and translated by
my brain, even through my dense skull.

However, with multiple formats of numeric items, it seems to me to be only a
matter of time before a mistake is made. I'm thinking of things like, oh I
don't know, a purely hypothetical situation where a LINE_NO column is stored
as NUMBER(6), but is treated programmatically as having a "990V999"-like
mask. Now let's say LINE_NO is in maybe 20 tables. If one should tell Toad
to format this column in one table as "990V999", shouldn't it be displayed
that was consistently to avoid misunderstanding?

Not many databases have well-designed layouts, IMHO. And in the case of ERP
systems, there are some horrific designs left over from the DASD days. I'm
wondering if an option like this would/could help.

Not exactly what I wanted to say, but I should really be tending to my
backups. I'd like to discuss this over a pint or four, but that's
considered a CLM* here for some strange reason.

My $000000.02,
Rich -- [TeamT]

Disclaimer: In Heaven there is no beer? WHAT?!???!? Since when?

*Career Limiting Move

always use the correct data type for all data

An excellent rule to follow. One that I firmly follow myself.

I get the sense we’ve been here before…

Don’t mind me, Holidays are coming soon and the mind is foggy. I guess I
can say that I’m lucky enough to not have run into a situation of conflict
with regards the two rules:

Hi Rich,

But your argument seems to be only peripherally or semantically different,
if at all? (yes, I'm feeling wordy this AM)
Is it? I'm not sure now you mention it. You said that you "store numbers
as character unless you are going to use it for counting" whereas I said
"store numbers as numbers unless they are not really numbers" - I think
that's quite a difference indeed.

As far as the OP's request of permanent spreadsheet-style formatting, I
think it's enticing, but I'm hesitant to say I'd be for it.
I agree. It would be nice to auto-format numbers like we have with dates
and times, but it can't work for all numbers - and that's the problem.

However, with multiple formats of numeric items, it seems to me to be only a
matter of time before a mistake is made.
Agreed.

Not many databases have well-designed layouts, IMHO.
I agree 100% there. Most of the ones I have seen (but obviously not
designed myself!!) are a nightmare. We have bonkers stuff like date_1,
date_2 ... date_99 (stored as 'dd/mm/yyyy' as VARCHAR2 of course - and
thus, unsortable!) and even worse, a VARCHAR2(4000) column holding lots
of 'fields' all separated by '^^' - AAArgh! (I could kill sometimes!)

Not exactly what I wanted to say, but I should really be tending to my
backups.
Never mind the backups - it's the restores that need tending! :wink:

I'd like to discuss this over a pint or four, but that's
considered a CLM* here for some strange reason.
:slight_smile:

Disclaimer: In Heaven there is no beer? WHAT?!???!? Since when?
Hmm. The advantages of "easy origami" are two-fold!

Cheers,
Norm. [TeamT]