2011-06-10 5 views
1

J'ai une table « Messages » qui a les champs suivants (correspondant à cette question):Faire un index unique qui est techniquement pas unique

SenderID | int 
DateSent | DateTime 

Je me demandais de créer un index unique sur ces deux champs et avez une question. Techniquement, cette combinaison de champs n'est pas une combinaison unique (c.-à-d., Par conception, il n'y a rien qui l'arrête), mais ce sera pratiquement le cas. L'application qui utilise cette table est une application web et un expéditeur ne pourra jamais envoyer des messages immédiatement les uns après les autres en raison de l'actualisation de la page, etc.

Est-il acceptable de rendre cet index unique?

Répondre

1

UNIQUE est un index et une contrainte en même temps. Si cela doit être unique, plutôt que de le rendre unique. Si vous souhaitez simplement améliorer les performances des requêtes, vous pouvez créer un index non unique sur 2 champs.

+0

N'accélère-t-il pas les résultats de requête ayant un index unique? – ajbeaven

+0

Sûrement c'est le cas. Mais si vous dites 'SenderID' +' DateSent' peut avoir des doublons (je suppose dans de rares circonstances), et c'est acceptable, la création d'un index unique empêchera d'insérer un enregistrement qui viole une contrainte unique. – a1ex07

+0

En théorie, il peut être pratiquement impossible pour quelqu'un d'envoyer 2 messages en une seconde - ie. Après l'envoi du premier message, ils doivent accéder à la page "Créer un message", remplir au moins 50 caractères pour un message valide, sélectionner un destinataire et appuyer sur Envoyer avant que le système ne puisse créer une autre ligne. – ajbeaven

1

Si vous le rendez unique et que votre application fonctionne assez rapidement, vous obtiendrez une violation de clé.

Je ne le rendrais pas unique.

+0

Il n'est certainement pas possible qu'une application Web s'exécute immédiatement? – ajbeaven

+1

Non "Immédiatement", mais dans la résolution du type de colonne DateTime est très possible. Je travaille avec un système qui fait exactement la même chose, sauf que le DateTime est limité à une résolution d'une seconde. C'est vraiment énervant quand le système fonctionne assez vite pour créer plus d'une ligne par seconde. Votre situation est la même, seulement sur une plus petite échelle de temps. –

0

Quel est le but de rendre cet index unique? Je suppose que l'inclusion de DateSent dans l'index ne réduit pas le temps de vos requêtes.

+0

il est trié par le champ DateTime donc je suppose qu'il va le réduire quelque peu. – ajbeaven

+0

Je vois, vous avez raison. Vous pouvez créer un index simple au lieu d'unique dans ce cas. – Fenec

+0

N'accélère-t-il pas les résultats de requête ayant un index unique? – ajbeaven