【VB.NET】LINQ友の会【C#, C♯, C#】

**デフォルトの名無しさん** · 2008/02/09(土) 23:51:34

VisualStudio2008より追加された便利で強力な機能

　　統合言語クエリ (LINQ : Language Integrated Query)

ちょっと使ってみると、意外と難しいし、テクニック的にも奥が深いものです。
関数型言語にしかないような機能ラムダ式(Lambda式)などはオブジェクト指向とは一味違う機能です。
DataBaseの操作にも、Xmlの操作にも、さらにもっと単純な配列なコンテナにさえ機能する
言語共通・高汎用な統合言語クエリを皆で一緒にマターリ勉強しましょう。
質問、便利なマイテクニックの発表、いろいろやっちゃってください。

**デフォルトの名無しさん** · 2008/02/21(木) 01:06:41

LINQでWin32のメッセージマップって書けないの？

**デフォルトの名無しさん** · 2008/02/21(木) 01:43:02

C++/CLI には無いの?

**デフォルトの名無しさん** · 2008/02/21(木) 07:12:47

>>85
遅くなるというのは１件あたりの処理時間が増えるということかな？
それだったらCompact Editonなのが影響してるのかもしれない。
2005Expressで実行してみたらどうだろう。

db.SubmitChanges(); は5000件まとめての方が速いと思う。
メモリがきついようなら500件くらいまとめてで。

**デフォルトの名無しさん** · 2008/02/21(木) 08:46:06

>>88
百件のインサートごとにその間にかかった時間を書いてるんですが、それがリニアに増えてきます。
Express　or　Serverで試してみます。

実際の実行時はまとめたほうがよさげですね。

**デフォルトの名無しさん** · 2008/02/21(木) 10:05:01

>>85のソースから
> protected string SetAndReturnDifferenceTimeString() {
> int current = Environment.TickCount;
> int lastDiff = current - _last;
> _last = current;
> return "[" + lastDiff + "]";
> }
> public void WriteLine(string message) {
> Console.WriteLine(message + " " + SetAndReturnDifferenceTimeString());
> }
> public void WriteLine(string message, params object[] args) {
> WriteLine(string.Format(message, args));
> }

100件毎に実行されるのってWriteLine(string message, params object[] args)じゃね？
最近プログラミングしてないんで間違ってたらｽﾏｿ

**デフォルトの名無しさん** · 2008/02/21(木) 10:13:41

>>90
下のWriteLine()の中で上のを呼んでる。

**デフォルトの名無しさん** · 2008/02/22(金) 00:11:14

>>1 です
クエリ式はとりあえず放って置いて、メソッドでしか表現できないタイプのものを解説してみようと思っているのですが
まずは一発目で Aggregate あたりからやってみようかと思ってます。
ただ、このメソッドあまりにも関数型言語らしい仕様をしています。
何か良い説明方法はないかと色々さがしているのですが、良いのがあったら誰か紹介してください。
http://d.hatena.ne.jp/blanketsky/20071129/1196329379
とりあえず、この辺りとか見てみたのですが……
こんなの見せられたら初心者さん気絶するよなとか思いつつ、何かいいのはないかなと……

**デフォルトの名無しさん** · 2008/02/22(金) 00:32:05

>>92
forループからの置き換えで解釈してみては。

int sum = 0;
for (int i = 1; i <= 100; i++) {
　　sum += i;
}

これをAggregateで記述するとどうなるか、とか。

85 · 2008/02/22(金) 00:39:59

Comapctでまとめて実行するようにしたらリニアに増加するのはなくなった様。
10000件ぐらいまではまとめたほうがトータルの実行時間が短くなった。
もっと多くした場合はどうなるかは今度試します。
ほかのデータベース試してないけれど、なんかCompactのせいっぽい匂いが・・・

**デフォルトの名無しさん** · 2008/02/22(金) 01:20:37

>>92
その情熱がどこから来るのかわからんが、Aggregateなら
・sum、factあたりを通常の再帰関数で書く
・共通する部分を抜き出す
・これがAggregateです
っていうのがわかりやすいんじゃないの？

**デフォルトの名無しさん** · 2008/02/22(金) 11:23:52

>>92
http://ufcpp.net/study/csharp/sp3_stdqueryo.html#aggregate

**デフォルトの名無しさん** · 2008/02/22(金) 19:46:15

クエリ式はきもいけどLINQ自体はないと生きていけんよ
コレクションに対するアルゴリズムは絶対に必要だ
XMLやSQLは別になくても生きていけるとは思うが

**デフォルトの名無しさん** · 2008/02/22(金) 22:13:52

>>92

**デフォルトの名無しさん** · 2008/02/23(土) 01:08:33

>>1 です
>>93 結局ループをどの様に書くかという問題なのだからそれが一番いいような気がしました。
それと、これは群論の本(数学の本です)を読んでいて、抽象化は具体例を限りなく沢山作ってその中から共通の物を取り出すことだという記述があって
それも考慮にいれて、まず具体例、それからループへと展開する方針でいってみようと思います。

>>95
申し訳ないですが、再帰は最終手段だと思います、非常に良くないと思います。それ以外の部分は賛成です。
再帰とラムダ(or Delegate)は絶対に最初に記述して説明してはならないものだと確信しています。

>>96
>http://ufcpp.net/study/csharp/introduction.html
>実を言うと、僕は趣味でプログラミングをしてるだけで、 C# は研究とは一切関係なかったりします。
>（むしろ C/C++ を使うことが多かった。 2007年追記：最近では割となんでも C# で書くようになりました。）
>初めて C# について調べてみたとき(ちょうど Java に物足りなさを感じ、SUNの方針に憤りを感じていたころです)、
> C# が普及してくれればプログラミングにかかる手間は大幅に削減されると感じるました。
>しかし、Microsoft は順調に行かなさそうなものはばっさりと切り捨てることで有名な企業ですし、
>世間の C# への関心が低ければ、C# は普及することなく消え去ってしまうでしょう。
>そこで、少しでも早く C# が普及するようにとの願いを込めて当コンテンツを作成することにしました。
実は自分も全く同じ境遇です、でも研究者じゃありません、ただのプログラマですが……
関数型言語をやっていて思うところで、こんなの一発なのにというコードがオブジェクト指向のスタイルでは全くまともにかけなくて歯がゆい思いをしていました。

今日からお休みなので、これから練ってみます、明後日辺りから書き始めるかもしれません。

**デフォルトの名無しさん** · 2008/02/23(土) 01:09:33

しかし、http://msdn2.microsoft.com/ja-jp/library/bb549218.aspx
これをみて理解できる人間が一体何人いるんだろうか……

Aggregate<(Of <(TSource, TAccumulate>)>)(IEnumerable<(Of <(TSource>)>), TAccumulate, Func<(Of <(TAccumulate, TSource, TAccumulate>)>))
この表現からぱっと見た目に使い方がわかる人は一体何人いるんだろうと、首を傾げそうになります。
ドキュメントのつくりを一度見直すべきだと思う……強力なのに……

>世間の C# への関心が低ければ、C# は普及することなく消え去ってしまうでしょう。
こんな状態になって欲しくないです
これを使えば、エクセルで小計等をやるような操作を一行で書き下せますが、使える人が居なくなってしまう。

**デフォルトの名無しさん** · 2008/02/23(土) 01:22:13

C++にBoostその他の取り合わせなんか、正にそんな世間の関心が低い状態。
LINQもそういうことになってしまうのは嫌だな。

**デフォルトの名無しさん** · 2008/02/23(土) 02:31:52

一応世間に知られてからもう大分経つでしょ・・・
これ流行らないよ・・・
from　の位置とか外人さんでも気持ちわるいんじゃないかな

95 · 2008/02/23(土) 02:36:28

>>99
あー、ごめん、関数型言語とごっちゃになってた。
C#なら95の最初の手順を
・sum、factあたりを通常の関数で書く
でいいな。確かに再帰とかいらない。

蛇足ですが、あなたの対象とする「初心者」像がいまいちわからないのが
少し気になります。

**デフォルトの名無しさん** · 2008/02/23(土) 03:22:34

>>102
発売後15日にして大分経っていたのか、それはショックだw
ごみレスつけるな、よそ行けよ

**デフォルトの名無しさん** · 2008/02/23(土) 10:15:51

Selectが X->Y のマップになってるのはちょっと名前がわかり辛くて見つけられなかったな
duck typing(?)とかいう手法で Map :: X[] -> (X -> Y) -> Y[] を作っちゃった

拡張性も結構あるしガクジュツ的ではなくちゃんと実務に沿って開発しやすくなるような言語拡張だからLINQは流行ると思う

**デフォルトの名無しさん** · 2008/02/23(土) 13:41:16

Enumerable.ForEachがほしい

**デフォルトの名無しさん** · 2008/02/23(土) 14:51:39

要望出してSP1に入れさせようぜ

**デフォルトの名無しさん** · 2008/02/23(土) 14:52:38

>>106　自分で作りなはれ。自分は作った。

**デフォルトの名無しさん** · 2008/02/23(土) 14:56:38

晒して

**デフォルトの名無しさん** · 2008/02/23(土) 15:10:50

void ForEach<T>(this IEnumerable<T> source, Action<T> action) {
　foreach(T item in source) action(item);
}
ただこれだけのことだけど
こんなことしちゃうとコード全体がガラッと変わるから非公式にやるのは抵抗がある

**デフォルトの名無しさん** · 2008/02/23(土) 15:17:25

なんでもかんでも一行でやろうとするのはC#的じゃないだろ
foreachぐらい分けて書こうぜ

**デフォルトの名無しさん** · 2008/02/23(土) 15:42:04

http://www.microsoft.com/japan/msdn/net/bb394939.aspx

ヘジ自ら書いてる
これが俺のバイブル

**デフォルトの名無しさん** · 2008/02/23(土) 16:44:36

foreachのみで簡潔に書けるものはforeachのみで良いと思います

foreach( var row in table ) 文 ;

これ以上何かをする必要はないだろうと思う、逆にややこしいだけだし。

はなしは変わって、http://ufcpp.net/study/csharp/sp3_stdqueryo.html#aggregate によると
>　でも、メソッド提供だけでは、 join や let などがどうしてもきれいに表現できなかったので、
<やむなく SQL 風のクエリ式を導入したそうです。
>（プログラミング言語の中に別に言語を埋め込むというのはデメリットも大きくて、
>言語制作者にとっては結構ためらわれる行為。）
>（join や let をきれいに書くためには、どうしても透過識別子のような考え方が必要だった。）
という事らしいのですが、私は、むしろ逆で、これを見た瞬間λ式消滅、これは素晴らしい！！
と思ったものなんですが……
"Language Integrated" Query というぐらいですから、最初こちらがあったのだと想像していのですが逆だったんですね。
foreach にはλ式は登場しないので十分だと思っています。

**デフォルトの名無しさん** · 2008/02/23(土) 16:47:27

デザイナを使っているとdelegateやeventなんて全然意識しやいじゃないですか
ダブルクリックすれば勝手にコード登場となって、こういうややこしいものは後回しにして使い方を最初に知ることができる。
これがC#の良い点だと思うんですよ。

**デフォルトの名無しさん** · 2008/02/23(土) 16:50:49

List<T>やArrayにはForEachがあるだろ
匿名メソッドよりも，普通のメソッドを直接渡すときに気持ちいいんだよね
list.ForEach(Console.WriteLine);みたいに
初めてみたときはびっくりしたけど

**デフォルトの名無しさん** · 2008/02/23(土) 16:59:23

普通にプログラミングしててもSelectやWhereは腐る程出てきて
それらを書くぶんにはクエリ式でなく拡張メソッド+ラムダ式の方がシンプルに書ける
ラムダ式は他にもプログラミングのあらゆる局面で使うと便利なことが多い
対してクエリ式はSelectManyやJoinなんかで使うとシンプルに書けるけど
そんなん滅多に使わん

**デフォルトの名無しさん** · 2008/02/23(土) 17:43:25

遅延評価のせいで，一旦必要な部分を評価しないといけないのか・・・

new[] { 1, 2, 3, 4, 5 }.Select(
    x => {
        Console.WriteLine(x);
        return x;
    }
).ToArray();

**デフォルトの名無しさん** · 2008/02/23(土) 18:06:36

遅延評価の問題すっかり忘れてた、あんまり意識する必要無いとおもったけど、デバッグ時にも面倒が起りますね。
あなたがその値を見るまでは値は計算されていませんって、まるでシュレディンガーの猫のような現象がありました。

**デフォルトの名無しさん** · 2008/02/23(土) 18:24:47

普通に書いたらええがな

**デフォルトの名無しさん** · 2008/02/23(土) 18:29:18

.ToList().ForEach(Console.WriteLine) でいいじゃん

**デフォルトの名無しさん** · 2008/02/23(土) 18:30:33

ToList超きもい

**デフォルトの名無しさん** · 2008/02/23(土) 18:32:42

遅延評価はLINQだと実態があいまいになりがちだがHaskellを使うと、なんというかテツガクしたくなる。
ものすごく面白いが、万人にお勧めではない。

**デフォルトの名無しさん** · 2008/02/23(土) 18:35:44

IEnumerable<>でforeachするときの例っぽいの書こうとした＾ｐ＾

**デフォルトの名無しさん** · 2008/02/27(水) 19:00:07

>>1 です
　ちょっとスタイル変更、くだすれC#だと、配列よりも List クラスの方が需要ありそうだったので。
　実際、実用上は配列って事はありえない気がしますし。
　名前は全部漢字にして、型名には末尾に"型" と付けてみました。

**デフォルトの名無しさん** · 2008/02/27(水) 19:00:49

Q.売上表で小計をもとめるような計算をしたい(1)
　Aggregate が便利です。
　以下の例では、合計原価と合計売価を求めます。解りやすさ優先で、型をすべて書ききったバージョンです。

　System.Collections.Generic.List<売上帳の行型> 売上帳 = new System.Collections.Generic.List<売上帳の行型>();
　売上帳.Add(new 売上帳の行型() { 品名 = "デスクトップPC", 数量 = 1, 原価 = 100000, 売価 = 120000 });
　売上帳.Add(new 売上帳の行型() { 品名 = "ノートPC", 数量 = 2, 原価 = 250000, 売価 = 280000 });
　// お試し表示
　dataGridView1.DataSource = 売上帳;
　// 合計の計算方法
　合計型合計の初期値 = new 合計型() { 合計原価 = 0, 合計売価 = 0 };
　合計型合計表 = 売上帳.Aggregate(
　　合計の初期値,
　　(合計型直前の合計, 売上帳の行型行) => new 合計型() { 合計原価 = 直前の合計.合計原価 + 行.数量 * 行.原価, 合計売価 = 直前の合計.合計売価 + 行.数量 * 行.売価 }
　　);
　dataGridView2.DataSource = new 合計型[] { 合計表 };

　public class 売上帳の行型 {
　　public string 品名 { get; set; }
　　public int 数量 { get; set; }
　　public int 原価 { get; set; }
　　public int 売価 { get; set; }
　}
　public struct 合計型 {
　　public int 合計原価 { get; set; }
　　public int 合計売価 { get; set; }
　}

**デフォルトの名無しさん** · 2008/02/27(水) 19:01:50

>>125の続き　売上表で小計をもとめるような計算をしたい(2)
省けそうな型名は省略したバージョンです

var 売上帳 = new System.Collections.Generic.List<売上帳の行型>();
売上帳.Add(new 売上帳の行型() { 品名 = "デスクトップPC", 数量 = 1, 原価 = 100000, 売価 = 120000 });
売上帳.Add(new 売上帳の行型() { 品名 = "ノートPC", 数量 = 2, 原価 = 250000, 売価 = 280000 });
// お試し表示
dataGridView1.DataSource = 売上帳;
// 合計の計算方法
var 合計表 = 売上帳.Aggregate(
　new { 合計原価 = 0, 合計売価 = 0 },
　(直前の合計, 行) => new { 合計原価 = 直前の合計.合計原価 + 行.数量 * 行.原価, 合計売価 = 直前の合計.合計売価 + 行.数量 * 行.売価 }
　);
dataGridView2.DataSource = new[] { 合計表 };

**デフォルトの名無しさん** · 2008/02/27(水) 19:03:01

>>126の続き　売上表で小計をもとめるような計算をしたい(3)
上記のコードが何をしているのかといいますと、以下のコードのような処理をしています。

var 売上帳 = new System.Collections.Generic.List<売上帳の行型>();
売上帳.Add(new 売上帳の行型() { 品名 = "デスクトップPC", 数量 = 1, 原価 = 100000, 売価 = 120000 });
売上帳.Add(new 売上帳の行型() { 品名 = "ノートPC", 数量 = 2, 原価 = 250000, 売価 = 280000 });
// お試し表示
dataGridView1.DataSource = 売上帳;
// 合計の計算方法
var 直前の合計 = new { 合計原価 = 0, 合計売価 = 0 };
foreach (売上帳の行型行 in 売上帳)
{
　直前の合計 = new { 合計原価 = 直前の合計.合計原価 + 行.数量 * 行.原価, 合計売価 = 直前の合計.合計売価 + 行.数量 * 行.売価 };
}
dataGridView2.DataSource = new[] { 直前の合計 };

**デフォルトの名無しさん** · 2008/02/27(水) 19:04:24

>>127の続き　売上表で小計をもとめるような計算をしたい(4)
これを使うと簡単になるケース
合計型と売上帳の行型が同じなら、コードは単純になります

var 売上帳 = new System.Collections.Generic.List<売上帳の行型>();
売上帳.Add(new 売上帳の行型() { 品名 = "デスクトップPC", 数量 = 1, 原価 = 100000, 売価 = 120000 });
売上帳.Add(new 売上帳の行型() { 品名 = "ノートPC", 数量 = 2, 原価 = 250000, 売価 = 280000 });
// 合計の計算
var 合計行 = 売上帳.Aggregate((直前の合計, 現在の行) => new 売上帳の行型() { 原価 = 直前の合計.原価 + 現在の行.数量 * 現在の行.原価, 売価 = 直前の合計.売価 + 現在の行.数量 * 現在の行.売価, 品名 = "合計" });
売上帳.Add(合計行);
// お試し表示
dataGridView1.DataSource = 売上帳;

**デフォルトの名無しさん** · 2008/02/27(水) 19:05:23

まとめ
駄目だ、どうあがいても単純になりません。
3 番目を書いてみたら、foreach で書いたほうが見通しがよさそうな感じすらしてきます。
綺麗になるのは、アキュムレーターの型とコンテナ要素の型が一致しているとき
もしくはアキュムレーターの型が int のような単純型で有る場合に限られます。
メソッド方式にはやはり何かが足りない感じがします。
LINQの新規キーワードとして、それも foreach をイメージできるような構文にして
"aggregate 売上帳" と書いたら、型名、その他をインテリセンスがズバズバッと書き出して、
作る側は中身をを書くだけといった具合になれば使えそうな気がするのですが……
もしくは Excel の、式のコピーのようなイメージができれば、やる事は一番上の式を書く事となるのですが。

**デフォルトの名無しさん** · 2008/02/28(木) 02:02:30

ところでこのコードってVB?

**デフォルトの名無しさん** · 2008/02/28(木) 11:52:14

驚くべきことに今まで一行もVBのコードは出てきていないんだ

**デフォルトの名無しさん** · 2008/02/28(木) 12:47:55

ほいじゃVB版Linq for XML
XMLリテラルが売りですのじゃ
Dim xm = <AAA>
  <BBB id="1">aaaaacxzc</BBB>
  <BBB id="2">aaaaaxczx</BBB>
  <BBB id="3">aaaaaxcxz</BBB>
  <BBB id="4">aaaaaxczx</BBB>
  <BBB id="5">aaaaaxxxx</BBB>
  <BBB id="6">aaaaazzzz</BBB>
  <BBB id="7">aaaaacccc</BBB>
  <BBB id="5">aaaaaxxxx</BBB>
  <BBB id="6">aaaaazzzz</BBB>
  <BBB id="7">aaaaacccc</BBB>
</AAA>
Dim rs = From x In xm...<BBB> _
  Where x.@id > 2 _
  Distinct Skip 1 Take 3 _
  Order By x.@id Descending _
  Select ID = x.@id, x
For Each r In rs
  Console.WriteLine(r)
Next

**デフォルトの名無しさん** · 2008/02/28(木) 13:15:08

クエリ式はC#よりVBの方が馴染んでるよなあ
VBのラムダ式は糞だけど

**デフォルトの名無しさん** · 2008/02/28(木) 17:54:04

>>129
AggregateはSumやMaxと同じで集合関数として使うように設計されてるので
group by と組み合わせて使うのが普通なのだと思う。
この例だとSumが使えるのだがAggregateを使ってみた。
var 合計表 = (
  from uri in 売上帳
  group uri by 1 into g
  select new 合計型(){
     合計原価 = g.Sum(o => o.原価 * o.数量),
     合計売価 = g.Aggregate(0, (t,o) => t + o.売価 * o.数量)
  }).First();
Console.WriteLine("{0}, {1}", 合計表.合計原価, 合計表.合計売価);

**デフォルトの名無しさん** · 2008/03/07(金) 01:17:17

C#なんだから大概の物は関数型チックにかくより普通に書いた方が
見やすいのは当たり前

**デフォルトの名無しさん** · 2008/03/07(金) 11:55:15

Expression Treeってフィールドの値を変更できないのか
できたらおかしいのはわかるけどDynamicMethodの簡易版として使うには貧弱だな

**デフォルトの名無しさん** · 2008/03/07(金) 12:01:30

>>136
そういう用途だと、LINQ の Expression から DLR の AST Expression に変換してしまうのがいいかも。

**デフォルトの名無しさん** · 2008/03/07(金) 17:40:05

LINQってDataTableに対してグループ化をしてDataGridViewに表示したり出来るんですかね？
現在、DataTableに対してグループ化ってかなり無理矢理やらないと出来ないと思うんですが、
これができると、DataTableがかなり使いやすくなりそうです。
.NET3.5をインストールさせる動機になりそうなくらい・・・

**デフォルトの名無しさん** · 2008/03/12(水) 12:24:53

みんな小難しいことばっかやってて、なんとなくLinq避けてたが、
実際に使ってみるとなかなかスイーツ(笑)な簡単さじゃないか。
List<T>なんか作って追加していって最後にToArray()してるようなのも
Linqで書き換えたら全部一行に出来そうだ。

**デフォルトの名無しさん** · 2008/03/13(木) 01:52:23

あれ？出勤、昼だか夜だかわからなくね？

**デフォルトの名無しさん** · 2008/03/13(木) 11:30:56

VB.NETもスレタイの仲間に入れてあげてください。

**デフォルトの名無しさん** · 2008/03/13(木) 13:24:30

VB.NETは新機能が全く話題にならないよな

**デフォルトの名無しさん** · 2008/03/13(木) 15:06:20

>>142
むしろ新機能はLINQ以外にあったっけか？
まぁ銀光とかあるけど

**デフォルトの名無しさん** · 2008/03/13(木) 15:07:51

宣言時の型推論，ラムダ式とか？

**デフォルトの名無しさん** · 2008/03/13(木) 15:16:04

Xmlリテラルとか。

**デフォルトの名無しさん** · 2008/03/13(木) 15:18:19

C#2.0+C#3.0+αだな

**デフォルトの名無しさん** · 2008/03/13(木) 16:24:25

ぶっちゃけXML生書き出来るようになったからって・・・
使う奴っている？

今一歩使い道が見つからん・・・

**デフォルトの名無しさん** · 2008/03/13(木) 21:19:44

>Xmlリテラル

タイミング良くっつーかこんな記事がでてるね。

.NETプログラマーにとって、XSLTは終焉なのか?
ttp://www.infoq.com/jp/news/2008/03/XML-Literals

>XML Literalsは最初Haskell向けに開拓され、
>のちにMicrosoftにおいてC#で使用するために開発された。
>どちらの言語においてもうまくいかないことが判明したので、
>Visual Basicチームが飛び付いて、VB 9の礎石にした。

>これはそれほどまでに驚くことではない。
>というのもHaskell構文がVBScriptのインラインHTML表記の影響を
>もろに受けていたからである。

まあヘジたんなら拒否るだろし、事実拒否ったんだろうなぁ。

**デフォルトの名無しさん** · 2008/03/14(金) 22:40:14

テーブル値関数をLinq to SQLで利用しようとしてるんだけど、
実行したら、
ストアドプロシージャはクエリ内では使用できない。ってエラーになるんだよ。
これバグじゃないかな。

**デフォルトの名無しさん** · 2008/03/15(土) 00:46:01

自己解決しました。ﾉｼ
IsComposable=true　がなかったのが原因みたいです。
なんだかなあ。
　

**デフォルトの名無しさん** · 2008/04/06(日) 03:35:46

保守

**sage** · 2008/04/13(日) 01:33:35

LINQでのサブクエリの書き方が分からん。どう書くの？

SELECT
　A.KEY1, A.COL1, B.COL2
FROM
　(
　　(SELECT * FROM TBL1) A
　　INNER JOIN
　　(SELECT * FROM TBL1) B
　　ON B.KEY1 = A.KEY1
　)

**デフォルトの名無しさん** · 2008/04/13(日) 02:32:31

そのままlinqに置き換えれば

var r =
　from i in
　　(from a in TBL1
　　 from b in TBL2
　　 where a.KEY1 == b.KEY2
　　 select new { A = a , B = b })
　select new { KEY1 = i.A.KEY1 , COL1 = i.A.COL1 , COL2 = i.B.COL2 };

こんな感じだけど、この例だとサブクエリ必要なくね？

**デフォルトの名無しさん** · 2008/04/13(日) 02:36:53

>>152
それ、LINQ だとサブクエリ要らない。

var q =
　from a in tbl1
　join b in tbl2 on a.Key equals b.Key
　select new { a.Key, a.Col1, b.Col2 };

サブクエリは普通に ↓ みたいに書ける。
from a in
　from b in list
　select b.SomeProperty
select a.SomeProperty

**デフォルトの名無しさん** · 2008/04/13(日) 14:50:18

そんなことしなくても
保守が容易な綺麗なコードを書けるから
(ﾟ⊿ﾟ)ｲﾗﾈ

**デフォルトの名無しさん** · 2008/04/13(日) 16:44:19

最近LINQ初めて>>22見たんだけど、
コードが見通しよく整理されていく中盤からの展開は見てて痛快だなぁ

**デフォルトの名無しさん** · 2008/04/24(木) 21:22:23

http://code.msdn.microsoft.com/vlinq

**デフォルトの名無しさん** · 2008/04/24(木) 21:41:48

>>157
Visual LINQ Query Builder

VS2008用のアドインか

**デフォルトの名無しさん** · 2008/05/24(土) 20:45:08

Ｌｉｎｑで書くと速くならないなら需要ないんじゃない
ＳＱＬでおなかいっぱいで

**デフォルトの名無しさん** · 2008/05/24(土) 21:01:08

>>159
LINQ の価値は速度じゃなくて、
OOP パラダイムと RDB パラダイムの懸け橋になること。
SQL でおなかいっぱいって人にこそ LINQ がいいんじゃないか。

**デフォルトの名無しさん** · 2008/05/24(土) 23:11:23

パラ？
お母さんが子供に教えるように教えてください

**デフォルトの名無しさん** · 2008/05/24(土) 23:23:16

>>161
C# の中で、オブジェクト指向言語の感覚からあまり外れることなく、
データベース問い合わせが書けるってことが大事。

**デフォルトの名無しさん** · 2008/05/25(日) 00:22:26

最初は書き方に戸惑うが、だいたいの書き方がわかってくればインテリセンス使えるのがとても大きい

**デフォルトの名無しさん** · 2008/05/25(日) 04:39:07

コンパイラによる構文チェックが行われるというのも大きい。
条件次第で内容が大きく変わるようなクエリを構成するときに、文字列の連結を間違えて
バグを作り込んでしまうような、つまらないミスを防げる。
DataContextの定義にあわせて自動でCREATE DATABASEしてくれるとか、生産性の向上に
つながる要素がいろいろあるよ。
俺もほとんど把握してないけどさ。

**デフォルトの名無しさん** · 2008/05/25(日) 09:04:21

SQLって、汎用コレクションデータ処理エンジンだね。
C/C++やらで何らかのデータ処理を行う場合、その度毎にアルゴリズムを考え、設計し、
コードを作りこまなくちゃいけないけど。
RDBだと、ちょこっとSQLを定義するだけで実際の処理はRDBのエンジンがやってくれる。
例えるなら文字列の正規表現みたいな感じで。

それが言語組み込みの文法として、RDBだとDBサーバを立て、テーブルを作り、データをインポートして
からじゃないと使えないのが、RDBに限らずC#言語上の任意のコレクションデータで使えてしまう
ってのは便利。

**デフォルトの名無しさん** · 2008/05/25(日) 09:41:44

>>161
インピーダンスミスマッチでぐぐれ

**デフォルトの名無しさん** · 2008/05/25(日) 11:12:57

SQLMetalってすでにあるテーブルのオブジェクト定義のXMLを生成するものだよね？
逆に今あるオブジェクトからテーブルとかを生成するツールってあったっけ？

**デフォルトの名無しさん** · 2008/05/25(日) 14:02:32

>>167
方法 : データベースを動的に作成する (LINQ to SQL)
http://msdn.microsoft.com/ja-jp/library/bb399420.aspx

**デフォルトの名無しさん** · 2008/05/25(日) 14:39:10

>>161
これでも読め
http://www.microsoft.com/japan/msdn/net/bb425822.aspx

**デフォルトの名無しさん** · 2008/06/02(月) 22:49:47

Linq人気ないから救済でAgeてやる
感謝しろビル

**デフォルトの名無しさん** · 2008/06/04(水) 08:38:01

PL/SQLですね。

**デフォルトの名無しさん** · 2008/06/09(月) 11:06:00

http://pc11.2ch.net/test/read.cgi/tech/1212972014/

**デフォルトの名無しさん** · 2008/06/15(日) 19:33:30

えーい
Linqも人気ないけど
ダメ技術のかほりがすっぞ

**デフォルトの名無しさん** · 2008/06/17(火) 02:07:55

使ったからといって、別に何かが楽になったりすっきりしたりするように見えないんだよな。

**デフォルトの名無しさん** · 2008/06/17(火) 07:25:18

ちょっとしたDBアプリ作るの楽になるが。
XMLとかにもいいと思うよ。

**デフォルトの名無しさん** · 2008/06/17(火) 21:00:53

メソッド形式は手軽に使えてすごく便利だよね
クエリ形式は「さあLINQ使っちゃうぞー」って感じになっちゃって好きじゃない

**デフォルトの名無しさん** · 2008/06/17(火) 22:19:07

未だにクエリ式だとｐとかｑとかのスコープがよくわかってない俺。

**デフォルトの名無しさん** · 2008/06/18(水) 03:55:30

fromやletが沢山必要になる場合は
クエリ式を使ってる

けど、それ以外ではクエリ式は全然使ってない

**デフォルトの名無しさん** · 2008/06/19(木) 22:35:19

使い方も確立されてない未知のもんだからな。
ポテンシャルは高い気がする。

**デフォルトの名無しさん** · 2008/06/20(金) 00:55:26

LINQきれいにかけるけれど、特にObjectLINQだと効率的にはだめな場合もあるからなぁ。
微妙なところだ。
PLINQとかになるとまた話は違うだろうけれど。

**デフォルトの名無しさん** · 2008/06/20(金) 08:43:29

>>180
from x in a select x; みたいなのを foreach(var x in a) yield return x; に変えるような
最適化だとせいぜい5％くらいしかスピード変わらない。
5％を気にしないといけない場面はそれほど多くないと思う。

ただ、a.Max(), a.Min(), a.Count() を同時に求めたいような場合、
自前で for まわして同時に求めた方が圧倒的に早い。

Parallel Extensions にはParallel.Forとかもついてるしなぁ。
PLINQでもやっぱり Max, Min, Count の問題は解消しない。

**デフォルトの名無しさん** · 2008/06/20(金) 09:05:06

>>181
DryadLINQみたいにExpressionを直接扱う計算エンジンが要るね。
PLINQは所詮IEnumerableベースだし。
ttp://research.microsoft.com/research/sv/DryadLINQ/

ポテンシャルはDryadLINQ>>>>>PLINQなんだろうけど、
出荷までにかかる時間を考えるとPLINQ>>>DryadLINQだろうねぇ。

C# 3.0もお披露目から1年半ぐらいかかったし。
出荷までの時間短縮はお金じゃ解決しづらいんだろうな。

**デフォルトの名無しさん** · 2008/06/20(金) 09:07:06

>出荷までにかかる時間を考えるとPLINQ>>>DryadLINQだろうねぇ。

不等号逆だった……
ポテンシャル: DryadLINQ>>>>>PLINQ
出荷までにかかる時間: PLINQ<<<DryadLINQ

**デフォルトの名無しさん** · 2008/06/20(金) 09:10:04

>C# 3.0もお披露目から1年半ぐらいかかったし。

あとこれもお披露目から2年半の間違い。

**デフォルトの名無しさん** · 2008/06/21(土) 10:41:48

もうちょっと落ち着いて！