一般的なテーブルの論理設計(データモデリング)のことクラウドでDBのPaaSを使うと「これでDB作れたのか?」「勝手にスケールできちゃう!」「勝手にインデックス張ってくれる?!」になってます。今のところテーブルの論理設計はエンジニアがやらないとできないので、まとめておきたい。(mBaaSやら、自然言語からSQLを作るサービスもあるので、そのうちテーブル設計もエンジニアがやらなくなりそうですが...)テーブル設計について一通り盛り込まれていて、簡潔にまとまってる記事を見つけたので拝借。Qiitaこの記事の内容で気になる点がいくつかあったのでメモしておきます。自然キーを使うべき?業務が変わるとキーが変わる可能性もある(殆どないですが...)ので代理キーを使うべき。考え方もあり、私は代理キー派です。Djangoを普通に使うと代理キーです。正規化は第三正規形まででOK?非正規化すると検索し易くなり(その検索処理だけコードが簡単になったり、レスポンスが良くなったりし)ます。逆に、正規化するほど業務の実態に近づきます。業務の実態に近いということは、仕様が変わってもテーブルの変更も対応し易い(正しくテーブル設計できていれば、テーブルには手が入らない。変更はなくテーブルの追加だけで対応できる。非正規化した項目は、画面の仕様が変わると、全く役に立たないゴミデータになる可能性があります。後々のことを考えると、できるだけ正規化しておきたいです。物理設計の内容クラウドサービスを使うとあまり意識しなくて良くなってきてます。理解しておいた方が良いですが、優先度を下げて考えても良いのかと思います。先述の記事でテーブル設計について一通りまとまっていますが、難しい単語があって頭に入りにくい部分もあります。Qiitaこの記事も気になる点をメモ。主キーをidにするとSQLでjoinした際に混乱するからentity名_idとするべき?Djangoでは主キーを定義しないと、自動的にidという主キーを作ってくれます。DjangoのORMだけ使用する場合、この記事の指摘は気にしなくて大丈夫ですが、Djangoでも生SQLを書くことができます。しておいた方が無難でしょう。中間テーブルについて中間テーブルが「多:多の関係を解消するために、業務要件にないけど人工的につくるテーブル」として説明されています。確かに多:多を解消しますが、業務分析が不充分であるとも言えます。この記事の例で言うと、学生は新学期が始まる際に新しい講義を選択し、受講期間を申し込むイベントがあるはずです。例にある中間テーブルに日付(受講期間)を追加したものが、このイベントのテーブルとして定義されるべきです。上記の中間テーブルをイベントのエンティティに落とし込む点に重点をおき、分かり易く業務分析/データモデリング(≒論理設計)する手順を説明したスライドを見つけました。イミュータブルデータモデル(入門編)このスライドを作成した方のベースにはT字型ERがあるようです。私も以前この本を読みました。言葉が難しいですが、テーブル設計が楽に出来るようになります。余裕があれば読んでみてはいかがでしょうか。複合ユニークキーにする。複合ユニーク制約をつける方法ORMでテーブルを結合検索したい場合、modelのFieldにForeignKeyの指定が必要ForeignKeyを張ると面倒な場面があるので、以前は物理設計時にForeignKey制約を外したこともありましたが、外さない方が良いです。あったので参考にしてみて下さい。指定することで、ForeignKey制約なしにするのは可能ではあります。10年ぐらいこれしか使ってないので、他のおすすめが分からない。無償きっと他にも良いところがあるはず。diaryで触れたAdminサイトについ...2017-09-04DjangoについてPythonで作られたフルスタック・フレームワーク。DjangoでWebアプリをつくる簡単なWebアプリはサクッと作れるようにしておきたい。読者になる検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事ブロックチェーンが気になるDjango管理サイトについてDBについてDjangoについてPythonについて月別アーカイブはてなブログをはじめよう!ping2shi2さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。