토너먼트 관리 소프트웨어 용 데이터베이스 디자인

Question

현재 PHP, 자바 스크립트 및 MySQL을 사용하여 웹 응용 프로그램을 디자인하고 있습니다. 데이터베이스에 대한 두 가지 옵션을 고려하고 있습니다.

토너먼트 ID와 함께 기본 정보가 저장된 모든 토너먼트에 대한 마스터 테이블을 보유하고 있습니다. 그런 다음 각 테이블 이름에 토너먼트 ID가 추가 된 디비전, 대괄호, 일치 등의 테이블을 만듭니다. 그런 다음 해당 토너먼트에 액세스 할 때 "SELECT * FROM BRACKETS_ [여기에 토너먼트 ID 삽입]"과 같은 간단한 작업을 수행합니다.

내 다른 옵션은 각 레코드가 해당 토너먼트 (또는 괄호, 대괄호와 일치하는 부분 등)에 적절한 외부 키에 연결되어있는 일반 대괄호, 구분, 일치 등의 테이블을 갖는 것입니다 기둥.

첫 번째 접근 방식에 대한 우려는 저에게 너무 비싸고 데이터베이스가 매우 빨리 지저분해질 수있는 것처럼 보입니다. 두 번째 접근 방식에 대한 나의 우려는 성능입니다. 이 프로그램은 국제적이지는 않더라도 국가가 될 것입니다. 한 테이블에 많은 레코드가있는 것을 염려하고 있습니다. 너무 많은 사람들이 동시에 그것을 치면 문제가 발생할 수 있습니다.

데이터베이스 관리와 관련해서는 완전히 새로운 것이 아닙니다. 그러나 이것은 내가 솔로로 완전히 한 첫 번째 것입니다. 그래서 모든 도움이 인정됩니다. 감사!

Answer 1

각 토너먼트에 대한 테이블을 만들지 마십시오. 테이블은 엔터티의 유형이며 엔터티의 인스턴스이 아닙니다. 이러한 개념을 혼합하면 유지 보수성과 확장 성은 무서울 것입니다.

이 프로그램은 국제적이지 않은 국가 일 수도 있지만, 단일 테이블에 너무 많은 레코드가 포함되어있을 가능성이 높습니다. 동시에 많은 사람들이 동시에이를 때릴 수도 있습니다. 문제가 발생할 수 있습니다.

각 레코드에 대해 전체 테이블을 만들어야하는 경우 지구는 어떻게 그 수준으로 확장됩니까?

두 번째 접근 방식의 성능과 관련하여 왜 걱정합니까? 이러한 우려를 뒷받침하는 구체적인 측정 항목이 있습니까? 관계형 데이터베이스는 이 매우 많아 관계형 데이터를 쿼리하는 데 매우 적합합니다. 따라서 관계형 데이터를 유지하십시오. 독창성을 발휘하여 사용중인 데이터베이스 기술의 디자인을 훼손하지 마십시오.

• 대회
• 부문
• 브라켓
• 일치
• 경쟁자
• 등

이 우 :

님의 엔티티의 몇 가지 유형을 명명 한 나는 테이블을 좋아한다. 데이터를 쿼리하는 방법에 따라 인덱스를 관리합니다 (즉, 인덱스를 초과하지 않거나 삽입/업데이트/삭제로 비용을 지불합니다). 데이터를 적절하게 표준화하고 감사 및보고가 더 많이 발생하는 위치를 정형화합니다. 성능에 대해 걱정이된다면 데이터에 액세스하는 방법에 대한 쿼리 실행 경로를 주시하십시오. 약간의 비틀기는 큰 차이를 만들 수 있습니다.

미리 성숙하지 마십시오. 실제적인 이유없이 복잡성이 추가됩니다.

Answer 2

먼저 저장할 항목을 찾으십시오. 토너먼트, 이벤트, 팀, 경쟁자, 상금 등과 같은 것들이 있습니다.이 엔티티 각각은 아마도 테이블 일 것입니다.

각각에 대해 기본 키를 갖는 것이 일반적입니다. 때로는 행을 고유하게 식별하는 열 (또는 열 그룹)이 있으므로 기본 키로 사용할 수 있습니다. 그러나 대개 ID 또는 이와 유사한 숫자 유형의 열을 사용하는 것이 가장 좋습니다. RDBMS가 이러한 열에 대한 색인을 작성하고 사용하는 것이 더 빠르고 쉽습니다.

데이터가 속한 곳에 저장하십시오. prizes 테이블이 아닌 events 테이블에 이벤트의 날짜와 시간이 표시됩니다.

또 다른 중요한 점은 First normal form을 준수한다는 것입니다. 이는 데이터 원 자성을 보장하기 때문입니다. 이것은 나중에 두통을 많이 줄여주기 때문에 중요합니다. 이 작업을 올바르게 수행하면 올바른 수의 테이블도 갖게됩니다.

마지막으로 중요한 것은 검색어에 가장 자주 나타나는 열에 관련 색인을 추가하는 것입니다. 이것은 성능 향상에 많은 도움이됩니다. 너무 많은 행이있는 테이블에 대해 걱정하지 마십시오. RDBMS-es는 요즘 테이블을 수억 개의 행으로 처리하므로 효율적으로 처리 할 수 ​​있습니다.

Answer 3

항목의 새 인스턴스가 나타날 때마다 새 테이블을 만드는 아이디어는 정말 안 좋은 일입니다.

• 귀하의 코드는 새로운 부문이든이 생성 될 때마다 자동으로 테이블을 추가해야합니다 :이 나쁜 생각하는 이유

  A (확실히 불완전한) 목록입니다. 이것은 분명히 나쁜 습관이며 극히 틈새 시장으로 제한되어야합니다. 경우

• 당신은 오류가 발생하기 쉽고 큰 유지 보수 두통에게 (예를 들어, 새로운 필드를 추가) 당신이 가실 것입니다 수백 테이블의에 추가해야합니다
• 를 추가하거나 나중에 테이블 구조를 수정하기로 결정 RDBMS는 테이블 및 관련 (인덱스, 트리거, 제약) 요소가 아닌 행에 맞게 확장되므로 에 대해에 대해 작업하고 있습니다.
• 이 사람은 진정한 클린저가되어야합니다 - "일요일에 경기했던 모든 경기를 나열하십시오"또는 "프랭크 페리가 활동적이었던 가장 최근의 3 개의 괄호를 찾으십시오"와 같은 요청을 어떻게 처리 할 계획입니까?

당신 말 :

는 데이터베이스 관리에 올 때 나는 완전한 newb 아니에요; 그러나 이것은 내가 완전히 솔로 한 첫번째 작품입니다 ...

새로운 세트가 필요할 때마다 테이블이 복제 된 다른 프로젝트를 기억할 수 있습니까? 그렇다면이 접근법에 몇 가지 문제점을 발견하지 못했습니까? 그렇지 않다면 DBA가 어떤 이유로 든 절대 수행하지 않을 것이라고 정확히 생각한 적이 있습니까?

Answer 4

코드의 품질과 유지 보수성을 손상시키는 것 외에도 (다른 사람들이 지적했듯이) 실제로 성능을 얻을 지 여부는 의심 스럽습니다.

당신이 실행

...

SELECT * FROM BRACKETS_XXX 

합니다 ... DBMS는 이름이 "BRACKETS_XXX"를 일치하는 테이블을 찾을 필요하고 검색 자체가 무리 인 DBMS'es 데이터 사전에서 이루어집니다 테이블. 따라서 테이블 내의 검색을 데이터 사전 테이블 내의 검색으로 바꿉니다. 당신은 검색의 가격을 어느 쪽이든 지불합니다.

(사전 테이블 또는 "진짜"테이블, 그리고 수도 있고 실제 테이블과 유사한 성능 특성이 없을 수 있습니다, 그러나 나는 이러한 성능 특성 에 대한 "정상"테이블보다 더 나은 될 가능성 내기하지 않을 수도 있습니다 행 번호 큽니다. 또한, 데이터 사전의 성능이 가능성이 문서화해야합니다 그리고 당신이 정말로 문서화되지 않은 기능에 의존해서는 안됩니다.)

는 또한, DBMS 갑자기 (prepare 더 많은 SQL 문에 필요 그들은 이후 별도의 표를 참조하여 다른 진술), 추가 사전을 제시합니다. 성능에 의지합니다.