관계형 데이터베이스에 대해 약간의 작업을 해왔으며 좋은 스키마 디자인의 기본 개념을 잘 이해하고 있다고 생각합니다. 저는 최근에 고임금 컨설턴트가 DB를 설계 한 프로젝트를 맡았습니다. 내 직감이 본능인지 알려주세요- “WTF ??!?” -보증을 받습니까, 아니면이 사람이 저의 영역에서 운영되고있는 천재입니까?

문제의 DB는 직원의 요청을 입력하는 데 사용되는 사내 앱입니다. 작은 부분 만 살펴보면 사용자에 대한 정보와 요청에 대한 정보가 있습니다. 나는 이것을 이렇게 디자인 할 것이다.

사용자 테이블 :

UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department

요청 테이블

RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table

간단 하죠?

컨설턴트는 다음과 같이 설계했습니다 (샘플 데이터 사용).

Users 테이블

UserID  FirstName   LastName
234     John        Doe
516     Jane        Doe
123     Foo         Bar

부서 표

DepartmentID   Name
1              Sales
2              HR
3              IT

UserDepartmentTable

UserDepartmentID   UserID   Department
1                  234      2
2                  516      2
3                  123      1

요청 표

RequestID   UserID   <...>
1           516      blah
2           516      blah
3           234      blah

전체 데이터베이스는 이와 같이 구성되며 모든 데이터는 자체 테이블에 캡슐화되며 숫자 ID는 모든 것을 연결합니다. 컨설턴트는 OLAP에 대해 읽고 ‘정수 조회 속도’를 원했던 것 같습니다.

또한 이러한 모든 테이블을 상호 참조 할 수있는 많은 저장 프로 시저가 있습니다.

중소 규모의 SQL DB에 적합한 디자인입니까?

의견 / 답변 주셔서 감사합니다 …

답변