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