Eindeutige ID zwischen mehreren Tabellen geteilt sql 2008

Question

Ich habe ein Problem mit meiner Website. Die Website hat mehrere Entitäten: Artikel, Beiträge, Reviews ... orund 6 Arten. Jetzt führe ich die Möglichkeit für einen Benutzer ein, einen Artikel zu bewerten (es kann eine dieser Entitäten sein)

Ich habe eine Tabelle erstellt Votes (int Id Primärschlüssel, int ItemId, nvarchar (30) Ip, datetime Zeitstempel, int VoteValue). Hier werde ich alle Stimmen und ihre ips speichern.

Mein Problem ist, dass ich ItemID eindeutig haben muss ... aber meine Datenbank hat bereits verschiedene Typen mit der gleichen ID. Alle Tabellen haben die IDs von 0 an gestartet. Welche Möglichkeiten sehen Sie für mein Design, um alle Stimmen in einer Tabelle speichern zu können?

Answer 1

Ihr Ansatz versucht, dem Feld "ItemId" mehrere Bedeutungen zuzuweisen, die zu den Problemen führen, denen Sie begegnen. Wenn ich "9500" in diesem Bereich sehen würde, woher soll ich wissen, was das bedeutet?

Ich würde vorschlagen, das ItemId-Feld fallen zu lassen und "Zebrastreifen" -Tabellen zwischen den Stimmen und den anderen Entitäten zu erstellen.

Zum Beispiel Ihre Entitäten:

+-----------+ 
| Articles | 
+-----------+ 
| ArticleId | PK 
| ~ snip ~ | 
+-----------+ 

+-----------+ 
| Posts  | 
+-----------+ 
| PostId | PK 
| ~ snip ~ | 
+-----------+ 

... etc ....

Ihre Stimmen Tabelle:

+-----------+ 
| Votes  | 
+-----------+ 
| VoteId | PK 
| ~ snip ~ | 
+-----------+ 

Ihre "Zebrastreifen" Tabellen:

+--------------+ 
| ArticleVotes | 
+--------------+ 
| ArticleId | PK, FK to Articles 
| VoteId  | PK, FK to Votes 
+--------------+ 

+--------------+ 
| PostVotes | 
+--------------+ 
| PostId  | PK, FK to Posts 
| VoteId  | PK, FK to Votes 
+--------------+ 

Beachten Sie, dass in Ihrem Zebrastreifen Tabellen, würden Sie einen zusammengesetzten Primärschlüssel erstellen, der aus den FK-Referenzen zu den entsprechenden Entitäten besteht, wodurch die Eindeutigkeit sichergestellt wird.

Meiner Erfahrung nach ist dies ein geeigneter normalisierter Ansatz für die von Ihnen beschriebene Domäne.

Bei der Abfrage, um die Stimmen für die Artikel (zum Beispiel) einfach INNER JOIN Artikel durch ArticleVotes zu Stimmen. Um alle Stimmen zu erhalten, fragen Sie einfach nach Abstimmungen.

Darüber hinaus würde ich vorschlagen, eine IPAddresses-Tabelle und FKing zu diesem in Ihrer Tabelle "Votes" zu erstellen, um die Redundanz zu reduzieren.

Answer 2

Eine Option, die nicht erwähnt wurde, waren GUIDs. Wenn Sie GUIDs in Ihren Artikeln/Posts/Reviews/etc. Anstelle der int-Primärschlüssel könnten Sie sich darauf verlassen, dass diese eindeutig sind. Ich sage nicht, dass dies die Route ist, die Sie verwenden sollten, da sie zusätzlichen Overhead zum Speichern/Suchen von GUIDs anstatt von Ints hinzufügen kann.

Ich würde empfehlen, das Feld type der votes-Tabelle hinzuzufügen und es Teil des Schlüssels zu sein. Es hört sich so an, als hättest du schon über diese Idee nachgedacht, bist aber besorgt über die Leistung. Wenn Sie sich Sorgen um die Leistung machen, führen Sie einige Tests durch, um sicherzustellen, dass die Tabellenabfragen Ihren Anforderungen entsprechen, bevor Sie die Änderungen in Produktion umsetzen.

Answer 3

Eine Möglichkeit besteht darin, Ihre verschiedenen Tabellen in einen Typ/Subtypsatz zu konvertieren. Eine Diskussion hierzu findet sich here. Der (vielleicht beträchtliche) Nachteil besteht darin, dass Sie alle Ihre Tabellen umgestalten müssen ... aber dann würde eine ID (vielleicht "ItemId?") Verwendet werden, um alle Ihre Artikeltypen eindeutig zu identifizieren.