Muitas Chaves Estrangeiras
Amigos,
Estou modelando um banco de dados para controle Financeiro, que possui as seguintes tabelas:
Caixa
Contas a Pagar
Contas a Receber
Conta Bancária
Cheques
Um registro na tabela Caixa deve obrigatóriamente estar vinculado a uma das outras tabelas. O problema é que quando eu tenho um registro do Caixa vinculado a uma tabela (Cheques, por exemplo) as demais chaves estrangeiras ficarão vazias (null).
Alguém tem outra alternativa a não ser a que estou usando (Uma chave estrangeira - na tabela Caixa - para cada tabela)?
Grato,
Estou modelando um banco de dados para controle Financeiro, que possui as seguintes tabelas:
Caixa
Contas a Pagar
Contas a Receber
Conta Bancária
Cheques
Um registro na tabela Caixa deve obrigatóriamente estar vinculado a uma das outras tabelas. O problema é que quando eu tenho um registro do Caixa vinculado a uma tabela (Cheques, por exemplo) as demais chaves estrangeiras ficarão vazias (null).
Alguém tem outra alternativa a não ser a que estou usando (Uma chave estrangeira - na tabela Caixa - para cada tabela)?
Grato,
Carlosfim
Curtidas 0
Respostas
Eduardo Pereira
06/06/2005
Uma segunda alternativa é criar tabelas de relacionamento entre a tabela Caixa e cada uma das outras tabelas. Estas tabelas conteriam a chave primária da tabela Caixa e a chave primária da respectiva tabela relacionada, não sendo neessário o uso das chaves estrangeiras na tabela Caixa.
Esta solução tem a desvantagem de um maior número de tabelas a serem manipuladas, aumentando a complexidade do processamento.
Porém não vejo problema na solução que você adotou. A aparente desvantagem de um maior consumo de espaço é desprezível, já qua a maioria dos BDs não armazena os nulos (pelo menos o Oracle e Interbase/Firebird).
Em ambas as alternativas a restrição da tabela Caixa ter que estar vinculada a pelo menos uma das outras tabelas tem que ser tratada, via trigger ou pela aplicação (a primeira é mais indicada).
Na sua solução também não é possível tornar a tabela Caixa dependente das outra tabelas, pois qualquer uma das chaves estrangeiras poderá ser nula, logo não podendo fazer parte da chave primária.
Esta solução tem a desvantagem de um maior número de tabelas a serem manipuladas, aumentando a complexidade do processamento.
Porém não vejo problema na solução que você adotou. A aparente desvantagem de um maior consumo de espaço é desprezível, já qua a maioria dos BDs não armazena os nulos (pelo menos o Oracle e Interbase/Firebird).
Em ambas as alternativas a restrição da tabela Caixa ter que estar vinculada a pelo menos uma das outras tabelas tem que ser tratada, via trigger ou pela aplicação (a primeira é mais indicada).
Na sua solução também não é possível tornar a tabela Caixa dependente das outra tabelas, pois qualquer uma das chaves estrangeiras poderá ser nula, logo não podendo fazer parte da chave primária.
GOSTEI 0
Carlosfim
06/06/2005
Obrigado pela dica Eduardo.
Uma segunda opinião é sempre válida num caso desses.
Vou continuar utilizando a solução antiga mesmo, mas vou adicionar o trigger que vc mencionou
até +.
Uma segunda opinião é sempre válida num caso desses.
Vou continuar utilizando a solução antiga mesmo, mas vou adicionar o trigger que vc mencionou
até +.
GOSTEI 0