# 2021/05/15 メンター相談 ###### tags: `メンター相談`,`5月` https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recsgWtO3JngG4LGN?blocks=hide ## アンチパターン5の回答の改善策を教えてください。(その1) - 何もしてない顧客を表現するには、何もしていない顧客テーブルを作る必要がある。 - RegisteredCustomerテーブルを作成して、イベントが起こった時にはそのidを各テーブルに入れる。 - または、全てのイベントテーブルをLEFT OUTER JOINして、どのイベントも発生していない(nullになる)ことをアプリケーション側で確認する - 顧客の最新の状態を取得するには、各イベントテーブルをLEFT OUTER JOINすれば取得できる。 - まだ行っていないイベントはnullになる。 - または、非正規化して、Customerに最新のステータス情報を持たせることでも解決できる - dbは2つ正規化がある (『楽々ERDレッスン』 より) 　 - 論理的な正規化とビジネス的な正規化 　 - 敢えて非正規化することはあり得る - 今回の設計では、具体的に「TelephoneToCustomer」「MeetToCustomer」と分けられていたので、電話営業を行った際の電話番号の登録や商談営業を行った際の営業した場所など、固有のデータが出てきた際に対応しやすくなった。 - その他改善点 - 一つのイベントに複数の顧客を割り当てられない - 例: グループ面談がある場合 など - 中間テーブルを挟み、多対多にすることで解決できる - dbでは排他制御が作りづらい - 例: 成約している顧客 には 電話できない ようにしたい場合など - そのため、アプリケーションで処理を待つことになる - 流れを表現できない - 電話 -> 面談 -> 成約 - この場合、createdAtで並び替えるしかなさそう - 営業工程のカスタマイズを柔軟に行えない - salesforceは独自に営業工程を作ることが出来る。 - -> 柔軟なテーブル設計が必要かも？ - 中野さんの案 (アンチパターン5の回答の改善策を教えて下さいその2) のように抽象化されていると増やしやすい ## アンチパターン6の回答の改善策を教えてください。 - マスターデータを変更する、という不安点は外部参照されていないテーブルは同様の不安点が挙げられるということになる - マスターテーブルのナチュラルキーorサロゲートキー問題は、サロゲートキーで良いのではないか - 少し考えすぎかな？ - 異口同音が出てきた場合を考える必要がある。 - 変更があった場合、Studantテーブルのstatusを全て更新する必要がある。(長時間ロックが掛かる恐れがある。) - サロゲートキーを用いた場合は、uniqueであり続けるかどうかを考える必要がある。 ## 経路列挙モデルは、整合性を担保出来ないが、参照整合性が担保できないようなモデルを敢えて採用することはあるのでしょうか？ - 経路列挙モデルは基本使わない（閉包テーブル一択） - パン屑には良いぐらいのメリットしかない - [SQLアンチパターンの著者が書いたスライド](https://www.slideshare.net/billkarwin/sql-antipatterns-strike-back) を確認したら書いてあった - RDBの利点を損なうため、参照整合性を担保できないモデルは採用すべきではない - 親が一人 or 階層が1つまでなら、ナイーブツリーを用いることはある。 - 開発スピードを重視して、リリースしてすぐに捨てるなら、参照整合性を担保しない設計をしても良いかも...？ - 閉包テーブルはテーブルのデータ量だけ、不安な点がある。 - データ量が増えても、そこまで費用が増えにくい ## アンチパターン5の回答の改善策を教えてください。(その2) - 日本語がアプリケーション内にはいるのは違和感がある。 - SalesMethodテーブルの内容を表示する際はidだけをフロントに返却して、フロント側で表示を変換する。 - 表示に関わる部分はフロントエンドで変換する - uiは更新頻度が高い 　 - そのため、dbの値をそのまま用いるのではなく、アプリケーション側で変換する 　 - 一点変更するのならばsalesmethodのnameをcode値にするかな、 　 - 多言語対応が必要になる可能性を考慮している - 抽象的なデータを管理するテーブルを作成する際、どこまで具体に落とすかどう判断するか？ - 具体的なユースケースを考慮する - どこまでのユースケースを想定するのか、は難しい問題 - 実際に作成したテーブルにデータをinsertし、実際に使ってみて問題があるか試してみる - とりあえず多対多の関係にしておけば、ほとんど問題にならなかった ## DIコンテナの実装について、具体的なサンプルコードがありましたら、見せていただきたいです。 - 使ったことはない。 - [Nestjs](https://docs.nestjs.com/fundamentals/custom-providers)はDIコンテナを使うことが出来る。 - プラハでは、コントローラー層の責務としてオブジェクトの生成知識の管理を持っており、DIコンテナ的な役割を担っている。 - コントローラーに書くというルールが出来ていれば、生成知識が問題になるほど散らばることはない。 ## ツリー構造の設計を行う際に、RDB以外の選択肢がありましたら、教えて頂きたいです。 - [Neo4j](https://neo4j.com/)を使うと、経路を取得するクエリを簡単に書くことが出来る。 - Linkedinのようなサービスを作っていたが、500人くらいのデータが増えたらクエリが遅くなり、使い物にならなかった。 - SQLアンチパターンのような情報がないので、ユースケースが増える毎に問題が起きてた。 - RDBで閉包テーブルで事足りることが多い。 - idだけをカラムに保持しているので、クエリが早い。 ## DDDでは、モデル名を変更した際にはテーブル名も変更するのか - やったことはないが、やるとしたらモデル名を先に変更して、問題がないことを確認した上でテーブル名の修正を行う。 - 実装着手前にユビキタス言語集の作成・モデリングを行うことで、認識ズレが起きないようにしている。 - 用語集に載っていない命名が出てきたら、都度都度内容を詳しく確認する。