단일 테이블 상속 및 Rails에서 사용 위치
이상한 디자인 문제에 갇혔습니다.
두 가지 유형의 프로필 모델 작업을 하고 있습니다.
- 사용자 프로필(사용자에게 속함)
- 현장에서 "봇"으로 유지 관리하는 기타(아무도 소유하지 않음)
이 두 가지 유형의 프로필의 일반적인 OO 동작은 동일하지만 중요한 속성/속성만 공통적이며(매우 중요한 것은 5-6개) "관심 사항 등"(거의 10-15개 속성)과 같은 다른 속성은 없습니다. 봇 프로필용
이전에 이 작업을 수행한 코더는 봇 프로필/사용자 프로필을 위한 별도의 모델/컨트롤러를 만들었습니다. 이 컨트롤러는 어디에서나 많은 중복성을 생성하고 예상대로 유지 관리, 테스트 등을 작성하기가 어렵습니다. 적어도 일부/모두를 해결하기 위해 이것을 건조하고 싶었습니다. 이러한 중복 문제의.
누군가가 단일 테이블 상속을 솔루션으로 제안했습니다.
누군가 대신 Use Polymorphic Associations를 제안했습니다.
더 나은 접근 방식은 무엇입니까? 우리는 실제로 STI를 언제 사용합니까?
내 생각에 STI는 속성이 모델에 대해 동일하고 동작이 다를 때 가장 잘 사용됩니다.
내가 무엇을 할 수 있을까?
속성은 동일하지만 동작이 다를 때 STI를 가장 유용한 것으로 특성화하는 것은 "거의 옳지만" 약간 제한적일 수 있습니다. 이름에서 알 수 있듯이 서로 다른 유형의 개체 간의 데이터베이스 스타일 관계보다는 명확한 OO 스타일 상속 관계가 있을 때 STI를 사용하는 것을 좋아합니다.
봇과 사용자 사이에 공통 코드가 있다면 STI가 승자처럼 들릴 것입니다. 몇 가지 공통 속성만 있다면 적용 가능성은 낮지만 시도해 볼 가치가 있습니다.
나는 꽤 실험적인 사람이기 때문에 추천합니다. 코드를 분기하고 모델을 STI 관계로 리팩토링하십시오. 실제로 문제를 해결하는지 또는 두통을 다른 문제로 바꾸는지 확인하십시오.
많은 이점을 얻지 못할 것이라고 생각하는 한 가지는 컨트롤러를 건조시키는 것입니다. 내 경험상 STI 모델은 종종 유사한 관련 컨트롤러로 변환되지 않습니다. 그러나 그것은 실험할 다른 것이 될 것입니다. 승리가 있을 때도 있고 없을 때도 있습니다.
STI 작업에 대한 몇 가지 팁을 포함하여 바로 이 주제에 대한 기사를 작성했습니다.
간단히 말해서: 일부 공유 데이터가 아니라 객체 간에 명확한 OO 스타일 상속 관계가 있어야 합니다(womble에서 웅변적으로 언급한 대로). 자연스럽고 명백한 클래스 계층 구조가 없으면 애플리케이션이 발전함에 따라 STI 디자인을 유지 관리하기 어려워질 수 있습니다.
둘째, 모든 데이터를 하나의 테이블에 보관하는 것이 중요한지 고려해야 합니다. 다형성 연결을 사용하면 데이터베이스 쿼리가 더 복잡해지고 느려질 수 있습니다. 사이트(예: 테이블)에 모든 개체를 함께 나열할 계획이라면 STI가 올바른 방법일 수 있습니다.
셋째, 자식 클래스에 고유한 속성이 너무 많지 않은지 확인하십시오. 모든 데이터가 하나의 테이블에 있으므로 비전역 열이 많이 필요하지 않습니다. 이것들은 공간을 차지할 뿐만 아니라(주요 문제는 아님) 데이터 구조를 혼란스럽게 만듭니다. "특별한" 열이 있는 경우 코드에서 명시적으로 설명해야 합니다.
마지막으로 STI를 사용하는 경우 모든 하위 모델에 대해 단일 컨트롤러를 사용하는 것이 좋습니다. 컨트롤러의 주요 기능은 개체에 대한 액세스를 제공하는 것이며 개체에 매우 다른 방식으로 액세스해야 하는 경우 STI는 처음부터 올바른 설계 선택이 아닐 수 있습니다.
더 유용한 팁을 보려면 내 기사(위 링크)를 확인하세요.
나는 아마도 STI를 사용하거나 특별한 기능을 전혀 사용하지 않을 것입니다. 모든 것을 프로필이라고 부를 수 있으며 사용자가 nil인 경우 "봇"인지 알 수 있습니다. STI를 사용하지 않고 "유형" 필드를 저장할 수도 있습니다.
특정 사항이 STI 사용 결정에 영향을 미칠 수 있습니다.
- 봇 전용 로직이 있는지 여부
- 얼마나 많은 봇이 있는지 대 사용자 프로필(봇 수가 적다는 것은 STI가 정상임을 의미합니다. 봇이 많고 다른 곳에 저장할 수 있음)
STI를 피하는 이유는 때때로 그것이 방해가 될 수 있기 때문입니다. 예를 들어 개체를 한 유형에서 다른 유형으로 변경하는 것은 상당히 성가실 수 있습니다(이 경우 봇에서 프로필로). 때로는 단순한 "유형" 필드가 더 좋습니다.
STI를 사용하는 경우 공통 기본 클래스가 필요할 것입니다. 당신이 할 수 있도록 Profile, BotProfile그리고 UserProfile. 이름은 당신에게 달려 있습니다. :)
Rails STI의 한 가지 문제 - 대부분의 플러그인(및 기타 등등)은 이를 완전히 지원하지 않습니다. 많은 일반적인 패치를 패치하는 자신을 발견하게 될 것입니다.
ReferenceURL : https://stackoverflow.com/questions/555668/single-table-inheritance-and-where-to-use-it-in-rails
'IT이야기' 카테고리의 다른 글
| DIV 대 테이블 또는 CSS (0) | 2021.10.27 |
|---|---|
| "Combinators"에 대한 좋은 설명 (0) | 2021.10.27 |
| 자바 인트로스펙션과 리플렉션 (0) | 2021.10.26 |
| Bitbucket에서 Github으로 HG 프로젝트 미러링 (0) | 2021.10.26 |
| Ruby에서 "=~" 연산자 (0) | 2021.10.26 |