banco de dados SQL (Firebird): problema com uma chave estrangeira

Question

banco de dados My SQL (Firebird) tem uma tabela chamada tTransaction . Ele contém duas colunas, senderFK e receiverFK . Há três outras tabelas, tBufferStock , tFacility e tOutsideLocation .

Um remetente ou um receptor pode ser um estoque regulador, nossas próprias instalações ou fora localização.

O meu problema é que eu não sei como deixar senderFK ou receiverFK referência a tabela direita.

Eu pensei em uma nova tabela entre o emissor e os três remetentes possíveis com um ID, um número entre 1 e 3 para a tabela eo ID referenciados dentro deste quadro, mas, na verdade, que não resolve o problema. Alguma idéia?

Norbert

Answer 1

O que você está tentando fazer não pode ser feito em SQL. Você não pode fazer referência até três tabelas diferentes com um único FK.

O que você precisa fazer seria:

• criar colunas adicionais senderBufferstockFK, senderFacilityFK e senderOutsideLocationFK
• conectar aqueles para as tabelas apropriadas
• tem uma restrição de verificação (se suportado) ou um gatilho ou outro mecanismo na sua mesa principal para certificar-se de apenas um dos três tem um valor a qualquer momento

Isto significaria, em determinado momento, apenas um da coluna de três "fk" poderia ter um valor nele, mas cada coluna FK seria uma FK específica a uma tabela específica.

Você poderia colocar esta diretamente para a tabela que você está falando, ou você pode exteriorizar isso em uma tabela separada e de sua mesa principal referência apenas que a tabela "intermediário", e de lá tem esses três FK

YourTable.SenderFK --> Intermediary.PK
    Intermediary.SenderBufferstockFK --> tBufferstock.ID
    Intermediary.SenderFacilityFK --> tFacility.ID
    Intermediary.SenderOutsideLocationFK --> tOutsideLocation.ID

Ou você pode simplesmente soltar o FK-relacionamento, mas isso é definitivamente não uma boa idéia!

Marc

Answer 2

Tente o seguinte esquema:

tSenderReceiver (type INT, id INT, PRIMARY KEY (type, id))

tTransaction (id INT PRIMARY KEY, senderType INT, senderId INT, receiverType INT, receiverID INT,
      FOREIGN KEY (senderType, senderID) REFERENCES tSenderReceiver,
      FOREIGN KEY (receiverType, receiverID) REFERENCES tSenderReceiver
)

tBufferStock (type INT, id INT,
      CHECK (type = 1),
      PRIMARY KEY (type, id),
      FOREIGN KEY (type, id) REFERENCES tSenderReceiver
)

tFacility (type INT, id INT,
      CHECK (type = 2),
      PRIMARY KEY (type, id),
      FOREIGN KEY (type, id) REFERENCES tSenderReceiver
)

tOutsideLocation (type INT, id INT,
      CHECK (type = 3),
      PRIMARY KEY (type, id),
      FOREIGN KEY (type, id) REFERENCES tSenderReceiver
)

Answer 3

SQL não suporta uma chave estrangeira da forma "quer esta coluna na tabela X ou essa coluna na tabela Y". Você pode:

1. Refactor seu banco de dados para que todos os três possíveis tabelas de chaves estrangeiras são combinados em um, possivelmente, chamado tCounterParty. Este é definitivamente apropriado se a estrutura dessas tabelas é idêntico ou muito similar. Se eles não são semelhantes você ainda pode tomar essa atitude e usar outras três tabelas, ligadas à tCounterParty, para armazenar as informações variadas.

2. Mova seu integridade referencial de uma chave estrangeira em um gatilho, se suportado pelo seu banco de dados.

Answer 4

você não pode usar 3 colunas remetente e 3 para o receptor? assim você vai ter bufferSenderFK, facilitySenderFK e facilitySenderFK. para uma única transação, 1 coluna podem ser usados ??e outros dois serão nulos.