概要 前回（PostgreSQLでテーブルの定義を確認する。 - Tihiroの頭を休めるIT教室）はPostgreSQLでテーブル定義を確認する、ということでした。 今回は、テーブルの制約を確認したいと思います。 例によって環境は PostgreSQL9.6 です。 確認してみる メタコマンドで確認してみる 前回、テーブル定義を確認したのと同じく ¥d テーブル名 で確認できます。便利ですね！ SELECT文で確認してみる メタコマンドとは違って、SELECT文で制約を確認するのは少しめんどいです。なぜなら、情報スキーマ内の複数のビューを参照する必要があるからです。 めんどいことは細かく分解して解決するのが一番です。 ということで、 主キー制約 CHECK制約 外部キー制約 ユニーク制約 の４つに分けて確認してみます。 1.SELECT文で主キー制約を確認する テーブルの主キー*1を確認
NTT オープンソースソフトウェアセンタ 板垣 貴裕 PostgreSQL でロケール (国際化と地域化) の設定を行うと、データベース内での文字列処理、日付や通貨の表示、メッセージの言語などを変更することができます。特に PostgreSQL 8.4 では、日本語のメッセージ・カタログが追加されたため、エラーメッセージを日本語化したい場合にはロケールを設定する必要があります。 ただし、C ロケール以外を設定すると、インデックスが使われないなどの性能への影響がある場合もあります。また、特に古いバージョンの PostgreSQL では、誤った設定によりサーバが正しく動作しなくなるケースもありました。 この記事では、ロケール設定の効果を結果例を交えて解説すると共に、トラブルへの対応方法を示します。PostgreSQL で日本語を扱う際に、ロケール設定を決める時の参考にして下さい。 Postgr
中古マンション購入の際に一番大きな悩みは、購入価格が適正かどうかということです。不動産屋はなんとかしてマンションの売買を成立させたいというモチベーションがあるので、そもそも完全に信用出来ないですし、かと言って市場調査を素人がすることが難しいのが現状でした。しかし、以下の記事で紹介されている「住まいサーフィン」でなんと過去のマンションの中古の売買記録が公開されており、そちらを見ればだれでも過去の中古マンションの価格を確認できるようになりました。 http://business.nikkeibp.co.jp/article/opinion/20111007/223066/ マンションの適正価格・資産価値・査定情報｜住まいサーフィン (「マンション検索」で該当マンションを検索して、「中古事例」の一覧をクリックで確認可能です。) このDBが信じらないくらいデータが詰まっており、試しに近くのマンショ
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
