【自分用まとめ】builderscon tokyo 2019 DAY1 はじめてのB2B SaaSデータモデリング #bc1204 #builderscon
Multi Tenancyの難しいところは、Aクライアントの情報がBクライアントに見えてしまう可能性が生まれるところ。 見えてしまったら訴訟沙汰の可能性高 #bc1204 #builderscon
2019-08-30 11:22:33Multi Tenancyの方針 1. テナントごとにDB or Schemaを定義 2. tenant_id管理 ふむ、、、 自分の知ってるなかだとBacklogっぽい感じかな #builderscon #bc1204
2019-08-30 11:24:39tenant_idって、企業の合併とかあったらそれを管理する用のテーブル必要なんだろか #builderscon #bc1204
2019-08-30 11:24:43Multi tenancyとは ユーザから見るとシステムを専有しているように見えるが、実は相乗りしているシステム 実現するには ・テナントごとにDBを分離するか ・全テーブルに tenant_idカラムを用意する #builderscon #bc1204
2019-08-30 11:24:431. Multi Tenancyの実現方法 * テナント毎にDatabase or Schemaを分離 * 全テーブツにtenant_idカラムを用意する 個人的に前者はmigration時の管理コストなどが辛い 後者はデータが増えてきた際のパフォーマンスがしんどい(使うDBにも一定の依存はある) #bc1204 #builderscon
2019-08-30 11:24:49企業のセキュリティチェックシートに"データ領域を分離してるのか?Multi Tenancyか?"みたいなのあるらしい。 #builderscon #bc1204
2019-08-30 11:26:02そうか取引があるから、テナント間のデータのやりとりのような話が生まれるのか。 #bc1204 #builderscon
2019-08-30 11:26:48テナントの単位を考える * サプライヤーベースなのか? * バイヤーベースなのか? ↓ 解約した際にデータを物理削除をしてほしいという要望・・・ -> メールをメタファーとして考える。メールは残るよね。 #bc1204 #builderscon
2019-08-30 11:28:56退会後の情報? メールをメタファーにすると受診した情報は削除されないよね たしかに #builderscon #bc1204
2019-08-30 11:29:16要件によっては複雑なテーブル構成になるとしてもビジネスとして価値を生む方向性を選択するべきなんやな… #builderscon #bc1204
2019-08-30 11:32:23これ退会発生した時に、何を消して何を残すのかが、かなり難しそうだ。 #bc1204 #builderscon
2019-08-30 11:33:11テナントをまたぐデータのやりとりはデータをコピーして受け渡しをする -> このコピーするロジックで他のtenant_idのデータをコピーするとやばいので、色々な対策をかけてそう。 #bc1204 #builderscon
2019-08-30 11:34:05データコピーする場合テナントidはコピーした時点で書き換わるんだろうか?発生源とどこかで紐付いてるのかな。 #builderscon #bc1204
2019-08-30 11:34:55NULLを許容しない -> Nullableなカラムがいるということはライフサイクルの異なるデータが一緒のテーブルになっているということではないか? #bc1204 #builderscon
2019-08-30 11:35:00NULLをできるだけ許可しない NULLカラムを外部テーブルにしたけどモヤモヤ ドメインエキスパートに深掘り 業務フロー的にNULLになる可能性がある Nullableはエンティティを混合している臭い #builderscon #bc1204
2019-08-30 11:36:43なるべくNULLを許容しない Nullable があるのはライフサイクルが異なるデータが入っている エンティティを混同している可能性があるから #builderscon #bc1204
2019-08-30 11:37:06