2011-01-17 3 views
1

Nous avons un type particulier de table dans notre base de données qui stocke l'histoire de ses changements en elle-même. Table dite "auto-archivée":MySQL index unique par plusieurs champs

CREAT TABLE coverages (
    id INT, # primary key, auto-increment 
    subscriber_id INT, 
    current CHAR, # - could be "C" or "H". 
    record_version INT, 
    # etc. 
); 

Elle stocke les "couvertures" de nos abonnés. Le champ "current" indique s'il s'agit d'un enregistrement courant/original ("C") ou d'un enregistrement historique ("H"). Nous ne pouvons avoir qu'une seule couverture "C" actuelle pour l'abonné donné, mais nous ne pouvons pas créer un index unique avec 2 champs (* subscriber_id et current *) car pour tout enregistrement "C" donné, il pourrait y avoir nombre d'enregistrements "H" - historique des changements.

L'index ne doit donc être unique que pour current == 'C' et tout numéro d'abonné. Cela pourrait être fait dans Oracle DB en utilisant quelque chose comme "visualisations matérialisées": où nous pourrions créer une vue matérialisée qui inclurait seulement les enregistrements avec current = 'C' et créer un index unique avec ces 2 champs: * abonné, courant *.

La question est: comment cela peut-il être fait dans MySQL?

+0

Quel est le but de l'index unique? Que ne pouvez-vous pas faire avec un index non unique? Cela ressemble un peu à une optimisation prématurée ... – dkretz

+0

Nous avons plusieurs serveurs d'applications (web) qui pourraient essayer d'insérer le même enregistrement simultanément (et cela arrive réellement). Nous devons éviter les doublons dans le tableau des couvertures. –

Répondre

2

Vous pouvez le faire en utilisant les valeurs NULL. Si vous utilisez NULL au lieu de « H », MySQL will ignore the row when evaluating the UNIQUE constraint:

A UNIQUE index creates a constraint such that all values in the index must be 
distinct. An error occurs if you try to add a new row with a key value that 
matches an existing row. This constraint does not apply to NULL values except 
for the BDB storage engine. For other engines, a UNIQUE index permits multiple 
NULL values for columns that can contain NULL. 

Maintenant, ce triche un peu, et cela signifie que vous ne pouvez pas avoir vos données exactement comme vous le voulez. Cette solution peut donc ne pas correspondre à vos besoins. Mais si vous pouvez retravailler vos données de cette façon, cela devrait fonctionner.

+0

Pour une raison quelconque, je ne pensais pas aux NULL :) Cela fonctionnerait vraiment bien pour nous, au moins comme une solution à court terme ... À long terme, nous allons diviser ce tableau en deux: les couvertures et coverage_history. MERCI BEAUCOUP MONSIEUR!!! –

Questions connexes