GraphQLを使ってシンプルな電子掲示板を作ってみる(2)

2020.5.9 12:00

前回に引き続き、スキーマの定義をしていく。

スキーマの定義

まず、取り扱うデータを明確にする。ざっと下記のデータを取り扱う必要がありそうだ。

  • 記事
  • 記事のタイトル
  • 記事の本文
  • 記事の投稿者名
  • 記事の投稿者メールアドレス
  • 記事を削除するための削除キー
  • 記事の投稿日時
  • 返信
  • 返信の本文
  • 返信の投稿者名
  • 返信の投稿者メールアドレス
  • 返信を削除するための削除キー
  • 返信の投稿日時

これらの従属関係を考え、整理するとこうなる。

「もの」にはそれぞれ固有の識別キーがあったほうが都合が良いので、通し番号も付与しておく。
また、「記事」と「返信」が1-Nの関係にあるので、正規化する。

  • 記事: もの

    • 記事のID: 数値
    • 記事のタイトル: 文字列
    • 記事の本文: 文字列
    • 記事の投稿者名: 文字列
    • 記事の投稿者メールアドレス: 文字列
    • 記事を削除するための削除キー: 文字列
    • 記事の投稿日時: 日付
  • 返信: もの

    • 返信のID: 数値
    • 投稿のID: 数値(外部キー)
    • 返信の本文: 文字列
    • 返信の投稿者名: 文字列
    • 返信の投稿者メールアドレス: 文字列
    • 返信を削除するための削除キー: 文字列
    • 返信の投稿日時: 日付

(補足)投稿者という概念はないのか

勘の良い方なら

  • 投稿者: もの

    • 投稿者名: 文字列
    • 投稿者メールアドレス: 文字列

という従属関係があるのではないかと思った方もいるかも知れない。

これはもちろん状況によりそうする場合もあるが、今回は「投稿者」という「もの」を このシステムにおいて重要なものとして捉えていないため、取り入れなかった。

具体的には、例えば2つの記事において同じ名前、メールアドレスのものがあったとしても、
いまは「これらは同じ人が書いたものである」ということを気にする必要がないということである。

もちろん、「自分の書いた記事を一覧表示する」といった要件があった場合は考慮する必要が出てくる。

(これをやる場合は「ユーザ管理」という機能が必要になってくるため、今回は要件に入れなかった)

アクセス権限を考える

次に、これらの「もの」へのアクセスはどうあるべきかを考える。

基本的にはCRUDと呼ばれる操作について考えるのが筋である。

  • 作成 (Create)
  • 参照 (Read)
  • 更新 (Update)
  • 削除 (Delete)

今回は、記事も返信も

  • 誰でも新規に作れる
  • 誰でも見られる
  • 編集する機能はない
  • 削除するには通し番号と削除キーが一致する必要がある

    • よって削除キーは人に見えてはダメ

になる。

スキーマ図を作る

以上までの従属関係とアクセス権限が整理されたものを図にするとこうなる。

2-1

次回

次回は定義したスキーマに基づいてバックエンド環境を構築してみる。

graphql

Copyright 2020 tkzwhr's tech notes. All Rights Reserved. Built with Gatsby.