Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha ou "neta" da tabela.
Mas assim, no que eu vi, na prática é o seguinte: 1 - A informação da chave, geralmente não é a que vc quer, então o join vai acontecer igual 2 - Os índices ficam bem maiores 3 - Vc tem uma redundância de informações e maior consumo de espaço 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense no tamanha da instrução. O sistema em questão que eu citei anteriormente tem todos esses problemas e hoje é um verdadeiro elefante branco. Em 25 de agosto de 2016 14:41, Tiago José Adami <[email protected]> escreveu: > 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 >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
