DB설계시 제공식별자, 시스템 생성 식별자의 장단점

1.사용자 제공 식별자 (예: 이메일 또는 사용자 이름)

 

장점: 사용자가 기억하기 쉽고, 로그인 시스템 등에서 자연스럽게 사용할 수 있다.

단점: 변경될 수 있으므로, 사용자가 이메일 주소나 사용자 이름을 변경하면 연결된 모든 정보를 업데이트해야 할 수도 있다.

또한 보안 문제로 예를 들어, 사용자 이메일이 공개적으로 알려져 있으면 스패밍 또는 사기에 이용될 수 있다.

 

 

2.시스템 생성 식별자 (예: 자동 증가 ID, UUID)

 

장점: 이 식별자는 시스템에 의해 제어되므로 변경되지 않는다. 이를 통해 데이터 일관성을 유지하고 보안 문제를 방지할 수 있다.

단점: 사용자가 기억하기 어렵다. 따라서 사용자 인터페이스에서는 이 식별자를 직접 사용하기보다는 사용자 제공 식별자를 사용하는 것이 일반적.

 

---

나는 개발자니까

개발자 입장에서는 시스템이 생성하는 고유한 번호를 사용하는 것이 일반적. 이는 데이터베이스에서 관계를 생성하거나 사용자를 참조할 때 특히 중요하다. 이런 식별자는 변경되지 않으므로, 사용자가 이메일 주소나 사용자 이름을 변경하더라도 관계를 유지할 수 있다.

 

"좋아요"나 "팔로우"와 같은 기능을 데이터베이스에 설계할 때는 일반적으로 시스템 생성 식별자 (자동 증가 ID나 UUID)를 사용하는 것이 더 좋다.

이유는 다음과 같다👉

1. 데이터 일관성: 시스템 생성 식별자는 변경되지 않는다. 사용자가 자신의 이메일 주소나 사용자 이름을 변경하더라도, 이전에 사용자가 "좋아요"를 누르거나 "팔로우"했던 모든 내용이 그대로 유지된다.
   
2. 성능: 대부분의 데이터베이스는 숫자형 식별자 (특히 자동 증가 ID)에 대해 인덱싱을 더 효율적으로 수행할 수 있다. 이는 "좋아요"나 "팔로우"와 같은 관계를 빠르게 조회하거나 업데이트하는 데 중요하다.
   
   
3. 보안과 개인정보 보호: 사용자의 이메일 주소나 사용자 이름은 민감한 정보일 수 있다. 이런 정보 대신 시스템 생성 식별자를 사용하면, 데이터를 외부에 공개하거나 다른 시스템과 공유해야 할 때 개인정보 보호에 도움이 된다.

따라서, 이러한 기능을 설계할 때는 시스템 생성 식별자를 사용하는 것이 일반적으로 더 좋다. 사용자 제공 식별자는 주로 사용자 인터페이스나 사용자가 직접 조작하는 부분에서 사용된다.

 

일반적으로 웹 어플리케이션에는 사용자가 로그인하면 해당 사용자의 시스템 생성식별자를 세션 또는 토큰에 저장하여 이후의 요청에 사용자를 식별하도록 하는 것이 좋다.

 

사용자가 "좋아요"를 누르거나 다른 사용자를 "팔로우" 하려는 요청을 보낼 때, 서버는 세션 또는 토큰에서 사용자 ID를 가져와 해당 작업을 수행 하는데, 이 ID는 사용자가 "좋아요"를 누른 게시물을 식별하거나 "팔로우"할 대상을 식별하는 데 사용된다.

 

이런 방식은 세션 또는 토큰을 사용하여 상태를 유지하는 HTTP와 같은 상태 없는 (stateless)프로토콜에서 사용자를 식별하고 권한을 관리하는데 매우 효과적이다.

 

하지만, 이러한 방식을 사용할 때는 보안에 주의해야 한다. 세션 또는 토큰은 적절하게 보호되어야 하기 때문에 민감한 정보를 포함하지 않는 것이 바람직하다.