0
로깅 데이터베이스를 개발할 때이 경우 기록되는 구성 요소의 ID는 데이터베이스 자체는 아니지만 보고서를 보내는 시스템이 결정합니다. 시스템 ID는 고유 한 varchar이며 구성 요소의 id는 시스템에 의해 (일부 먼 위치에서) 결정되므로 구성 요소의 기본 키가 system_id + component_id 일 때 고유성이 보장됩니다.MySQL의 varchar 및 복합 기본 키?
이 접근 방식이 효율적 일지 궁금합니다. id로 자동 증가 정수를 사용할 수는 있지만 삽입하기 전에 선택 작업을 수행해야한다는 의미이므로 시스템에서 제공하는 이미 알려진 문자열 ID를 사용하는 대신 생성 된 ID를 얻을 수 있습니다.
데이터베이스는 소수의 구성 요소가있는 수십 개의 시스템과 구성 요소 업데이트 (다른 테이블)가 수천 개에 불과한 규모가 작습니다. 이전 업데이트는 주기적으로 파일에 덤프되고 데이터베이스에서 제거되므로 "큰"업데이트를 얻지는 않습니다.
추천?
몇 가지 테스트를했는데 데이터베이스는 수십만 개의 component 및 component_update 행 (무작위로 생성)으로 정상적으로 수행됩니다. 그것은 각 테이블의 각 10,000 행에 대해 약 1MB를 측정 했으므로 크기가 좋을 것으로 예상됩니다. 조인을 더 많이 수행하고 요청 당 선택하는 작업을 절약 할 수 있습니다. ID의 크기를 32 및 64 자로 제한했지만 객체 이름은 대개 16 자 미만입니다. – elite5472