DateTime 열에 startingDate를 저장하는 테이블이 있습니다. 내가 STARTINGDATE 값이 있으면성능 및 유지 관리를 위해 계산 열을 사용하거나 사용하지 않으려면
,의
을 해야하는 건가요 현재 날짜.
응용 프로그램의 두 개 이상의 장소에서이 값을 사용하려고 할 때 응용 프로그램 응답 시간에 많은 신경을 쓰면보기에서 계산을 수행하거나 각각에 대해 계산 된 열을 만들어서 쿼리 할 수 있습니다 직접 테이블?
계산 된 열은 유지하기 쉽고 문제에 대한 이상적인 솔루션을 제공합니다. 최근에 이러한 솔루션을 사용했습니다. 그러나 행이 테이블에 INSERT 될 때가 아니라 요청이있을 때 (선택된 경우) 값이 계산된다는 점에 유의하십시오. 따라서 성능이 여전히 문제가 될 수 있습니다. 응용 프로그램 서버에서 데이터베이스 서버로 작업량을 줄일 수 있으면이 방법이 적합 할 수 있습니다. 뷰는 요청이있을 때까지 존재하지 않으므로 (실체화되지 않은 경우) 런타임시 오버 헤드가 발생하지만 다시 애플리케이션 서버가 아니라 데이터베이스 서버에 있습니다.
거의 모든 것 : 좋아요.
@RedX는 성능 차이가별로 없으므로 사용 방법에 대한 질문이됩니다. 나에게 이것은 좀 더 느낌이 든다.
두 번 이상 사용하면보기 또는 계산 열로 즉시 이동하지 않아도됩니다. 몇 군데 또는 적은 양의 코드 경로에서만 사용하면 해당 장소에서 인라인으로 계산하거나 CTE를 사용할 수 있습니다. 그러나 만약 그것이 광범위하게 퍼져 있거나 과도하게 사용된다면 저는 전망이나 계산 된 칼럼에 동의 할 것입니다.
ORM 도구를 통해보기를 원할 경우보기 또는 참조로 표시 할 수도 있습니다.
개별 "장소에서 계산 된"열을 사용합니까? 아니면 세트로 사용합니까? 세트에서 사용하는 경우에는 아마도 모두 포함 된 테이블의보기를 원할 것입니다.
내가 필요할 때 일반적으로 특정 다른 테이블의 데이터와 연결되기를 원하십니까? 그렇다면 그것은 관점을 제안 할 것입니다.
계산 된 값의 원본 테이블에서 업데이트를 기반으로합니까? 그렇다면 계산 된 열이 이러한 경우보기에 합류하지 못하게해야합니다.
계산 된 열은 처음에는 쉬운 솔루션으로 보일 수 있지만 회사에서 Attunity와 같은 도구를 사용하여 실시간 변경 데이터 캡처를 위해 ETL을 수행하려고 할 때 계산 된 열을 인식하지 못하기 때문에 회사에 문제가있는 것으로 나타났습니다. 값이 영구적으로 존재하지 않기 때문입니다. 그래서 몇 가지 문제가 있습니다. 또한 사용자가 여러 번 열을 검색하는 경우 ETL 도구 또는 프로 시저에 논리를 넣고 요청마다 여러 번 계산하지 않고 데이터베이스에 한 번 작성하여 시간을 절약 할 수 있습니다.
프로필이 응용 프로그램의 병목인지 확인하고 프로필을 확인하십시오. 그렇지 않다면 걱정하지 말고 실제 병목 현상을 먼저 개선하십시오. – RedX