활성 레코드의 문제점

Question

사용자 모델이 있다고 가정합니다. 사용자는 몇 가지 활동을 계획 할 수 있습니다. 액티비티 유형의 수는 약 50 개입니다. 모든 액티비티에는 start_time, end_time, user_id 등과 같은 공통 속성이 있습니다. 그러나 각각의 액티비티에는 고유 한 속성이 있습니다.

이제 각 활동은 DB의 자체 테이블에 있습니다. 그리고 우리가 같은 끔찍한 SQL 쿼리를 가지고있는 이유는 무엇입니까

SELECT * FROM `first_activities_table` WHERE (`first_activity`.`id` IN (17,18)) 
    SELECT * FROM `second_activities_table` WHERE (`second_activity`.`id` = 17) 
    ..... 
    SELECT * FROM `n_activities_table` WHERE (`n_activity`.`id` = 44) 

약 50 개의 쿼리. 그것은 끔찍한 일입니다.

이 문제를 해결하는 방법은 여러 가지가 있습니다.

1. 가장 많은 수의 등록 정보로 활동 유형을 선택하고 '활동'테이블을 작성하고 STI 모델을 작성하십시오. 그러나이 방법으로 우리 컬럼을 불편한 방식으로 명명해야하며 그 테이블의 레코드에는 NULL 필드가있을 수 있습니다.
2. 또한 STI 모델이지만 모든 활동 유형에 공통 인 열과 일련 화 된 특성을 갖는 일부 BLOB 열이 있습니다. 그러나 우리는 활동에 대한 몇 가지 조사를해야합니다. 문제가있을 수 있습니다. 그리고 직렬화는 아주 느립니다.

이 문제를 해결하도록 도와주십시오. 어쩌면 내 문제는 내 요구에 맞는 아주 다른 해결책이 될 수 있습니다.

도움 주셔서 감사합니다.

Answer 1

아마도 여기서는 관계형 데이터베이스가 이상적인 솔루션이 아닙니다.

Mongo DB과 같이 document oriented database을 확인하십시오.

위키

: 균일 각 레코드에 대한 필드를 크기와 관계형 데이터베이스와 달리

, 문서 기반 데이터베이스는 테이블에 데이터를 저장하지 않습니다. 대신, 각 레코드는 에 특정 특성이있는 문서로 저장됩니다. 임의의 길이의 임의의 필드의 수는 이 문서에 추가 될 수 있습니다. 여러 개의 데이터가 들어있는 필드도 있습니다 ( ).

가 왜 몽고 싫어 모든 편집? 누군가 설명 해주십시오.

원래의 질문에서 고정 된 것으로 지정되지 않은 관계형 데이터베이스를 사용하여 chap이 이미 시작되었다는 것을 제외하고는 이것이 잘못된 생각 일 수밖에없는 이유를 알 수 없습니다.

활동에는 50 가지 다른 표현이 있습니다. 그들은 몇 가지 데이터를 공유하지만 각 유형의 필드는 크게 다릅니다. 많은 다른 활동들로 인해 활동에 대한 고정 된 표현이 없다는 것이 나에게 시사한다. 수정되지 않은 데이터 세트를 처리하기 위해 고정 열 데이터베이스를 유지 관리하는 것은 고통 스러울 것입니다.

포스터에서 언급 한 두 번째 가능성은 blob 데이터로 액티비티를 직렬화하는 것이 본질적으로 매우 비효율적이며 쿼리 할 수없는 문서 기반 데이터베이스 버전입니다.

downvoters을 dissing하지 않고, 나는 단지 나 자신을 교육시키고 싶어한다!

Answer 2

활동을 여러 테이블로 나눠서 몇 가지 모델로 구성하십시오.

테이블 activity_types : 예를 들어

이름 이 테이블이 이 activity_id activity_details

[일반 필드] USER_ID activity_type_id

테이블 활동 키 사용 가치

활동 de 행당 하나씩 비 공통 요소를 저장하는 꼬리.

각 활동에 대해 단일 모델/표의 단순성을 잃어 버릴 수 있지만 '세부 정보'데이터를 더 쉽게 가져올 수있는 몇 가지 방법을 추가 할 수있는 통합 활동 모델을 얻습니다. #method_missing이 과부하 될 수 있습니다. ? 또는 뭔가.

당신은 여전히 ​​쿼리 개 이상의 세트를 가지고 있습니다,하지만 당신은 같은 뭔가 결말, 오십이 없습니다 :

활동을 선택

* 여기서 USER_ID = 1; activity_types SELECT * FROM 곳의 아이디 (...) activity_details에서 선택 * 어디에서 activity_id (...)

당신은 당신이 각 활동에 대한 여러 세부 행을해야해서 더 많은 행을 반환하는거야

,하지만 전반적으로 빠를 것이라고 생각합니다.