2010-01-06 4 views
4

우리 조직에서는 WHERE 절을 제공하여 직원이 웹 응용 프로그램의 데이터를 필터링 할 필요가 있습니다. 큰 테이블이나 비효율적 인 조인에 풀 테이블 스캔을 요구하는 쿼리를 제공하는 사용자에 그것은 오랜 시간 동안 좋은 일,하지만 우리는 가끔 실행 등"합리적인"쿼리 만 사용

일부 광대과 같이 작성할 수 있습니다

: 분명히

select * from big_table where 
Name in (select name from some_table where name like '%search everything%') 
or name in ('a', 'b', 'c') 
or price < 20 
or price > 40 
or exists (select 1 from some_other_table where col1 + col2 + col3 = 4) 
or exists (select 1 from table_a, table+b) 

을, 이것은 계산 된 값, 색인화되지 않은 열, 많은 OR 및 table_a 및 table_b에 대한 제한되지 않은 조인으로 이러한 테이블을 쿼리하는 좋은 방법은 아닙니다.

하지만 사용자에게는 이것이 합리적 일 수 있습니다.

그렇다면 내부 사용자가 데이터베이스에 쿼리를 제공하면서 12 개의 테이블을 잠그지 않고 웹 서버를 5 분 동안 정지시키지 않도록하는 가장 좋은 방법은 무엇입니까?

나는 그것이 실행되기 전에 질의에 대한 실행 계획을 얻기 위해 C#/sql-server에서 프로그래밍 방식으로 생각하고 있습니다. 그렇다면 비용 요인은 무엇입니까? 예상 I/O 비용? 예상 CPU 비용은 얼마입니까? 사용자에게 쿼리가 좋지 않음을 알리는 합리적인 제한은 무엇입니까?

편집 : 우리는 시장 조사 회사입니다. 수천 개의 설문 조사가 있으며 각 설문 조사마다 자체 데이터가 있습니다. 우리는 수십명의 연구자가 그 데이터를 임의적으로 분할하고자합니다. GUI를 사용하여 "유효한"필터를 구성 할 수있는 도구가 있지만 일부 "고급 사용자"는 자체 쿼리를 제공하려고합니다. 이것이 표준이 아니거나 모범 사례는 아니지만, 수십 명의 사용자가 임의로 복잡한 조건과 끊임없이 변화하는 조건을 사용하여 원하는 행을 쿼리 할 수 ​​있도록하는 방법은 무엇입니까?

+0

고객과 WHERE 절을 작성하는 일종의 계층을 제안하는 답변 외에도 일반적인 쿼리에 대한보기를 설정하는 방법은 무엇입니까? – Zwergner

+2

데이터웨어 하우스에 데이터를 복사하고 사용자가 안전한 곳에서 데이터를 분석하도록 할 것입니다. – CaffGeek

답변

3

다음 사용해 볼 수 있습니다 :

SET SHOWPLAN_ALL ON 
GO 
SET FMTONLY ON 
GO 
<<< Your SQL code here >>> 
GO 
SET FMTONLY OFF 
GO 
SET SHOWPLAN_ALL OFF 
GO 

그런 다음 당신이있어 무엇을 구문 분석 할 수 있습니다. 여러 가지 일에 선을 그어야 할 곳은 경험이 필요합니다. 지켜봐야 할 것이 있지만 잘라내어 말리는 것은 없습니다. 과학보다는 쿼리 계획을 조사하는 것이 더 많은 기술입니다.

다른 사람들이 지적했듯이, 나는 당신의 문제가 기술의 영향보다는 더 깊다고 생각합니다. 이러한 방식으로 자격이없는 사람들이 귀하의 데이터베이스에 액세스하게한다는 사실은 근본적인 문제입니다. 과거 경험에 비추어 볼 때, 나는 자신들의 애플리케이션 요구 사항을 적절히 포착하기에는 너무 게으르거나 너무 경험이없는 회사에서 종종 이것을보고 있습니다. 나는 이것이 당신의 기업 환경에서 반드시 필요한 경우는 아니지만 그것이 내가 본 것입니다.

0

SQL 주입 공격에 대해 들어 본 적이 없습니까? 사용자가 WHERE 절 다음에 DROP DATABASE 명령을 입력하면 어떻게됩니까?

+0

a) 앱을 사용하는 직원입니다. 일부는 바보, 아무도 악의적 인 사람이 아닙니다. b) 쿼리는 읽기 전용 사용자 만 사용하여 실행됩니다. –

+0

유효한 관심사이지만 질문에 대한 답변이 아닙니다. – Zwergner

+5

직원들이 결코 악의적이지 않다는 가정에주의해야합니다. :) –

1

직원들이 쿼리를 직접 작성 (추가)하는 대신 쿼리 비용을 계산하는 대신, 제어 할 수없는 SQL을 작성하지 않는 고급 검색 또는 필터 기능을 만들지 마십시오.

5

질문 상태의 전제 :

우리 조직에서

우리가 WHERE 절을 제공하여 웹 응용 프로그램에서 직원 필터 날짜를하게 할 필요가있다.

이 전제는 얼굴에 결함이있는 것으로 나타났습니다. 나는 사용자가 이것을 할 수있는 상황을 상상할 수 없다. 이미 확인한 문제 외에도 SQL 주입 공격까지 스스로 열 수 있습니다.

귀하의 요구 사항을 재평가하여 사용자가 검색 할 수 있도록보다 안전하고 집중된 방법을 구축 할 수 없는지 확인하는 것이 좋습니다.

그러나 실제로 사용자가 WHERE 절을 직접 제공 할 정도로 정교하고 신뢰할 수 있다면 사용자가 필터로 제출할 수있는 것과 제출할 수없는 것에 대해 교육 받아야합니다.

+0

동의. 정말로 요구 사항이 실제로 사용자가 직접 쿼리를 발행 할 수 있도록 허용하는 것이라면 (교육이 최선의 경로입니다) –

0

이는 대다수의 응용 프로그램에서 사용자에게 직접 SELECT 권한이 부여되지 않는 이유입니다.

훨씬 더 나은 접근법은 유스 케이스를 중심으로 애플리케이션을 설계하여 특별히 설계된 필터/집계/레이아웃 옵션으로 합당한 비율의 요구 사항을 충족 할 수 있도록하는 것입니다.

이 방법에는 무수히 많은 방법이 있으므로 특정 문제 영역에 대한 분석이 실용적인 방법에 대한 연구와 함께 반드시 필요합니다.

직접 SQL 액세스가 사용자에게 가장 융통성이 있지만 오래 실행되는 쿼리는 두통의 시작일뿐입니다. SQL 인젝션은 소스가 악의적이거나 단순히 잘못된 것인지는 큰 관심사입니다.

2

사용자가 입력 한 내용을 제어하려는 것 외에도 (느슨한 전투 임에도 불구하고 항상 새로운 질문이 생깁니다), 리소스 관리자 (Resource Governor)를 살펴 보겠습니다 (Managing SQL Server Workloads with Resource Governor 참조). ad-hoc 쿼리를 별도의 풀에 넣고 할당 된 리소스를 제한합니다. 이렇게하면 잘못된 쿼리가 수행 할 수있는 피해의 양을 다른 개의 작업으로 제한하여 문제를 완화 할 수 있습니다.

또한 Power Pivot과 같은 다른 방법으로 데이터에 액세스 할 수 있도록하고 사용자가 자신의 Excel에서 원하는만큼 자신의 데이터를 마사지 할 수 있도록해야합니다. 비즈니스 파워 사용자는이를 좋아하고 transaciton processign 서버에 미치는 영향은 미미합니다.

1

매우 큰 규모의 내부 응용 프로그램에서 발생하는 기업 환경에서 이는 일반적인 관행입니다. 디자인 단계에서 기준을 제한하거나 데이터 범위에 합리적인 제한을두기도하지만 일단 비즈니스가 응용 프로그램을 확보하면 비즈니스 단위 관리가 제한을 제거하라는 요청이있을 것입니다. 나의 창안에서 이것은 엔지니어링 문제가 아닌 관리 문제입니다.

우리가 한 것은 모든 기준을 분석하여 가장 큰 범죄자, 사용자 및 어떤 유형의 쿼리가 가장 많은 문제를 일으켰으며 일부 쿼리에 제한을 두는 것을 발견했습니다. 또한 정기적으로 사용되는 매우 비싼 쿼리가 앱에 추가되어로드가 낮을 때 앱이 결과를 캐싱하고 쿼리를 실행했습니다. 우리는 표준 사용자를 위해 caned 최적화 된 쿼리를 생성하고 지정된 사용자에게만 아무것도 검색 할 수있는 권한을 부여했습니다. 몇 가지 아이디어 만 있습니다.

1

데이터베이스에 대한 데이터 모델을 만들고 사용자가 SQL Reporting Services의 보고서 작성기를 사용할 수 있도록 허용 할 수 있습니다. GUI 기반이며 WHERE 절을 작성할 필요가 없으므로 수행 할 수있는 손상의 한계가 있어야합니다.

아니면 창고 사용자 쿼리의 목적을 위해 DB의 복사, DB를 매 시간 정도를 업데이트하고 마을 ... :) 가자 수는

0

(차드 주석이 언급 하지만 대답이 될만한 가치가 있다고 생각합니다.) 대다수 사용자의 문제를 해결하기 위해 임시로 쿼리해야하는 데이터를 별도의 데이터베이스에 복사해야합니다.

1

나는이 또한 올 수있는 몇 곳에서 일했다. 우리가 한 일은 결국 사용자가 무제한 액세스를 할 수 없도록하고 IT가 필요할 때 쿼리를 제공하도록 최선을 다할 것을 약속하는 것이 었습니다. 문제는 데이터베이스가 상당히 복잡하고 사용자가 문법적으로 구문 론적으로 올바른 SQL을 작성할 수 있다고하더라도 테이블 간의 관계를 반드시 이해할 필요는 없다는 것입니다. 즉, 자신의 SQL을 작성할 수 있다고해도 잘못된 대답을 얻을 수 있습니다. 우리는 사용자가 데이터베이스의 200 개 테이블에 대한 결함 또는 불완전한 이해를 기반으로 잘못된 결정을 내릴 위험이 너무 높다고 확신했습니다. 하루가 지나면 잘못된 대답보다 즉시 올바른 답을 얻는 것이 더 좋습니다.

다른 부분은 사용자 A가 쿼리를 작성하고 1 개의 대답을 얻을 때 IT가 수행하는 작업이며 사용자 B는 동일한 쿼리라고 생각하는 내용을 쓰고 다른 대답을 얻습니다. 차이점을 찾는 것이 IT 부서의 임무입니까? 두 가지 SQL 부분을 수정하려면? 결론은 나는 그들에게 접근을 허용하지 않을 것이라는 것이다. 다른 사람들이 언급 한 것처럼 미리 정의 된 쿼리로 시스템을로드하고 장기적으로 이것이 작동하는 유일한 방법은 mgmt를 교육하려고합니다.

1

당신은 너무 많은 데이터가 있고 고객에게 분석하고, 나는 강력하게 일에 대한 OLAP 기술을 운영자 추천 원하는대로 정보를 볼 수있는 기능을 제공합니다.

관련 문제