sql userid + nom + profil optimiser la question

Question

Il y a de fortes chances que je doive faire beaucoup de recherche de nom d'utilisateur et de nom d'utilisateur. Donc je pensais, au lieu d'avoir une table comme ci-dessous

userid int PK 
username text 
userpass_salthash int 
user_someopt1 int 
user_sig text 

de l'avoir rompu comme ci-dessous

//table1 
userid int PK 
username text 

//table2 
userid int //fk 
userpass_salthash int 
user_someopt1 int 
user_sig text 

raisonnement que je voudrais faire est parce que je soupçonne une table moins complexe (i peut également faire des noms plus que 32 octets si je veux) est plus rapide pour les recherches avec moins de données en bonus. Mais je sais que je peux me tromper, quelle version dois-je faire et quelles sont les raisons à côté de l'optimisation?

Answer 1

Vous devez effectuer la première option (table unique) pour la normalisation et les performances.

Performance:

• Si vous mettez un index sur (UserId, Username), vous aurez un indice de couverture - de sorte que vous ne serez jamais besoin d'aller à la table pour obtenir le nom d'utilisateur de toute façon.
• Si vous placez votre index cluster sur UserId, vous obtiendrez une recherche d'index en cluster - qui se terminera quand même sur les données de ligne.

Normalization:

• Votre deuxième option permet à un utilisateur d'exister dans le tableau 1, mais pas table2. Puisque vous ne voulez probablement pas un utilisateur sans mot de passe (qui ne peut pas se connecter), je considérerais cela comme cassé.

Ma suggestion serait un index clusterisé sur UserId. Si vous avez besoin de l'index clusterisé ailleurs, un index de couverture serait presque aussi bon.

Answer 2

Je suis d'accord que pour une table qui se rétrécit, une seule table est presque certainement le meilleur pari.

Encore une chose à ajouter - un type de données texte (si vous utilisez MS SQL Server) est incroyablement large. nvarchar (200) devrait être plus que suffisant. Utilisez les données LOB avec discrétion.

Answer 3

Ne vous inquiétez pas de l'optimisation de cette recherche, à moins que vous ne soyez sûr qu'elle doit l'être. S'il vous plaît rappelez-vous les règles du Club Optmization.

1. La première règle de Optimization Club est, vous ne l'optimisez pas.
2. La deuxième règle de Optimization Club est, vous ne pas optimiser sans mesurer.
3. Si votre application s'exécute plus vite que le protocole de transport sous-jacent, l'optimisation est terminée.
4. Un facteur à la fois.
5. Pas de marketroids, pas d'horaires marketroid.
6. Les tests se poursuivront aussi longtemps qu'il le faudra.
7. Si c'est votre première nuit à Optimization Club, vous devez écrire un test.