0
SQL Server 2008 R2에서 sys.geography 유형을 사용하려고합니다. 위치 기반 쿼리에이 지리 정보 유형을 사용하고 싶습니다. 예를 들어, 저장 프로 시저에 위치 (경도 및 위도 변수로)를 전달하고 근처의 모든 레코드를 반환합니다.SQL Server 지리 유형 성능 - 데이터 트리거 대 뷰
엔티티 프레임 워크가 지리 유형을 지원하지 않으므로이 값을 C#에서 직접 설정할 수 없습니다.
동일한 테이블에서 LocationLatitude 및 LocationLongitude 열을 생성하여이 문제를 해결했습니다. 엔티티 프레임 워크에서 LocationLatitude 및 LocationLongitude 열을 사용하고 데이터베이스 저장 프로 시저의 지리적 유형 "위치"열을 사용하여 작업합니다.
내가 알 수있는 한,이 두 필드에서 지리 "위치"열을 유도하는 세 가지 방법이 있음을 알 수 있습니다.
- 테이블 +
- 이 테이블에 데이터 트리거를 만들기 계산 된 위치의 내용을 반환하는보기 만들기 "위치"계산 된 열
- 을 확인합니다. LocationLongitude 또는 LocationLatitude 열이 업데이트 될 때마다 지리 값을 계산하고 위치 열을 채 웁니다.
성능 측면에서 어느 것이 더 좋을지 궁금합니다. # 1과 # 2가 # 2와 # 3 사이에 있다고 생각합니다.
현재 데이터 트리거를 사용하고 있지만 데이터 트리거를 피하는 것이 가장 좋습니다. 이것은 # 2 (보기)가 그 관점에서 가장 좋을 것이라는 것을 의미하지만 ... # 2를 사용하는 것이 어떤 이유로 믿기지 않을 정도로 바보 일 것이라고 걱정합니다. 그리고 Stack Overflow가이를 확인하는 가장 좋은 장소입니다!
수 ... 이렇게하려면 # 1, # 2, # 3 또는 다른 방법을 사용해야합니까?
# 1이 "최악"이라는 가정에 도전합니다. # 2와 다른 방식으로 # 1을 만드는 것은 무엇을 생각하고 있습니까? –
EF5가 지리 데이터 유형을 지원한다고 생각합니다. 그게 선택의 여지가 있니? – podiluska
@Damien_The_Unbeliever 나는 테이블을 쿼리 할 때마다 지리 정보를 다시 계산해야하는 것이 좋지 않을 것이라고 생각합니다. 별도의 뷰를 가짐으로써 스토어드 프로 시저 내에서만 호출하게됩니다 – John