SQL Server Normalisierung Taktik: varchar vs int Identität

Question

Ich frage mich nur, was die optimale Lösung ist hier.

Sagen, dass ich eine normalisierte Datenbank haben. Der Primärschlüssel des gesamten Systems ist ein VARCHAR. Was ich frage mich ist, sollte ich dieses varchar in einen int für die Normalisierung beziehen oder es verlassen? Es ist einfacher als varchar zu verlassen, aber es könnte mehr optimal sein

Zum Beispiel kann ich

People
======================
name      varchar(10)   
DoB       DateTime    
Height    int  

Phone_Number
======================
name      varchar(10)   
number    varchar(15)

Oder ich könnte

People
======================
id        int Identity   
name      varchar(10)   
DoB       DateTime  
Height    int  

Phone_Number
======================
id        int   
number    varchar(15)  

In mehreren anderen one-to-many-Beziehungen natürlich.

Was tun Sie alle denken? Was ist besser und warum?

Answer 1

Kann man wirklich Namen als Primärschlüssel verwenden? Ist das nicht ein hohes Risiko von mehreren Personen mit dem gleichen Namen?

Wenn Sie wirklich so viel Glück, dass Ihr Name Attribut als Primärschlüssel verwendet werden, dann - mit allen Mitteln - das nutzen. Oft aber, müssen Sie etwas nach oben, wie ein customer_id machen, etc.

Und schließlich: „NAME“ ist ein reserviertes Wort in mindestens einen DBMS, so betrachtet, etwas mit anderer, zum Beispiel Fullname.

Answer 2

Ich glaube, dass die Mehrheit der Menschen, die keine signifikante Größe der realen Welt Datenbankanwendungen entwickelt haben, werden Ihnen sagen, dass Ersatzschlüssel die einzige realistische Lösung.
Ich weiß, dass die akademische Gemeinschaft wird aber damit nicht einverstanden ist der Unterschied zwischen theoretischer Reinheit und Praktikabilität.

Jede vernünftige Größe Abfrage, die Verknüpfungen zwischen Tabellen zu tun hat, die nicht-Ersatzschlüssel verwenden, in denen einige Tabellen schnell zusammengesetzte Primärschlüssel haben werden wartbaren.

Answer 3

Verwendung von jeder Art von nicht-synthetischen Daten (das heißt etwas von dem Benutzer, wie von der Anwendung erzeugten Gegensatz) als PK ist problematisch; Sie müssen über die Kultur / Lokalisierung Unterschiede, Groß- und Kleinschreibung (und andere Fragen abhängig von DB Sortierungs) kümmern, Datenproblemen führen kann, wenn / wenn dieser vom Benutzer eingegebenen Daten jemals ändert, etc.

Die Verwendung von nicht-user-generierten Daten (Sequential GUIDs (oder nicht-sequenziellen wenn Ihr DB nicht unterstützt werden oder Sie kümmern sich nicht um Seite Splits) oder Identität Ints (wenn Sie GUIDs nicht brauchen)) ist viel einfacher und viel sicherer.

In Bezug auf doppelte Daten: Ich sehe nicht, wie unter Verwendung von nicht-synthetischen Schlüssel, die Sie aus, dass schützt. Sie haben noch Fragen, bei denen der Benutzer „Bob Smith“ anstelle von „Bob K. Smith“ oder „Smith, Bob“ oder „Bob Smith“ usw. Die Vervielfältigung Management notwendig ist (und so ziemlich identisch), unabhängig davon, ob Ihr Schlüssel synthetischen eintritt, oder nicht-synthetische und nicht-synthetische Tasten haben eine Vielzahl von anderen möglichen Problemen, dass synthetische Schlüssel ordentlich vermeiden.

Viele Projekte müssen nicht über die (eng beschränkt Sortierungs Entscheidungen vermeiden zum Beispiel viele von ihnen) kümmern, aber im Allgemeinen ziehe ich synthetische Schlüssel. Dies ist nicht zu sagen, dass Sie nicht mit organischen Schlüssel erfolgreich sein kann, klar können Sie, aber für viele Projekte, sie sind nicht die bessere Wahl.

Answer 4

Ich denke, wenn Ihr VARCHAR größer war würden Sie feststellen, das Sie duplizieren einiges an Daten in der gesamten Datenbank. Während, wenn Sie mit einer numerischen ID-Spalte gehen, sind Duplizieren Sie nicht annähernd die gleiche Menge an Daten, wenn Fremdschlüsselspalten zu anderen Tabellen hinzufügen.

Darüber hinaus Textdaten sind eine königliche Schmerz im Hinblick auf Vergleiche, wird Ihr Leben viel einfacher, wenn Sie tun, WHERE id = Benutzer-ID im Vergleich zu WHERE name LIKE inputname ( oder so ähnlich).

Answer 5

Wenn das Feld „Namen“ wirklich angemessen als Primärschlüssel ist, dann mach es. Die Datenbank wird nicht erhält mehr normalisiert durch einen Ersatzschlüssel in diesem Fall zu schaffen. Sie werden einige doppelten Strings für Fremdschlüssel zu bekommen, aber das ist keine Normalisierung Problem, da die Einschränkung FK guarantrees Integrität auf Strings nur, wie es wäre auf Ersatzschlüssel.

Doch erklären Sie nicht, was der „Name“ ist. In der Praxis ist es sehr selten, dass ein String als Primärschlüssel geeignet ist. Wenn es der Name einer Person ist, es wird nicht als PK arbeiten, da mehr als eine Person kann den gleichen Namen haben, die Menschen Namen ändern können und so weiter.

Answer 6

Eine Sache, die andere scheinen nicht erwähnt zu haben, ist, dass tritt auf int Felder sind in der Regel besser ab als auf varchar Felder verbindet.

Und ich würde auf jeden Fall immer einen Ersatzschlüssel verwenden, um über Namen (von Personen oder Unternehmen), weil sie im Laufe der Zeit nie eindeutig sind. In unserer Datenbank zum Beispiel haben wir 164 Namen mit mehr als 100 Instanzen des gleichen Namen. Dies zeigt deutlich die Gefahren des als Schlüsselfeld mit Namen berücksichtigen.

Answer 7

Die ursprüngliche Frage ist nicht eine Normalisierung. Wenn Sie eine normalisierte Datenbank, wie Sie sagen, dann müssen Sie es nicht Gründe für die Normalisierung ändern.

Es gibt wirklich zwei Fragen in Ihrer Frage. Das erste ist, ob oder ints VARCHARs eine bevorzugte für die Verwendung als Primärschlüssel und Fremdschlüssel. Die zweite ist, ob Sie die natürlichen Schlüssel gegeben in der Problemdefinition verwenden können, oder ob Sie einen synthetischen Schlüssel (Ersatzschlüssel) erzeugen soll an die Stelle der natürlichen Schlüssel zu nehmen.

ints sind etwas knapper als Varchars, und ein wenig effizienter für solche Dinge wie Indexverarbeitung. Aber der Unterschied ist nicht überwältigend. Sie sollten wahrscheinlich nicht Ihre Entscheidung allein auf dieser Grundlage machen.

Die von Frage, ob die natürlichen Schlüssel versehen wirklich funktioniert als natürliche Schlüssel oder nicht viel mehr an Bedeutung. Das Problem der Duplikate in einer Spalte „Name“ ist nicht das einzige Problem. Es gibt auch das Problem, was passiert, wenn eine Person ihren Namen ändert. Dieses Problem wahrscheinlich die Oberfläche nicht in dem Beispiel, das Ihnen gegeben haben, aber es in vielen anderen Datenbankanwendungen ist die Oberfläche. Ein Beispiel wäre das Transkript über vier Jahre von allen Kursen von einem Student genommen werden. Eine Frau könnte heiraten und ihren Namen im Laufe von vier Jahren ändern, und jetzt bist du stecken.

Sie haben entweder den Namen unverändert zu lassen, in diesem Fall ist es nicht mehr mit der realen Welt übereinstimmt, oder es rückwirkend aktualisieren in allen Kursen die Person nahm, die die Datenbank mit den gedruckten Plänen gemacht zu der Zeit nicht einverstanden machen.

Wenn Sie auf einem synthetischen Schlüssel entscheiden haben, müssen Sie nun entscheiden, ob die Anwendung wird den Wert des synthetischen Schlüssel für die User-Community offenbaren. Das ist eine andere ganze Dose Würmer und sprengt den Rahmen dieser Diskussion.