2012-12-31 4 views
1

나는 다음과 같은 정보를 저장하는 데이터베이스가 필요합니다SQL 다중 사용자 유형 데이터베이스

사용자 : 이름, 성, 이메일, 모바일, 설명/소개, 유형 (직원/프리랜서/클라이언트)

직원 수 : 유형 (디자이너/FE 개발자/BE 개발자/DB 개발자/SE 낙천가), 직원 수
(프로젝트 관리자, 직원 근무), 진행중인 활동중인 프로젝트, 주소, 기술 (HTML/CSS/JS/ASPX/PHP/DB 개발/SEO/디자인), 소프트웨어 (포토샵/일러스트 레이터/인 - 디자인/불꽃 놀이 /으로 VisualStudio /은 mSQL/워드 프레스)

프리랜서 : 유형 (디자이너/FE 개발자/BE 개발자/DB 개발자/액티브 프로젝트가 작업 SE 낙천가가) 프로젝트가했다, 주소, 기술 (HTML/CSS/JS/ASPX/PHP/DB 개발/SEO/디자인), 소프트웨어 (포토샵/일러스트 레이터/인디자인/불꽃 놀이 /으로 VisualStudio /은 mSQL/워드 프레스)

클라이언트 : 프로젝트가 소유, 활성 , 주소 (집에서/일/인보이스/배달) 소유의 프로젝트

주소 : 하우스 없음 :, 주소, 행 2, 3 행, 카운티, 국가, 우편 번호, 유선

프로젝트 : 제목, 클라이언트 이름, 시작 날짜, 종료 날짜, 기한, 상태 (활성, 대기, 비활성), 정보, 개발 팀 (프로젝트에서 작업하는 프리랜서 또는 직원 목록), 진행률 (마일스톤 : 설계/FE/BE/DB/BO/SEO/배포)

기본적으로 내가 고민하는 것은 다른 유형의 주소 및 사용자 등이 있습니다. 예를 들어 사용자는 다음과 같을 수 있습니다. 직원 또는 프리랜서 또는 클라이언트 또는 직원 또는 프리랜서가 클라이언트 일 수 있습니다. 그게 어떻게 데이터베이스 형식에서 작동할지 모르겠다. 주소 유형 등에 대해서도 동일합니다.

어떤 도움 이라니? 나는 정말로 붙어있다. 미리 감사드립니다.

+0

사용자에 대해 적용 가능한 모든 유형을 설명하는 "속성"테이블을 가질 수 있습니다. 예를 들어,이 테이블의 레코드가 사용자 ID 1 인 경우 Staff 또는 Freelancer 또는 Client 유형과 같이 해당 사용자를 고유 한 유형 ID로 설명하는 여러 유형을 나열 할 수 있습니다. –

+0

e/r 다이어그램을 검토하십시오. http://en.wikipedia.org/wiki/Database_design#ER_Diagram_.28Entity-relationship_model.29 – jcho360

답변

0

외래 키의 개념을 사용하여이 모든 작업을 수행 할 수 있습니다.

일반적으로 각 테이블에 데이터의 각 행에 대한 식별자로 사용할 기본 키 열을 제공하는 것이 좋습니다. User 테이블에는 ProjectId 등의 UserId가 있습니다.

거기에서 외래 키 제약 조건을 다른 테이블의 열에 추가하여 해당 행을 사용자에 매핑하도록합니다. 예를 들어, Address 테이블에는 User 테이블의 외래 키인 UserId라는 열이 있습니다. 이 키는 해당 행의 주소가 해당 사용자에 속한다는 것을 알려줍니다.

외래 키 제약 조건을 작성하는 방법은 요구 사항 및 데이터 간의 관계에 따라 달라집니다. 간단한 쿼리를 사용하여 필요한 모든 정보에 액세스 할 수 있도록 알아야 할 것이 있습니다.

또한 데이터가 계층 구조임을 명심하십시오. 클라이언트, 프리랜서 및 직원이 있으며 각각은 주소가 필요합니다. 그러나이 3 개 모두는 사용자이기도합니다. 이러한 각 테이블을 User 테이블에 키를 입력 한 다음 Address 테이블을 User 테이블에도 입력하는 것이 훨씬 더 합리적입니다. 이를 통해 관계가보다 유연하고 이해하기 쉬워집니다.

2

RDBMS 디자인의 기본 사항을 묻습니다. 때로는 엔티티 - 관계 디자인이라고도합니다. 그것은 큰 주제입니다. 그 책을 읽을 수도 있습니다.

시스템의 고유 한 사람을 설명하는 행이있는 Person 테이블이 필요합니다.

그러면 각 조직 (회사, 컨설팅, 프리랜서 엔터티, 고객, 공급자 등)을 설명하는 행이있는 조직 테이블이 필요할 수 있습니다.

Person_Organization 테이블은 개인을 조직과 관련시킬 수 있습니다. 이것은 Person과 Organization 사이에 다 대다 엔티티 관계를 구현합니다. 이 테이블은 PersonID, OrganizationID 및 해당 조직에서 그 사람의 역할을 설명하는 필드를 포함 할 수 있습니다.

연락처 정보 (주소, 전화 번호, 이메일 등)가있는 연락처 테이블을 추가 할 수 있습니다. 그것은 각 행에 개인 ID를 포함합니다.

각 프로젝트에 대해 행이있는 프로젝트 테이블이 있어야합니다. 여기에는 단일 고객을 식별 한 OrganizationID 및 프로젝트를 설명하는 기타 자료가 포함됩니다.

또한 각 프로젝트에서 역할을 담당하는 각 조직에 대한 역할이있는 역할 테이블이 있습니다.

둘 이상의 연락처 주소가있는 조직을 처리하는 방법은 사용자에게 남겨 둡니다.

이런 종류의 작업에서는 "너무 영리합니다."라는 점에 유의하십시오.

관련 문제