2013-05-19 3 views
-1

나는 이정표, 직장, 고등학교, 대학의 다른 유형을 두 가지 모델 FUTUREMAPMILESTONESTI 또는 다형성 모델을 사용해야합니까?

FUTUREMAP

class Futuremap < ActiveRecord::Base 
    attr_accessible :name 
    has_many :milestones 
end 

이정표

class Milestone < ActiveRecord::Base 
    attr_accessible :description, :type 
    belongs_to :futuremap 
end 

을하는이 있고 지금 나는 속성이 다르다는 것을 알리는 것 type. 그러나 그것은 위대한 디자인이 아닙니다.

이것은 내가 유형이 직장이고 그 대학이 적을 때 정보를 저장해야한다는 것을 알기 때문입니다.

다른 유형의 하위 클래스를 만들거나 마일스톤을 다형성 모델로해야합니까? 어떻게하면 더 좋은 디자인을 만들 수 있습니까? 어떤 제안이나 아이디어라도 환영합니다.

+0

정확히이 디자인에 대해 마음에 들지 않는 부분은 무엇입니까? –

+0

@SergioTulentsev, 다른 유형에는 다른 속성이 있습니다. 직업은 5 가지 특성을 지니고 있으며 대학은 3 가지를 가질 수 있습니다. – SHUMAcupcake

+0

한 번 읽으면 누군가가 "Gang of Four"의 "책에서"워드 프로세서를 썼습니다. 이 프로그램은 실제 기계식 타자기보다 느 렸습니다. 그래서 overdesign하지 말아라. –

답변

2

STI (Single Table Inheritance)는 다양한 마일스톤간에 상당한 공용성이있는 경우에 유용합니다. 테라 바이트 크기의 하드 드라이브 시대에 나는 모든 분야를 항상 활용하지 않을까 걱정하지 않을 것입니다. 더 단순한 스키마를 사용하면 복잡성을 희생하면서 작은 공간을 절약 할 수 있습니다.

"다형성 모델"과 같은 것은 없지만 모델 간의 다형성 관계가 있습니다. 이것은 데이터베이스가 이해하기가 훨씬 더 어렵고, 복합 키가 필요하며 외래 키 제약 조건을 사용하여 유효성을 검사 할 수 없지만 특정 상황에서 유용 할 수 있습니다.

그러나 설명하는 상황은 그 중 하나가 아닙니다.

다형성 관계는 검색하는 오버 헤드가 높아질 수 있으므로 엔티티 관계의 "가장자리"에 맡기는 것이 가장 좋습니다. 이상적으로는 :through 관계 또는 JOIN과 관련된 관계가 없어 쿼리의 복잡성이 급속히 커지기 때문에 이상적입니다.

STI 테이블은 데이터베이스와 관련된 일반 레코드입니다. type 열은 인스턴스화 방법에 대한 ORM에 대한 힌트 일뿐입니다. 전체적으로 엔티티가 상당한 공용성을 가지고있는 한 매우 효율적입니다.

관련 문제