アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
とらわれちゃうとねぇ (スコア:0)
結果として「なんでこんなに高くなるんだよっ!」と言いたくなるようなオーバースペックなシステムができてしまう、なんてことがよくありましたね。
どんな仕組みだって「適材適所」なはずなんですがね。
あぁ、Codd先生が悪いわけじゃないんですけれど。
Re:とらわれちゃうとねぇ (スコア:1)
設計はいやですけど個人レベルでもSQL叩いて手軽にデータをい
じれるようになったのでとても重宝します。
大きなシステムで重宝するのもありますけど、手軽にデータと
ロジックを分離する(か、その前提)ツールとして使ってるよ
うな気がします。
taka4
Re:とらわれちゃうとねぇ (スコア:1)
>設計はいやですけど個人レベルでもSQL叩いて手軽にデータをい
>じれるようになったのでとても重宝します。
昔、Niftyで(笑)、
SQLを使えば、 DBをアドホックにいじれるし、言語として難しくない(比較対象はC/C++など)から
ぜんぜんプログラマじゃない人でも手を出せるので、よってRDBは大変便利なDBシステムなのだ、
とかいう議論を展開した人がいました。
その時は俺も旨い反論が思いつかなかった(その頃からRDBには違和感を感じていたので
反論したかったんですが)のですが…
それから幾らかして、C++やjavaみたいな言語とは一味違う言語の世界が、
Object指向のほうにも存在する、ということを知りました。
つまり反論する(笑)ためのネタが身についたわけです。
何の事はない、「扱い易い言語」ならば、いいんですよね。
それがRDBを対象としたSQL言語でも、OOPを対象としたSmalltalkやRuby(笑)でも、
本質的には同じなんだろうなと。
というわけで、例えば「個人レベルでRuby叩いて手軽にプログラム」という世界も、悪くないと思っています。
扱い易く、動的で、さらりと短く書ける言語(最近ではLightWeight言語ってんでしたっけ?)なら、
そういうやりかたを採れるのが期待できそう。
さらに、(なんらかのOODBと接続して)Rubyで永続オブジェクトを叩けば、それもんの人(???)も幸せになるはずです。
# WordClass.search("Filename like '*123.doc'").each{|file| file.delete } なんて書けると結構幸せなのでG7
Re:とらわれちゃうとねぇ (スコア:1)
>それがRDBを対象としたSQL言語でも、OOPを対象としたSmalltalkやRuby(笑)でも、
>本質的には同じなんだろうなと。
スケーラビリティって言うんでしょうか。扱うデータ量で、OOPとDBでは雲泥の差が出ます。
データ数が百万超えたらDBなしで生きていけません。OOPは、扱えるデータ数上限が百万でしょうが、
DBにとってはデータ数百万なんてカスみたいなもんです。
ほら、例えばデータ数が高々千だったら、プログラミングのプの字も知らないおじさん、おねーさんが
Excelでしこしこ「情報処理」できちゃうじゃないですか。
定型データが1000以上あるからこそ、(かつ、それなりのレスポンスが求められているからこそ)
プログラミングする価値があるわけで。
つまり、Excel < OOP < DB って感じですね。
Re:とらわれちゃうとねぇ (スコア:1)
あのー?
OOPをそのままスケールするために(モデル変換も大きなコストも無くそのまま永続化できる仕組みがあれば
スケールするための助けになるだろうと考えて)、RDBならぬODBが(メジャーになって)欲しいぞ、
という感じですので、OOPとDBとを比較されても困ります。
もしかしてs/DB/RDB/gですか?
だったら1つの主張として理解は出来ます(ので以下そういう仮定で書きます:それ以外の場合は知りません)が。
# DBといったらRDBしか思いつかない人が目の前にいたらムカツクのでG7
# DBといったらOracleしか思いつかない人と、そう違わないんだよな…
>定型データが1000以上あるからこそ、(かつ、それなりのレスポンスが求められているからこそ)
>プログラミングする価値があるわけで。
うーむ。Excel(表計算)の限界は、表ってものは構造化がされていないせい、ですよね。
で、同じような質的な決定的違いが、RDBとOOPの間に、何か有るんでしょうか?
やはり児戯指向(笑)である点を弱点だと見なすべきでしょうかね?
# 同一性という概念は、(100%俺の想像ですが(笑))算数習ってない人でも、理解できると思うんです。
# それを中心に据えたOOPは、良くも悪くも児戯指向なんだと思います。
# で、問題はおそらく、同一性という概念がDBに対してどれだけ足引っ張りになってしまうか?という点なんじゃないかと。
# たくさん引っ張るのか、少しだけなのか、が。
# まあ確かに、DBに限らず一般に「永続化」は、同一性との相性が悪いことが既に知られてはいます。DB空間に複製を取った瞬間に、同一性が崩れるわけで。
## 参照の解決が厄介なのも、この同一性の問題が原因ですし。
あと、レスポンスについては、Intel様(笑)が速度をたたき出すおかげで、
一昔前には「プロが(アセンブラだのCだので)コーディングしないと」使い物にならなかった場面でも
今やScript言語とかでスカスカ書けて実用になるわけでして、たぶん別問題じゃないかなと。
Re:とらわれちゃうとねぇ (スコア:1)
世界中の*123.docが消滅するとか・・
冗談はおいといて、OODBというのをあまり知らないのですが、その
コードは例えばファイルシステムをRDBで構成したとして、それを
ラッピングしたFileSystemClass(内部でSQLを叩いてデータを返す)
を用意して、
# FileSystemClass.search("*123.doc").each{|file| file.delete }
なんてやってみるのと何か違うでしょうか?
むしろこの方がOO的な気がしますが・・・これなら実装がRDBでも他
のファイルシステムでもいいですが。
個人的にはSQLはデータを取り出すまでが仕事で、その出力を
そのまま表示して終わりみたいな使い方はしないのですが、
SQLを「叩く側の言語」はRubyはじめOOな言語は重宝すると思
います。
取り出したデータのセットがオブジェクトになってくれればい
いわけで。そういうクラスがあればいいわけですから。
OODBってそういうのをDB自身が装備したものでしょうか?
(・・・自分で調べろって)
taka4
Re:とらわれちゃうとねぇ (スコア:1)
どーでもいいですが、せっかくFileSystemという概念を持ち込むならば、
FileSystemClassじゃなくtheFileSystemという FileSystemクラスのInstanceであるほうが、嬉しいような気がしてます。
FileSystemはFileSystemItemのコンテナであり、FileSystemItemのサブクラスにはFileやDirやSymLinkがある…と。
さて。
>なんてやってみるのと何か違うでしょうか?
>むしろこの方がOO的な気がしますが・・・これなら実装がRDBでも他のファイルシステムでもいいですが。
あはは。ご指摘の通りで、実はそう違いません(^^;
ただし、見た目はです。中はぐちゃぐちゃしたコーディングをしないとなりませんし、
ラッパーの生成を自動化したり実行時解決するようにしたとしても、効率の悪さの問題は残ります。
たとえばRDBは、ツリーというか数珠繋ぎというかのデータ(構造?)を扱うのが苦手(コストが高くつく)ですが、
だからってアプリが数珠繋ぎ構造データ(の永続化)を放棄するのは本末転倒なので、
遅いけど我慢して使う羽目になります。
足回りも含めて交換したくなるってのは、そういう事情があるから。
# O-Rマッピング自動化クラスをJavaで書いて疲れたんでG7
あと、以下はマッピングをどうやるかによって違ってくる話です(が主流なマッピングのやりかただと抱えてしまう問題です)が、
「関連」をどう保存しようか?という問題が残ります。
関連ってのは、RDB用語のほうじゃなく、OO用語の「オブジェクト同士の繋がり」のほうの話です。
これをどう扱うか?っていう問題。
ここでOOとRの根本的な差が効いてきます。
全てのケースを円満解決して処理効率も良いような決定版的マッピング技術てのは、無いっぽい。
仕方ないんで毎回毎回逃げを打ちます。
ObjectIDを持たせてそれをポインタ代わりに使う、ってのが一番楽そうですが、
「違うクラス(=違うテーブル)でもUniqなID」を生成したり唯一性チェックしたりするのは
(それが出来ないと、多態をサポートできませんから、使い物にならん。)
それなりの仕掛が要りますし、その仕掛自体の処理コストも馬鹿にならない。
それにDBファイルのサイズ効率を気にする客から「IDみたいな余計なフィールド持たせるなよ」と怒られがちだし。
# 自作マッピングでは結構逃げたのでG7
# 「参照先のObjectはどのタイミングでメモリにロードするか」とか、結構悩ましい問題が多いんですよー(T_T)
## HollowObjectを導入しなかった時点で敗北とも言うが(笑)。
もともとOOにとってはObjectIDは暗黙のうちに存在する(他の属性がなんぼ同じでも、同一性と同値性は別ものだと捉える)
のが王道ですが、一方RDBは、(レコードとかの)同一性と同値性をいかに区別しないか(笑)が味噌なんだと思います。
だから select distinct みたいな考え方が生じる。モデル違いすぎ。
余談:
UMLの関連は、普通のOOP言語の関連とも違って、むしろRDBのほうに通じるものがあるように思います。
UMLを考えた人たちが一体何を考えていたのか、俺には不思議でなりません。
OOP開発を支援するためにUMLは作られたんじゃないのか??
余談2:
そういやRDBのほうも、レコードの同一性という情報が結局欲しくなって、それを補ってる製品が結構ありますよね。
行IDってものがある製品、ありますよね。
やっぱり(OOPには最初からある)IDという概念は必要なんだな!と感動した(笑)ものでした。
>そのまま表示して終わりみたいな使い方はしないのですが、
>SQLを「叩く側の言語」はRubyはじめOOな言語は重宝すると思います。
「叩く側」と言ってしまうと、(あなたの意図はさておき世間全般(?)から見れば)二通りの意味に取れると思います。
つまり、上記のようなO-Rマッピングをしたいという話と、
もう一つは、単にRDBアクセス機能を提供する仕組みをOOPなクラスライブラリとして実装すると
すっきりしますよ、という世界の話。
後者はJDBCやDelphiのDBコンポの話ですね。オブジェクトを「使って」RDBアクセスをすると、
使わずにアクセスするよりも数段楽に、アプリ書けますです。アクセスの単位や検索結果の保持が
凄く管理しやすくなるんで。
そういうクラス類は、べつにOOPの青年の主張はしません。
単にRDBというもの自体の構造をモデリングしたクラス群ですから、意味的ミスマッチを生じるはずがない。
(生じていたらただの設計ミス)
で、もう一方の(たぶんそういうものを土台にして)逆にRDBを「使って」オブジェクト(の永続化)を扱う場合は、
OO側でのモデリングをどうRDBに落とすか?で悩む、
Re:とらわれちゃうとねぇ (スコア:1)
私もOODBに興味が出てきたので、時間が取れたら調
べてみます(笑
#ひきこまれるな~
taka4
便利すぎて(Re:とらわれちゃうとねぇ (スコア:0)
それが便利すぎて常道化してしまったのですよね。
なんだか、醤油が日本人にとってあまりに美味しすぎるので
なんでもかんでも醤油で味付けしてしまうようになった話を
思い出しました。