- PR -

一テーブルのカラム数について

1|2 次のページへ»
投稿者投稿内容
どんたくお
ベテラン
会議室デビュー日: 2005/08/29
投稿数: 88
投稿日時: 2005-11-23 22:18
みなさん、こんにちは。
どんたくおです。


今回もまたテーブル設計に関しましてです。

RDBMSはPostgreSQL 7.4を想定しております。


現在、項目が20カラム近くあるテーブルの設計を行っています。
20個あるうちの15個は、商品名と価格が入ります。

CREATE TABLE test(
id serial,
title varchar(100),
goods_name1 varchar(100),
goods_price1 integer,
goods_name2 varchar(100),
goods_price2 integer,
<snip>
goods_name15 varchar(100),
goods_price15 integer
);
// 途中のgoods_nameとgoods_priceを省きました。m(_|_)m

テーブルのSQL文は以上のような感じになります。
そこで、ご質問なのですが、今回
goods_name
goods_price
は、15個ありますが、同じテーブルに羅列してよいものかと少し疑問に思いました。

あまり深くRDBMSを理解していないせいか、テーブルにたくさんのカラムを持つことをどうしてもきらう傾向が僕にはあります。
goods_name
goods_price
をテーブルにして、
CREATE TABLE test_goods(
id integer,
no integer,
goods_name varchar(100),
goods_price integer,

primary key (id, no)
);
のようにしてもよいのかなと思いました。
こうした場合、たとえば現在15となっている項目の束も、20個なり30個なり変更になった場合でもテーブル的に何か操作する必要がないのかなと思いました。


ひとつのテーブルにたくさんのカラムを持つことが、あまりよくないことなのか。
また、テーブルにカラムが沢山あった場合、SELECTやINSERTなどでパフォーマンス低下があるのかご存知の方がおいでましたら、ご教授いただければと思います。

すみませんが、よろしくお願いします。m(_|_)m
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-11-23 22:43
冗長化していると (一般的に) パフォーマンスが良いという利点があります。
ただし、テーブル設計の変更に弱いです。

普通はやりません。(私は)
しかしながら、幾度となく見てきています。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
ina
ベテラン
会議室デビュー日: 2005/04/14
投稿数: 58
投稿日時: 2005-11-24 02:12
テーブル設計を行う上で「正規化」というのはとても大事ですので、ネット等で「正規化」について調べることをお勧めします。

これが理解できると「横に持つべきか？」「縦に持つべきか？」といった疑問は自ずと解消できますので。
Java僧
ぬし
会議室デビュー日: 2003/11/06
投稿数: 261
投稿日時: 2005-11-24 08:48
「DBを正規化すると遅くなる」は誤解だそうです。

実体験から感覚的になんとなくそんな気がしていましたが、
実証結果を発表したプロジェクトがあります。

http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/

が、私も横にずらっと並んだカラムを幾度となく見てきています。
設計に携わる方は「正規化」については知っておいてもらいたいものです。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-11-24 10:50
引用:

「DBを正規化すると遅くなる」は誤解だそうです。

提示されてるページを読んでみましたけど、なんか眉唾モノですね。説得力がないと思います。

引用:

複数テーブルにわたって検索処理をするときには，非正規化すると処理性能は極端に落ちる。

複数テーブルにわたる結合処理をしなくても済むように冗長に項目を持たせるのでは？ 複数テーブル結合しないといけない時点で、十分な冗長化が行われていないと思います。確かに冗長化設計でもテーブル結合が必要なケースは多くありますが、その場合でも適切にインデックスを作成していれば、正規化設計に比べて『処理性能は極端に落ちる』ということはないと思います。

引用:

複数テーブルで同じ項目を持つことになる。その項目が検索対象になると，その項目を含め，複数のテーブルから値を集計するようなケースでは，テーブルの結合処理が多く発生するため(非正規化されたデータベースの場合は遅くなる)

これも意味が分かりません。どなたか理解できた方いらっしゃいますか。

私は当該ページを、正規化を推奨するためのプロパガンダと感じました。正規化だけでなく、適切な冗長化がよりよいパフォーマンスを生むと考えている私は、あのページの内容にはまったく同意できません。
今川 美保(夏椰)
ぬし
会議室デビュー日: 2004/06/10
投稿数: 363
お住まい・勤務地: 神奈川県茅ヶ崎市
投稿日時: 2005-11-24 10:56
単純に15個の配列にしてはいけないのでしょうか？
#添え字などの注意が必要になってしまうかもしれませんが。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-11-24 11:35
引用:

未記入さんの書き込み (2005-11-24 10:50) より:
引用:

複数テーブルで同じ項目を持つことになる。その項目が検索対象になると，その項目を含め，複数のテーブルから値を集計するようなケースでは，テーブルの結合処理が多く発生するため(非正規化されたデータベースの場合は遅くなる)

これも意味が分かりません。どなたか理解できた方いらっしゃいますか。

たぶんね、たとえば仕入れテーブルと、販売テーブルがあったとします。冗長化の結果、双方のテーブルに商品名を格納していた場合、商品コードと商品名の双方で結合する必要があると言いたいのだと思います。

でも反対意見として「結合するのは商品コードだけで十分だ！」とか「テーブルの論理状態が正常か確認するためにも商品名での結合が必要だ！」とか「論理状態の検証は別のタイミングでやっておけば十分だろ！」とか出てくるでしょうね。

冗長化した場合と、正規化した場合、どちらがより高速に動作するかは相反する条件が多くて一概には言えません。冗長化を行うと、データI/Oの増加、キャッシュヒット率の低下、インデックス増加に伴う更新時の速度低下、バグや誤操作による論理構造破壊のリスク増加、破壊を検出&訂正するための処理など遅くなる要因がいくつもあります。

引用:

私は当該ページを、正規化を推奨するためのプロパガンダと感じました。正規化だけでなく、適切な冗長化がよりよいパフォーマンスを生むと考えている私は、あのページの内容にはまったく同意できません。

私もすべての場合において、正規化してもパフォーマンスが変わらないとは考えていません。あの記事は「正規化したからといって必ずしも遅くなるわけでは無い。無闇に冗長化を行うのは速度向上のメリットを得られず、保守性を低下させるだけに終わるかもしれない。」程度に理解しておけばよいのではないかと。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-11-24 12:19
引用:

あの記事は「正規化したからといって必ずしも遅くなるわけでは無い。無闇に冗長化を行うのは速度向上のメリットを得られず、保守性を低下させるだけに終わるかもしれない。」程度に理解しておけばよいのではないかと。

その通りですね。

あの報告では「正規化したからといって必ずしも遅くなるわけでは無い。」という表現ではなく「冗長化すると極端に性能が低下する」という表現になっているので、プロパガンダだと評しているのです。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）