it-swarm.com.de

Wann sollte ich eins zu eins Beziehung verwenden?

Sorry für diese Noob-Frage, aber gibt es wirklich eine Notwendigkeit, eine Eins-zu-Eins-Beziehung zu Tabellen in Ihrer Datenbank zu verwenden? Sie können alle erforderlichen Felder in einer Tabelle implementieren. Selbst wenn die Daten sehr groß werden, können Sie die Spaltennamen auflisten, die Sie in der SELECT-Anweisung benötigen, anstatt SELECT * zu verwenden. Wann brauchen Sie diese Trennung wirklich?

68

1 bis 0..1

  • Die "1 bis 0..1" zwischen Ober- und Unterklassen wird als Teil der Strategie "Alle Klassen in separaten Tabellen" für Implementieren der Vererbung verwendet.

  • Eine "1 bis 0..1" kann in einer einzigen Tabelle dargestellt werden, wobei der Teil "0..1" von NULL-fähigen Feldern abgedeckt wird. Wenn die Beziehung jedoch meistens "1 zu 0" mit nur wenigen "1 zu 1" -Zeilen ist, kann das Aufteilen des "0..1" -Abschnitts in eine separate Tabelle etwas Speicher- (und Cache-Leistung) einsparen ) Leistungen. Einige Datenbanken sind beim Speichern von NULL sparsamer als andere, daher kann ein "Grenzwert", an dem diese Strategie realisierbar ist, erheblich variieren.

1 zu 1

  • Das echte "1 zu 1" partitioniert die Daten vertikal, was Auswirkungen auf das Caching haben kann. Datenbanken implementieren Caches normalerweise auf Seitenebene, nicht auf der Ebene einzelner Felder. Wenn Sie also nur wenige Felder aus einer Zeile auswählen, wird normalerweise die gesamte Seite, zu der die Zeile gehört, zwischengespeichert. Wenn eine Zeile sehr breit ist und die ausgewählten Felder relativ schmal sind, werden im Endeffekt viele nicht zwingend erforderliche Informationen zwischengespeichert. In einer solchen Situation kann es sinnvoll sein, die Daten vertikal zu partitionieren, so dass nur der schmalere, häufiger verwendete Teil oder die Zeilen zwischengespeichert werden, sodass mehr von ihnen in den Cache passen können, wodurch der Cache effektiv größer wird ".

  • Eine andere Anwendung der vertikalen Partitionierung besteht darin, das Sperrverhalten zu ändern: Datenbanken können normalerweise nicht auf der Ebene einzelner Felder sperren, sondern nur die gesamten Zeilen. Durch das Aufteilen der Reihe lassen Sie zu, dass nur eine der beiden Hälften gesperrt wird.

  • Trigger sind normalerweise auch tabellenspezifisch. Während Sie theoretisch nur eine Tabelle haben können und der Auslöser die "falsche Hälfte" der Zeile ignorieren kann, können einige Datenbanken zusätzliche Beschränkungen für das, was ein Auslöser kann und nicht kann, auferlegen, was dies unpraktisch machen könnte. Zum Beispiel lässt Oracle die Mutationstabelle nicht modifizieren. Wenn Sie separate Tabellen verwenden, kann nur eine von ihnen mutieren, sodass Sie die andere noch von Ihrem Trigger aus ändern können.

  • Separate Tabellen ermöglichen möglicherweise eine differenziertere Sicherheit.

Diese Überlegungen sind in den meisten Fällen irrelevant. In den meisten Fällen sollten Sie die "1 zu 1" -Tabellen in einer einzigen Tabelle zusammenführen.

82

Wenn sich Daten in einer Tabelle auf die von der anderen beschriebenen Entität beziehen, aber nicht zu dieser gehören, ist dies ein Kandidat, um sie getrennt zu halten.

Dies könnte in Zukunft Vorteile bieten, wenn die separaten Daten auch mit einer anderen Entität verknüpft werden müssen.

15
Sepster

Wenn Sie zwei eins-zu-eins-Tabellen in einer platzieren, haben Sie wahrscheinlich ein Problem mit der Semantik. Wenn beispielsweise jedes Gerät über eine Fernbedienung verfügt, klingt es nicht gut, das Gerät und die Fernbedienung mit ihren verschiedenen Eigenschaften in einer Tabelle zu platzieren. Möglicherweise müssen Sie sogar herausfinden, ob ein bestimmtes Attribut zum Gerät oder zur Fernbedienung gehört.

Es kann Fälle geben, in denen die Hälfte Ihrer Säulen für längere Zeit leer bleibt oder nie ausgefüllt wird. Ein Auto könnte beispielsweise einen Anhänger mit einer Reihe von Merkmalen oder keine besitzen. Sie haben also viele ungenutzte Attribute.

Wenn Ihre Tabelle 20 Attribute hat und nur vier davon gelegentlich verwendet werden, ist es sinnvoll, die Tabelle aus Leistungsgründen in 2 Tabellen aufzuteilen. 

In solchen Fällen ist es nicht gut, alles in einer Tabelle zu haben. Außerdem ist es nicht leicht, mit einer Tabelle mit 45 Spalten zu arbeiten!

11
superM

Meine 2 Cent.

Ich arbeite an einem Ort, an dem wir alle eine große Anwendung entwickeln, und alles ist ein Modul. Wir haben beispielsweise eine users-Tabelle und ein Modul, das einem Benutzer facebook-Details hinzufügt, ein weiteres Modul, das einem Benutzer Twitter-Details hinzufügt. Wir könnten uns entscheiden, eines dieser Module zu entfernen und alle Funktionen aus unserer Anwendung zu entfernen. In diesem Fall fügt jedes Modul der globalen users-Tabelle eine eigene Tabelle mit 1: 1-Beziehungen hinzu.

create table users ( id int primary key, ...);
create table users_fbdata ( id int primary key, ..., constraint users foreighn key ...)
create table users_twdata ( id int primary key, ..., constraint users foreighn key ...)
10
santiago arizti

Der sinnvollste Zeitpunkt, um dies zu nutzen, wäre, wenn es zwei getrennte Konzepte gibt, die sich immer nur auf diese Weise beziehen. Zum Beispiel kann ein Auto nur einen aktuellen Fahrer haben, und der Fahrer kann immer nur ein Auto gleichzeitig fahren - die Beziehung zwischen den Konzepten Auto und Fahrer würde also 1 zu 1 sein. Ich akzeptiere, dass dies ein Beispiel ist, um das zu demonstrieren Punkt.

Ein weiterer Grund ist, dass Sie ein Konzept auf verschiedene Arten spezialisieren möchten. Wenn Sie über eine Personentabelle verfügen und das Konzept der verschiedenen Personentypen hinzufügen möchten, z. B. Mitarbeiter, Kunden, Anteilseigner, müssen für jede einzelne Daten unterschiedliche Datensätze verwendet werden. Die Daten, die zwischen ihnen ähnlich sind, befinden sich in der Personentabelle, die Fachinformationen in den spezifischen Tabellen für Kunden, Anteilseigner und Mitarbeiter.

Einige Datenbank-Engines haben Schwierigkeiten, einer sehr großen Tabelle (viele Zeilen) effizient eine neue Spalte hinzuzufügen, und ich habe gesehen, dass Erweiterungstabellen die neue Spalte enthielten, und nicht die neue Spalte, die der ursprünglichen Tabelle hinzugefügt wurde. Dies ist eine der verdächtigsten Anwendungen zusätzlicher Tabellen.

Sie können auch entscheiden, die Daten für ein einzelnes Konzept aus Leistungs- oder Lesbarkeitsproblemen auf zwei verschiedene Tabellen aufzuteilen. Dies ist jedoch ein vernünftiger Sonderfall, wenn Sie bei Null anfangen - diese Probleme werden sich später zeigen.

9
Fenton

nicht sehr häufig.

wenn Sie Sicherheitsaspekte implementieren müssen, ist möglicherweise ein Vorteil von Bedeutung. Einige Benutzer können einige Spalten (table1) sehen, andere jedoch nicht (table2).

natürlich können einige Datenbanken (Oracle) diese Art von Sicherheit in derselben Tabelle ausführen, andere jedoch nicht.

5
Randy

Sie beziehen sich auf die Datenbank-Normalisierung. Ein Beispiel, das mir in einer von mir gewarteten Anwendung einfällt, ist Items. Die Anwendung ermöglicht es dem Benutzer, viele verschiedene Arten von Artikeln zu verkaufen (z. B. InventoryItems, NonInventoryItems, ServiceItems usw.). Während ich alle für jedes Element erforderlichen Felder in einer Elementtabelle speichern konnte, ist es viel einfacher zu verwalten, dass eine Basiselementtabelle vorhanden ist, die Felder enthält, die allen Elementen gemeinsam sind, und dann separate Tabellen für jeden Elementtyp (z. B. Inventar, etc ..), die nur für diesen Artikeltyp spezifische Felder enthalten. Dann hätte die Artikeltabelle einen Fremdschlüssel für den bestimmten Artikeltyp, den sie darstellt. Die Beziehung zwischen den einzelnen Artikeltabellen und der Basis-Artikeltabelle wäre eins zu eins.

Nachfolgend finden Sie einen Artikel zur Normalisierung.

http://support.Microsoft.com/kb/283878

4
Grasshopper

Wie bei allen Designfragen lautet die Antwort "es kommt darauf an." 

Es gibt einige Überlegungen: 

  • wie groß wird die Tabelle (sowohl in Feldern als auch in Zeilen)? Es kann unbequem sein, den Namen und das Kennwort Ihrer Benutzer mit anderen, weniger häufig verwendeten Daten aus Wartungs- und Programmierungssicht zu versehen

  • felder in der kombinierten Tabelle, die Einschränkungen aufweisen, können im Laufe der Zeit umständlich werden. Wenn zum Beispiel ein Auslöser für ein bestimmtes Feld ausgelöst werden muss, wird dies bei jeder Aktualisierung der Tabelle geschehen, unabhängig davon, ob dieses Feld betroffen war. 

  • wie sicher sind Sie, dass die Beziehung 1: 1 sein wird? Wie Diese / Frage weist darauf hin, dass Dinge schnell kompliziert werden können. 

3
Rob Allen

Ein anderer Anwendungsfall kann der folgende sein: Sie können Daten aus einer beliebigen Quelle importieren und täglich aktualisieren, z. Informationen zu Büchern. Dann fügen Sie selbst Daten zu einigen Büchern hinzu. Dann ist es sinnvoll, die importierten Daten in einer anderen Tabelle als Ihre eigenen Daten abzulegen.

3
Dirk

Normalerweise begegne ich in der Praxis zwei allgemeinen Arten von 1: 1-Beziehungen:

  1. IS-A-Beziehungen, auch als Supertyp-/Subtyp-Beziehungen bezeichnet. Dies ist, wenn eine Art von Entität tatsächlich eine Art von Entität ist (EntityA IS A EntityB). Beispiele:

    • Personeneinheit mit separaten Einheiten für Buchhalter, Ingenieur, Verkäufer innerhalb derselben Firma.
    • Elemententität mit separaten Entitäten für Widget, RawMaterial, FinishedGood usw.
    • Fahrzeugeinheit mit separaten Einheiten für LKW, Limousine usw.

    In all diesen Situationen hätte die Supertyp-Entität (z. B. Person, Artikel oder Fahrzeug) die Attribute, die allen Untertypen gemeinsam sind, und die Untertypen-Entitäten hätten Attribute, die für jeden Subtyp eindeutig sind. Der Primärschlüssel des Untertyps wäre derselbe wie der des Supertyps.

  2. "Boss" Beziehungen. Dies ist, wenn eine Person der eindeutige Chef oder Manager oder Vorgesetzter einer Organisationseinheit (Abteilung, Firma usw.) ist. Wenn für eine Organisationseinheit nur ein Chef zulässig ist, besteht eine 1: 1-Beziehung zwischen der Personenentität, die den Chef vertritt, und der Organisationseinheit.

2
Tripartio

Erstens denke ich, es ist eine Frage der Modellierung und Definition, was eine separate Einheit besteht. Angenommen, Sie haben customers mit einem und nur einem einzigen address. Natürlich können Sie alles in einer einzigen Tabelle implementieren customer, aber wenn Sie ihm in Zukunft erlauben, 2 oder mehr Adressen zu haben, müssen Sie dies umgestalten (kein Problem, aber treffen Sie eine bewusste Entscheidung ).

Ich kann mir auch einen interessanten Fall vorstellen, der in anderen Antworten nicht erwähnt wurde und in dem das Aufteilen der Tabelle nützlich sein könnte:

Stellen Sie sich noch einmal vor, Sie haben customers mit jeweils einem address, aber dieses Mal ist es optional, eine Adresse zu haben. Natürlich können Sie das als eine Reihe von NULL -fähigen Spalten wie Zip,state,street Implementieren. Angenommen, Sie haben haben eine Adresse, der Status ist nicht optional, die Postleitzahl jedoch. Wie modelliere ich das in einer einzelnen Tabelle? Sie könnten eine Einschränkung für die Tabelle customer verwenden, aber es ist viel einfacher, sie in eine andere Tabelle aufzuteilen und den Fremdschlüssel auf NULL zu setzen. Auf diese Weise wird Ihr Modell deutlicher, wenn Sie sagen, dass Entitätaddress optional ist und dass Zip ein optionales Attribut dieser Entität ist.

1
polvoazul

In meiner Programmierzeit bin ich nur in einer Situation darauf gestoßen. Dies ist der Fall, wenn zwischen den beiden Entitäten ("Entity A" und "Entity B") eine 1-zu-Viele-Beziehung und eine 1-zu-1-Beziehung besteht.

Wenn "Entity A" mehrere Entity B hat und "Entity B" nur 1 "Entity A" Und "Entity A" hat nur 1 Strom "Entity B" und "Entity B" hat nur 1 "Entität A".

Zum Beispiel kann ein Auto nur einen aktuellen Fahrer haben, und der Fahrer kann jeweils nur ein Auto fahren. Die Beziehung zwischen den Konzepten Auto und Fahrer würde also 1 zu 1 sein. - Dieses Beispiel habe ich der Antwort von @Steve Fenton entlehnt

Wo ein Fahrer mehrere Autos fahren kann, nur nicht zur gleichen Zeit. Die Entitäten Car und Driver sind also 1-zu-viele oder viele-zu-viele. Wenn wir jedoch wissen müssen, wer der aktuelle Treiber ist, dann brauchen wir auch die 1: 1-Beziehung.

0
Jo Smo

Ein anderer Anwendungsfall könnte der Fall sein, wenn die maximale Anzahl von Spalten in der Datenbanktabelle überschritten wird. Dann könnten Sie mit OneToOne eine andere Tabelle verbinden

0
db303