実現する、言語統合クエリ(LINQ Language integrated query)
DLINQ (LINQの実装) などについて語り合いましょう。
The LINQ Project
ttp://http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx SQL文を文字列変数に代入して、それをオブジェクトに渡して、
っていう処理にすごく違和感があって入りにくかったのを思い出した。
今はその書き方に慣れてしまったので、逆にLINQに違和感を感じているｗ
でも、配列もテーブルと同じような操作が出来ないかなと感じたことは
あったので、設計やコーディングが楽になるかもしれないと期待している。
でも、初期バージョンは安定しないんだろうね。
データベースのテーブルの構築の仕方そのものが変わっていくことになる。
オブジェクト指向でデータを格納するプログラミングは書いてみたいと
思っていたので、今回のバージョンアップには期待しているが、
C#みたいに、現実にはあまり移行してくれなかった、なんて事になる可能性もあるだろうね。
strSQL = strSQL & "FROM PARIS;"
数行ならともかく10行以上のSQLをこうやって
羅列してるVBって恥ずかしくないの？
これは恥ずかしいということではないんだと思う。
じゃ、どうすんの？
strSQL = "SELECT * " & _
"FROM PARIS;"
のほうが連結がコンパイル時に解決されるので効率が良い。
The LINQ Project
ttp://http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx dlinq_overview_for_vb_developers.doc の４ページ目
> ' DataContext takes a connection string
> Dim db As DataContext = New DataContext("c:\...\northwnd.mdf")
> ' Get a typed table to run queries
> Dim Customers As Table(Of Customer) = db.GetTable(Of Customer)()
ADO.NETでいう、ConnectionオブジェクトやDataAdapterオブジェクトを
宣言して接続する一連の操作が、LINQではDataContextを宣言して、
定義したクラスにGetTableに読み込むという手順に変わったよ、という
旨の文章のところだけど、mdfの場所をフルパスで指定している
理由が分からない。mdbならファイルなのでフルパス指定だと思うけれど、
mdfはフルパス指定じゃなくて、SQLサーバ名とデータベース名の指定
にするべきだと思う。
この理由分かる方いらっしゃいますか？
それだとインデントの関係でSQLが見づらい
mdfファイルのフルパス指定で接続も可能なようだ。こういうコードの書き方はあまり
しないと思うけれど。
ttp://http://www.microsoft.com/japan/msdn/thisweek/10lines/vs2005/adonet_dataadapter/vb.aspx ttp://http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/cpref/html/frlrfsystemdatasqlclientsqlconnectionmemberstopic.asp 従来のRDBなんだよね。
同時にサーバのリリースもあって、そういう設計が出来るのであれば、
画期的なんだろうけど。ま、しばらくの間はRDBにDLinqで接続となるのかな。
そうなると、設計とかややこしくなる気がする。
テーブルを設計して、サーバにテーブルをつくり、それを読み込むオブジェクト
データベースを設計して、クライアントのプログラムを作るというやり方になる
わけでしょ。
サンプルの一部から持ってきたからでしょ。
サンプルのプロジェクトをアーカイブして配布する時に、
その中にmdfを含めて、そのまま実行してもらえるし。
DataSetでいいじゃん。
| 虚塵（笑）、お外に出た途端に負けますた！
＼
￣∨￣￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ （ ´Д｀ ） ＜ インチキ先発の一角鬱身が６失点！初黒星おめでとう！
（ ´Д｀ ） ／⌒ ⌒ヽ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
／, / ／_／| へ ＼
(ぃ９ | （ぃ９ ./ / ＼ ＼.∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
/ /、 / ./ ヽ （ ´Д｀ ）＜ 無駄なソロ空砲３発が惨めさを引き立てますた！
/ ∧_二つ （ / ∪ , / ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
/ / ＼ .＼＼ (ぃ９ |
/ ＼ ＼ .＼＼ / / ,、 （（（ ））） ／￣￣￣￣￣￣￣￣￣￣￣￣
/ /~＼ ＼ > ） ） ./ ∧_二∃ （ ´Д｀ ） ＜ ＧＷとはGiants Weakの略！連休中全敗確実！
/ / > ） / ／／ ./ ￣￣ ヽ (ぃ９ ） ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／ ノ / ／ / / / .＿/ /~￣￣/ ／ / ∧つ
/ ／ . / ./. / / / )⌒ ＿ ノ / ./ / ＼ ＼(ﾟдﾟ) (ﾟдﾟ) ｱｵｷ、ﾗﾐﾚｽ、ｼﾛｲｼ､ GJ!ﾐﾔﾓﾄﾓﾅｲｽﾓｳﾀﾞｼｮｳ!!ﾌｼﾞｲﾓﾅｲｽﾋﾟｯﾁﾝｸﾞ!
/ ./ （ ヽ､ （ ヽ ヽ | / （ ヽ､ / /⌒> ） ( )−'( )ヽ
（ _) ＼__つ ＼__つ).し ＼__つ （＿) ＼_つ / > .>> (･∀･) ｸｻﾚｷｮｳﾀﾞﾝﾊ､ﾊﾔｸｼﾃｲｾｷﾉｻｲｶｲﾆｶｴﾚ!!
コードをかけば、自動的にDataSetが内部で呼び出され、操作されるというものだよ。
でも、「DataSetなんて重くて使わないよ。おれはDataTableを使っているよ」という
人にとっては、嫌われるものかもしれない。
ちょうど、VBが重くて使えない、みたいな物と同じ話なのかな。
区別する時は、リンキュー。もしくは、データベース リンク
そうでないときは、普通に、リンク
と、自分の頭の中で発音してたがｗ
その辺は分かっているつもりなんだけど、
Linq To SQL でクラスを生成して、それを後からソースの内部で使うよね。
でも、型つきDatasetでも.xsdを事前に生成して、それを後からソースで使う。
結局同じような事を、違ったテクニックで行えるようになった訳で、あえてLinqを使う意味が良くわからない。
もちろん、SQL文みたいなものが、C#やVBとして記述ができるので、コンパイル時にエラーが出てくれるとか、
SQLインジェクションなんかが起こりにくい、と言うメリットは分かるんだけど、
正直それだけの為に、言語拡張までして対応した意味が不明なのです。
TableAdapterを使うものが、.xsdを事前に生成して・・・にあたって、
DataAdapterを使うものが、Linqを使ってコーディング・・・にあたるということ
だと解釈している。
この違いは、「前者は、ADO.NETではない。」ということ。
Win環境での開発だと違いが分からないが、そうでないところで開発する時に
影響するというものなのかも。
…って、このスレって見てる人いるのかな？
スレを立てるのが早すぎたのかもね。。。
さんくす。見てる人いたのね^^
DLinqのORMとしての評価はどうなのだろう。
DBに被せるレイヤとかラッパって感じ。
テンプレも含めた案をお願いします。
私は、これからの流れとして、「オブジェクトデータベース」を
つけたほうが良いと解釈していたのですが。
いまのところサポートしてるのはSQLサーバーだけだし。
持ち上げられて、RDBの次はODBだなんて言われたこともあるけど、
今じゃ落ち着くところに落ち着いただろ。
「これからの流れ」というより、うさんくさい目で見られる可能性の方が
高いと思うけどねぇ。数年前のXML-DBとおんなじで。
それはともかく、LINQが想定しているのはリレーショナルモデルだから
オブジェクトデータベースとは違うと思うよ。
どちらかというと、3GL埋め込みSQLを今風にOO言語をホスト言語に
してみたらこんなんできましたぁ、ってところだよね。
ラッパーではないっていうのは、「厚み」の問題? もっと根本的に違うとか?
この調子じゃあ、どう見積もっても次のスレタイを考えるまでに十分な時間がある。
LINQとは何か、結論出てからでいいんじゃね?
LINQってMSの日本語訳によれば、「 .NET 統合言語クエリ」だから、まあそんなとこ
なんじゃね?
「.NET 統合言語クエリ LinQ DLinq のスレ」
マイクロソフトのコードネーム Orcas に搭載予定のオブジェクトデータベースを
実現する、言語統合クエリ(LINQ Language integrated query)
DLINQ (LINQの実装) などについて語り合いましょう。
The LINQ Project
ttp://http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx マッピング情報をXMLに書き出さなければならない点で、
DLinqはNHibernateに負けているような希ガス。
MSは、こんなものを実装する前に、
ADO.NETドライバの仕様を弄って、
NHibernateを使えなくしたほうが良くねｗ
普通のLinqで使ってるdelegate型のLinq構文は別物。
マッピング情報は属性(アノテーション)に書き込むタイプ。
開発の手順はDBのスキーマからdbml(xml形式)のファイルを生成。
必要に応じてdbmlを変更。dbmlから属性付きデータクラスを生成となる。
ADO.NETのDataSetと同じで実行時にxmlファイルを参照するわけではない。
聞きかじりなので詳しくは分からないんだけど、
ぱっと見で単なるラッパーのようだが目指すところはそれだけではないとのこと
なので、ラッパーだと思ってスルーしている人も
情報収集しておいた方がいいかも？って感じかな
大文字小文字の使い分けは意味がある？
LINQは全部大文字なのでは？違うのかな… orz
dbmlファイルってRDBMS使うときの過渡的なものだっけ？
まぁ、SELECTしかできないらしい最初のバージョンは使いづらいかも
全部大文字（現行スレのタイトル）が正しいです。
ミスでした。（＾＾；
ここでデモプロ１本作ってみるよ。数回の連載になるけど過疎ってるから勘弁な。
とりあえず環境はSQL2005Express+.NET3.5日本語Betaでおｋすよ。VS2008なしでいける。
まずはDBを作ります。ShopとCustomerで1:nの関係。
sqlcmd -S .\sqlexpress
接続できたら
create database DLinqDemo
go
use DLinqDemo
go
create table Shop (ID char(4) primary key, Name nvarchar(10))
create table Customer (ID int primary key identity,
ShopID char(4) references Shop(ID), Name nvarchar(20))
go
今後このデータベースが不要になったらsqlcmdで次のコマンドをたたけば消せます。
drop database DLinqDemo
Path=C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;%PATH%
コマンドプロンプトからSqlMetalコマンドを実行します。
sqlmetal /server:.\sqlexpress /database:DLinqDemo /dbml:DLinqDemo.dbml /namespace:demo
userdb.dbmlを編集。ただし今回は編集の必要なし。
もし共用のDBを使ってるなら全ユーザーテーブルが入ってるのでいらないのは削除。
データクラス＋マッピング属性のDLinqDemo.csを生成。
DLinqDemo.csはデータベースから直接も作れるのだけど２段階に分けたほうが後々便利。
sqlmetal /code:DLinqDemo.cs DLinqDemo.dbml
コンパイルは cs /o demo.cs DLinqDemo.cs
// demo.cs
using System;
using System.Collections.Generic;
using System.Data;
using System.Linq;
namespace demo {
class Demo {
static readonly string conn =
@"Data Source=.\sqlexpress;Initial Catalog=DLinqDemo;Integrated Security=SSPI";
static bool logFlg = false;
static void Main(String [] args) {
logFlg = args.Length > 0;
DemoList();
}
static void DemoList() {
using(DLinqDemo dc = new DLinqDemo(conn)) {
if (logFlg) dc.Log = Console.Out;
var qr = from c in dc.Customer select c;
var rs = qr.ToList();
foreach (var r in rs)
Console.WriteLine("{{ {0}, {1}, {2}, {3} }}",
r.ID, r.Name, r.Shop.ID, r.Shop.Name);
var rs2 = from c in dc.Customer join s in dc.Shop
on c.ShopID equals s.ID
orderby s.ID, c.ID
select new { ID = c.ID, Name = c.Name, ShopID = s.ID, ShopName = s.Name };
foreach (var r in rs2) Console.WriteLine(r);
}
}
}
}
クエリーしてないのに関連をたどってShopの情報も取れる。
下段は普通のLINQ風の構文で更新不可。アドホックなクエリーに使う。
demo.exeに適当な引数をつけると、DLinqがどんなSQLをデータベースに投げてるか見れる。
demo.exe log
データが入ってないので次回はデータを入れたいが、繰り返し実行できるように
テーブルを消してしまう処理を書いておこう。
これはデータを直接生のSQLを投げて消してしまうもので、
ORMのキャッシュはスルーしてしまうので注意。あくまでも初期化用。
static void Cleanup() {
using(DLinqDemo dc = new DLinqDemo(conn)) {
if (logFlg) dc.Log = Console.Out;
dc.ExecuteCommand("delete from Customer", new object[0]);
dc.ExecuteCommand("delete from Shop", new object[0]);
}
}
shop1に対してCostomerを２件。
shop2に対してCostomerを３件追加している。
それぞれ別のやり方で登録してるから見比べて欲しい。
static void DemoAdd() {
using(DLinqDemo dc = new DLinqDemo(conn)) {
if (logFlg) dc.Log = Console.Out;
var shop1 = new Shop() { ID = "A001", Name="WAHAHA" };
shop1.Customer.Add(new Customer() { Name="AAAA BBBB" });
shop1.Customer.Add(new Customer() { Name="AAAA CCCC" });
shop1.Customer.Add(new Customer() { Name="AAAA DDDD" });
dc.Shop.Add(shop1);
var shop2 = new Shop() { ID = "A002", Name="UFUFU" };
dc.Shop.Add(shop2);
dc.Customer.Add(new Customer() { Name="RRRR BBBB", Shop=shop2 });
dc.Customer.Add(new Customer() { Name="RRRR CCCC", Shop=shop2 });
dc.SubmitChanges();
}
}
Mainから次の順番で呼び出してくんしゃい。
Cleanup();
DemoAdd();
DemoList();
static void DemoModify() {
using(DLinqDemo dc = new DLinqDemo(conn)) {
if (logFlg) dc.Log = Console.Out;
var qr = from c in dc.Customer
where c.Name == "RRRR CCCC" || c.Name == "AAAA CCCC"
select c;
var rs = qr.ToList();
foreach (var r in rs) {
if (r.Name == "RRRR CCCC") r.Name = "YYYY CCCC*";
if (r.Name == "AAAA CCCC") dc.Customer.Remove(r);
}
dc.SubmitChanges();
}
}
長々とすまなかった。以上だ。
デモプログラムサンクス。
ちなみに何処の解説を参考にして書いたの？
リリース版の.NET3.5にsqlmetalが付いて来なくなってる。SDKはまだか。
しかもインストール不可版もダウンロードしてしまった ^^;
なかなか使いやすいんではないかな。
手っ取り早く LINQ to SQL を試すためのテストコード - NyaRuRuの日記
ttp://d.hatena.ne.jp/NyaRuRu/20071219/p4 っていうか、何でDB板は全体的に過疎ってるんだ？
完全な無法地帯になりそうで危険な悪寒…
あとSQLが自動生成されると、パフォーマンスチューニングがしづらそうだが
本当に大丈夫か？
自分の思い通りじゃなかったりするもんな。
で、結局は信頼性に欠けるということで、
自分で手修正してることはあるな。
だから俺はまだLINQそのものを使ってないな。
O/Rの出力SQLを例と見ると・・・
そもそも対象になる製品が限られている＝ユーザー数の裾野が狭い
っていうのと学生はデータベース触らない
っていう２ちゃん的に盛り上がれる要素が少ないからだと思われ
ム板みたいに速度チューンネタや言語速度比較みたいなのも
データベースの場合は「場合による」で終わっちゃうし
それにみんな本当はDBあまり好きじゃないんだ・・・・趣味でやるほどには・・・・
確かにデータベースは余り面白くないものかも。
AccessやLAMPが出るなどして、スタンドアロンでも出来るようになって
大分一般的なものになってきたように思うんだけどな。
まだまだなのかな。
家ではディスクのインデックスでも作っといてって感じだな
特別企画『マイクロソフトの最新統合クエリ言語「LINQ」を試す』
先輩や先生の関係かな。
ま、半ば選択の余地がなくて強制って感じｗ
凄く嫌だとか抜け出したいとかは思ったことは無いけれど。
あらたまってこれについて語れって言われても思い浮かばないんだよな。
それはそうと、
.NET 3.5 SP1でADO.NET Entity Frameworkが追加になってけどどうよ？
統合するのか、それぞれ存続させるのか？
LINQのクエリだと結果集合を毎回APサーバまで引っ張ってくるのか？
一発で絞り込めるクエリにしないと簡単に帯域ぶっちぎって
パフォーマンスダメダメになりそうだな。
ttp://pc11.2ch.net/test/read.cgi/tech/1202568694/ 言語仕様としてのサポートが無いと、LINQほどスマートにはいかないよねぇ。
特に急いで習得する必要性がなさそうだと思った。
これで書かれたプログラムを読まなければいけない状況も当分の間は
なさそうだしね。
配列のデータを扱う時、DataTableのデータを扱う時、ADO Recordsetで
接続してデータを扱う時は、すべてコードの書き方が異なっているので、
それぞれのやり方を覚えなおすよりも統一した方がプログラマにとっては
助かるので、方向性としてはLINQのようなものになるのは分かるが、
いまはまだVer1なわけなので、さらにまた言語仕様が変わっていくような
気がする。
過去のものを見るとVB.NETそのものが方向性を模索してるようなところが
あったしね。オブジェクト指向を強く出してVB6の要素を切り捨てたが、
ユーザがついてこなかったため、VB6よりに作り直したとか。
しばらく様子見かな。
