1
SQL Server 2012를 데이터베이스로 사용하는 클라이언트 - 서버 시스템이 있습니다. 시스템은 정기적으로 업데이트되고 향상됩니다.SQL Server에서 일반 테이블 만들기
우리는 최근 테이블 디자인의 반복적 인 패턴을 보았습니다. 사용자 테이블을 데이터베이스의 다른 테이블에 연결하여보기 및 권한의 기초를 형성하는 테이블입니다. 예 :
CREATE TABLE Documents_Users (
ID int not null identity(1,1) not for replication,
UserID int not null, -- foreign key to the Users table
DocumentID int not null, --- foreign key to the Documents table
[...]
)
우리는 대신이 모든 테이블을 만드는, 우리는이 같은 하나 개의 큰 테이블을 만들 수 있다고 생각했다 :
CREATE TABLE UserPermissions (
ID int not null identity(1,1) not for replication,
UserID int not null, -- foreign key to the Users table
ObjectID int not null, -- pointer to any object ID in another table
TableID int not null, -- actual id of the referenced table in sys.objects
[...]
)
장점 : 하나 개의 테이블이 해결하는 우리의 권한 모두가 모든 필요를 현재와 미래의 테이블.
단점 :
없는 외래 키. 우리는 한 번씩 실행되는 작업을 생성하고 고아 포인터를 삭제해야합니다 (스토어드 프로 시저에서 삭제하지 않는 경우).
뷰의 라인을 따라 쿼리 할 필요
선택 * some_table]에서 ID 곳에서 ( 가 UserPermissions에서 OBJECTID 선택 여기서 테이블 ID = OBJECT_ID ('someTableName') )
이런 일반화를 만들려면 그만한 가치가 있으며 좋은 습관이 필요합니까? 가능한 한 많은 테이블이 아닌 하나의 테이블과 하나의 인덱스를 읽으면 성능이 향상됩니까?
ERP에는 이와 같은 일반화 된 테이블이 많이 있습니다 (예 : 특성 테이블, 특성은 테이블의 모든 개체와 관련 될 수 있음). 장점 - 적은 테이블 (여전히 수백 개의 테이블이 있음), Attributes 테이블의 공통 트리거. 외래 키 대신 일반 테이블에서 INSERT UPDATE 트리거를 사용하여 모든 대상 테이블의 키 무결성을 검사해야하며 대상 테이블에서 DELETE 트리거를 사용하여 공통 테이블에서 삭제하거나 부모 삭제를 방지해야합니다. – huhu78
SQL Server sys 테이블 식별자 (예 : TableId)의 값을 유지하지 마십시오. 이러한 핵심 가치는 본질적으로 취약하고 여러 가지 이유로 변경 될 수 있습니다. 그들에게 의지하면 당신에게 많은 고통을 줄 수 있습니다. 객체 이름을 사용하거나 자체 대리 문자를 만듭니다. 당신의 쿼리는 분명히 조인을 단순화합니다 : SELECT s. * FROM [some_table] s, UserPermissions u WHERE s.ID = u.ObjectID 및 u.name = 'some_table'; 원칙적으로 동일한 SEQUENCE 객체를 사용하여 IDENTITY 대신 모든 ObjectiD를 생성하면 여기에 외래 키를 사용할 수 있습니다. – sqlvogel
@sqlvogel -이 의견에 감사드립니다. 나는 이것을 몰랐다. – user884248