sql userid + name + profile optimize question

Question

Die Chancen stehen gut, dass ich eine Menge Userid-> Benutzernamen suchen muss. So denke ich war, sondern eine Tabelle wie die von unter

userid int PK 
username text 
userpass_salthash int 
user_someopt1 int 
user_sig text 

, um es als unten aufgebrochen zu haben

//table1 
userid int PK 
username text 

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

Argumentation ich dies tun würde, ist, weil ich eine weniger komplexe Tabelle vermuten (i kann auch Namen nicht mehr machen dann 32bytes, wenn ich mag) ist schneller für Nachschläge zusammen mit weniger Daten als ein Bonus. Aber ich weiß, dass ich falsch liegen könnte, welche Version sollte ich tun und welche Gründe neben der Optimierung?

Answer 1

Sie sollten die erste Option (einzelne Tabelle) für Normalisierung und Leistung durchführen.

Performance:

• Wenn Sie einen Index auf (UserId, Username) setzen, erhalten Sie einen abdeckenden Index haben - so dass Sie nicht immer an den Tisch gehen müssen sowieso den Benutzernamen zu erhalten.
• Wenn Sie Ihren Clustered-Index auf UserId setzen, erhalten Sie eine Clustered-Index-Suche - die sowieso in den Zeilendaten endet.

Normalisierungs:

• Ihre zweite Option ermöglicht es einem Benutzer in table1 existieren, aber nicht table2. Da Sie wahrscheinlich keinen Benutzer ohne Passwort wollen (der sich nicht einloggen kann), würde ich das als kaputt betrachten.

Mein Vorschlag wäre ein gruppierter Index auf UserId. Wenn Sie den Clustered Index woanders benötigen, wäre ein Covering Index fast genauso gut.

Answer 2

Ich stimme zu, dass für einen Tisch, der schmal ist, ein einzelner Tisch fast sicher die beste Wette ist.

Eine weitere Sache hinzufügen - ein Text-Datentyp (wenn Sie MS SQL Server verwenden) ist schrecklich breit. nvarchar (200) sollte mehr als breit genug sein. Verwenden Sie LOB-Daten mit Diskretion.

Answer 3

Bitte machen Sie sich keine Gedanken über die Optimierung dieses Lookups, es sei denn, Sie sind sicher, dass es sein muss. Bitte beachten Sie die Regeln des Optimisation Club.

1. Die erste Regel von Optimization Club ist, dass Sie nicht optimieren.
2. Die zweite Regel von Optimization Club ist, Sie optimieren nicht ohne zu messen.
3. Wenn Ihre App schneller als das zugrunde liegende Transportprotokoll ausgeführt wird, ist die Optimierung abgeschlossen.
4. Ein Faktor nach dem anderen.
5. Keine Marketroids, keine Marketroid-Zeitpläne.
6. Testen wird so lange wie es sein muss.
7. Wenn dies Ihre erste Nacht im Optimization Club ist, müssen Sie einen Testfall schreiben.