Sollte eine Protokolltabelle ein ID-Feld oder einen Primärschlüssel erhalten?


12

Ich habe eine Protokolltabelle, die den Datums- / Uhrzeitstempel erfasst, als bestimmte Dateien auf ein anderes System exportiert wurden.

Die exportedLog-Tabelle enthält derzeit drei Felder:

id                (primary key)
messageId         (int)
exportedDateTime  (datetime)

Als ich dies überprüfte, stellte ich fest, dass das idFeld keinen Zweck erfüllt, da es keine Verknüpfungen zu dieser Tabelle gibt. Das einzige, was an dieser Tabelle arbeitet, ist das Einfügen des Stapeljobs, der die Nachrichten verarbeitet und in diese Protokolltabelle einfügt.

Soll ich das idFeld entfernen ?

Soll ich einen Primärschlüssel haben entweder messageIdoder exportedDateTimeoder beides?


2
Für welches DBMS ist das?
Ypercubeᵀᴹ

Antworten:


10

Soll ich das ID-Feld entfernen?

Ich würde empfehlen, es zu behalten.

Möglicherweise benötigen Sie das Feld jetzt nicht , aber in Zukunft kann es Ihnen wirklich helfen - was ist, wenn Sie Details der Dateien für jeden Protokolleintrag speichern müssen?

Ich weiß nicht, wie groß diese Tabelle wird und wie schnell, aber das Hinzufügen einer Spalte zu einer großen Tabelle ist normalerweise eine teure Operation. Wenn der Tisch relativ klein ist, ist es keine große Sache, Speicherplatz zu sparen. IMO, behalte die Spalte und speichere später mögliche Kopfschmerzen.

Sollte ich einen Primärschlüssel für messageId oder exportedDateTime oder beides haben?

Es hört sich nicht so an messageId, als wäre allein in dieser Tabelle eindeutig (obwohl ich mich irren könnte), und das Erstellen einer Eindeutigkeit in einer Datums- / Zeitspalte allein kann möglicherweise zu Duplikaten (und damit zu Fehlern) führen. Die einzige verbleibende Option ist ein zweispaltiger Schlüssel, der angesichts des oben beschriebenen Szenarios nicht besonders ansprechend ist.


Im Wesentlichen geht es mir bei dieser Antwort darum, dass das Beibehalten der Spalte keine große Sache ist (nehme ich an), aber eine spätere Notwendigkeit kann eine große Sache sein und / oder zusätzliche Arbeit erfordern, um sie zurückzusetzen.


6
  • Wenn Sie keine Verknüpfungen in dieser Tabelle, keine Aktualisierungen und keine Löschungen haben, benötigen Sie überhaupt keine Schlüssel.

  • Wenn dies nicht der Fall ist und messageIdeindeutig ist, können Sie es zu einem Primärschlüssel machen.

  • Wenn es nicht eindeutig ist, aber (messageId, exportedDateTime)ist, machen Sie dies zu einem zusammengesetzten Primärschlüssel.

  • Selbst wenn nur die (messageId, exportedDateTime)können Kombination Duplikate geben und Aktualisierungen und Löschungen erforderlich sein könnten (etwa versehentlich eingefügten Zeilen entfernen), sollten Sie besser das verlassen idFeld gibt.


0

Ein Primärschlüssel wird nicht schaden ... Wenn Sie den Zweck des Protokoll- / Überwachungspfads berücksichtigen, wird er wahrscheinlich in Zukunft verwendet (abgefragt), um ein Problem zu beheben oder Daten usw. wiederherzustellen, und wird wahrscheinlich mit anderen verknüpft vorhandene Nicht-Protokoll- / Überwachungstabellen, um diese Art von Arbeit auszuführen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.