質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

パフォーマンス

コード効率の向上や計算に関する質問には、このタグを使ってください。

Q&A

解決済

4回答

326閲覧

一覧画面表示用のテーブル

annderber

総合スコア98

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

パフォーマンス

コード効率の向上や計算に関する質問には、このタグを使ってください。

0グッド

1クリップ

投稿2018/01/11 11:05

編集2018/01/11 11:08

お世話になります。

一般的な業務システムなどで、一覧画面がありそこから詳細画面に飛ぶというというような処理があると思います。
テーブル構成は一覧画面用テーブルが親で、子に明細テーブルが紐付くというような感じです。
ここで一覧画面に明細テーブルにあるデータを表示したいという要件がでてきた場合、テーブルを結合する必要が出てきますが、結合するテーブルの数がかなり多くパフォーマンスの問題が発生してしまいます。

という想定で、一覧画面用に詳細テーブルのデータを登録するフィールドを設けるのはアリでしょうか。
同期する必要があったり、親子関係がおかしくなったりする気もしますし。
アリだとすると設計方法のグッドプラクティスはあるのでしょうか。

そもそもパフォーマンスの問題と言ってもレコード数によっても変わってくると思います。
例えば、ページャーなどで一覧画面に表示できる件数を20件程度に絞ってからjoinをかければ
パフォーマンス的にはそれほど問題ならなくなったりするのでしょうか。自分で調べろと言われそうです。。。

よろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

リレーションが複雑でパフォーマンスがでないのであれば
サマリーをつくっておくのは悪くない選択肢だと思います
ただし期間を絞って締め処理など行わないと、サマリーをつくる範囲が
つねにデータの先頭からになってしまうので、確定データの運用方法については
設計段階で熟慮が必要です

投稿2018/01/12 01:26

yambejp

総合スコア114572

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

annderber

2018/01/12 01:43

コメントありがとうございます。 単純に明細テーブルのデータを更新する際に同一トランザクションで親テーブル側も更新するというのでは問題あるのでしょうか。
yambejp

2018/01/12 01:45

具体的なサンプルの例示がないのでなんともいえません 子データを投入すると紐付いた親データのidを元に親データ管理テーブルの内容が 更新されるイメージでしょうか? であればトリガーを設定しておけばよいかもしれません。 ただし例えば、親データp1対して子データc11,c12、親データp2対して子データc21,c22,c23が ぶら下がっているとして、c21の親情報をp2からp1に変更するときは p1とp2両方に対してサマリーの更新が必要になります。 漏れがないよう仕様を検討してみてください
annderber

2018/01/12 06:46

すいません。 なぜトリガーを使うといいのかが分かりません。
yambejp

2018/01/12 07:40

> なぜトリガーを使うといいのか 入力をすると自動的に別テーブルを更新できるからです
annderber

2018/01/12 07:44

なるほど同じデータを入れるならトリガー使った方がいいですね
guest

0

一覧画面用に詳細テーブルのデータを登録するフィールドを設けるのはアリでしょうか。

は、要件内容や前提条件、制約条件によると思います。

個人的な見解になりますが、
基本的には、一覧画面に詳細テーブルのデータを登録するフィールドを設けるのはお勧めしないです。

一覧画面に登録・編集機能を設けた場合、一覧に表示しているデータは、他の誰かに編集されないようにロックを行う必要が出てきます。

課題(機能仕様として設計しておくべき内容)としては、次のようなことが考えられます。
・一部のデータがロックできなかった時の扱い
・一部のデータを更新できなかった場合の扱い
・一部のデータのロック解除に失敗した場合の扱い など

データレコードをロックするのではなく、テーブルロックや画面ロック(誰かが開いていれば、他の人は開くことができない)であれば、いくつかの課題はクリアできますが、利便性の問題が出てきます。
(基幹系システムなどで、一人しか処理ができない仕組みは致命的です)

ただ、利用者が1名しかいない場合などは、問題ないかもしれません。

投稿2018/01/11 20:22

Shara

総合スコア125

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

annderber

2018/01/12 01:38

コメントありがとうございます。 質問としては親テーブルに子テーブルのサマリー用のフィールドを設けるのはアリかというものです。 一覧画面に登録編集機能を設けるということではありません。
guest

0

個人的意見ですが、
そもそも、一覧用のテーブルがあるのが、おかしいと思います。
詳細画面のテーブルがあり、それを絞って表示するのが、一覧画面だとおもいます。

結合条件もキー結合であれば、1000万件ぐらいなら、処理速度的にさほど問題にはならないです。
※一括、全件取得は不可(テーブルは10テーブルぐらいを想定)

投稿2018/01/11 11:31

himakuma

総合スコア952

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

annderber

2018/01/12 01:42 編集

コメントありがとうございます。 一画面用というか親テーブルですね。請求書管理があったとしたら、おそらく請求書テーブルの下に請求明細テーブルが紐付くと思います。そうするとたいてい一覧画面に表示するのは親テーブルの一覧ですよね。 設計次第なら1000万件でもパフォーマンスにはあまり影響がないですか! ページャー等で一画面あたりのレコード数を絞れば問題なさそうですね。
himakuma

2018/01/12 02:26

これも個人的な意見ですが、よほど項目数が多くなければ(200項目orver)、 1対1のテーブル構成は作りません。 カラムの増加によるコストより、結合によるコストが大きいです。 過剰な正規化ではないですか?
himakuma

2018/01/12 02:28

追記:トランザクション管理によるテーブルの細分化はします。
guest

0

ベストアンサー

人間が一覧を見て詳細へ飛ばすのですから
表示できるデータ量というのはしれていると思います。
例えば一覧で1万件をスクロールして探すとかになることはほとんどないので
私ならwhereが適正なら多少joinの数が多くても都度計算してやりますね。
計算でやれることは計算でやりたいところです。

投稿2018/01/12 02:52

sousuke

総合スコア3828

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

annderber

2018/01/12 06:47

コメントありがとうございます。 最初から絞り込めばパフォーマンスへの影響はかなり軽減できると言うことですね。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問