- ベストアンサー
MySQLのテーブル設計について
- MySQLのテーブル設計について効率と使いやすさを考える
- バイナリデータの管理や負荷分散、バックアップの勉強も必要
- 詳しい本や参考資料を教えてほしい
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
関連するQ&A
- ＭｙＳＱＬの行儀のいいテーブルってどんなのですか？
独学なので、どういったものが行儀がいい、もしくは、きちんとしたテーブルの構成なのか分かりません。 とりあえず悩んでいるのが、テーブルを二つに分けるか、一つのままにするかです。 フリーのMySQLの掲示板を見ると、名前、パスワード、コメントが一つのテーブルもあります。 私は、ユーザー情報を他でも利用したいので、自作で ユーザーテーブル ID、名前、パスワード ＢＢＳテーブル ID、コメント と、したいのです。 とはいえ、書き込み時に二つのテーブルに書き込み。 表示の時は、結合してから、表示。 サーバの負荷は、テーブルが一つの時と比べて、どれくらい違うのでしょうか？ 普通開発する時は、テーブルの数は意識するものなんでしょうか？ 前に、「個人のＨＰのデーターベースでは、無茶してもＯＫ」(かなりの意訳あり)とお許しを頂いたので、負荷の事は気にしない事にしたのですが。 テーブル一つで作成したので、作り替えるのが面倒で、okwebで現実逃避しているという事もなきにしもあらずです。
- ベストアンサー
- MySQL
- テーブルの設計についてアドバイスください
MySQL5を使用しています。 あるプレゼントコンテンツを作ろうとしているのですが、1箇所、懸念点がありなにかいい方法がないかアドバイス頂ければと思います。 presets（プレゼントテーブル） ------------- id users（会員テーブル） ------------- id tickets（応募可能テーブル） ------------- id present_id user_id left_ticket（応募可能数） logs（応募履歴テーブル） ------------- id present_id user_id is_prize（当選したかどうか） 仕様 ・各プレゼントへの応募可能数は、ユーザ／プレゼントによって違う（=left_ticket） プレゼントを新規登録する際に、ticketsテーブルに全ユーザ分のレコードを登録しなくてはならず、数十人程度なら良いんですが、数百人～数千人となると非現実的かなと思っています。 なにか良い方法はありますでしょうか？
- ベストアンサー
- MySQL
- mysqlのデータベース設計(1テーブルで管理)
お世話になります。 現在、会員がログインしてブログ管理できる(記事を作成・編集できるシステム)を考えています。 そこでデータベース設計について質問があります。 一般的には、 ・ユーザー情報に関するテーブル ・ブログ記事に関するテーブル この２つを以下のような感じで設計すると思うのですが↓ ■usersテーブル ・id ・ユーザー名 ・パスワード ■articleテーブル ・id ・user_id(記事投稿者のid) ・contents(ブログタイトル、ブログ本文) ・created ・modified 私は、この２つを１つのテーブルですべてまとめて管理することを考えているのですが、 何かデメリットはあるのでしょうか？↓ ■usersテーブル(このテーブル１つですべてまとめて管理) ・id ・ユーザー名 ・パスワード ・contents(ブログタイトル|ブログ本文|記事投稿日|記事編集日) ・created ・modified ちなみにブログ記事は、区切り文字で分けながらcontentsにどんどん詰め込んでいき(updateする)、 取り出すときは区切り文字をexplodeしていく形を考えています。 実際にはもっと項目が多くなるのですが、１ユーザーの情報をすべて１つのテーブルで管理することで個人的に非常にわかりやすい、さらに単純なのでこちらのほうが速度も速いのではないかと思っているのですが、良くないのでしょうか？（あまり見かけないので） どなたか教えていただけると幸いです。 よろしくお願い致します。
- ベストアンサー
- PHP
- MySQLでのテーブル設計(SET型)の使用有無について
MySQLのSET関数を使う場合、汎用性はなくなりますが、それ以外の メリット、デメリットが知りたいです。 http://www.itmedia.co.jp/enterprise/0308/24/epn01.html を見たのですが、使用すべきかの判断がつきません（><） 以下のようなシステムを考えています。 ■メールマガジン配信 以下、ユーザーがチェックした材料が含まれる料理が投稿されると 1日1回メール配信されます。 このような場合、テーブルに、SETを持つべきか 項目毎にカラムを持つべきか迷っています。 好きなフルーツ（項目はこちらで指定し５～７種類） ・りんご ・ぶどう ・いちご ・バナナ ・キウイ 好きな食べ物の色（項目はこちらで指定で５色） ・赤 ・黄色 ・緑 ・しろ ・茶色 ■現時点でのテーブル設計 ★ユーザーマスタテーブル PK user_id - その他15ぐらいのカラム ★メール配信テーブル PK user_id - f1 - f2 - f3 - f4 - f5 - c1 - c2 - c3 - c4 - c5 このテーブル設計は正しいでしょうか？
- ベストアンサー
- MySQL
- 効率のよいテーブル設計について
個人運営ですが、Win2000+Appache+MYSQLを使って会員性のブログのようなサイトをやっています。 DBの設計をなおそうと思っているのですが、以下、どちらの設計のほうが効率が良いのでしょうか。 １）会員毎にテーブルを用意しそこにブログを記録。 ２）１つのテーブルで会員全てのブログを記録。（会員番号にインデックス。） ご教授よろしくお願いいたします。
- ベストアンサー
- MySQL
- 人気記事（ランキング）表示に関するDB設計や方法
DBのテーブル設計と実装について教えて頂けると嬉しいです。 登録制サイトで、記事を投稿して閲覧者がお気に入りに登録できるような仕組みを作っています。 トップページ等で「人気の記事」を表示する際、お気に入り登録数が多いものを表示させたいと思っています。 このような場合、どのようなテーブル設計や方法を取るのが良いのでしょうか？ ３つ方法を思いつきますが、どれも一長一短なのかなという気がしています。 （テーブル設計の例） 「posts」テーブル ： post_id, user_id, text 「favorites」テーブル： favorites_id, user_id, post_id 「users」テーブル ： user_id, user_name （方法１）お気に入り登録数をテーブルに持たない（都度カウント処理する） トップページ表示の都度、「favorites」各記事のお気に入り登録数をカウントして（post_id で group byしてcountする）、登録の多い記事を表示させます。シンプルな方法ですが、レコード数が多い場合の負荷を心配しています。 （方法２）お気に入り登録数をテーブルに持つ お気に入り登録数を「posts」テーブル内に保持させます。 「posts」テーブル ： post_id, user_id, text, favorite_count 閲覧者がお気に入り登録した場合は「favorites」テーブルへの追加を行うと供に「posts」テーブルの「favorite_count」を更新します。トップページ表示の際は「posts」テーブルの「favorites_count」を見に行って多いものを表示させるだけなので負荷の心配は減ります。しかし、冗長な？データをテーブルに持つのは何か嫌な気がしますし、またプログラム実装が少し困難になります。 （方法３）人気の記事テーブルを別に持つ バッチ処理を1日1回等走らせ、登録数の多い記事をサーチして「人気の記事」テーブルに格納します。トップページでは、この「人気の記事」テーブルを見に行って表示させるだけになりますので負荷が減ります。しかし、リアルタイムな情報を表示できないのが残念です。 環境は、MySQL5.1、PHP5.2.17 となります。 アドバイス等頂けましたら嬉しいです。
- 締切済み
- MySQL
- MySQLのテーブル設計で迷っています(桁数)
MySQLのテーブル設計で迷っています。 クリエイト文のカッコの中は桁数を表しているのでしょうか？それともバイト数でしょうか？桁数であれば、それぞれの型で何桁まで設定できますでしょうか？ int型のnoを18桁に変更したいのですが、調べているうちに迷ってしまいました。 型 バイト 最小値 最大値 TINYINT 1 -128 127 SMALLINT 2 -32768 32767 MEDIUMINT 3 -8388608 8388607 INT 4 -2147483648 2147483647 BIGINT 8 -9223372036854775808 9223372036854775807 CREATE TABLE `user` ( `no` int(8) unsigned NOT NULL auto_increment, `id` varchar(24) NOT NULL default '', `email` varchar(255) NOT NULL default '', `reg_date` datetime NOT NULL default '0000-00-00 00:00:00', PRIMARY KEY (`no`) ) TYPE=MyISAM;
- ベストアンサー
- MySQL
- テーブル設計について
会員制の小さなサイトを運営しています。 会員は会員IDで管理しているのですが、テーブル設計が適切であるか判断できず、助言を頂きたく書き込みさせて頂きました。 現在、会員情報テーブル(info)というテーブルが全ての基本となっています。 このテーブルには、会員IDの他、名前や性別、住所、自己紹介文などほとんど全ての会員情報が含まれています。 このほかに会員同士の交流用のテーブル(koryu)がいくつかあり、 そこには、会員IDとその会員が行った内容が記録されています。 で、現状、交流用テーブルを使用する場合、常に会員の名前を会員情報テーブルから引っ張ってきており、これが、処理的に重いのでは無いか、と思っています。 以下はたとえばの例ですが、 select koryu.id, info.name, koryu.contents from info,koryu where koryu.id=info.id のように、毎回、（ほぼ）名前だけを引っ張ってきています。 引っかかっているのは、この「名前だけ」というところで、例えば、会員IDと名前しかないテーブルを作成すれば、もしかしたら、処理が軽くなるのでは・・と思っているのです。 ２０カラムあるテーブルと関連付けを行う場合と、２カラムのテーブルと関連付けを行う場合、 ２カラムのテーブルのほうが、処理は軽くなるのでしょうか？また、軽くなる場合、そうしたほうが良いのでしょうか？ （現在、１０００名くらいしか会員がいないため、処理が重いということは無いのですが、 安いサーバを使用しているため、処理はなるべく軽くしておきたいと思っています。） よろしくお願いします。
- ベストアンサー
- MySQL
お礼
詳細にありがとうございます！ よく分かりました。 正規化というのですね。疑問が解消されてすっきりです。 また、blobで保存とbase64encodeはデータベースへの格納方法が別だと思っていました。。 blob形に指定したmysqlテーブルにbase64encodeでテキスト化して入れるということですね。 とにかく色々といじってみます。 親切にありがとうございました。