StackOverflow ( LINQ 초보자 안내서)의 "LINQ 초보자 안내서"게시물을 살펴 보았지만 후속 질문이있었습니다.
우리는 거의 모든 데이터베이스 작업이 상당히 간단한 데이터 검색 (이미 데이터를 쓰는 프로젝트의 다른 세그먼트가 있음) 인 새 프로젝트를 시작하려고합니다. 지금까지 우리의 다른 프로젝트들 대부분은 그런 것들을 위해 저장 프로 시저를 사용합니다. 그러나 LINQ-to-SQL이 더 합리적이라면 활용하고 싶습니다.
따라서 문제는 다음과 같습니다. 간단한 데이터 검색의 경우 LINQ-to-SQL 또는 저장 프로 시저 중 어떤 방법이 더 좋습니까? 특정 장단점?
감사.
답변:
sproc에 비해 LINQ의 몇 가지 장점 :
LINQ vs sproc의 몇 가지 단점 :
사람들은 보안 및 관리 효율성에 대해서도 논쟁하고 있습니다.
나는 큰 sproc 사람 이었지만 일반적으로 더 나은 대안으로 LINQ에 기대기 시작했습니다. sproc이 더 나은 일부 영역이 있다면 아마도 sproc을 작성하지만 LINQ를 사용하여 액세스 할 것입니다. :)
if진술 로 해결할 수 있습니다 .
나는 일반적으로 DBA가 수년 동안 해왔 던 모든 이유 때문에 모든 것을 저장 프로 시저에 넣는 것을 제안합니다. Linq의 경우 간단한 CRUD 쿼리로 성능 차이가 없을 것입니다.
그러나이 결정을 내릴 때는 몇 가지 사항을 명심하십시오. ORM을 사용하면 데이터 모델과 밀접하게 연결됩니다. DBA는 컴파일 된 코드를 변경하지 않고 데이터 모델을 자유롭게 변경할 수 없습니다. 스토어드 프로 시저를 사용하면 프로 시저에서 리턴 된 매개 변수 목록 및 결과 세트가 계약을 나타내며 해당 계약이 여전히 충족되는 한 내부 값을 변경할 수 있으므로 이러한 종류의 변경 사항을 범위에서 숨길 수 있습니다. .
또한 Linq를보다 복잡한 쿼리에 사용하면 데이터베이스 튜닝이 훨씬 더 어려운 작업이됩니다. 스토어드 프로 시저가 느리게 실행될 때 DBA는 코드에 전적으로 집중할 수 있으며 많은 옵션을 가질 수 있으므로 계약이 완료 될 때에도 계약이 여전히 충족됩니다.
배포 된 컴파일 된 코드를 변경하지 않고 저장 프로 시저의 스키마 및 코드를 변경하여 응용 프로그램의 심각한 문제를 해결 한 사례가 많이있었습니다.
아마도 Linq와 함께 하이 버드 접근이 좋을까요? 물론 Linq는 저장 프로 시저를 호출하는 데 사용될 수 있습니다.
Linq-Sql
SQL Server는 쿼리 계획을 캐시하므로 sproc의 성능 향상은 없습니다.
반면, linq 문은 논리적으로 응용 프로그램의 일부이며 테스트를 거칩니다. Sproc은 항상 약간 분리되어 있으며 유지 관리 및 테스트가 더 어렵습니다.
지금 처음부터 새로운 응용 프로그램을 작업하고 있다면 Linq를 사용하고 싶었습니다.
기본적인 데이터 검색을 위해 망설이지 않고 Linq를 사용하려고합니다.
Linq로 이사 한 후 다음과 같은 장점을 발견했습니다.
LINQ는 프로 시저 캐시를 팽창시킵니다
응용 프로그램에서 LINQ to SQL을 사용하고 있고 쿼리 길이가 매우 가변적 인 문자열을 사용하는 경우 SQL Server 프로 시저 캐시는 가능한 모든 문자열 길이마다 하나의 쿼리 버전으로 확장됩니다. 예를 들어 AdventureWorks2008 데이터베이스의 Person.AddressTypes 테이블에 대해 생성 된 다음과 같은 매우 간단한 쿼리를 고려하십시오.
var p =
from n in x.AddressTypes
where n.Name == "Billing"
select n;
var p =
from n in x.AddressTypes
where n.Name == "Main Office"
select n;이러한 쿼리가 모두 실행되면 SQL Server 프로 시저 캐시에 NVARCHAR (7)로 바인딩 된 항목과 NVARCHAR (11)로 바인딩 된 항목이 두 개 표시됩니다. 이제 길이가 다른 수백 또는 수천 개의 다른 입력 문자열이 있는지 상상해보십시오. 프로 시저 캐시는 불필요하게 정확히 동일한 쿼리에 대한 모든 종류의 서로 다른 계획으로 채워질 것입니다.
자세한 내용은 https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290
프로 LINQ 논쟁은 데이터베이스 개발에 대한 역사가없는 사람들 (일반적으로)에게서 온 것 같습니다.
특히 VS DB Pro 또는 Team Suite와 같은 제품을 사용하는 경우 여기에 작성된 많은 주장이 적용되지 않습니다.
유지 관리 및 테스트 어려움 : VS는 전체 구문 검사, 스타일 검사, 참조 및 제약 조건 검사 등을 제공합니다. 또한 전체 단위 테스트 기능과 리팩토링 도구를 제공합니다.
LINQ는 ACID 테스트에 실패하여 진정한 단위 테스트를 불가능하게 만듭니다.
LINQ : 디버깅이 더 쉬운 이유는 무엇입니까? VS를 사용하면 관리되는 코드와 SP의 정기적 디버깅을 완벽하게 활용할 수 있습니다.
배포 스크립트가 아닌 단일 DLL로 컴파일 : VS는 다시 한 번 전체 데이터베이스를 구축 및 배포하거나 데이터에 안전한 증분 변경을 수행 할 수 있습니다.
LINQ로 TSQL을 배울 필요가 없습니다. 아니요, LINQ를 배워야합니다. 이점은 어디에 있습니까?
나는 이것이 이것이 유익하다고 생각하지 않습니다. 격리 된 상태에서 무언가를 변경할 수 있다는 것이 이론적으로는 좋은 것처럼 들릴 수 있지만, 변경 사항이 계약을 이행한다고해서 그것이 올바른 결과를 반환한다는 의미는 아닙니다. 올바른 결과가 무엇인지 결정하려면 컨텍스트가 필요하며 호출 코드에서 해당 컨텍스트를 가져옵니다.
음, 느슨하게 결합 된 앱은 유연성을 높이기 위해 모든 훌륭한 프로그래머의 궁극적 인 목표입니다. 개별적으로 변경 사항을 변경할 수 있다는 것은 환상적이며, 여전히 적절한 결과를 반환하는지 확인하는 단위 테스트입니다.
여러분 모두 화를 내기 전에 LINQ는 그 자리에 있으며 미래가 큽니다. 그러나 복잡하고 데이터 집약적 인 애플리케이션의 경우 스토어드 프로 시저를 대신 할 준비가되지 않았다고 생각합니다. 이것은 올해 TechEd에서 MVP에 의해 반향 된 견해였습니다 (그들은 이름이 남지 않을 것입니다).
편집 : LINQ to SQL 저장 프로 시저 측면은 여전히 더 읽을 필요가 있습니다-찾은 내용에 따라 위의 diatribe를 변경할 수 있습니다.)
LINQ는 새롭고 자리가 있습니다. LINQ는 저장 프로 시저를 대체하기 위해 발명되지 않았습니다.
여기서는 "LINQ to SQL"에 대한 성능 신화 및 CONS에 중점을 둘 것입니다. 물론 완전히 잘못되었을 수도 있습니다. ;-)
(1) 사람들은 LINQ 통계가 SQL 서버에서 "캐시"될 수 있으므로 성능을 잃지 않는다고 말합니다. 부분적으로 사실입니다. "LINQ to SQL"은 실제로 LINQ 구문을 TSQL 상태로 변환하는 런타임입니다. 따라서 성능 관점에서 하드 코딩 된 ADO.NET SQL 문은 LINQ와 차이가 없습니다.
(2) 예를 들어, 고객 서비스 UI에는 "계정 전송"기능이 있습니다. 이 함수 자체는 10 개의 DB 테이블을 업데이트하고 일부 메시지를 한 번에 반환 할 수 있습니다. LINQ를 사용하면 일련의 문을 작성하여 SQL Server에 일괄 처리로 보내야합니다. 이 변환 된 LINQ-> TSQL 배치의 성능은 저장 프로 시저와 거의 일치하지 않습니다. 이유? 내장 SQL 프로파일 러 및 실행 계획 도구를 사용하여 스토어드 프로 시저에서 명령문의 최소 단위를 조정할 수 있으므로 LINQ에서는이를 수행 할 수 없습니다.
요점은 단일 DB 테이블과 작은 데이터 CRUD 세트를 말할 때 LINQ가 SP만큼 빠릅니다. 그러나 훨씬 더 복잡한 논리의 경우 저장 프로시 저는 성능을 더 조정할 수 있습니다.
(3) "LINQ to SQL"은 초보자가 쉽게 성능 호그를 도입하도록합니다. 수석 TSQL 담당자는 CURSOR를 사용하지 않을 때 알려줄 수 있습니다 (기본적으로 대부분의 경우 TSQL에서 CURSOR를 사용해서는 안됩니다). LINQ와 쿼리가 포함 된 매력적인 "foreach"루프를 사용하면 초보자가 그러한 코드를 작성하는 것이 매우 쉽습니다.
foreach(Customer c in query)
{
c.Country = "Wonder Land";
}
ctx.SubmitChanges();이 쉬운 코드가 너무 매력적이라는 것을 알 수 있습니다. 그러나 .NET 런타임은 이것을 업데이트 배치로 변환합니다. 500 줄만 있으면 500 줄 TSQL 배치입니다. 백만 줄이 있다면 이것은 히트입니다. 물론 숙련 된 사용자는이 방법으로이 작업을 수행하지 않지만 요점은이 방법으로 넘어지기가 쉽다는 것입니다.
LINQ는 응용 프로그램 별 데이터베이스와 소기업에서 확실히 자리 잡고 있습니다.
그러나 중앙 데이터베이스가 많은 응용 프로그램의 공통 데이터 허브 역할을하는 대기업에서는 추상화가 필요합니다. 보안을 중앙에서 관리하고 액세스 기록을 표시해야합니다. 영향 분석을 수행 할 수 있어야합니다. 새로운 비즈니스 요구에 부응하기 위해 데이터 모델을 약간 변경하면 어떤 쿼리를 변경하고 어떤 응용 프로그램을 다시 테스트해야합니까? 뷰와 저장 프로 시저가 그 점을 알려줍니다. LINQ가이 모든 것을 할 수 있고 프로그래머를보다 생산적으로 만들 수 있다면 환영합니다. 누구나 이런 종류의 환경에서 사용해 본 경험이 있습니까?
DBA는 컴파일 된 코드를 변경하지 않고 데이터 모델을 자유롭게 변경할 수 없습니다. 스토어드 프로 시저를 사용하면 프로 시저에서 리턴 된 매개 변수 목록 및 결과 세트가 계약을 나타내며 해당 계약이 여전히 충족되는 한 내부 값을 변경할 수 있으므로 이러한 종류의 변경 사항을 범위에서 숨길 수 있습니다. .
나는 이것이 이것이 유익하다고 생각하지 않습니다. 격리 된 상태에서 무언가를 변경할 수 있다는 것이 이론적으로는 좋은 것처럼 들릴 수 있지만, 변경 사항이 계약을 이행한다고해서 그것이 올바른 결과를 반환한다는 의미는 아닙니다. 올바른 결과가 무엇인지 결정하려면 컨텍스트가 필요하며 호출 코드에서 해당 컨텍스트를 가져옵니다.
IMHO, RAD = LINQ, RUP = 저장 프로 시저 경영진을 포함한 여러 차원에서 수년 동안 대규모 Fortune 500 대 기업에서 근무했으며 솔직히 RUP 개발을 위해 RUP 개발자를 고용하지는 않았습니다. 그들은 다른 단계의 프로세스에서 무엇을해야하는지에 대한 지식이 매우 제한되어있다. 사일로 환경에서는 DBA가 매우 구체적인 진입 점을 통해 데이터를 제어하는 것이 합리적입니다. 다른 사람들은 솔직히 데이터 관리를 수행하는 가장 좋은 방법을 모릅니다.
그러나 대기업 은 개발 분야에서 고통스럽게 느리게 움직 이며 이는 매우 비용이 많이 듭니다. 시간과 비용을 모두 절약하기 위해 더 빨리 이동해야하는 경우가 있으며 LINQ는 그 이상을 스페이드로 제공합니다.
때로는 DBA가 업무 보안을 위협한다고 느끼기 때문에 LINQ에 대해 편향되어 있다고 생각합니다. 그러나 이것이 짐승, 신사 숙녀 여러분의 본성입니다.
나는 당신이 진짜로 procs와 함께 가야한다고 생각합니다.
A) linq에 모든 논리를 쓰면 응용 프로그램 만 사용할 수 있기 때문에 데이터베이스의 유용성이 떨어집니다.
B) 어쨌든 객체 모델링이 관계형 모델링보다 낫다고 확신하지 않습니다.
C) SQL에서 저장 프로 시저를 테스트하고 개발하는 것은 모든 Visual Studio 환경에서 컴파일 편집주기보다 훨씬 빠릅니다. 당신은 F5를 편집하고 select를 누르면 레이스에서 벗어납니다.
D) 어셈블리보다 저장 프로 시저를 관리하고 배포하는 것이 더 쉽습니다. 파일을 서버에 놓고 F5를 누릅니다.
E) Linq to sql은 예상치 못한 크 래피 코드를 작성합니다.
솔직히, 나는 MS가 t-sql을 보강하여 linq 가하는 것처럼 암시 적으로 조인 프로젝션을 수행 할 수 있다고 생각합니다. t-sql은 예를 들어 order.lineitems.part를 수행 하려는지 알고 있어야합니다.
LINQ는 저장 프로 시저 사용을 금지하지 않습니다. LINQ-SQL 및 LINQ-storedproc 과 혼합 모드를 사용 했습니다 . 개인적으로, 나는 저장된 procs를 쓸 필요가 없어서 기쁘다 .... pwet-tu.
또한 가능한 2.0 롤백 문제가 있습니다. 그것이 두 번 나에게 일어났다는 것을 믿어 라. 그래서 나는 그것이 다른 사람들에게 일어났다 고 확신한다.
또한 추상화가 최고라는 데 동의합니다. 사실과 함께 ORM의 원래 목적은 RDBMS를 OO 개념과 잘 일치시키는 것입니다. 그러나 OO 개념에서 약간 벗어나서 LINQ 이전에 모든 것이 제대로 작동했다면 나사를 조이십시오. 개념과 현실이 항상 잘 맞지는 않습니다. IT에는 무장 한 열광자가 없습니다.
Linq To Sql을 의미한다고 가정합니다.
CRUD 명령의 경우 저장 프로 시저와 모든 기술의 성능을 쉽게 프로파일 링 할 수 있습니다. 이 경우 두 가지의 차이점은 무시할 수 있습니다. 실제 차이가 있는지 알아 보려면 100,000 개의 선택 쿼리를 통해 5 (단순 유형) 필드 개체에 대한 프로파일 링을 시도하십시오.
반면에, 실제 거래 차단기는 비즈니스 로직을 데이터베이스에 편하게 배치 할 수 있는지 여부에 대한 질문이 될 것입니다. 이는 저장 프로 시저에 대한 논쟁입니다.
전문가에 따르면, 나는 LINQ를 오토바이로, SP를 자동차로 정의합니다. 짧은 여행을 가고 작은 승객 (이 경우 2) 만 가지고 싶다면 LINQ와 함께 우아하게 가십시오. 그러나 여행을 가고 싶어하고 큰 밴드를 원한다면 SP를 선택해야한다고 생각합니다.
결론적으로, 오토바이 또는 자동차 중에서 선택하는 것은 경로 (비즈니스), 길이 (시간) 및 승객 (데이터)에 따라 다릅니다.
그것이 도움이되기를 바랍니다. :디
LINQ를 향한 이러한 모든 답변은 주로 코딩의 품질 저하 또는 코딩의 게으름과 관련이있는 개발의 EASE에 대해 이야기하고 있습니다. 나는 그런 것뿐입니다.
몇 가지 장점이나 Linq는 여기에서 테스트하기 쉽고 디버깅하기 쉬운 것으로 읽었지만 최종 출력 또는 최종 사용자와 연결된 곳은 아닙니다. 이것은 항상 최종 사용자가 성능을 저하시키는 원인이됩니다. LINQ를 사용하여 메모리에 많은 것들을로드 한 다음 필터를 적용하는 요점은 무엇입니까?
다시 TypeSafety는 linq를 사용하여 개선하려는 품질이 좋지 않은 "잘못된 유형 캐스팅을 피하기 위해주의합니다"라는 경고입니다. 이 경우에도 데이터베이스에서 문자열 열의 크기와 같은 내용이 변경되면 linq를 다시 컴파일해야하며 .. 없이는 형식이 안전하지 않습니다.
비록 우리가 LINQ로 작업하는 동안 좋고 달콤하고 흥미로운 등을 발견했지만 개발자를 게으르게 만드는 전단 단점이 있습니다.
게으르지 마라. 열심히 노력하고 있습니다. :)
Create PROCEDURE userInfoProcedure
-- Add the parameters for the stored procedure here
@FirstName varchar,
@LastName varchar
AS
BEGIN
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT FirstName , LastName,Age from UserInfo where FirstName=@FirstName
and LastName=@FirstName
END
GOhttp://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx
LINQ와 SQL은 모두 자리를 차지합니다. 둘 다 단점과 장점이 있습니다.
때로는 복잡한 데이터 검색을 위해 저장된 procs가 필요할 수 있습니다. 때로는 다른 사용자가 Sql Server Management Studio에서 저장된 proc을 사용하기를 원할 수도 있습니다.
Linq to Entities는 빠른 CRUD 개발에 좋습니다.
물론 하나만 사용하여 앱을 만들 수 있습니다. 아니면 섞을 수도 있습니다. 그것은 모두 당신의 요구 사항에 달려 있습니다. 그러나 SQL에 저장된 procs는 곧 사라지지 않을 것입니다.