2011-01-05 4 views
1

다소 복잡한 시나리오가 있지만 가능해야한다고 생각합니다.SQL에서 다양한 수의 열을 가진 테이블을 반환 할 수 있습니까?

나는 결과가 일련의 사람에 대한 특성 세트 인 큰 SPROC를가집니다.

 
Property |	 Client1 	 Client 2	 Client3 
----------------------------------------------------------- 
Sex  |	 M  	 F  	 M 
Age  |	 67  	 56  	 67 
Income |	 Low  	 Mid 	 Low 

그것은 서로 다른 데이터 세트 반복, 커서를 사용으로 구축 :

그래서 표는 다음과 같이 보일 것이다.

내가 직면하고 문제는 클라이언트와 속성의 다양한 수의가 있음을, 그래서 다른 입력 설정을 통해 동등하게 유효한 결과는 다음과 같을 수 있습니다 속성의 다른 번호를 쉽게

 
Property |	 Client1 	 Client 2 
------------------------------------------- 
Sex  |	 M  	 F 
Age  |	 67  	 56 
Weight |	 122  	 122 

, 사람들은

있습니다 그냥 여분의 행.

제 문제는 다양한 수의 열이있는 임시 테이블을 선언해야한다는 것입니다.

2 명의 클라이언트 또는 100 명이있을 수 있습니다. 모든 클라이언트는 궁극적으로 나열된 모든 속성을 가질 수 있습니다.

어떤 SQL 구조가이 점을 규정하고 어떻게 선언하고 삽입 할 수 있습니까?

각각의 변수 번호가 있기 때문에 열과 행을 뒤집을 수 없습니다.

+1

행과 열의 순서는 논리적이고 평범한 것으로부터 바뀌 었습니다. 일단 전치가되면, 이것은 단순히 다른 수의 열을 반환하는 셀렉트의 경우입니다. 셀렉트를 사용할 때마다 발생합니다. 저장 프로 시저에 문제가 있습니까? – Phrogz

답변

4

먼저,과 같이 설계를 정상화 고려해야합니다

Create Table ClientAttributes 
(
    ClientId .... 
    , Sex Char(1)... 
    , Age int... 
    , Income... 
) 

둘째, 일반적으로 SQL 언어를 대상으로하지 않습니다 동적 컬럼 생성. 이를 위해 런타임시 SQL 문 (동적 SQL)을 문자열로 작성해야합니다. 중간 계층 또는 T-SQL이 아닌보고 엔진에서이 작업을 수행하는 것이 가장 좋습니다.

셋째, 속성 또는 인스턴스의 수 또는 유형에 관해 전혀 알지 못하는 무한히 유연한 디자인은 전혀 디자인이 아닙니다. 각 테이블은 알려진 속성을 가진 엔티티의 콜렉션을 나타냅니다. 그들은 임의적 인 데이터의 뭉치가 아닙니다. 특성 (기둥)은 설계시 알려질 필요가 있거나 혼란 이외에 아무것도없는 Cthulhu 설계를 위험에 빠뜨릴 수 있습니다.

Hughes의 제안은 Entity-Attribute-Value 디자인 (a.k.a. EAV)을 사용하는 것입니다. EAV를 제대로 수행하려면 엄청난 수의 훈계가 필요합니다. 그것은 단지 데이터의 뭉치로 취급되는 경우에만 작동합니다. 즉 개발자는 특정 속성 (예 : 특정 속성 이름을 찾는 검색어)을 필터링 할 수 없으며 값을 계산할 수 없기 때문에 특정 값 사이의 일관성을 보장 할 수 없습니다. 당신이 그 분야를 유지할 수 있다면, 으로 제한된 부분으로 데이터의 임의의 뭉치가 작동 할 수 있습니다. 그러나 특정 속성을 찾기 위해 검색어를 하드 코딩하기로 결정한 후에는 어둠의 길을 무너 뜨리고 영원히 당신의 운명을 지배하게됩니다. 데이터베이스가 커짐에 따라 성능이 크게 떨어집니다. 데이터 무결성이 없습니다 (예 : 'Age'및 'Client Age'라는 두 가지 속성이 있으며 일부 값은 정수이고 다른 일부 속성은 텍스트 임). EAV는 유지 관리가 어려울 수 있습니다. 유지 보수,보고, 쿼리 등이 표준화 된 설계를 갖는 것이 훨씬 낫습니다.

4

서버 *에서 피벗을 사용하고있는 것 같습니다.

이 작업을 수행 할 수 있지만 처리하기가 상당히 어려울 것입니다. 그런 경우에는 잘 작동하는 ORM을 알지 못합니다. 대신 피벗의

, 얼마나 더 (* 2)처럼 배열에 대해 : 당신은 여전히 ​​당 클라이언트 표시 목적으로 응용 프로그램에서 피벗 것을 할 수

Client | Property | Value 
------------------------------ 
Client 1| Sex  | M 
Client 1| Age  | 67 

이 방법.

(* FWIW :.? 당신은 당신이 커서를 사용하여 저장하려면 오른쪽 PIVOT Commands을 가지고 2005 + SQL 서버를 알고있다).

(* 2 단지 방법입니다 그것은 해키, 그리고 토마스의 추천에 . 스키마가 훨씬 더 (가능성이) 더 효율적인 방법입니다 정상화)

+0

Ew ... EAV. 또한 EAV에 함부로 언급하거나 링크 할 수 있습니다. – Thomas

+0

왜 나쁜 생각인지 설명하는 데 꽤나 도움이 된 것처럼 보입니다. :) –

관련 문제