Re: PostgreSQL Developer Best Practices
| От | David G. Johnston |
|---|---|
| Тема | Re: PostgreSQL Developer Best Practices |
| Дата | |
| Msg-id | CAKFQuwbazNC48GTDyCdZf7iZnK6Rxpp7_gdbN1iYJ=eb6784mw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PostgreSQL Developer Best Practices (Melvin Davidson <melvin6925@gmail.com>) |
| Ответы |
Re: PostgreSQL Developer Best Practices
|
| Список | pgsql-general |
Consider:
SELECT c.registration_no,
c.car_make,
p.part_no
FROM car c
JOIN parts p ON ( p.registration_no = c.registration_no)
WHERE registration_no = <some_var>;
versus:
SELECT c.registration_no,
c.car_make,
p.part_no
FROM car c
JOIN parts p ON ( p.id = c.id)
WHERE registration_no = <some_var>;
Why join on id when registration_no is better?
I believe you are mistaken if you think there are absolute rules you can cling to here. But even then I would lean toward calling primary keys an internal implementation detail that should be under the full control of the database in which they are directly used. Artifical "natural" keys I would lean toward turning into, possibly unique, attributes. Inherent "natural"
keys get some consideration for using directly.
The issue arise more, say, in a many-to-many situation. Do you define the PK of the linking table as a two-column composite key or do you introduce a third, serial, field to stand in for the pair?
David J.
В списке pgsql-general по дате отправления: