【Web開発】「一覧画面」の設計について

一覧画面設計パターン

下記4つのパターンに分けられます。

• 全件表示
• 一部表示
• ページング
• モダンなUI

全件表示

• 大量データ表示には向かない。
• 取得SQLの大量データ取得時は大量にデータを取得しすぎてサーバのメモリ領域の要領を超えないように注意する。
• また何万件とデータがある場合はレスポンスに時間がかかってしまいます。

一部表示

データの絞り込みには向かない。

ページング

全てにおいて機能性は優秀だが実装に工数がかかる。世の中のシステムはページング方式にも色々方式があります。下記の記事でも解説しております。

【Web開発】「ページング機能」の設計

モダンなUI

最初の画面を一部表示パターンで表示して利用者が最終行に到達した際に追加行を表示します。FacebookやTwitter等の多くのSNSでも採用されていたりします。ただ、このパターンも下記のようなデメリットがあるため万能ではありません。

デメリット

• 件数が膨大すぎて特定データを探したい場合はスクロールが追いつかない。

一覧画面に求められること

• ページの表示速度が早い事
• 縦スクロール量が短いこと
• 検索結果を条件で絞り込む機能があるとなお良い。
• 検索結果の昇順、降順を切り替える機能があるとなお良い。
• デフォルトでのソート順を考慮する。（優先度が高いソート順にするため顧客に確認する）

検索条件について

• 各項目ごとに部分一致か完全一致かの要件は明確にする。
• 日付のFrom Toバリデーションはしっかり行う。

ソート機能について

ソート自体は下記の2種類に分かれます。

• 表示されているデータだけをソートする。（よくあるWeb部品はこっち）
• データ全体をソートする。

よくあるのは「表示されている部分だけをソートする」ですがユーザーから本当にその仕様で良いかは確認するようにしましょう。

サーバのメモリ領域超過

サーバのメモリ容量超過（アウトオブメモリー）でシステムエラーで落ちてしまう。

原因

• 単純に検索で取得してきている件数が多すぎてサーバーのメモリにデータを格納できなくなってしまうこと。
• 「条件で絞り込んだデータを取得するSQL」と「全件件数を計算するSQL」をまとめて実施している場合（全件のデータがメモリ上に格納されてしまう。）

対策

• 全件表示の場合は条件の絞り込みを必須とする。（条件が指定されていない場合は検索を行わない）
• 絞り込みを必須化できない場合は一部表示やページングの実装をする。
• SQLは別々に分けて発行するようにする。

利用者一人当たりに使えるメモリサイズを計算するには

下記3つのことを考慮してユーザー一人当たりが使えるメモリ使用量を決める。なお該当アプリが使うことができるメモリ量に関してはインフラ担当者に必ず確認しましょう。

• 利用者数
• サーバーのメモリサイズ
• データの生存期間