Datenbank-Design: Primärschlüssel und viele bis viele Assoziationen

-1

Dies ist mein erstes Datenbank-Design meiner Home-Bibliothek. Ich habe eine Frage darüber, wie man die Primärschlüssel in jeder Tabelle implementiert, ich bin auch daran interessiert zu wissen, ob es akzeptabel ist, viele Tabellen mit einem fremden verknüpft zu haben, wie ich es mit den vielen Beziehungen mit "contributor_id" getan habe.Datenbank-Design: Primärschlüssel und viele bis viele Assoziationen

Link to image of design

Nicht alle meine Tabellen haben einen Primärschlüssel. Wenn ein Primärschlüssel NICHT der Fremdschlüssel sein sollte (wie ich es verstanden habe), was könnte als Primärschlüssel in den Tabellen copy_info und book_info dienen? Ich bin mir nicht sicher, ob ich die Zwischentabellen richtig implementiert habe, wo es viele oder viele Beziehungen gibt. Ist dies eine Situation, in der ich einen zusammengesetzten primären Schlüssel ( ) benötigen sollte?

Vielleicht gibt es unterschiedliche Meinungen darüber, wie dies zu tun ist, aber jede Einsicht wäre willkommen. Wo ich neu bin, bitte entschuldigen Sie, wenn meine Frage nicht spezifisch genug ist.

Quelle

2017-01-02 Kaari Landry

[_Tipps auf optimale Viele-zu-Viele Tabelle design_] (http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table) –

Sie müssen ein College/Universität Intro zu Datenbank-Design lesen. Dann folgen Sie einer Design-Methode daraus. Stellen Sie dann eine spezifische Frage in diesem Zusammenhang. Die Hauptsache hier ist falsch, Sie müssen contributer_id ablegen und Edits (book_id, contributor_id), Illustrates (...), etc. einführen. Aber die Begründung ist ein paar Kapitel des Lehrbuchs. – philipxy

ich war Missverständnis, wie eine viele-implementieren Viele Beziehungen: Sobald ich die Junction-Tabellen eingegeben habe, hatten meine Tabellen alle Primärschlüssel. Updated Design

Quelle

2017-01-05 01:25:51

ich nur geben paar schnelle Hinweise:

Ich verstehe die 4 Tabellen auf der linken Seite sind Vermittler zwischen Tabellen book_info und anderen 4 Tabellen mit Übersetzern Info, Info Autoren und so weiter; habe ich recht? So ist eine Viele-zu-Viele-Beziehungen (ein Buch kann viele Autoren haben und ein Autor hat viele Bücher), aber wenn Sie die Tabellen so einrichten jedes Mal, wenn Sie versuchen, den gleichen Beitrag für ein anderes Buch einfügen wird es verursachen ein doppelter Schlüsselfehler! Also, entfernen Sie die Tasten von dort.
der richtige Weg, um einen Schlüssel zu diesen aggregierten Tabellen zuweisen mit dem Schlüssel zu beiden Werten zuzuordnen sein (so dass Sie nie den „Einzigartigkeit“ Zwang brechen), ABER ist vollständig unuseful (und eine Verschwendung von Speicherplatz und Db-Ressourcen), um Schlüssel in diesen einfachen Aggregattabellen zuzuweisen
Bücher und book_info ist eine Eins-zu-eins-Beziehung? Es ist also sinnvoll, dies in zwei separate Tabellen NUR für die Zwecke der Sauberkeit zu teilen (zum Beispiel wenn Sie viele Felder haben und Sie durch einige logische Kriterien trennen möchten)
Bücher und Book_info ist eine andere Viele-zu-Viele-Beziehung ? In diesem Fall ist das "id" -Feld als Schlüssel eine korrekte Lösung, aber es ist nicht korrekt, die Tabellen books und copy_info zu koppeln (besser, um copy_info mit book_info zu koppeln, so dass Sie es in zwei Eins-zu-viele-Beziehungen aufteilen (einfacher in diesem Fall zu verwalten)

ich hoffe, dass ich ein wenig geholfen, irgendwie, das Sie leicht mit wenig Übung auf dem Feld lösen.

Quelle

2017-01-02 17:39:43 Scare

die Art und Weise, wie dies derzeit eingerichtet ist, kann ich nicht einen Mitwirkenden mit mehreren Büchern aufgrund von Doppelfehlern verbunden haben.Wenn ich Sie richtig verstehe, wenn diese 4 Tabellen überhaupt keine Schlüssel haben, muss ich mich nicht um die Einzigartigkeit kümmern. Ich verstehe Ihren letzten Punkt nicht vollständig, ist es, weil book_info eine Eins-zu-Viele-Beziehung zu copy_info ist (ich kann mehrere Kopien eines Buches besitzen), so dass es die Zwischentabelle der Bücher nicht braucht? EDIT: [wie das?] (Http://imgur.com/a/loXSg) –

Besser! Eins zu viele braucht niemals die Zwischentabelle. Du hast mich verstanden. Über copy_info planen Sie, mehrere Kopien eines Buches zu besitzen, aber wie werden Sie zwischen ihnen unterscheiden? Wenn sie denselben Herausgeber haben, dasselbe pub_date und so weiter? Sie können unterschiedliche Bedingungen haben, aber in diesem Fall sind Ihre Tabellen ohne guten Grund zu kompliziert. – Scare

Ich habe seither einen Primärschlüssel zur copy_info-Tabelle mit dem Namen copy_id hinzugefügt und den Herausgeber in die Tabelle copy_info verschoben. In einigen Fällen habe ich vielleicht mehrere Kopien desselben Buches, aber mit unterschiedlichen Veröffentlichungsdaten (Editionen) oder in verschiedenen Sprachen, so dass für mich eine Eins-zu-Viele-Beziehung zwischen book_info und copy_info sinnvoll ist. Deine Tipps sind erleuchtet, danke schön. –

Datenbank-Design: Primärschlüssel und viele bis viele Assoziationen

Antwort

Verwandte Themen