議論していて思ったこと。
「文書検索システムはRDBMSの中の重要な数値データを含むものは検索できない。
でも、それが出来ないと、充分ではない」
確かに、ユーザ視点だと、文書データであろうがRDBMS内のデータであろうが
どちらも検索できて当然だ。
「システム上の仕掛けが違う」というシステム屋の理屈も、
それはシステム屋がそのようにした(そのようなシステム上の仕掛けを採用した・開発した)のがおかしいのである。
今思えばナレッジマネジメントだった（その２）の最後に書いているように、単にファイルフォーマットとそのデータ形式の話にとどまらず、それを支えるAplication ArchitectureとData Architectureの両方に関しても、ユーザの素朴な要望に答えられないのが今の情報システムなのかも。
最後にユーザ視点で言われた一言が心に残った。
��一部、意訳あり。
「昔は、紙という共通フォーマット上に文書も数値もグラフも図も書かれており、
紙さえ見つければ(検索できれば)、あらゆるデータが参照できたのに。」
確かに、数値データを蓄えて、いろんな演算を行う上では、現在のRDBMSは最適化されたものだろう。
しかし、「人が見たいものを俯瞰的に見たい」ということをスタートラインにすると、RDBMSは個別最適の特殊なファイルシステムとアプリケーションと考えられなくもない。
Osekiは文書検索システムにして、RDBMSなんだがな。
返信削除> Osekiは文書検索システムにして、RDBMSなんだがな。
返信削除そうなんですか。不勉強で知りませんでした。
ちなみに、もとの記述は、
ある「ナレッジマネジメントシステム」の壁(限界)をもとに、
いわゆる「文書検索システム」の機能の限界を言いたかったことと、
単にRDBMSの中が検索できても、そのRDBMSのスキーマがわからないと、
単にテーブル内で検索出来ても意味がないので、もう一工夫必要である
ということを言いたかった訳です。
継続運用しそうなシステム間のインターフェースに柔軟性をもたせるため、インターフェースのスキーマをいかに知るかというところも作りこみすることがあります。この場合どうしてもスキーマ自体について定義した情報(メタ情報?)が必要になります。この定義によってスキーマを知ることが可能になります。
返信削除排他的なシステム間のインターフェースならこの作業もたいしたこと無いかも知れませんが、人間相手のインターフェースであるならスキーマを定義するところで一般化に一苦労。それを広くしらしめる手段で一苦労しそうです。