Programming, data storage, database

Question

0.00/5 (No votes)

See more:

Is there any reasonable reason to have the numeric ID stored as a string? I have come across a number of occurrences where a number is written as a string in the database or in code. It seems like a waste of space, memory and computer power, doesn't it?

What I have tried:

ask here how others see it :)

Posted 9-Nov-21 5:07am

KarNullKa

Updated 9-Nov-21 5:54am

Add a Solution

Comments

Richard MacCutchan 9-Nov-21 11:13am

No, it is a bad idea. Numbers should be stored as numbers (integer, floats etc.), Dates as Date or DateTime types etc.

Richard Deeming 9-Nov-21 11:33am

It depends on the data. For example, a telephone "number" isn't really a number, so it makes sense to store it as a string.

But if it's just a simple numeric key for the record, then it shouldn't be stored as string.

KarNullKa 9-Nov-21 14:02pm

Usually it's an ID element, so numbers like 1, 2, 3... 1,000,000, 1,000,001, often very large, but nothing SqlDecimal can't handle.

CHill60 9-Nov-21 11:46am

This drives me mad at my current place of work, all of the UIDs are strings, deliberately so. Someone did try to explain to me why it was a "good idea" but I switched off after "what if we want to use a non-numeric UID". Phone numbers I get (and would deffo never use a numeric), even house "numbers" ("13b" anyone?) but IDs - nope, not strings.
BTW, these are the same people that have inserted "[UNKNOWN]" as values in to columns containing NULLs. Oh to be able to use ISNULL or COALESECE just once more!

KarNullKa 9-Nov-21 14:06pm

That's why I'm finding out if there's a reason for it before I start fighting with management, but it's probably going to be a futile fight.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2021-11-09T05:54:00

None whatsoever: always store data in the most appropriate datatype. That means numbers in numeric field (INT, DECIMAL, FLOAT, ...), dates in DATETIME, DATE, or DATETIME2, and only string based data in strings.
Storing data in strings when it isn't string based data is a recipe for problems later, as it allows for bad data to enter your DB and not be detected until later when it's used - and by them it's too late, nobody has any memory of what it should be.

The only time an ID should be stored as a string is when it contains non-numeric data such as a prefix code: "AB1234" or occasionally "001234" - but I'd probably store that as a number and post process it to add the leading zeros if and when necessary.