Können Sie zwei Tabellen mit identischer Struktur in einem guten DB-Schema haben?

Question

2 Tische:
- Ansichten
- Downloads

Identische Struktur:
item_id, user_id, Zeit

Sollte ich besorgt sein?

Answer 1

Ich glaube nicht, dass es ein Problem an sich ist.

Beim Entwerfen einer Datenbank gibt es viele verschiedene Parameter, und einige (z. B. Leistung) können Vorrang haben.

Fall in Punkt: selbst wenn die Strukturen (und ich denke Indexierung) identisch sind, vielleicht "Ansichten" hat mehr Datensätze und wird häufiger zugegriffen werden. Dies allein könnte ein guter Grund sein, es nicht mit Rekordern aus den Downloads zu belasten.

Auch die Tatsache, dass sie jetzt identisch sind, bedeutet nicht, dass sie in der Zukunft sein werden: Ansichten und Downloads sind schließlich unterschiedlich, so dass früher oder später einer oder beide ein zusätzliches Feld oder zwei erweitern könnten.

Answer 2

Diese Tabellen sind identisch mit NOW, können sich jedoch in Zukunft ändern. Wenn sie 2 verschiedene Konzepte darstellen, ist es gut, sie getrennt zu halten. Was ist, wenn Sie einen Fremdschlüssel aus einer anderen Tabelle in die Download-Tabelle, aber nicht in die Views-Tabelle haben möchten, wenn dies die gleiche Tabelle ist, könnten Sie dies nicht tun.

Answer 3

Aus Sicht der E/R-Modellierung sehe ich kein Problem damit, solange sie zwei semantisch unterschiedliche Entitäten darstellen.

Von einer Umsetzung Sicht hängt es davon ab, wie Sie planen, diese Daten abfragen:

• Wenn Sie diese Tabellen unabhängig voneinander Abfrage-Plan zu, halten sie eine gute Wahl getrennt ist
• Wenn Sie planen, gemeinsam die Tabellen abzufragen (vielleicht mit einer UNION eines JOIN-Operation), sollten sie in einer einzigen Tabelle mit einem Diskriminator Spalte Speichern betrachten ihre Art

zu unterscheiden, wenn man bedenkt, ob sie int zu konsolidieren oa einzelne Tabelle sollten Sie auch in berücksichtigen andere Faktoren wie:

• Die Menge der Daten in jeder Tabelle gespeichert
• Die Rate, mit den Daten in jeder Tabelle
• Das Verhältnis von Lese-/Schreiboperationen ausgeführt wachsen auf jedem Tisch

Answer 4

Ich denke, die Antwort muss sein "es kommt darauf an". Wie jemand anders hervorhebt, wenn sich das Schema einer oder beider Tabellen entwickeln wird, dann nein. Ich kann mir andere Fälle gut vorstellen (vereinfacht das Sicherheitsmodell, indem ich Apps/Benutzern den Zugriff auf das eine oder andere erlaube).

Nachdem ich dies gesagt habe, arbeite ich mit einer Legacy-DB, wo ein Problem ist. Wir haben mehrere identische Tabellen für Kundenrechnungen. Die Daten werden tatsächlich zu verschiedenen Zeitpunkten im Verarbeitungslebenszyklus zwischen diesen verschoben. Es macht eine komplizierte Unordnung beim Versuch, auf Daten zuzugreifen.Es wäre leicht durch eine Zustandsflagge im ursprünglichen Schema gelöst worden, aber wir haben jetzt mehr als 20 Jahre Code gegen die Multi-Table-Version geschrieben.

Kurze Antwort: hängt davon ab, warum sie das gleiche Schema sind :).

Answer 5

Chris Date und Dave McGoveran formalisierten die "Principle of Orthogonal Design". Grob gesagt bedeutet dies, dass Sie im Datenbankdesign die Möglichkeit vermeiden sollten, das gleiche Tupel in zwei verschiedenen Relvars zuzulassen. Ziel ist es, bestimmte Arten von Redundanz und Mehrdeutigkeiten zu vermeiden, die sich ergeben können.

Wohl ist es nicht immer ganz praktisch, das zu tun, und es ist nicht unbedingt klar geschnitten genau, wenn das Prinzip gebrochen wird. Ich denke jedoch, dass es eine gute Führungsregel ist, schon allein deshalb, weil es das Problem doppelter Logik in Datenzugriffscodes oder -beschränkungen vermeidet, d. H. Es ist ein gutes Prinzip. Vermeiden Sie Tabellen mit potenziell überlappenden Bedeutungen, es sei denn, es gibt eine Datenbankeinschränkung, die eine Duplizierung zwischen ihnen verhindert.

Answer 6

Es hängt vom Kontext ab - was ist ein View und was ist ein Download? Bedeutet ein Download eine View (wie sonst würde es heruntergeladen werden)?

Es ist möglich dass Sie klar definierte, separate Konzepte haben - aber es ist ein Geruch, den ich weiter untersuchen möchte. Es scheint wahrscheinlich, dass eine Ansicht und ein Download irgendwie zusammenhängen, aber Ihr Modell zeigt nichts.

Answer 7

Wollen Sie sagen, dass beide Tabellen einen 'item_id' Primärschlüssel haben? In diesem Fall haben die Felder den gleichen Namen, aber nicht die gleiche Bedeutung. Eine ist eine 'view_id', und die andere ist eine 'download_id'. Sie sollten Ihre Felder folglich umbenennen, um diese Art von Missverständnis zu vermeiden.