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

• クラサバでサブスクで提供
  • 一番儲かりそう。というか今っぽい。
  • クラサバは開発が大変。
  • データ吹き飛んだ時が大変。１，２回データ吹き飛ばして知見が溜まるまではサブスクしないほうがよさそう。
  • WorkflowyやDynalistとガチンコ勝負になる。
• クラサバで広告モデルで提供
  • デライトの劣化コピーを目指す形になってよろしくない。
  • サブスクよりもデータに対する責任をあまりとらなくて良さそう。
  • ペルソナとして作家のTak.氏があるので、利用者の注意を広告で煩わせるのはそれに沿ってない。
• ローカルアプリでサブスクで提供
  • ビミョー。「商用利用は有料」みたいにして、本当に金払ってくれんの？みたいな疑いがある。
  • 結局サブスクの管理機能が必要になるのでサーバー不要とはいかない
  • Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
• ローカルアプリで買い切りで提供
  • 一番儲からなさそう。というか古臭い。古いから悪いというわけではないということを肝に銘じていただきたい。
  • でも一番楽。
  • ライセンス管理とかは大変そう。そういうことをしだすと結局サーバーが必要。
  • Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
• 寄付で運用
  • 論外。寄付で回っているところをWikipedia以外で見たことがない。大体ヒーヒー言ってる。と思ったけど、Rustとかは寄付（というかスポンサー）でやっていってるらしい。

気持ち的には「クラサバでサブスクで提供」に傾いている。

　正直、この先開発を進めるか悩むな。ノリと勢いで開発を始めてしまったので、どういう位置づけにするか決めていない。デライトの劣化コピーになるのは避けたいし、応用はしつつも別の山を登りたい。というか、KNSにまで作り上げる技術力がない。
　進めるとして、WorkflowyかObsidianのような感じにするのがいいかもしれない。クラウド、もしくはローカル。

あ～～～～サーバー持ちたくねぇ。
サーバー持つと、お金かかるわセキュリティのリスクが発生するわで大変。
セキュリティ三ない運動をしてきたので、知識がたまらずに来てしまった。

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

　サブスクとか買い切りにしようとすると特定商取引法に基づく表示が必要になって、名前と住所をネットにさらさないといけなくなってしまうな。個人がやるにはちょっとプライバシー的に問題がある。
　私書箱契約すれば多少はましだろうだけど金をかけるのは嫌だ。
　一旦はスポンサーで行ったら良さそうな気がしてきた。

サーバーにDBを置く場合は、アウトラインの所有者を決めないといけないな。
今のところはDBを利用者のPCの中だけの想定だから問題にはならないけど、将来を見越して今のうちに所有者のテーブルを作ってもいいかもしれない。と思ったけど、YAGNIの考え方だと今対応するのもなんだかなぁだな。必要になってからでいいか。テーブルを一つ追加する形になるので、そこまで大それた変更にもならないはずだ。