2012-07-26 2 views
1

MySQL을 사용하여 프로젝트에 태그와 같은 구조를 설계하려고합니다.MySQL에서 비트 필드로 태그 저장. 인덱스?

http://forge.mysql.com/wiki/TagSchema을 읽고 나면 m2m 테이블 디자인에 많은 숫자가 필요하기 때문에 매우 실망 스럽습니다. join 큰 데이터에서 성능이 확실히 떨어집니다.

내가 생각하고있는 것은 각 태그는 name 내가 태그 할 항목 테이블에 그런 다음 id

이있는 태그 테이블이며, 각 항목은 각 태그는 비트를 표시, tag라는 열이 인덱스 1로, 다른 비트 필드는 예를 들어 내가 특정 태그를 가진 item를 조회하려면

table: tag 

id name 
1 tag1 
2 tag2 
3 tag3 



table: item 

id  name tag (in binary)  tag (in array) 
1  item1 00000001   [tag1] 
2  item2 00000100   [tag3] 
3  item3 00000110   [tag2, tag3] 

를 들어 0

, 난 단지 & binar 필요 원하는 태그가있는 y 태그 필드 id.

  1. 내 디자인이 좋은 생각입니까?

  2. 태그 비트 세트 필드에 색인을 사용할 수있어서 조회 속도를 높일 수 있습니까?

  3. MySQL은 # 2를 할 수없는 경우, (NoSQL이 외에) 내 최선의 선택 미리

감사거야!

답변

1

아니요, 다 대다 관계에 필요한 두 조인은 대용량 데이터를 빨아 먹지 않습니다. 기본 디자인 패턴이며 MySQL은 합류시 매우 빠릅니다. 32 개 이상의 다른 태그 (또는 BigInt 데이터 유형을 사용하는 경우 64 개)가있는 경우 디자인이 손상됩니다. 이유를 파악할 수 있습니까? 또한 응용 프로그램을 먼저 구현하는 것에 대해 걱정하고 나중에 문제가 될 때 나중에 성능에 신경을 쓰는 것이 좋습니다.

+0

int 또는 bitint를 사용하지 않을 것이므로 이진 필드를 사용하려고합니다. 항목 당 평균 3 개의 태그가있는 경우 항목 테이블에 1m 행이 있으면 태그 ID에 대해 3m 행을 스캔 한 다음 실제 태그 이름에 대한 태그 테이블을 스캔해야하기 때문에 디자인이 좋지 않습니다. – est

+0

아니요, 모든 외래 키에 색인이 자동으로 할당되어 있기 때문에 수백만 행을 검사 할 필요가 없습니다. 그래서 당신이 ID를 알고있는 항목에 대한 모든 태그를 찾는다면, MySQL은 항목에 대한 모든 태그 ID를 찾기 위해'log (3m)'연산의 순서로 필요할 것이고, 또 다른'log (다른 태그의 수)'를 눌러 태그 이름을 찾습니다. 'BINARY'를 사용하기를 원한다면, MySQL은 인덱스 길이를 필요로 할 것이기 때문에 당신의 스키마는 여전히 다른 태그들의 최대 수를 규정한다. – Simon