관계형 데이터베이스의 무결성 제약-간과해야합니까?


10

나는 큰 쿼리 속도를 높이고 더 나은 결과를 얻기 위해 관계형 데이터베이스에서 관계 시행을 제거하는 것이 좋습니다 (ForEIGN KEY 제약 조건 정의를 통해)는 회사의 개발자와 영구적으로 토론하고 있습니다. 공연.

고려중인 플랫폼은 MySQL 5.x이며 FOREIGN KEY가 설정되지 않았으며 관련 테이블의 일부 PRIMARY KEY 제약 조건이 없어도 적어도 나에게는 합리적이지 않습니다. 그들이 옳고 틀렸을 수도 있지만,이 상황에 대해 논의 할 충분한 주장이 없습니다.

이것은 3 년 동안 선호되는 접근 방식입니다. 나는이 회사에 처음 생겼지 만 (1 개월 만), 제품이 작동함에 따라 데이터베이스를 향상시키는 데 주저함이 있습니다. 그럼에도 불구하고 가장 먼저 눈에 띄는 것은 한 페이지를로드하는 데 1 분이 걸린다는 것입니다 (예, 60 초!).

현재의 상황에 대한 주장 중 하나는“비정규 화 된”데이터베이스가 정규화 된 데이터베이스보다 빠르다는 것이지만 이것이 사실이라고는 생각하지 않습니다.

대부분의 관련 쿼리에는 JOIN 연산이 포함되어있어 대량의 데이터 (데이터베이스에 수백만 개의 행이 있음)에서 매우 느리게 실행됩니다.

일반적으로 "CRUD"작업 처리는 응용 프로그램 코드 수준에서 구현됩니다. 예를 들어, 일부 데이터를 삭제하려면 다음과 같이하자 TableA.

  • 먼저 확인할 필요가 즉석에서 의 열 사이에 관계가 존재하는 경우 TableATableB,
  • 상기 관계가 "감지 된"경우, 앱 프로그램 코드는 관련 행을 삭제할 수 없지만
  • 어떤 이유로 든 앱 프로그램 코드가 실패하면 관련된 행과 테이블에 관계가 있더라도 DELETE 작업이 "성공"합니다.

질문

토론을 풍요롭게하기 위해 정확하고 탄탄한 대답을 정교하게 도와 줄 수 있습니까?


참고 : 어쩌면 이와 같은 것이 전에 요청되고 대답되었지만 Google을 통해 아무것도 찾을 수 없었습니다.


의견은 긴 토론을위한 것이 아닙니다. 이 대화는 채팅 으로 이동 되었습니다 .
Paul White 9

답변:


12

게시물에 명시된 바와 같이 관계형 데이터베이스 (간단히 RDB )를 작성하려는 의도 이므로 그 기능을 수행 할 것으로 예상되는 경우 짧은 대답은 다음과 같습니다.

  • 아니요, 데이터 무결성 제약 조건을 간과해서는 안됩니다 .

주요 목표는 관련 데이터를 그대로 관리하는 것이어야하며, 매우 귀중한 조직 자산이며, 이러한 목표를 달성하기위한 신뢰할 수있는 방법은 건전한 이론에서 지원되는 기술적 수단을 사용하는 것입니다.

따라서 데이터베이스 전문가 는 EF Codd 박사가 제공 한 최신의 우아한 관계형 모델 메커니즘 을 활용하여 비즈니스 규칙을 시행하고 활용되지 않을 경우 발생할 수있는 문제를 피할 수 있습니다.

이와 관련하여 (a) 전반적인 제약 조건과 (b) 데이터베이스 상태 및 문제가되는 작업 환경에 대한 몇 가지 고려 사항을 다음과 같이 공유합니다.

FOREIGN KEY 제약 조건, 데이터 관계 및 참조 무결성

RDB는 관심있는 비즈니스 컨텍스트의 특성을 높은 정확도로 반영해야하며 , 비즈니스 전문가의 필수 지원을 고려하여 모범 사례를 따르는 모델러 또는 설계자가 주도하는 심층적 인 개념 수준 분석이 필요합니다. 이러한 분석은 정확한 식별과 적용 가능한 비즈니스 규칙을 제시해야합니다 .

결과적으로, 이러한 모델러가 관련 데이터간에 상호 관계가 있음을 식별 한 경우 데이터베이스 관리 시스템 (DBMS)이 데이터가 정확한 특성과 일관성을 유지하도록 보장 할 수 있도록 해당 논리 레벨 제한 사항을 구성해야합니다. 위의 분석 에서 항상 결정된 규칙 .

논의중인 데이터베이스와 관련하여, 응용 프로그램 코드의 dint에 의해 DBMS 시설 외부에서 데이터베이스를 시행하려는 절차 적 (우회하기 쉬운) 시도가 있다고 언급하기 때문에 관련 상호 관계가 식별되었다는 것을 알 수 있습니다 상관 관계의 전체 성을 검증하기 위해 데이터베이스를 "만져야"하는 사전 관계형 접근 방법입니다.

그러나 관계 과학은이 목적을 위해 매우 강력한 도구, 즉 FOREIGN KEY (FK) 제한 조건을 규정했기 때문에 참조 무결성 을 보호하는 최적의 기술은 아닙니다 . 불필요하고 오류가 발생하기 쉬운 임시 절차에 의존하지 않는 단일 문장 이므로 이러한 제약 조건은 우수한 선언적 접근 방식을 통해 매우 쉽게 만들 수 있습니다 . FK 제약 조건의 실행 속도는 전문 프로그래머에 의해 고도로 최적화되어 있으며 주요 플랫폼 공급 업체는 수십 년 동안이 작업을 해왔다는 점에 매우 유용합니다.

또한 RDB는 여러 응용 프로그램 (데스크톱, 자동, 웹, 모바일, 이들의 조합)에 의해 액세스 할 수있는 독립적 인 (자체 보호, 자체 설명 등) 소프트웨어 구성 요소 여야합니다. 이러한 앱의 코드와 "커플 링 된"

마찬가지로 중요한 조직 리소스 인 데이터는 자연스럽게 응용 프로그램, 응용 프로그램 프로그래머, 응용 프로그램 개발 플랫폼 및 프로그래밍 패러다임보다 오래 지속되는 경향이 있습니다.

PRIMARY KEY 제약 조건 및 중복 행의 의미

-conceptually 특정 speaking- 때 물건의 종류의 비즈니스 환경에서 의미가있는 것으로 간주되어, 데이터베이스 모델러는 확인했다, (1)의 관련 특성, 그것의 속성 -을 - 즉 결정해야 종류의 일의 엔티티 인스턴스로 프로토 타입 - 즉, 엔티티 유형-(2) 논리 설계에서 하나 이상의 열에 의해 통합 된 테이블 을 통해이를 나타냅니다 .

그런 다음 현실에서 주어진 엔티티 유형의 각 개별 인스턴스 를 구별 하는 것이 가장 중요 하듯이 , 테이블에 포함 된 각 행도 고유하게 구별되어야합니다. 테이블에 KEY가 선언되어 있지 않으면 결국 중복을 유지하고 정확히 동일한 값을 유지하는 둘 이상의 행이 있으면 모두 동일한 의미를 갖 습니다. 모두 동일한 사실을 나타냅니다 .

이때 여러 가지 이유로 중복 행을 삭제해야합니다. 이론적 인 관점에서, 설계자는 SQL 데이터 하위 언어가 허용하는대로 (데이터 조작 작업에 중요한 영향을 미침) 관계형으로 작동하는 테이블을 가지기 위해 각 행이 항상 고유해야합니다. 또한 정보 관점에서 볼 때 여러 행이 동일한 사실을 나타내는 경우 다음과 같이 레코드가 불필요 할뿐만 아니라 해 롭습니다 .

  • 누군가 특정 테이블에 두 개의 동일한 행을 삽입했다고 가정하십시오.
  • 나중에 다른 사람이 와서 한 번만 중복 항목을 업데이트합니다. 결과적으로 다른 발생은 더 이상 최신 상태가 아닙니다.
  • 계속해서 다른 사람이 지금까지 수정하지 않은 발생을 업데이트합니다. 이러한 방식으로, 두 복제물은 별개의 시점에서 상이한 변화를 겪었다.
  • 그 후, 누군가가 해당 행에 의해 전달되는 정보를 선택하는 데 관심이있을 때, 두 가지 다른 "버전"을 찾을 수 있습니다.

이런 식으로:

  • 어떤 "버전"이 정확하고 신뢰할 수있는 것으로 간주 될 수 있습니까?
  • 어느 것이 현실 세계를 정확하게 반영합니까?

아시다시피,이 현상은 법적으로 중요한 의미를 지닐 수 있습니다.

또한 이러한 모순을 처리하기 위해 (어떤 종류의 "업데이트 동기화"를 통해) 수행해야하는 시간과 노력은 실제로 조직의 가치를 창출하는 작업에 더 집중해야합니다. 따라서 데이터베이스의 일관성을 그대로 유지하기 위해 모순 된 행 을 유지하는 것은 설계 상 피해야 합니다.

그렇기 때문에 PRIMARY KEY (PK)의 식별 각 제약 조건의 선언은 항상 데이터베이스 디자이너가 수행 해야합니다 . 그러나 테이블에 모든 행을 고유하게 식별하는 값을 보유하는 둘 이상의 열 또는 열 조합이있을 수 있다는 점도 언급해야합니다. 결과적으로 PK 제약 조건 (실용적인 이유로 인해 PRIMARY로 이상적으로 설정 됨)을 설정하는 것 외에도 설계자는 적용 할 때 하나 이상의 대체 키 (일반적으로 하나 이상의 UNIQUE + NOT NULL 제약 조건을 통해 정의 됨)를 선언해야합니다. 꽤 흔함).

PK의 또 다른 유리한 특성은 단일 또는 복합 FK에 참여하기 위해 다른 테이블로 "마이그레이션"할 때 데이터간에 존재하는 관계 의 카디널리티 비율 을 적용하는 데 도움이 될 수 있다는 것입니다. 간단하고 효율적인 선언적 설정을 통해이 모든 것이 DBMS에 의해 보장됩니다.

(현재) CHECK 제약 조건 및 단일 행 유효성 검사

(현재) CHECK 제약 조건의 관련성을 잊지 말고 행의 유효한 열 값 집합을 선언적으로 제한하십시오 (단순하게 보일 수 있지만 실제로는 관계형 DBMS의 기본 기능 임). 비즈니스 컨텍스트의 규칙은 항상 정확하게 반영됩니다.

MySQL 태그로 질문을 표시했을 때 불행히도 그러한 플랫폼은 상기 종류의 제약 선언을 허용하지만 동시에 그 시행을 무시 한다는 점을 언급해야합니다 ! 2004 년 이후로 버그로보고 된 상황 .

이와 관련, 다른 예를 들어 수단에 의해이 요소 알아서해야 ACID 트랜잭션 , 트리거 또는 DBMS 자체 내에서 다른 방법 (볼 이 대답 하여 @ ypercubeᵀᴹ 때문에 데이터에 계속이 주제에 대한 정보를) 일관성을 유지하십시오.

ASSERTION 제한 조건 : 선언적으로 여러 행 및 다중 테이블 비즈니스 규칙을 추가로 설정

MySQL을 포함한 여러 SQL DBMS가 어떤 이유로 든 지원을 제대로 지원하지 못하는 한 가지 측면은 PK 및 FK를 넘어 선언적 방식으로 여러 행 및 다중 테이블 제약 조건을 활성화하는 것입니다.

현재 SQL 표준에는 몇 년 전부터 ASSERTION이 포함되어 있습니다. 비즈니스 수준의 논리 수준 유효성 검사 접근 방식이 어떤 이점을 얻을 수 있는지는 알지 못하지만 데이터베이스 디자이너는 하나 이상의 ASSERTION으로 데이터를 제한하는 것이 매우 편리하다고 생각합니다. DBMS 개발자의 관점에서 볼 때,이 가장 중요한 도구는 물리적 추상화 수준에서 구현하기가 어려웠습니다.

Oracle 벤더 및 / 또는 개발자 2016 년 이후 ASSERTION 지원을 평가 하고 있으며, 이는 DBMS를보다 관계에 적합하고보다 강력하고 경쟁력있게 만드는 것으로 보입니다 . (i) 소비자가 계속 추진하고 (ii) Oracle이 구현에 성공하면 (iii) 다른 DBMS 공급 업체 / 커뮤니티도이를 활성화해야하고 사용량이 확산되기 시작합니다. 확실히, 그것은 데이터베이스 관리 분야에서 큰 진전이었으며 Codd 박사가 구상 한 가장 독특한 도구 중 하나이기 때문에 개인적으로 우리는 그것이 곧 일어날 것을 기대합니다.

데이터 일관성 및 의사 결정 프로세스

위에서 논의한 바와 같이, RDB의 가장 중요한 측면 중 하나는 RDB가 보유한 데이터 의 일관성 을 자체적으로 보장한다는 것이며, RDB가 모델러가 선언 한 무결성 제약 조건을 준수 할 때만 일관성이 충족된다는 것입니다.

이와 관련 하여 신뢰할 수있는 파생 테이블 (예 : 여러 테이블에서 열을 검색하는 SELECT 문 또는 뷰) 을 만들 수 있도록 무결성이 보호되는 기본 테이블 (DDL 구조에 설정된 테이블) 을 가져야 합니다 . 파생 테이블은 반드시 기본 테이블과 관련하여 생성되어야하기 때문입니다.

사람들은 정보를 조직 (및 일반적인) 의사 결정 과정에서 주요 도구로 사용하는 것으로 잘 알려져 있습니다. 그런 다음 데이터베이스에서 제공하는 정보가 일관성 있고 정확하지 않은 경우 해당 정보를 기반으로 한 결정은 적절하지 않습니다 (최소한). 그렇기 때문에 RDB는 신중하게 설계되고 구현되어야합니다. 사용자가 제대로 결정을 내릴 수 있도록 신뢰할 수있는 리소스가되도록 구축해야합니다.

"비정규 화"

아아,“비정규 화 된 데이터베이스가 정규화 된 데이터베이스보다 빠르다”는 것은 논리적, 물리적, 실용적 근거에 반박 할 수있는 논거이기도하지만 널리 퍼져있는 오해이다.

첫째, 비정규 화 는 기본 테이블이 사전에 정규화되었음을 의미합니다 ( 데이타베이스의 논리적 추상화 레벨에서 수행 된 공식적인 과학 기반 절차로 인해).

따라서 해당 표가 실제로 실제로 정규화되었다고 가정 할 때 표를 '비정규 화'합니다 (단어의 형식적 의미와 달리 광고의 다른 표에 속하는 열에 추가하는 것과 관련이 있음) 특별 패션) 물리적 수준에서 (속도, 예를 들어, 도움이 될 수 있음) 하나 또는 몇 개의 특정 SELECT 문의 처리, 액션 세력의 이러한 과정 동안, 같은 시간에, 다른 많은 관련 데이터의 실행을 훼손 할 수 조작 조작 (예 : 여러 INSERT, UPDATE, DELETE 및 SELECT 문 또는 단일 또는 복수 ACID TRANSACTIONS로 묶인 명령문 조합)

또한 비정규 화 (형식적이든 비공식적이든)는 데이터베이스의 일관성을 떨어 뜨리는 업데이트 / 수정 이상 을 초래할 수 있는데,이 모든 문제를 예방할 수있을 때 복잡하고 비용이 많이 들고 오류가 발생하기 쉬운 절차로 "처리 될 수있는"문제 처음.

정규화 된 테이블과 "비정규 화 된"테이블을 지원하는 물리적 수준의 스캐 폴딩

실제 환경에서 사용하기위한 논리적 (추상) 레이아웃 (SQL-DDL 디자인)에는 고려해야 할 물리적 (콘크리트) 영향이 명확하게 있습니다.

이런 방식으로, "비정규 화 된"테이블은 반드시 "더 넓게"(추가 열 보유)되어야합니다. 즉, 행이 더 무겁고 (물리적이고 더 큰 물리적 레벨 구성 요소가 필요함) 기본 컴퓨팅 프로세스 (예 : , 하드 드라이브 또는 메모리와 관련이있는 장치는 느리게 회전 할 수 있습니다.

반대로,“더 좁게”(더 적은 열을 갖는) 정규화 된 테이블은“더 빠르게 작동”하는“더 가벼운”요소 (더 작고 더 작은 물리적 구성 요소로 제공)가되어 관련 작업의 속도가 빨라집니다. 예를 들어, 데이터 쓰기 및 읽기.

따라서 (a) 관련 테이블을 공식적이고 신중하게 정규화하여 그대로 유지 한 다음 (b) 데이터 검색 및 수정 속도를 최적화 할 수있는 물리적 레벨 자원 (예 : 구현)을 사용하는 것이 매우 편리합니다. 적절한 소프트웨어 및 하드웨어 서버 구성, 네트워크 대역폭 기능 업그레이드 등을 가능하게하는 신중하고 효율적인 인덱싱 전략

고려중인 데이터베이스의 기능

질문의 다음 단락은 데이터 검색 작업의 속도와 관련이 있습니다.

[A] 제품이 "작동"하면 데이터베이스를 향상시키는 데 주저함이 있습니다. 그럼에도 불구하고 가장 먼저 눈에 띄는 것은 한 페이지를로드하는 데 1 분이 걸리는 것입니다 (예, 60 초!).

특정 페이지를로드하는 데 많은 양이 필요한 경우 시스템 사용자가 서비스를 제대로받지 못하고 있음이 분명합니다. 따라서“작동”하더라도 그 기능이 전혀 최적 인 것처럼 보이지는 않지만 전체 환경 (데이터베이스 및 앱)을보다 효율적으로 만들려는 의도가 잘 유지되고 매우 건설적인 태도를 보여줍니다.

그런 다음 과학이 당신을 확실히지지하고 확고한 자세를 유지해야 할지라도, 하루가 끝날 무렵에 고용주, ​​동료 및 자신이 전체 조직을 만들기 위해 노력하고 있기 때문에 외교적 방법으로 상황에 접근하는 것이 좋습니다. 더 성공적인. 따라서 이것이 강조해야 할 한 가지 주장은 다른 것보다 더 많은 일을하고 있지만 일반 및 특정 데이터 관리 관행을 개선하면 조직 및 개인의 성장을 크게 향상시키는 데 큰 도움이 될 수 있다는 것입니다.

대부분의 관련 쿼리에는 JOIN 연산이 포함되어있어 대량의 데이터 (데이터베이스에 수백만 개의 행이 있음)에서 매우 느리게 실행됩니다.

JOIN 연산자는 데이터의 관계형 조작과 관련된 필수 적이고 강력한 요소입니다. 그러면보다 강력한 플랫폼이 비교적 빠른 실행으로 플랫폼을 제공하지만 설명하는 환경은 아마도 비효율적 인 디자인의 증상 일 것입니다 (개념적, 논리적 및 물리적 추상화 수준에서). 그래서, 나의 첫 시력 추정치는 다음과 같습니다 :

  • INDEX 설정을 개선해야 할 수도 있습니다.
  • PK 및 FK 열 유형 및 크기 정의를 검토해야합니다 (그리고 복합 KEY는 적절한 경우 추가 된 대리자보다 훨씬 효율적이기 때문에 PK 고려 사항 에 대해 @Rick James 와 완전히 동의합니다 ).
  • 또한 (공식 과학 기반의) 정규화 는 올바른 상황에서 (즉, 잘 설계된 RDB에서 수행됨) JOIN이 매우 빠르게 실행 된다는 사실 때문에 이러한 문제를 완화하는 데 도움이 될 수 있습니다 .

또한 @TommCatt그의 답변 에서 언급 했듯이 쿼리의 (논리적) 재 작성은 데이터 읽기 / 쓰기를 가속화하는 (물리적) 실행 계획을 수정합니다. 이는 결정적으로 고려해야 할 요소입니다.


1
좋은 대답입니다. 구현 팀의 성능을 고려할 때 필자보다 개발자 팀이이 문제에 대해 오랫동안 오랫동안 연구 해 온 것보다 훨씬 똑똑하다는 사실을 항상 상기시킨다. 관계형 데이터베이스는 세계에서 가장 거대한 시스템의 핵심입니다 (Facebook 및 Twitter는 몇 가지 명백한 데이터베이스를 나타냅니다).
Nick Bedford

9

개발자의 기본 전제는 절대적으로 잘못되었습니다. 외래 키는 시스템의 DML 성능에 약간 영향을줍니다. 쿼리에서 전혀 사용되지 않으므로 성능에 영향을 미치지 않습니다. 따라서 개발자는 자신이 무엇을 말하는지 알지 못하며 조언을 구해야 할 마지막 사람입니다.

외래 키는 데이터의 무결성을 유지하는 데 중요한 역할을합니다. 이를 제거함으로써 얻은 작은 성능 향상보다 훨씬 더 중요합니다.

어떤 상황에서도 OLTP 데이터베이스에서 FK를 제거 하지 마십시오 .

또한 비정규 화로 인해 일부 쿼리 속도가 향상되는 경우가 있습니다. 그들이 말했듯이 그것은 달려 있습니다. 그럼에도 불구하고 약간의 속도 향상이 있더라도 일반적으로 데이터 무결성을 유지하기위한 추가 노력은 가치가 없습니다.

간단한 튜닝으로 비정규 화보다 속도를 크게 향상시킬 수없는 경우는 매우 드 rare니다. 좋은 DBA가 (최종적으로) 급여를받을 수있는 곳입니다. 쿼리를 조정할 수도 있습니다. 한 번은 30 분 이내에 답변을 반환하는 쿼리를 가져 와서 8 초 안에 작동하도록했습니다. 데이터베이스를 변경하지 않고 쿼리를 다시 작성하십시오. 물론, 이것은 내 개인 최고 기록이므로 마일리지는 다를 수 있지만 비정규 화는 가장 마지막 시도해야합니다.

개발자가 더 복잡한 쿼리를 작성하지 못하게 할 수도 있습니다. 원하는 데이터와 원하는 형식을 물어보십시오. 그런 다음 데이터를 제공 할 뷰를 제공하십시오. 복잡한 쿼리가 뷰가됩니다. 개발자는 다음과 같이 작성하면됩니다.

select <something> from <SomeView> where <whatever>;

또한 데이터베이스가 잘 설계되었다고 가정합니다. 데이터베이스의 디자인이 좋지 않거나 심지어 작은 부분이라도 실제로 속도가 느려질 수 있습니다. 나는 매우 큰 테이블 (각각 수십 개의 레코드)을 사용하여 왼쪽과 오른쪽으로 결합하고 몇 초 만에 예상 (답변) 된 쿼리로 작업했습니다. 테이블 크기는 쿼리 속도를 결정하지 않습니다.

누군가가 "제품이 '작동'하기 때문에 데이터베이스를 향상시키는 데 주저함이 있기 때문에 나는 정말로 울부 짖었다." 이 "주저함"이 "내 시계에 있지 않다, 친구 야!" 이력서 업데이트를 시작할 수도 있습니다. 그러한 환경에서 좋은 점은 없으며 앞으로도 실패 할 수없는 변화를주기 위해 몇 시간 동안 로비를 했음에도 불구하고 미래의 모든 실패에 대한 책임이 있습니다. "지금은 변경하기에 좋은 시간이 아닙니다"라는 소리가 계속 들립니다. 권리. 행운을 빕니다.


한 가지주의해야 할 점은 반환 할 데이터의 양에 따라 동일한 데이터에 대해 다른 쿼리가 필요한 경우가 있습니다. 예를 들어 단일 행을 반환하는 쿼리 (또는 카운트)는 수천 개의 레코드를 반환하는 쿼리와 다르게 작성하는 것이 좋습니다.
Joe W

2

제목을 변경하면 질문이 변경됩니다. FOREIGN KEYs선택 사항입니다. 그들이하다:

  • FK INDEX는 테이블 중 하나에 내재적으로 작성합니다 . 이러한 색인은 수동으로 추가 할 수 있습니다. 따라서 FK는 필요 하지 않습니다 .
  • FK는 무결성을 검사합니다. 이것이 FK의 명성에 대한 주요 주장입니다. 응용 프로그램이 유사한 검사를 수행하거나 검사가 필요하지 않다고 결정할 수 있으므로 FK는 필요 하지 않습니다. 그래서...
  • 무결성 검사는 성능이 저하됩니다. 처리 속도가 느려집니다. (일반적으로 큰 문제는 아닙니다.)
  • FK는 모든 사람이 원하는 모든 것을하지 않습니다. 이 포럼에는 "FK가 X를 수행 할 수없는 이유"질문이 있습니다. 특히이 CHECK옵션은 작동하지 않습니다.
  • FK는 할 수 있습니다 CASCADE. (개인적으로, 나는 통제를 유지하는 것을 선호하며 FK가 '올바른 일을 할 것'이라고 가정하지 않습니다.)

FK의 결론 : 일부 사람들은 FK를 주장합니다. 일부 제품은 제품없이 완벽하게 작동합니다. 당신이 결정합니다.

PRIMARY KEYInnoDB에서 제거 하는 것은 큰 실수입니다. 반면에 대리자를 제거 AUTO_INCREMENT하고 하나 이상의 열로 구성된 "자연"PK를 사용하는 것이 종종 올바른 일입니다. 여기에 설명 된 것처럼 단순하고 일반적인 경우는 many : many 매핑 테이블 입니다.

개인적인 경험에 따르면, 테이블의 모자 2/3가 auto_inc PK 대신 'natural'을 사용하는 것이 좋습니다.


1
따라서 ... 예를 들어 개발자가 실수를하고 DB 측에 제한을 두지 않으면 데이터 손실이 발생 하기 때문에 거의 완벽한 응용 프로그램에 의존 DELETE합니다. 이 접근 방식은 유효하지만 강력한 코드와 우수한 테스트가 필요합니다. :)
ReynierPM

너무 많이 삭제 하면 앱 또는 FK에서 발생할 수 있습니다. 너무 적게 삭제 하면 대개 분명해집니다. OTOH, 너무 적은 것을 삭제하는 것이 비용이 드는 경우를 보았습니다. 물건이 거의 삭제되지 않는 "정규화"를 생각하십시오. 여분의 미사용 행은 사실상 무해합니다.
Rick James

고속 인제 스트를위한 준비 테이블 인 테이블에 인덱스 가없는 하나의 '좋은'사례를 보았습니다 . 매우 일시적이므로 (InnoDB가 필요하지 않음) 완전히 읽어야합니다 (따라서 인덱스가 필요하지 않음).
Rick James

1
내 욕설에서 공통된 주제에 주목하십시오. 단일 답변은 없습니다. 한 번에 맞는 것은 아닙니다.
Rick James

테이블의 길이가 천 행인 경우 성능은 문제가되지 않습니다. 테이블의 길이가 10 억 행인 경우 정규화, PK, 인덱스, FK, UUID 등에 대한 모든 "규칙"을 면밀히 조사해야합니다. 그렇지 않으면 db가 녹습니다.
Rick James
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.