[pgsql-jp: 31229] Re: テーブルの構造について

Chie.M gontakun_72 @ yahoo.co.jp
2003年 10月 20日 (月) 10:05:09 JST


Chieです。
ミーシャ様、大変判りやすい解説ありがとうございます。

> PostgreSQL の場合、「追記型」というデータ管理の方式を取っているため、
> 1カラムでもUPDATEをすれば、その該当レコードはオーバライトされず、
> 物理的には、新しいレコードがその分だけ追加され、
> 更新前のレコードは「ゴミ(不要領域)」として残ります。
> つまり、相当量のカラムを持つデータであれば、不要領域は
> かなりのものになります。
> (場合によっては、頻繁にVACUUMをかける必要が生じるでしょう)

なるほどそうですね!
そうすると、やはり性能的にもわけた方がいいですね。
・・・snip・・・

> 私の思う最善の方法は、Chieさんのおっしゃるとおり、
> 関連性の高いコンパクトなテーブルに複数分け、これを1対1で紐付けすることです。
> また、あくまで「問い合わせに特化」すると決めごとをした上で、VIEWなどを使うのがよいかと考えます。
・・・snip・・・
> ちょっと話が脱線気味になりますが、「正規化」、というもの自体がもともと冗長なものですし、
> 極端にパフォーマンスが落ちるようなケースでなければ、前者はあまり気にする必要はないと思いますし、
> 「構造的に」という点でいえば、前述のとおり、
> 長蛇の列を1件のレコードにまとめてしまうほうが、むしろ「よろしくない」と思います。
・・・
> PHPで
>  > pg_affected_rows()で件数の取得ができなかったりしますし。
・・・
> これも、きれいに分類がされていれば、むしろ、「どれかが更新された」、という情報よりは、
> 「このカラム(データ)が更新された」と明確に解って、むしろ望ましいのではないでしょうか?
> (どうしても「どれかが更新された」としての情報が必要であれば、
> 予め更新対象の行数を問い合わせておくしかないでしょうが・・・)

判りやすい解説ありがとうございます。

私は今まで自分の作っていたテーブルの作り方について
ずっと疑問に思っていたのですが、背中を押してもらったと言う感じです。
# こういう事を話せる知り合いはひとりもいないのです。
非常にスッキリしました。(^^)

本当にありがとうございました!
-- 
Chie <gontakun_72 @ yahoo.co.jp>




pgsql-jp メーリングリストの案内