Poprawienie bazy danych

Jest aplikacja na produkcji od 5. lat i jej baza jest zrobiona bez sensu,
tzn bardzo dużo pól które muszą być wypełnione nie jest 'not null' .
Dodatkowo posiada w niektórych tabelach dane które nie mają sensu ze względu na dane w innej tabeli(brak constraintów).

Zakładając poprawienie aplikacji tak żeby nie wpisywała bzdur, wjaki sposób tak poprawić bazę dodając jej te wszytkie ograniczenia żeby stare dane(błędne) nie przeszkadzały?
Czy jedynym wyjściem jest wywalenie wszytkich danych które są niepełne, lub długie rozkminianie co wstawić w puste pola?

Jak się powinno takie modyfikacje na bazie robić w praktyce?

Chodzi o to, że baz jest zrobiona źle, a chciałbym ją zrobić żeby była bardzo dobrze.
Dodałem już indeksy i widoki po czym działa to wszytko znacznie szybciej, ale dalej to wszytko jest bez sensu.

W takiej sytuacji najlepszym rozwiązaniem wydaje mi się zaprojektowanie nowej bazy i migracja danych. Oczywiście takiej operacji nie da się przeprowadzić ad hoc, trzeba wszystko dokładnie przemyśleć

A są jakieś schematy zachowań, co robić z niepełnymi, lub błędnymi danymi(tzn jedno pole jest puste a nie powinno, lub prawidłowy constraint powodowałby na jakichś danych problemy)?
Może trzymać je w osobnej tabeli 'legacy_coś' dopóki się nie przeterminują, albo mieć podłączone 2 bazy w pkresie przejściowym?
Pytam się, bo nie chciałbym sam wymyślać rozwiązań kiedy na penwno wiele razy taki problem był rozwiązywany i ipewnie istnieją jakieś ogólne wytyczne czego robić, a czego na pewnoe nie nie robić.

Okazało się, że źle szukałem.

Jak zacząłem szukać dobrze znalazłem coą takiego(może komuś się przyda):
http://agiledata.org/essays/databaseRefactoring.html

Szczególnie ważna wydaje się część 4.1.4

Poczytaj o postaciach normalnych oraz normalizacji relacji (tabel), musisz doprowadzić tablę przynajmniej do postaci BCNF i jeżeli nie będzie występowała redundancja przy obecnie przechowywanych danych to w przyszłości raczej będzie ok.

Duża.TajemnicaWiedzy napisał(a):

Zakładając poprawienie aplikacji tak żeby nie wpisywała bzdur, wjaki sposób tak poprawić bazę dodając jej te wszytkie ograniczenia żeby stare dane(błędne) nie przeszkadzały?
Czy jedynym wyjściem jest wywalenie wszytkich danych które są niepełne, lub długie rozkminianie co wstawić w puste pola?

A jaki jest charakter tych danych? Czy mogą po prostu przyjąć wartości domyślne? Czy jest możliwe wyznaczenie brakujących danych automatycznie, czy np. musiałby to zrobić człowiek?

Dane możesz:

• oczyścić automatycznie (np. ustandaryzować pole "płeć", zamienić wartości nieprawidłowe na jakieś arbitralnie wybrane)
• uzupełnić automatycznie (tam gdzie ich nie ma spróbować znaleźć poprawne wartości - np. płeć na podstawie imienia i nr pesel)
• wprowadzić okres przejściowy (np. utrzymywać stare i nowe pole, przy zapisie wymagać od użytkownika uzupełnienia brakujących/poprawienia niewłaściwych pól, w momencie gdy dane są poprawione oznaczasz rekord jako "sprawdzony")
• przygotować zestawienia i narzędzia do ręcznej korekty (np. lista klientów ze złym nr pesel)

To powyższe ma sens jeśli masz dostęp do kodu aplikacji i możesz go poprawić.
Bo jeśli aplikacja nadal będzie wprowadzać błędne / niepełne dane to ma to mały sens.

Część danych da się poprawić automatycznie, część jest całkiem bez sensu, część jest dobra, tylko nie znormalizowana.
Z tymi nie ma problemu.

Problem stanowią dane niepełne
np. System opłat zapisuje dane na podstawie których dana instutucja ma zapłacić za używanie systemu(lub innej za dane), ale w bazie nie jest wypełniopne kto ma płacić lub komu.
To są ważne dane, ale bez logów(bo tych już nie ma) nawet człowiek sobie nie poradzi i dane są bezużyteczne a opłaty(ok 140k$ łącznie) zwyczajnie wyparują jak się to usunie.

Innym problemem są dane gdzie z braku constraintów są one sprzeczne(wg logiki aplikacji opisanej w UC).

Jest też część danych które nie wiadomo zupoełnie do czego są, a nikt z twórców systemu nie pracuje już nad tym systemem.
Te trzeba będzie rozkminiać na podstawie samego kodu.

Ogólnie straszne to bagno, ale im później się zacznie coś z tym robić, tym gorsze bagno to będzie.

W ostatecznośći zostaje jeszcze rozwiązanie polegające na wywaleniu wszytkich problematycznych danych z nadzieją, że nikt nie zauważy(w korpo jest na to jakieś 90% szans), ale to dalej słabo.

Przy sprzeczności/brakujących danych możesz spróbować wymyśleć jakąś heurystykę. Przykład:

• gdy nie ma zdefiniowanego płatnika, ale przez ostatnie 3 miesiące kasa przychodziła tylko od jednego klienta, to klient ten może zostać uznany za płatnika dla konta i przypisany do niego.

Takie przypisanie automatyczne powinno być:

• rejestrowane (np. w dzienniku procesu)
• odwracalne (gdyby automat się pomylił)

Może też być kilkuetapowe, np:

• wnioskowanie: generacja danych takie jak automat myśli że pownny być
• weryfikacja: sprawdzenie ręczne / automatyczne czy po korekcie dane będą spójne
• akceptacja i wykonanie modyfikacji

Znam przypadek systemu, w którym w podobnej sytuacji pozostawiono dwie bazy i aplikacja obsługiwała obie. Nowe dane trafiały do nowej, a stare ciągle mogły być przeglądane i edytowane w starej. Co prawda wymaga to utrzymywania starego kodu i przypięcia go do nowej aplikacji, ale jak się sensownie zaprojektuje aplikację, to nie powinno być specjalnie trudne. Za to jest pewniejsze w działaniu niż wymyślanie jakichś algorytmów i obejść w celu doprowadzania starej bazy do porządku.

@Duża.TajemnicaWiedzy: żeby coś poprawić trzeba to najpierw poznać i zrozumieć. Wywalenie i czekanie na zgłoszenie jest ostatecznością - jak napisałeś.

Dzięki.
Na tym się pewnie skończy, że będą przez jakiś czas 2. bazy, przy czym nowe dane(i to co się da łatwo przenieść) będą trafiały tylko do nowej(bo na szczęście dostęp do kodu mam aplikacji).
Ustali się z klientem(to niestety potrwa) jakąś datę odcięcia starej.
A co do tych 140k$ które i tak teraz "wiszą w próżni" bo nie wiadomo kto ma komu płacić decyzję trzeba będzie przepchnąć na klienta.

BTW:
Co do postaci normalnych to wiem czym są i po co są, ale faktycznie znam tylko nazwy numeryczne i nie pamiętam dokładnie wymagań na poszczególne poziomy.

@Marcin.Miga
Niestety tak dobrze nie ma :)

D.użaTajemnicaWiedzy tak z czystej ciekawości, kwoty które się tutaj przewijają nie wyglądają na małe i to wszystko działa tak na zasadzie "nie wiadomo kto komu ale wiadomo że ktoś coś komus"? Nie mówie o Tobie, bo widzę, że szukasz rozwiązania itd, ale jak to działało przez 5 lat?

A bo ja wiem jak to działało.
Po prostu ktoś kiedyś napisał system, później 2 inne firmy go modyfikowały, a właściciel nie zna się lub nie interesuje za bardzo.
Jest spora szansa, że albo nikt nie wie co się dzieje, albo ktoś wie, ale woli się nie dotykać bo jakiś kierownik go zbeszta, bo nikt nie lubi posłańców złych wiadomości.
Nie mam pojęcia jak to audyty przechodzi ale podejrzewam, że nikt tego tak na prawdę nie sprawdza albo sprawdzający dostaję w łapę.

Ta kasa to jest przybliżona suma opłat w których nie wiadomo kto lub komu, bo są jeszcze opłaty dobrze uzupełnione, i tych jest więcej, ale nie liczyłem.