Czy sensowna jest standaryzacja uwzględniająca datę utworzenia i datę ostatniej aktualizacji we wszystkich tabelach DB?

38

Mój szef obecnie próbuje zastosować pewne standardy programistyczne w naszym zespole, więc wczoraj spotkaliśmy się, by omówić standardy, które były w większości dobre, dopóki nie poruszyła:

  • Wszystkie tabele DB będą miały kolumnę CreatedDate i LastUpdatedDate, zaktualizowaną przez wyzwalacze.

W tym momencie nasz zespół doznał schizmy opinii; połowa z nas uważa, że ​​robienie tego na wszystkich stołach wymaga dużej ilości pracy, przynosząc niewielkie korzyści (pracujemy nad projektami o stałym budżecie, więc wszelkie koszty pochodzą z zysków naszej firmy); druga połowa uważa, że ​​pomoże to w wsparciu projektów.

Jestem zdecydowanie w byłym obozie. Chociaż doceniam, że niektóre przypadki zewnętrzne spowodowałyby, że dodatkowe kolumny poprawiłyby obsługę, moim zdaniem ilość pracy, która byłaby wymagana, aby dodać kolumny w pierwszej kolejności, a także konserwacja, sprawiłyby, że spędziliśmy mniej czasu na więcej ważne rzeczy, takie jak testy jednostkowe lub obciążenia. Jestem też całkiem pewien, że te dodatkowe kolumny sprawiłyby, że korzystanie z ORM byłoby bardziej niezręczne - pamiętając, że używamy głównie C # i Oracle, co na początku nie jest zbyt przyjemne z ORM.

Moje pytanie jest więc dwojakie:

  • Czy jestem we właściwym obozie? Nie twierdzę, że mam znane na całym świecie umiejętności baz danych, więc może to być banalnie łatwy dodatek bez żadnych niepożądanych skutków ubocznych.
  • Jak poradziłbyś sobie z sytuacją, w której spotkanie na temat standardów zmienia się w mecz żużlowy? Jak mogę naprawdę sprzedać, że ten standard nie pomoże nam w dłuższej perspektywie?
Ed James
źródło
Dlaczego mówisz, że C # nie jest zadowolony z ORM? Ponadto dodanie właściwości [insert = "false" update = "false" Wygenerowane = "zawsze"] do mapowania tych dwóch kolumn w NHibernate na przykład nie wydaje mi się tak niewygodne, czy coś mi brakuje?
Jalayn
C # + Oracle nie jest zadowolony z ORM i stwierdziliśmy, że NHibernate był zbyt ciężki (najwyraźniej nie byłem zaangażowany w to śledztwo w sprawie narzędzi). Prawdopodobnie postawiłem C # i Oracle do tyłu w głównym pytaniu.
Ed James,
Należy rozważyć zmianę nazwy tytułu pytania, aby była bardziej opisowa w stosunku do standardów baz danych.
wałek klonowy
Jak miałoby to zabrać trochę czasu? Będziesz musiał to zrobić co najmniej dwa razy w przypadku „spraw zewnętrznych”. Utwórz narzędzie i kilka klas wielokrotnego użytku i nigdy więcej się o to nie martw.
Steven Evers,

Odpowiedzi:

27

Jest to dość powszechna praktyka, chociaż nie powiedziałbym, że wsparcie jest główną korzyścią. Prawdziwą korzyścią z tego podejścia jest prowadzenie ścieżki audytu. Często spotyka się dodatkową kolumnę zawierającą nazwę użytkownika, który dokonał ostatniej aktualizacji.

Jeśli masz do czynienia z jakimikolwiek danymi finansowymi lub wrażliwymi, jestem pewien, że słyszałeś o zgodności z PCI i SOX . Posiadanie kompleksowej ścieżki audytu jest niezbędne do spełnienia tych specyfikacji.

Zastrzeżenie: Istnieją jednak znacznie lepsze sposoby uzyskania ścieżki audytu bazy danych> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails

MattDavey
źródło
Przepraszam, zapomniałem wspomnieć, że zgodność z PCI (itp.) Nie ma zastosowania, w dziennikach znajduje się już ścieżka audytu procesu (WSZYSTKO jest rejestrowane dość dokładnie).
Ed James,
6
„(WSZYSTKO jest rejestrowane dość dokładnie)” czy obejmuje to CreatedDate i LastUpdatedDate? Jeśli tak, być może mógłbyś wskazać swoim kolegom zasadę SUCHEGO :)
MattDavey,
2
To bardzo dobra uwaga, być może powinienem naciskać na bardziej wydajny parser dziennika, którego moglibyśmy użyć do łatwego zapytania do zarchiwizowanych danych (oczywiście dane służą do celów ścieżki audytu, więc nie przechowujemy więcej niż tydzień lub mniej zapytanie, reszta jest magazynowana).
Ed James,
3
Nie sądzę, aby takie podejście przyniosło bogatą ścieżkę audytu ... Nawet nie nazwałbym tego ścieżką audytu .
Jordão,
@ Jordão Powiedziałem, że to powszechne podejście, ale nie powiedziałem, że to dobre! Stąd wyłączenie odpowiedzialności :)
MattDavey
17

Pierwszy argument jest nieprawidłowy, ponieważ dodanie kilku pól znaczników czasu przechowywanych w bazie danych do szeregu tabel nie jest trudną pracą. Jest to w rzeczywistości rodzaj odrętwiającego zadania, które można by powierzyć młodszemu lub stażyście, i mogliby to łatwo zrobić w ciągu zaledwie dwóch tygodni sprintu z czasem do stracenia.

Mapowanie tych pól w ORM może, ale nie musi być konieczne, po prostu dlatego, że nie chcesz, aby użytkownicy aplikacji modyfikowali te pola i ponieważ są one przydatne do konserwacji i debugowania i rzadko mają zastosowanie w logice biznesowej. Pracowałem w sklepach, które zrobiły to w obie strony i szczerze mówiąc, nie mam zbyt wiele zdania na ten temat.

Korzyści, nawet jeśli przesadzone, wciąż znacznie przewyższają wszelkie koszty ludzkie związane z wdrażaniem takiej funkcjonalności na poziomie bazy danych, a na pewno prawdopodobnie mniej niż zbiorowa moc mózgu projektów wielkich umysłów technicznych przejmujących spotkanie i walczących z nimi w epickim meczu walącym w klatkę piersiową. Gdy zliczysz wpływ kilku godzinnych spotkań na czas trwania projektu, prawdopodobnie nie będziesz zaskoczony, że są one drogie. Wyobraź sobie zbiorowe stawki godzinowe i świadczenia wszystkich tych osób łącznie, które powinny dać ci pomysł.

wałek klonowy
źródło
8
Utwórz skrypt, który doda te kolumny do każdej tabeli, jeśli nie istnieją jeszcze razem z wyzwalaczami.
JeffO,
3
+1 Możesz łatwo wygenerować skrypty w ciągu kilku dni. Tylko dużo pracy, jeśli jest wykonywana ręcznie.
Jon Raynor,
8

... im bardziej jednoznaczne stwierdzenia człowiek czyni, tym bardziej prawdopodobne jest, że ostatecznie się myli ... - Tyler Durden

dotyczy to kocowych „standardów”, podczas gdy na niektórych stołach może to być ogromna wygrana, przy każdym stole najprawdopodobniej byłby to bezużyteczny szum i więcej kodu do utrzymania lub zapomnienia o utrzymaniu.

jest tu równowaga, którą powinieneś naciskać na decydentów.


źródło
8

Zgadzam się z całego serca. Prawie każda tabela w każdej bazie danych powinna mieć co najmniej 2 pola: datę utworzenia i datę aktualizacji . Istnieje wiele powodów, dla których warto ustawić datę utworzenia i aktualizację. Z oczywistych powodów poprzednie osoby stwierdziły… co jest audytem.

Projektuję systemy i bazy danych od 25 lat i pracowałem dla setek klientów. Nie ma jednego klienta, który NIE potrzebowałby tego.

Istnieją 2 podstawowe sposoby na to:

1 - Pierwsza praktyka polega na tym, że baza danych wykonuje pracę i umieszcza ją bezpośrednio w projekcie tabeli. Co jest absolutnym minimum, polecam.

2 - Inną praktyką, którą wolę .... jest użycie do tego narzędzia replikacji. Zespoły DEV nie ponoszą żadnych kosztów ogólnych. Narzędzia są jednak drogie. Dodatkową zaletą jest to, że proces usuwania może być kontrolowany o wiele łatwiej dzięki tego typu narzędziu. Bez narzędzia do replikacji trzeba by utworzyć tabelę audytu i wyzwalacze wyzwalające usuwanie - moim zdaniem nie jest to dobra praktyka.

Kolejną korzyścią z posiadania tych pól jest hurtownia danych i ODS, które ZAWSZE są budowane dla dowolnego systemu OLTP. Bez niego nie można skutecznie wyciągać danych przyrostowych. W przeciwnym razie ryzykujesz konieczność przeładowywania całego DB codziennie.

Istnieje ogromna liczba innych powodów biznesowych dla wprowadzenia tych dwóch dat, których nie będę tutaj zagłębiał. Odrób pracę domową i na pewno 3-6-12-48 miesięcy później będziesz bardzo szczęśliwy, że umieścisz te 2 proste pola.

Wdrożyłem i zazwyczaj polecam oba rozwiązania tam, gdzie to możliwe.

Andrew Venuto
źródło
5

Mamy datę utworzenia i utworzyliśmy kolumny w naszej bazie danych, które pomogły nam ogromnie w śledzeniu problemów z danymi. Jeśli musimy cofnąć, pomaga nam to znaleźć właściwe rekordy w pełnych tabelach kontroli (ponieważ wiemy, gdzie szukać w bardzo dużej tabeli). Powinna także dodać utworzony i zmodyfikowany przez kolumny. Naprawdę naprawdę pomaga wiedzieć, kto wprowadza dane, szczególnie jeśli nie masz pełnego audytu.

Nie mogę sobie wyobrazić żadnej aplikacji Enterprise, która nie wymagałaby kontroli takiej czy innej formy. Najwyraźniej twój szef uważa, że ​​wymaga jedynie stosunkowo łagodnego audytu. Osobiście opowiadam się za pełnym audytem każdej bazy danych zawierającej dane, od których twoja firma jest zależna (o wiele łatwiej jest przywrócić 2000 złych rekordów z tabel audytu niż przywrócić kopie zapasowe) i wymagałbym tego, gdyby w ogóle były jakieś informacje finansowe, ponieważ ja widziałem tego rodzaju rzeczy, które pomagają złapać osoby popełniające oszustwa. Cała kontrola musi odbywać się na poziomie bazy danych.

Jak te dane mogą pomóc? Cóż, najpierw zawęża, kiedy szukać starych danych (w wersji) i może pomóc ci zobaczyć, która wersja twojego programu była aktywna w momencie wprowadzania danych. Więc jeśli wiesz, że rozwiązałeś ten problem w wersji 2.3, która została uruchomiona 6 lipca 2011 r., A następnie znalazłeś ten sam problem z rekordem wstawionym 7 sierpnia, być może Twoja poprawka nie była dobra. Jeśli musisz przywrócić stare dane, podpowie Ci, w której wersji kopii zapasowych możesz znaleźć stare dane, jeśli nie masz pełnej kontroli.

Programiści rzadko sądzą, że dane muszą być utrzymywane z czasem i że złe dane muszą zostać naprawione przez kogoś. Posiadanie takich rzeczy może być bardzo cenne dla tych z nas, którzy muszą robić takie rzeczy. Twój szef ma rację, chociaż nie sądzę, żeby poszła wystarczająco daleko w audycie. Potrzeba tylko jednego naprawdę poważnego problemu, który można łatwo naprawić, aby uzasadnić bardzo krótki czas potrzebny na dodanie tych kolumn i wyzwalaczy.

HLGEM
źródło
Wolę widzieć ludzi skutecznie Testowanie ich poprawek przez Jednostki niż próbę ich weryfikacji za pomocą kontroli DB, ale doceniam twój punkt widzenia. Nie jestem jednak pewien, czy punkt, który podałeś, dotyczyłby KAŻDEJ tabeli we wszystkich naszych bazach danych, nawet tabelach referencyjnych itp.
Ed James,
Testy jednostkowe są niezależne od audytu. Wspominam, że może złapać błąd, ponieważ widziałem, jak to się dzieje, nawet gdy były testy jednostkowe, ponieważ istniała niesprawdzona obudowa. Może również wskazywać, że dane zostały wprowadzone przed naprawą błędu, a następnie może być konieczne znalezienie innych danych, które również wymagają naprawy. Lub po prostu wiedz, że to dane wprowadzone podczas importu w dniu 6 czerwca 2016 r. Pomogą ci sprawdzić, czy problem był spowodowany przez import, czy coś nie tak z danymi w pliku importu. To o wiele łatwiejsze niż przeglądanie codziennych importowanych plików.
HLGEM,
4

Obciążenie jest sporne, ponieważ można je skryptować i stosować do każdej bazy danych, którą kiedykolwiek utworzysz. Dodaj kolumny do wszystkich tabel wraz z wyzwalaczami. Musisz tylko pamiętać, aby uruchomić go ze swoją kompilacją.

Jeśli chodzi o to, czego chce klient, możesz zapłacić, aby zintegrował je z Twoją aplikacją według własnego uznania. Wiele osób lubi widzieć dodatkowe informacje w rekordzie, takie jak kto utworzył / zmienił go ostatnio i kiedy. Nie musisz wysyłać wszystkim wiadomości e-mail, aby dowiedzieć się lub zostać okłamanym. Nie musisz sprawdzać dziennika za każdym razem, gdy ktoś patrzy na rekord.

Umieszczenie go w bazie danych i posiadanie go na wszelki wypadek nie jest trudne i może pozwolić ci na pobieranie opłat za dodatkowe funkcje wykorzystujące pola lub po prostu dać ci opinię na temat ilości klientów korzystających z systemu.

JeffO
źródło
Klienci nie wyrazili żadnej opinii na ten temat (o ile mi wiadomo) i prawdopodobnie nie mają pojęcia o naszych nowych standardach, więc bardzo bym się spodziewał, że nie będą zainteresowani płaceniem za jakąkolwiek integrację;) „może pozwolić ci na obciążenie” to dość dobry argument, jeśli trochę polegam na „mógłbym” w moim zwykłym podejściu do rozwoju.
Ed James,
1

Byłoby to dość trywialne do wdrożenia (może w sumie od 1 do 3 dni), więc moim zdaniem to, ile wartości doda do twojej aplikacji przez cały okres jej użytkowania.

Po pierwsze, do dodania kolumn potrzebna byłaby instrukcja alter table, wszystkie byłyby takie same (oprócz nazwy tabeli), więc można napisać skrypt generujący instrukcję alter SQL dla wszystkich potrzebnych tabel . Muszą pozwolić, aby wartości NULL uwzględniały istniejące dane i sprawdzały istnienie kolumn, aby można je było ponownie uruchomić.

Po drugie, w przypadku kolumn przy użyciu wartości domyślnych, takich jak GetUTCDate () (SQL Server, Oracle może być inny) rozwiązuje wszelkie dodania kodowania we wstawce, więc podstawa kodu nie musi się zmieniać dla żadnej instrukcji wstawiania, ponieważ wartości domyślne będą używany.

Aktualizacje danych (zmiana na ostatnią modyfikację) można rozwiązać za pomocą wyzwalacza aktualizacji. Ponownie, ten wyzwalacz byłby prawie taki sam we wszystkich tabelach, więc ten kod wyzwalający (SQL) mógłby zostać wygenerowany również dla wszystkich istniejących tabel.

Potencjalnie byłoby dużo kodu skryptu SQL (w zależności od liczby tabel), ale jest to wzór, który jest powtarzalny, więc można go wygenerować, patrząc na istniejący schemat DB.

Jon Raynor
źródło
Martwiłbym się, że przy takim podejściu wielkopasmowym będziesz mieć problemy z długoterminową konserwacją nowych tabel lub że (co gorsza) będziesz musiał zrobić sproc, który skanuje każdą tabelę w poszukiwaniu określonych nazwanych kolumn, a następnie generuje skrypt DDL, aby je dodać, jeśli brakuje, co brzmi jak koszmar konserwacji!
Ed James
Jeśli jest to standard, mam nadzieję, że deweloper tworzący nowe tabele postępuje zgodnie ze standardem. W przeciwnym razie tak, koszmar. Podejście polega na przyspieszeniu istniejącego schematu, po tym jak na deweloperu spoczywa obowiązek przestrzegania standardu.
Jon Raynor,
Myślę, że kluczowym słowem tego komentarza jest „mam nadzieję”, nie jestem pewien, czy ufam cokolwiek, co musi się wydarzyć z własnej woli każdego nowego dewelopera!
Ed James,
2
@Ed - Uzgodnione, bez zaufania, po to są recenzje kodu! :)
Jon Raynor