[firebase-br] chave estrangeira

Marcelo Geyer estanisgeyer em gmail.com
Seg Mar 6 09:33:13 -03 2017


Pois é, cada caso é um caso. Eu estou adotando um caso com
possibilidade de FK nulos, quando vinculo um registro opcional da
tabela "B" à um registro "A". Então se este campo da tabela "A" for
nulo, quer dizer que não há um registro da tabela "B" associado. Para
esta situação a performance é excelente com um banco de dados bem
populado, mas eu concordo com o Gladiston que isso deve ser usado com
cuidado.

Em 6 de março de 2017 09:14, Gladiston Santana <gladiston em vidy.com.br> escreveu:
> O uso de nulos em FK no Firebird, embora aceitáveis, acho questionáveis.
> Há inclusive uma opção de CASCADE SET NULL (no enlace de PK e FK) que
> quando um registro-pai é excluido, os registros filhos tem o campo alterado
> para NULL. Ficam órfãos do mesmo jeito, mas é uma forma de explicitá-los e
> evitar que uma futura inclusão de informação seja erroneamente associados
> aos antigos registros filhos. Então, se eu fosse auditar uma tabela, eu
> poderia supor que nulos foram registros que ficaram orfãos num dado momento
> e que há registros faltando na tabela principal.
>
> Sobre aceitar ou não nulos numa PK (também FK) , é como decidir permitir
> nulos em campos numéricos, o que é mais aceitável: deixar zero ou permitir
> que nulos gerem erros em expressões e ficar colocando coalesce em tudo que
> é expressão?
> Da mesma forma. talvez você tenha que resolver muitos problemas depois para
> lidar com a presença desses nulos em sua base de dados.
>
> Em tabelas pequenas, quando preciso que um valor seja uma referencia de um
> dado de outra tabela, mas não quero uma FK para isso porque alguns dados
> sem uma PK (orfãos) seriam aceitáveis então crio um DOMAIN que faça um
> LOOKUP em outra tabela, ex:
> CREATE DOMAIN DOM_UF AS CHAR(2) DEFAULT '**' NOT NULL
> CHECK ((VALUE='') OR (VALUE='**')
>        (EXISTS(SELECT * FROM TABELA_UF WHERE UF=VALUE)));
>
>
> CREATE TABLE CLIENTES(id_cliente int, ..., ENDERECO varchar(120), UF
> DOM_UF);
>
> No exemplo acima, o campo *UF* com esse domain aceitaria uma unidade
> federativa como SP, RJ, MG, ... mas também branco ou '**', e com uma leve
> modificação eu poderia aceitar nulos também.
> Nesse caso, um ** ou branco não precisaria estar previamente cadastrado
> noutra tabela.
> Quando a tabela é pequena não é necessário criar nenhum indice no firebird,
> porque quando há poucos registros, ele sempre faz um *natural plan*, parece
> que esse é um caminho mais performático do que analisar e determinar um
> indice. Já experimentei tabelas com milhares de registros onde o natural
> plan foi a melhor opção, *acho* que a condição que determina o uso ou não
> de um indice é quantas vezes uma informação é requisitada e quanta memória
> há no sistema para absorver uma tabela inteira na memória.
>
> Se não for criar um índice, pense duas vezes, porque não estou dizendo que
> o natural plan é bom sempre, em algumas situações ele pode ser a resposta
> do banco no inicio, mas a medida que a tabela popular-se, essa questão pode
> mudar.
>
> []´s e sucesso.
>
>
> Em 3 de março de 2017 09:55, Rodrigo Arcoverde <rodrigo.arcoverde em gmail.com>
> escreveu:
>
>> Pessoal, bom dia.
>>
>> Estou com uma dúvida com relação a criação de chaves estrangeiras
>> compostas. Me ocorre que uma chave estrangeira serve para garantir que um
>> determinado conjunto de campos da tabela A possui uma correspondência exata
>> em uma chave primária (neste caso composta) na tabela B. Se todos os campos
>> da chave estrangeira na tabela A são não nulos, a verificação é feita na
>> chave primária da tabela B. Se todos os campos da chave estrangeira da
>> tabela A são nulos, não ocorre erro, pois não há a necessidade de validação
>> da integridade referencial. No entanto, se apenas uma parte dos campos da
>> chave estrangeira na tabela A for não nulo, como isso funciona no firebird
>> 2.5 e no 3.0? Estava validando um código para alterar o metadado de um
>> banco e poderia jurar que isso não ia funcionar, mas está rodando e não dá
>> erro de validação da chave estrangeira nesta situação. Gostaria de entender
>> melhor este processo para manter a chave estrangeira como proposto pela
>> minha equipe ou se tratamos isso nas triggers. Obrigado.
>>
>> Att,
>> Rodrigo Arcoverde
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://www.firebase.com.br/pesquisa_lista.html



-- 
Marcelo E. Geyer
Standard Net Tecnologia e Informação




Mais detalhes sobre a lista de discussão lista