.NETs Select(Map)およびAggregate(Reduce)の命名の背後にある理由は何ですか?


17

他のプログラミング言語では、MapとReduceを見てきましたが、それらは関数型プログラミングの基礎です。LINQがAggregate(と同じReduce)およびSelect(と同じ)を持つ理由や歴史を見つけることができませんでしたMapか?

私が尋ねているのは、それが同じことだと理解するのに時間がかかったからです。そして、私はこの理由を知りたいのです。




一方、私は、選択の「マップ」と集計「リデュース」の命名の背後にある理由を知りたいと思っています。
デン

回答:


32

これは主にLINQの歴史に由来します。

LINQはもともと SQLに似たものであり、SQLデータベースに接続するために(主に、排他的ではありませんが)使用されていました。これにより、その用語の多くはSQLに基づいています。

だから、「選択」のSQLから来たselect声明、および「集約」は、SQL集約関数から来た(例えば、countsumavgminmax)。

LINQが元々SQLに関連していた程度に疑問を抱く人のために、MicrosoftのCωに関する記事を参照します。 C#および.NETに追加される前に出力されます。

たとえば、次のようなCωに関するMSDNの記事を考えてみましょう。

Cωのクエリ演算子

Cωは、C#言語に2つの広範なクラスのクエリ演算子を追加します。-
オブジェクトのメンバー変数を名前またはタイプでクエリするためのXPathベースの演算子。
-1つ以上のオブジェクトからのデータの投影、グループ化、結合を含む高度なクエリを実行するための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ライブラリファイル)として公開する必要があります。このアセンブリは、アプリケーションによって参照されます。リレーショナルデータベースは、sql2comega.exeコマンドラインツールまたはVisual Studio内から[ データベーススキーマ追加... ]ダイアログを使用して、マネージアセンブリとしてCωに公開できます。データベースオブジェクトは、サーバーによってホストされるリレーショナルデータベースを表すためにCωによって使用されます。データベースオブジェクトは、各表またはビューのパブリックプロパティ、およびデータベースで見つかった各テーブル値関数のための方法を有しています。リレーショナルデータベースをクエリするには、1つ以上のSQLベースの演算子への入力として、テーブル、ビュー、またはテーブル値関数を指定する必要があります。

次のサンプルプログラムと出力は、SQLベースの演算子を使用してCωのリレーショナルデータベースを照会する機能の一部を示しています。この例で使用するデータベースは、Microsoft SQL Serverに付属のサンプルNorthwindデータベースです。この例で使用されている名前DBは、sql2comega.exeを使用して生成されたNorthwind.dllアセンブリのNorthwind名前空間にあるデータベースオブジェクトのグローバルインスタンスを指します。

そのため、はい、最初から(またはあなたの視点によっては開始前でも)LINQは明示的にSQLに基づいており、特にSQLデータベースのデータへのアクセスを許可することを目的としていました。


5
SQLクエリ用にLINQが発明されたことには同意しません。LINQは、のクエリ操作に基づいており、これは古いHaskellの論文に基づいているX♯から順に継承されます。前述のHaskell論文の著者の1人はErik Meijerであり、彼はその後X♯とCωの設計にも携わり、もちろんLINQのデザイナーであることに注意してください。また、LINQを使用して、SQLだけでなく、あらゆる種類のクエリを実行できることは最初から明らかでした(1日目からLINQ-to-SQL、LINQ-to-XML、およびLINQ-to-Objectsに付属しています)続いて…
ヨルグWミットタグ

4
LINQ-to-Entities)、および実際にはクエリよりもはるかに多く(基本的には一般的なMonad Comprehension構文です)。SQL(およびXQuery)プログラマーになじみやすいように設計されていますが、それに限定されるものではありません。同様に、ScalaのMonad Comprehensionsはforループのように見え、HaskellのCスタイルの命令コードブロックのように見えるため、Scalaはモナド演算をflatMap呼び出し、Haskellはreturn同じ理由で呼び出します。(元)命令型プログラマ。
ヨルグWミットタグ

2
@JörgWMittag:編集済みの回答を参照してください。Microsoftのドキュメントが私の声明を裏付けていると思います。
ジェリーコフィン

3
希望的でウォッシュな推測の代わりに実際に答えを正当化するために+1。マイクロソフト自身よりも信頼できるソースを入手することはできません。
ミレニアムバグ

ありがとう、元気!これはまさに私が受け取ることを望んでいた種類の答えです。
Tx3

8

.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

2

私にとって、Select and Aggregateの方が理にかなっています。エンティティが.Netでデータをクエリおよび操作する主要な方法になると、Linqは、SQLを介してデータを操作することに慣れている開発者によってますます使用されています。そのため、これらの開発者にとっては「選択」などの単語を使用する方が理にかなっています。これは、それらが慣れ親しんでいるキーワードだからです。


4
「おそらくSQLを介してデータを操作することに慣れている開発者によってますます」私はこれを疑います。Entity Frameworkの賞賛を歌う私と一緒に仕事をしている人は、INNER JOINEntity Frameworkがオプションではなかったときに1日だけをやる必要があるとは考えられませんでした。おそらくまったく逆です。SQLの作成を積極的に避けているLINQを毎日使用する人が増えています。SQLに慣れている人は、おそらくSQLでもっと多くのことをするでしょう。
jpmc26

1
それは私が見たものではありません。主に私が見つけているのは(最近の求人検索で)ストアドプロシージャを使用してデータを操作したことがある開発者が、コントローラーですべてのスクリプトを実行し始めていることです。私にとっては、Linqが使い慣れた式を使用するのに役立ちます。それは「一緒に働く人」のケースだと疑いませんが、それは私の経験ではありません。
クリスティーン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.