Em 25 de agosto de 2016 14:29, Fabiano Machado Dias
<[email protected]> escreveu:
> Legal, você poderia usar UK's e ainda assim manter a suas chaves
> artificiais, muitas vezes a preocupação com a chave primária faz com que as
> pessoas esqueçam que podemos ter N UK's para manter a integridade nos
> trilhos e no banco!
>
> Hoje tenho diversos projetos onde o uso de ORM é constante, para conviver
> com ele faço isso, o fato é que tabela sem chave natural é o inferno de
> qualquer modelo.
Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?) não
garante a integridade lógica entre as tabelas, apenas entre os
registros de uma só tabela. Por exemplo, eu poderia ter a tabela de
reservas como antes:
CREATE TABLE reserva (
/* PK artificial, única */
id_reserva SERIAL NOT NULL,
/* FK tabela ITEM_RESERVA */
id_item_reserva INTEGER NOT NULL,
/* FK tabela PESSOA */
id_pessoa INTEGER NOT NULL,
(...)
)
Uma das regras do sistema é que apenas servidores do próprio campus
possam fazer reservas dos itens do seu campus.
Nesse modelo com chaves artificiais acima, mesmo que haja um índice
único não impede de fazer uma reserva de um item do campus A para uma
pessoa do campus B. Só se você implementar um TRIGGER que valide isso
e retorne uma exceção, mas aí já começa a complicar demais o modelo.
Outra vantagem das chaves naturais é saber pela tabela "filha" quem
são os "pais". Neste exemplo com chaves artificiais, eu precisava
fazer JOIN com mais 3 tabelas para saber qual o campus.
TIAGO J. ADAMI
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
