Jakie są najlepsze praktyki dotyczące wycofywania przestarzałych kolumn bazy danych? [Zamknięte]

Projektuję aplikację, która na wczesnym etapie będzie zbierać dane A, B i C od klientów, ale później będzie zbierać dane A, B i D.

A, B, C i D są bardzo powiązane i obecnie istnieją jako kolumny pojedynczej bazy danych tabeli T PostgreSQL .

Gdy C nie będzie już potrzebny, chcę usunąć jego odwołania z mojej aplikacji (korzystam z Django ORM ), ale chcę zachować dane, które zostały już wprowadzone. Jak najlepiej to zrobić?

Myślałem o utworzeniu nowej tabeli dla ABD, ale to oznacza, że ​​może to powodować problemy z dowolnymi wierszami odwołującymi się do tabeli T.

Mógłbym po prostu zostawić kolumnę C razem i usunąć odniesienia do niej w kodzie, pozwalając na przetrwanie istniejących danych.

Czy jest lepsza opcja, której nie widzę?

Kilka dodatkowych szczegółów:

Liczba wierszy nie będzie duża, najprawdopodobniej 1-2 na użytkownika. Jest to aplikacja na rynek masowy, ale zanim przejdę z C do D, baza użytkowników nie będzie jeszcze bardzo duża. C i D prawdopodobnie nie zostaną zebrane w tym samym czasie, chociaż jest to możliwe. C i D prawdopodobnie reprezentują wiele kolumn, a nie tylko jedną.

Jeśli chcesz zachować dane, nie są one przestarzałe. Po prostu zostaw to tam, gdzie jest. W porządku, jeśli jakaś klasa odwzorowana na tabelę nie odwzorowuje każdej kolumny.

OK, więc twoja sytuacja jest taka, że ​​chcesz, aby stare wiersze miały właściwość C, ale nowe nie.

Jest to równoważne z relacją dziedziczenia klas

class All
{
    string A;
    string B;
}

class Old : All
{
    string C;
}

class New : All
{
    string D;
}

który reprezentowałbyś w bazie danych za pomocą trzech tabel z relacjami 1 do 1

table All
    id varchar
    A varchar
    B varchar

table Old
    id varchar
    C  varchar

table New
    id varchar
    D  varchar

Aby można było utworzyć skrypt migracji w celu utworzenia nowej Starej tabeli, skopiuj do niego dane identyfikatora i C i usuń kolumnę C z tabeli Wszystkie.

Aktualizowanie kodu zgodnie z wymaganiami w nowej wersji SQL;

Alternatywnie, jeśli potrzebujesz tylko zapytania o stare dane C, możesz utworzyć nową tabelę archiwizacji za pomocą A, B, C skopiować wszystkie dane i usunąć kolumnę C, dodaj kolumnę D do tabeli „Na żywo”

Jeśli przechowywanie danych może stanowić problem, podziel tabele: klawisz / klawisz A / B / klawisz C / D

Dostęp można wykonać za pomocą widoku (definicja lokalizacji danych w bazie danych) lub poprzez zmianę definicji ORM.

Nie jest to najbardziej wydajne (wiąże się to z łączeniem), ale może przedstawiać dowolną kombinację A / B / C / D w czasie bez zmiany podstawowej pamięci i w zależności od rzeczywistych wzorców dostępu może być wystarczające.

Możesz nie mieć szczęścia do możliwości przestoju, restrukturyzacji tabel itp. W systemie produkcyjnym.

Wykonywanie dostępu za pośrednictwem widoku umożliwia przełączanie z A / B / C na A / B / C / D na A / B / D w podstawowej tabeli przy minimalnej zmianie i bez przenoszenia danych. Widok będzie przezroczysty dla logiki odczytu, a jeśli dbms obsługuje albo funkcje, albo aktualizowalne widoki, będzie również przezroczysty dla logiki zapisu.

Naprawdę myślę, że twoja decyzja będzie odzwierciedlać wiele rzeczywistych problemów: 1) jakie są typy danych C i D 2) względne objętości danych zebrane dla C / D 3) Względne nakładanie się danych C / D w porównaniu do wpisów czysto C lub D 4) Dostępność i czas trwania okna przestoju / konserwacji 5) Obsługa DBMS dla aktualizowalnych widoków 6) Konieczność przechowywania szczegółów struktury fizycznej db w ORM w porównaniu do uczynienia go przejrzystym poprzez prezentację poprzez widoki / funkcje w db (gdzie jest taki sam dla wszystkich osób uzyskujących dostęp aplikacje, nie tylko bieżąca)

Moja odpowiedź preferowała duże / złożone typy danych dla (1), niewielkie nakładanie się dla (3) i minimalne przestoje dla (4), idealnie z dobrą obsługą dbms w (5) i wieloma aplikacjami uzyskującymi dostęp do danych w (6)

Ale nie ma dobrego / złego dla wielu alternatyw: - zacznij od A / B / C, później dodaj D, dostosowując ORM, jeszcze później upuść kolumnę C - zacznij od A / B / C / D i zignoruj ​​wartości zerowe itp. Myślę, że , zastanów się nad swoim rozwiązaniem i tym, co wiesz o jego przeznaczeniu / cyklu życia, wykonaj modelowanie wielkości / objętości i spodziewaj się zmiany rzeczy później, ponieważ nie wszystko zmieni się zgodnie z oczekiwaniami.

Usuwanie referencji i osierocanie danych jest opcją niskiego ryzyka.

Zawsze możliwe są nieznane zastosowania danych typu „backdoor”, które mogą, ale nie muszą być istotne do ujawnienia przez usunięcie kolumny.

W zależności od zawartości kolumny C może wystąpić niewielki problem z wydajnością, gdy DB wewnętrznie wykonuje pełne skanowanie tabeli lub próbuje wciągnąć całą tabelę do pamięci podczas łączenia, jeśli optymalizator uzna to za bardziej wydajne niż użycie indeksów.

Aplikacje mogą czytać cały stół zamiast wybranych kolumn - ale jeśli używasz wyłącznie ORM, jest to mało prawdopodobne.

Wiele rzeczy do rozważenia tutaj, ale możesz rozważyć dodanie widoku do nakładania się na tabelę zamiast wprowadzania zmian bezpośrednio w tabeli. W ten sposób tylko widok musi się zmienić.

Nie znam Django ORM, ale może być taka możliwość.

• Masz tabelę A z kolumnami a, b, c.
• Utwórz nową tabelę B z kolumnami a, b, d.
• Przeprowadź migrację danych do tabeli B.
• Przenieś swoje klucze obce do tabeli A do tabeli B.

Możesz teraz użyć tabeli B i nadal masz swoje stare dane w celach informacyjnych.