내 사이트 중 각 사용자의 고유 사용자 아이디, 전자 메일 주소, 비밀번호 등으로 기본 사용자 테이블이 있습니다.각 사용자의 "바이너리 플래그"를 기본 Users 테이블 또는 자체 "바이너리 플래그"테이블에 배치해야합니까?
각 사용자와 관련된 많은 이진 플래그를 추적해야합니다. 메일을 확인했는지 여부, 계정을 업그레이드했는지 여부, Y를했는지 여부, Y를했는지 여부 등
이러한 플래그는 각각 간단한 "0"(거짓) 또는 "1"(참)이며,이 플래그를 기반으로 내 사이트는 사용자를 보여 주거나 다른 일을합니다.
제 질문은이 이진 플래그를 주 Users 테이블에 추가하거나 이진 플래그 또는 다른 것에 대해 별도의 테이블을 만드는 것이 합리적입니까?
당신이 어디에서 왔는지 이해할 수 있도록 추론 (그리고 접근법의 장점)을 설명해주십시오.
모든 플래그를 저장해야합니까, 아니면 으로 계산합니까?? 예를 들어, 사용자가 메시지를 게시하지 않은 경우, 이는 MESSAGE 테이블을 조회하여 쉽게 판별 할 수 있습니다.
"계산 가능한"플래그를 물리적으로 저장하는 것은 불필요하며 데이터 불일치가 발생할 수 있습니다. 예를 들어 사용자가 메시지를 추가했지만 애플리케이션의 버그로 인해 플래그가 업데이트되지 않으면 어떻게됩니까? 이러한 "비정규 화"는 성능상의 이유로 정당화 될 수 있지만, 을 측정 한 후에는의 데이터 및 대표 작업 부하에 대한 성능을 측정 한 후에 만 이러한 결정을 내릴 수 있습니다.
OTOH와 같이 일부 플래그는 "실제"일 수 있습니다 (예 : 사용자가 전자 메일을 확인했는지 여부). 그러한 플래그가 비교적 정적 인 경우 (즉, 데이터 모델을 디자인 할 때 사전에 알 수 있음) USER 테이블 자체에 간단한 부울 (또는 동등한) 필드로 직접 저장하십시오.
상당한 런타임 유연성이 필요한 경우에만 USER 테이블과 N : 1 관계에있는 별도의 FLAG 테이블을 사용하는 것이 좋습니다. 이 종류는 EAV입니다.
두 테이블을 분리 할 때 장점이 있습니다. Users 테이블에 플래그를 넣으면 사용자 ID에 대한 간단한 쿼리를 사용하여 조인을 사용하는 대신 해당 사용자에 대한 모든 정보를 갖게됩니다 그들을 검색하십시오.
다른 측면에서 볼 때, 별도의 테이블에두면 사용자가 Users 테이블에있는 데이터와 "논리적으로"분리되므로 완전히 관련되지 않을 수 있습니다 (둘 다 사용자에 대해 말하더라도). 명확한 데이터베이스 구조.
또 다른 중요한 점은 이러한 데이터를 얼마나 자주 변경하고 가져와야하는지입니다. 예를 들어 로그인 할 때만 필요하면 다음 테이블을 동일 테이블에 유지하고 모든 로그인 정보를 얻으십시오 한 번에 데이터; 대신, 당신이 그들을 반복적으로 변경해야한다면, 당신의 선택은 다른 테이블에 있어야합니다.
그렇다면 필자는 두 가지 테이블 솔루션에 대해 설명 하겠지만, DB 스키마에서이 두 테이블을보고 싶습니다.
입력 해 주셔서 감사합니다. 그래서 내가 올바르게 이해한다면 상대적으로 "정적 인"플래그가 자주 변경되지 않고 Users 테이블에 저장되어야하며 자주 변경되는 플래그는 즉석에서 계산되어야합니다. 맞습니까? 또한 "런타임 유연성"이란 무엇을 의미합니까? – ProgrammerGirl
@Programmer 의미 : 데이터베이스 모델을 설계 할 때 사전에 알고 있습니까? ** 예 ** 인 경우 데이터베이스에 이미있는 다른 데이터에서 파생 될 수 없으면 단순 필드로 저장하십시오. ** 예 **이지만 성능과 데이터 무결성 사이의 올바른 균형이 무엇인지 결정할 때 파생되거나 저장하거나 저장하지 않을 수 있습니다. ** no **를 별도의 테이블에 행으로 저장하면 데이터베이스 구조를 변경하지 않고 (즉, 새로운 열 추가) 런타임에 필요에 따라 쉽게 추가 할 수 있습니다. 즉, "run- 시간 유연성 ". –
@Programmer 이것은 특정 플래그의 _value_ 빈도와 관련이 없습니다. –