Czy jest jakaś nadzieja na napisanie dobrego kodu na okropnie zaprojektowanej bazie danych?

Oto moja sytuacja. Jeden z kilku programów, które niedawno odziedziczyłem, jest zbudowany ze strasznej bazy danych na backendie. Szanowani twórcy tego najwyraźniej nie docenili koncepcji relacyjnych. Tabela dla każdego klienta, nazwana jako unikalny identyfikator klienta. Osiemdziesiąt trzy pola o kryptonimie nazwanym. Cały kod jest proceduralny z dziesiątkami połączonych wbudowanych instrukcji SQL.

Ponieważ nie otrzymaliśmy ważnej aplikacji pomocniczej działającej z tej samej bazy danych, miałem za zadanie odtworzyć ją od zera. Jestem jedynym programistą, co nie jest nawet moją główną odpowiedzialnością, ponieważ co najmniej połowa mojego czasu jest zajęta operacjami. Jest nieunikniony termin wyznaczony na 30 dni od teraz.

Pomimo mojego braku doświadczenia jestem pewien, że mogłem zaprojektować tę bazę danych i istniejącą aplikację znacznie lepiej niż były, ale nie sądzę, aby realne było modyfikowanie bazy danych, dostosowywanie istniejącej aplikacji i upewnienie się, że nie zrobiłem tego ” t zepsuć wszystko, jednocześnie potrzebując tak szybko utworzyć dodatkową aplikację.

Załóżmy więc, że utknąłem w strasznej bazie danych. Czy potrzebując pracy z tak złą strukturą, czy cokolwiek, co piszę, by się z nią zgadzało, po prostu zwiększyłoby stos zadłużenia technicznego, który miał być odłożony na półkę, aż coś się całkowicie zepsuje lub potrzebna będzie nowa funkcjonalność? Jak podejść do tej sytuacji i wyciągnąć z niej coś dobrego oprócz, mam nadzieję, funkcjonalnej aplikacji?

edytuj: Na wypadek, gdyby ktoś był zainteresowany, złomowaliśmy tę okropną bazę danych i uruchomioną na niej aplikację. Zleciliśmy outsourcing tworzenia aplikacji pomocniczej (nie byłem zaangażowany w konfigurację tego) ostatecznie dwóm różnym kontrahentom, którzy oboje wpadli na nas, nic nie osiągając. Skończyło się na tym, że musiałem spieszyć się z przerażającym, częściowo funkcjonalnym hakiem poprawki w ciągu trzech dni, które są nadal w użyciu.

Jest nadzieja, ale to ciężka bitwa, szczególnie jeśli nikt nie zdaje sobie sprawy, że projektowanie bazy danych jest okropne. Możesz spróbować oderwać nieprzyjemność warstwami abstrakcji, ale są szanse, że nie będzie to warte bitwy.

Moją radą byłoby stworzenie wystarczającej liczby abstrakcji w bazie danych, aby sama aplikacja była czysta i odpowiednio zaprojektowana; W ten sposób, jeśli kiedykolwiek uda się naprawić bazę danych, nie będzie to miało wpływu na aplikację, ponieważ nie ma znaczenia, w jaki sposób baza danych została zaprojektowana.

Jest to podejście, którego zwykle używam, gdy mamy do czynienia z bazą danych, która jest na miejscu i, najczęściej, projektowana z zerową myślą. Kilka wybranych aplikacji wzorców repozytorium lub bramy, z niektórymi warstwami usług do komunikowania się z bramą / repozytorium, powinno pomóc w kwarantannie złego projektu.

Zbuduj warstwę interfejsu, która obsługuje wszystkie elementy DB, a następnie napisz aplikację, aby się z tym współdziałała. W przypadku, gdy baza danych zostanie kiedykolwiek „naprawiona”, wystarczy wymienić / zaktualizować „interfejs”. Takie podejście pozwoliło mi zaoszczędzić mnóstwo czasu, gdy mamy do czynienia ze złą bazą danych lub bazą danych, która zasila inne aplikacje i z którą nie można się pomylić.

Ojej… odziedziczyłeś koszmarny koszmar, masz 30 dni na wykorzystanie go w swojej organizacji, a połowa dnia to zadania operacyjne?

Jestem pewien, że mógłbyś dokonać refaktoryzacji, ale na pewno nie w tak krótkim czasie.

Aby odpowiedzieć na twoje pytanie, nie sądzę, że możesz napisać dobry kod na takim projekcie. Dług techniczny jest już za duży. Gdybym był tobą, włamałbym się do funkcji, które mogłem, i naciskałbym na całkowite przefakturowanie w późniejszym terminie, kiedy masz więcej czasu i ludzi w zespole, aby lepiej rozwiązać ten problem.

Tylko uważaj, pchając do refaktoryzacji. Czasami przełożony podejmie decyzję o zakupie kodu źródłowego produktu i praw własności i nie chce myśleć, że całkowicie zmarnował pieniądze na śmieci. Tak było w przypadku jednej pracy, którą miałem. Niestety, menedżerowie podejmują decyzje o zakupie takiego oprogramowania i nigdy nie angażują się w kwestie techniczne, aby ocenić, co kupują, i sprawdzić, czy jest ono możliwe do utrzymania i ma duże zadłużenie techniczne. W tym przypadku zła decyzja ma charakter polityczny, a naciskanie na refaktoryzację może narazić twoją pracę na niebezpieczeństwo.

Bazy danych można refaktoryzować tak jak inne kody. Napraw część, na którą wpływa kod, który musisz napisać i napisać testy, aby upewnić się, że nic więcej się nie zepsuje. Rób po jednym kawałku, tak jak w przypadku każdego innego refaktoryzacji. Jest dobra książka na temat refaktoryzacji bazy danych, która może pomóc w rozpoczęciu sprzątania bałaganu. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Są też inne, ale ja osobiście przeczytałem i pracowałem z technikami opisanymi w tym.

I nie zapomnij, że możesz zrestrukturyzować sposób, w jaki potrzebujesz przesyłać zapytania do bazy danych, tworząc widoki, aby wykonać paskudną pracę transformacyjną dla Ciebie, w strukturę, która jest łatwiejsza do zapytania.

Aby uzyskać najwyższy zwrot z każdej zainwestowanej złotówki, utwórz widoki, które można aktualizować, aby przywrócić niektóre „relacje” i zapewnić bardziej znaczące nazwy kolumn.

Jedną z możliwości byłoby skonfigurowanie drugiej bazy danych o strukturze (przynajmniej bliżej), jak chcesz, i skonfigurowanie replikacji między dwiema bazami danych. Następnie możesz napisać kod w oparciu o nową bazę danych i nadal pozostawić istniejącą bazę danych (i aplikację) nienaruszoną, aby zająć się nimi, gdy będziesz miał więcej czasu.

Prawdę mówiąc, wciąż pozostaje wiele pytań, czy możesz to zrobić w ciągu ~ 15 dni pracy. W szczególności może to zależeć od tego, czy potrzebujesz dwukierunkowej replikacji (tj. Twoja nowa aplikacja faktycznie zaktualizuje dane), czy tylko w jeden sposób (nowa aplikacja pozwala tylko użytkownikom przeglądać dane). Ten drugi przypadek jest (oczywiście) znacznie łatwiejszy do rozwiązania.

Jeśli potrzebujesz dwukierunkowej replikacji, są szanse, że po prostu nie wystarczy czasu na wykonanie zadania. W szczególności dwukierunkowa replikacja polegająca na istotnym przekształceniu struktury nigdy nie jest trywialna, a dostępne narzędzia często obsługują ją dość słabo (np. Konieczność ręcznego pisania całego kodu SQL dla wszystkich transformacji danych w obu kierunkach).

Jeśli potrzebujesz tylko w jedną stronę, to jest to w momencie, w którym może to być możliwe. Zależy to również w dużej mierze od tego, czy możesz wydawać pieniądze, czy nie - istnieje wiele aplikacji do hurtowni danych, które są przeznaczone właśnie do tego rodzaju zadań, co prawdopodobnie uczyniłoby to nieco szybszym i łatwiejszym zarządzać - ale większość z nich nie jest tania.