Eu prefiro sempre criar uma chave primaria como ID que uso para
relacionamentos. E uso chaves Uniques para evitar duplicidade. Para mim é a
melhor maneira.



Enviado com MailTrack
<https://mailtrack.io/install?source=signature&lang=pt&referral=sil...@gmail.com&idSignature=24>

Silfar Goulart

Em 26 de agosto de 2016 13:03, Tiago José Adami <adam...@gmail.com>
escreveu:

> 2016-08-26 0:30 GMT-03:00 Euler Taveira <eu...@timbira.com.br>:
> > On 25-08-2016 14:17, Tiago José Adami wrote:
> >>    Também há 2 triggers um pouco mais complexos que não permitem
> >>    horários conflitantes, algo impossível de tratar apenas com FKs.
> >>
> > Você tentou usar range types [1] e/ou restrições de exclusão [2] (ex.
> [3])?
> >
> > [1] https://www.postgresql.org/docs/9.6/static/rangetypes.html
> > [2]
> > https://www.postgresql.org/docs/9.6/static/sql-createtable.html#SQL-
> CREATETABLE-EXCLUDE
> > [3]
> > http://stackoverflow.com/questions/10759531/exclusion-
> constraint-with-overlapping-timestamp-range#10760028
>
> Inicialmente a implementação dos triggers foi feita ainda quando as
> chaves primárias eram compostas e era necessário validar junto as
> chaves realmente naturais (em campos fora das PKs) pelo código dos
> triggers. Depois de migrar as tabelas para usar chaves naturais
> simplesmente ajustei o código no tocante às chaves e tudo funcionou
> perfeitamente, portanto não procurei algo para substituir os triggers.
>
> Agora que as tabelas possuem chaves naturais adequadas e o projeto
> está quase homologado, vou me planejar para investir um tempo nisso.
>
> TIAGO J. ADAMI
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a