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

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?

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

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ł.

... 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.

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.

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.

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.

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.