디렉토리와 파일의 파일 시스템 계층 구조를 저장하고 있습니다.데이터 테이블과 검색 테이블을 동시에 계단식으로 삭제하십시오.
innodb 테이블에서 각 디렉토리/파일의 세부 정보를 저장하고 삭제할 때 종속 될 외래 키 제약 조건과의 상위 하위 관계를 유지합니다.
myisam 테이블은 전체 텍스트 검색으로 이러한 디렉토리/파일을 검색하는 데 사용됩니다. 여기에는 각 행의 이름과 ID가 들어 있습니다.
데이터 테이블 (innodb 테이블)의 모든 행은 검색 테이블 (myisam 테이블)에 해당 행을 가지며 데이터 테이블에서 행을 추가 또는 제거하는 것은 검색 테이블에 반영되어야합니다.
부모 디렉토리를 삭제할 때 두 테이블간에 데이터 일관성을 유지하는 최상의 솔루션을 찾으려고합니다. innodb 테이블은 괜찮습니다. 부모를 삭제하면 모두 삭제 될 때까지 자식을 통해 삭제됩니다. myisam 테이블에서 해당 행을 삭제하는 것이 더 어렵습니다.
나의 첫 번째 생각은 innodb 테이블에서 on-delete 트리거를 사용하는 것이었다. 행이 삭제되면 myisam 테이블에서 해당 행이 삭제됩니다. 그러나, MySQL은 캐스케이드 삭제 중에 트리거를 활성화하지 않기 때문에 (매뉴얼에서 지원 부족을 언급함으로써 해결 된 7 년간의 알려진 버그) 옵션이 아닙니다.
나의 두 번째 생각은 검색 테이블에 상위 하위 관계가 있었지만 전체 텍스트 검색 기능을 지원하는 myisam 테이블이므로 외래 키 제약 조건을 지원하지 않습니다.
innodb가 이제 전체 텍스트 검색을 지원한다고 들었으므로 검색 엔진을 변경할 수는 있지만 실험실에서만 사용할 수 있다고 생각했습니다.
마지막으로 생각한 것은 외래 키 제약 조건을 포기하고 데이터 일관성을 유지하기 위해 트리거 만 사용하는 것이 었습니다. 삭제시, innodb와 myisam 테이블에서 parent = OLD.id를 삭제하십시오. 그러나 테이블의 모든 데이터를 손상시킬 수있는 무한 루프를 방지하기 위해 MySQL은 트리거를 활성화 한 동일한 테이블에서 데이터를 조작하는 것을 지원하지 않습니다.
나는 부모 디렉토리 아래에있는 모든 하위 항목을 프로그래밍 방식으로 요청 루프를 통해 검색하지만, 더 나은 옵션이 있어야한다고 생각합니다. 그 밖의 다른 해결책이 있습니까? 내가 생각할 수있는 유일한 두 가지 옵션은 위 접근법 중 하나가 수정되거나 계단식 삭제에서 트리거를 실행하는 것을 지원하는 PostgreSQL과 같은 다른 RDBMS로 변경 될 때까지 기다리는 것입니다.
다른 아이디어는 크게 감사하겠습니다.
나는 그것을 얻었는지 잘 모르겠다. 두 테이블 사이의 관계에 대해 꽤 혼란 스럽다. 나는 서로 다른 타입을 가진 두 테이블 사이의 관계를 정의한다. 필자는 이전에 이것을 시도했고 데이터 일관성 유지시 문제가 발생했습니다. 외부 및 기본 키 사용자와의 테이블 관계를 통해 데이터 일관성을 유지하려는 경우 관계를 정의 할 모든 테이블에서 innodb를 사용하십시오. –
검색 테이블 (myisam)이 데이터 테이블 (innodb)의 검색 엔진으로 사용됩니다. 그러나 하위 디렉토리 및 파일이있는 디렉토리가 삭제되면 변경 사항이 데이터 테이블과 검색 테이블에 모두 반영되어야합니다. 적어도 전체 텍스트 검색 지원이 부족하기 때문에 검색 엔진에 innodb를 사용할 수 없습니다. 관계는 데이터 테이블에서 잘 정의되지만 삭제는 검색 테이블에 반영되지 않습니다. – JayceTDE
+1 잘 쓰여진 질문; 불행히도 현재 접근 방식에 대한 대안이 보이지 않지만 다른 누군가가 뭔가를 제안 할 것입니다. – Daan