각 카테고리에 대해 별도의 표를 만들어야합니까?

Question

그래서 저는 최근 C#을 사용하여 오래된 플랫 파일 시스템 스케줄링 시스템을 SQL 데이터베이스로 이전하는 작업을 수행했습니다.

내가 아는 주요 문제는 작업 (아래의 스 니펫보기)에서 문자열 목록 (GUID를 사용하여 만든 목록)을 사용하여 데이터베이스 구성 방법을 확신 할 수 없다는 사실입니다.

public class Task 
{ 
     private string TaskID; 

     private string TaskName; 
     private string TaskDescription; 

     private bool IsComplete; 

     private DateTime EstimatedStartDate; 
     private DateTime ActualStartDate; 

     private DateTime EstimatedCompletionDate; 
     private DateTime ActualCompletionDate; 

     private string TeamLead; 
     private List<string> TeamMembers = new List<string>(); 

     private TaskType TaskType; 
     private string ParentID; 
     private List<string> ChildIDs = new List<string>(); 
} 

SQL의 경우 단일 셀에만 포함될 수있는 목록을 사용하는 것이 일반적으로 비효율적이라는 것을 알고 있습니다.

실제 질문은 : 쿼리가 taskID 또는 parentID를 쿼리하여 요청한 작업을 찾거나 시스템의 각 범주에 대해 서로 다른 테이블로 분할해야하는 목록에 있어야합니다. 네 가지 범주로 작동) 작업 유형 및 taskID에 종속되어 해당 하위 항목을 쿼리해야하는 올바른 테이블을 선택합니다.

Answer 1

준 정식 구문을 사용하여 문제 영역을보다 명확하게 정의하면 도움이됩니다. 코드 스 니펫을 해석하면 다음과 같이 요약 할 수 있습니다.

A task is identified by TaskID 
A task has attributes name, description etc. 
A task has exactly one person, in the role "TeamLead". 
A task has 0 or more persons, in the role "team member". 
A task has exactly one type, selected from a collection of valid types. 
A task may or may not have a relationship to another task, in the role ParentTask 
A task has a relationship with 0 or more other tasks, in the relationship "childTask". 

이 경우 관계형 모델이 나타납니다.

일반적으로 "x..n"연결이있는 모든 관계는 브리징 테이블을 만듭니다. 귀하의 경우에는 "TeamMembers"이고 TaskID 및 PersonID은 외래 키입니다. ChildTasks도 비슷한 관계입니다.

"정확히 하나"또는 "가질 수도 있음"인 경우 외래 키입니다. TeamLead 및 TaskType은 예제입니다.

작업 유형에 대해 다른 테이블을 만들 이유가 전혀 없습니다. 관계형 모델을 사용하면 비슷한 것을 그룹화하고 구조가 아니라 데이터로 구별 할 수 있습니다.

Answer 2

구조가 동일하고 의미가 같은 여러 테이블을 사용하면 올바른 테이블에 액세스 할 수 있습니다 (여러 범주의 데이터를 요약하려는 경우 특히 복잡해집니다). 가능한 범주 세트가 변경 될 때마다 데이터베이스 구조를 수정해야합니다. 측정 가능한 차이는 없지만 성능 차이는 눈에 띄지 않습니다.

은 즉, 테이블 이름에 데이터를를 넣어하지 않습니다.