.NETs Select (Map) 및 Aggregate (Reduce)의 이름을 짓는 이유는 무엇입니까?

다른 프로그래밍 언어에서는 Map and Reduce를 보았으며 기능 프로그래밍의 초석입니다. LINQ에 Aggregate(와 동일한 Reduce) 및 Select(와 같은 Map) 이유가없는 이유는 무엇입니까?

내가 묻는 이유는 그것이 똑같은 것임을 이해하는 데 시간이 걸렸으며 이것에 대한 추론이 무엇인지 궁금합니다.

.net language-design linq

— Tx3
소스

— gnat

친절하게 알려 주시기 바랍니다. 감사합니다.

— maple_shaft

반면에 나는 "Map"과 "Reduce"라는 이름을 짓는 이유를 알고 싶습니다.

— Den

이것은 대부분 LINQ의 역사에 달려 있습니다.

LINQ는 원래 SQL과 유사하게 만들어 졌으며 SQL 데이터베이스에 연결하는 데 주로 사용되었지만 독점적으로 사용되지는 않았습니다. 이로 인해 많은 용어가 SQL을 기반으로합니다.

그래서, "선택"은 SQL에서 온 select문, 및 "총은"SQL 집계 함수에서왔다 (예를 들어, count, sum, avg, min, max).

LINQ가 원래 SQL과 어느 정도 관련이 있는지에 대해 의문을 가진 사람들은 (예를 들어, Microsoft Research에서 고안 한 언어 인 Cω에 대한 Microsoft의 기사를 참조하고 LINQ의 기본 사항이 대부분 작동 한 것으로 보입니다. C # 및 .NET에 추가되기 전에

예를 들어, Cω에 대한 MSDN 기사에서 다음 과 같이 말합니다.

Cω의 쿼리 연산자

Cω는 두 가지 광범위한 클래스의 쿼리 연산자를 C # 언어에 추가합니다
.-이름 또는 유형별로 개체의 멤버 변수를 쿼리하기위한 XPath 기반 연산자.
-하나 이상의 개체에서 데이터를 투영, 그룹화 및 조인하는 복잡한 쿼리를 수행하기위한 SQL 기반 연산자.

적어도 내가 아는 한 XPath 기반 연산자는 C #에 추가되지 않았으며 문서화 된 (LINQ가 존재하기 전에) 연산자 만 SQL을 직접 기반으로하는 것으로 남겨 둡니다.

LINQ가 Cω의 SQL 기반 쿼리 연산자와 동일하지 않다는 것은 사실입니다. 특히 LINQ는 C #의 기본 개체와 함수 호출 구문을 Cω보다 훨씬 더 밀접하게 따릅니다. Cω 쿼리는 SQL 구문을 훨씬 더 밀접하게 따르므로 다음과 같이 작성할 수 있습니다 (위의 링크 된 기사에서 직접 작성).

 rows = select c.ContactName, o.ShippedDate
      from c in DB.Customers
      inner join o in DB.Orders
      on c.CustomerID == o.CustomerID;

그리고 같은 기사에서 SQL 기반 쿼리를 사용하여 실제 SQL 데이터베이스에서 오는 데이터를 쿼리하는 방법에 대해 구체적으로 설명합니다.

Cω에서 SQL 데이터베이스에 연결하려면 관리되는 어셈블리 (즉, .NET 라이브러리 파일)로 노출 된 다음 응용 프로그램에서 참조해야합니다. Visual Studio 내에서 sql2comega.exe 명령 줄 도구 또는 데이터베이스 스키마 추가 ... 대화 상자를 사용하여 관계형 데이터베이스를 관리되는 어셈블리로 Cω에 노출 할 수 있습니다 . 데이터베이스 오브젝트는 서버에서 호스트하는 관계형 데이터베이스를 나타 내기 위해 Cω에 의해 사용됩니다. 데이터베이스 객체는 각 테이블이나 뷰, 데이터베이스에있는 각 테이블 반환 함수에 대한 방법 공용 속성이 있습니다. 관계형 데이터베이스를 쿼리하려면 테이블, 뷰 또는 테이블 반환 함수를 하나 이상의 SQL 기반 연산자에 대한 입력으로 지정해야합니다.
다음 샘플 프로그램 및 출력은 SQL 기반 연산자를 사용하여 Cω에서 관계형 데이터베이스를 쿼리하는 기능 중 일부를 보여줍니다. 이 예제에서 사용 된 데이터베이스는 Microsoft SQL Server와 함께 제공되는 샘플 Northwind 데이터베이스입니다. 예제에서 사용 된 이름 DB는 sql2comega.exe를 사용하여 생성 된 Northwind.dll 어셈블리 의 Northwind 네임 스페이스에 있는 Database 개체의 전역 인스턴스를 나타냅니다 .

따라서 LINQ는 명시 적으로 SQL을 기반으로하며 특히 SQL 데이터베이스의 데이터에 액세스 할 수 있도록 의도되었습니다.

— 제리 관
소스

LINQ가 SQL 쿼리를 위해 발명되었다는 것에 동의하지 않습니다. LINQ는 Cω 의 쿼리 작업을 기반으로하며, 이는 이전 Haskell 용지를 기반으로하는 X♯에서 상속되었습니다. Haskell 논문의 저자 중 하나는 Erik Meijer이며, 그 이후 X♯와 Cω의 디자인에도 관여했으며 물론 LINQ의 디자이너이기도합니다. 그리고 처음부터 LINQ를 사용하여 SQL (LINQ-to-SQL, LINQ-to-XML 및 LINQ-to-Objects와 함께 제공되는 SQL)뿐만 아니라 모든 종류의 쿼리에 사용할 수 있다는 것이 분명했습니다. ... 다음

— 르그 W MITTAG

LINQ-to-Entities), 실제로는 쿼리 이상의 기능을 제공합니다 (기본적으로 일반적인 Monad Comprehension 구문). SQL (및 XQuery) 프로그래머 에게 친숙 하도록 설계 되었지만 이에 제한되지는 않습니다. 비슷한 맥락에서 Scala의 Monad Comprehensions는 for루프 처럼 보이고 Haskell은 C 스타일 명령 코드 블록처럼 보이기 때문에 Scala는 monadic 연산을 flatMap호출하고 Haskell return은 같은 이유로 : "환상"에 맞지 않는 것과 같은 이유로 호출합니다 . (이전) 명령형 프로그래머.

— Jörg W Mittag

@ JörgWMittag : 수정 된 답변보기. Microsoft 설명서가 본인의 진술을 뒷받침한다고 생각합니다.

— Jerry Coffin

소란스러운 추측 대신 답을 실제로 정당화하기위한 +1 Microsoft보다 훨씬 더 권위있는 소스를 얻을 수는 없습니다.

— milleniumbug

고마워요 이것은 내가 받기를 바랐던 종류의 대답입니다.

— Tx3

.Net의 LINQ 메소드

source.Where(x => condition)
      .Select(x => projection)

C # 및 VB.NET의 LINQ 쿼리 구문과 일치하도록 명명되었습니다.

from x in source
where condition
select projection

SQL을 아는 사람들에게 친숙하도록 설계되었습니다.

SELECT projection
FROM source x
WHERE condition

— 스빅
소스

나에게는 Select and Aggregate가 더 의미가 있습니다. .Net에서 데이터를 쿼리하고 조작하는 주체가 엔티티가됨에 따라 Linq는 SQL을 통해 데이터를 다루는 데 익숙한 개발자들에게 점점 더 많이 사용되고 있습니다. 따라서 "선택"과 같은 단어를 사용하는 것은 개발자에게 익숙한 키워드이기 때문에 개발자에게 더 적합합니다.

— 크리스틴
소스

"SQL을 통해 데이터를 다루는 데 익숙한 개발자들이 점점 더 많아지고 있습니다." Entity Framework의 칭찬을 부르는 사람과 함께 일하는 사람은 Entity Framework가 INNER JOIN옵션이 아니었을 때 하루 를해야한다고 생각할 수 없었습니다 . 아마도 그 반대 일 것입니다. 점점 더 많은 사람들이 SQL 작성 을 적극적으로 피하는 LINQ를 매일 사용 합니다. SQL에 익숙한 사람들은 아마도 SQL에서 더 많은 일을 할 것입니다.

— jpmc26

그것은 내가 본 것이 아닙니다. 주로 내가 최근에 구한 검색을 통해 내가 찾은 것은 한 번 저장 프로 시저를 사용하여 데이터 작업을 한 개발자가 컨트롤러에서 모든 스크립팅을 시작한다는 것입니다. 저에게는 Linq가 친숙한 표현을 사용하는 데 도움이됩니다. 나는 그것이 "당신과 함께 일하는 사람"의 경우라는 것을 의심하지 않지만, 그것은 내 경험이 아닙니다.

— Christine