Re: FW: Re: FW: Re: Shouldn;t this trigger be called?

From: stan <stanb(at)panix(dot)com>
To: Michael Lewis <mlewis(at)entrata(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: FW: Re: FW: Re: Shouldn;t this trigger be called?
Date: 2019-09-20 10:30:31
Message-ID: 20190920103031.GA21182@panix.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Sep 19, 2019 at 03:54:40PM -0600, Michael Lewis wrote:
> You can also look at citext type to avoid the casting.

Oh, that looks really useful I think I will go back and use that type quite
a bit.

Thanks for pointing it out to me.

>
> customer_key integer DEFAULT
> nextval('customer_key_serial') PRIMARY KEY ,
> cust_no smallint NOT NULL UNIQUE ,
> name varchar UNIQUE ,
>
> Why do you have a surrogate primary key generated by a sequence when you
> have a natural key of either cust_no or name? Why not just declare the
> customer number to be the PK?

At the moment, the customer (who is a small startup) really does not have a
customer number. It is really a place holder at the moment, with the
sequence being the "real" key. For all I know, the customer number may be
alphanumeric. in the final implementation.

> Where does customer number come from anyway?
> Using smallint seems potentially short-sighted on potential future growth,
> but changing the type later should be minimal work as long as you don't
> have this customer_number denormalized many places, or use it as the FKey
> after dropping customer_key surrogate key.

Thanks for your suggestion.

--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Morris de Oryx 2019-09-20 10:52:00 Re: FW: Re: FW: Re: Shouldn;t this trigger be called?
Previous Message Michael Lewis 2019-09-20 04:01:28 Re: problems importing from csv