캐릭터 기반의 안전성과 캐릭터 차단

묘사

안녕, 리안,
플러그인 고마워요.간단하게 말하자면 한 사용자가 여러 개의 캐릭터를 가질 수 있을 때 캐릭터의 안전성을 바탕으로 한 해결 방안은 나를 놀라게 한다. 예를 들어 캐릭터 위치 마스크는 나에게 매우 위험하다. 예를 들어 새로운 캐릭터를 추가하거나 다른 캐릭터를 삭제하는 것이다.의심할 여지없이, 너는 이 점을 알고 있다. 그래서 나의 문제는, 네가 이렇게 한 것은 성능 때문이냐?
물론 cancan은 특정한 역할 실현 방식을 강제로 실시하지 않았기 때문에 우리는 다대다ql관계를 사용하는 것처럼 자유롭게 자신의 방식으로 실현할 수 있다.나는 단지 너의 비키에 이 예를 보류하는 것이 좋은 일인지 알고 싶을 뿐이다.
감사합니다. 매혹적인 스크린도 감사합니다!
Philippe

토론 #1

는bitmask에 캐릭터를 추가하는 데 문제가 없을 것이다.색인을 상쇄하기 때문에 캐릭터를 삭제해서는 안 된다. 반대로 '삭제된' 캐릭터를 표시해야 하는 곳에 캐릭터를 숨기는 것이 좋다.
비트 마스크 역할은 성능이 아니라 코드와 데이터베이스 간의 의존 관계를 삭제하기 위한 것이다.만약에 모든 역할이 하나의 단독 데이터베이스 항목이라면 데이터베이스와 코드 간의 결합은 매우 긴밀하다. 코드를 바꾸지 않으면 데이터베이스를 영원히 바꾸지 않을 것이다. 반대로도 마찬가지다.모든 개발 기계와 생산 사이에서 모든 동기화를 유지하려고 시도하는 것은 복잡성을 증가시켰다.
비트 마스크 역할은 이러한 결합을 없애고 코드의 모든 내용을 관리할 수 있도록 합니다.그러나 이것은 모든 응용 프로그램에 적용되지 않는다.각 역할과 연관된 추가 메타데이터가 필요하면 데이터베이스로 이동하는 것이 좋습니다.
나는 위키 페이지에서 이 점을 더욱 명확하게 설명할 것이다.

토론 #2

안녕, 리안,
네, 알겠습니다.이제 사용자 역할 인덱스를 비트 마스크에 저장하는 것보다 사용자 역할 이름을 연결하여 문자열로 저장하는 것이 좋습니까?이 두 가지 측면이 모두 가장 좋다. 데이터베이스와의 느슨한 결합, 역할 삭제, 역할 재배열 또는 마지막 위치 전에 캐릭터를 삽입할 때 문제가 없다.대부분의 경우 문자열 (255) 은 충분할 것이다.물론 디스크에 몇 바이트가 더 필요하지만, 누가 신경 쓰겠는가?
Philippe

토론 #셋

나는 문자열을 정확하게 일치하는 것을 좋아하지 않는다.만약 한 사람이 캐릭터를 다시 명명해야 한다면, 많은 변화가 있을 것이다.그러나 네가 말한 바와 같이 순서와 색인은 중요하지 않다.
나는 그것을wiki에 대체 옵션으로 추가할 것이다.

토론 #4

plang은 특정 캐릭터를 가진 사용자를 선택할 때 비트 마스크도 우수성을 가진다.
예를 들어 ROLES = %w(admin sales csr customer)모든 관리자를 찾으려면 다음과 같이 하십시오.

# index for admin is 0
# bit for admin is 2**0 == 1
User.all(:conditions => ["roles_mask & ?", 1])

모든 CSR 찾기

# index for csr is 2
# bit for csr is 2**2 == 4
User.all(:conditions => ["roles_mask & ?", 4])

실제로, 나는 이미 이 때문에 소형 named_scope 생성기를 만들었다

ROLES.each_with_index do |role, bit|
  self.instance_eval <<-"end_eval", __FILE__, __LINE__
    named_scope :#{role}, :conditions => ["roles_mask & ?", 2**bit]
  end_eval
end

위에서 정의한 ROLES를 사용하면

User.admin
User.sales
User.csr
User.customer

비트 마스크 예뻐요: D

토론 #5

Hi-macek,
캐릭터가 고정된 상황에서 비트 마스크를 사용하면 된다는 것에 동의합니다.그러나 내가 보기에 캐릭터를 추가하거나 수정하거나 삭제하기 시작하면 상당히 위험해진다.실수하기는 쉽다.
반면 사용자와 역할 간에 다대다관계를 가진 데이터베이스 디자인은 오류를 범하는 것을 허용하지 않는다.외키는 여기서 당신을 막는다. 만약 당신이 하루 아침에 커피를 마시지 않았다면, 소란을 피우기 시작할 것이다.
나는 바로 이렇게 생각하지만, 해결 방법이 매우 많다.지난 15년간 데이터베이스 기반 애플리케이션을 작성해 왔기 때문에 다른 데이터베이스 디자인으로 완전히 전환하는 데 시간이 필요합니다.
가장 좋은 축원을 드립니다.
필립

토론 #6

필립,
사용자와 캐릭터 간의 다대다 관계가 최고 수준의 유연성을 가져올 수 있다는 것을 이해할 수 있지만 간단하게 실현되기만 하는 사용자에게 비트 마스크는 매우 우아한 처리 방식이다.
그것의 속도에 비견할 만한 것은 아무것도 없다.그것은 다대다의 관계를 효과적으로 모의했고 심지어는 별도의 표도 없었다.그것은 기존 테이블의 한 필드일 뿐입니다.전통적인 다대다 관계에 비해 두 개의 모형표와 하나의 연결표가 필요하다...
나는 일을 완성하는 방법이 한 가지가 아니라는 것을 기억해 보았다.내가 과거에 사용했던 해결 방안은 내가 오늘 직면한 새로운 문제에 적합하지 않을 수도 있다.칸칸이 다른 방식이 아닌 다른 방식을 강요하지 않았기 때문에 환호한다:)
여기다
바울

토론 #7

@macek: 오토매틱 오실로그래프를 자동으로 생성하는 좋은 생각입니다.감사합니다:)
비트맵 솔루션의 마지막 점은 모든 역할에 역할 영역을 만들고 싶지 않다는 것입니다.나는 낡은 역할을 삭제할 필요가 없다. 나는 이 해결 방안에 전적으로 동의한다.

토론 #8

이 문제를 끝낼 때 나는 Separate Role Model 페이지에서 Role Based Authorization 해결 방안을 다시 언급했다.어떤 사람들은bitmask 솔루션을 좋아하지 않는다는 것을 깨달았습니다. 이런 상황에서 제가 여기서 언급한 단독 캐릭터 모델을 견지해 주십시오.