[firebase-br] chave estrangeira

[Gladiston Santana]

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