Re: PostgreSQL Developer Best Practices

Поиск
Список
Период
Сортировка
От Melvin Davidson
Тема Re: PostgreSQL Developer Best Practices
Дата
Msg-id CANu8Fiwww79WdhADHXCdULEoAAP=nZVwgQ-iwgDuOxsvE=00Kg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL Developer Best Practices  (Ray Cote <rgacote@appropriatesolutions.com>)
Ответы Re: PostgreSQL Developer Best Practices
Re: PostgreSQL Developer Best Practices
Список pgsql-general
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.

On Mon, Aug 24, 2015 at 9:15 AM, Ray Cote <rgacote@appropriatesolutions.com> wrote:
On Sat, Aug 22, 2015 at 11:46 AM, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:
> 1. Prefix ALL literals with an Escape
>    EG:  SELECT E'This is a \'quoted literal \'';
>         SELECT E'This is an unquoted literal';
>
>    Doing so will prevent the annoying "WARNING:  nonstandard use of escape in a string literal"

I'd be concerned that what is missing here is the bigger issue of  Best Practice #0: Use Bound Variables. 
The only way I've seen invalid literals show up in SQL queries is through the dynamic generation of SQL Statements vs. using bound variables. 
Not using bound variables is your doorway to SQL injection exploits.


9. Do NOT arbitrarily assign an "id" column to a table as a primary key when other columns
    are perfectly suited as a unique primary key.
... 
        Good example:
        CREATE TABLE accounts
        ( accout_id bigint NOT NULL ,

I would not consider the general use of natural primary keys to be best practice. 
Let's assume your account_id field is used as a foreign key in a dozen other tables.
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?
3) Your example shows the id as a bigint, but your rule is not limited to integers. 
What if your table is country populations and the primary key is country name?
Now, you have quite large foreign keys (and a country changing its name is not unheard of).
(and let's not even get started on case-sensitivity or character encodings).

--
Raymond Cote, President
voice: +1.603.924.6079 email: rgacote@AppropriateSolutions.com skype: ray.cote





--
Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

В списке pgsql-general по дате отправления:

Предыдущее
От: Ray Cote
Дата:
Сообщение: Re: PostgreSQL Developer Best Practices
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: PostgreSQL Developer Best Practices