2010-12-15 1 views
3

C#/.NET WinForms/Desktop 응용 프로그램에 대한 보안을 추가해야합니다. Oracle DB 백엔드를 사용하고 있습니다.데스크톱 앱의 '사용자'/ '역할'테이블에서 대리 키를 사용 하시겠습니까? 목적은 무엇입니까?

테이블은 사용자 (ID, 이름), 역할 (ID, 역할), UserRole (UserID, RoleID)과 같이 간단합니다.

사용자 계정을 채우는 데 Windows 계정 이름을 사용하고 있습니다. 역할 테이블은 이제는 단지 'Admin', '수퍼 유저', 'BasicUser'...

두 명의 사람들이 동일한 Windows 계정 이름을 가질 수 없기 때문에 ...이 이름을 제어하지 않더라도 관리 (netops 않습니다, 그래서 내가 왜 그것을 관리하지 않아도 windows 계정을 사용하려면;)). 롤 테이블의 경우, 나는 속임수 값을 결코 갖지 말아야한다. 나는 입력을 제어한다. 단 3 (전술적 인 앱이 1 년 내에 사라짐)이 될 것이다. UserRole은 사용자와 역할의 다 대다 관계를 나타 내기 위해 조인 테이블이므로 사기 키가 정당화되지 않습니다.

간단한 질문 - 왜 사용자 및 역할 테이블에서 'ID'(int)를 사용해야합니까? 여기에 어떤 이점이나 이점이 있습니까? 이것들 중 하나는 '나는 항상 이런 식으로 해왔다'라는 것입니까? 아니면 잠시 후에이 일을하지 않고 그 이유를 잊어 버린 적이 있습니까?

답변

2

이름 변경 - 기본 키 값을 사용할 수 없습니다. Abigail Smith는 Abigail Jones가되고 사용자 이름은 변경되지만 대리 키는 모든 곳에서 변경 사항을 계단식으로 적용하지 않아도되는 것을 방지합니다.

대리 키를 사용하고 있지만 고유해야하는 열 또는 열의 조합이있는 경우 고유 색인을 사용하여 시행하십시오. 어쨌든 user.name 및 role.role 열의 색인을 원할 수있는 좋은 기회가 있습니다. 고유 색인은보다 공간 효율적이며 유용한 메타 데이터를 최적화 프로그램에 제공합니다. 서로 게이트 키가 있지만 행을 고유하게 식별하는 다른 열의 조합이 없으면 엔티티 정의가 올바른지 다시 확인하십시오.

주의하십시오. 특히 액세스 경로가 거의없는 매우 좁은 테이블의 경우 인덱스 구성 테이블을 사용할 수 있습니다. Oracle은 기본 키에 대한 인덱스 구성 테이블 만 허용하지만 고유 한 인덱스 집합에 대한 외래 키는 허용하지 않습니다 (고유 인덱스가 아닌 고유 제약 조건에 의해 적용되는 경우).

고유 색인을 통해 고유 ID가 적용되고 ORM에 의해 PK로 처리되고 외부 키 관계의 부모로 사용되지만 정의 된대로 기본 키가 사용되는 테이블로 끝날 수도 있습니다 DB에서) rolename/username/whatever 당신이 그것을 인덱스 구성 테이블의 드라이버로 원하기 때문입니다.

+1

"대리 키가 있지만 행을 고유하게 식별하는 다른 열의 조합이 없으면 엔티티 정의가 올바른지 다시 생각해보십시오." - 아 아.당신이 이제까지 1000x 쉬워 야하는 경우에 명백한 가치를 새롭게하는 것을 제외하고 - 이것은 나가 찾고 있던 문장이었다. 이런, 내가 잊을 수있는 기본적인 것들이 얼마나 많은지 나이가 들면서 궁금해. 내가 배운 새로운 재료의 비율은 (켈리 번디 교장) – dferraro

1

는 대리 키는 intersection tables에 필요하지만 여기에 그렇게 할 몇 가지 이유가되지 않습니다

  • 일관성는 : 모든 테이블은 하나의 인공 키가있는 경우, 당신은 항상 키 이름 때를 알고 당신은 테이블 이름을 안다.
  • 사용의 용이성 : 하나의 키로 인해 ONWHERE 절이 더 짧아 오류가 발생하지 않습니다.
  • 상호 운용성 : 일부 ORMs은 단일 기본 키 열이있는 테이블에서만 작동합니다.