사용자가 아티스트, 앨범 또는 노래를 검색 할 수있는 뮤직 플레이어를 만들고 있습니다.음악 데이터베이스의 구조 - 여러 테이블 또는 단일 테이블?
음악 라이브러리의 mp3에서 모든 태그를 읽고 아티스트 이름, 앨범, 트랙 제목 등이 포함 된 단일 테이블에서 노래 데이터베이스를 업데이트하는 스크립트를 만들었습니다. 현재이 방법이 작동합니다 음, 음악 라이브러리의 변경 사항을 검색하고 데이터베이스에서 해당 노래에 대한 행을 추가/삭제할 수 있기 때문입니다. 이 스캔 루틴은 단일 테이블 만 유지하기 때문에 이해하기 쉬운 코드 조각입니다.
아티스트, 앨범 및 트랙에 자체 테이블이 있고 모두 서로 링크되어 있으면 데이터베이스가 더 강력해질 것입니다. 아직 검색 부분에 대해서는 아무 것도하지 않았습니다. 모든 것을 하나의 테이블에 보관하면 어떻게 될까요?
감사합니다.
정말 엉망입니다. 그것은 거의 정상화되지 않았습니다. 별도의 테이블을 찾으십시오.
정규화에 대해 들어 본 적이 없거나 왜 중요한지 잘 모르는 경우 this을 읽어야합니다. 많은 특수 용어가없는 간결하고 간단한 설명입니다.
하거나 이미 MySQL을 사용하고 있기 때문에 당신은 소스에 바로 갈 수 : http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
이 모델의 카디널리티 관계에 대해 생각을 :
하면 인덱스, 기본 및 외래 키에 대해 신중하게 생각 할 것 (작가는-에 앨범 대다입니다). 검색하려는 키가 아닌 열이나 그룹에 색인을 추가하십시오.
이 디자인은 앨범, 트랙, 아티스트 및 artist_to_album의 4 개 테이블을 보유하게됩니다.
데이터베이스가 정규화되지 않았습니다. 당신은 모든 하나 개의 테이블에 말할하지만 스키마에 대한 정보를 제공하지 않았습니다. 중복 된 정보를 저장에 관련된 일관성에 문제가 포함되어있는 비 표준화 된 데이터베이스 문제의
종류 - 당신이 같은 경우 :
앨범, 트랙, 아티스트
다음 앨범 이름을 변경하려면, 앨범과 관련된 모든 트랙에서이를 변경해야합니다.
물론,이 표준화되지 않습니다 거기 "데이터베이스"시스템의 모든 종류가 있지만, 이들은 보통 패러다임에 적합한 사물의 이러한 종류를 처리 할 수있는 메커니즘을 가지고있다.
그래서 당신은 "정상화"라고 대해 요구하고이 많은 상황에서 유용하지만, 항상 적용 할 수없는 주제.
아티스트 핑크를 고려해보십시오. 그녀의 앨범 중 일부는 그녀의 이름이 Pink이고 기타는 P!nk입니다. 우리는 그것이 그녀임을 알기 때문에 시각적으로 똑같은 것으로 인식합니다. 그러나 데이터베이스는 강제로이 두 가지를 별도로 보게됩니다 (또한 그녀의 노래를 더 세게 검색하지만, 그것은 또 다른 이야기입니다). 또한 난 (예술가 모두 Pink 및 P!nk에 일치하지만도 등 그녀의 앨범 Funhouse에 일치 ID을 가지고 그래서 할 수 있습니다 등
왕자, "공식적으로 왕자로 알려진 작가를"고려 더 많은 예제가 표로 작성되어야하기 때문에 지금 예제로 끝낼 것입니다.)
그래서 질문은 얼마나 복잡합니까? 검색을 원하십니까? 마찬가지로 태그와 데이터베이스 정보간에 1 : 1 상관 관계를 유지할 수 있습니다. 그것은 당신이 원하는 것을 얼마나 좋아하는지에 달려 있습니다. 또한 위에서 언급 한 조회에 대해 사용자가 정보를 제공한다는 사실을 대부분 고려하면 코끼리에서 Pachyderm에 이르는 것보다 P! nk에서 Pink까지 조회를 제공 할 수 없습니다. 사람들이 들어 오기를 원할 것입니다.
이 경우에는 순진한 접근 방식이 좋다고 생각합니다.
또한 예술가, 앨범, 타이틀뿐만 아니라 제작자, 믹서, 스튜디오, 밴드 멤버, 작사가 등도 고려해야합니다. 그런 다음 원본 디스크와 동일한 정보의 특별판 재 출시가 있습니다. 그것은 복잡해진다. 진짜 질문은 당신의 의도가 무엇인지, 당신의 유스 케이스는 무엇입니까? 대부분의 사람들은 음악 목록에 이러한 모든 요소가 필요하지 않습니다. – jcolebrand
"Pink"및 "P! nk"와 같은 문제는 삽입하기 전에 일종의 스크러빙을 사용하여 해결할 수 있습니다. 당신이 정규화에 대한 어떤 묘사를 했었다면, 당신이 그렇게하지 않았다고 나를 비난했기 때문에 나는 더 감동했을 것입니다. 당신의 대답은 오히려 실망 스럽습니다. 나는 훨씬 더 통찰력이있는 무엇인가를 기대했다. – duffymo
물론 위키 피 디아는 주제에 대한 좋은 글을 남겼으므로 여기 정규화에 대한 심층적 인 토론을하지 않았으며 정상화에 관해 이야기하는 많은 스레드가 있습니다. 그러나이를 확인하고 그를 고려해야 할 몇 가지 사항을 지적하려고했습니다 . 내 게시물을 올렸을 때 귀하의 의견은 약 10 단어로 매우 도움이되지 않았습니다. 위에서 언급 한 바와 같이 그 이후로 수정했습니다. 당신의 마음이 대답에 없었던 것처럼 보였습니다. – jcolebrand
Pink/P! nk 상황과 관련하여 큰 문제인 경우 정규화가 유용 할 것입니다.
노래 테이블이 artist_id를 참조합니다.
아티스트 별칭 테이블은 특정 아티스트의 다양한 이름을 해당 artist_id에 매핑합니다.
하지만 상당히 기술적으로 어려울 수 있습니다. 예술가가 다른 이름으로 프로젝트를 출시하기로 결정한 것처럼 상황이 올바르지 않을 수도 있습니다. 프로젝트를 모두 함께 정리하기를 원하지 않을 수도 있습니다.
일반적으로 표준화 된 데이터베이스는 시작하기에 안전한 장소이지만, 비정규화할 충분한 이유가 있으며, 그 이유를 이해하고 맹목적으로 일방적으로 일하는 것이 더 중요합니다.
고마워요 @Daryn, 그게 제가 설명하려고했던 것입니다. 나는이 특정 데이터 세트를 정상화하는 것이 좋다고 생각하지 않는다. 어쨌든 ... – jcolebrand
나는 OP가 4 개의 테이블 주위에 머리를 맞출 수 없다면 이미 심각한 위험에 처해있다. – duffymo
Pink/P! nk 상황은 데이터베이스를 수동으로 유지해야하기 때문에 큰 문제는 아니며, 별칭이 다른 수많은 예술가가 있습니다. Last.fm이 Pink와 P! nk를 두 개의 서로 다른 엔티티로 나열하면 두 개의 다른 아티스트로 사용하는 것이 나에게 충분합니다. – Wurlitzer
@drachenstern - 매우 심각합니다. 영업 사원은 정상화에 대해 알지 못한다고 가정합니다. 그것은 좋은 가정이지만 내가하지 않기로 결정한 것입니다. 나는 너의 모범과 논평을 읽을 것이다. – duffymo
~ 이제 다시 돌아와서 좀 더 자세히 설명해 드리겠습니다. 불만을 철회합니다. – jcolebrand
한 사람이 할 수있는 일은 사람이 할 수있는 일을합니다. 나는 항상 내가 처음으로 원하는 답을 줄 시간이 없다. – duffymo