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?
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
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. –