-
- いいね！4
Masayoshi Hagiwara
@masayh
行指向は人間が情報を扱う点でシステムのどこかで必ず出現し、主に入口で使われるので避けて通れません。ただ、RDBはそれをシステム全体で使っている点が制約で、その優れたアルゴリズムだけを取り出して、並列エンジンに乗せてNoSQLと組み合わせ、入口以外のところに適用していくのがいい。
2010-11-19 11:41:05
Masayoshi Hagiwara
@masayh
情報を行で扱うのは人間の意味の認識と深くかかわるので、避けて通れない自然の発想、概念です。それ自体は何も制約がない。
2010-11-19 11:42:27
Masayoshi Hagiwara
@masayh
RDBMSだめと言い切る前に、なぜだめか、どこがこれからも利用可能かを考えてみましょう。同じように、OOPや既存の開発方法も振り返るのは大切です。時代が変わり、環境が変わり、要求が変わる以上、同じ技術も見方や立ち位置が変わるから。
2010-11-20 12:50:29
Masayoshi Hagiwara
@masayh
まず自分で問題意識を持って、調べて、意見として考え方をまとめましょう。次にそれを技術者同士で確認しあいましょう。そして、価値を認めて広げていきましょう。そうすれば、技術は発展していくはずです。
2010-11-20 12:52:41
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
クラウド時代のデータ構造は、いろんな意味でフローデータとストックデータの境は曖昧になる。・・・・どちらかというと世の中の実態に近くなる、と思っています。
2010-11-20 20:34:22
Masayoshi Hagiwara
@masayh
RDBがスケールしない理由に続いて。RDBがデータモデル上の定義で、本質的に間違っている点を考えてみてください。なぜテーブルを定義し、ジョインしなければいけないのか？
2010-11-21 15:32:50
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
今年のIT関連のベストTweetではないでしょうか。RT @masayh: RDBがスケールしない理由に続いて。RDBがデータモデル上の定義で、本質的に間違っている点を考えてみてください。なぜテーブルを定義し、ジョインしなければいけないのか？
2010-11-21 16:14:44
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
「なぜテーブルを定義し、ジョインしなければいけないのか？」なるほど。
2010-11-21 16:14:58
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
「Aというのものが、Bと同一である」ということがなぜわかるかというと、「そう決めたから」で、それは決めた人（または人たち）のルールでしかないわけよ。
2010-11-21 16:18:10
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
技術に変わり目には本質的な議論が剥き出しになる。直視してこその技術屋。・・・個々人のポリシーや考え方の問題。「いやだって、RDBはそういうものだから」どういうもの？「いや、会社で決めたからｗ」あぁそうですかw。
2010-11-21 16:21:56
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
ちょっと流通ITでのアイテムの正規化についてつぶやく。
2010-11-22 00:22:56
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
一般に消費財にJANコードと言われるコードがつけられる。レジでスキャンされるバーコードだ。今はJANではなくGTINといって、ワールドワイドに一意に決められている。管轄は経産省の外郭団体で、GS1というグローバル標準化団体に属している。
2010-11-22 00:23:19
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
んで、このJANコードは一見すると商品のキーに格好の材料だ。何しろ各商品にユニークについているし、ダブりなく管理もされている。んで、初心者のSE（そして大抵のSE）はいそいそと、こいつをキーにする。
2010-11-22 00:23:40
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
んで、あるタイミングで即死する。実は、JANコードは切り替わるわけです。いつか？新商品が出た時。そりゃ新商品だからスペックも変わるし、メーカーも形式上は違う物として管理したい。だから実態は「同じ」商品だけど、別々のJANコードが混在する、ということになってしまう。
2010-11-22 00:24:09
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
ちゃんとした業務系の仕組みは実はJANコードは絶対にキーにしない。そういう事情を知っているからだ。（そして、そうなっていないパッケージとか結構ある。・・・・まじで関係者猛省してくれ。あとでメチャクチャなカスタマイズが大抵入る。）
2010-11-22 00:24:31
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
じゃー、JANはキーでないのか？そんなことはない。実際、ある一定時点ではユニークなキーである。レジでPLU（売価をJOINする）する時には絶対的にJANがキーになる。また、発注する時点でもJANコードでの発注は普通にある。・・・・だから正規化ってのは、本当に難しい。
2010-11-22 00:24:58
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
商品の切り替わり、というのは認識論的に非常におもしろい。「それは前と同じ商品ですか？」YESでもあり、NOでもある。微妙に属性が変わっているのはよくあるし、その場合は厳密に言えば別商品。でも「後継商品だから、実際は前の商品と同じ」なんてことは普通にある。
2010-11-22 00:25:23
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
実はこれは商品に限らない。極論すると時系列で変化があるもの（そして大抵のものは変化する）は、すべて同じ問題につきあたる。あなたという人間は10年前と同じですか？違いますか？「同じであるならばそのキーって何ですか？」・・・名前って言いたいですよね。でもホントですか？
2010-11-22 00:26:11
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
@kis ユニークネスの保証って感じなんで、語義にもよりますが、そうとらえてもらっていいかな、と。
2010-11-22 00:29:12
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
.@Guutara 個人的には、お勧めは、野矢茂樹の「同一性・変化・時間」ですね。「ユニークネス」を考えるのであれば、絶対に必携だと思います。http://amzn.to/burbDY
2010-11-22 00:58:35
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
@Guutara まーほかに取り柄もないもんで・・・。実際、この「同一性・変化・時間」は一般の人を対象にしているので、専門書ではなく、非常に読みやすいです。まじでお勧め。
2010-11-22 01:07:44
Masayoshi Hagiwara
@masayh
RDBがデータモデル上の定義で、本質的に間違っている点: 概念モデルの表現の限界は恣意的なものです。視点を限定するのがモデルなので制約にはなりません。逆に制約を与えている。同様に、高階表現しないのもモデルへの制約であって本来のデータモデルの間違いではありません。
2010-11-22 14:01:35
Masayoshi Hagiwara
@masayh
RDBがデータモデル上の定義で、本質的に間違っている点： 正規化や結合は、関係モデルの理論上の決まりであって、ここで問題にしているのは、正規化以前のデータモデルです。つまり、第１正規化以前にすでにデータ定義に誤りがあることを指摘しようとしています。
2010-11-22 14:04:15
Masayoshi Hagiwara
@masayh
開発生産性を高める方法は強力なフレームワークやIDEを使い、”手順”に従って、できるだけ機械的に開発を進め、あまり、内部の仕組みや最適化のための独自に仕様化を考えないことです。しかし、技術が変わり、固定的な手順、強力なツールが無力になったとき、基本原理と機構の理解こそが重要です。
2010-11-22 14:15:19