Re: PostgreSQL Developer Best Practices

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Melvin Davidson <melvin6925(at)gmail(dot)com>
Cc: Ray Cote <rgacote(at)appropriatesolutions(dot)com>, pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: PostgreSQL Developer Best Practices
Date: 2015-08-24 14:04:45
Message-ID: CAKFQuwbsjDdnc-oV6S2QfkeX=vKRdRJ_dAd6buqRw1b2i1TeQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Aug 24, 2015 at 9:27 AM, Melvin Davidson <melvin6925(at)gmail(dot)com>
wrote:

> 9.
> >1) What happens if someone mis-types the account-id?
> > To correct that, you also need to correct the FK field in the other
> dozen tables.
> >2) What happens when your company starts a new project (or buys a
> competitor) >and all the new account numbers are alpha-numeric?
>
> I would reply that in good applications, the user DOES NOT type the key,
> but rather selects from a drop down list, or the app looks it up / enters
> it for them. Besides, it's just as easy to miskey an integer as it is an
> aplha numeric. The point is, do not create two primary pkey's when one will
> do.
>

​Your missing the point. The existing "Account ID" that you refer to is
apparently externally defined. Pretend it is a social security number.
How would one create a new user in your system, and record their
account_id/social-security-number, without typing it in. What then if it
is discovered that the keyed in value was mis-typed?

​The "point" is to not introduce redundant information. Creating your own
surrogate identifier in order to avoid using a surrogate identifier value
created by another system does not introduce redundancy but rather provides
the system using the primary key control over its generation and, more
importantly, format. The highly situational nature of this is why "data
modelling" is not something I'd incorporate in a "usage" document.​

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2015-08-24 14:09:54 Re: PostgreSQL Developer Best Practices
Previous Message Melvin Davidson 2015-08-24 13:27:15 Re: PostgreSQL Developer Best Practices