mysql:13109
From: "F.Y" <"F.Y" <fumi_sby@xxxxxxxxxx>>
Date: Sun, 25 Jun 2006 21:23:12 +0900 (JST)
Subject: [mysql 13109] Re: テーブル設計について
答えにくい話だなや。 「効率的」がわからん。開発効率、メンテナンス効率、ディスク使用率上の効 率、ファイルI/Oの効率、動作速度、などなど。 がんばって時間を作り出して、何種類も作ってみると糧になると思う。 わしならたいていは1の方法をとるけど、ピックアップアイテムが5つ以内だと か条件が絞れてマスタメンテ画面作る気力がわかないときは顧客マスタに持た せるかもしれない。ケースバイケース。 レコード数が多いってことは現代においてはあまり気にしないと思う。わしゃInnoDB がキライでMyISAM命だけど、800万や1000万レコードならものの数ではない。考 えてもみよ、なんたらIDとなんたらIDとなんたらIDなどでint型を3つ4つもつと して、1レコード30byte程度、1000万レコードあってインデックスはりまくって いたとしても500MB程度でしょ。いまどきのCPUといまどきのメモリ搭載量とい まどきのHDDなら気にすることはまったくない。 --- 荒木 満 <araki@xxxxxxxxxx> からのメッセージ: > いつも勉強させてもらっております。 > > 早速ですが、テーブル設計について皆さんのご意見を頂きたくお願いいたし ます。 > > 現在、会員制ショッピングサイトのようなものを製作中なのですが、 > 会員が気に入った商品を「お気に入りに追加」、というようにして登録でき るようにしたいのですが、 > このデータをどのように保存するのが効率的なのでしょうか? > 例えば商品のデータを格納する、syouhinテーブルと、会員のデータを格納す る、memberテーブルがあり、 > それぞれに、id というプライマリーキーがあるとして、 > 1.syouhin_id と member_id というカラムを持つfavarit > というお気に入り専用のテーブルを作り、ここのテーブルにレコードを追加 していく。 > 2.member テーブルにカラムを追加し、syouhin.id > のデータを追加していく。 > > 1の方法だとレコードの数がかなり多くなってしまうと考えられますがどうで しょうか? > > その他、効率的な方法などございましたらご指摘いただけませんでしょうか ? > よろしくお願い致します。 > > > > -------------------------------------- Let's start Yahoo! Auction - Free Campaign Now! http://pr.mail.yahoo.co.jp/auction/
13107 2006-06-25 13:50 [荒木 満 <araki@xxxx] テーブル設計について -> 13109 2006-06-25 21:23 ┗["F.Y" <fumi_sby@xxxx] 13111 2006-06-26 17:33 ┗[荒木 満 <araki@xxxx]