OOとDOAの周りでいつもの井戸端会議。

foobardam @foobardam

@pokarim @twtshi @nouvellelune ちなみに、その当時（6～7年前くらいだったか）、PL/SQLでCGIを組んでいるところは結構ありますよって、誰からか聞いたことあります。私は、その現場しか知りませんけど。

しゅわみ @twtshi

@nouvellelune @pokarim @foobardam スキーマレスなんてことは本当にあり得るのでしょうか。スキーマの異なるデータどうしはどうやって演算するのでしょう。

foobardam @foobardam

@nouvellelune @pokarim @twtshi ちなみに、OOコンサルの人と要件定義で一緒のチームとしてプロジェクトに参加したことあります。その時、印象的だったのが、開発のことを考えてはいけないと仕込まれました。概念モデリングは、彼から教わって今でも感謝してます。

しゅわみ @twtshi

@foobardam @pokarim @nouvellelune そのイメージだと片方は擬人的な数字でもう片方は擬人的でない数字ですね。

しゅわみ @twtshi

@foobardam @nouvellelune @pokarim ハンガリアンを言語がサポートしたのだというくらいに思っておけばよいのかもしれません。

nouvellelune @nouvellelune

@twtshi @pokarim @foobardam それは逆に言うと本来スキーマレスなものを無理矢理型にハメて「きれいなモデル」と言っているにすぎないのでは。目的特化という意味ではスキーマは便利ですが、その過程で失われるものもあります。

foobardam @foobardam

@nouvellelune @pokarim @twtshi 私の会社は10名近く参加してたと思うのですが、要件定義チームは私一人だけだったので、開発のことは考えないように、意識的に同じ会社の人たちと距離を置くように努めてました。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 本来スキーマレスなものというと、例えばどんなものでしょうか？

nouvellelune @nouvellelune

@twtshi @pokarim @foobardam もちろん、定型処理が主目的なのであればスキーマで型定義することに異議はありません。ただ、スキーマを使うことで「毎月データ項目(列)を追加/削除する」ような使い方をはなから諦めていませんか？ とも思うのです。

foobardam @foobardam

@nouvellelune @pokarim @twtshi ということで、コンサルの人と、開発の人では、思考様式が違うなということを経験しました。そんな体験させてもらったのは、非常に良い経験でした。他にもOO方針の挫折などいろいろな経験をさせてもらいましたが。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 静的型付けvs動的型付けの話にも通じる気がします。その論でいくと静的型付けであることも同様の弊害を生むということになりそうですが、どうでしょうか？

nouvellelune @nouvellelune

@pokarim @twtshi @foobardam もちろんそこを静的型付けの弊害だと思っています。私も静的片付け言語を好みますが、それはプログラマとしての好みであって、デメリットでないと言うつもりはありません。

しゅわみ @twtshi

@nouvellelune @pokarim @foobardam 例えば２つのウェブページがあるとします。これらの間でなんらかの演算ができたとしましょう。この時，もとの２つのウェブページはスキーマレスだと言えますか？

pokarim @pokarim

@nouvellelune @twtshi @foobardam 静的型付けでもスキーマのあるDBMSでも、「毎月データ項目(列)を追加/削除する」ようなシステムは十分作れると思います。作りやすいかどうかという点では議論の余地はあると思います。

nouvellelune @nouvellelune

@foobardam @pokarim @twtshi コンサルの人は論理整合性重視、開発の人は実用性重視という傾向（あるいは役割・立場の違い）はあると思います

foobardam @foobardam

@twtshi @nouvellelune @pokarim 製造業のシステムで、スキーマが窮屈に感じた事ありますよ。工業製品って部品の組み合わせですよね。だから、木構造になるんですけど、これをRDBの2次元テーブルに押し込んでて、スキーマが窮屈に感じましたけどね。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 「毎月データ項目(列)を追加/削除する」の項目変更を、固定したスキーマの中での単なるデータの変更として実装することもできるし、スキーマの変更として実装することもできます。

foobardam @foobardam

@twtshi @nouvellelune @pokarim こういう工業製品みたいな木構造なのは、XMLDBとかオブジェクトDBとかの方がいいんじゃなかろうかと思いました。でも、いまだにRDBばかりですよねー。私DB周りは不得意なので、違ってたらごめんなさい。

nouvellelune @nouvellelune

@pokarim @twtshi @foobardam あまり(今日の)プログラミングの話に振りたくないのですが、「定型処理はもうだいたいできるんだから、そろそろ構造を持たないデータを扱えるアプローチが出てきてもいいんじゃないの？」と思うわけです

しゅわみ @twtshi

@foobardam @nouvellelune @pokarim 部品表のことでしょうか。

nouvellelune @nouvellelune

@foobardam @twtshi @pokarim その通りです。でも親が偉大すぎるせいで息子がいまいちパッとしない問題w

しゅわみ @twtshi

@foobardam @nouvellelune @pokarim 根本的なことを言えば２つのノードの関係を示してやれば，グラフを表現することができます。

nouvellelune @nouvellelune

@twtshi @pokarim @foobardam その２つを(変換なしで)演算できる範囲は最大公約数的な共通部分に限られると思いますが、だからといって共通項以外の項目をもってはいけない、ということにもならないでしょう。

nouvellelune @nouvellelune

@twtshi @foobardam @pokarim グラフをRDBでやるのは（出来ないとは言いませんが）きつくないですか？

しゅわみ @twtshi

@nouvellelune @pokarim @foobardam 巨大な疎行列みたいなものだと思えばいかがでしょう？