スキーマ定義するときに、時間軸でみたユニーク性ってのも意識しておくと何が嬉しいかというと、
この値を変化させたときに連携先が困るよね、いつの間にか別レコードに紐付いちゃうことになるわ、みたいなのが想像できて手を打てます。
スキーマ定義するときに、時間軸でみたユニーク性ってのも意識しておくと何が嬉しいかというと、
この値を変化させたときに連携先が困るよね、いつの間にか別レコードに紐付いちゃうことになるわ、みたいなのが想像できて手を打てます。
例えばだけどUserというテーブルのidはおそらくシステムの一生を通じてユニークだけど、login_idとかmail_addressは時間断面ではユニークだけどシステムの一生を通じてみると複数のレコードで同じ値が設定されるかもしれない。
（twitterで「そのID使いたいからID変えてください」と交渉することがあるよね、同時に同じIDは名乗れないけど、ID変えてどいてくれたあとにはそのIDを名乗れるようになる）
データスキーマを設計するとき、「ユニーク」には2種類あって、システムの一生を通じてユニークなのと、ある時間でみたときユニークなの、そのどちらなのかを意識しておくといいですよ
このアカウントは、notestockで公開設定になっていません。
物理出社するじゃん？
コンビニの引力に負けて飲み物とか買っちゃうじゃん？
レシート握りしめて席まで来るじゃん？
レシートが鶴に化けるじゃん？
結論でてるなら教えてもらえるし、出てないなら今時点の論点を教えてもらえる。
教えてくれないなら安心してちゃぶ台返ししにいける。
読み始めたSlackのスレッドが入り組んだ議論になっててしかも最後のコメントから時間がたっていて結局何を読み取れば良いのかわからなかったときのセリフまわし、これですね。
「↑結論出てます？」
