アカウント名:
パスワード:
単にストアドプロシージャの言語に、(T-SQLではなく)VB(.NET)やC#が使える [atmarkit.co.jp]だけだ、ということでしたら同感です。
が、CLRをSQLServerに組み込むということは、SQL文の中で単に'sp_hogehoge'を呼び出すだけ、という従来型の利用法を超えた使い方があるんじゃないかなあ、とは思います。spとしてDBと無関係な処理が、CLRベースで書けるはずです。使えない「SQLメール」なんかもう切り捨てて、自前でメール送信処理を記述したり、あるいは任意の時点でファイルを書き出す処理を書けたり出来るわけです(多分)。
また、サーバ上のCLRとクライアント側のCLRとでリモーティングができれば、これは「.netらしい」ものではないでしょうか。あ、処理の重さは.netらしく豪快に度外視します:-)
あと、Yukonに対応するVisual Studioというのは、もしかしたらYukon上の各テーブルに該当するクラスなどが(ADO.NETのDataTableの派生として)自動生成出来たりするのかもしれませんね(xsd.exeでXML Schemaからクラスを生成する、っていうのとおんなじ発想です)。 # これでまた「醜悪な」コードが増えるのかな?...と、無理矢理本題に戻してみたりして。
(っていうかそういうのが実はあったりします? わたしが知らないだけで)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
DB開発者不足の解決? (スコア:3, 参考になる)
> つまり、Visual Basicでデータベースクエリを行えるようになるのだ。
>
(中略)
>まず第1に、データベース開発者は不足気味であり、データベースを開発環境に統合するというのは、この問題に対する部分的な解決策として注目される。
って、あるけど、データベース開発のキモは「どういうデータベースにするか」という設計のところにあって、
どの言語を使うのか、ってのは機能やコストを勘案して決めるわけでしょ?
なので、VBでクエリーができる、ってのは選択肢が一つ増えただけで、開発者不足の解決には全然なってないと思うんだけど。
ただ単に、「SQLわかんなくてもVBわかればオッケーだよ」ってだけだよね?
MSは、筆者の理解とは違う考えで実装しようとしてるんだと思うのだが。
#DBには詳しくないので、詳しい人からの突っ込みキボンヌ。
なんか、全体的に的を外れた批判と思われ。
.Netを擁護するのは別にいいが、MSの意図するところからはずれてるんじゃあ…
Re:DB開発者不足の解決? (スコア:1)
既にあるんですが…これとは違うのかなぁ。
記事をみるとサーバ側で動く(?)ような気もするけど。
> .Netを擁護するのは別にいいが、MSの意図するところからはずれてるんじゃあ…
Visual Studioを擁護するなら前半の「統合すれば便利」で十分だと思いますけどね。
# オープンソース陣営(?)ももっと統合して欲しい…。
Re:DB開発者不足の解決? (スコア:1)
T-SQLの代わりに、VBを利用できるってことになったのでは。
OracleのストアドにJavaが使えるようになったものかしら?
Re:DB開発者不足の解決? (スコア:1)
いまでも十分使いやすいと思うけどなぁ。ストアドのステップ実行できるし。SQLServer
そんなにT-SQLって難しくないし。
DBにCLRが組み込まれる事の意味 (スコア:1)
単にストアドプロシージャの言語に、(T-SQLではなく)VB(.NET)やC#が使える [atmarkit.co.jp]だけだ、ということでしたら同感です。
が、CLRをSQLServerに組み込むということは、SQL文の中で単に'sp_hogehoge'を呼び出すだけ、という従来型の利用法を超えた使い方があるんじゃないかなあ、とは思います。spとしてDBと無関係な処理が、CLRベースで書けるはずです。使えない「SQLメール」なんかもう切り捨てて、自前でメール送信処理を記述したり、あるいは任意の時点でファイルを書き出す処理を書けたり出来るわけです(多分)。
また、サーバ上のCLRとクライアント側のCLRとでリモーティングができれば、これは「.netらしい」ものではないでしょうか。あ、処理の重さは.netらしく豪快に度外視します:-)
あと、Yukonに対応するVisual Studioというのは、もしかしたらYukon上の各テーブルに該当するクラスなどが(ADO.NETのDataTableの派生として)自動生成出来たりするのかもしれませんね(xsd.exeでXML Schemaからクラスを生成する、っていうのとおんなじ発想です)。
# これでまた「醜悪な」コードが増えるのかな?...と、無理矢理本題に戻してみたりして。
(っていうかそういうのが実はあったりします? わたしが知らないだけで)
Re:DB開発者不足の解決? (スコア:1)
「スキーマさえ貰えれば私は騙されないが、フローチャートだけを渡されたら私は容易に騙されるだろう」
とかいう話が、プログラミング作法に載っていたような(うろ覚え御免)。
あれは実感としてもわかりますね。プログラムの流れそのものを正しく追うのって結構しんどくて、
静的であるスキーマのほうを中心に考えるほうがずっと楽だし確実。
>どの言語を使うのか、ってのは機能やコストを勘案して決めるわけでしょ?
>なので、VBでクエリーができる、ってのは選択肢が一つ増えただけで、開発者不足の解決には全然なってないと思うんだけど。
機能やコストというか、書き(&読み)やすさかな。#もし俺が決める立場ならね(^^;
別にDBに限ったことじゃないけど、PL/SQLやVBみたいな肩が凝ってくるような融通利かない言語も困るし、
かといってタコなみのC言語の柔らかさがJavaもとい邪魔になることは、アプリレベルを書く時には多いし。
(逆にCの硬さに悩まされることも有るけど。)
ああいう状況(^^;で欲しい機能と欲しくない機能が、有るっすね。
なにがどうとは一言では言いにくいけど、とにかくその理想に近い言語を、使えるものなら使いたい。
#そういう意味では、Javaはなかなかの"隙間産業"かも。
----
で。
いろんな言語が使える、ってのは嬉しいかもしれない。
ただ、使いたいと思った言語の能力を「フルに」使うことを、Frameworkが制限してしまうのならば、
使いたい言語を選んだのは無駄にしかならない、ということにもなる。
却って期待が外れるぶんだけストレスが増えるかも(^^;
.NETがナニをどのくらい制限する(orしない)Frameworkなのかは俺は知らないんで、
こっから先は更に識者に委譲っす。よろしく。
>全体的に的を外れた批判
確かに。かなり変な文っすね。
Re:DB開発者不足の解決? (スコア:0)
-- ここから --
>って、あるけど、データベース開発のキモは「どういうデータベースにするか」という設計のところにあって、
「フローチャートだけ見せてくれてテーブルは見せてもらえなかったら、わたしはわけがわからぬままだろう。テーブルさえみせてもらえれば、フローチャートのほうはたぶんいらない。見るまでもなく明らかだから」という話が『人月の神話』に載っていた(*1)。
あれは実感としてわかる。プログラムの流れを正しく追うよりも、静的であるスキーマの方を中心に考える方がずっと楽だし確実だ。
>どの言語を使うのか、っての
Re:DB開発者不足の解決? (スコア:0)
プログラミング作法 [amazon.co.jp]の第3章冒頭で引用されていますた。
#リンクだけだし、出遅れたので名無しさん