사이트 등록을 활성 사용자에게 별도의 테이블에 저장해야 합니까?

Question

사용자 등록에 대한 모범 사례가 궁금합니다.나는 별도의 등록 테이블에 사이트 등록을 저장한 다음 데이터를 사용자 테이블로 전송하는 이메일을 통해 가입이 확인되면 기울고 있습니다.

이것의 이점은 사용자 테이블의 읽기가 활성화되지 않은 등록으로 인해 복잡해지지 않는다는 것입니다.또 다른 이점은 이메일(사용자 이름) 필드가 사용자 테이블에서 고유하게 유지될 수 있다는 것입니다. 그러나 귀하가 소유하지 않은 이메일 주소로 등록을 시도하는 경우 해당 이메일 주소의 소유자는 여전히 해당 이메일 주소를 이메일 필드는 등록 테이블에서 고유하지 않습니다.

이것이 일반적인 관행인지, 아니면 이것이 좋은 생각이 아닌 이유가 있는지 궁금합니다.

Answer 1

활성화 여부

다른 테이블에 사용자를 저장할 필요가 없습니다. 모든 사용자를 하나의 테이블에 보관하면 부울 플래그가 활성화되었는지 여부를 나타냅니다. 너무나 종종 Cron 작업을 실행하여 X 일이었고 활성화되지 않은 계정이 있는지 확인하고 확인하십시오.

이메일

아마도 당신은 이메일에서 사용자를 활성화하고 있습니까? 다른 사용자가 다른 사람의 이메일을 입력 한 경우 다른 사람이 여전히 올바르게 등록 할 수 있도록 설정하고 싶습니까? 그것은 실제로 다소 간단합니다. 실수로 전자 메일로 보내는 이메일에는 데이터베이스에서 전자 메일을 제거 할 수있는 링크가 있어야합니다.

그러나 다른 사람이 방금 삭제하면 어떨까요?

그런 다음 등록하면 이미 이메일이 있고 활성화를 다시 보내겠다고 제안하면이 이메일은 데이터베이스에서 제거 할 수있는 옵션도 있습니다.

또는

데이터베이스에서 이전 계정을 제거하십시오. 그 사람이 새 계정을 활성화하려고 시도하고 활성화되지 않은 오래된 계정이 있으면 제거 할 수 있습니다.

Answer 2

나는 그것이 엔지니어링 과잉 일 것이라고 생각합니다.

이 모든 것을 하나의 테이블에 저장하고 30 일 이하의 작용 계정을 삭제하도록 SQL 쿼리 (매일)를 예약하십시오.

Answer 3

자신에게 호의를 베풀고 단일 테이블을 유지하십시오. 성과 문제가 발생할 수있는 등록이 충분하지 않을 것입니다 (특히 3 주 후에 닦는 경우).

이메일 주소에 대한 귀하의 정당성은 어리석은 일입니다. 아무도 허위 등록으로 이메일을 차단하지 않을 것입니다.

Answer 4

두 테이블을 논리적으로 분할하는 경우가 하나 있을 수 있습니다.이메일 주소를 확인한 후에만 등록 과정에서 많은 필수 사용자 정보를 요구하는 경우.예를 들어, 보류 중인 등록 테이블에 이메일 및 활성화 키와 같은 몇 개의 열만 있는 반면 사용자 테이블에는 사용자 이름, 이름, 성, 우편 주소 등과 같은 많은 추가 열이 있는 경우

이 경우 해당 열을 선언할 수 있으므로 분할이 의미가 있을 수 있습니다. NOT NULL.

하지만 그 외에는 대부분의 답변에 동의해야 합니다.나에게는 조기 최적화처럼 들립니다.동일한 구조를 가진 여러 테이블은 다음과 같은 강력한 경고 신호입니다. 당신이 잘못하고 있어요. 확실하지는 않지만 강력한 경고입니다.

Answer 5

우려 사항의 분리에 대한이 관행에 동의합니다. "등록 프로세스"와 "사용자 계정"은 두 가지 개념입니다.

등록 테이블은 "등록 절차"의 상태를 지속하는 데 사용됩니다. 해당 프로세스가 완료되면 (이메일이 확인되면) 프로세스의 "출력"은 새로운 "사용자 계정"입니다. 프로세스가 실패하면 (예를 들어, 사용자가 1 개월 동안 이메일을 확인하지 못한 후에는 "타임 아웃"되면 "사용자 계정"개념에 영향을 미치지 않습니다.

또 다른 대답에서 말했듯이, 이것은 경우에 따라 과잉 엔지니어링 일 수 있지만,이 두 개별 개념의 복잡성을 행사하는 유용한 방법 일 수도 있습니다. 그것은 또한 정규화 원칙을 모순하는 것으로 보일 수 있지만, 나는 당신이 당신의 컨텍스트에 따라 캡슐화와 정규화 사이의 트레이드 오프를 선택해야한다고 생각합니다.