Jak najlepiej nazwać moje pola znaczników czasu?

Kiedy chcę utworzyć pola znaczników czasu (lub inne pola stylu daty / godziny), jaki jest najlepszy sposób na ich nazwanie? Czy powinienem po prostu wstawić record_timestamp?

Powinieneś opisać cel kolumny, a niekoniecznie typ danych. Nazwa może zawierać datę / godzinę / znacznik czasu, ale należy również podać znaczenie. Na przykład

• Data utworzenia
• Data rozpoczęcia
• StatusTime
• Dostęp
• Zaktualizowano

Dodanie daty / godziny / znacznika czasu itp. Na końcu jest szczególnie przydatne, gdy absurcja dodania koliduje z inną kolumną. Na przykład tabela może wymagać zarówno Statusu, jak i StatusTime.

Co powiesz xyz_atna a timestampi xyz_onna datepole - np. start_atLub start_on?

Zwykle unikałbym umieszczania typu danych w nazwie pola - znacznie lepiej, jeśli możesz wywnioskować, co musisz wiedzieć o typie z nazwy dowolnego pola (pole o nazwie descriptionprawdopodobnie nie będzie integer) - ale będąc w stanie powiedzieć różnica między timestampa a datejest często pomocna.

Używam:

• utworzono_at
• aktualizacja_at

Spojrzałem na twój profil i mówi, że pracujesz z SQL Server, a typ danych TIMESTAMP w SQL Server nie ma nic wspólnego z datą ani godziną, a jego wersja służy do stemplowania wierszy. Jest to bardzo przydatne do identyfikacji, które wiersze zostały zmodyfikowane od określonego momentu.

Jeśli używasz TIMESTAMP, nie musisz określać nazwy kolumny, a SQL Server utworzy dla Ciebie kolumnę „TimeStamp”. Zalecane jest jednak użycie typu danych „ROWVERSION” iw tym przypadku należy podać nazwę kolumny.

Jaka jest najlepsza nazwa takiej kolumny? To zależy, i użyłbym czegoś takiego jak VersionStamp, RV itp. Uważam, że ważne jest NIE to, jak je nazywasz, ale czy używasz tego konsekwentnie na całym forum.

HTH

Ref: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx

http://msdn.microsoft.com/en-us/library/ms182776.aspx

Okazało się, że stosując takie jak nazwy kolumn create_time, update_timei expire_timeprowadzi do lepszej czytelności, jeśli chodzi o metody nazewnictwa i specyfikacje (RSpec).

Wolę używać prefiksu DT dla znaczników daty. Na przykład: DTOpened, DTClosed, DTLastAccessed. To pozwala mi wymienić wszystkie DTxxxx w celu szybkiego odniesienia do wszystkich znaczników daty w danej tabeli.

Pracuję dla Texas Instruments i na swoich systemach używają xxxx_ dttm

Wolę stosować konwencje, które już istnieją.

Unix i języki programowania mają powszechnie przyjętą konwencję mtimedotyczącą czasu modyfikacji

Na czas tworzenia

• BSD i Windows używają porodu
• System Windows używa również czasu utworzenia
• xstat używa btime
• ext4 wykorzystuje crtime
• Używają JFS i btrfs otime(nie pytaj, zgadując „tworzenie”).

Więc dla mnie wybieram mtimei crtimedla metadanych.

W przypadku danych dostarczonych przez użytkownika używam tego, co reprezentuje to pole. Jeśli to urodziny, po prostu mówię user_birthday.

Jeśli chodzi o precyzję, dla niektórych wydaje się, że zawieszają się one na zbyt dużej precyzji. Możesz zapisać go birthdatejako znacznik czasu (po tym, jak technicznie narodziłeś się o danej porze dnia), ale specyfikacja SQL ma rzutowania z wyższej precyzji na niższą, więc jeśli używasz porządnej bazy danych, nie powinno to stanowić problemu . W samej aplikacji możesz zawsze obciąć w razie potrzeby. To znaczy, nigdy bym nie poszedł birthday_date.

Użyłbym znaczącego prefiksu i _TSMP jako sufiksu, np. CREATION_TSMP lub LAST_UPDATE_TSMP

Aby zachować spójność między nazwami kolumn, sugerowałbym zastosowanie następującej składni:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...

Jak sugeruje @Evan Carroll, postępuj zgodnie z istniejącymi standardami, chyba że masz silny powód, by złamać ten schemat.

Jeśli jest to coś nowego, możesz zastosować się do odpowiedzi, która najbardziej Ci odpowiada.

Używam * _on i * _by, ponieważ pomaga mi zachować spójność w przypadku, gdy i kto z wiersza:

- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by