新人がテーブル設計でつまずいた話 | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、土屋です。 今回の記事では、私が初めてテーブル設計をしたときに、つまずいた話をまとめてみました。 テーブル設計の経験者の方には、「新人はこんなところでミスするんだ」と知っていただければいいなと思います。 【ミスその1】エンティティの属性の書き方が適切ではなかった 論理名を簡潔に書く 社員情報をまとめるエンティティに、社員のIDを属性として入れたいときがありました。 はじめは属性の論理名を、次のように「社員ID」にしていました。 ですが、「社員ID」ではなく、簡潔に「ID」とだけ書けばOKです(※)。 エンティティ「社員」の属性にIDがあると、それが「社員ID」であるのは自明だからです。 ※必ずしも当てはまるわけではありません。例えば、全てのテーブルで「社員ID」にしておくと、JOIN するときに迷いにくいので便利という意見もあります。 正しい表現か確認しながら物理名を書く 物理
ドメイン駆動設計をかじってみる | TECHSCORE BLOG | TECHSCORE BLOG
はじめまして！平奥と申します。 TECHSCORE BLOGに記事を投稿させていただくことになりました。 みなさま、よろしくお願いします！ 今回は私が設計について学んでみようと思い、「エリック・エヴァンスのドメイン駆動設計」を読んだ内容を記事にしました。 感想としては率直に申しますとすごく抽象的で、読みづらいですが、有益な内容がたくさん書かれています。 こういう設計関連の学習をするときに、私が心がけているのが「完璧な設計はない。」ということです。 実は、ある設計思想に基づいて設計しているときに、その思想に完璧を求めるあまり解決できなくて 途方にくれた時がありました。 しかしもっと柔軟に設計を行い、その設計思想のコアなルールは守るというスタンスでよいのではと考えています。 他の設計思想と共存させ、そのプロジェクトにおいて最適な設計を行うことが大事だと考えています。 このことはエリック・エヴァ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
