더 구체적인 궁금증은 아닙니다.딜레마 : 캐스케이드 삭제 또는 결합 삭제
1 : M 관계로 여러 테이블을 삭제해야 할 경우, 계단식 삭제로 FK 제약 조건을 설정하거나 delete 문에서 테이블을 조인하는 것이 좋습니다.
관련 테이블에 별도의 삭제 명령문이있는 오래된 프로젝트가 있었는데 몇 번은 명령문이 실행되지 않아 데이터 무결성이 손상되었습니다. 두 사람 사이에서 결정을 내려야했기 때문에 더 나은 해결책이 될 것이라고 생각했습니다.
저장 프로 시저 또는 트랜잭션을 만드는 옵션이 있습니다.
그래서 의견이나 조언을 찾고 있는데 ...?
데이터베이스에 대해 정의 된 올바른 RI가있는 경우 데이터 무결성이 손상되지 않아야합니다. 모든 관련 테이블에는 선언적 RI가 있어야합니다. 즉, 은 부모가 아이를 가질 때 삭제할 수 없습니다.
또한 때때로 일부 행을 삭제하는 코드가있는 경우 코딩이 잘 안되어 테스트가 불량합니다. 이러한 종류의 작업은 단일 트랜잭션이어야합니다. 저장 프로 시저 사용에 대한 귀하의 제안은 그 문제를 해결하기위한 훌륭한 접근 방법이며 매우 표준적인 방법입니다.
이미 언급했듯이 계단식 트리거는 누군가 삭제하지 않을 행을 삭제할 위험이 있습니다. 때로 사람들이 응용 프로그램 외부의 데이터에 액세스하는 경우가 있는데, 특히 데이터 문제를 수정할 때 고려해야합니다. 누군가 실수로 잘못된 학부모를 삭제하려고 시도했을 때 좋은 RI 오류가 발생했습니다. 그들이 우연히 잘못된 부모를 삭제하려고 시도했을 때 그 부모를 삭제할뿐만 아니라 다른 5 개의 테이블에있는 20 명의 어린이를 삭제하면 그것은 나쁘다.
또한 계단식 삭제는 매우 숨겨져 있습니다. 개발자가 부모에 대한 삭제를 코딩하는 경우 삭제 저장 프로 시저를 사용하여 자식을 처리해야한다는 것을 알아야합니다.개발자가 코드를 작성하지 않고 오류를 얻고 코드를 수정하면 (또는 실제로 삭제하지 않고도) 코드를 수정하면 개발자가 삭제를 던져서 코드를 수정하는 것이 훨씬 더 바람직합니다. 코드가 공개 될 때까지 어린이를 죽이는 것은 아무도 알지 못합니다.
IMO, 나는 개발자가 응용 프로그램에 대해 잘 알고있어 그들이 응용 프로그램을 모르는 사이에 쉽게 유지할 수있게하는 것을 선호합니다.
캐스케이드 삭제를 사용하는 것이 더 안전하다고 말하고 싶습니다. 조인을 사용하기로 결정한 경우 조인을 부모 테이블에서 삭제할 때마다 사용하는 것을 기억해야합니다. 그렇게하기에 충분한 징계를 받더라도 장래에 소프트웨어를 지원할 동료 또는 사람들에 대해 확신 할 수 없습니다. 또한 테이블 관계에 대한 지식을 한 번 이상 인코딩하면 DRY 원칙을 위반하게됩니다.
캐스케이드 삭제를 사용하는 경우 아무도 기억하지 않아도되며 필요에 따라 하위 행이 항상 삭제됩니다.
캐스케이드 삭제는 많은 문제를 유발하므로 매우 위험합니다. 그 사용을 권장하지 않습니다. 우선, 수백만 개의 하위 레코드가있는 레코드를 삭제해야한다고 가정합니다. 데이터베이스를 잠그고 몇 시간 동안 사용할 수 없도록 만들 수 있습니다. 캐스케이드 삭제를 데이터베이스에서 사용할 수있는 DBA는 거의 없습니다.
다음으로 FK를 정의한 경우 데이터 무결성에 도움이되지 않습니다. 여전히 존재하는 하위 레코드가있는 삭제는 실패합니다. 은입니다. 예를 들어 기존 주문이 있으면 고객 삭제가 실패하기를 원합니다. 무의식적으로 사용 된 계단식 삭제 (일반적으로 내 경험에 따라)로 삭제하려는 항목을 삭제할 수 있습니다.
둘 다 사용하십시오!
"결합 된"수동 삭제는 삭제 작업을 더 작은 작업 단위로 분해 할 수 있으므로 교착 상태 및 기타 경쟁 문제를 피할 때 더 좋습니다. 논쟁이 있다면 분명히 분쟁의 원인을 쉽게 찾을 수 있습니다.
"삭제 캐스케이드"는 명시 적으로 참조 무결성을 보장합니다.
교착 상태 및 성능 문제를 피하려면 조인 된 sqls의 "children"을 명시 적으로 삭제하십시오. 그러나 "CASCADE DELETE"를 놓아두고 놓친 것을 잡으십시오. 부모를 삭제할 때 남겨진 자녀가 없어야하므로 삭제와 실수를하지 않는 한 아무런 비용도 들지 않습니다.이 경우 비용은 참조 무결성을 유지하는 데 가치가 있습니다.
모든 외부 키가 참조 무결성을 보장합니다. –
전적으로. 위대한 대답과 잘 넣어. 데이터 무결성은 항상주의를 기울이지 않고 있으며 대개 몇 년 전부터 시작되어 많은 기업을 목 졸라 죽이는 결과를 낳습니다. 데이터 수집에 관한 오래 전에 나쁜 결정으로 인해 더 이상 혁신과 변화를 가져올 수 없습니다. –
수동으로 데이터를 삭제할 때 발생할 수있는 사고로 인해 캐스케이드 삭제와 관련된 오명이있는 것 같습니다. 개인적으로 나에게는 몇 가지 나쁜 경험이 있지만 엄격한 데이터 무결성을 유지하는 것이 더 안전한 방법이라는 데 여전히 동의합니다. 반면에 저는 여전히 캐스케이드 사용을 피하려고합니다. –