더 이상 사용되지 않는 데이터베이스 열을 폐기하는 데 대한 모범 사례는 무엇입니까? [닫은]

초기 단계에서 클라이언트에서 데이터 A, B 및 C를 수집하지만 나중에 데이터 A, B 및 D를 수집하는 응용 프로그램을 설계하고 있습니다.

A, B, C 및 D는 매우 관련이 있으며 현재 단일 데이터베이스 PostgreSQL 테이블 T의 열로 존재합니다 .

C가 더 이상 필요하지 않으면 응용 프로그램에서 참조를 제거하고 싶습니다 ( Django ORM 사용 ).하지만 이미 입력 한 데이터를 유지하고 싶습니다. 가장 좋은 방법은 무엇입니까?

ABD에 대한 새 테이블을 만들려고 생각했지만 테이블 T를 참조하는 행에 문제가 발생할 수 있습니다.

C 열을 그대로두고 코드에서 해당 열에 대한 참조를 제거하여 기존 데이터를 유지할 수 있습니다.

보이지 않는 더 나은 옵션이 있습니까?

몇 가지 추가 정보 :

행 수는 크지 않으며 대부분 사용자 당 1-2입니다. 이것은 대량 시장 응용 프로그램이지만 C에서 D로 전환 할 때까지 사용자 기반은 아직 크지 않습니다. C와 D는 동시에 수집되지는 않지만 가능할 수도 있습니다. C와 D는 각각 하나가 아니라 여러 개의 열을 나타냅니다.

데이터를 유지하려면 더 이상 사용되지 않습니다. 그대로 두십시오. 테이블에 매핑 된 클래스가 모든 열을 매핑하지 않는 경우 좋습니다.

예, 이전 행에는 속성 C가 있지만 새 행에는 없습니다.

이것은 클래스 상속 관계를 갖는 것과 같습니다.

class All
{
    string A;
    string B;
}

class Old : All
{
    string C;
}

class New : All
{
    string D;
}

1 대 1 관계가있는 3 개의 테이블이있는 데이터베이스에서 나타낼 것입니다.

table All
    id varchar
    A varchar
    B varchar

table Old
    id varchar
    C  varchar

table New
    id varchar
    D  varchar

따라서 마이그레이션 스크립트를 작성하여 새 Old 테이블을 작성하고 id 및 C 데이터를 복사 한 후 All 테이블에서 C 컬럼을 제거 할 수 있습니다.

새 sql에서 필요에 따라 코드를 업데이트합니다.

또는 이전 C 데이터를 쿼리 할 수 ​​있어야하는 경우 A, B, C를 사용하여 새 아카이브 테이블을 만들고 모든 데이터를 복사하고 C 열을 제거하고 D 열을 '라이브'테이블에 추가하십시오.

데이터 저장이 문제가 될 수 있으면 테이블을 분할하십시오. 키 / A / B 키 / C 키 / D

뷰 (db의 데이터 위치 정의) 또는 ORM 정의 변경을 통해 액세스를 수행 할 수 있습니다.

이것은 가장 성능이 좋지는 않지만 (결합이 관련되어 있지만) 기본 스토리지를 변경하지 않고 실제 액세스 패턴에 따라 시간이 지남에 따라 A / B / C / D의 조합을 제공 할 수 있습니다.

프로덕션 시스템에서 가동 중지 시간, 테이블 재구성 등을 수행하는 기능에 익숙하지 않을 수 있습니다.

뷰를 통한 액세스를 수행하면 데이터 이동없이 최소한의 변경으로 기본 테이블에서 A / B / C에서 A / B / C / D로 A / B / D로 전환 할 수 있습니다. 뷰는 읽기 로직에 투명하며 dbms가 함수 또는 업데이트 가능한 뷰를 지원하는 경우 쓰기 로직에도 투명합니다.

실제로 귀하의 결정은 1) 데이터 유형 C & D는 무엇입니까 2) C / D를 위해 수집 된 상대 데이터 양 3) 순수한 C 또는 D 항목과 비교 한 C / D 데이터의 상대적 중복 4) 다운 타임 / 유지 보수 기간 가용성 및 지속 기간 5) 업데이트 가능한 뷰에 대한 DBMS 지원 6) ORM에 db 물리적 구조 세부 사항을 유지하고 db에 뷰 / 함수를 통해 제시함으로써 투명성을 확보하는 것이 바람직 함 (모든 액세스에 대해 동일) 현재 응용 프로그램뿐만 아니라 응용 프로그램)

내 대답은 (1)에 대한 대규모 / 복잡한 데이터 유형, (3)에 대한 작은 오버랩 및 (4)에 대한 최소 중단 시간, (5)의 우수한 dbms 지원 및 (6)의 데이터에 액세스하는 여러 응용 프로그램에 이상적입니다.

그러나 많은 대안에 대한 옳고 그름은 없습니다. , 솔루션과 의도 한 목적 / 라이프 사이클에 대해 알고있는 것을 고려하고, 크기 / 볼륨 모델링을 수행하고, 모든 것이 예상대로 바뀔 수는 없으므로 나중에 변경 될 것으로 예상합니다.

참조를 제거하고 데이터를 고아하는 것은 위험이 낮은 옵션입니다.

열을 제거하여 노출해야 할 수도 있고 중요하지 않을 수도있는 알 수없는 '백도어'데이터 사용이 항상 가능합니다.

C 열의 내용에 따라 DB가 내부적으로 전체 테이블 스캔을 수행하거나 옵티마이 저가 인덱스를 사용하는 것보다 더 효율적인 것으로 조인하는 동안 조인 중 전체 테이블을 메모리로 가져 오려고하면 약간의 성능 문제가 발생할 수 있습니다.

응용 프로그램이 선택된 열이 아닌 전체 테이블을 한 번 읽는 것일 수 있습니다. 그러나 ORM을 독점적으로 사용하는 경우에는 그렇지 않습니다.

여기에서 고려해야 할 많은 사항이 있지만 테이블을 직접 변경하지 않고 테이블을 오버레이 할 뷰를 추가하는 것이 좋습니다. 그렇게하면 변경해야 할보기 만 있습니다.

Django ORM을 모르지만 가능성이 있습니다.

• 열 a, b, c가있는 테이블 A가 있습니다.
• 열 a, b, d를 사용하여 새 표 B를 작성하십시오.
• 데이터를 표 B로 마이그레이션하십시오.
• 외래 키를 테이블 A로 이동하여 테이블 B로 이동하십시오.

이제 표 B를 사용할 수 있으며 여전히 참조 할 이전 데이터가 있습니다.