当たり前ですけど、１つの注文で複数の商品を購入できるか否か？っていう業務要件によって適切なDB設計は変わるのでこの情報だけじゃなんとも言えないですよね 1 vs nなら受注と受注明細テーブルに分けて、受注番号だけでは受注明細が一意にならないので明細番号（受注番号毎の通し番号）みたいなものが必要ですし、1vs1しかありえないのであればこのafterが適切な設計になりそうですね
@Nash I. 受注IDと品目IDが1対1で紐づくのであればそもそもafterで品目コードを含めた複合主キーである必要はなく受注IDだけを主キーにすればいいので1つの受注IDに対して品目が最大複数あることは確定ですね。 ここでは簡略化されているみたいですが、流石に普通なら最低でも受注日や受注会社くらいは保持していて、かつそれらは受注IDのみに依存している可能性が高いので(絶対とはいいませんが）1 vs nならと仰ってるように明細テーブルを作って品目コードはそっちに入れるのが適切なんじゃないかと思いますね。
![Megan Thee Stallion - Roc Steady (feat. Flo Milli) [Official Video]](http://i.ytimg.com/vi/HozPPyqW0dY/mqdefault.jpg)
これすごくいいです。
判断力がつきますよね！
単に教科書的に正解だけを示す、というものではなく、作り手の「考えながら判断し、結論する」という、センスを培えるものなので、エンジニアではない自分にとって貴重な学び材料です
最後のはどっちが良いか難しいよね。
結局は要件や仕様次第だけど、中間テーブル作るとデータ構造も処理も複雑になりやすいし。
全員白Tなのちょっとおもろい
1問目について、ちょっと本題から逸れるけど、顧客の大部分が法人のデータベース作るなら、メンテナンス用に法人番号も記録しといた方が便利だと思う。
法人番号が分かれば、国税庁の公開データベースから法人名、名称フリガナ、本店所在地、郵便番号等が照合できるし、法人が解散した情報も調べられる。
アメリカでデータ分析の仕事をしています。
3:41 はfact tableの可能性もありますから一概に言えないかもですね。私はIDと品目コードの違いがleading zerosがあるかないかの違いしかない方が問題かと思います。
普通の人は話しながら理解するのがすごいよな
正規化の具体例参考になります。
勉強になりました。このシリーズ継続して見たいです！！
初めてこちらのチャンネル拝見します。
こういうのって経験知ですよね。
右の方がお歳を召されてる分、問題単体だけじゃなくて業務想定も含めた回答になっていて流石だと思いました。
次はnoSQLのDB編待ってます！
データエンジニア、データベースエンジニアまわりの動画もっと見たいです！
顧客IDは同じ顧客が複数できた場合(話に出ていた拠点など)に同じIDを振った方が管理しやすい。そうすると、ユニークなIDじゃなくなるから、別途ユニークなIDも入れた方がよさそう。
こちらのチャンネルで勉強に・・・
というのは、無理がある。
確かに、視点としての気づきになる話はありますが、
動画の中で「正解」と言っている事柄も、必ずしも正解なの？
と思うケースが多々あります。
今回はデータベース設計ですが、受注テーブルの話をはじめ、他の方も同様のコメントされていますし、
コードの見直しの部分でも、正解に対して、えっ？と思うケースが多々。
あくまでも、開発時の視点を学ぶという程度で観るのが良いかと思います。
タイトルが「クソ～」としている時点で、煽って視聴数を伸ばそう
という意図が見え隠れしますし。
受注テーブルにはサロゲートキー残した方がいいと思うなぁ〜
むしろ複合キーの採番が同じとこから来てないか心配になるw
2問目、再表示時にソートを再現できないのも結構大きい問題。
0:01 そのまま「3人合わせて、パヒュームです」が始まるのかと思った
これ、IDの話のとこのやつ、そもそも受注IDは品目コードを保有するなら受注IDは｢一意｣になることはないんじゃないですかね
これだと、1受注に複数の商品をまとめて発注(受注)することに対応できない、、、
受注IDというより、売上IDとかなら、、、
と問1にもあった｢意図が伝わる項目名｣も大切ですね
当たり前ですけど、１つの注文で複数の商品を購入できるか否か？っていう業務要件によって適切なDB設計は変わるのでこの情報だけじゃなんとも言えないですよね
1 vs nなら受注と受注明細テーブルに分けて、受注番号だけでは受注明細が一意にならないので明細番号（受注番号毎の通し番号）みたいなものが必要ですし、1vs1しかありえないのであればこのafterが適切な設計になりそうですね
@Nash I. 受注IDと品目IDが1対1で紐づくのであればそもそもafterで品目コードを含めた複合主キーである必要はなく受注IDだけを主キーにすればいいので1つの受注IDに対して品目が最大複数あることは確定ですね。
ここでは簡略化されているみたいですが、流石に普通なら最低でも受注日や受注会社くらいは保持していて、かつそれらは受注IDのみに依存している可能性が高いので(絶対とはいいませんが）1 vs nならと仰ってるように明細テーブルを作って品目コードはそっちに入れるのが適切なんじゃないかと思いますね。
後日追記
主キーが「受注ID」のみだと思ったので、当初の疑問が浮かびましたが、
改めて正解の例を見たら、「受注ID」と「品目コード」の 複合主キー になっているので、
それであれば、1回の受注で複数品目を受注出来ますね😅
受注テーブルなのか明細テーブルなのかがよく分かりませんが、受注テーブルらならば
受注IDだけでなく品目カラムが入るのもおかしいし、明細テーブルならば、品目が複数
入る可能性があるので受注IDはそのままで問題なく、むしろ数量カラムが無いのがおかしいです
初心者が考えるにはいい問題だと思ったけど
受注IDは桁数少なすぎて重複は有り得ると思う。
年ごとにテーブル分けてるのはレコード件数次第でbeforeの方が良い場合もあるよね。
勉強になりました！ありがとうございます！
面白いテーマでした。
「中間テーブル」の件ですが、これが必要になるときは「多対多」のリレーションになる時のみ必要になる、という認識で合っていますか？
このシリーズ好きです！これからもお願いします
ちょうどDBの勉強していたので面白かったです！
これむっちゃくちゃ助かります
23卒情報系学生です。最後の問題の中間テーブルは、FKなのはわかるんですけどPKでもあるんですか？
PKだとしたらPKカラムは一つのテーブルに１つという認識で勉強してたのでイメージが湧きづらいです。いつか違う問題でもいいので解説していただきたいです。
横から失礼します、主キー(PK)は一つのテーブルで複数持てる(いわゆる複合主キー)の場合もあると思います！
dynamoDBでこの企画やって欲しいな・・・
こういうのに正解・不正解はないね。住所を別のテーブルにするかはデータの使い方による。漠然と会社テーブルなら別けてもいいけど、所在地を中心としたデータの使い方であれば住所はそのままで同じ会社でも別の場所であれば別のレコードとする。あと電話番号のハイフン有り無しに関して、すでにあるデータが統一していなければあんまりいじらないほうがいい。ただUIやAPIで何かをベースにフォーマット指定をして、それをもってハイフン無しで保存するのはOK。下手にいじって表示する時に間違ってハイフンを入れたれたりすると後で問題になるから。あと受注IDをPKにするのは止めたほうがいい。（これは動画でも後で触れてますが）
勉強になりました！REST API でもやって欲しいです🙏
他の方々のコメント同様、とても勉強になりました、ありがとうございます！
「達人に学ぶDB設計」を読みましたが、私には動画で学ぶほうが頭に入りやすいようで、助かります。
シリーズ化して、動き（アニメーション）付きの図解で、いろいろなバッドノウハウ、グレーノウハウのクイズ＆解説をしていただけたら嬉しいです！
どうしよう。右の人がイケメソで内容入ってこない。。
後ろの男の子が置物になっている。経験が少ない人(のように見える)がどのように考えているのかを見せてほしい。
前のお兄さんだけが正解を一直線に答えてしまっているのがもったいない。
右の方の言ってること、実際の業務ではそうなる！ってこと言ってる！から正解が本当の正解ではないような気もする
タイトルがいいですね笑
サムネ同じ人3人いるのかと思った
白Tおじさんズ
受注テーブルの品目コードのコード体系は、Excelにエクスポートして開くと前0始まりが0落ちするので、0以外の方がいいかなと思いました。
1001、A001とか。
外部連携されてくるデータとかなら、変えようが無いですが…
そういう理由でテーブル設計しないほうがいいよ。
😅
it企業でも蔓延しているク◯エクセルファイルなんとかなんないでしょうかね。
1対多の観点で情報を管理する概念はDBエンジニア以外には装備されていないんでしょうか。