![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#navi(雑記2009) 加盟店用非公開プログラムの修正作業。 あまりチェックしていなかったが、ブラウザーによって動作エラーが生じる場合があった。 ---- 目録少々追加。 プログラム弄りしていると、中途でやめるわけに行かないから目録追加ペースがガクンと落ちる。ここのところ申し訳程度の追加状態が続いている。 6:00 室温18度。随分暖かくなってきた。これから雨らしい。 昨夜うとうとしていて、とあるプログラムアイデアが閃いた。 1年半前から作り始めサーバー交換などで途中中断しているプログラムに関するアイデア。 これを実現するには、今少し下準備がいる。 まだ思考回路は柔軟だ。作業ペースはひどくのろまだが・・・・。 SQLにおける[[関係論理:http://ja.wikipedia.org/wiki/%E9%96%A2%E4%BF%82%E8%AB%96%E7%90%86]]。 この本質的意味がイマイチ解らない。つうか、納得できない。結構曖昧な定義のままで使用が優先されてきたような感触がある。 要するに未完成であるにもかかわらず、枝葉の方ばかり組み上げられ使われて来ているような気がする。 データベースの設計プロセスというものが、人間の通常思考プロセスに則っていない、そんな感じ。そこに違和感を覚える。この事は拡張性という事とも関わってくる。 事物を集め整理するという作業プロセスを考える時、当初想定し得なかった事物が見つかった時、どのように設計方法の変更を行うか、その部分が想定されていない。そんなこと。 ---- 2次元平面上に、bit単位のxy座標系を作り、 そのある一定範囲に、データベース領域（表組み）を作る。 固定長の場合、データへのアクセスは、座標ポイントで行う。 項目位置は、固定されたx座標と変動的y座標で決まる。項目特定には列単位の走査だけでよい。 可変長の場合、項目特定のためには列単位と行単位で走査する必要があるので、別途index領域を作成し、その部分を固定長にしておき、リレーションをとる。 物理的にはこのxy座標系はHDD上に作成されるから、128bitの整数倍で固定長領域が形成されていれば走査に無駄がない。 てなことがデータ処理なのだけれど、SQLってのはこうして作られたデータMapへのアクセス言語で、データ本体のMap構造が奥に追いやられ、intarfaceだけの理解で使えるというのは便利なようでいて、処理Logicが良く解らぬという事が起きる。 現在作っている、書誌詳細へのアクセスは、file名・書店コード・書籍コード・データ品番の4要素で行うようにし、解析すれば又そのように表示されるが、実際には、データ品番に重複がなければ、データ品番の1要素だけで処理できる。 file名・書店コード・書籍コードは、処理を高速化する為の副次要素・index代参に過ぎない。 この内書店コードと書籍コードは、これを組み込むことで、外部に対して汎用性が生まれる。 又、書店コードと書籍コードでindexを作成すれば、汎用性の面に置いては、データアクセスを一意的に処理できる。 ---- 19:30 室温24度。異常だ。 ---- #comment
