- データベース
DBについて
DBとしての捉え方
常に与えられた命題は念頭に、 最終的な出力形態をモデリングに反映させなくてはいけない。
物事をデータベースとして捉えられるように身に着けなくてはいけない
モデリングについて
- DBとしてどうやって捉えているか
化粧品の物流についてどのようにモデリングしたらよいか
マスタ
キーはひとつでなくてよい（業務系に限り）
-
商品マスタ
- 品名
- JAN
- 商品コード
- 単価
- 色
- サイズ
-
仕入先マスタ
-
出荷先マスタ
idをシステムに任す
現場では商品コード、JANコードはユニークなキーになりえない 過去の0001と現在の0001は同じ商品をさしていない場合がある
これを防ぐには商品IDをキーに使うなど、シーンによってキーを使い分ける
論理削除フラグがたってるけどidがことなるけど商品コードが同じという状況が発生する
FWに任すと上記の不整合が起こり得る
FWの癖をわかりつつ使わないといけない
同じレコードがたくさんあってステータスがそれぞれ違うというのが起こっている
ディメンショナルモデル
| 商品 | カテゴリ |
|---|---|
| id | id |
| 名前 | 名前 |
| カテゴリid |
それぞれ1万件あったら
先にカテゴリを絞ってから商品マスタにぶつけてみる という手法
遅いけど、正しい
使うRDBによって手法がそれぞれある
目的に応じて作戦を練る必要がある
例：宅急便
- 送り状番号 13桁(12 + 合計値を7で割ったあまり)
- 届け先
- 送り主
- 品名
- 取扱（割れ物・天地無用・水濡れ厳禁）
- 温度帯（常温・冷蔵・冷凍）
- 支払い方法
送り状番号は自動裁判、送り主・届け先の営業所番号をひく 郵便番号は各社のテーブルから見る 支払い方法から送り状番号の生成ロジックは変わる
採番について
最終の番号をもっておけば、最後の番号までいったらの処理を決めておく
※同梱か同梱できないかもフラグで持っておく必要がある
処理済みフラグを複合キーとして持っておく
toCで数値化できないものを数値化させる難しさ
実際にどう組んだら良いのか
化粧品の場合
セット品なのか、単品なのか
セット品はバラしていいのかだめなのか
商品マスタの他にセット品マスタを用意する
ばらしていいものは1商品扱い
バラせないものはそれを1商品扱いとする
なるべくセット品マスタをメインにシステムを組んでいく
--
機能単位でテーブルのここを見るというのは苦しい
拝殿テーブルに受注伝票の中に拝殿No、 受注伝票テーブルに拝殿と受注No
モデリング練習
化粧品のECサイト
仕入テーブル 商品テーブル 在庫テーブル 注文テーブル 赤伝テーブル ユーザーテーブル
クロンでやるなら5分おき注文データを見て在庫を管理する 計算する対象を限らせるように
在庫計算の難しさ
在庫 ... 100 入庫 ... 20 出庫 ... 30 ーーーーー 在庫 ... 110 棚卸 ... 107 ーーーーー 在庫 ... 107 . . . みたいなことがおきる
在庫
親TBL ーーーー 親id 区分 ... 売・仕・棚
子TBL ーーーー 子id 親id 商品id 数量 + -
カテゴリー
一般的な例
1,
大分類、中分類、小分類でわける
-
大分類マスタ
- id
- 名前
-
中分類マスタ
- 大分類id
- id
- 名前
-
小分類
- 中分類id
- id
- 名前
2,
- カテゴリーマスタ
- id
- 親id
- 名前
| id | 親 | 名前 |
|---|---|---|
| 1 | 0 | a |
| 2 | 0 | b |
| 3 | 1 | c |
| 4 | 3 | d |
大中小で分類するときはこれがきれいかも
共通化のメリデメ
- バグが出ても一部分直せば
ECサイトを作るときに どんなテーブルにどんなカラムがあるのか考える
それをヤフーショッピングやアマゾン、楽天にぶつけて動くか検証する
| 商品マスタ | カテゴリマスタ | 商品カテゴリマスタ |
|---|---|---|
| id | id | id |
| 名前 | カテゴリ名 | 商品id |
| -- | -- | カテゴリid |
| -- | -- | プライオリティ |
1対1でも1対nにしたとき対応できるように想定したテーブルを
結局こういうこと言ってくるよねっていうことを想像しておく
きっとこういうこと言ってくる
この業種ならこういうデータを欲してくるだろうという
人は3秒までは待てる
だいたいSQL自体は1秒くらいで返ってくるけど
表示に時間がかかっている
Googleを支える技術は読んだほうがいいと思う
最終目標
2000万件分のDBデータを一覧で表示するには