외래 키는 제약 조건이므로 확실히 추가 오버헤드가 발생합니다. 예를 들어, 책에 자주 등장하는 예시인 학생과목선택제도, 학생표, 과목일정표를 보면 중간에 반드시 학생과목연합표가 있을 것이다. 외래키 제약조건을 추가하면 과목 삭제 시 반드시 학생이 해당 과목을 선택했는지 확인하게 됩니다. 그렇지 않으면 삭제 후 학생이 선택한 과목을 찾을 수 없으며 오류가 발생하게 됩니다.
외래 키 제약 조건을 생략하면 데이터베이스 설계가 더 간단하고 유연해지거나 더 효율적으로 실행될 수 있지만 다른 측면에서는 그에 상응하는 대가를 지불해야 하는 이유가 무엇인지 모르겠습니다. 참조 무결성을 수동으로 유지하려면 추가 코드를 추가해야 합니다. 원래는 데이터베이스의 제약 조건 키로 문제를 해결할 수 있었지만 이제는 이를 유지하기 위해 코드 조각을 작성해야 합니다. 게다가 판단을 유지하기 위해 수동으로 코드를 작성하는 것도 제약이고, 성능 손실도 있겠지만 이는 단지 논리적 수준에 불과하고 데이터베이스보다 훨씬 빠르지는 않을 것입니다.
저는 일을 시작한 이후로 외래 키를 추가한 적이 없습니다. :D 종속성이 너무 많으면 성능에 영향을 미치지 않습니다. 효율성을 높이기 위해 외래 키를 추가하는 방법에 대한 문서는 본 적이 없습니다. 저는 신인이니까 비난하지 마세요. 하하, 상처받는 건 용납할 수 없어요. 지나가다 지나가다
외부 지안은 주로 데이터의 무결성과 일관성을 유지하는 역할을 합니다. 예를 들어 사용자 테이블과 사용자 주문 테이블 사이에 외부 키 관계가 없는 경우 이를 주문 테이블에 삽입할 수 있습니다. 하지만 이 주문 양식은 해당 사용자의 것입니다. 어떻게 알 수 있나요? 그러면 그러한 데이터는 외로운 유령이 됩니다. 외부 건강 관계. 삽입 시에도 사용자 테이블에 해당 사용자가 삽입되도록 해야 합니다. 마찬가지로 사용자 테이블의 데이터를 삭제하는 경우에도 주문 테이블에 대한 참조가 있으면 삭제할 수 없습니다. 이는 데이터 일관성과 무결성을 보장합니다.
외래 키 제약 조건은 주로 데이터베이스 수준에서 데이터 일관성을 보장하기 위한 것이며, 데이터를 삽입하고 업데이트하려면 외래 키를 확인해야 하기 때문에 구두에서는 외래 키 수가 증가합니다. 마스터와 슬레이브 테이블의 메인 테이블 잠금 경쟁은 성능에 부정적인 영향을 미칩니다.
실제 프로젝트에서는 외래 키를 사용하지 않는 것이 한편으로는 개발의 복잡성을 줄이는 데 도움이 됩니다(외래 키가 있는 경우 먼저 마스터 테이블에서 마스터-슬레이브 테이블의 작업이 수행되어야 함). 반면, 외래키는 데이터 처리 시 처리가 매우 어렵습니다.
신청 수준에서 데이터의 일관성을 확인하는 것은 일반적인 기능 요구 사항입니다. 예를 들어 학생이 과목을 선택하는 시나리오에서는 과목을 입력하지 않고 드롭다운 또는 검색 방법을 통해 시스템에서 선택해야 합니다. 등을 통해 법률 강좌 ID임을 확인할 수 있으므로 데이터베이스의 외래 키에 의존하여 확인할 필요가 없습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
외래 키는 제약 조건이므로 확실히 추가 오버헤드가 발생합니다. 예를 들어, 책에 자주 등장하는 예시인 학생과목선택제도, 학생표, 과목일정표를 보면 중간에 반드시 학생과목연합표가 있을 것이다. 외래키 제약조건을 추가하면 과목 삭제 시 반드시 학생이 해당 과목을 선택했는지 확인하게 됩니다. 그렇지 않으면 삭제 후 학생이 선택한 과목을 찾을 수 없으며 오류가 발생하게 됩니다.
외래 키 제약 조건을 생략하면 데이터베이스 설계가 더 간단하고 유연해지거나 더 효율적으로 실행될 수 있지만 다른 측면에서는 그에 상응하는 대가를 지불해야 하는 이유가 무엇인지 모르겠습니다. 참조 무결성을 수동으로 유지하려면 추가 코드를 추가해야 합니다. 원래는 데이터베이스의 제약 조건 키로 문제를 해결할 수 있었지만 이제는 이를 유지하기 위해 코드 조각을 작성해야 합니다. 게다가 판단을 유지하기 위해 수동으로 코드를 작성하는 것도 제약이고, 성능 손실도 있겠지만 이는 단지 논리적 수준에 불과하고 데이터베이스보다 훨씬 빠르지는 않을 것입니다.
외래 키는 속도가 느린 innodb를 사용해야 하며, myisam은 관련 쿼리를 사용하여 해결할 수 있습니다.
외래 키나 패러다임 같은 것은 교과서에만 존재해야 합니다. 외래 키를 금지하고 비정규화를 수행해야 합니다. 외래 키와 쿼리 효율성 사이에는 연관성이 없습니다. 이 기능은 단지 데이터 연결을 설정하는 것뿐이므로 논리를 통해 데이터 연결을 제한하지 않는 이유는 무엇입니까?
일부 회사에서는 외래 키를 추가하지 않고 테이블을 생성합니다
저는 일을 시작한 이후로 외래 키를 추가한 적이 없습니다. :D 종속성이 너무 많으면 성능에 영향을 미치지 않습니다. 효율성을 높이기 위해 외래 키를 추가하는 방법에 대한 문서는 본 적이 없습니다. 저는 신인이니까 비난하지 마세요. 하하, 상처받는 건 용납할 수 없어요. 지나가다 지나가다
외부 지안은 주로 데이터의 무결성과 일관성을 유지하는 역할을 합니다. 예를 들어 사용자 테이블과 사용자 주문 테이블 사이에 외부 키 관계가 없는 경우 이를 주문 테이블에 삽입할 수 있습니다. 하지만 이 주문 양식은 해당 사용자의 것입니다. 어떻게 알 수 있나요? 그러면 그러한 데이터는 외로운 유령이 됩니다. 외부 건강 관계. 삽입 시에도 사용자 테이블에 해당 사용자가 삽입되도록 해야 합니다. 마찬가지로 사용자 테이블의 데이터를 삭제하는 경우에도 주문 테이블에 대한 참조가 있으면 삭제할 수 없습니다. 이는 데이터 일관성과 무결성을 보장합니다.
외래 키 제약 조건은 주로 데이터베이스 수준에서 데이터 일관성을 보장하기 위한 것이며, 데이터를 삽입하고 업데이트하려면 외래 키를 확인해야 하기 때문에 구두에서는 외래 키 수가 증가합니다. 마스터와 슬레이브 테이블의 메인 테이블 잠금 경쟁은 성능에 부정적인 영향을 미칩니다.
실제 프로젝트에서는 외래 키를 사용하지 않는 것이 한편으로는 개발의 복잡성을 줄이는 데 도움이 됩니다(외래 키가 있는 경우 먼저 마스터 테이블에서 마스터-슬레이브 테이블의 작업이 수행되어야 함). 반면, 외래키는 데이터 처리 시 처리가 매우 어렵습니다.
신청 수준에서 데이터의 일관성을 확인하는 것은 일반적인 기능 요구 사항입니다. 예를 들어 학생이 과목을 선택하는 시나리오에서는 과목을 입력하지 않고 드롭다운 또는 검색 방법을 통해 시스템에서 선택해야 합니다. 등을 통해 법률 강좌 ID임을 확인할 수 있으므로 데이터베이스의 외래 키에 의존하여 확인할 필요가 없습니다.