공연자와 장소 목록을 표시하는 앱이 있습니다. 앱 사용자는 원하는만큼 각 유형을 '즐겨 찾기'로 선택할 수 있습니다. MySQL 데이터베이스에서 이것을 구현하는 표준 방법이 있는지 궁금합니다. 내 옵션은 다음과 같습니다.
Favorite을 가지고 저장UserID, Type, TypeID
Type 'Performer'또는 'Venue'가됩니다.Favorite을 가지고 저장UserID, PerformerID, VenueID
PerformerID또는 중 하나만 VenueID각 항목에 대한 값을 가질 수 있습니다.Favorite_Performer과 Favorite_Venue, 각각 저장 UserID, PerformerID또는UserID, VenueID
각 방법의 장단점은 무엇이며 향후 유지 관리 측면에서 어떤 것을 권장합니까? 감사.
옵션 3이 가장 깨끗합니다. 즐겨 찾기를 추가하고 제거하는 것이 가장 쉽습니다. 그리고 이것이 ORM 프레임 워크가 구현할 스키마입니다.
옵션 1은 실행 가능하지만 무결성을 적용하기 위해 외래 키 제약 조건을 정의 할 수 없습니다. WHERE type='Venue'쿼리에 조건 자를 추가하면 별도의 'Favorite_Venue'테이블로 작업하는 것과 거의 비슷하게 해당 테이블로 작업 할 수 있습니다.
옵션 2는 즐겨 찾기가 이미있는 경우 추가하는 것을 복잡하게합니다. (이렇게하려면 삽입하는 대신 기존 행을 업데이트해야합니다. 누군가가 즐겨 찾는 장소 2 개와 좋아하는 공연자 5 명을 가졌다면 몇 개의 행이 될까요? 그러나 최소한 외래 키를 정의 할 수 있습니다.
좋아하는 공연장 2 개와 좋아하는 공연자 2 개가 있다고 가정 해 보겠습니다.
userID venueID performerID
------ ------- -----------
1 11 177
1 NULL 654
1 12 NULL
즐겨 찾는 장소 ID 11이 제거되면 행을 업데이트하여 장소 ID를 NULL로 설정합니다. 그러나 placeID 12가 즐겨 찾기에서 제거되면 열을 NULL로 설정하거나 행을 삭제합니다. 좋아하는 연기자를 추가하려고 할 때 performerID가 NULL 인 기존 행을 업데이트하거나 행을 삽입합니다. 작동하지 않는 것은 아니지만 더 복잡합니다.
VenueID 또는 performerID 열 중 하나만 채울 수 있다는 규칙이있는 경우 다음과 같은 조건자를 사용 WHERE venueID IS NOT NULL하면 별도의 Favorite_Venue 테이블로 작업하는 것과 거의 비슷하게이 테이블로 작업 할 수 있습니다.
요컨대, 그렇지 않은 설득력있는 이유가없는 한 옵션 3을 선택하겠습니다.
"혼잡함"이 아닙니다. 각 테이블 Favorite_Venue 및 Favorite_Performer에는 목적, "raison d' etre", 그 이유가 있습니다. 각 테이블은 다 대다 관계를 해결합니다.
이 두 개의 개별 "관계"테이블을 단일 테이블로 결합하면 실제로 혼란스러워집니다. 행을 구분하기 위해 열을 추가하면 (이 행이 실제로 속하는 테이블에 대한 질문에 효과적으로 답하기 위해) 해당 열은 "정리"입니다. 두 관계에 대해 동일한 행에 두 개의 개별 열을 사용하면 즐겨 찾기 추가 또는 제거를 처리하는 코드가 복잡해집니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다