다른 테이블에 사용자 및 사용자 프로필을 유지 하시겠습니까?

필자는 개발자가 한 테이블에 필수 사용자 정보 (이메일 / 로그인, 비밀번호 해시, 화면 이름)를 남기고 나머지는 필수가 아닌 다른 사용자 프로파일 (생성 날짜, 국가 등)을 유지하는 것을 선호하는 몇 가지 프로젝트를 보았습니다. 필수적이지 않은 것은이 데이터가 가끔 만 필요하다는 것을 의미합니다. ORM 쿼리를 사용하는 경우 적은 수의 필드를 사용하는 것이 좋습니다. 그러나 두 개의 엔터티를 동일한 테이블에 매핑하면 필요없는 항목을 쿼리하지 않아도됩니다 (더 편리함). 아무도이 두 가지 테이블에 이러한 것들을 유지하는 다른 이점을 알고 있습니까?

프로젝트의 크기와 요구 사항에 따라 다릅니다.

사용자에 대한 데이터를 목적과 요구 사항이 다른 두 세트로 나눌 수있는 한 가지 방법을 볼 수 있습니다.

• 아이디 데이터 : 사용자 이름, 비밀번호 해시, 이메일 주소, 마지막 로그인 시간 등
• 사용자 기본 설정, 최신 활동, 상태 업데이트 등이 포함 된 사용자 프로필 데이터

어느 카테고리에 속할 수있는 사용자에 대한 속성이 있습니다 (예 : 사용자의 생년월일). 그러나이 두 세트의 차이점은 첫 번째 세트는 엄격하게 제어되며 특정 워크 플로를 통해서만 수정할 수 있다는 것입니다. 예를 들어, 비밀번호를 변경하려면 기존 비밀번호를 제공해야하고 이메일을 변경하면 이메일 확인이 필요할 수 있으며 사용자가 비밀번호를 잊어 버린 경우에 사용됩니다.

기본 설정에는 이러한 ACL이 필요하지 않으며 사용자가 동의 한 한 이론적으로 사용자 나 다른 응용 프로그램에서 수정할 수 있습니다. 응용 프로그램이 악의적으로 또는 버그로 인해 데이터가 손상되거나 데이터를 수정하려고 시도하는 경우 위험이 적습니다 (다른 보안 조치를 취한 경우). 그러나 사용자 이름, 암호 또는 전자 메일 중 하나라도 수정 될 수있는 경우 일반적으로 재앙이됩니다. 사용자의 신원을 확인하거나 서비스를 거부하거나 관리자를위한 지원 비용 등을 유발하는 데 사용될 수 있기 때문입니다.

따라서 일반적으로 데이터는 두 가지 유형의 시스템에 저장됩니다.

• 자격 증명 데이터는 일반적으로 디렉토리 또는 IAM 솔루션에 저장됩니다.
• 기본 설정 데이터는 데이터베이스에있게됩니다.

실제로 사람들은 이러한 규칙을 위반하고 하나 또는 다른 규칙 (예 : ASP.NET 멤버 자격 공급자 뒤에있는 SQL 서버)을 사용하게됩니다.

ID 데이터가 커지거나이를 사용하는 조직이 커짐에 따라 여러 유형의 문제가 발생합니다. 예를 들어, 디렉토리의 경우 비밀번호 변경 사항을 다중 서버 환경의 모든 서버에 즉시 복제하려고 시도합니다. 그러나 사용자 기본 설정에는 최종 일관성 만 필요합니다. (FYI : 두 가지 모두 CAPS 정리의 최적화가 다릅니다.)

마지막으로 디렉토리 (예 : 온라인 / 클라우드 디렉토리)는 OAUTH (예 : Facebook, Google, Microsoft 계정, ADFS 고려)와 같은 프로토콜을 사용하여 다른 리소스에 대한 액세스 토큰을 발급하지만 데이터베이스에는 그러한 요구가 없습니다. 데이터베이스는 디렉토리가 필요없는 매우 복잡한 조인 및 쿼리 구조를 지원합니다.

자세한 내용은 신원 디렉토리 대 데이터베이스에 대한 몇 가지 검색이 도움이 될 것입니다.

결국 타사와의 통합 (및 사용중인 대상)을 포함하여 시나리오가 미래에있을 것으로 예상됩니다. 잘 포함 된 프로젝트이고 사용자 ID 데이터를 보호하고 올바르게 인증 할 수 있다고 확신하는 경우 데이터베이스를 사용할 수 있습니다. 그렇지 않으면 자격 증명 디렉토리를 조사 할 가치가 있습니다.

DB, IMO를 사용한다면 하나의 DB와 2를 사용하면 결국 사용자와 응용 프로그램 모두에 대한 액세스 제어가 이루어집니다.

기본 속성에 대한 개인 테이블이 있고 일대일 관계를 갖는 다른 속성에 대한 두 번째 테이블이있는 경우 최소한 세 가지 경우가 있습니다.

• 그림과 같은 BLOB 데이터 . 별도의 테이블을 사용하면 성능상의 이유로 예를 들어 별도의 테이블 스페이스에 데이터를 별도로 저장할 수 있습니다.
• 모든 사람에게 적용되지 않거나 특정 역할을 수행하는 사람에게만 적용되는 데이터. 기본 테이블의 일부인 경우 여러 행에서 널이되는 열로 생각하십시오. 클리닉의 데이터베이스에는 개인 테이블, 환자 테이블 및 의료 테이블이있을 수 있습니다. 첫 번째 테이블에는 기본 속성이 있고 두 번째 테이블에는 개인이 보험 적용 범위와 같은 환자 인 경우에만 해당되는 속성이 있습니다. 세 번째 테이블 (사람이 의료인 인 경우)에는 의료 전문인 및 의료 개인에게만 적용되는 기타 데이터가있을 수 있습니다. 분명히 의료진은 환자가 될 수 있습니다.
• 원격 시스템에서 엔티티와의 관계를 구체화하는 테이블입니다. 이 경우, 테이블은 상호 운용성 이유로 별도의 데이터베이스에서 고유 식별자 사이의 동등성을 설정합니다.

나는 당신이 노출하는 사건이 두 번째 사건에 적합하다고 생각합니다.

그것들을 분리시키는 나의 주된 이유는 객체 지향 프로그래밍에서 '신 클래스'로 알려진 것을 시도하고 피하는 것입니다. ORM은 테이블과 필드를 클래스 및 속성과 관련 시키므로 SQL 레벨과도 관련이 있습니다 (ORM이 없어도 일반적으로 유사한 원칙이 있습니다).

User 클래스 (및 user 테이블과 연관 됨)는 종종 수백 개의 속성 / 필드, 수십 또는 수백 개의 메소드와 1000 개가 넘는 클래스 정의 (메소드에 대한)가있는 god 클래스가되는 테이블입니다. 나는 그것을 모두 보았다. 두 번 이상

따라서 사용자와의 분리는이를 해결하려고합니다. 사람, 사용자, 계정이있을 수 있으며 우려의 분리는 다소 인위적으로 보일 수 있지만 복잡성을 피하려고 노력하고 각 객체가 데이터의 한 측면에만 관심을 갖도록하는 것입니다.