t_wの輪郭

　テーブル設計がつらすぎる。DBの経験が薄い＆DBから長らく離れていた せいだろう。プログラムだったら感覚でなんとなくなんかいい感じにできてしまうが、経験のないやつはどうしようもない。
　PlantUMLでER図を書いて、壁打ちしたほうがよさそうだ。設計資料も残るのでその意味でも利点がある。

@startuml

entity outline as "outline\nアウトライン" {

}

entity relation as "relation\n関係" {
    
}

entity home_outline as "home outline\nホームアウトライン" {

}

outline }-- relation
outline ||--home_outline

@enduml

　OPMLでやろうかなと思ったけど、ほかのアウトライナーから読み込めるようにするのがめんどくさい。OPMLはあくまでエクスポート専用にしたほうが幸せになれる気がする。

　sql.jsでDBにして保存…！なぜこのような危ない橋を渡ろうとしているかというと、セキュリティ的に安全にRDBの知見をためる必要性があるためです。

@startuml

entity outline as "outline\nアウトライン" {
    ulid
    text
    created_at_timestamp_ms
    edited_at_timestamp_ms
}

entity outline_relation as "relation\n関係" {
    ulid
    parent_outline_ulid
    child_outline_ulid
}

entity home_outline as "home outline\nホームアウトライン" {
    outline_ulid
}

outline }-- outline_relation
outline ||--home_outline


@enduml

　PlantUMLでER図を書いていて気づいたのだけれど、輪郭のデータ構造ってどれだけ親ノードをたどっていっても根ノードにたどり着けないな。なんてデータ構造だ。
　なので、読み込みをした直後に表示するノードは、特別に記録しておかないといけない。

　いろいろ検討してみたけどめんどくさすぎるし、sql.jsのwasm読み込みがなんか信用できないし、npm install sql.jsしてもうまく動かなかったし、DB扱うのは後回しでいいかなってなってきた。普通にオブジェクトを文字列化して保存して終わりにしよう。YAGNIだ。まあいい勉強にはなった。後々役には立つ。

@startuml

entity outline {
    ulid
    text
    created_at_timestamp_ms
    edited_at_timestamp_ms
    first_outline_relation
}

entity outline_relation {
    ulid
    parent_outline_ulid
    child_outline_ulid
    next_outline_relation
}

entity home_outline {
    outline_ulid
}

outline }-- outline_relation
outline ||--home_outline

@enduml

文輪のデータモデルが単純すぎてこれで大丈夫か不安になってくるな。
まあ単純すぎて不足がある分には追加すればいいから大丈夫か。「複雑かつ問題がある」よりも対処しやすい。