sanryuブログ

（１）マルチバイトの使用は禁止。
　※理由はググッてください。
（２）開発前に命名基準書を作成する。
（３）全て英語またはローマ字で表記する。
　※できる限り英語。
（４）ローマ字で表記する場合、ヘボン式で表記する。

（１）同一の内容を示すカラム名は同一とする。
　　・当たり前と思うかもしれませんが、規模が大きいシステムだと複数人でテーブル設計をしていると、同じ物を指しているのに、違うカラム名だったりします。はっきり言って頭痛いです。
　　これを回避するには、システム開発用の辞書を作ったり、データベースモデリングツールを使ったりして対応します。
（２）○○フラグというカラム名の値は、0(false)または1(true)とする。NULLもNG。
　　・フラグと名前でいろんな値が入っていると訳が分からない。
（３）上記とかぶるが、○○フラグ、○○区分、○○分類、○○状態などのカラム名をよく見るが、適切な名前をつけること。

（１）サロゲートキーの使用。
　・自然キーには、ユニーク制約をつける。
（２）正規化くずし。
（３）トランザクションへの値の埋め込み。
　・マスタデータが変更される場合、計算結果を格納する場合など考慮。
（４）削除の方針。
　・論理削除か物理削除するか。
（５）マテリアライズドビュー（Oracle）の使用。
（６）固有の値の作成にシーケンスの使用。

（１）どのテーブルにも必要なカラム
　　「作成日」、「作成者」、「更新日」、「更新者」
（２）論理削除の場合に必要なカラム
　　「削除フラグ」、「削除日」、「削除者」
（３）世代（履歴）管理に必要なカラム
　　「使用（有効）開始日」「使用（有効）終了日」

トリガは使いたいが、こんな事があった。

　・仕様変更をしたとき、トリガだけ修正漏れ。
　（仕様書のどこにもトリガを使用していること書いてない。）
　・トリガに限って仕様書ない。
　（別にトリガの問題ではない。）
　・運用を実施する人がトリガを知らない。
　・当該テーブルのデータをメンテナンスする時に、トリガが動くのを忘れてしまう。

なので、下記程度にとどめたい。
　・監査ログや、テーブルの履歴の作成みたいなの。

結論は、システム開発から運用まで考えて、
保守できる程度に使用すればいいかと思う。

自分の周りの話です。世間ではどうなのでしょうか？

データ件数を考慮していないで設計・開発する為、
まともに動かないものが多いです。

（１）実行計画を取得しない。
ＳＱＬが自分の思ったとおりに実行されているか確認しない。

（２）実際のデータ件数を想定しない。
データ件数を考慮しない、データ件数がどのくらいか知らないでＳＱＬを作る。
※ＳＥがテーブル設計時にデータ件数を考慮しない。

（３）セオリー(チューニング含む)をやらない。
ＷＥＢでも、書籍でも、雑誌でもやらないでねと書いてあることを平気でやる。
かつ、やろうねと書いてあることをしない。

（４）システム標準ルールを無視する。
・・・・。

（５）実行時間の計測をしない。
・・・・。当然性能要件を守れない。

テーブルに制約を指定していない為に、想定(意図)していない値が設定されて、
アプリケーションが正しく動作しないことがあります。
個人的には、（１）～(３)は、必ず指定して欲しいです。
（４）（５）は、設計はして欲しい。

（１）主キー制約（PRIMARY KEY制約）
　主キーのないテーブルは、原則だめ。※一時テーブルのみ可。

（２）一意キー制約（UNIQUE制約）
　代替キーを使用し、かつ、一意となる自然キーがある場合は指定する。

（３）NOT NULL制約
　NULLがだめな項目には必ず指定すること。

（４）CHECK制約
　意図している値があるなら指定すること。個人的にはあまり使用しない。
　アプリケーション側でチェックしている。

（５）参照整合性制約（REFERENCES制約）
　いろいろご意見あると思いますが、個人的には、設計時（ＥＲ図など）には指定しているが、
　実際のテーブル(物理構造)には適用していない。
　※レスポンス、メンテナンス、仕様変更などを考えると・・・・。