アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
とらわれちゃうとねぇ (スコア:0)
Re:とらわれちゃうとねぇ (スコア:1)
設計はいやですけど個人レベルでもSQL叩いて手軽にデータをい
じれるようになったのでとても重宝します。
大きなシステムで重宝するのもありますけど、手軽にデータと
ロジックを分離する（か、その前提）ツールとして使ってるよ
うな気がします。
taka4
Re:とらわれちゃうとねぇ (スコア:1)
>設計はいやですけど個人レベルでもSQL叩いて手軽にデータをい
>じれるようになったのでとても重宝します。
昔、Niftyで(笑)、
SQLを使えば、 DBをアドホックにいじれるし、言語として難しくない(比較対象はC/C++など)から
ぜんぜんプログラマじゃない人でも手を出せるので、よってRDBは大変便利なDBシステムなのだ、
とかいう議論を展開した人がいました。
その時は俺も旨い反論が思いつかなかった(その頃からRDBには違和感を感じていたので
反論したかったんですが)のですが…
それから幾らかして、C++やja
Re:とらわれちゃうとねぇ (スコア:1)
世界中の*123.docが消滅するとか・・
冗談はおいといて、OODBというのをあまり知らないのですが、その
コードは例えばファイルシステムをRDBで構成したとして、それを
ラッピングしたFileSystemClass（内部でSQLを叩いてデータを返す）
を用意して、
# FileSystemClass.search("*123.doc").each{|file| file.delete }
なんてやってみるのと何か違うでしょうか？
むしろこの方がOO的な気がしますが・・・これなら実装がRDBでも他
のファイルシステムでもいいですが。
個人的にはSQLはデータを取
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に落とすか？で悩む、と。
>OODBってそういうのをDB自身が装備したものでしょうか？
数珠繋ぎでも格別遅くならないし、関連も心配せずそのまま保存できる、という代物ですね。
Re:とらわれちゃうとねぇ (スコア:1)
私もOODBに興味が出てきたので、時間が取れたら調
べてみます（笑
#ひきこまれるな～
taka4