Isso aí, chave primária é só uma chave, não precisa ser a "sua" principal chave no modelo. No caso dos ORM's que gostam de usar os famigerados "ID's", deixe que eles usem isso, vc usa as suas chaves e doutrina os seus desenvolvedores.
Em 25 de agosto de 2016 14:54, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > 2016-08-25 14:41 GMT-03:00 Tiago José Adami <adam...@gmail.com>: > > > > Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?) > > Na verdade, chaves alternativas. Uma relação tem n chaves, onde n >= > 1. Assim, além da chave primária pode haver o outras chaves, onde o > >= 0. É irrelevante qual das chaves se escolhe como primária, esse > conceito de chave primária está obsoleto e é vazio. > > > > > não > > garante a integridade lógica entre as tabelas, apenas entre os > > registros de uma só tabela. > > Não exatamente, a função das chaves alternativas, além de documentar o > modelo, tornando-o mais transparente (de fácil compreensão), é > justamente possibilitar a convivência de chaves naturais e artificial; > nos raros casos em que há exagero de consumo de memória por uso de > chaves naturais complexas se reproduzindo em tabelas filhas muito > maiores que as pais, pode-se ‘exportar’ a chave artificial, garantindo > a integridade referencial, enquanto as naturais seguem garantido a > unicidade. Mas há que se lembrar que cada chave artificial é um > atributo e um índice a mais, custando não apenas memória mas também > E/S. > > Creio que não é esse caso que exemplificaste abaixo, é? > > > > 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. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org > +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm > _______________________________________________ > 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
