최근에 MySQL 데이터베이스에 내역 데이터를 저장하는 것이 가장 좋습니다. 현재 버전 별 테이블에는 valid_from 및 valid_to 두 가지 열이 있으며 모두 DATETIME 유형입니다. 현재 데이터가있는 레코드의 생성 일은 valid_from입니다. 이 행을 업데이트 할 때 업데이트 날짜가 valid_to으로 채워지고 이전 행의 valid_to과 동일한 valid_from이라는 새 레코드를 추가합니다. 그러나 나는 테이블이 매우 빨라 데이터를 가져 오는 것이 매우 느릴 수 있다는 것을 알고 있습니다.
이전 데이터를 저장하는 관행이 있는지 알고 싶습니다.MySQL 데이터베이스의 내역 데이터를 사용한 모범 사례
"큰"테이블과 성능에 대해 걱정하는 것은 일반적인 실수입니다. 인덱스를 사용하여 데이터에 액세스 할 수 있다면 1000000 개의 레코드가 1000 개라도 상관이 없습니다. 적어도 측정 할 수있는 수준은 아닙니다. 언급 한 디자인은 일반적으로 사용됩니다. 시간이 비즈니스 로직의 중요한 부분 인 곳은 훌륭한 디자인입니다.
예를 들어, 고객이 주문한 시점의 가격이 얼마인지 알고 싶다면 valid_from < order_date 및 valid_until이 null이거나 order_date 인 제품 레코드를 검색 할 수 있습니다. 가장 쉬운 솔루션.
항상 그런 것은 아닙니다. 아카이브 목적으로 만 데이터를 보관한다면 아카이브 테이블을 만드는 것이 더 바람직 할 수 있습니다. 그러나 시간이 인 경우이 비즈니스 로직의 일부가 아닌지 확인해야합니다. 그렇지 않으면 여러 테이블을 검색 할 때의 어려움이 심각합니다. 제품 테이블 또는 product_archive 테이블을 찾을 때마다 검색해야한다고 상상해보십시오. 주문이 접수 된 시점의 제품 가격에 대해
이것은 완전한 답변이 아니며 몇 가지 제안입니다.
is_valid과 같은 색인 된 부울 필드를 추가 할 수 있습니다. 이렇게하면 과거 및 현재 레코드가있는 큰 테이블의 성능이 향상됩니다.
일반적으로 과거 데이터를 seprate 테이블에 저장하면 응용 프로그램이 복잡해질 수 있습니다. 현재의 기록과 기록이 혼합 된 데이터를 가져 오는 것으로 가정되는 복잡한 쿼리를 상상해보십시오.
오늘 컴퓨터는 정말 빠릅니다. 나는 당신이/단일 테이블과 과거 기록에 대한 별도의 테이블과 성능을 비교/테스트해야한다고 생각합니다.
또한 하드웨어를 테스트하여 데이터베이스를 설계하는 방법을 결정하기 위해 MySQL이 얼마나 큰 테이블인지 확인하십시오. MySQL의 구성을 조정할 수 있습니다 (캐시/RAM 증가로 시작).
정확히 이것을 수행하는 응용 프로그램이 완료 될 예정입니다. 대부분의 색인은 키 필드별로 먼저 색인을 만들고 valid_to 필드는 현재 레코드를 NULL으로 설정하여 현재 레코드를 쉽고 빠르게 찾을 수 있도록합니다. 대부분의 응용 프로그램은 실시간 작업을 처리하므로 인덱스는 빠른 성능을 제공합니다. 가끔씩 누군가가 과거 기록을 볼 필요가 있고, 그 경우에는 실적이 좋지만, 테스트에서부터 대부분의 기록은 평생 동안별로 많은 변화가 없으므로별로 나쁘지 않습니다.
현재 레코드가 아닌 다양한 키의 만료 된 레코드가있는 경우 키 필드가보다 앞에 의 인덱스로 지불 할 수 있습니다.
보관 처리를 수행합니다. 즉, 이전 데이터를 다른 테이블로 이동하고 현재 테이블을 최신 상태로 유지합니다. –
@PradeepPati 역사적인 데이터와 현재 데이터를 모두 선택할 수있는 쿼리가 필요한 경우 응용 프로그램이 엄청나게 복잡해집니다. 그러나 그는 역사적인 테이블과 현재 테이블을 "병합"할 수있는 뷰를 만들 수 있습니다. – Kamil
@ 카밀 (Kamil) 아무 것도 복잡하게 만들지 않고 앱을 정상적으로 유지합니다. 당신은 역사가 필요합니다, 당신은 역사표에 가셔야합니다, 현재 데이터가 필요합니다, 현재 테이블로 가십시오. –