버전 제어 독립 레코드 및 구성을 기반으로 모든 레코드 나열

버전 제어 독립 레코드 및 구성을 기반으로 모든 레코드 나열

저는 이 두 가지 질문을 읽었습니다.

레코드 변경 내역을 추적할 수 있는 MySQL 옵션/기능이 있습니까?

데이터베이스에서 레코드를 버전 제어하는 방법

저는 버전 시스템이 어떻게 작동해야 하는지 이해했지만 제 상황에 대해 특별한 질문이 있습니다.

예를 들어 다음 표가 있습니다.

이 테이블에 약 4000개의 레코드가 있다고 가정해 보겠습니다.사전 설정된 구성을 기준으로 사용자에게 100개의 레코드를 한 번 표시합니다. 예를 들어 레코드 A 값이 foo인 모든 레코드를 표시합니다.

이제 사용자는 100개의 레코드 중 하나를 변경할 수 있습니다. 예를 들어, 4개의 레코드를 변경하고 나머지 96개의 레코드는 변경하지 않은 상태로 둡니다.

제 질문은:

사용자가 사전 설정된 구성에서 4개의 레코드만 변경하는 경우 변경 내용을 추적하는 가장 좋은 방법은 구성 추적(변경 전 특정 날짜에 100개의 레코드가 표시된 방식)입니다.

다른 테이블의 구성을 추적하기 위해 start_date 및 end_date 필드를 추가할 수 있지만 특정 날짜의 구성이 어떻게 보이고 해당 날짜 이후 버전에 따라 어떤 레코드가 변경되었는지 알기 위해 4개의 레코드만 변경된 100개의 레코드로 테이블을 채우는 것은 옳지 않다고 생각합니다.마지막으로 날짜 필드만 다른 수백 개의 중복된 콘텐츠를 제공합니다.이 상황에 대한 이상적인 해결책은 무엇입니까?

---

나중에 편집:주요 아이디어는 다음과 같은 것을 얻는 것입니다.

특정 생성 날짜부터 각 구성 버전(버전 1, 2, 3, 4)을 볼 수 있기를 원합니다.각 구성에는 이전 구성 버전의 이전 행 + 새 버전에서 사용자가 수정한 행이 포함됩니다.

우리의 채팅 토론과 이 링크를 토크 포인트로 고려하면,

다음 스키마를 고려하고 확장합니다.

-- drop table bom
create table bom
(   -- Bill of Materials
    bomId int auto_increment primary key
    -- other high level fields
);

-- drop table bomVersion
create table bomVersion
(   -- Bill of Materials / version
    id int auto_increment primary key,
    bomId int not null,
    -- other high level fields
    version int not null, -- you need to figure out how to increment this, and it is not an auto inc here
    description varchar(1000), -- ie: let's add a Floppy Drive
    creationDate datetime not null,
    unique key(bomId,version),  -- no dupes
    -- yes, (bomId,version) could be the PK but I chose not to
    CONSTRAINT fk_version_bom FOREIGN KEY (bomId) REFERENCES bom(bomId)
);

-- drop table bvDetails;
create table bvDetails
(   -- Bill of Materials / Version / Details
    id int auto_increment primary key,
    bvId int not null,
    lineNumber int not null, -- if ordering is important
    partId int not null,
    qty int not null,   --  I am no BOM expert, is this stuff in there?
    price decimal(12,2) not null, --    I am no BOM expert, is this stuff in there?
    -- FK constraints back to Part table and bvId, below shows one of them
    CONSTRAINT fk_det_bomversion FOREIGN KEY (bvId) REFERENCES bomVersion(id)
);

가장 큰 문제 중 하나는 부품 설명의 변경 사항이 변경된 경우 이를 캡처하는 방법입니다.맨 위의 링크에서, 해당 케이스 SX1040의 설명이 간편 액세스에서 간편 액세스/웰벤트로 변경된 경우.

따라서 이 경우 BOM(ISO 표준에 의해 고정되어야 하는)의 재인쇄가 변경됩니다.그것은 좋지 않다.따라서 텍스트 행에 대한 변경 내역을 감사하고 감사한 후 해당 ID를 저장해야 합니다(예: 부품 번호).확실히 말하자면, 당신이 가질 수는 있지만,Parts테이블, 또한 가지고 있습니다.PartsHistory표(그리고 후자의 ID는 폭탄에 들어갑니다).

위 스키마처럼 price와 qty 같은 숫자는 저장하기에 멋집니다.문제가 되는 것은 텍스트 히스토리 변경이며, 이전 단락에서 설명한 대로 해결해야 합니다.

---

참고로, 저는 텍스트 열이 변경된 경우 모든 수정사항을 동일한 테이블에 유지하고 하나의 행(예: 해당 부분)만 활성으로 표시하는 시스템을 작성한 적이 있습니다='지정된 항목에 대해 Y'를 지정합니다.이렇게 하면 다른 기록 테이블에 조인할 필요가 없습니다.어느 쪽이든 GUI를 통해 원하는 버전을 선택할 수 있습니다.감사 관점에서 이러한 테이블에는 updateBy(personId)와 updateDt가 있어야 합니다.

편집

질문이 방금 바뀌었습니다.의 새 열bomVersion

언급URL : https://stackoverflow.com/questions/33812121/version-control-independent-records-and-list-them-all-base-on-a-configuration