Utilisation de valeurs NULL dans la table de correspondance

Question

Je travaille sur la partie comptable d'un système de réservation (pensez à la société de limousine).

Dans le système, plusieurs objets peuvent être payés ou envoyer un paiement. Je suis suivi de toutes ces "transactions" dans trois tables appelées: tx, tx_cc, et tx_ch. Tx génère un nouveau tx_id (pour l'ID de transaction) et conserve les informations sur la quantité, la validité, etc. Tx_cc et tx_ch conservent les informations sur la carte de crédit ou le chèque utilisé, respectivement, qui pointent vers d'autres tables (credit_card et bank_account entre autres).

Cela me semble assez normal, non?

Voici mon problème:

La transaction de paiement peut avoir lieu pour une myriade de raisons. Une réservation est payée, un agent de voyages ayant réservé une réservation est payé, un chauffeur est payé, etc.

Il en résulte plusieurs tables, une pour chacune des entités: agent_tx, driver_tx, reservation_tx, etc.

Ils ressemblent à ceci:

CREATE TABLE IF NOT EXISTS `driver_tx` (
    `tx_id` int(10) unsigned zerofill NOT NULL, 
    `driver_id` int(11) NOT NULL, 
    `reservation_id` int(11) default NULL, 
    `reservation_item_id` int(11) default NULL, 
    PRIMARY KEY (`tx_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

maintenant, cette transaction est un pilote, mais il pourrait être appliqué à un élément individuel sur la réservation ou toute réservation globale. Par conséquent je demande soit reservation_id OU reservation_item_id soit nul. Dans le futur, il y a peut-être d'autres choses pour lesquelles un chauffeur est payé, que j'ajouterais à cette table, par défaut à null.

Quelle est la règle à ce sujet? Opinion?

Évidemment, je pourrais décomposer cela en plusieurs tables de trois colonnes, mais le montant de l'assemblage externe nécessaire semble scandaleux.

Vos commentaires sont appréciés.

paix, Tom

Answer 1

Peut-être la meilleure façon de gérer cela est par generalization, mais il est difficile de dire que par la structure de base de données.
Vous pouvez modéliser un supertype pour chaque entité qui peut être payée et un autre type pour chaque entité qui peut soumettre un paiement.

Dans ce cas, votre table driver_tx seraient généralisées à:

CREATE TABLE IF NOT EXISTS `tx` (
    `tx_id` int(10) unsigned zerofill NOT NULL, 
    `paying_id` int(11) NOT NULL, 
    `payable_id` int(11) NOT NULL, 
    PRIMARY KEY (`tx_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8;