mongodb 데이터 디자인 질문

Question

나는 mongo_mapper를 사용하여 레일즈에서 mongodb로 첫 번째 어플리케이션을 시도하고 있으며 아래의 STI 모델에서 내 옵션을 비교 중이다.

잘 작동합니다. 물론 내가 현재 계산할 수있는 것보다 더 많은 방법으로이 작업을 추가 할 예정입니다. 임베디드 문서 또는 일부 작업을 더 잘 수행하지 못한다면 궁금 할 것입니다.

내 모델은 가능한 한 많이 공유하고 싶습니다. IE는 특정 속성, 공유 된 부분/property/_form.html.erb ... 등의 고유 한 양식 요소 등을 상속합니다. 보기가 다르다는 것을 알고 있지만 컨트롤러에 대해서는 아직 잘 모르겠습니다. 속성 컨트롤러를 사용할 수 있으므로 대부분의 작업을 맡을 수 있습니까? 그리고 내가 갈수록 더 복잡해질 것이라고 확신합니다.

모든 포인터 자원 및/또는 지혜 (통증이 팁을 저장)을 크게 감상 할 수

property.rb

class Property 
     include MongoMapper::Document 

     key :name, String, :required => true 
     key :_type, String, :required => true 
     key :location_id, Integer, :required => true 
     key :description, String 
     key :phone, String 
     key :address, String 
     key :url, String 
     key :lat, Numeric 
     key :lng, Numeric 
     key :user_id, Integer, :required => true 
     timestamps! 

    end 

레스토랑

class Restaurant < Property 
    key :cuisine_types, Array, :required => true 

end 

바

class Bar < Property 
    key :beers_on_tap, Array 

end 

Answer 1

하지 마라. 더 많은 모델을 두려워하게되면, OO의 아이디어는 당신의 관심사를 작은 조각으로 잘라 내고 대우받을 필요가있는 방식으로 각각을 다룰 수있게하는 것입니다.

예를 들어, 부동산 모델이 전체적으로 많은 것처럼 보입니다. EmbeddedDocument (위도, 경도, 주소 등)에 들어가는 지형을 왜 분리하지 않습니까? 그렇게하면 코드가 더 간단하고 읽기 쉽도록 유지됩니다.

나는이 종류의 STI를 직접 사용하고 있으며 코드가 훨씬 간단하고 유용하다는 것을 알았다. Mongo와 같은 DB 사용의 아름다움 중 하나는 이와 같이 매우 복잡한 STI를 수행 할 수 있고 관리 가능한 데이터 콜렉션을 보유 할 수 있다는 것입니다.

당신의 cuisine_types와 beers_on_tap 등에 대해서는 훌륭한 개념이라고 생각합니다. Cuisine과 Beer 모델을 사용하는 것이 유용 할 수 있으므로 데이터베이스가 더 표준화 된 상태로 유지됩니다 (Mongo에서 쉽게 잃어 버릴 수있는 개념). 예 :

Answer 2

레스토랑과 바 모두를 동일한 검색어로 반환 하시겠습니까?

그렇지 않은 경우 기본 유형에서 파생 된 것을 재검토하고 싶을 수 있습니다.

기본적으로 Mongo_Mapper는 Restaurants와 Bars를 하나의 컬렉션에 넣습니다. 이로 인해 성능이 저하되고 향후 확장이 어려워 질 수 있습니다.

일부 Mongo_Mapper 코드를 살펴보면 set_collection_name을 사용하여 즉시 설정할 수있는 것처럼 보입니다.