Kiedy tabela bazy danych powinna używać znaczników czasu?

Po pierwsze, pomyślałem, że może to pytanie należało do wymiany baz danych, ale myślę, że bardziej ogólnie dotyczy rozwiązania programistycznego jako całości niż baz danych. Przejdzie do wymiany baz danych, jeśli ludzie uznają to za najlepsze.

Zastanawiałem się, kiedy tabela bazy danych powinna mieć utworzony i zaktualizowany znacznik czasu?

Pierwszą oczywistą odpowiedzią jest to, że jeśli jakakolwiek logika biznesowa musi wiedzieć, kiedy coś zostało zaktualizowane (np. Data zakończenia transakcji itp.), To musi wejść.

Ale co z przypadkami nielogicznymi? Mogę na przykład wymyślić scenariusze, w których przydałaby się znajomość daty i godziny zmiany wierszy, aby pomóc w znalezieniu błędu, np. Niektóre logiki biznesowe zawodzą i patrząc na powiązane wiersze bazy danych można zidentyfikować, że jeden wiersz jest aktualizowany przed kolejny wiersz, który powoduje błąd.

W tym przypadku użycia sensowne byłoby nadanie każdej tabeli aktualizacji i utworzenie znacznika czasu (z wyjątkiem być może najbardziej trywialnych tabel wyliczeniowych, które nie byłyby aktualizowane przez żadną część aplikacji).

Nadanie każdej tabeli znacznika czasu jest z pewnością świetnym sposobem na szybkie zebranie bazy danych (choć może być błędne).

Kiedy więc tabela bazy danych powinna tworzyć i aktualizować znaczniki czasu?

Aby uzyskać lepsze i bardziej kompleksowe zarządzanie bazą danych i najmądrzejszą praktyką jest to zrobić.

Po pierwsze, jest bardziej prawdopodobne, że jako programista chciałbyś śledzić transakcje i / lub działania w bazie danych w celu opracowania i ułatwić śledzenie błędów i błędów w kodzie, ilekroć dotyczy to bazy danych.

Ponadto, gdy trzeba śledzić działania wykonane w bazie danych do celów statystycznych .

Po drugie, często zdarza się, że być może na razie nie musisz śledzić działań w bazie danych, ale bardziej prawdopodobne jest, że w przyszłości. Będzie potrzebował twojego czasu dzisiaj, ale kupi więcej w przyszłości .

Jako ktoś, kto był zarówno kłusownikiem (programistą), jak i geniuszem (DBA), jestem zaskoczony, że wielu nadal nie widzi w tym wartości i uważa ją za nadętą.

Po prostu:

Dla każdej tabeli, do której dodawane są rekordy (ale nigdy nie są aktualizowane), np. Loginów itp. Rozważam dodanie kolumny DATE_CREATED.

W przypadku każdej tabeli, w której rekordy są dodawane i aktualizowane, rozważę dodanie kolumny DATE_CREATED i DATE_UPDATED.

Pracowałem w wielu miejscach, w których DATE_CREATED i DATE_UPDATED są domyślnie uwzględnione w każdej tabeli jako część projektu.

W przypadku większych baz danych z milionami / miliardami wierszy, w których aktualizacja bazy danych działała w ciągu kilku dni, dodaliśmy również kolumnę ŹRÓDŁO dla niektórych tabel, które śledziły, który zestaw danych spowodował aktualizację, np. Kanał danych innych firm, aktualizacja użytkownika, modyfikacja DBA, czyszczenie danych itp.

W sposobie sformułowania pytania pytasz o listę rzeczy. Zaryzykuję, że nie odpowiem bezpośrednio na twoje pytanie, ale odpowiem, kiedy powinieneś użyć alternatywnego rozwiązania.

Mogę wymyślić scenariusze, w których naprawdę przydatna byłaby data i godzina zmiany wierszy, aby pomóc w znalezieniu błędu

Czy bardziej użyteczne byłoby posiadanie dziennika wszystkich aktualizacji dla danego rekordu? Sama znajomość ostatniej aktualizacji może być niewystarczająca. Ten dziennik można umieścić w osobnej tabeli. Wygodniej byłoby śledzić zmiany z kilku tabel w tym samym pliku (plikach dziennika) (nie musi to być tabela). Zapobiega to masowemu zapytaniu związkowemu wszystkich tabel data_zmian w celu uzyskania agregacji. Przydałoby się to również w rozwiązywaniu problemów, pomagając zobaczyć rejestrację większej liczby zdarzeń w systemie.

Ponadto: należy również wziąć pod uwagę użytkowników. Nie mogą to stanowić uzasadnienia biznesowego, ale jeśli masz niedoświadczonych użytkowników lub osoby w kulturze korporacyjnej, w których nigdy nie popełniają błędu użytkownika i chcą zawsze obwiniać go na komputerze, wszelkie rejestrowanie pomoże, w tym zaktualizować daty w tabelach. W takim przypadku możesz również chcieć mieć pole Update_UserID.

Tabela bazy danych powinna zawierać szablony tworzenia i modyfikacji, jeśli spełniony jest jeden z poniższych warunków:

1. Tabela przedstawia podstawowy zapis niektórych działań dostarczonych przez użytkownika. Jeśli użytkownik używa X, a masz zarówno a, jak Table_Xi Table_Yjeden do wielu potomków Table_X, Table_Ynie jest to rekord podstawowy i dlatego nie wymaga dodatkowych pól.
2. Gdy masz stałą, tymczasową lub cykliczną potrzebę śledzenia systemu . Jeśli musisz sprawdzić, czy Table_Yaktualizuje się tylko po Table_Xaktualizacji, dodatkowe pola śledzenia mogą pomóc.

Pamiętaj, że żaden z nich nie jest wyłączny; możesz dodawać je domyślnie wszędzie i pomijać tylko wtedy, gdy jest to potrzebne do dostrajania wydajności.

Osobista opinia:

Nie widzę wartości w modifiedkolumnie.

created, absolutnie, należy dodać do każdej tabeli bazy danych, chyba że istnieje wyjątkowe uzasadnienie, aby tego nie robić. Posiadanie go ma tak wielką wartość.

Jednak updatedwydaje się odpadów. Dlaczego nie po prostu pójść na całość, stworzyć dwie tabele bazy danych, jedną, która określa identyfikator dokumentu, a drugą wersję dokumentu. W bardzo uproszczonym przypadku

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Następnie wybierz najnowszy versionz nich document. W ten sposób nie tylko zapisujesz każdą datę modyfikacji - nie tylko ostatnią - ale także zachowujesz każdą wersję tego dokumentu. Jedynym argumentem przeciwko temu jest tak naprawdę miejsce na dysku twardym, ale na pewno, gdy dojdziesz do momentu, w którym martwisz się, ile miejsca zajmuje on na dysku twardym - w większości przypadków byłbyś jeszcze bardziej zaniepokojony wersjonowaniem danych