I design a DB which contains districts of cities.

The question: Is it reasonable to store IDs of districts instead of
district names, provided that we have hard-coded map from district IDs
to district names? Conditions: 1. Disk space is not an issue. 2.
Search on districts is not going to be implemented.

I'm sure that disk space and ability to quickly search districts
mandate to use IDs in place of strings. But that's is not an issue.

So, should I?

On 2008-10-26, Victor Porton <porton (AT) narod (DOT) ru> wrote:
if it's not going to be a foreign key for some other reason there's no
need make it one.

Bye.
Jasen

On 2008-10-26, Victor Porton <porton (AT) narod (DOT) ru> wrote:
if it's not going to be a foreign key for some other reason there's no
need make it one.

Bye.
Jasen

On 2008-10-26, Victor Porton <porton (AT) narod (DOT) ru> wrote:
if it's not going to be a foreign key for some other reason there's no
need make it one.

Bye.
Jasen

On Oct 26, 4:58*pm, Victor Porton <por... (AT) narod (DOT) ru> wrote:
I usually stick to the natural keys when possible. Now some questions
are:

Are these IDs natural? (e.g. plot map lot numbers)
Are these IDs known to users?
If the answer to either of these is yes, then use the IDs.

Are you merely "normalizing" the verbiage out to reduce space? What
does you data model look like? Are you planning on leaving the
district names totally out of the database?

Your search comment is totally wrong for many DBMS products. Numeric
ID keys are NOT significantly faster than text keys. And with the
prices and capacities of disc drives nowadays, trying to squeeze disc
space is a poor planning approach. Before thinking about space or
speed, get the system functioning first.

Ed

On Oct 26, 4:58*pm, Victor Porton <por... (AT) narod (DOT) ru> wrote:
I usually stick to the natural keys when possible. Now some questions
are:

Are these IDs natural? (e.g. plot map lot numbers)
Are these IDs known to users?
If the answer to either of these is yes, then use the IDs.

Are you merely "normalizing" the verbiage out to reduce space? What
does you data model look like? Are you planning on leaving the
district names totally out of the database?

Your search comment is totally wrong for many DBMS products. Numeric
ID keys are NOT significantly faster than text keys. And with the
prices and capacities of disc drives nowadays, trying to squeeze disc
space is a poor planning approach. Before thinking about space or
speed, get the system functioning first.

Ed

On Oct 26, 4:58*pm, Victor Porton <por... (AT) narod (DOT) ru> wrote:
I usually stick to the natural keys when possible. Now some questions
are:

Are these IDs natural? (e.g. plot map lot numbers)
Are these IDs known to users?
If the answer to either of these is yes, then use the IDs.

Are you merely "normalizing" the verbiage out to reduce space? What
does you data model look like? Are you planning on leaving the
district names totally out of the database?

Your search comment is totally wrong for many DBMS products. Numeric
ID keys are NOT significantly faster than text keys. And with the
prices and capacities of disc drives nowadays, trying to squeeze disc
space is a poor planning approach. Before thinking about space or
speed, get the system functioning first.

Ed

Ed Prochak wrote:

Another approach when in doubt of using surrogate keys, would be to ask
oneself: "how many million districts will there ever be? how many times
per day will a district change its name?"

Ed Prochak wrote:

Another approach when in doubt of using surrogate keys, would be to ask
oneself: "how many million districts will there ever be? how many times
per day will a district change its name?"

Ed Prochak wrote:

Another approach when in doubt of using surrogate keys, would be to ask
oneself: "how many million districts will there ever be? how many times
per day will a district change its name?"