ToDoアプリのDB設計について

Question

現在ToDoアプリを作っているのですが、DB設計に悩んでいます。

具体的には、タスクを分割しサブタスクとして管理するアプリをイメージしています。
サブタスクがサブタスクを持つ可能性があり、
タスクの並び替えなどもできるようにしたいと考えています。

データ構造としては木構造になっていると思うのですが、
このような場合、どのような手法を使って設計するとよいのかアドバイスをいただければと思います。

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

追記
画面レイアウトはTodoistと同じようなレイアウトで考えています。
この画像にあるようにタスクに対してタスクを入子にして保存できるようにしたいと考えています。

ToDoに関する機能でいうと以下になると考えています。

• タスクを登録できる（入力項目はタイトルと期限）
• タスクにサブタスクを登録できる
• タスクは並び替え可能

Answer 1

データ構造としては木構造になっていると思うのですが、
このような場合、どのような手法を使って設計するとよいのかアドバイスをいただければと思います。

木構造を表せる構造として一番シンプルなのは(KEY,親KEY)のようなナイーブツリーと呼ばれるものです。
但し、ナイーブツリーはアンチパターンでもあります。
再帰の使用できるRDBMSであればアンチパターンにはならないので、RDBMSの選定も重要事項となります。

Comments

[nyago49]

ご回答ありがとうございます！
ナイーブツリー調べてみました。
教えていただいた通り通常はアンチパターンとされていましたが、PostgreSQLだと再帰が使えるようで大丈夫そうですね！

並び替えのことを考えて経路列挙モデルも良いのかなと思ったのですが、このような場合どちらが良いのでしょうか？

[sazi]

列挙する経路は、再帰の中で組み立てることも可能ですし、取りあえずは、ナイーブツリーとしておき、性能要件を満たさないような箇所が発生した場合に経路列挙モデルとするのが良いかと思います。

但し、その場合はストアド経由とするなどして、SQLの変更の影響箇所を極力少なくすることを考慮しておいた方が良いでしょう。
また、列挙する経路について、postgresなら配列として置いた方が経路の深さが変更になってもカラムを追加する必要がありません。

[nyago49]

返信ありがとうございます！

まずナイーブツリーで進めてみます。
postgresの配列についても調べてみます。

Answer 2

たとえば、ToDoリストを使ってみよう で、どんなテーブルにどんなカラムが必要か考えて質問に追加し、それで良いか判断を仰いでは？

Comments

[nyago49]

ご回答ありがとうございます。
リンクを参考にさせていただきます。

Answer 3

今どこまでできているかわからないですが
まず画面レイアウトを確定し項目を全て洗い出してください。
「画面は機能」と言うのがよく言われます。
機能を全て洗い出すことでデータの形も決まってきます。
いきなりデータから考えると大体後付が積もり積もって破綻します。

※もし画面レイアウト・項目洗い出しが済んでいるのでしたら
その情報を提示されたほうがより的確な回答が得られると思います

Comments

[nyago49]

ご回答ありがとうございます。
指摘いただいたレイアウト、項目を追記したのでご確認いただけたらと思います。

もし過不足、間違い等ありましたらお手数ですが、コメントをいただければ幸いです。

[m.ts10806]

えっと、言葉足らずで申し訳なかったのですが、そのレイアウトを元に考えた設計内容を提示した上でどこが課題かとか問題かとかを質問するようにしないと丸投げになってしまいます。

[nyago49]

こちらこそ申し訳ございません。
今回のようなDB設計が始めてで、どこが課題かもわからない状態でしたのでもう少し自分で調べて考えてみます。