アカウント名:
パスワード:
-- cooper
Javaのほうが言語としては数段便利だろうなとは思います。はい。
でも、クラスに色々機能を持たせなくちゃならないことも多いので、そこで継承を使うか、別のクラスにするかみたいな話になって、んじゃ定石集めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは?
なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
全てが表だと困っちゃう (スコア:1)
それでもRDBってものには複雑な(おいそれと賛美できない)気持ちを持たずにはいられないです俺。
なまじ表構造なもんだから、表と相性が良いとは限らないTreeだのNetworkだのの様々な構造を
取り得るデータ…最近の流行だとObjectですが…との間で、いわゆる
意味的インピーダンスミスマッチを、抱えさせられるんですよね。アプリ作ってると。これが辛い。
というわけでRDBもほどほどにしてOODBなりなんなりの時代になって欲しいなあ。
ええと。俺の理解が間違ってなければ(笑)、細かく言うと、
紹介された http://www-6.ibm.com/jp/gto/seibu/it/020311.html の中に書かれている
「規則9 データは論理的に独立している」を、積極的に人間の直感に従って崩す(笑)のが、
OODBへの第一歩かなという気がしています。
ほら。クラス分析/設計って、あいかわらずヒューリスティックな作業でしょ(笑)。
あの人間くささが良いわけでして。#本気か俺?
#制約条件はMethodで実現するし、保全はガベコレで本質的には実現可能だし。
#キーという概念も、「Objectを検索する」という概念が実装されてる系では別に珍しくないし。
というわけで今日も我々はO-Rマッピングで苦労させられるわけですが、
やっぱり1クラス1テーブル方式は(目先の処理効率は良いけど)弱点も多すぎますね。
http://rwiki.jin.gr.jp/cgi-bin/rw-cgi.rb?cmd=view&;name=PRb
みたいな方向性じゃないと長い目で見ればきついんじゃないかな。
Re:全てが表だと困っちゃう (スコア:2, すばらしい洞察)
八つ当たりですが
Re:全てが表だと困っちゃう (スコア:0)
ただ Oracle とか言って気取ってみたいだけちゃうんかと、
小一時間問い詰めたくなるわけで。
前に当たった小規模 SIer は抱えている SE が Oracle しか分からないため Oracle で提案してきやがりました。同時接続数 15 以下、
Re:全てが表だと困っちゃう (スコア:0)
Oracleじゃないと満足しない客もいますからねぇ
そういう客が存在する限りOracleさえ使えるようになれば、なんとかなるんじゃねぇか、、という考え方のSEが育つのも当然か、と思います
/*
そういう客に限ってtns
PL/SQL(オフトピ) (スコア:1)
個人的には、Oracle というより、PL/SQL が使えるかどうかで設計が全然違ってきちゃいますね。開発も楽になるし、メンテ時の作業効率も圧倒的に良いし。そういう意味では、情けないくらい完全に取り込まれちゃってます。
一旦 PL/SQL で組むと、他の RDBMS への移行が困難(というか、事実上無理)だしなぁ...
# しかし、僖奪院璽献?璽愁襪陵僅任砲肋,討覆い里任后▲肇曠
-- cooper
Re:PL/SQL(オフトピ) (スコア:1)
# しかし、パッケージカーソルの誘惑には勝てないのです、トホホ
でした。
-- cooper
Re:PL/SQL(オフトピ) (スコア:1)
という感じですよね。言語仕様そのものはあんまり格好良い言語ってわけでもないような気がする。
あれ?Oracleのサーバー側手続き言語を、PL/SQLからJava(かなんか)に交換しちゃうっていう話が、
有ったような気がしたけど、気のせいかな?
Javaのほうが言語としては数段便利だろうなとは思います。はい。
Re:PL/SQL(オフトピ) (スコア:1)
やっぱり、Java Stored Procedure だと、なにかこう奥歯に物が挟まったような気持ちになるんですよね、うまく表現できないんですけれど...
そこらへんについてちょっと書いてあるコラムはこちら:
http://otn.oracle.com/oramag/oracle/03-jan/o13java.html
-- cooper
Re:PL/SQL(オフトピ) (スコア:1)
うーん。なんだろうこれは?
面倒さは、どっちかってーと、周辺のツール(の整備度?)とか言語仕様とかが面倒さを醸し出しているような気がしました。
プログラムをサーバーに突っ込む手順がもっと楽になればだいぶ良い感じになるんじゃないかなあ?
Classのソースを全部自分で書かないとならないのだとしたらウザイから、
該当Methodの中身のコードだけ書いたら、その外枠は勝手に生成してくれる、というツールが
あればいいんだろうな、という感じかなと。
あと、Javaだとクドイというかなんというか、な面はあるかも知れません。
それこそRubyみたいな軽いノリの言語のほうが更に嬉しいかもと思う。
Re:全てが表だと困っちゃう (スコア:2, すばらしい洞察)
(中略)O-Rマッピングで苦労なさっているというご主張について、そもそもそのTreeだのNetworkだの
を関係モデルとして正規化(Normalize or Normalization)若しくは非正規化(一応断っておきますが、
「非正規化」は「非正規形」のまま放置することではなく、一旦正規化したデータモデルを、さまざまな
目的から、その正規を崩すことを意味しています。)が十分でないからではないでしょうか?という疑問を
抱きました。
また、OODBについて言及なさっていますが、果たしてOODBとOOPは相性が良いのでしょうか?
(私はいまだに良くわかりません。それほど経験をつんでいないもので...)
それから、規則9(の日本語訳)のあなたの理解は読みきれませんが、後続の記述から類推すると誤解
されているようです。規則9のココロは、従前のアプリケーションとデータの一体化状態から脱却しての
独立性という意味です。
Re:全てが表だと困っちゃう (スコア:1)
>を関係モデルとして正規化(Normalize or Normalization)
OO的なやりかただと、正規化とか非正規化という考え方を(普通は)しないんですよね。
OO勢がやってる分析や設計は、とどのつまりは「直感」です。
直感的にすっきり納得できるデータの並べ方ならOK、という感じです。
#Objectをいったん全部ばらしてRDBに格納するという前述のやりかたならば話は別ですが、
#あーゆーやりかたは主流じゃないようなのでここでは置いておきます。
#素朴に1クラス1テーブルにするか、それの亜種的なやりかた、あたりが主流だと思います。
そして、直感から離れるようなヤリカタは、たとえそれが正規化やそれ以外の何かであろうとも、
あんまり受け入れられてない、と思って良いと思います。
正規化とかの論理的に裏付けられたヤリカタに、あえて(かどうかはともかく)背を向けてるという印象です。
冷静に考えれば、おっかない話ではあるんですが(笑)。
俺としてはOOP(というかOOA/OOD)は、「児戯指向」だと思っています。
つまり幼稚園児でも判るような(笑)直感のみに従ったヤリカタを選択しがち。
これ、OOPの元々の考え方であるシミュレーションやメタファというものが、
元来そういうものである、という面が有るせいだと思います。
そういやSmalltalkは子供でも使える言語を目指したものでしたっけね。
#とはいえ、だから悪いと思うことも出来ない俺。OOPって、馬鹿だから可愛い子みたいな感じなんですよ(^^;
まあ、高速化のためのノウハウも存在しますし、Objectであるがゆえに却って性能的に得をする面もある
(なんせObjectはそれ自体が何らかの情報のCacheみたいなもんですから、うまく使えば色々と…)んで、
悲観することもないかなーという気もしています。
というか、正規化とかの方向は、コッチ(笑)から見れば、
「やりすぎて人間様に理解しにくくなってしまった最適化」
みたいに見えちゃったりするんですよね。その捉え方が正しいかどうかは別として。
>OODBについて言及なさっていますが、果たしてOODBとOOPは相性が良いのでしょうか?
まともな奴なら、「そのまま」保存するように作られてるはずですから。
O-Rのようにマッピングをする必要が無いわけです。
>規則9のココロは、従前のアプリケーションとデータの一体化状態から脱却
ああ。そっちですか。
でもOO勢なら、そういう場合は「ドメイン領域のデータのクラス」という括り方をするだろうな。
ネジクギトンカチ的なクラスは「アプリに依存しないクラス」として作られて当然ですが、
ドメイン領域のデータでありながら同時にアプリ依存性を薄くした「直感的でない(笑)」クラスの作り方は、
OO勢はあんまり得意としていないんじゃないかな。
なんでもかんでもモデリング「して」しまうってゆー感じ。
後で変更したくなったらどうすんだ?とクビを傾げることが時折。
#数年越しの永続クラスの設計を(欠点が判っても)今更変更できなくて喘いでいるG7
(オフトピ)OOは直感か? (スコア:1)
> OO勢がやってる分析や設計は、とどのつまりは「直感」です。
> 直感的にすっきり納得できるデータの並べ方ならOK、という感じです。
オブジェクトというのを最初に素人に説明するときは、直感とか「もの」とかいう話になりますが、「分析と設計」ってことになると、モジュール化でしょう。coupling & cohesion. (定着してる訳は知らないけど、多分モジュール結合度と凝集度。)一つのクラスで色々やらないで、別々に分ける。(hi cohesion)で、なるべく他人の内部構造に依存しない。(lo coupling)
でも、クラスに色々機能を持たせなくちゃならないことも多いので、そこで継承を使うか、別のクラスにするかみたいな話になって、んじゃ定石集めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは?
なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
Re:(オフトピ)OOは直感か? (スコア:1)
>めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは?
>なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
いや、直感という言い方は確かにちょっとアレだったかもですが、
パターンは今度は「経験」の世界であるわけで、
それが機械的論理的に決まる世界ではないという点において、直感とは同類ですね。
つまり、自分ひとりのではないのだけど、大勢の人々の直感(笑)の集積物っす。
定石と論理的帰結とは同じではないわけで。
もしパターンが正規化と同じような位置付けのものだとしたら、
パターンは単純に「究極の答え」と「それを崩したもの」とに分かれていたんじゃないかな。
でも実際のデザパタは、「トレードオフ」の世界ですね。
2つのパターンの採用を比較検討するとき、しばしばどっちも究極の答えではない、という世界です。
#もちろん、論外に間違った選択もありえますが、そういうのはここでは数にいれる意味がないんでパス。
てゆーか、パターンの数がこんなに何十個もある(さらに、自作することも可能(笑)だし、
世間でも日々新たなパターンが作られてる(大袈裟?)わけだし)のを見れば、
「ああ、これはプリミティブでもなんでもないんだ」と思うモンなんじゃないかな。
#元素の数が多すぎるんで「原子は究極の単位ではないのでは?」と昔の科学者は思ったのだとか...
正規化って、パターンのような、直感だか伝統だか経験だか自然発生だかによって生まれたものじゃないですよね。
よだん:
正規化と同じくらいに究極の答えがもしOOPにもあるなら、
ある1つの分野におけるクラスライブラリは、そうそう何種類も作る余地が無かったのではないかな?
でも実際には色々なカタチのものがあるわけです。
それだけ恣意または偶然(笑)によって如何様にも出来る世界だということじゃないかなあ?
Re:全てが表だと困っちゃう (スコア:0)
正規化は、考え方ではなくて手法です。その目的は、"One Fact in One Place" で、関係(Relations(複数形です))の一貫性を保つために行うもので決して最適化ではありません。
一部の設計の方法論では、正規化/非正規化≒パフォーマンスチューニングのような方針で(正規化)作業をされることがあるようですが、これは正しい正規化/非正規化ではありません。
正規化作業が上手な人のモデリングを見ていると、あたかも直感的に行っているように見えることもあります。それこそ、クラ
Re:全てが表だと困っちゃう (スコア:0)
プログラムの性質に合わせて変えたらいいのでは。
別にRDBにこだわる必要もない。
Re:全てが表だと困っちゃう (スコア:1)
だけど実際には、サポートやらネームバリューやらのせいで先にRDB(主にoracle)に決定するケースが多いんですよね。
OODBに特化した製品もあるのに推進するだけの(材料||件名)にならないという(汗
(oracleのOODBに関する動きだとoo4oをwrapするくらい?識者の意見を求む)
私の場合は、某F社のメインフレーム上での開発がメインだった時期があるのですが、当時のNDBの方が今のRDBよりもoopsにフィットする気がしますね。
---- 何ぃ!ザシャー
Re:全てが表だと困っちゃう (スコア:0)
GETANY GETNEXT GETNEXT...あぁBANK ACEが懐かしい.
Re:全てが表だと困っちゃう (スコア:1)
選択肢が有ればいいんですがね(^^;。
Transactionがきちんと有って、しかも普通の奴らの上を行ってない(そのせいで選択してもらえる(笑))ような
DBとなると、やっぱり今はRDBが多いでしょうね。
同様にObject指向言語に拘る必要もないわけなんだが、いまどき使い物になって、しかも普通の(中略)
言語となると、OOP言語が多いかな。
ところでプログラムの性質といっても、Collection(OOP言語風に言えば)の能力で大勢が決するって面が有りますね(^^;
まあGreenspun's Tenth Rule of Programming [dreamhost.com]ということだそうで。
RDBじゃないと恐ろしい (スコア:0)
表にできないところはそのままBLOBにブチ込んであとで展開したり、データ構造自体が表に出来ない場合はそこだけオンメモリにしたりして、主なところだけを表にするようにしないとダメ。じゃなければ物理デバイス自体を改良しないと。
新生代のデータベースなりデータ構造なりというものは、モデルに対してこれまたある種の「制限」を課すことによって生まれるんじゃないかな。なんで
Re:RDBじゃないと恐ろしい (スコア:1)
>データ構造自体が表に出来ない場合はそこだけオンメモリにしたりして、
>主なところだけを表にするようにしないとダメ。
そんな無茶な…
オンメモリにしちゃえってのは、そこを永続化するために別の工夫が要るってことですか?
なんか、何もするなといわれてるような気がしてならないなあ。
>じゃなければ物理デバイス自体を改良しないと。
「物理」まで手を出す必要あるんですかね?
それって(DBのデータ塊を置く場所である)ファイルそのものが
RDBには向いているけど他のDBには向いていない、と
言ってるようなもんだと思いますが、そこまで言えるもんなんでしたっけ?
#むしろRDBのデータファイルが古典的な「ファイル」に(効率よく)収まることのほうが俺には不可思議なんですが…
>新生代のデータベースなりデータ構造なりというものは、モデルに対してこれまたある種の「制限」を課すことによって生まれるんじゃないかな。
それは勘弁願いたいな。ODBが先祖がえりに過ぎないロクでもないものだってのは確かに言えます(笑)が、
だからって逆に、進化の方向が常に制限で縛られて使いにくい方向にしか向かない、なんていう真っ暗な未来も
ちょっと想像したくないです。
せっかくプログラミングが昔に比べてこれだけ楽になったというのに、
それを永続化しようとしたとたんに地獄っすか?
それは人としてどうよ?という感じ。
余談:
そんなことするくらいなら、人はもっと違う世界に逃げようとするんじゃないかな。
例えばSmalltalkみたいに(笑)とりあえずメモリ上のObjectを全部そのままファイルに書くだけの世界。
それじゃ困るという声が生じそうですが、サーバーサイドなんかは特に、「ファイルに」落とす必要が
どれだけあるかってのを再考したほうがいいんじゃないかなと思います。
つまりshutdownするまではオンメモリでやっちゃえと。
そうすりゃついでにOOP言語でサーバーサイドロジックも素直に(ローコストで)書けますしね。
OSはワンレベルストアを提供してくれりゃそれでいいかも。ん?物理的って、このことですかね?
>なんでもありの OO からはおそらく何も生まれない。RDB もデータ構造を大胆にむりやり表にして相互に関係づけさせることで生まれたわけで、
OOは何でも有りってほど何でも有りではないですけどね(^^;。
#「このくらいいいじゃん!」という感じかな(笑)
ただ、こないだも書いたけど、OOとRDBのマッピングについても、素朴な1クラス1テーブルとは
全然違うヤリカタにすると、それはそれで面白い世界が拓けてくるんじゃないかとも思うので。
余談:
あのPRbの説明を読むとむしろ、OOPも
「データ構造をむりやりObjectと参照(属性名)の連鎖にして相互に関連づけさせる(Binding)ことで生まれた」
などと言えるような気がします。
その軸は、いわゆるユーザーのモデリングの恣意性とは無縁の世界なんで。
>エンジニアが自分の直感でシステムのデザインを決めるような時代は絶対に来ないし来ても意味がない。
「来ない」というのが何を指しているのかちょっと不明なんですけど。
なにせ、今がまさにその「直感で決めてる」時代なのですから、もう「来ています」ですよ?(^^;
良し悪しはさておき。