2017-02-17 5 views
6

저는 데이터베이스 작업에 중점을두고 매일 파이썬을 사용합니다. 내 표준 시작 pyodbc 사용파이썬 pyodbc 커서 대 데이터베이스 커서

connection_hostname = pyodbc.connect('connection_string') 
cursor_hostname = connection_hostname.cursor() 
command_hostname = 'select * from everything_forever;' 
cursor_hostname.execute('command_hostname') 

같은 것입니다 그리고 난 새로운 커서를 만드는 대신 다른 쿼리에 대한 커서를 다시 사용할 필요가 있다면, 정말 같은 첫 번째 쿼리에서 결과 집합을 저장할 수 있습니다 :

results_from_query = cursor_hostname.fetchall() 

그 후 계속 진행하십시오.

이 접근 방식은 지금까지 저에게 효과적이었습니다.

최근에 일자리가 바뀌었고 GUI를 사용하는 새로운 동료 중 일부가 DB를 사용하여 위의 기술을 시연했을 때 당황했습니다. 그것들을 설정하는 것은 커서 키워드였습니다. 커서가 집합 이론에 기반하지 않은 논리를 나타내며 호스트를 저/제로 수준의 병렬 처리 및 RBAR 유형 연산으로 푸시하는 경향이 있기 때문에 커서가 DB를 사용하는 것은 큰 문제가 아니라는 것을 이해합니다. 그러나 ODBC 커서 ' 위의 선언문은 SQL Server 엔지니어링 및 관리 용 모자를 쓰고있을 때 생각할 수있는 커서와 같습니다.

다른 사람이 이러한 ODBC 커서와 SQL Server 형식 커서 간의 차이점을 설명 할 수 있습니까?

내가 틀렸다면 제게 알려 주어 제 DB와보다 효율적으로 인터페이스 할 수있는 방법을 알려주십시오.

왜 당신은 단지 그들이 연결 비용 등을 줄이기 위해 같은 연결을 통해 여러 커서를 허용 함께 할 수있는 뭔가가 있습니다로 ODBC 커서 구조를 가진 같은

connection_hostname.execute(command_hostname) 

내가 느끼는 같은 연결에서 직접 실행하지 못할. 기지에서 벗어나?

답변

2

데이터베이스 커서는 일반적으로 정당한 이유 때문에 DBA에 의해 비방 받고 불신합니다. 종종 성능 문제의 원인이되며, 집합 기반 방식이 거의 항상 더 좋습니다. 예를 들어

http://www.databasejournal.com/features/mssql/article.php/3896206/What-Every-DBA-Ought-to-Know-About-SQL-Server-Cursors-and-Their-Alternatives.htm는 말한다 :

는 "내 직장에서, 커서는 우리의 SQL 서버 표준에서 금지 커서를 사용하려면, 우리는 커서의 성능은 처리를보다 낫다는 것을 증명해야합니다. 다른 방법으로 행을 사용하는 것이 좋습니다. "

지나치게 단순화하기 위해 파이썬 커서는 실제로 다른 언어에서 레코드 집합이나 결과 집합을 호출하는 것과 동의어이며 GUI 도구는 커서/레코드 집합 (그러나 DB에 커서를 만들지 마십시오!).

difference between cursor and connection objects