20 개의 테이블을 결합하여 데이터 쓰기/읽기를위한 다른 옵션을 제외하고는?

사용자 프로필을 만들고 있습니다. 모든 필드는 좋아하는 영화, 좋아하는 음악, 좋아하는 음식, 스포츠 등 자신의 테이블을 기반으로 조회됩니다 ... 이들은 텍스트 필드가 아니지만 자동 시스템 유지 목록에서 필드를 제안합니다. 이것들이 모두 자신의 식탁에있는 이유는 그들 만의 고유 한 색을 가지고 있기 때문입니다.20 개의 테이블을 결합하여 데이터 쓰기/읽기를위한 다른 옵션을 제외하고는?

사용자 입력시 데이터를 읽으려면 괜찮습니다.하지만 그 후에는 두 가지 문제가 있습니다.
1) 데이터 쓰기 : M : M 관계이므로 20 개의 테이블이 필요합니까?
2) 프로필로드 시간에 데이터 읽기 : 사용자 데이터를 얻기 위해이 20 개의 테이블을 모두 조인해야합니까?

다른 모든 옵션은 이러한 모든 사용자 정보를 저장해야합니까? 이 사이트는 소셜 사이트이므로 나의 유일한 관심사는 실적입니다. 20 개의 조인은 좋지 않습니다. 그러나 나는 다른 기술에 대해 확신하지 못합니다. 나는 mysql과 PHP를 사용하고있다.

내가 생각할 수있는 유일한 다른 옵션은 데이터베이스에서 배열에 데이터를 저장하는 것입니다. 검색이 얼마나 잘 수행되는지는 잘 모릅니다.

출처

2011-02-09 SuriP

20 조인은

말한다 좋지 않다? 실제로 문제가되는 것을 보지 않는 한 쿼리의 조인 횟수를 걱정하지 않아도됩니다. 관계형 데이터베이스는 으로 설계되어으로 처리되며, 테이블을 서로 연관시킵니다.

자, 실제로 이 필요합니까? 또 다른 질문은 모두입니다. 샘플 질의와 데이터베이스 디자인의 관련 부분을 게시해야하며, 문제가있을 경우 알려 드릴 수 있습니다.

출처

2011-02-09 04:22:33

(그게 가능 모르겠어요하지만) : M, 자신의 테이블에있는 각 지금 ID와 이름이 있습니다. 좋아, (fav_brands, fav_places, fav_food, fav_drinks, fav_movies, fav_music, fav_sportteams, fav_sports, fav_activities, ...) 다음 user_brands, user_place, user_food 등 .. 4 개의 열이있는 사용자 정보를 보유 테이블 : user_id, created_dt, updated_dt. 생각으로 나는 '이름'도 추가 할 생각이기 때문에 텍스트 설명도 아이템의 테이블에있다. 그래서 나는 그것을 쿼리 할 필요가 없다. – SuriP

@ SuuriP : 완벽하게 의미있는 스키마입니다. 문제가 있습니까? 관계형 데이터베이스는 사실상 즉시 데이터를 제공하는 데 문제가 없어야합니다. –

아니지만 그물에 본 샘플 스키마는 빠른로드를 위해 1 개의 테이블에 모든 사용자 정보를 덤프하려고합니다. 나는 그것이 현실 세계에서 작동하는 방식이 아니라면 프로파일 세부 사항을 위해 20 개의 테이블을 사용하고 싶지 않습니다. – SuriP

MongoDB과 같은 비 관계형 데이터 저장소에 사용자 프로필을 저장할 수 있습니다.

이것은 조인 혼란을 피할뿐만 아니라 사용자 프로필 스키마를 즉시 변경하고 많은 데이터 액세스 코드를 작성하는 것을 방지합니다.

출처

2011-02-09 04:31:26 saille

그럼 누군가 먼저이 데이터베이스를 배워야합니다. My dev 팀은 MySQL에서 모험을 해 본 적이 없으므로, 이것을 사용하면 한 달 동안 배우려고 노력할 것입니다. – SuriP

나는 MongoDB 나 CouchDB와 같은 NoSQL 데이터베이스를 추천하는 시류에서 많은 사람들을 만난다. 나는 그것들을 망쳐 놓지는 않았지만, 스키마가없는 데이터 저장소에 대한 일반적인 아이디어를 얻었습니다 (실제로 잘 정의 된 저장 형식을 사용하는 것이 좋은 일이 아닐지라도). 이 시나리오에서 MongoDB 등을 사용하면 쿼리의 복잡성을 어떻게 줄일 수 있습니까? –

@Adam 한 사용자에 대한 모든 사용자 프로필 데이터는 단일 '문서'에 보관됩니다 (MongoDB 용어 사용). 조인이 필요하지 않습니다. 모든 데이터가 들어있는 객체 그래프를 저장하고 검색하면됩니다 (예 : 사용자 환경 설정, 좋아하는 음식, 영화 등 – saille

성능 요구 사항에 따라 20 개의 조인이 문제 일 수도 있고 아닐 수도 있습니다. 하지만 초당 1 초 미만의 응답을 원하는 경우 실제로는이를 피할 수 있습니다. 그러나 사용자가 로그인 할 때만 발생하며 초당 로그인 수가 2 회 이상이고 다른 무거운 데이터베이스로드가없는 등의 경우에는 성능이 상당히 저하 될 수 있습니다.

그 중 일부를 결합 할 수 없다면 놀랄 것입니다. 많은 프로필 속성이 PersonId, TraitType, string1, string2, int1, int2, date1, date2와 같은 공통 구조로 표현 될 수 있다고 생각합니다.

코드에서 데이터의 객체 지향 (OO) 표현과 같은 작업을 수행하는 경우 해당 유형을 완전히 나타내는 클래스로 traittypes를 매핑 할 수 있으므로 프로그램은 추상화 수준에서 작동하지 않아도됩니다. 테이블 디자인을 나타냅니다.

Elroy

출처

2011-02-09 04:48:14

그들은 사용자의 Favourie 브랜드, 영화, 스포츠 팀, 활동, 음악, 음악가 등을 어떻게 결합 할 수 있는지와 같이 모두 다른 항목입니다. 각 데이터는 자체 속성 세트가있는 자체 조회 테이블을 가지고 있습니다. 그렇지 않으면 나는이 모든 데이터를 보유하고 큰 테이블을 각 개별 테이블에 연결할 별도의 링크 테이블을 가지고 1 큰 조회 테이블이 필요합니다. 어떤 항목의 고유 한 데이터가 필요한 경우. – SuriP

테이블이 적절한 외부 키를 가지고 있다고 가정하면, 제안하는 것 (실제로는 EAV를 나타내는 범용 "속성"테이블)은 실제로 더 느릴 수 있습니다 *. 작은 * 큰 * 테이블보다 적은 * 큰 * 테이블이 더 낫습니다. 기본 키에 20 조인을 추가하면 비용이 들지 않습니다. –

조인은 중요하지 않지만 테이블 크기입니다. 백만 명의 사용자가있는 경우 각 사용자는 10 개의 좋아하는 영화를 가지고 있으므로 테이블은 1 천만 행입니다. 이제 각 테이블 (영화, 스포츠, 음식 등)은 같은 크기를주고받습니다. 따라서 시스템은 user_id를 검색하고, 페이지로드시 각 테이블에서 그의 즐겨 찾기를 즉시 찾아 자신의 프로파일 데이터와 함께 표시해야합니다. – SuriP

그것은 프로필 부하에서 모든 데이터를로드 할 필요가 있습니까? 참조 테이블 이름은 프로필 자체에 대한 일종의 자산을 나타내며 사용자가 활성화하면 해당 테이블의 항목에 대한 쿼리를 실행합니다.

저는 전문 웹 프로그래머가 아니므로이 모든 것을 잘못 할 수 있습니다. 그러나 프로필이로드되어 사용자에게 요약/탐색 인터페이스에 대한 정보를 제공하는 것처럼 보입니다. 맞습니까? 일부 버튼/글리프로 사용자가 탐색하거나 더 많은 정보를 요청할 수있는 항목이 있습니다.

프로필로드시 최상위 프로필 정보가 머리글 위젯 "즐겨 찾기"아래에있는 일부 버튼과 함께 나타납니다. "장소", "음식/음료", "음악"등의 버튼이있을 수 있습니다. 사용자가 THESE 중 하나를 활성화하면 해당 특정 테이블 (및 관련 조인)에 대해 쿼리가 실행되어 "장소" 예를 들면.

어쩌면 웹과 다를 수 있습니다 (그리고 나는 곧 배우게 될 것입니다).하지만 이해할 수있을 때 데이터를 요청하려고합니다. 그리고 사용자가 간단한 액세스 시간을 기대할 때 퐁 (pont)을 시도합니다. 일반적으로 버튼 클릭은 사용자가 약간의 지연이 예상되는 지점입니다.

출처

2011-02-09 05:02:11 XIVSolutions

좋아하는 영화, 스포츠 팀 등이있는 페이스 북 프로필과 비슷합니다. 페이스 북은 10-15 개의 필드가 있습니다. 나는 총 30-35 개의 필드를 가지고있다. Ofcourse는 페이지로드시 모두로드되지 않습니다. UI는 각 행에 대해 한 행을로드하고 사용자가 '자세히'를 클릭하면 더 많은 것을 볼 수 있습니다. – SuriP

OK, 알겠습니다.이 경우 각 행에 대해 해당 행을 검색하기 위해 이미 조인을 작성 중이므로 대부분의 지연을 프로파일로드와 연관시킬 수 있습니다. 초기로드 순서 (페이지가 웹에서 열릴 때 대부분의 사용자가 합당한 지연을 예상하는 경우) 동안 더 많은 데이터를 효과적으로 캐시 할 수 있는지 테스트 한 다음 표시 할 첫 번째 행을로드하십시오. 이 시나리오에서 사용자가 클릭하면 "더"볼 훨씬 빠른 액세스에 의해 전면에 큰 지연이 상쇄됩니다. 필요에 따라 요청하고, 어떤 방법을 볼지 비교하십시오. . . – XIVSolutions

. . 보다 만족스러운 사용자 경험을 제공합니다. FB 또는 Myspace가로드 될 때 페이지가로드되는 동안 때로는 상당한 대기가 있음에 유의하십시오. 그리고 나서 "사진보기"를 클릭하거나 당신이 가지고있는 것을 클릭 할 때 더 많은 돈을 벌 수 있습니다. 사물의 웹 측면에 관련된 일부 역학에 익숙하지 않은 나는 도움이되지 않는다고 생각합니다. 그러나 나는 이런 종류의 문제를 즐긴다! 마지막으로 언급 한 내용은 위에서 설명한대로 v1에 대해 개발자 팀이 최선을 다한 다음 Hadoop 또는 MongoDb를 사용하여 v2를 다시 작업 할 준비를 마친 것입니다. 행운을 빕니다! – XIVSolutions

조인 수를 줄이는 한 가지 방법은 모든 20 가지 유형에 공통되는 데이터를 단일 테이블에 저장하는 것입니다. 이 테이블과 20 개의 특수 테이블과의 관계는 gen-spec 디자인 패턴을 따릅니다. 테이블에서 gen-spec 패턴을 구현하는 방법을 보려면 "일반화 전문화 관계형 모델링"을 참조하십시오.

이렇게하면 특수 테이블 만 필요할 때 참조하게됩니다.

귀하의 사례에서 귀하의 사용 패턴을 잘 모르겠습니다. 따라서이 조언이 귀하의 상황에 적용되는지 말할 수 없습니다. 그러나 조사 할 가치가 있습니다.

출처

2011-02-09 09:48:57

좋아하는 dbms를 설치하십시오.
사용자 테이블을 만들고 두 개의 사용자 즐겨 찾기 테이블 두 개 또는 을 만듭니다.
을 생성하고 백만명의 무작위 사용자를로드하는 작은 프로그램을 작성하십시오.
을 생성하고 명의 사용자에게 1 천만 개의 좋아하는 영화 인 (또는 그 이상)을로드하는 작은 프로그램을 작성하십시오.
몇 가지 쿼리를 실행하십시오.

속도가 문제가되면 "database-design"및 "query-optimization"태그가있는 스키마를 게시하고이 질문에 대한 링크를 포함하십시오.

나중에. . . 지루함. 그래서 나는 직접 시험을했다. 20 회의 조인을 수행 할 시간이 없지만 조인 된 테이블 각각에 백만 명의 사용자와 50 만 개의 행이 약 400 밀리 초에 반환됩니다. (PostgreSQL 9.0.2) 지금 바로 작업하십시오. . .

그리고 나중에. . . 여전히 지루합니다. 더 많은 테이블, 더 많은 데이터, 더 많은 외부 조인을 추가했습니다. 특정 전자 메일 주소의 데이터에 따라 더 많은 조인이 더 빠를 수 있습니다. (당신은 그것을 짐작 했겠습니까?난 아직도 나중에 지루 해요 경우) 마지막 시험은 내가 실행

에 함께 프로그램을 쾅거야,
```
  run time (milliseconds) 
-- 
median  40 
maximum 222 
minimum  0.4 ("Four tenths of a millisecond", not a typo.) 
```
, "사용자"에서 수십 임의의 이메일 주소를 선택 달린 임의의 이메일 주소에 기반으로 몇 백 쿼리 및
기록 실행 시간 디자인은 M 단지 필드입니다

출처

2011-02-09 10:31:48

20 개의 테이블을 결합하여 데이터 쓰기/읽기를위한 다른 옵션을 제외하고는?

답변

관련 문제