- 締切済み
テーブル設計について教えてください。
- みんなの回答 （2）
- 専門家の回答
みんなの回答
- sava1
- ベストアンサー率66% (2/3)
安心してください nharasawa様の回答されたテーブルで十分です 数千万レコード、1秒間に100近い更新、リアルタイム表示 これらすべての条件が重ならない限り、別に回数などを記録しなくても 集約関数を使って（GROUP BY）集計(COUNT)すれば、安サーバー、ノートパソコンでも余裕ですｗ （HAVING句も使えばさらに応用の幅が広がります） 参考 集約関数 http://www.atmarkit.co.jp/fnetwork/rensai/sql03/sql1.html むしろ回数などのデーターを持ってしまうと、回数データの整合性をチェックするために 定期的に内部結合を伴ったクエリを発行しなくてはなりません。 おそらくこちらのほうが厄介です。←まあどんぐりの背比べですがｗ
- 原沢 信道（@nharasawa）
- ベストアンサー率53% (90/168)
そのテーブルの今後の利用方法によっては、構造を変える必要があります。質問のみで想定した場合は、会員番号、資料番号、確認時間（年月日時分秒ミリ秒）で記憶してゆく方法が一番簡単と思います。
関連するQ&A
- 効率のよいテーブル設計について
個人運営ですが、Win2000+Appache+MYSQLを使って会員性のブログのようなサイトをやっています。 DBの設計をなおそうと思っているのですが、以下、どちらの設計のほうが効率が良いのでしょうか。 １）会員毎にテーブルを用意しそこにブログを記録。 ２）１つのテーブルで会員全てのブログを記録。（会員番号にインデックス。） ご教授よろしくお願いいたします。
- ベストアンサー
- MySQL
- テーブル設計について
会員制の小さなサイトを運営しています。 会員は会員IDで管理しているのですが、テーブル設計が適切であるか判断できず、助言を頂きたく書き込みさせて頂きました。 現在、会員情報テーブル(info)というテーブルが全ての基本となっています。 このテーブルには、会員IDの他、名前や性別、住所、自己紹介文などほとんど全ての会員情報が含まれています。 このほかに会員同士の交流用のテーブル(koryu)がいくつかあり、 そこには、会員IDとその会員が行った内容が記録されています。 で、現状、交流用テーブルを使用する場合、常に会員の名前を会員情報テーブルから引っ張ってきており、これが、処理的に重いのでは無いか、と思っています。 以下はたとえばの例ですが、 select koryu.id, info.name, koryu.contents from info,koryu where koryu.id=info.id のように、毎回、（ほぼ）名前だけを引っ張ってきています。 引っかかっているのは、この「名前だけ」というところで、例えば、会員IDと名前しかないテーブルを作成すれば、もしかしたら、処理が軽くなるのでは・・と思っているのです。 ２０カラムあるテーブルと関連付けを行う場合と、２カラムのテーブルと関連付けを行う場合、 ２カラムのテーブルのほうが、処理は軽くなるのでしょうか？また、軽くなる場合、そうしたほうが良いのでしょうか？ （現在、１０００名くらいしか会員がいないため、処理が重いということは無いのですが、 安いサーバを使用しているため、処理はなるべく軽くしておきたいと思っています。） よろしくお願いします。
- ベストアンサー
- MySQL
- ショッピングサイトのテーブル設計について
練習でショッピングサイトを制作しています。 このサイトでは会員サービスもありますが、会員登録せずに商品を購入することもできます。 会員の場合、受注テーブルに会員コード(会員を一意に表す)があれば、それを元に会員テーブルから発送に必要な情報を取り出すことができます。 しかし非会員は会員テーブルに情報がないため、発送に必要な情報が別途必要になります。 非会員の情報はどこで管理するべきでしょうか？
- 締切済み
- MySQL
- データベースのテーブル設計について
データベースのテーブル設計で、数項目のみのデータをひとつのテーブルにしていますでしょうか？ すべてデータベース内で管理するという一貫性はあると思うのですが、たかだか数項目なのでどうかなとも思ってしまいます。 かといって、数項目のみのデータをプログラム内（たとえば構造体）で管理するというのも、管理が必要な要素が散らばるし、再コンパイルも必要になってきます。 このあたりどのようにすればよいのかなといつも判断に悩んでいます。 みなさんはどのように判断、設計していますでしょうか？ご意見お教えください。
- ベストアンサー
- その他(データベース)
- テーブル設計において
データベース（RDB）のテーブルを設計する際に、 データの連結の関係を考えた際に、連結の関係は簡単にしておいたほうがいいのかそれとも実登録データの量をとにかく少なくするように したほうがいいのかで悩んでいます。 今現在やっているのがデータベースのデータ量を少なくするためといって、非常にややこしくなっています。 正直今現在DBに登録するデータというのがテキストおよび数値データのみで、画像や動画といったバカデカイコンテンツデータは登録するようになっていないシステムにおいて、HDDやストレージがパンクするといったことがまずありえないぐらいの容量はあるんじゃないかなとおもっています。これってどうなんだろうと思って質問しています。皆さんはどう考えていますか？
- 締切済み
- その他(データベース)
- mysqlのデータベース設計(1テーブルで管理)
お世話になります。 現在、会員がログインしてブログ管理できる(記事を作成・編集できるシステム)を考えています。 そこでデータベース設計について質問があります。 一般的には、 ・ユーザー情報に関するテーブル ・ブログ記事に関するテーブル この２つを以下のような感じで設計すると思うのですが↓ ■usersテーブル ・id ・ユーザー名 ・パスワード ■articleテーブル ・id ・user_id(記事投稿者のid) ・contents(ブログタイトル、ブログ本文) ・created ・modified 私は、この２つを１つのテーブルですべてまとめて管理することを考えているのですが、 何かデメリットはあるのでしょうか？↓ ■usersテーブル(このテーブル１つですべてまとめて管理) ・id ・ユーザー名 ・パスワード ・contents(ブログタイトル|ブログ本文|記事投稿日|記事編集日) ・created ・modified ちなみにブログ記事は、区切り文字で分けながらcontentsにどんどん詰め込んでいき(updateする)、 取り出すときは区切り文字をexplodeしていく形を考えています。 実際にはもっと項目が多くなるのですが、１ユーザーの情報をすべて１つのテーブルで管理することで個人的に非常にわかりやすい、さらに単純なのでこちらのほうが速度も速いのではないかと思っているのですが、良くないのでしょうか？（あまり見かけないので） どなたか教えていただけると幸いです。 よろしくお願い致します。
- ベストアンサー
- PHP
- MySQLのテーブル設計について
PHPとMySQLを勉強中です。 データベースと連携させた「お気に入りのお店」を登録するような地図サイトを作ろうと思っているのですが、テーブル設計について疑問ですので、よろしければ教えてください。 ちなみにMySQLへ登録する項目は、 id（連番）、日付、ユーザーID、ユーザーパス、お店の名前、お店の住所、電話番号、HPアドレス、お店の写真 などを考えています。 １、効率のいいテーブルの設計とはどのようなものでしょう？ 素人考えでは、一括で管理したほうがよさそうだと思うのです。 ですが、他の方のスクリプトをダウンロードして見てみると、ほとんどテーブルが分割されていることが多いです。 どのような意図なのでしょう？？ ２、バイナリデータはbase64でテキストにしたほうがいいと本に書いてありましたが、テーブルも別にしたほうがいいのでしょうか？ ３、このような内容について、詳しい本などがありましたらぜひ教えてください。負荷分散とかバックアップなどについても勉強しようと思っています。 結局は、どのような使われ方をするかで設計が変わってくるような気がしますが、何分、勉強し始めたばかりでよく分かっていません。。 お手すきのときに教えてください。 よろしくお願いいたします。
- ベストアンサー
- MySQL
- テーブル設計につきまして(正規化)
顧客情報管理サイトを作ろうと思っています。 ・非正規化 {顧客コード , 氏名 , かな名 , 性別 , 郵便番号 , 都道府県 , 市区町村 , 建物名 , 電話番号 , FAX番号 , 携帯番号1, 携帯メール1 , 携帯番号2 , 携帯メール2 , 顧客ランク,備考} の列を考えております。 ・正規化テーブル 1.顧客情報テーブル {顧客コード , 氏名 , かな名 , 性別 ,郵便番号(外部キー) , 建物名 , 電話番号 , FAX番号 , 携帯番号1, 携帯メール1 , 携帯番号2 , 携帯メール2 , 顧客ランク,備考} 2.郵便情報 {郵便番号(主キー) , 都道府県 , 市区町村 これ以上、正規化できないと思っているのですが、顧客情報テーブルをもっと効率よく テーブルを設計し、正規化できるものでしょうか？ よろしくお願いします。
- ベストアンサー
- その他(データベース)
- テーブルサイズについて
環境 Oracle9i 9.2.0 OS Windows2003 Server 言語 Visual Basic6.0 自社の事務所移転に伴ってDB環境の再構築をすることになりました。 DB環境を作成し、インポート程度ならできますが、DBの見積もりなどの設計は未経験です。 DB管理者もいますので構築は進むとは思いますが、自分の知識が進まないと困るのでいろいろと質問したいと思います。 とりあえず、漠然と疑問点となっていることを以下に並べてみました。 １．表領域のサイズを決定する判断 ２．データファイルサイズを決める判断 ３．DBブロックサイズの判断 ４．再構築する為にチェックする内容 ３についてはマニュアル参照したのですが、設定が必要なブロックサイズは「標準ブロックサイズ」のみとなっており、ほとんどの場合、オペレーティングシステム固有のデフォルト・データブロックサイズで大丈夫と記述がありますが、その根拠はなんでしょうか？ ちなみにDBの詳細ですが、 マスタ系のテーブル数：４３ トランザクション系のテーブル数：５０ です。 200万件程度のテーブル数が１５ぐらいです。 最大で800万件のテーブルがあります。 件数程度じゃ詳細にならないと思いますが、こういうときのテーブルのサイズはどう調べたらよいのでしょうか？各テーブルごとの容量とかわかるのでしょうか？ その他気になることなどございましたらご指摘ください。 ご教授お願い致します。
- ベストアンサー
- Oracle
補足
ご回答ありがとうございます。 今後の利用方法としましては、 会員の方が資料を過去に何回開いたかをリスト形式で表示する、 全会員で資料を何回開かれているか、 などを表示したいと想定しております。 その場合、項目として別途カウントの項目を設けるのでしょうか。 よろしくお願いいたします。