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
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 |