Jak przekonująco argumentować przeciwko duplikowaniu kolumn bazy danych?

47

Zacząłem pracować w nowej organizacji, a jednym z wzorców, które widziałem w bazie danych, są powielanie pól, aby ułatwić pisanie zapytań analitykom biznesowym. Używamy Django i jego ORM.

W jednym przypadku przechowujemy obiekt MedicalRecordNumber z unikalnym ciągiem identyfikującym pacjenta w określonym kontekście. Mamy obiekty rejestracyjne, które śledzą pacjentów i mają powiązane numery MedicalRecordNumbers , ale zamiast używać relacji klucza obcego, duplikują ciąg, aby uniknąć pisania sprzężenia ( nie ze względu na wydajność). Ten wzorzec jest powszechny w całej bazie danych.

Dla mnie znaczenie czystego modelu danych jest po prostu tak, że mogę o nim dobrze myśleć. Niepotrzebna złożoność to strata mojego ograniczonego czasu przetwarzania poznawczego. To systematyczny problem. Niekomfortowe pisanie łączy jest problemem, który można naprawić. Niekoniecznie chcę opowiadać się za powrotem i zmianą schematu, ale chciałbym móc przekonująco przedstawić problemy związane z tego rodzaju powielaniem.

database-design

— canisrufus
źródło

2

Co to znaczy „nie czuć się komfortowo w dołączaniu”? Jak oni to wyjaśniają?

— scriptin

9

Czy ci ludzie pracują dla ciebie? Czy jesteś ich przełożonym? Większość uzasadnień można znaleźć tutaj: en.wikipedia.org/wiki/Database_normalization . Tak, muszą lepiej korzystać z połączeń.

— Robert Harvey

1

Czy przeglądałeś literaturę dotyczącą tego, dlaczego normalizacja jest pożądana?

— Nathan Tuggy,

17

Czy dodawanie widoków, które łączą wewnętrznie, nie sprawia, że pisanie zapytań jest tak łatwe? Możesz zasugerować je jako alternatywę.

— CodesInChaos

1

Czy przekazałeś to (grzecznie) swoim rówieśnikom i seniorom? Jakie są ich uzasadnienia, jakie rozważania podejmują? Istnieje wiele możliwych powodów, dla których może to być dobry pomysł (nawet jeśli mówisz, że „wydajność nie jest powodem”, jakie dowody musisz to poprzeć?). Czy zanim oskarżyłeś ich o zbyt lenistwo i / lub sztywność, czy zastanawiałeś się (i zapytałeś), dlaczego mają taki projekt? Może jest o wiele więcej odczytów niż zapisów (analityczna baza danych)? Zmienić śledzenie? Dane historyczne? Zapytaj wszystkich - ktoś może znać prawdziwy powód.

— Luaan,

128

Twoja operacyjna baza danych powinna być wysoce znormalizowana, aby zmniejszyć anomalie .

Twoja analityczna baza danych (magazyn) powinna być wysoce zdenormalizowana, aby ułatwić analizę.

Jeśli nie masz osobnej analitycznej bazy danych, powinieneś stworzyć wysoce zdenormalizowane [zmaterializowane] widoki.

Jeśli powiesz starszym analitykom / menedżerom biznesowym, aby wykonali wiele połączeń w celu przeprowadzenia prostej analizy, możesz zostać zwolniony.

Agile Data Warehouse Design to dobra książka

Zobacz moje szybkie porady dotyczące hurtowni danych tutaj

— Neil McGuigan
źródło

9

To jest właściwa droga.

— Nit

6

+1 To jest dokładnie to, do czego przeznaczone są Widoki: zezwalanie na zdormalizowany widok w znormalizowanej bazie danych.

— Nzall

4

Absolutnie słuszne, ale myślę, że należy „podkreślić anomalie” bardziej podkreślić, ponieważ jest to główna odpowiedź na pytanie. Najczęstszą (jedyną?) Anomalią, którą zobaczysz w przypadku powielania / denormalizacji danych, jest to, że kolumny zostaną w jakiś sposób zapełnione sprzecznymi danymi w tym samym czasie, nie pozostawiając ci żadnej możliwości dowiedzenia się, jakie powinny być rzeczywiste dane i nie sposób ustalenia, co poszło nie tak. To ostatnie można złagodzić za pomocą masowego śledzenia zmian, ale nie będzie to tanie ani szybkie przejście do rozwiązania problemu. Bardziej opłacalne, aby całkowicie uniknąć problemu.

— jpmc26

2

Innym aspektem do rozważenia jest to, że nawet zakładając, że programiści są w stanie zachować poprawność danych (wątpliwe), staje się to ogromnym obciążeniem dla ich zasobów, aby zapewnić, że każde zduplikowane pole jest aktualizowane, gdy jest to wymagane dla zachowania spójności.

— Nate CK

1

@Panzercrisis Jedynym sposobem, w jaki transakcja jest „niejawna”, jest automatyczne zatwierdzanie uruchomione na końcu zapytania. Zwykle nie powinno tak być w przypadku produkcyjnej bazy danych. W aplikacji transakcje powinny być inicjowane automatycznie, a zatwierdzenie powinno być wydawane niezależnie od zapytania. Jest to niewielka wstępna inwestycja w aplikację, ale upraszcza zmiany w kodzie, które wymagają dodawania wywołań do bazy danych, i zmniejsza ilość myśli o programistach (poprawia szybkość tworzenia, zmniejsza liczbę błędów tworzenia). Tego rodzaju konstrukcja dobrze pasuje również do takich elementów, jak pula połączeń.

— jpmc26

57

Rozumiem, dlaczego ktoś chce uniknąć pisania złączenia dla każdego wyboru.

Ale można utworzyć raz myślą o łączeniu i używać go zamiast swojego nieznormalizowanych tabeli.

Łączymy więc zaletę normalizacji z wygodą łatwego wyboru.

— knut
źródło

12

Widoki są twoimi przyjaciółmi. Używaj ich swobodnie. Aby zwiększyć wydajność, można nawet użyć widoków zmaterializowanych, jeśli RDBMS je obsługuje.

— VH-NZZ

13

Odpowiedzi, które zostały już ocenione, w dużej mierze obejmują „jak uniknąć powielania” (korzystanie z widoków), ale nie dlaczego. Zasadniczo pokazują, że duplikacja kolumn jest złym rozwiązaniem problemu ułatwiającego pisanie zapytań. Ale pytanie „dlaczego nie zduplikować przypadkowej kolumny tylko ze względu na nią?” wciąż stoi.

Odpowiedź brzmi „Z powodu prawa Murphy'ego”. Prawo Murphy'ego stanowi, że:

Jeśli coś może pójść nie tak, zrobi to.

W takim przypadku zawartość każdego pola wiersza zduplikowanej kolumny powinna być identyczna z zawartością każdego odpowiadającego pola wiersza oryginalnej kolumny. Co może się nie udać, zawartość niektórych pól wierszy może różnić się od oryginałów, siejąc spustoszenie. Możesz pomyśleć, że podjąłeś wszelkie możliwe środki ostrożności, aby upewnić się, że nie będą się różnić, ale prawo Murphy'ego stanowi, że skoro mogą się różnić, będą się różnić. I nastąpi spustoszenie .

Jako przykład tego, jak to się może stać, po prostu rozważ fakt, że zduplikowane kolumny nie są wypełnione magią; ktoś musi napisać kod, który przechowuje w nich wartości, ilekroć wiersze są tworzone w oryginalnej tabeli, a ktoś musi pisać kod, który aktualizuje je za każdym razem, gdy oryginały zostaną zmodyfikowane. Pomijając fakt, że powoduje to nadmierne obciążenie kodu, który wprowadza dane do bazy danych (i który z definicji jest znacznie bardziej istotny niż jakikolwiek kod, który po prostu wysyła zapytanie do bazy danych), ktoś może w pewnych okolicznościach zapomnieć do wykonania tej kopii. Następnie wartości będą się różnić. Mogą też pamiętać o przeprowadzeniu duplikacji, ale nie w ramach transakcji, więc w pewnych rzadkich przypadkach może zostać pominięty. Ale tak naprawdę nie musiałem tracić czasu na pisanie tych przykładów,jeśli coś pójdzie nie tak, to zrobi to.

— Mike Nakis
źródło

12

Myślenie o tym w kategoriach kompromisów zamiast dobrych / złych będzie bardziej produktywne. Wymieniają zalety normalizacji (zwłaszcza spójność) za zalety w użyteczności zapytań.

Z jednej strony baza danych stałaby się bezużyteczna, gdyby dane stały się bardzo niespójne. Z drugiej strony baza danych byłaby bezużyteczna, gdyby ludzie, którzy muszą codziennie przesyłać do niej zapytania, nie mogliby uzyskać wyników, na które mogą liczyć.

Co możesz zrobić, aby zmniejszyć ryzyko i koszty?

Zbuduj narzędzie do sprawdzania spójności i uruchom je regularnie.
Kieruj dostępem do zapisu za pomocą oprogramowania, które konsekwentnie aktualizuje replikowane dane.
Dodaj widoki lub buduj narzędzia do zapytań, które automatycznie łączą się, aby ludzie biznesu mogli myśleć bardziej na podstawie informacji niż elementów wewnętrznych DB.

— Jerry101
źródło

6

Myślę, że najsilniejszym argumentem za normalizacją danych dla analityków biznesowych jest to, że promuje integralność danych. Jeśli twoje kluczowe dane są przechowywane tylko w jednym miejscu (jedna kolumna, w jednej tabeli), jest znacznie mniej prawdopodobne, że dane zostaną uszkodzone przez nieprawidłowe aktualizacje. Myślę, że zapewne by im zależało na znaczeniu integralności danych, więc może to być dobry sposób na przekonanie ich do zaktualizowania sposobów interakcji z bazą danych.

Nieco trudniejsza metoda zapytań będzie prawdopodobnie lepsza niż potencjalne uszkodzenie danych.

— Oleksi
źródło

6

Jego ludzie będą argumentować, że są wystarczająco dobrzy, aby upewnić się, że wszystkie dane są odpowiednio aktualizowane (założenie, które kwestionuję, jeśli są niewygodne przy dołączaniu). Być może lepszym argumentem jest to, że tracisz większość zalet ACID, które zapewniają RDBMS, jeśli unikniesz normalizacji.

— Robert Harvey

4

Prawdopodobnie, ale to wszystko kwestia ryzyka. Czy są gotowi zaakceptować ryzyko uszkodzenia bazy danych, ponieważ ułatwia to zapytania?

— Oleksi

1

Grając tutaj jako adwokata diabła, oczywistym kontrargumentem byłoby to, że jeśli ktoś i tak spieprzy aktualizację i uszkodzi dane, jest to problem z normalizacją lub bez niej - a przynajmniej pewna nadmiarowość w bazie danych zwiększa prawdopodobieństwo że ktoś zauważy uszkodzenie, a może nawet będzie w stanie to naprawić później. (Oczywiście, denormalizacja ad hoc nie jest najbardziej niezawodnym schematem wykrywania błędów, ale zasada sprawdzania błędów za pomocą redundancji jest rozsądna: tak działa podwójna księgowość .)

— Ilmari Karonen

Innymi słowy, integralność danych to coś więcej niż integralność relacyjna. Dzięki w pełni znormalizowanej bazie danych nadal możesz zachować idealną integralność relacyjną, nawet jeśli ktoś pomyśli aktualizację, ale to nie czyni śmieci niepoprawnie aktualizowanymi danymi.

— Ilmari Karonen,

0

Aby dodać do tego, co sugerowali inni faceci powyżej. Jest to kwestia zarządzania danymi. Musisz współpracować z odpowiednimi interesariuszami: architektami danych i zarządcami danych, aby opracować zasady, zasady i konwencje nazewnictwa danych.

Bądź cierpliwy i pracuj metodycznie. Zmiana nie nastąpi w nocy.

— hlosukwakha
źródło

0

Porzucić.

Szczerze mówiąc, możesz spędzać miesiące na kłótniach o normalizację, spójność i zwalczanie szalonych błędów spowodowanych czystym lenistwem, a następnie zrezygnować.

Albo możesz po prostu zaoszczędzić czas, frustrację i rzucić teraz.

Dobrzy programiści to bardzo leniwi ludzie. Rozumieją potrzeby klientów i kierownictwa. Ale co najważniejsze, rozumieją, że dobre rozwiązywanie problemów, stosowanie dobrze zaprojektowanych i dobrze wdrożonych rozwiązań oszczędza im osobiście OGROMNE ilości pracy, wysiłku, a przede wszystkim cierpienia i stresu.

Lepiej byłoby więc pracować w miejscu, które rozumie i ceni dobrą inżynierię.

Powodzenia.

Po namyśle: być może potrzebują narzędzi BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing

— AK_
źródło