웹 사이트 용 데이터베이스를 개발하려고합니다. 이 웹 사이트에는 등록 된 사용자가 있으며이 사용자는 다른 사용자와 친구가 될 수 있습니다. 전통적인 소셜 네트워킹 사이트와 비슷합니다. 이제 내 문제는 각 사용자의 친구 목록과 프로필 정보를 저장해야한다는 것입니다. 각 사용자는 자신의 프로필 ID를가집니다. 이 외에도 각 사용자는 친구를위한 그룹을 만들 수 있으며 두 사용자 간의 우정의 상태를 나타내는 상태 필드도 있습니다. 이제 데이터베이스 테이블 수 대 테이블 크기
내가 두 솔루션의 생각이 작업을 수행합니다 :각 사용자는 프로필 ID와 그의 다른 프로필 정보가있는 테이블라는 이름의 프로파일을 유지하고 글로벌 친구 테이블이, 즉이 자신의 프로필 ID와 그의 친구 프로필 ID. 그리고 다른 필드는 그룹을 설명 할 것이고 사용자는 특정 친구와 우정에 대한 지위를 선택했습니다.
profile이라는 테이블을 유지 관리합니다. 각 사용자는 프로필 ID와 위와 같은 다른 프로필 정보를 가지며 friends_profileid와 같은 사용자 별 별도의 친구 테이블을 가지고 있으며 각 사용자는 자신의 친구 목록을 가지고 있습니다. 다른 모든 정보가 있습니다.
위의 두 기술 중 어느 것이 더 적절합니까? 필자는 MySQL Server 5.0을 사용하고 있으며 추상적 인 데이터 유형과 배열 유형을 사용하는 것을 고려했지만 프론트 엔드 구현이 더 복잡하고 어렵고 번거로워졌습니다. 첫 번째 기법은 단일 테이블의 행 수를 매우 빠르게 증가시키는 반면 두 번째 기법은 테이블 수를 사용자 수에 비례하여 증가시키는 것입니다. 무엇이 더 충고됩니까? 테이블 수가 많거나 행 수가 많습니까?
두 번째 기법은 단일 테이블에서 검색의 오버 헤드를 줄이는 반면, 스키마를 반복해서 저장하는 오버 헤드는 무엇입니까? 이런 유형의 상황에 가장 적합한 방법은 무엇입니까?
동의합니다. 사용자 1과 2가 있다고 가정 해 봅시다. 이제 user1이 B를 A로 분류하고 user2가 B를 분류합니다. 따라서 분명히해야합니다. user_friends 테이블에 1과 2 & 2 및 1 값을 모두 저장하십시오. 이제 1000 명의 사용자가 있고 각각 50 명의 친구가 있다고 가정하면 테이블 크기는 50,000으로 커지고 친구 목록을 쿼리 할 때마다 엄청난 오버 헤드가 발생하며 친구 목록을 가져와야합니다. 자주. 쿼리 실행 시간은 조그마한 데이터베이스에서도 기하 급수적으로 증가합니다. – sasidhar
나는 이것에 대해 한 번 더 생각해 보았는데, 이것이 전혀 이해가되는지 모르겠다.하지만 주어진 테이블의 친구 목록을 가져 오는 것과 같은 테이블을 쿼리하는 것이 바람직하다. – sasidhar
@ sasidhar : _ "전통적인 소셜 네트워킹 사이트"_라고 말하면 페이스 북을 생각합니다. Facebook에서는 우정이 서로 같습니다. A가 B와 친구라면 B도 A와 친구가되어야합니다. 반대로 B가 A와 친구가 아니면 A는 B와 친구가 될 수 없습니다. 이것은 각 우정을 한 번만 나열하면되므로 표의 크기가 제한됩니다. –