@yuba@reax.work @yuba@reax.work @yuba@reax.work @yuba@reax.work @yuba@reax.work @yuba@reax.work @yuba@reax.work
本拠地(リアクションするだけのお仕事) @yuba@reax.work
春色インク @yua@mi.halu.ink
Misskeyをしよう @yuba@mi-wo.site
おとうふ王国 @yuba@nemudaru.uk
りんごぱい @yuba@misskey.04.si
日 | 月 | 火 | 水 | 木 | 金 | 土 | |
1 | 2 | 3 | |||||
4 | 5 | 6 | 7 | 8 | 9 | 10 | |
11 | 12 | 13 | 14 | 15 | 16 | ||
18 | 19 | 20 | 21 | 22 | 23 | 24 | |
25 | 26 | 27 | 28 | 29 |
スキーマ定義するときに、時間軸でみたユニーク性ってのも意識しておくと何が嬉しいかというと、
この値を変化させたときに連携先が困るよね、いつの間にか別レコードに紐付いちゃうことになるわ、みたいなのが想像できて手を打てます。
例えばだけどUserというテーブルのidはおそらくシステムの一生を通じてユニークだけど、login_idとかmail_addressは時間断面ではユニークだけどシステムの一生を通じてみると複数のレコードで同じ値が設定されるかもしれない。
(twitterで「そのID使いたいからID変えてください」と交渉することがあるよね、同時に同じIDは名乗れないけど、ID変えてどいてくれたあとにはそのIDを名乗れるようになる)
データスキーマを設計するとき、「ユニーク」には2種類あって、システムの一生を通じてユニークなのと、ある時間でみたときユニークなの、そのどちらなのかを意識しておくといいですよ
このアカウントは、notestockで公開設定になっていません。
読み始めたSlackのスレッドが入り組んだ議論になっててしかも最後のコメントから時間がたっていて結局何を読み取れば良いのかわからなかったときのセリフまわし、これですね。
「↑結論出てます?」