Schwarzes Brett - Datenbankoptimierung

.
22.3. Zu verstehen warum, ist überhaupt kein Problem. Nur Kinder befolgen blind einfache Regeln, und Sie gehören sicher nicht dazu.
.
23. Bestätigt:users.total_bulletins ist überflüssig; es kann abgeleitet werden. Entfernt.
.
24. Alle Ihre PKs sind IDs. Sind Sie es noch nicht leid, sich im Code zu verlieren? Vergessen Sie das Anhängen von Id iot PKs für alles, was sich bewegt, lassen Sie uns herausfinden, wie Ihre Benutzer Identifizieren Sie ihre Einheiten; welche Entitäten wirklich unabhängig sind und welche anderen von unabhängigen Entitäten abhängig sind.

24.1. Verwenden Sie niemals Id oder irgendeine solche Form. Wenn es sich um eine PK handelt, verwenden Sie das vollständige Formular.

24.2. Rufen Sie location_id, location_id auf, wo auch immer es ist, einschließlich der PK-Tabelle. Die Ausnahme ist, wenn Sie die Rolle zeigen müssen. Dies wird im Datenmodell deutlich.
.
25. Sie haben keine deklarative referenzielle Integrität, keine definierte Fremde Schlüssel. Das sind aus vielen verschiedenen Gründen schlechte Nachrichten. Sobald diese Fragen geklärt sind, fügen Sie sie bitte hinzu. DRI bedeutet, dass so viel wie möglich, wenn nicht alles, Integrität in SQL deklariert wird. Der ISO/IEC/ANSI-SQL-Standard lässt dies zu, aber die Freeware-Seite des Marktes bietet den Standard nicht und holt langsam auf. Dies bedeutet, dass der Server das Hinzufügen einer Zeile in der FK-Tabelle nicht zulässt, es sei denn, der PK ist in der übergeordneten Tabelle vorhanden. MySQL hat kürzlich DRI für Fremdschlüssel bereitgestellt. Informationen zu FKs finden Sie unter ▶ diesen Artikel◀ .

25.1. Für CHECK-Einschränkungen und REGELN müssen Sie diese im Code implementieren.

Meine Fremdschlüssel sind wie folgt:users-id(fk) =users.id(pk) Ich bin mir nicht sicher, wie ich sie hinzufügen soll, außer dem, was ich getan habe, aber ich werde es sicherlich tun, sobald ich weiß, wie es geht.

Fünfundzwanzig. Kommentare notiert. Ich bin kein MySQL-Spezialist. Ja, das sind die Probleme, die Sie für sich selbst herausfinden müssen. Im Allgemeinen ist MySQL nach meiner Lektüre beinlos; Für alles, was mit SQL zu tun hat, brauchen Sie InnoDB.

.
27. Gegeben:Ich habe die Sortieranforderungen für Bulletins überarbeitet. Benutzer könnten chronologisch sortieren - einfach, macht Sinn. Benutzer können Bulletins nach dem Datum der letzten Antwort auf das Bulletin sortieren. Dann können wir den Rang vergessen und es sollte wirklich einfach sein, Bulletins chronologisch nach dem Zeitpunkt ihrer letzten Antwort zu sortieren? Was sind Ihre Gedanken.

Offene Probleme

(Null)

Datenmodell

Ok, vorausgesetzt, Sie haben keine Probleme mit der ERD und implementieren alle geschlossenen Probleme, habe ich die Daten modelliert und ein fünftes Datenmodell 09. Dez. 10 vorbereitet für Deinem Bericht. Ich brauche definitiv viel mehr Feedback, Fragen usw. dazu. Ich habe Schwierigkeiten zu akzeptieren, dass es getan ist. Wahrscheinlich ist es am besten, echten Code für Ihre Problembereiche zu schreiben.

Links

▶Link zur IDEF1X-Notation◀ Sie müssen dies wirklich lesen und verstehen, bevor Sie das Datenmodell lesen.

▶Link zu Daten des fünften Bulletins Modell◀ Das Entity-Relationship-Diagramm befindet sich auf der ersten Seite, gefolgt vom Datenmodell .

• Die Schlüssel sind ziemlich direkt IDEF1X (mit Ausnahme der UserId, die ich als Kontrapunkt angegeben habe); was Geldbeutel-Relational-Keys bedeutet. Unerweitert und nicht für physikalische Überlegungen optimiert. Bevor Sie sich dagegen wehren, bemerken Sie sie zuerst, registrieren Sie sie und bewerten Sie sie. Natürlich können wir hinzufügen Id iot-Schlüssel, aber bevor wir das tun, stellen wir sicher, dass wir verstehen, was wir verlieren werden.

• Beachten Sie die Bezeichner (durchgezogene Linien) gemäß dem Notationsdokument. Die Wirbelsäule, die Wirbel des Systems, ist Location ... Bulletin ... Response .

• Beachten Sie, dass Schlüssel tatsächlich viele Geschäftsregeln implementieren.

• Beachten Sie die natürliche Hierarchie, die ich gerendert habe. Prüfen Sie, ob es für Sie eine Bedeutung hat.

• Die VerbPhrases sind wirklich wichtig; sehen, ob sie etwas bedeuten.

Kommentare zum ersten Datenmodell und Antworten

Eine Frage, die ich habe, ist, dass der Primärschlüssel des Standorts verwendet wird, um den untergeordneten Primärschlüssel zu bilden? (Sie sind durch eine durchgezogene Linie verbunden). Ich verstehe dieses Konzept nicht wirklich.

• Was ist eine gute Kennung für Bulletins? , was verwenden Ihre Benutzer normalerweise, um ein Bulletin zu identifizieren ...
• "Hast du gestern das Bulletin von Virginia FO gesehen?",
• "Sally aus Washington schreibt sicher gute Bulletins" usw.

oder warum besteht diese Beziehung nicht zwischen dem Benutzer und dem Bulletin?

• Wie weiter oben angegeben, werde ich, da ich jetzt die Bewertung als Tabelle gezeigt habe und wie das Rendering aussehen würde, es einmal entfernen

• Ich denke, die Berechtigung sollte eine Entität sein.

• Bulletin PK ist jetzt (StateCode, Town, UserId, SequenceNo) . Um es klar zu sagen, SequenceNo liegt innerhalb von StateCode, Town, UserId :Es wird 5 für Sallys 5. Bulletin bezüglich MO/Billngs FO sein.

• Beachten Sie, dass Benutzereinstellungen BulletinsPerPage usw. sind 1::1 mit User , sie befinden sich also in User; untergeordnete Tabelle wäre falsch.

• Tippfehler korrigiert.

Kommentare zum zweiten Datenmodell und Antworten

• Die PKs für beide Bulletin und Response wurden geändert, um (7) widerzuspiegeln. BulletinNo und ResponseNo wurden durch BulletinDate ersetzt und ResponseDate (früher CreatedDate ), um mehrere Antworten pro User zu ermöglichen pro Bulletin .

Kommentare zum dritten Datenmodell und Antworten

Vertrauen Sie darauf, dass Sie eine gute Pause hatten.

1. Vor mindestens 30 Jahren (soweit ich weiß) hatten die Giganten der Branche diese Debatte. Namen stehen immer im Singular. Tabellen sind Substantive. VerbPhrasen sind Verben. Dies beschränkt sich nicht auf Namenskonventionen für Datenbanken, sondern gilt für Dokumente, Thesen, Dissertationen usw. Sie können am Ende des Dokuments 5 Schlussfolgerungen haben, aber den Abschnitts- oder Kapiteltitel sowohl im Inhaltsverzeichnis als auch oben auf der Seite ist "Abschluss".

   Nachdem ich sie während der ganzen Uni bekämpft hatte, gab ich es als Verschwendung auf, sobald ich meinen ersten bezahlten Programmierjob antrat und die Bedeutung der Regeln in der realen Welt sah, im Gegensatz zu den theoretischen Auseinandersetzungen, die wir im College hatten von Zeit. All die Zeit und Energie, die ich verschwendete, wurde für produktive Arbeit freigesetzt. Seitdem hinterfrage ich die Riesen nicht mehr; Ich akzeptiere einfach. Dass ihr Verstand größer ist als meiner. Es ist wie das Akzeptieren von Standards oder das Verhalten innerhalb des Gesetzes oder Gottes. Ich habe keine wirklich, wirklich guten Gründe, irgendetwas Illegales zu tun.

   Jedenfalls kann die durch solche Regeln unterstützte Leichtigkeit des Sprachgebrauchs (Diskussion, SQL, Dokumentation) nicht hinreichend erklärt werden; wenn Sie mehr und mehr SQL-Code schreiben, wird es klar.

   Sie können immer verwenden, was Sie wollen. Ich liefere nur Singular.

2. Für mich in Ordnung.

   Aber Sie müssen bedenken, dass diese beiden Elemente in der identifizierten Sequenz (auch bekannt als Non-PK Unique Index oder Alternate Key) allgemein erforderlich sind, um die Einzigartigkeit für eine Person herzustellen. Das Entfernen führt zu zwei Dingen. Erstens können Sie die Eindeutigkeit von Users nicht mehr erkennen (und somit können Sie doppelte Zeilen haben). Zweitens wird das AK nicht eindeutig, ein Inversionseintrag.

3. Der Punkt ist (im Gegensatz zu einem der Beiträge), jede Spalte, die 1::1 mit dem User ist PK, sollte sich in User befinden . Alle Voreinstellungen. Seit wir dieInterestedLocations aufgeräumt haben undInterestedCategories , ich kenne nur nur BulletinsPerPage verbleibend; aber ich bin mir sicher, dass es noch andere gibt. IsPreference2 ist ein Bsp. eines booleschen Werts;NumPreference3 ist ein Bsp. einer Ganzzahl. Etc. Sie können mir sagen, was die wirklichen Einstellungen sind.

   (Lassen Sie uns das im Plural versuchen:... jede Spalte, die 1::1 mit den Users ist PK, sollte sich in User befinden . Tut es einfach nicht für mich, ich hänge an dem gebrochenen Englisch und ich bin ein bisschen wertvoll in Bezug auf meine Muttersprache.)

   Datenmodell aktualisiert.

4. Exzellent. Lassen Sie es mich wissen, wenn Sie sich damit wohlfühlen, und ich gebe Ihnen das physikalische Modell.

   Wie wäre es mit den VerbPhrasen?

Kommentare zum 06. Dez. 10, 20:38 Uhr EST (kleine Aktualisierungen)

.
28. Wo PK nur einmal als FK vorkommt, ist der FK-Spaltenname natürlich derselbe wie der PK-Spaltenname. Wenn es jedoch mehr als eine Besetzung des FK gibt (siehe ResponseRating ), gibt es drei UserIds ), müssen wir sie unterscheiden. In der IDEF1X-Terminologie wird dies Rollen genannt. Die Rolle des User der das Bulletin herausgegeben hat ist Issuer , und so weiter. Offensichtlich ist es besser, diesen Namen zu verwenden und ihn in der gesamten Hierarchie konsistent zu halten (nicht UserId im Bulletin und dann, wenn wir zu Response kommen , wo es zwei gibt und eine Unterscheidung verlangt wird, ändern Sie es in IssuerId . Ich dachte, Sie könnten damit ein Problem haben; In den frühen Stadien ist die Verwendung Issuer.UserId damit eindeutig ist, dass es sich um UserId handelt als FK, und die Rolle ist Issuer; Wenn wir zum physischen Modell kommen, wird es zu IssuerId vereinfacht .

Ebenso haben wir viele DateTime-Spalten (abgekürzt Date, wenn Sie so wollen; sonst Dtm), die differenziert werden müssen.
.
29. Hat die IDEF1X-Notationsdokumentation keinen Sinn gemacht?

• Der PK für jede Tabelle steht in der angegebenen Reihenfolge über der Zeile.
• Denken Sie daran, dass wir die PKs der übergeordneten Tabellen sowieso tragen und, wenn es eine Bedeutung gibt, diese FKs verwenden, um die untergeordneten PKs zu bilden.

• Für Bulletin :

  • Der Ort FK (StateCode, Town) für die es ausgestellt wird
  • Die UserId des Emittenten
  • und DateTime, zu der es ausgestellt wurde, um es eindeutig zu machen.
  • daher (StateCode, Town, IssuerId, BulletinDate)`

• Um alle ResponseRatings zu löschen für dieses Bulletin , verwenden Sie WHERE = auf diesen vier Bulletin Säulen.

.
30. Weil (State, Town) ist der PK von Location , überall hin mitnehmen. Und es ist Teil des Bulletin PK, also tragen alle abhängigen Tabellen diese Spalten, weil sie das Bulletin tragen PK.

Wir hatten zuvor diesen (State, Town) identifiziert ist die PK, ich lasse das so wie es ist Siehe (38) für Änderungen.

.
33. Diskussion wert. Ja, wenn Sie es anzeigen, wenn Sie (zB) Responses anzeigen , und die Benutzer verstehen UserName . Nein, wenn es 30 Bytes sind, und es gibt auch eine eindeutige 4-Byte-UserId . Die Idee ist, diese Entscheidungen bewusst zu treffen und sich bewusst zu machen, was Sie aufgeben, wenn Sie schließlich entscheiden, dass ein 6-Spalten-30-Byte-Schlüssel zu umständlich ist, um ihn auf die Kinder zu migrieren.

• Ich habe eingangs gesagt, ich würde UserId verwenden als typische Id Pk, weil es in mehrere untergeordnete Tabellen übertragen/migriert wird.
• Wie das erstellt wird, können wir für später aufheben. Aber es ist ein reines Surrogate PK.

.
34. Kein Problem. Category hat es schon. Ich ändere Order zu ListOrder .

.
35. Sicher. Nach allem, was ich gelesen und gehört habe, bin ich damit sehr zufrieden. Aber ich würde mir mehr Hin und Her wünschen, um etwas Selbstvertrauen zu erreichen, bevor Sie Code schreiben. Betrachten Sie es alternativ als Lernerfahrung und akzeptieren Sie, dass sich das Modell und der Code später ändern können. Möchten Sie, dass ich jetzt das Physische produziere? Wenn Sie mir alle Korrekturen geben, werde ich die nächste Version veröffentlichen. Ich erwarte Einstellungen in User . Gehen Sie außerdem schnell die Funktionen durch und überprüfen Sie, ob Sie alle Spalten haben, die Sie benötigen.

Schauen Sie sich einige der anderen Antworten zum Zwecke des Lernens und Interesses an.

.
36. Schließt sich an. Sie treten einfach auf four bei drei Spalten statt einer. SQL ist umständlich mit Joins, und die neue Syntax, die es einfacher machen sollte, ist tatsächlich umständlicher. Meine Programmierer schreiben nie Joins:Wir sparen Zeit und Tippfehler. Ich habe eine Prozedur, die bei zwei oder mehr Tabellen den Code mit allen Spalten und Joins generiert. Ich weiß nicht genug von MySQL, um das für Sie umzuwandeln.

Datenmodell aktualisiert.
.

Kommentare zum 08.12.10 20:49, Viertes Datenmodell und Antworten

.
Überprüfen Sie den vorherigen Abschnitt direkt darüber, es gibt kleine Aktualisierungen.

IDEF1X:Ihre Geschwindigkeit ist in Ordnung.

Beachten Sie das Kind immer "erbt" die Eltern-PK als FK (entweder durchgezogene oder unterbrochene Linie), ansonsten besteht keine Beziehung zwischen ihnen. Indem wir diese ohnehin im Kind vorhandenen Spalten verwenden, um das Kind-PK zu bilden, tragen wir die Bedeutung (und das ist der Unterschied zwischen fest und gebrochen). Und somit müssen wir nicht nach einem unabhängigen Identifikator für das Kind suchen. Die Beziehungskraft dieser Methode wird später beim Programmieren deutlich.

Der Abschnitt, mit dem wir uns befassen, befasst sich mit Identifikatoren :natürlich vs. unnatürlich; sinnvoll gegen sinnlos. Später werden Sie sehen, wie wir die relationale Fähigkeit der Engine nutzen können, wenn die Kind-PK aus der Eltern-PK gebildet wird. (Ist Ihr Nachname nicht derselbe wie der Ihres Vaters?)

Es ist auch wichtig, relationale Datenbanken und ihre Fähigkeiten zu verstehen. Das geht verloren, wenn wir uns der Datenbank (zB) aus einer OO-Perspektive nähern und sie als Ort behandeln, um unsere Klassen "persistent" zu machen. Daher werden wir versuchen, relationale Begriffe zu lernen und zu verwenden. Es wird schwierig, wenn Sie nach Frankreich gehen und erwarten, dass sie Amerikanisch sprechen und die gleiche Währung verwenden; Lernen Sie 10 Wörter Französisch zu sprechen, und Sie werden mit offenen Armen empfangen, und Sie werden eine ganz andere Erfahrung mit den Einheimischen machen.

Fahren Sie auf jeden Fall mit der Implementierung des Modells fort. Stellen Sie sich nur vor, dass wir wahrscheinlich irgendwann eine Änderung vornehmen werden. Speichern Sie alle Ihre DDL. Speichern Sie alle Ihre Testdaten als Einfügeanweisungen oder als Tabellensicherung oder Zeichenformatexport (keine Ahnung, was MySQL in diesem Bereich kann/nicht kann).
37.1. Bearbeitet, die n::n Relation mit Office &Category . Sie werden das erst "sehen", wenn wir zum physikalischen Modell kommen.

37.2. Fertig.

37.3 Fertig.
.
38. Exzellent. Auch kürzer. Beachten Sie, dass sie niemals zwei Offices haben können in der gleichen Postleitzahl. NUMERIC(5,0) ist gut, aber ich dachte, die USA bewegen sich in Richtung 7 Ziffern. Spielt keine Rolle, Sie können es herausfinden; es ist ein ausgezeichnetes PK für Office . Nun diese Spalte, die Teil von Address war , wahrscheinlich ZipCode , wurde ohne Vervielfältigung zu einem höheren Zweck erhoben; Da wir es in 5 untergeordneten Tabellen tragen und wir möchten, dass der PK-Name gemäß den zuvor erläuterten Konventionen klar ist, nennen wir es OfficeCode; ZipCode könnte albern sein.

Wir brauchen einen eindeutigen Index für Name um sicherzustellen, dass sie nicht zwei Offices hinzufügen mit gleichem Namen. Beachten Sie, dass dies zu Erklärungszwecken eigentlich der logische Schlüssel von Office ist , wobei (StateCode, Town) ersetzt wird , und es bleibt so.

Ich denke immer noch, dass Sie StateCode benötigen und Town als schnelle Referenz (außer irgendwo in Address zu sitzen )

Datenmodell aktualisiert, fünftes jetzt zur Überprüfung verfügbar. Sie haben Ihre Präferenz für ...Date nicht angegeben vs ...Dtm . Ich gehe mit letzterem, da es spezifischer ist, und identifiziere auch die Zeitkomponente. Einfach zu ändern.

Diese Antwort hat die maximale Länge erreicht. Fortsetzung in "Teil II"