내가

Question

내가이 필드가 테이블이 (파이어 서버를 사용) SQL로 연속 문자 occurencies를 계산하는 데 도움이 필요 : 각 행의 몽의 매일

 
id(primary key, auto increment) 
car registration number 
car model 
garage id 

31 필드.

이 필드에는 해당 날짜에 자동차 상태를 나타내는 1 또는 2 문자의 문자가 있습니다. 그 날의 각 가능성의 수를 얻기 위해 질의를해야합니다. 어떤 날의 필드도 값을 가질 수 있습니다 : D, I, R, TA, RZ, BV 및 LR.

각 행에서 각 행의 값을 계산해야합니다. 얼마나 많은 I, 얼마나 많은 D 등등. 그리고 테이블의 모든 행에 대해. 최선의 접근 방법은 무엇입니까? 또한 아마도 30 개가 넘는 필드를 분명히 만들기 때문에 데이터베이스 테이블에 필드를 추가하는 것이 더 나은 방법 일 수도 있습니다.

Answer 1

더 좋은 방법이 있습니다. 다른 테이블이 있도록 같은 행이 데이터를 구성해야합니다

• CarId
• 날짜
• 은 상태

그런 다음 쿼리는 단순히 다음과 같습니다

select status, count(*) 
from CarStatuses 
where date >= @month_start and date < month_end 
group by status; 

데이터 모델의 경우 처리하기가 훨씬 더 어렵습니다. 다음과 같이 할 수 있습니다.

select status, count(*) 
from ((select status_01 as status 
     from t 
    ) union all 
     (select status_02 
     from t 
    ) union all 
     . . . 
     (select status_31 
     from t 
    ) 
    ) s 
group by status; 

Answer 2

관계형 데이터베이스 및 SQL 디자인에 대한 가장 기본적인 자습서부터 시작해야합니다. "Martin Gruber - Understanding SQL"과 같은 고전 작품이 도움이 될 수 있습니다. 또는 다른 사람. ATM은 기본을 놓쳤습니다.

몇 가지 힌트.

1. 사용자 용으로 인쇄하거나 사용자로부터받은 문서는 내부 데이터 구조를 나타내지 않습니다. 그들은 그 목적을 가진 machine-to-human 인터페이스를 위해 생성/파싱됩니다. 프로그램 내부에서 저장/처리가 용이하도록 데이터를 구조화해야합니다.

2. 상태에 "사전 표"를 추가해야합니다.

ID/약자/사람이 읽을 수있는 설명

당신은 "R"상태에서 당신이 중 하나를 "D"상태거나 "BV"상태로 전환 할 수있는 "비즈니스 규칙"을 가질 수 있지만, 다른 어느 누구에게도. 즉, 가능한 방향 전환 "방향성 그래프"를 작성하는 것이 좋습니다. 사전 테이블의 추가 열 또는 하나의 특수화 된 도우미 테이블에이 열을 보관합니다. 가능한 상태 사전에 대한 전환 사전입니다.

3. 용지 여백은 합계와 일별 상세 정보를 같은 행에 결합합니다. 그것은 인간이보기에 쉽지만 어떤면에서는 단일 책임 원칙을 위배하는 컴퓨터의 경우입니다. 행은 기본 레코드 또는 파생 된 전체 계산을 담당해야합니다.일일 기록과 일별 총계에 대해 하나씩 두 개의 테이블을 갖는 것이 좋습니다.

4. 보너스 포인트는 기본 데이터 테이블의 값을 변경하면 해당 달 총계를 자동으로 다시 계산하도록 서버에 요청할 수 있습니다. SQL triggers에 대해 읽어보십시오.

5. 또한 "비즈니스 규칙"에 설명 된대로 새 상태가 전날 상태에서 올바르게 전송되는지 확인할 수 있습니다. 그들은 또한 하루 사이에 간격이 없는지 확인해야 할 것입니다. "march 03"에 대한 레코드가 있고 "march 05"에 대한 레코드가 새로 삽입되면 "march 04"에 대한 레코드가 존재해야하며 그렇지 않으면 서버에서 해당 행을 추가 할 수 없습니다. 어쩌면 그렇지 않을 수도 있습니다. 그것은 비즈니스 프로세스에 달려 있습니다. 일반적인 생각은 서버가 유효하지 않은 데이터를 저장하는 것을 거부해야하고 서버가이를 알 수 있어야한다는 것입니다.

6. 날짜 및 월별 테이블에 UNIQUE CONSTRAINT은 중복 행 입력을 금지해야합니다. 또한 이전에는 DATE 형 컬럼이 있어야하고 후자는 INTEGER 형 컬럼이 있어야하고 DATE 형 컬럼이 있어야합니다. DATE 타입 컬럼은 항상 "1"이됩니다. - CHECK CONSTRAINT이 필요합니다. .

7. 귀하의 회사가 자동차 등록 정보가있는 경우 (그리고 아마 자동차를 등록한 사람이 몰려 들었다는 것을 알지 못할 수도 있습니다), 자동차 사전 테이블을 도입해야합니다. 정수 ID (PK), 등록 번호, 엔진 공장 번호, 수레 공장 번호, 색상 및 기타 사항.

8. 월별 합계 테이블에는 모든 상태마다 많은 열이 포함되지 않습니다. 대신 모든 상태에 대해 특별한 행을 가질 것입니다! 구조는 아마도 다음과 같을 것입니다 : 월/년/레지스트리에있는 차량의 ID/사전의 상태 ID/개수. 모든 열은 정수 유형입니다 (일부는 SmallInt 또는 BigInt 일 수 있지만 이는 미묘한 차이입니다). 함께 모든 열 (개수 열 제외)은 UNIQUE CONSTRAINT 또는 더 나은 "화합물"Primary Key을 구성해야합니다. 여기에 총 전용 테이블에 특별한 전용 PK 컬럼을 추가하는 것은 나에게 불필요한 것처럼 보입니다.

9. 따라서 일일 및 월별 테이블에는 상태 및 자동차 ID에 대한 문자 (텍스트 및 즉시) 데이터가 없습니다. 대신 정수 ID가 해당 자동차 사전 및 상태 사전 테이블의 적절한 레코드를 참조 할 수 있습니다. 그 코드는 FOREIGN KEY입니다.

엄지 손가락의 규칙을 기억 :/추가 한 테이블에 행을 삭제하지만, 아주 열심히 추가/열을 삭제하기 쉽습니다.

너와 같은 디자인으로 열 지향적인데, 내년에 상사가 더 많은 지위를 도입한다면 어떻게 될까? 당신은 테이블, 프로그램 등을 많은 시점에서 재 설계해야 할 것입니다.

행 지향 디자인을 사용하면 상태 사전에 한 행을 추가하고 전환 규칙 사전에 행을 몇 개 추가해야하며 나머지는 변경하지 않고 작동합니다. 그런 식으로하면 안된다