데이터베이스 디자인 개념

Question

방금 ​​프로젝트를 시작했고 올바른 방향으로 약간 밀어 넣어야합니다. 여기 내 테이블 구조는 다음과 같습니다.

users   departments  sub-departments 
-------  -------   ------- 
id   id    id 
name   name   name 
email 
password 
created 
modified 

posts   photos  profiles 
-------  -------  ------- 
id   thumbnail  id 
content  large   photo_id 
created  created  user_id 
user_id  profile_id department_id 
profile_id id   sub-department_id 

프로필 테이블은 약 5 개의 필드가 더 중요하지 않습니다. 이 중 조금이라도 보이는 것이 있다면 아마 그럴 것입니다.

users have one department 
users have one sub-department 
users have many posts 
users have one photo 
users have one profile 

는 내가 뭘 "원한"내가 필요한 내 모든 테이블을 생성하고 외부 키를 사용하여 프로파일 테이블에서 모두 함께 가지고 있었다. 내 프로필 모델의 CakePHP 조각 외모와 같은 :

var $belongsTo = array('User', 'Department', 'Sub_Department', 'Photo') 
var $hasMany = array('Comment'); 

지금 당신이 "무슨 일이 쓰레기인가?".. 나는 당신과 함께 바로 거기 있어요 생각합니다. 이 협회는 스캐 폴딩에서 작동합니다. 그러나 나는 정말로 내 논리를 꽂기 시작할 때 문제가 생기고 싶지 않다.

저는 아직 ERD 및 CakePHP에 익숙하지 않습니다. User와 ProfilesController 쿼리에 속하는 모든 것을 $ this-> Profile-> User-> find ('all', array ('contains'=> ....))와 같이 선언해야합니다. ?

나는이 시점에서 조금 길을 잃었다. 어떤 도움을 주시면 감사하겠습니다. 어떻게 구현할 것인가?

Answer 1

당신은 말했다 :

• 사용자는 하나 개의 부서가
• 사용자가 하나의 하위 부서가
• 사용자는
• 사용자가 하나의 사진
• 사용자가 하나 개의 프로파일

을 가지고 많은 게시물이

재미있는 용어 ... 사용자가 한 부서에서 사실, 하나의 하위 부서에서 근무합니다. 아마도 하위 부서는 단 하나의 부서에 속하기 때문에 부서 테이블과 하위 부서를 모두 프로필 테이블에 기록 할 필요가 없습니다. 사실, 둘 다 기록하면 시행해야 할 복잡한 제약이 있습니다. 그래서, 당신이 우리에게 말하지 않은 것이 없으면, 그 부서는 프로파일에 필요하지 않습니다. 그러나 실제로 부서와 하위 부서 간 상호 참조가 없으므로 단일 하위 부서가 여러 부서와 연관 될 수 있습니다. 하위 부서 번호 1이 한 사람과 연결되는 것을 막을 수있는 방법은 없습니다. 부서 1에서 일하고 부서 2에서 일하는 다른 사람. 그것은 이상하지 않습니다. 반드시 틀린 것은 아니지만 대부분의 조직에서 일하는 방식이 아닙니다.

"사용자가 한 번에 사진 한 장만 있고 프로필이 하나 뿐인 이유는 사용자 테이블과 구분되는 이유는 무엇입니까?"라고 묻는 유혹이 있습니다. 그러나 별개로 유지해야하는 이유가 있습니다.

모델링 테이블의 핵심 포인트 중 하나는 자연 기본 키를 식별하는 것입니다. ID 열은 계산되지 않거나 계산 될 수 있지만 다른 열의 조합은 고유해야합니다. 예를 들어 프로필 표에는 프로필 ID가 있지만 사용자 ID는 명시한 규칙에 따라 고유해야하므로 실제로 프로필 ID는 불필요합니다. 사실 공간 낭비입니다 (두 번, 데이터 열 및 인덱스에 대해 한 번) 생성됩니다. 이제 사용자가 시간 경과에 따라 여러 개의 프로필을 가지고 있고 프로필에 유효한 기간 또는 이와 유사한 것이 있다고 결정한 경우 프로필 ID 열은 의미가 있지만 마지막 글 머리 기호는 더 이상 유효하지 않습니다.

게시물 테이블에서 사용자 ID와 프로필 ID를 모두 기록하는 이유는 무엇입니까? 다시 말하지만, 이는 명백한 이점을 강요하지 않는 복잡한 제약 조건을 제공합니다. 프로필 ID로 충분합니다. 당신은 그 사용자를 찾을 수 있습니다.

사용자는 하나의 사진이 있지만 사용자가 모델링 한 사진이 아니라고 말합니다. '각 프로필에는 사진이 있고 사진은 하나의 프로필에서만 사용됩니다'라고 모델링했습니다. 마찬가지로, 실제로 '사용자는 하나의 하위 부서'를 모델링하지 않았습니다. '프로필에는 하나의 하위 부서가 있습니다.'라고 모델링했습니다. 대개 그 정의가 엉성한 정의와 관련된 문제이지만, 부적절한 정의가 엉뚱한 데이터베이스로 이어지고 데이터베이스가 엉성하기 때문에 잘못된 대답과 나쁜 성능이 발생할 수 있으므로주의해야합니다.

이러한 문제를 해결하면보다 효과적인 디자인을 구현하는 데 도움이됩니다. 그러나이 개요 스키마에있는 모든 예외를 발견했는지 확신 할 수 없습니다.

Answer 2

CakeApp.com에서 CakePHP 데이터베이스 디자인 개념을 테스트 할 수 있습니다.

Answer 3

내가 볼 수있는 샘플 스키마/다이어그램을 제공했습니다.

몇 가지 유의 사항. 포스트 모델 (포스트 테이블)에는 필드 슬러그가 있습니다. Sluggable 동작을 사용하여 여기에 슬러그 생성을 처리하십시오.

부서 모델 (부서 테이블)의 department_id 필드는 이어야합니다.은 parent_id 여야하지만 빌더 도구는 오류를 발생시킵니다. 필요에 따라 변경하십시오. lft, rght 및 parent_id 필드는 트리 비헤이비어에 해당합니다. 부서 모델에서 트리 동작을 사용하면 부서가 임의로 '상위'부서에 속하게됩니다. 이렇게하면 하위 부서가 실제로 다른 부서의 ID로 설정된 parent_id가있는 부서이므로 sub_departments 테이블이 필요하지 않습니다.

사용자에게 첨부 된 프로필 및 사진 habtm 프로필을 사용하면 사용자에게 사진을 무제한으로 첨부 할 수 있습니다. 필자는 Auth 구성 요소에 필요한 것만으로 사용자 모델을 유지하려고합니다. 프로필 모델은 first_name, last_name, age, city 등을 유지할 곳입니다.

업로드를 자동으로 처리하려면 사진 모델에서 업로드 동작 (MeioUpload)을 사용하십시오.

디자인을 수정하는 출발점이어야합니다.

http://cakeapp.com/sqldesigners/sql/centro

비밀번호 : 센트로