관계형 데이터베이스에서 사용자 테이블과 사람 테이블 분리

Question

나는 가장 먼저 사용자 이름, 비밀번호, 이름, 이메일 및 기타 일반적인 표류물이 포함된 사용자 테이블을 만드는 많은 웹 앱을 수행했습니다.현재 프로젝트에서는 비사용자 레코드가 사용자와 유사하게 작동해야 하지만 1차 사용자가 될 필요는 없는 상황을 제시합니다.

두 번째 테이블을 만드는 것이 합리적인가요? people_tb, 이는 기본 관계형 테이블이자 데이터 저장소이며 users_tb 인증을 위해?분리합니까 user_tb ~에서 people_tb 문제가 있나요?이것이 일반적으로 수행된다면 몇 가지 전략과 해결책은 물론 단점은 무엇입니까?

Answer 1

데이터베이스를 정규화하는 것이므로 이는 확실히 좋은 생각입니다.저는 제가 작성하고 있는 앱에서 직원 테이블과 사용자 테이블이 있는 유사한 디자인을 수행했습니다.사용자는 외부 회사나 직원일 수 있으므로 직원은 항상 사용자이지만 사용자는 직원이 아닐 수 있으므로 별도의 테이블을 만들었습니다.

직면하게 될 문제는 user 테이블을 사용할 때마다 거의 항상 person 테이블이 표시하려는 이름이나 기타 공통 속성을 가져오기를 원한다는 것입니다.

코딩 관점에서 볼 때, 직접 SQL을 사용하는 경우 select 문을 정신적으로 구문 분석하는 데 약간의 노력이 더 필요합니다.ORM 라이브러리를 사용하는 경우 조금 더 복잡할 수 있습니다.나는 그런 것들에 대한 경험이 충분하지 않습니다.

내 애플리케이션에서는 Ruby on Rails로 작성하고 있으므로 직원.사용자.이름과 같은 작업을 지속적으로 수행합니다. 여기서 이들을 함께 보관하면 직원.이름 또는 사용자.이름만 됩니다.

성능 관점에서 볼 때 하나가 아닌 두 개의 테이블에 도달하지만 적절한 인덱스가 제공되면 무시할 수 있습니다.예를 들어 기본 키와 사람 이름이 포함된 인덱스가 있는 경우 데이터베이스는 사용자 테이블에 도달한 다음 개인 테이블에 대한 인덱스(거의 직접 적중)를 사용하므로 성능은 다음과 거의 같습니다. 테이블이 하나 있어서.

또한 데이터베이스에 뷰를 생성하여 두 테이블을 함께 결합한 상태로 유지함으로써 추가적인 성능 향상을 제공할 수도 있습니다.Oracle의 이후 버전에서는 성능을 높이기 위해 필요한 경우 뷰에 인덱스를 넣을 수도 있다는 것을 알고 있습니다.

Answer 2

저는 "사용자"(사용자 이름, 비밀번호, 생성 날짜, 마지막 로그인 날짜) 개념이 "사람"(이름, 주소, 전화, 이메일) 개념과 다르기 때문에 일상적으로 그렇게 합니다.발견할 수 있는 단점 중 하나는 원하는 정보를 얻기 위해 쿼리에 더 많은 조인이 필요한 경우가 많다는 것입니다.가지고 있는 것이 로그인 이름뿐이라면 예를 들어 성과 이름을 얻으려면 "people" 테이블에 가입해야 합니다.사용자 ID 기본 키를 중심으로 모든 것을 기반으로 하는 경우 이는 약간 완화되지만 여전히 팝업됩니다.

Answer 3

user_tb에 인증 정보가 있으면 people_tb와 별도로 보관할 것입니다.그러나 나는 둘 사이의 관계를 유지할 것이며 인증에 필요한 모든 정보를 제외하고 대부분의 사용자 정보는 people_tb에 저장될 것입니다(다른 용도로는 많이 사용되지 않을 것 같습니다). 디자인과 효율성 사이의 절충안입니다. 생각하다.

Answer 4

나는 항상 가능한 한 많은 데이터 반복을 피하려고 노력합니다.모든 사람이 로그인할 필요가 없는 경우 일반 로그인을 사용할 수 있습니다. people 사람과 사용자 모두에게 적용되는 정보가 포함된 테이블(예:이름, 성 등).

그런 다음 로그인하는 사람들에 대해 users 1~1 관계에 있는 테이블 people.이 테이블은 사용자 이름과 비밀번호를 저장할 수 있습니다.

Answer 5

나는 정규화된 디자인(테이블 2개)을 선택하고 실제로 인생을 더 쉽게 만들 수 있는 경우에만 비정규화(하나의 사용자/사람 테이블로 이동)한다고 말하고 싶습니다.그러나 실제로 모든 사람이 사용자이기도 하면 미리 비정규화하는 것이 더 간단할 수 있습니다.그것은 당신에게 달려 있습니다.나는 문제없이 정규화된 접근 방식을 사용했습니다.

Answer 6

매우 합리적입니다.

예를 들어 aspnet_* 서비스 테이블을 살펴보세요. 여기.

내장된 스키마에는 aspnet_Users 그리고 aspnet_Membership 나중 테이블에는 특정 사용자에 대한 더 확장된 정보(해시된 비밀번호 등)가 포함되어 있지만 aspnet_User.UserID 참조 무결성 등을 위해 스키마의 다른 부분에서 사용됩니다.

결론적으로, 귀하의 경우와 같이 속성이 다른 엔터티인 경우 별도의 테이블에 속성을 갖는 것은 매우 일반적이며 좋은 디자인입니다.

Answer 7

우리는 수백만 명의 기록을 보유하고 있고 사용자는 수천 명에 불과하므로 이것이 바로 우리가 하는 일입니다.또한 많은 사람들이 이러한 항목 중 하나 이상을 갖고 있으므로 주소, 전화 및 이메일을 관계형 테이블로 분리합니다.이름은 고유하지 않으므로 식별자에 의존하지 않는 것이 중요합니다.이름이 아닌 특정 유형의 대리 키(정수 또는 GUID가 바람직함)를 통해 테이블이 조인되었는지 확인하세요.