tonextone.com/type/

1. スキーマのモデリング技法のうち重要なものは、以下の 2 つ。

   第3正規形(3NF)

   汎用的な(最適化されていない、中立的な)スキーマ。
   マスター/ディテールもこっち。

   スタースキーマ

   データ・ウェアハウス用スキーマ。
   分類のキーとなる「ディメンジョン」表。
   各種「ディメンジョン」の組み合わせに対応する集計可能な値「メジャー」だけを含む「ファクト」表。
   

2. メタ設計よりも、サブタイプを使おう。
   まだ、ピンと来ないので、引き続き、調べ中。

参考URL:

スキーマのモデリング化技法

データウェアハウス関連用語　解説

1. 効果的なフィルターとして働くカラムを見つける。
2. なるべく早い段階で、そのフィルターを適用する。

例1: 結合する前にフィルター

結合する前にフィルタリングできるならば、そうしたほうが速いに決まっている。
-- before SELECT A.x FROM ( A JOIN B ON A.a_id = B.a_id ) WHERE B.y = 'foo' ; -- after (faster) SELECT A.x FROM ( A JOIN B ON B.a_id = A.a_id AND B.y = 'foo' ) ;
旧来の結合構文でも、同様。
-- before SELECT A.x FROM A, B WHERE A.a_id = B.a_id AND B.y = 'foo' ; -- after (faster) SELECT A.x FROM A, ( SELECT * FROM B WHERE B.y = 'foo' ) AS C WHERE A.a_id = C.a_id

例2: IN か EXISTS か？

サブクエリの内側のフィルターが効果的な場合は IN (非相関サブクエリ)
サブクエリの外側のフィルターが効果的な場合は EXISTS (相関サブクエリ)
ただし、相関サブクエリの結合キーには、インデックスを張るべし。
-- A.z = 'bar' が効果的なフィルターである場合、 -- ( B.a_id にインデックスを張るのを忘れずに ) SELECT A.x FROM A WHERE A.z = 'bar' ; AND EXISTS( SELECT * FROM B WHERE B.a_id = A.a_id AND B.y = 'foo' ) ; -- B.y = 'foo' が効果的なフィルターである場合、 SELECT A.x FROM A WHERE A.z = 'bar' ; AND A.a_id IN( SELECT B.a_id FROM B WHERE B.y = 'foo' ) ; -- この場合、以下のようにも書ける、 SELECT C.x FROM (SELECT * FROM A WHERE A.z = 'bar' ) AS C, (SELECT * FROM B WHERE B.y = 'foo' ) AS D WHERE C.a_id = D.a_id ; -- あるいは、 SELECT A.x FROM ( A JOIN B ON A.a_id = B.a_id AND A.z = 'bar' AND B.y = 'foo' );

ずっと dmoccur を使ってたんだけど、

( moccur-grep(-find)は、) find-file でファイルを開くことをしないので，dmoccur よりもはやく検索できますし，バッファが氾濫することもありません．

だそうで試してみることにしました。

で、まずは .svn/* とかを検索対象から省いてから速さを比較しようと思ったんだけれど、この「省き方」の情報が無い。

そんな中、 id:higepon さんが moccur を愛用しているようだったので質問させていただいたところ、
elisp を書いていただきました。ありがとうございました!!!

で、結論を言うと、
どうやら、 moccur-grep(-find) でも、 dmoccur の設定(dmoccur-exclusion-mask)を、利用してくれるようです。
color-moccur.el を読めないなりに読んでみると、どうもそのようです。

現在、以下のような設定で、試用中です。
(setq moccur-grep-default-mask "\\.\\(html\\|php\\|js\\|css\\)$") (load "color-moccur") (setq dmoccur-recursive-search t) (setq dmoccur-exclusion-mask (append '("\\~$" "\\.svn\\/") dmoccur-exclusion-mask)) (setq dmoccur-mask '("\\.\\(html\\|php\\|js\\|css\\)$"))
もともと dmoccur の設定があったせい(おかげ)で、
id:higepon さんから教えていただいた設定を追加しても(しなくても)状況が変化せず、ちょっと混乱してしまいましたが、
id:higepon さんの elisp も、期待どおりの動作をしています。

まだ、試用を開始したばかりなので、もしかしたら、この結論も正しくないかもしれません。
間違いなどあれば、ご指摘いただければ幸いです。

「セマンティック・ウェブのためのRDF/OWL入門」より抜粋。

すべてのものが URI で識別可能

ネットワーク上のリソースばかりでなく、人間、場所、事象も URI を通してウェブ上で識別されます。 URI という分散型の識別メカニズムを用いることで、誰もがセマンティック・ウェブに参加し、様々な情報を効率的に統合し、意味を明瞭に示すことが可能になります。

部分的な情報 Partial Information

セマンティック・ウェブは完全な情報を前提とした閉じた世界を扱う学問ではなく、部分的な情報しか知りえない実世界を対象にし、そこから有益な結論を引き出すことを目指しています。情報は、いつ誰がどこで記述してもよく、同じリソースに関する矛盾する情報が存在するかも知れません。「すべてを知っている人はいない」のです。誰もがどんなことについて何でもいえる（Anyone can say anything about anything）というキャッチフレーズは、セマンティック・ウェブが自由で拘束がなく、小さな情報を断片的に発信できるということと同時に、不完全な情報を前提とし、それを生かすことの重要性を示しています。

発展性 Evolution

分散型のウェブでは、さまざまなコミュニティや個人が、独自に情報を発信したり、知識の体系を整えたりします。同じ分野の情報が、異なる方法で記述されることもあるでしょう。これらの情報を統合したり、新しい知識を加える時に、古いものを犠牲にしなくてもうまく融合できること、別々のコミュニティどうしが同一性や矛盾をきちんとチェックできることは、このような分散型の世界が自立的に発展していくために欠かせない要件です。

最小のデザイン Mimimalist Design

セマンティック・ウェブでは、できるだけ制約を課さない、必要以上の標準化を求めない、シンプルなものはシンプルなままに、複雑なものは実現できるように解きほぐして（モジュール化して）、という方針で仕様を設計します。こうすることで、個別仕様の実装が容易になり、またそれに基づいた応用を柔軟に考える事が可能になります。

信頼のウェブ Web of Trust

ウェブにはいろいろな情報があり、そのコンテクストや信頼度はさまざまです。自分が良く知っているところからだけ情報を集めれば安心ですが、それではグローバルなセマンティック・ウェブの力を生かせません。セマンティック・ウェブでは、存在する情報すべてが信頼できると保証するのではなく、アプリケーションがコンテクストから信頼度を評価するために必要な仕組みを考えていきます。

↓この辺の動向も要チェック。
MQL SPAQL

ここ 10 年間ほど、シるという過程に対する私のイメージには、いつも Post-it が登場する。

それは、私の大学時代の学習法に関係がある。

最初は、自分が理解した(と思えた)事柄を紙のノートに書いていた。
新しい事柄が次々に登場するたびに、それらの相互関係を、ノートに反映させていく。
その当時は紙に筆記することに慣れていたので、しばらくはこの方法でやっていた。
しかし、そのうち書き直しが面倒になってきた。

次に、いわゆるルーズリーフを採用した。
前後関係を入れ替えたり、書き直したものに入れ替えたり、というのをページ単位でできるようになった。
しかし、それでも書き直しがあることに変わりなく、不満があった。

ここで、飛躍があり、
「できるだけ書かないようにしよう」と思った。
書かなければ、書き直す必要がない。

まず、良い教科書や、自分の思考に近い文書を見つけ、
その中の要点に、なるべく大きな付箋を貼る。
そして、必要であれば、そこに自分の理解の足跡を残していく。
何章の何節の何処とか何頁の何行目とか、ポインタを記入しておけば、
相互の関係も記述しやすい。
しかし、今度は教科書が膨れ上がっていった。付箋の厚みで。

最終的には、
付箋を貼っていた場所には、ID 番号だけを鉛筆で書いておいて、
その付箋自体は、ルーズリーフにバインドした無地の紙に貼ることにした。
ルーズリーフの返り咲きである。
教科書とルーズリーフとは 1 対 1 にして、章立てなども対応させる。


…と、前置きが長くなったが、
自分自身、相変わらず、上記と同じことをしているなぁ、と思うことが最近あった。

それは、プログラムのコーディング中。

私は、いずれ書き捨てのコードであるという前提で書き始める。

信用できる教科書の、あの部分とこの部分とを補完するストーリーを、
付箋に書くような気持ちで書き始める。

だらだらと手続き志向で書くのでメソッドが長くなるが、それで良いと思っている。

# 付箋と、メソッドとが対応しているイメージ？

理解が進んだら、付箋を張り替えるように、リファクタリングする。

よほど理解が進んだら、教科書の改定にコミットしたくなるかもしれない。

でも、どちらかというと、
教科書を参照しながら、具体的な状況のストーリーを記述するほうが
性に合っているんだろうな。

多分、理解する過程っていうのは、すごく個人差があって、
だから、チームのコードをキレイに保つのが難しいのだと思う。

関連: オブジェクト指向に対する抵抗感