2011-04-26 8 views
2

나는 수천 명의 사용자를 보유하게 될 데이터베이스 디자인을하고있다. 각 사용자는 귀하의 프로파일과 특정 데이터를 연관시킵니다.데이터베이스 모델링 -mysql

id, username, activationLink 및 hash에 대한 테이블과 주소, 나이, 사진, 작업에 대한 테이블을 사용하는 것이 가장 좋으며, 모든 항목에 대해 고유 한 테이블을 만드는 것이 가장 좋습니다. 시간에 대한

감사

답변

2

경우 :

  1. 모든 (또는 거의 모든) 사용자는 모든 데이터를 채운
  2. 모든 필드 다음

쿼리 대부분의 시간 그들은 하나의 테이블에 보관하고, 다른 테이블은 그들을 분할합니다.

모델에서 activationLink은 활성화 당 한 번만 쿼리되는 것으로 보이므로 별도의 테이블로 옮깁니다 (계정을 활성화 한 후에 삭제할 수 있음).

주소, 나이, 사진 및 작업이 일반적으로 사용자 이름과 함께 표시되므로 단일 테이블로 병합하는 것이 좋습니다.

+0

내 모델에서는 계좌가 활성화되었거나 활성화되지 않은 경우 항상 로그인을 확인합니다. –

+0

@Wire : 물론, 활성화 링크를 사용한 후에는 영구적으로 저장해야합니까? 나는 1 바이트의 isActive BOOL을 만들고 활성화가 수행 된 후에 링크를 버린다. – Quassnoi

+0

나는 활성화되었거나 활성화되지 않는 부울을가집니다. 하루나 이틀 후에 링크를 삭제할 수 있습니다. 예 : –

1

향후 초기 요구 사항을 확장 할 수있는 능력을 제한하거나 초기의 설계를 어렵게 만듭니다.

  • 순간, 사용자는 하나의 address 그래서 당신이 users 테이블에 넣을 수있을 수 있습니다 - 당신이 원하는 경우에 그들을 "작업"미래의 "홈"주소 또는 기록을 저장 할 수있을 것 과거 주소들?
  • 사용자는 사진 한 장만 허용 할 수 있지만, 사진 (또는 URL)을 users.photo에 넣으면 사용자가 프로필 기록을 보유 할 수 있도록 데이터 구조를 변경해야합니다 사진

Quassnoi는 이러한 각각의 결정에 성능에 영향을 미칩니다. 테이블이 많을수록 복잡성이 증가하고 느린 쿼리의 가능성이 높아집니다. 이를 위해 새 테이블을 만들지 말고 데이터 모델을 신중하게 고려하여 변경하기가 매우 어렵습니다.

user 엔티티와 1 대 1로 엄격한 관계가 있고 변경 될 가능성이 적고 (생년월일이 좋은 예입니다) 히스토리가 필요한 값은 핵심 정의가있는 테이블에 있어야합니다 . 잠재적 인 일대 다 관계 (심지어 이 아닐지라도)는 자신의 테이블에 대한 좋은 후보입니다.

+0

감사합니다. 좋은 설명 - –

관련 문제