Re: [Info-ingres] Re: is there an equivavlent to auto_increment in ingres ?

"Roy Hann" <specially@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:m4ednc_qSLM4hEPfRVnyvQ@xxxxxxxxxxxx
> "Paul Andrews" <ac297@xxxxxxxxxxxxxxxxxx> wrote in message
> news:9moDe.4620$jo3.676@xxxxxxxxxxxxxxxxxxxxxxx
> > I thought I'd jump in here and add in a scenarios where <sharp intake of
> > breath> I don't have a problem with artificial keys.
>
> They are not invariably wrong, bad, or even undesirable. They just
usually
> are.
>
> > For example, a queue processor where jobs are added to a queue and users
> can
> > view the queue to see the progress of their job. Of course, we could
> > timestamp the job and locate it with the userid and timestamp and maybe
> the
> > jobname, but users would find it infinitely more convenient to refer to
> job
> > 456 on the queue and be able to say that job 456 appears to have a
> problem,
> > rather than saying the job I submitted at 10 O'clock needs to be rushed
> > through. it's far more convenient to key the job queue on the job number
> and
> > have the system increment the jobnumber as jobs are submitted.
>
> I don't want to pick an endless stream of specific examples apart, so I
will
> just say that there are a number of appealing-sounding intuitions here
that
> actually require careful justification. It is not at all clear to me that
> this is a plausible example of where a synthetic key is required. For a
> start, what is the intrinsic significance of 456 to the user? It has none
> at all.

The user understands the notion of a queue of jobs to be performed and
understands the idea that 456 uniquely identifies their task in the queue -
they may have 20or 30 tasks in progress. If need be they can pick up the
phone and discuss their job with a helpline, administrator or work
colleague.

In an ideal world maybe they could press some button to get the desired
effect, but in practice there's more involved than pressing buttons - some
debate between humans!

The really important thing is that the user can simply identify the job in
question and they have no problem in doing that. I suspect that if I'd
called it a transaction number and used text there wouldn't be much of an
argument, but in practice a simple numeric value does nicely and auto
increment would work nicely too.



> The user can know that a job is urgent or in trouble only because
> of the intrinsic facts about that job. The only slight advantage of a
> shorthand synthetic is if you want to type a command, e.g. kill job 456

Effectively, I'm allowing them to do that but with human interaction. If
your comfortable with a command line interface using such a value, you can't
dismiss the use of these artificial keys in general.

>, but
> the user would almost certainly prefer a GUI even if they had a shorthand
> they could use. And if they had a GUI they wouldn't need (or miss) the
> synthetic key.

They do have a GUI and they still will refer to the job number - infinitely
preferable to the 12th job submitted at 11:01 for the payroll run..

> > So, this is a case where I'd use an artificial key that's exposed to the
> > user.
> >
> > I've no doubt I could think of more scenarios, but that's at least one
to
> > chew over.
>
> As I said in an earlier post, these synthetic identifiers have a place,
but
> as your last sentence makes clear, those places are more rare than you'd
> guess from looking at the average database design. Even if the system can
> generate values automatically, they (usually) make more work, not less,
and
> they (usually) create more doubt and confusion, not less. Use them only
> very reluctantly.

I will agree with that, but I suspect that people sometimes use data that
they consider to be immutable in keys when it is not immutable.

Paul

> Roy
>
>
> _______________________________________________
> Info-ingres mailing list
> Info-ingres@xxxxxxxxxxxxxxx
> http://mailman.cariboulake.com/mailman/listinfo.py/info-ingres
>


.

Quantcast