2010-02-25 3 views
9

저는 회사에서 설문 조사를 만드는 데 사용하는 오래된 웹 응용 프로그램을 만들고 있습니다. 나는 mysql 명령 프롬프트를 통해 데이터베이스 스키마를 살펴 보았는데 테이블이 꽤 견고하다고 보았다. 비록 내가 DB 전문가가 아니기는하지만, 그 뒤에있는 이론에 정통합니다 (소프트웨어 엔지니어링 프로그램에서 데이터베이스 디자인 과정을 몇 개 택한 것).외래 키를 사용하지 않는 이유는 무엇입니까? [php + MySQL]

그런데 나는 create 문을 SQL 파일에 버리고 MySQL Workbench에서 가져 와서 "실제"외래 키를 사용하지 않는다는 것을 알았다. 그들은 FK를 사용하는 것처럼 다른 테이블의 기본 키를 저장하지만 키를 하나라고 선언하지는 않습니다.

그래서 내가 알고있는 것 (FK 문제 제외)을 통해 DB를 설계하는 방법을 보았습니다. 그 이유가 궁금 할 때가 있습니다. 이것은 게으른 프로그래밍의 경우입니까, 아니면 모든 오류 검사를 프로그래밍 방식으로 수행하여 성능을 향상시킬 수 있습니까?

예제를 원할 경우 기본적으로 설문 조사가 있고 설문 조사에는 일련의 질문이 있습니다. 질문은 설문 조사의 일부이므로 열이 PK인지 확인합니다. 그것은 꽤 많이 있지만 그들은 모든 곳에서 그것을 사용합니다.

나는이 질문에 옳고 그른 대답이 없을지 모르지만 나는이 시스템이 꽤 견고 해져서 왜이 일을 할 것인지에 대한 정보를 찾고있다. 우리는 그것을 사용하기 시작했기 때문에이 사람들은 자신이하는 일을 알고 있다고 믿었습니다.)

답변

12

원래 개발자는 MyISAM 또는 외래 키 제약 조건을 지원하지 않는 다른 저장소 엔진을 사용하기로 결정했을 수 있습니다.

+0

정확히 그대로입니다. 나는 종이에 무언가를 디자인 할 수 있을지 모르지만 나는 실무 부서에서 확실히 부족하다. 덕분에 많은 사람들 :) – Gazillion

+0

마찬가지로 사이드 노트로, MySQL은 버전 3.23.44 이후 InnoDB에 대한 외래 키를 지원 해왔다. 출처 : http://en.wikipedia.org/wiki/MySQL#Future_releases –

+0

나는 MySQL 워크 벤치를 사용하여 내 스키마를 만든 다음 내 문장을 내 보냅니다. 나는 항상 InnoDB를 스토리지 엔진으로 선정 할 것이므로 MyISAM이 FK를 전혀 지원하지 않는다는 것을 알지 못했습니다. – Gazillion

4

MySQL은 InnoDB 테이블에서 실제 외래 키 관계를 정의하는 것을 지원합니다. 아마도 MyISAM입니까?

더 중요한 것은 적절한 열에는 색인이 정의되어 있으므로 (다른 테이블의 PK를 보유하는 색인이 색인되어야 함). 이것은 MyISAM에서도 가능합니다.

0

외래 키를 사용할 필요가 없습니다.

데이터가없는 경우 데이터가 일치하지 않아 계단식 삭제 및 업데이트를 사용할 수 없습니다.

스키마 변경으로 인해 발생하는 SQL 문의 버그로 인해 일부 사용자 데이터가 손실 될 수 있습니다.

일부는 그 (것)들을 선호한다, 어떤은 그 (것)들없이 생활을 선호한다. 두 경우 모두 실질적인 이점은 없습니다.

+4

데이터 일관성이 진정한 이점이라고 저는 말할 수 있습니다. – simon

+0

@ 사이먼 나는 동의 할 것이다 – meagar

+0

@ 사이먼. 대부분의 쿼리에는 보이지 않기 때문에 주위를 둘러싼 추가 행이있을뿐입니다. 반면에 숨겨진 행에는 사용자에게 중요한 일부 정보가있을 수 있습니다. – vava

2

큰 데이터베이스 (Teradata가 지원하는 유형)에서는 외래 키를 사용하지 않는다는 것을 알게됩니다. 그 이유는 성과입니다. 데이터베이스에 쓸 때마다 데이터웨어 하우스에서 충분할 때마다 테이블에있는 모든 fk를 확인해야하는 추가 오버 헤드가 있습니다. 당신이 이미 그것을 사실이라면, 요점은 무엇입니까.

작은 DB의 디자인이 좋을뿐입니다.하지만 성능을 향상시킬 수는 있습니다.

+0

감사합니다. 이것은 내가 궁금해하는 것입니다. 나는 그들의 데이터베이스가 "FK"를 추적 할 수있을만큼 작은 수의 테이블을 가지고 있다고 생각한다. – Gazillion

0

여기 외래 키를 사용하지 않는 실제 인스턴스입니다.

자식이 존재하지 않을 수도 있고 자식이 추상 클래스 인 부모 자식 관계를 저장하는 방법이 필요했습니다. 아이는 몇 가지 타입이 될 수 있으므로 하나의 필드를 사용하여 아이의 유형을 지정하고 하나의 필드는 아이의 ID를 나열합니다. 응용 프로그램은 대부분의 논리를 처리합니다.

이것이 최고의 디자인 결정인지 확실하지 않지만 최종 기한 내에 만날 수있는 최선이었습니다. 지금까지 잘 작동했습니다!

3

일반 사항; 키는 읽기 속도를 높이고 (테이블에 오버 헤드를 추가하기 때문에 읽기 성능이 옵티 마이저에 도움이되는 경우), 쓰기 속도를 낮 춥니 다.

대부분의 경우 읽기 무결성 및 읽기 유지를위한 속도 향상은 쓰기에 추가하는 사소한 오버 헤드보다 중요합니다.

매우 큰 사이트에서 많은 읽기가 실제로 '라이브'데이터베이스에 도달하지 않기 때문에 이러한 구별은 캐시, 미러링 등으로 흐리게 처리되었습니다.하지만 아마존, 트위터 또는 처럼.

관련 문제