Antworten:
Sie sollten den Zweck der Spalte und nicht unbedingt den Datentyp beschreiben. Sie können Datum / Uhrzeit / Zeitstempel in den Namen aufnehmen, sollten aber auch die Bedeutung angeben. Zum Beispiel
Das Hinzufügen von Datum / Uhrzeit / Zeitstempel und dergleichen am Ende ist besonders nützlich, wenn das Fehlen des Hinzufügens zu einem Konflikt mit einer anderen Spalte führen würde. Beispielsweise benötigt eine Tabelle möglicherweise sowohl einen Status als auch eine StatusTime.
Wie wäre es xyz_atfür ein timestampund xyz_onfür ein dateFeld - zB start_atoder start_on?
Normalerweise würde ich es vermeiden, den Datentyp in den Feldnamen aufzunehmen - viel besser, wenn Sie aus dem Namen eines Feldes (ein Feld mit dem Namen descriptionist wahrscheinlich kein Feld) ableiten können, was Sie über den Typ wissen müssen integer-, aber in der Lage zu sein, dies zu sagen Der Unterschied zwischen a timestampund a dateist oft hilfreich.
Ich benutze:
updated_atKönnte beides sein. Aber ich denke, die Antwort ist, wie immer beim Benennen, den prägnantesten Namen zu verwenden, der alle realistischen Unklarheiten beseitigt. Dh wenn in einem bestimmten Kontext die
Ich habe mir Ihr Profil angesehen und es besagt, dass Sie mit SQL Server arbeiten und der Datentyp TIMESTAMP in SQL Server nichts mit Datum oder Uhrzeit zu tun hat und für die Art der Versionsstempelung der Zeilen verwendet wird. Dies ist sehr nützlich, um festzustellen, welche Zeilen zu einem bestimmten Zeitpunkt geändert wurden.
Wenn Sie TIMESTAMP verwenden, müssen Sie keinen Spaltennamen angeben, und SQL Server erstellt eine Spalte "TimeStamp" für Sie. Es wird jedoch empfohlen, den Datentyp "ROWVERSION" zu verwenden. In diesem Fall müssen Sie den Spaltennamen angeben.
Was ist der beste Name für eine solche Spalte? Es hängt davon ab, und ich würde so etwas wie VersionStamp, RV usw. verwenden. Was ich für wichtig halte, ist NICHT, wie Sie es nennen, sondern verwenden Sie dies durchweg.
HTH
Ref: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx
Ich fand , dass Spaltennamen wie create_time, update_timeund expire_timeführt zu einer besseren Lesbarkeit , wenn es um Verfahren Namensgebung kommt und Spezifikationen (RSpec).
Ich bevorzuge ein Präfix von DT für Datumsstempel. Zum Beispiel: DTOpened, DTClosed, DTLastAccessed. Auf diese Weise kann ich alle DTxxxx auflisten, um eine schnelle Referenz aller Datumsstempel in einer bestimmten Tabelle zu erhalten.
Ich arbeite für Texas Instruments und auf ihren Systemen verwenden sie xxxx_dttm
Ich bevorzuge die Verwendung von Konventionen, die bereits existieren.
Unix und Programmiersprachen haben eine weithin akzeptierte Konvention mtimefür die Änderungszeit
Für die Erstellungszeit,
btimecrtimeotime(nicht fragen, "Herkunft" erraten).Also für mich, ich wähle mtimeund crtimefür Metadaten.
Für vom Benutzer bereitgestellte Daten gehe ich mit dem, was das Feld darstellt. Wenn es Geburtstag ist, sage ich nur user_birthday.
Was die Präzision betrifft, scheint es für manche zu viel Präzision zu geben. Sie können Ihre birthdateDaten als Zeitstempel speichern (nachdem Sie zu einer bestimmten Tageszeit technisch geboren wurden), aber die SQL-Spezifikation enthält Umwandlungen von höherer Präzision zu niedriger Präzision. Wenn Sie also eine anständige Datenbank verwenden, sollte dies kein Problem sein . In Ihrer App selbst können Sie bei Bedarf immer abschneiden. Das heißt, ich würde nie gehen birthday_date.
Ich würde ein aussagekräftiges Präfix und _TSMP als Suffix verwenden, z. B. CREATION_TSMP oder LAST_UPDATE_TSMP
Verwenden Sie, wie von @Evan Carroll vorgeschlagen, die vorhandenen Standards, es sei denn, Sie haben guten Grund, das Muster zu brechen.
Wenn dies etwas Neues ist, können Sie jeder Antwort folgen, die am besten zu Ihnen passt.
Ich benutze * _on und * _by, weil es mir hilft, es für wann und wer in der Zeile konsistent zu halten:
- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by