検索
カレンダー
2017年8月
« 4月    
 12345
6789101112
13141516171819
20212223242526
2728293031  
ブログメニュー
Amazon検索
キーワード:

SQL Server でカラムのデフォルト値を削除する方法

2012年12月18日

DB関連の記事を投稿しまくっているので、調子に乗って SQL Server についても書いてみます。

SQL Server では、カラムのデフォルト値は制約になっているみたいで、
普通に ALTER TABLE table_name ALTER COLUMN column_name INT みたいにしても
デフォルト制約は削除できませんでした。

これを削除するには(すんごい面倒ですが)以下の様にする必要があります。

(続きを読む…)

PostgreSQLで自動採番した値を取得するコツ

2012年12月18日

前回に引き続き、Statement#getGeneratedKeys() メソッド関連です。

PostgreSQLではserial型などで自動採番できますが、
INSERT 後の Statement#getGeneratedKeys() メソッドで
採番された値を取得できない場合があります。

採番された値を取得するには CREATE TABLE で
自動採番したいカラムを一番最初に定義する必要があります。

例:

CREATE TABLE table_name (
  id SERIAL,
  value VARCHAR,
  PRIMARY KEY (id)
)

…この問題に対する正式なドキュメントは見つかりませんでした。

今更ながらOracleの自動採番について調べて(ハマって)みた

2012年12月16日

ご無沙汰しております。

最近Oracleを少し触ってみて自動採番でハマったところがあったのでメモ。

(続きを読む…)

WHERE句でエイリアスを使う

2010年10月14日

PostgreSQL(や他の大多数のDBMS)で、次のようにWHERE句でエイリアスを使うとエラーになってしまいます。

SELECT name, AVG(income) AS a FROM employee WHERE a>100 GROUP BY name;

WHERE句でエイリアスを使うにはどうすればいいか聞いたのでメモ。

(続きを読む…)

レコードを他のテーブルにコピーする

2006年12月21日

履歴用テーブルとマスタ用テーブルなど、カラム構成が同じテーブル同士でレコードをコピーしたい場合があります。
このような時は下記のようなSQLを使います。

INSERT INTO table1 SELECT * FROM table2;

複数のテーブルを組み合わせたDELETE/UPDATE

2006年12月20日

他のテーブルと関連した検索条件で抽出した複数のレコードを、
DELETEしたりUPDATEしたりするには下記のようにサブクエリ(副問い合わせ)を使います。

(例)
DELETE FROM table1 WHERE column1 IN (SELECT column1 FROM table2 WHERE ...);

複数のカラムでプライマリーキーになっているテーブルがあると、複数のカラムで比較する必要がでてくると思います。
複数のカラムで比較したい場合は、下記のように複数のカラム名をカッコで囲んで書きます。

(例)
DELETE FROM table1 WHERE (column1, column2) IN (SELECT column1, column2 FROM table2 WHERE ...);

EXPLAIN句を使ったインデックスの設定

2006年11月1日

リレーショナルデータベースのテーブル設計を行っていると、どのカラムにインデックスをつければよいかがよくわからなくなってしまうのは私だけではないと思います。
DBMSがMySQLやPostgreSQLの場合、私はEXPLAIN句を使ってインデックスのつけ忘れがないかをチェックするようにしています。
EXPLAIN句を使うとSELECTクエリの実行計画が表示されるようになり、この情報を元にテーブルのインデックスを設定していきます。

MySQLの場合

EXPLAIN SELECT …

を実行すると表示されるテーブルのうち、チェックすべきカラムは「type」です。
このtypeカラムに「ALL」と表示されているレコードがあれば、そのテーブルのインデックスを見直す必要があるかもしれません。

PostgreSQLの場合

EXPLAIN SELECT …

を実行すると表示される「QUERY PLAN」に「Seq Scan on」から始まる行がある場合、onの後に続くテーブルのインデックスを見直す必要があるかもしれません。

(注意)
テーブルのインデックスは万能ではないので、何でもつけていればよいというわけではありません。
インデックスをつけすぎると更新性能が低下してしまいます。
またデータの種類によってはインデックスをつけても検索速度の向上が見込めない場合があります。
その最たる例はブーリアン値や性別のような限られた少ない種類のデータしか格納されないカラムです。
DBMSによっては、こういったデータ用のインデックス技術が実装されているようですが…。

参考:
PostgreSQL 文書
MySQL 4.1 リファレンスマニュアル