Refaktoryzacja lub aktualizacja baz danych w celu obsługi nowych funkcji

W kilku odpowiedziach na pytanie dotyczące schematu bazy danych zasugerowano dodatkową tabelę w celu znormalizowania bazy danych dla funkcji, która nie jest częścią bieżących wymagań (tabela UserDepartment, która pozwala na relacje wielu pracowników / użytkowników i różnych działów, które mogą należeć do.).

Nie przeciw normalizacji. Wydaje się, że jeśli chodzi o projektowanie baz danych, istnieje silny nacisk na włączenie funkcji, których „pewny” ktoś będzie chciał w przyszłości. Czy tak trudno jest dodawać tabele / pola do bazy danych, aby uwzględnić funkcje, że istnieje tendencja do nadmiernej inżynierii? Czy nie byłyby one refaktoryzowane lub uaktualniane tak jak reszta aplikacji, jeśli to konieczne? Ponawianie czynności nigdy nie jest przyjemne, ale można przenosić dane z jednej tabeli do nowej. Po prostu nie jestem pewien, gdzie zakończy się ta myśl.

Edycja: Jest w tym tyle awersji, zastanawiam się, ile projektów ostatecznie nie dodaje funkcji wymagającej drastycznej zmiany bazy danych lub są to podejścia niestandardowe, takie jak dodanie pola DepartmentID2 zamiast nowej tabeli. Potrzeba wielu działów dla pracownika jest częstym problemem domenowym. Po prostu nie zauważyłem wielu schematów baz danych zaśmieconych relacjami wiele do wielu.

Jest cała książka o refaktoryzacji baz danych. Podobnie jak w przypadku refaktoryzacji kodu, istnieją standardowe sposoby refaktoryzacji bazy danych. Jedyną różnicą jest to, że podczas refaktoryzacji kodu nie musisz brać pod uwagę stanu obiektu / kodu, podczas gdy w bazach danych musisz brać pod uwagę dane, ponieważ utrata danych nie jest dobra dla użytkowników (ani dla nikogo, w rzeczywistości ).

Możesz przeczytać więcej o refaktoryzacji bazy danych tutaj .

Refaktoryzacja kodu jest łatwa - wystarczy zmienić kod i uruchomić testy regresji.

Refaktoryzacja baz danych jest trudna - musisz przenosić (potencjalnie ogromną ilość) danych, upewnij się, że żadna z nich nie została usunięta, upewnij się, że ograniczenia są zachowane w nowym schemacie. A jeśli masz wymagania dotyczące audytu danych, musisz być w stanie wyjaśnić, dlaczego są one inaczej zorganizowane, i być w stanie dopasować dane sprzed refokatora do danych po refaktorze. Ponadto żadne stare kopie zapasowe nie będą pasować do nowego schematu, co stanowi kolejne ryzyko.

Straszna rzecz.

Istnieje spora granica między spędzaniem dużej ilości czasu na nadmiernej inżynierii a inwestowaniem czasu, aby dodać tylko tyle funkcji, aby zaoszczędzić znaczną ilość czasu w przyszłości.

Myślę, że teoria jest taka, że ​​jeśli dodasz tabelę linków do obsługi relacji wiele do wielu między 2 tabelami, to nawet jeśli tak naprawdę w danych istnieje tylko relacja wiele do jednego, wszyscy napiszą SQL w taki sposób, że jeśli kiedykolwiek wielu do wielu jest obsługiwanych, wszystko „po prostu działa”.

W praktyce zwykle nie stwierdziłem, że to prawda, ale przypuszczam, że SQL jest bliższy temu, co musi być, aby obsługiwać wielu do wielu, niż byłoby to możliwe.

Ale aby przejść do konkretnego pytania, w rzeczywistości istnieje spory ból powodujący konwersję związku z 1 na wiele do wielu na wiele. Powodem jest to, że SQL nie jest zaprojektowany z takimi samymi celami enkapsulacji jak obiekty, a większość zapytań wykorzystuje więcej tabel w warstwie bazy danych, niż ludzie mogliby widzieć, mając obiekt w warstwie biznesowej.

Dlatego zmiana relacji wiele do wielu wpłynie na każde zapytanie obejmujące oryginalne 2 tabele, często znacznie szerszy efekt kaskadowy niż na warstwie biznesowej. Dlatego ludzie dokładają wszelkich starań, aby temu zapobiec.

IMHO nie byłoby to konieczne, gdybyśmy mieli lepszy język niż SQL do określenia algebry relacyjnej. Gdyby było możliwe zbudowanie zapytania SQL kawałek po kawałku według obiektów, które nie wymagałyby widoczności każdej tabeli w zapytaniu, nie byłoby to możliwe. Rzeczy takie jak LINQ (do SQL lub Entities) próbują rozwiązać ten problem, ale jest to bardzo złożone rozwiązanie i trudne do optymalizacji (i byłem w grupach użytkowników DBA, w których wspomniano o LINQ i za każdym razem narastał zbiorowy jęk). Marzę o języku bazy danych, który jest powszechnie obsługiwany z pierwszorzędnymi funkcjami algebry relacyjnej ...

W międzyczasie tak, możesz refaktoryzować od 1 do wielu do wielu do wielu, ale może to być dużo pracy.

Zazwyczaj tłumaczę to w ten sposób PHB - kod to ściany i dach, baza danych to podstawa.

Przesuwanie ścian i zmiana dachu można wykonać. Zmiana fundamentu wymaga dużo kopania i przebudowy ścian i dachu.

To, co mówią niedoświadczeni programiści (i profesorowie college'ów), to „nadmierna inżynieria” - to, co doświadczeni programiści nazywają „próbą przyszłości”. Pomimo tego, co mówi specyfikacja, wiesz, co prawdopodobnie zmieni się podczas ALM lub gdzie wystąpią problemy z wydajnością, więc chcesz od razu zacząć budować swoją strukturę tabeli.

Wdrażanie skryptów aktualizacji na serwery klientów to nietrywialny projekt, a DBA każdego klienta są wszędzie, aby potroić to wszystko. Niektóre dodatkowe kolumny i tabele wcale nie są takie złe.

Ogólna zasada jest taka, że ​​relacja jest relacją jeden do jednego, ale w przyszłości może być wiele do wielu, a następnie uczynić z niej wiele do wielu.

Pracownik / dział jest klasycznym przykładem. W większości małych firm jest to zazwyczaj relacja jeden do wielu przez większość czasu . Jednak prawie zawsze zdarza się, że staje się wielu do wielu - jeden z inżynierów przechodzi do zarządzania, ale nadal jest odpowiedzialny za wspieranie produktu, który opracował, gdy był inżynierem, lub jeden z sprzedawców przeniósł się do rozwoju produktu, ale ponieważ ma bliskie relacje z ważnym klientem, nadal jest głównym sprzedawcą tego klienta.

Nie kosztuje dużo więcej, jeśli jeden do wielu jest implementowany jako wiele do wielu - ale refaktoryzacja bazy danych i aplikacji do obsługi wielu do wielu jest kosztowna i trudna.

Istnieją dwa sposoby spojrzenia na projektowanie oprogramowania (i prawdopodobnie wiele innych rzeczy) - widok taktyczny lub widok strategiczny. Każdy ma swoje zalety i wady.

Nawet przy modyfikacjach oprogramowania OO wciąż jest to problem, nie tylko część kodująca jest trudna, ale proces promowania zmiany w produkcji w środowiskach reklamacyjnych (biorąc pod uwagę obecny stan techniki) jest nierealny dla dużych systemów, które powinny być pracuje 24/7.

Postępuję zgodnie z moją zasadą: „ Jeśli to możliwe, strategicznie projektuj wspólne artefakty oprogramowania ” - To może brzmieć, jakby w jakiś sposób było sprzeczne z zasadą YAGNI, jednak taka jest moja opinia. Takie podejście gwarantuje mniej przeróbek związanych z kosztami złożoności i zasobów.

W twoim przypadku działania wymagane do dodania nowej tabeli połączeń obejmowałyby: projekt, zatwierdzenie projektu, zmianę schematu, przepisanie kilku metod CRUD dla 3 tabel (z wyjątkiem niektórych odczytów), budowanie indeksów, tworzenie GUI dla CRUD dla nowej tabeli, aby umożliwić użytkownikowi wybór PK podczas tworzenia, aktualizacji nowej tabeli itp. A tak przy okazji, nie zapomnij o testowaniu jednostkowym, testowaniu akceptacji użytkownika, testowaniu systemu i promocji produkcji.

Jeśli to nie wystarczy, prawdziwy koszmar pochodzi z utraty informacji. Jeśli nie miałeś na początku tabeli skrzyżowań i postanowiłeś uchwycić daty, w których nastąpiło powiązanie / separacja między pracownikiem a działem, nie będziesz w stanie automatycznie wypełnić daty w tabeli skrzyżowań. Musisz wprowadzić je ręcznie (jeśli masz dane).

Lepiej więc przewidzieć to od samego początku.

Jak powiedział Matthew powyżej, refaktoryzacja / zmiana baz danych jest często bardziej zaangażowana w porównaniu z oprogramowaniem, ponieważ należy również wziąć pod uwagę zarządzanie danymi. Istnieją techniki, które mogą pomóc np. Upewnić się, że masz odpowiedni pakiet testów jednostek bazy danych, oddzielić aplikacje klienckie od podstawowego schematu za pomocą „DB API” - sproki / widoki itp.