Jakie jest uzasadnienie nazewnictwa .NETs Select (mapa) i agregacja (redukcja)?

17

W innych językach programowania widziałem Map and Reduce, a są to podstawy programowania funkcjonalnego. Nie mogłem znaleźć żadnego uzasadnienia ani historii, dlaczego LINQ ma Aggregate(to samo jako Reduce) i Select(to samo jak Map)?

Pytam, dlaczego zajęło mi trochę czasu, aby zrozumieć, że to to samo i jestem ciekawy, co jest tego powodem.

Tx3
źródło
Z drugiej strony chciałbym poznać uzasadnienie wyboru nazwy „Mapa” i agregacji „Zmniejsz” na początek.
Den

Odpowiedzi:

32

Sprowadza się to głównie do historii LINQ.

LINQ pierwotnie miał być podobny do SQL i był używany (w dużej mierze, choć nie wyłącznie) do łączenia się z bazami danych SQL. Prowadzi to do tego, że duża część terminologii jest oparta na SQL.

Tak więc, „wybierz” pochodzi z SQL selectoświadczenie i „agregat” pochodzi z SQL zagregowanych funkcji (na przykład count, sum, avg, min, max).

Dla tych, którzy kwestionują stopień, w jakim LINQ pierwotnie odnosi się do SQL, odsyłam do (na przykład) artykułów Microsoftu na temat Cω, który był językiem opracowanym przez Microsoft Research, i wydaje się, że tam, gdzie pracowała większość podstaw LINQ obecnie, zanim zostały dodane do C # i .NET.

Rozważmy na przykład artykuł MSDN na temat Cω , który mówi:

Operatory zapytań w Cω

Cω dodaje dwie szerokie klasy operatorów zapytań do języka C #:
- Operatory oparte na XPath do zapytań o zmienne składowe obiektu według nazwy lub typu.
- Operatory oparte na SQL do wykonywania skomplikowanych zapytań obejmujących wyświetlanie, grupowanie i łączenie danych z jednego lub więcej obiektów.

Przynajmniej o ile wiem, operatory oparte na XPath nigdy nie zostały dodane do C #, pozostawiając tylko te operatory, które zostały udokumentowane (zanim istniał LINQ) jako oparte bezpośrednio na SQL.

Teraz z pewnością jest prawdą, że LINQ nie jest identyczny z operatorami zapytań opartymi na SQL w Cω. W szczególności LINQ podąża za podstawowymi obiektami i wywołaniami funkcji języka C # znacznie bardziej niż Cω. Zapytania Cω podążały za składnią SQL jeszcze ściślej, więc możesz napisać coś takiego (ponownie, zaczerpnięte bezpośrednio z artykułu, do którego link znajduje się powyżej):

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

I tak, ten sam artykuł mówi konkretnie o używaniu zapytań opartych na SQL do zapytania danych pochodzących z rzeczywistych baz danych SQL:

Aby połączyć się z bazą danych SQL w Cω, musi być ona ujawniona jako zespół zarządzany (czyli plik biblioteki .NET), do którego następnie odwołuje się aplikacja. Relacyjna baza danych może być narażona na Cω jako zespół zarządzany za pomocą narzędzia wiersza polecenia sql2comega.exe lub okna dialogowego Dodaj schemat bazy danych ... w programie Visual Studio. Obiekty bazy danych są używane przez Cω do reprezentowania relacyjnej bazy danych hostowanej przez serwer. Obiekt bazy danych ma właściwość publiczną dla każdej tabeli lub widoku oraz metodę dla każdej funkcji o wartości tabeli znalezionej w bazie danych. Aby wysłać zapytanie do relacyjnej bazy danych, należy podać tabelę, widok lub funkcję o wartości tabeli jako dane wejściowe do jednego lub większej liczby operatorów opartych na SQL.

Poniższy przykładowy program i dane wyjściowe pokazują niektóre możliwości korzystania z operatorów opartych na SQL w celu przeszukiwania relacyjnej bazy danych w Cω. Baza danych użyta w tym przykładzie jest przykładową bazą danych Northwind dostarczaną z Microsoft SQL Server. Nazwą DB stosowany w tym przykładzie, odnosi się do globalnej przykład obiektu danych w Northwind przestrzeni nazw Northwind.dll zespół wytworzonej w sql2comega.exe .

Tak, tak, od samego początku (lub nawet przed początkiem, w zależności od twojego punktu widzenia) LINQ był wyraźnie oparty na SQL i miał na celu umożliwienie dostępu do danych w bazach danych SQL.

Jerry Coffin
źródło
5
Nie zgadzam się, że LINQ został wymyślony dla zapytań SQL. LINQ opiera się na operacjach zapytania w , które z kolei odziedziczyły je po X♯, który jest oparty na starym papierze Haskell. Zauważ, że jednym z autorów wspomnianych artykułów Haskella jest Erik Meijer, który później był również zaangażowany w projektowanie X♯ i Cω, i oczywiście jest projektantem LINQ. Od samego początku było jasne, że LINQ może być używany do wykonywania zapytań różnego rodzaju, nie tylko SQL (dostarczany z LINQ-to-SQL, LINQ-to-XML i LINQ-to-Objects od pierwszego dnia, wkrótce a następnie…
Jörg W Mittag
4
LINQ-to-Entities), a właściwie o wiele więcej niż zapytania (to w zasadzie ogólna składnia Monad Compstandingion ). Został on zaprojektowany do znajomości to SQL i XQuery) (programistów, ale z pewnością nie ogranicza się do tego. W podobnym duchu Scala's Monad Compthingions wygląda jak forpętle, a Haskell wygląda jak imperatywne bloki kodu w stylu C, a więc Scala nazywa swoją operację monadyczną flatMap, a Haskell nazywa to returnz tego samego powodu: aby dopasować się do „iluzji” uniemożliwiającej (byli) programiści imperatywni.
Jörg W Mittag
2
@ JörgWMittag: Zobacz zredagowaną odpowiedź. Uważam, że dokumentacja Microsoft popiera moje oświadczenia.
Jerry Coffin
3
+1 za faktyczne uzasadnienie odpowiedzi zamiast zgadywania. Nie można uzyskać bardziej wiarygodnego źródła niż same Microsoft.
milleniumbug
Dziękuję, proszę pana! To jest dokładnie taka odpowiedź, na jaką miałem nadzieję otrzymać.
Tx3
8

Metody LINQ w .Net

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

zostały nazwane, aby były spójne ze składnią zapytania LINQ w C # (i VB.NET)

from x in source
where condition
select projection

który został zaprojektowany, aby być zaznajomionym z osobami znającymi SQL

SELECT projection
FROM source x
WHERE condition
svick
źródło
2

Dla mnie Select and Aggregate ma większy sens. Ponieważ jednostka staje się dominującą metodą kwerend i danych w .Net, Linq jest coraz częściej wykorzystywany przez programistów, którzy prawdopodobnie są przyzwyczajeni do pracy z danymi przez SQL. Używanie słów takich jak „Wybierz” ma dla tych programistów więcej sensu, ponieważ są to słowa kluczowe, do których są przyzwyczajeni.

Christine
źródło
4
„coraz więcej deweloperów, którzy prawdopodobnie są przyzwyczajeni do pracy z danymi przez SQL” Wątpię w to. Facet, z którym pracuję, który śpiewa pochwały Entity Framework, nie mógł zrozumieć, że musiał zrobić INNER JOINjeden dzień, gdy Entity Framework nie byłaby opcją. Prawdopodobnie wręcz przeciwnie. Coraz więcej osób korzysta z LINQ codziennie, którzy aktywnie unikają pisania SQL. Ludzie, którzy znają się na SQL, prawdopodobnie robią więcej w SQL.
jpmc26,
1
Nie to widziałem. Głównie to, co znajduję (podczas mojego ostatniego poszukiwania pracy), to to, że programiści, którzy kiedyś pracowali z danymi przy użyciu Procedur składowanych, zaczynają wykonywać wszystkie swoje skrypty w kontrolerze. Dla mnie to pomaga, że ​​Linq używa znanych wyrażeń. Nie wątpię, że tak jest w przypadku „faceta, z którym pracujesz”, ale to nie jest moje doświadczenie.
Christine,