[firebase-br] Ajuda projeto

[Gladiston Santana]

Olá.
Não tem segredo.
Chamamos de PK (chave primaria) a chave de sua tabela mestre que nunca se
repete, as tabelas adicionais que se ligam com ela, eu gosto de chamar de
tabela detalhe, assim fica fácil de entender o termo de tabela mestre vs
detalhe. O campo chave da tabela detalhe que se liga uma tabela mestre
chamamos de FK (chave estrangeira).
Quando você faz esse enlace entre tabelas criando PK e FK, também chamamos
de modelagem normatizada porque na teoria não deixaria registros orfãos, ou
informações de tabelas detalhes que não se ligam a ninguém na tabela mestre.
Ao ligar uma tabela mestre a outras detalhes como a que você quer fazer,
chamamos esse tipo de enlace como 1 para N.
Quando se  faz esse tipo de enlace pode tomar ações quando uma FK é
alterada (on update) ou excluída (on delete):
no action->não faz nada
cascade->reflete a mudança no PK e as transfere para as FKs
set null->ajusta o valor da FK como nulo
set default->ajusta o valor da FK para o default do campo.

Por exemplo, como 'cascade' quando alguem altera o codigo do produto de
XPTO para ACME, a regra fará as alterações nas tabelas detalhes sem que
você precise fazer nada. Muito util para campos chave que sejam ALFA e que
por alguma razão tenham de ser modificados por usuários, códigos de produto
são bastante usuais enquanto clientes, fornecedores,... quase não se usa
codigo alfa, apenas inteiro.
O set null é assim: apagou a PK, as tabelas detalhes virarão null´s.
O set default é assim: apagou a PK, as tabelas detalhes, mais precisamente
as FKs receberão o valor default do campo. Para não gerar registros órfãos,
o pessoal cria registros virtuais na tabela mestre onde seriam endereçados
os orfãos, por exemplo, um registro de cliente id=0 receberia os telefones
cujo set default os tornasse id=0.
Na pratica o mais comum é 'no action' e 'cascade', o cascade a primeira
vista parecer ser o melhor caminho, mas não é em todas as situações, tem
que ser usado com cautela antevendo mudanças lá na frente. Porque uma vez
usado será sempre usado por todas as tabelas que envolverem integridade
referencial, ai de você se não colocar a integridade ou não fizesse o
enlace PK/FK por uma inconveniência qualquer, produzirá resultados lixo na
sua base que quem não participou da modelagem  nunca entenderá o porquê um
lixo anda aparecendo se é que algum dia a percebesse.

Eu tentei simplificar para você, a rigor, há explicações exatas, mas não
tão simples.

Em 18 de janeiro de 2015 21:42, Qatan <wanstadnik em gmail.com> escreveu:

> Olá Walter,
>
> Segue link para download da base que preparei: http://dropcanvas.com/obm5j
> Uma coisa que não encontrei no seu material foi sobre a questão da
> integridade referencial, mais especificamente: ON DELETE/ON UPDATE
> Você poderia explicar um pouco mais sobre isso?
> Obrigado
>
> Qatan
>
>