2010-12-29 3 views
8

나는 admin, employee, manufacturer, transporter의 네 가지 사용자 유형으로 인벤토리 관리 애플리케이션을 구축하고 있습니다. 아직 코딩을 시작하지 않은, 그러나 이것은 내가 생각하고 ... 제조 업체 및 운송이 has_many와 관련된 무엇인가를 대다 제품과 관련하여 다음과 같이Ruby on Rails의 다중 사용자 역할

class Manufacturer < ActiveRecord::Base 
has_many :products 
has_many :transporters, :through => :products 
end 

class Product < ActiveRecord::Base 
belongs_to :manufacturer 
belongs_to :transporter 
end 

class Transporter < ActiveRecord::Base 
has_many :products 
has_many :manufacturers, :through => :products 
end 

모든 4 개 개의 사용자 유형 것이다 로그인 할 수는 있지만 다른 사용 권한과보기 등이 있습니다. 다른 요구 사항을 갖기 때문에 같은 테이블 (사용자)에 넣을 수는 없습니다. 공급 업체 및 제조업체는 청구서 수신 주소 및 연락처 정보 (유효성 검사를 통해)는 있지만 관리자와 직원은이 필드가 없어야합니다.

가능하다면 4 개의 다른 화면과 달리 하나의 로그인 화면을 만들고 싶습니다.

이 코드를 작성하는 정확한 코드는 요구하지 않지만 문제가 발생하지 않도록 최선의 방법을 결정하는 데 문제가 있습니다. 어떤 아이디어라도 크게 감사 할 것입니다 - 감사합니다!

답변

5

기본적인 접근 방식은 타당를 참조 할 수 있습니다. 사용자의 기본 클래스를 만들고 특정 사용자 유형에 대해 STI를 사용하는 것이 좋습니다 (예 :

...) 이렇게하면 유형에 관계없이 여러 사용자 유형을 하나의 관계로 집계해야하는 경우 사용자를 일반적으로 설명하는 하나의 표가 있습니다. 이것은 상당히 일반적인 접근 방식입니다.

다른 사용자가 시스템에 얼마나 많은 액세스 권한을 부여 할 것인지에 따라 Declarative Authorization과 같은 역할 관리 젬을보고 싶을 수도 있습니다.

+0

도움을 주셔서 감사합니다! 데이터베이스 테이블은 기본 사용자 클래스와 특정 사용자 유형에 대한 STI를 사용하여 어떻게 설정합니까? 난 정말 레일에 처음이에요 :) – aguynamedloren

+0

당신은 오직 '사용자'테이블을 데이터베이스에 가지고있을 것입니다. STI/단일 테이블 상속에서는 기본 테이블 (이 경우 '사용자')의 '유형'필드를 사용하여 기본 클래스의 하위 유형을 구별합니다. 마이그레이션에서이 필드를 추가해야합니다. 그런 다음 기본 클래스의 모든 부속 유형에 대한 모든 속성은 많은 특정 인스턴스/행에 의해 사용되지 않더라도 users 테이블에 보관됩니다. 이것은 STI 패턴을 사용하는 절충안입니다. 사용되지 않은 속성에 대한 Null 필드의 수는 하위 유형별 속성의 수에 따라 달라질 수 있습니다. –

1

사용자 모델, 주소 모델, ContactInfo 모델 등을 만드는 것이 좋습니다. 이러한 종류의 필드는 사용자 모델에 있어서는 안됩니다. 데이터베이스를 표준화하십시오. 다른 클래스의 각각에서 FK를 User.id로 가져옵니다. 별도의 그들을 유지해야하는 경우

, 다음 로그인을 정상화하고 다형성의 소유자 (제조 업체, 직원 등)

+0

Weeeelll ... 아마도. 주소 테이블을 갖는 것은 확실하게 표준화되었지만 현실 세계에서는 여러 번 지나치게 과장되어 있습니다. 실제로 하드 코어 정규화 괴물도 주소와 같은 것을 인정할 것입니다. 대부분의 경우 주소는 더 이상 없습니다. varchar 필드보다 - 발생하는 모든 오버 헤드가있는 자체 테이블로 정규화 할 필요가 없습니다. 영원한 사용자 쿼리에 대해 SQL 결합 히트를 정말로 원하십니까? 이러한 간단한 조작에는별로 좋지 않습니다. 너무 많은 것은 도메인과 주소가 실제로 복잡하고 재사용 가능한지 여부 등에 달려 있습니다. –

+0

@Dave Sims - 전적으로, 정중히 동의하지 않습니다. 오늘날 세계에서 가능한 한 많은 정보가 필요합니다. 정규화 (특히 주소 포함)는 향후 확장이 가능하므로 사용자가 여러 주소 (예 : 집과 직장)를 가질 수 있습니다. SELECT *가 10 개의 열을 반환하는지 또는 JOIN이 10 개의 열을 반환하는지는 중요하지 않습니다 (오버 헤드가 엄청나게 큰 데이터 세트의 경우 중요하지 않음). 또한 사용자에게 주소를 항상 표시하지는 않으므로 왜 사용자 테이블에 표시됩니까? 그것은 별도의 객체입니다. – sethvargo

+0

@Dave Sims - (con't). 나는 그것을 이렇게 보았다. 나에게는 이름이있다. 성이있다. 나는 또한 주소가있다. 나는 address_line_1과 address_line_2, zip ...을 가지고 있지 않다. address에는 address_line_1, 2..zip 등이있다.나를 위해서,이 일들을 분리시키는 것이 더 합당합니다. 주소가없는 사용자가있을 수 있습니까? 누군가 집이없는 경우 사이트에 대한 액세스를 정말로 제한 하시겠습니까? 나는 정상에 오르고 있지만 정상화가 중요한 이유를 알 것입니다. – sethvargo

4

여러 사용자 시스템의 경우 일반적으로 선호되는 방법은 역할 모델 또는 STI 사용입니다. 사용자가 한 번에 여러 개의 역할을 수행 할 수있는 경우 (예 : 단일 사용자가 제조업체 및 운송 업체 인 경우) 역할 기반 시스템이 좋은 해결책이 될 수 있습니다. 사용자 역할이 수정되면 STI와 함께 가야한다고 생각합니다.