여분의 열이있는 단일 테이블 대 스키마를 복제하는 여러 테이블

어느 시점에서 데이터베이스에서 모든 레코드가 사용하지 않는 여러 열이있는 단일 테이블이나 스키마가 중복 된 여러 테이블이 있는지 여부를 결정 해야하는 프로젝트를 진행하고 있습니다.

여러 스포츠를 처리 할 수있는 스포츠 정보 응용 프로그램을 만들고 있습니다. 우리는 예를 들어 NBA, NHL, MLB, NFL을 처리 할 수 ​​있습니다. 각 스포츠는 팀, 일정, 부상, 선수 정보와 매우 유사한 개념을 가지고 있습니다.

물론 우리의 데이터 소스는 동일한 스키마의 각 데이터를 제공하지 않습니다. 각 스포츠에는 공급 업체로부터 데이터를받는 다른 스키마가 있습니다.

공통점을 판단하기 위해 데이터 피드를 사전 분석 할 시간이 충분하지 않았기 때문에 (내가 요구하는) 내기를 걸고 '안전한 내기'를 수행하여 모든 스포츠 테이블마다 개별 테이블을 만들었습니다 사용되는 스포츠.

결과는 여러 테이블에 스키마가 복제되므로 데이터베이스에 대한 인터페이스 (예 : 저장된 procs)도 복제됩니다. NBA_Game, NFL_Game, NBA_Team, NFL_Team 등이 있습니다. 각 테이블에는 다른 테이블에는없는 몇 가지 속성과 공유되는 몇 가지 속성이있을 수 있습니다. 4 개 또는 5 개의 스포츠에서 5-10 개의 테이블로 진행됩니다. 나는 이것이 완전히 나쁜 일인지 확실하지 않습니다. 대체, 모든 스포츠가 사용하지 않을 속성이있는 단일 테이블 세트를 갖는 대안은 자체적으로 다루기 어려울 수도 있습니다.

이 작업을 한 사람이 이런 종류의 디자인의 함정에 빠졌고 여기에서 경험을 공유 할 수 있습니까? 어려운 길을 배우는 대신 지금 아는 데 도움이 될만한 것들이 있습니까? 모든 레코드가 사용하지 않는 열이있는 하나의 큰 테이블 / 테이블 집합을 사용하여 다른 방법으로 수행 했습니까? 그 일에 어떤 함정이 생겼습니까?

과거에 더 잘 작동했던 테이블 상속 과 같은 대안이 있습니까?

감사

궁극적으로 사용 및 아키텍처가 결정됩니다.

건축물

시스템이 "모든 스포츠"를 처리합니까? 건축 우주 비행사 모자를 쓰고 오늘날에도 존재하지 않을 미래의 모든 유형의 스포츠를 처리 할 수있는 일반적인 시스템을 구축한다는 아이디어가 있습니까?

그렇다면 동적으로 이름이 지정된 테이블을 갖는 것은 큰 고통이므로 필요한 경우 n 개의 스포츠를 지원하는 스키마를 갖는 것이 좋습니다.

즉, 나는이 접근법에 대한 매우 강한 편견이 있습니다. 이것은 거의 항상 더 많은 작업이며 결과가 좋지 않습니다. 각 스포츠에 대해 별도의 UI, 스키마 등을 만들면 궁극적으로 약간의 중복이 발생하더라도 사용자 경험이 향상되고 코드를 유지 관리하기가 더 쉬워집니다 (이를 피 / 최소화하는 방법은 별도의 질문 임).

여러 스포츠를하는 플레이어는 어떻게 처리합니까? 그들은 두 가지 항목을 얻습니까 (예를 들어, 다른 사람으로 취급) 그들과 관련하여 무언가를하려고합니까?

사용하다

따라서 스포츠를 동적으로하지 않는다고 가정 해 봅시다 (예 : 누군가가 새로운 스포츠를 추가하려면 추가 노력이 필요합니다).

한 번에 둘 이상의 스포츠에서 플레이어 (또는 언급 한 다른 개체)를 표시하는 시간이 있습니까?

나는 검색 기능에 대해 이것을 볼 수 있습니다. 여기서 스포츠에 관계없이 선수 또는 팀 이름으로 검색 할 수 있지만 그 외에도 많은 유스 케이스를 상상할 수 없습니다.

이 작업을 수행 할 필요가 없으면 접근 방식이 완벽합니다. 여기서 읽을 수 없습니다.

대체 스키마

견해

나는 KISS의 팬입니다. 15 년 이상의 소프트웨어 개발 과정에서 저는 "가장 간단한 일을하는 것"이라는 철학으로 계속 넘어갑니다.

크로스 스포츠 검색 기능이 실제로 유일하게 사용된다고 가정하면 내 초기 반응은 뷰를 만드는 것입니다.

SELECT PlayerName, 'NFL' as [Sport], TeamName FROM NFL_Players JOIN NFL_Teams ... 
UNION  
SELECT PlayerName, 'NHL' as [Sport], TeamName FROM NHL_Players JOIN NHL_Teams ... 
UNION ....

물론 새 스포츠를 추가하면 뷰에 추가해야합니다. 다른 공통 정보를 포함하는 것이 유용 할 수도 있지만 실제로는 표시해야 할 사항에 따라 다릅니다.

모든 스포츠 관련 항목을 View 정의에 유지하려고하므로 검색 코드에 많은 코드가 있거나 특정 코드가 필요하지 않습니다 (어떻게 앱 /nhl/players/player-name과 링크하는지 /nfl/...또는 앱이 링크하는지 아는 것 외에도 ).

테이블 상속

테이블 상속은 작동 할 수 있지만 매우 복잡합니다. 나는 그것에 대해 많은 경험을 가지고 있지 않으며, 실제로, 나는 그것을 평가할 때마다 더 간단한 것을했다고 생각합니다 (여기에서 제안하는 것처럼).

그래서 개인적으로, 이것이 왜 유용한 지 아직 찾지 못했지만 복잡성을 정당화하는 설득력있는 유스 케이스가 있습니다 (예 : 테이블 상속이 다른 솔루션보다 유스 케이스를 더 잘 해결합니다) .

스포츠 별 속성을위한 별도의 테이블

players모든 스포츠의 모든 플레이어에게 공통적 인 속성을 가진 단일 테이블을 수행 한 다음 nhl_players_detailsplayerId 및 플레이어에 대한 추가 정보가있는 열을 포함하는 다른 테이블 세트를 수행 할 수 있습니다. 공통된 속성이 많거나 "모든 스포츠의 모든 플레이어"를 많이 사용하는 경우 이는 의미가 있습니다.

스포츠 별 속성의 키 값 쌍

완전히 다른 접근하십시오 가지고 players다음 (일반 이름 같은 속성을 다시) 테이블 player_data이 테이블을 PlayerId, Sport, Attribute, Value. 입력 한 속성 이름은 스포츠에 따라 다릅니다. 이를 통해 스키마를 수정하지 않고도 기본적으로 새로운 속성을 추가 할 수 있습니다 (코드는 물론로드 / 표시해야 함). 단점은 무결성을 잃는다는 것입니다. 값은 일반적으로 문자열 필드이므로 앱 코드는 복원력이 뛰어나고 문자열 value을 정수와 같은 특정 데이터 유형으로 변환하는 잠재적 인 오류를 처리 해야합니다.

이 개념은 물론 팀, 게임 등에 적용될 수 있습니다.

데이터베이스 표준화 에 대해 이야기하고 있습니다. 완벽한 데이터 모델과 같은 것은 없으며 정규화가 항상 좋은 것은 아니라는 사실을 알게 될 것입니다. 정규화는 데이터 모델의 명확성과 데이터베이스 성능 측면에서 비용을 부과 할 수 있습니다. 따라서 가장 적합한 모델은 사용 요구 사항에 따라 다릅니다.

표면적으로, 당신의 예제는 개념 (X_Game vs Y_Game 및 X_Team vs Y_Team)에서 충분히 비슷해 보입니다. 즉, 각 스포츠가 테이블에 수십 개의 추가 열을 추가하면 실제로 다루기 어려울 것입니다.

이 경우 공통 데이터는 중앙 테이블에 유지되지만 스포츠 관련 데이터는 연결된 데이터 구조로 유지되는 하이브리드 모델을 고려할 수 있습니다. 다음과 같은 것 :

table Game {
    gameId int,
    teamId1 int fk,
    teamId2 int fk
}

table HockeyGame {
    gameId int fk,
    penaltyMinutes int
}

table BasketballGame {
    gameId int fk,
    freeThrows int
}