DB設計を語るスレ 10 [無断転載禁止]©2ch.net

**NAME IS NULL** · 2017/05/22(月) 16:38:31.52

語れ

前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/

**NAME IS NULL** · 2020/10/20(火) 14:56:58.07

なぜ指摘した本人に理由を聞かないのか

そもそもそれほんとにちゃんとした正規化が出来てるのか？
正規化を避けるべき理由はないのか？

そもそも設計を提出ってなんだよ。業務なのか？
だったらなぜ上司ではなく詳しそうな人なんだ

**NAME IS NULL** · 2020/10/20(火) 15:05:03.53

もしかしてRDBじゃなくMongoみたいの使う前提なのかな？

まあ指摘した本人に理由を聞くべきなのは間違いない

**NAME IS NULL** · 2020/10/20(火) 15:31:38.20

理由ははぐらかされてしまいました
そっちのほうがいい気がする
というようなことを言っていました

> もしかしてRDBじゃなくMongoみたいの使う前提なのかな？
RDBです

**NAME IS NULL** · 2020/10/20(火) 16:12:36.27

技術的な面じゃなくサーバーが年代物で貧弱とか
開発予算がないから手抜きで作るとか政治的な事だったり

**NAME IS NULL** · 2020/10/20(火) 17:39:35.83

正規化した設計とかフラットにした設計の中身が
もう少し具体的にわからんとなんとも言えないね

フラットにすることで更新異常が発生しうるんなら
メリットデメリット理解して選択するしかない

**NAME IS NULL** · 2020/10/20(火) 19:58:51.65

>>725
世の中には自分の理解できないものは使うな
って言う上司とか先輩はいっぱいいる
その人に従わないとダメなら言質を押さえて従うがよろし
単に詳しそうな身近な人と言うだけならもう変更の工数ないからとか言って無視しとけばいい

**NAME IS NULL** · 2020/10/21(水) 00:08:11.04

原則は教科書通りにるすのが一番ですが

場数踏んだ熟練のPGさんとか
製造工数おさえてギリokみたいな
絶妙な作りしてくる人もいる
理由は経験とカンみたいな

気にやまないことだと思います

**NAME IS NULL** · 2020/10/21(水) 01:41:41.26

すぐに言語化できなくても直感的にモヤッとする設計ってのはある
必ずしもその直感が妥当というわけではないんだけど
熟練になればなるほど感覚的なものも大事にしたほうがいい

**NAME IS NULL** · 2020/10/21(水) 01:49:04.44

なんとなく分かる
気持ち悪い設計って確かにある

**NAME IS NULL** · 2020/10/21(水) 13:04:54.08

第4や第5とかボイス何たらとかを第3に戻されたとか？

**NAME IS NULL** · 2020/10/21(水) 13:07:36.31

第5はともかくボイスコッドで設計できる人の質問ではない気がする

**NAME IS NULL** · 2020/10/21(水) 17:30:47.48

詳しそうで素人な人もいるぜ
クソ設計なテーブルで、プログラム書かされて死にそうになったことある

**NAME IS NULL** · 2020/10/23(金) 14:20:38.63

>>736
ボイスコッドの方が難易上なの？
自分が理解し切れてないのだけど、ボイスコッド正規形は条件満たすだけならまあ簡単だけど実務とか現実世界の関係的に違和感のある設計になるよくわからんもの、みたいなイメージがある……

**NAME IS NULL** · 2020/10/23(金) 23:40:51.85

実務のボイスコッド正規形は理論のそれと違って
導出属性を使った制約を追加することで第三正規形から関数従属性を失わずに
ある種のビジネスルールをデータモデルに埋め込むことができる

第3や第5よりもBC正規形使った設計ができる人のほうが
DB設計に対して深い理解があると思うよ

**NAME IS NULL** · 2020/11/30(月) 22:31:04.06

とりあえずサロゲートキー持たせたいとき（持たせるって表現で良いのか解らないけど）って、
数字のみの連番にする？　何か文字列も付与する？　ケースバイケース？

数字のみで良いのかなと思ってたんだけど、文字列付けた方が良い時ってあるんじゃろか

**NAME IS NULL** · 2020/11/30(月) 23:55:06.66

サロゲートキーという範疇に入らないかもしれないがUUIDを使ったほうがいいケースは自然と文字列も入る
分散データベース間でも一意に識別したいとかDBにアクセスせずに一意なIDを生成したい場合

でもそういうのはDBのプライマリキーには使わないから
1つのテーブル内の一意性で十分で、数字の連番を使い切る可能性がなければ文字列を入れる理由はないかな

他には人間に読みやすくかつ間違いにくくするために文字を入れるケースもあるけど
その場合は生成した数字とは別のカラムで文字列込みの値を管理する

**NAME IS NULL** · 2020/12/01(火) 00:00:33.65

最初に文字を入れると全部桁数は揃うだろうから見た目は気持ちはいいかもな

**NAME IS NULL** · 2020/12/02(水) 02:52:19.08

>>741
なるほど。こういうのもあるのか
> その場合は生成した数字とは別のカラムで文字列込みの値を管理する

これはこれで、それぞれのカラム名どうしようとか悩みます
文字列込みにした方が人間に読みやすいのは確かなんだけど、２つ管理するのも不慣れなせいかしっくりこない
選択肢が増えてますます混乱したｗ

**NAME IS NULL** · 2020/12/02(水) 09:55:10.43

そもそも代理キーに文字を入れたいとか、代理キーになんらかの意味を持たせたいってことだろ
それすでに代理キーじゃなくね

**NAME IS NULL** · 2020/12/04(金) 10:49:18.51

>>744
代理キーならあるでしょ
サロゲートキーの話をしてるなら同意するけど

**NAME IS NULL** · 2020/12/04(金) 11:41:14.98

>>745

>>715

**NAME IS NULL** · 2021/01/04(月) 11:20:12.25

商品に、表示フラグ、新着フラグ、18禁フラグや、表示優先順位などWeb上の表示だけに特化した値を持つ場合、商品マスタに書いてしまっていいのでしょうか？それとも別に持ったほうがいいのでしょうか？

**NAME IS NULL** · 2021/01/04(月) 12:28:55.25

表示フラグと18金ｗはいるだろうな
他は、コロコロ変わるものだから
別にして良いと思う

**NAME IS NULL** · 2021/01/04(月) 18:53:45.42

>>747
商品マスタの構成や商品マスタをどう使う前提なのかによる

一般論で言えば商品IDが決まれば値が確実に決まるような属性なら商品マスタに書く
商品すべてがWeb上で扱う前提ならWebに特化した値も商品マスタに書いてもいい
Webに特化した属性のCRUDのタイミングが商品マスタの基本属性と異なるなら
別テーブルにしたほうがいい可能性が高い

18禁フラグ以外は商品ID+日時の組み合わせで管理できるようにしておいたほうが運用は楽
(商品マスタ自体が商品ID+日時の組み合わせで一意になるようなら更新頻度/更新タイミングなどから別テーブルにするかどうか検討)

あと新着かどうかは販売開始日付みたいなのからアプリで判断するほうが普通

**NAME IS NULL** · 2021/01/04(月) 21:39:09.85

サロゲートキーにulid 使うのは異端？
スレ検索してもulid 出てこないね。

**NAME IS NULL** · 2021/01/04(月) 22:01:16.35

サロゲートキーにUUIDを必要とするユースケース自体がかなり稀だからね

**NAME IS NULL** · 2021/01/04(月) 23:04:35.94

ごめん、ちゃんと注意して書けば良かった。
128bitのUUID(Universally Unique Identifier)ではなくて、
同じく128bit(Timestamp 48 bit + Randomness 80 bit)のULID(Universally unique Lexicographically sortable IDentifier)。

日時でソートできるUUID的なヤツなんだけど、あんま使われてないんかな？

**NAME IS NULL** · 2021/01/04(月) 23:37:36.45

わかってるよ
UUIDを必要とするユースケース以外でULID使うことないでしょ

**NAME IS NULL** · 2021/01/04(月) 23:55:03.99

仰る通りです。すいませんでした。

**NAME IS NULL** · 2021/01/05(火) 00:56:58.70

それサロゲートキー項目に一意性と日時って二つの意味を持たせることになるんじゃね
ありえないな。日時でソートしたいならちゃんと日時の項目もつべき

**NAME IS NULL** · 2021/01/05(火) 01:50:26.16

生成順にソート可能にするための実装として日時を使っているからといって
日時の意味を持たせてるということにはならないよ

ULIDから日時を取り出してデータ作成日時として利用するなら別だが

**NAME IS NULL** · 2021/01/05(火) 15:53:27.55

日時としての意味はなくても、その日時で生成順としての意味をもたせてるじゃないか

シーケンスとか生成順に使うような場合って実際には結構あるけど、本来それも間違ってる
昔のオラクルのマニュアルとか生成順は保証しないようなこと書いてあったんだがなぁ

**NAME IS NULL** · 2021/01/05(火) 17:16:48.59

大小比較可能な値を生成したら「二つの意味を持たせてるからありえない」ってどういう脳みそしてるんだか

オラクルが正だと思ってるようなやつは中途半端な知識で
斜め上の御託を並べ立てるやつが多くて困る

**NAME IS NULL** · 2021/01/05(火) 20:05:33.88

一意保障以外に大小比較って意味をもたせてるんだから二つの意味なんだが
サロゲートキーに一意保障以外の意味を持たせるなって大原則をまず理解しような

**NAME IS NULL** · 2021/01/05(火) 20:08:21.25

シーケンスのDB発番はクラスタ化が難しいので元々ありえない。

UUIDは日時でソート出来ない。

ULIDはソート出来るだけでありがてぇ。パーティショニングで役に立ちそう。あ、DB発番しないよ。

**NAME IS NULL** · 2021/01/05(火) 20:24:27.35

だったら素直にUUIDと日付列用意すればいいんじゃね
インデックスの効率落ちそうだ

**NAME IS NULL** · 2021/01/05(火) 22:59:49.77

>>759
なんで2つ意味を持たせると良くないのかをまず考えろよ
その理由を理解せずにトンチンカンなことばっかり言ってマウント取ろうとするからいつもバカにされてるんだぞ

**NAME IS NULL** · 2021/01/09(土) 14:41:54.56

上の話どうなった？
自分740の質問した人間なので気になる

きのこたけのこ論争みたいなもんで正解はないやつ？

**NAME IS NULL** · 2021/01/09(土) 16:21:49.00

UUIDの代替としてULID使うべきかどうかはケースバイケースだからその点ついての正解はない
ULID使いたければ特徴と限界を理解した上で使えばいい
まだ比較的新しいものだから標準ライブラリ相当で安定した実装が提供されてる言語は少ない

二つの意味を持たせてる云々は少し考えればわかるでしょ

**NAME IS NULL** · 2021/01/10(日) 00:03:48.39

ULIDはUUIDのパフォーマンス問題を軽減できるのが一番大きい

**NAME IS NULL** · 2021/01/10(日) 07:38:57.64

>>765
インサートが遅くなるアレ？
ulid 解決できるんだ！？

**NAME IS NULL** · 2021/01/10(日) 08:36:14.08

UUIDを主キーにするって人は、衝突しないって前提でやってるの？

**NAME IS NULL** · 2021/01/10(日) 08:59:33.73

そりゃそのために作られたものなわけだし。使う場合はその前提に乗っかるのが当たり前。

**NAME IS NULL** · 2021/01/10(日) 16:24:43.84

UUID使ってるシステム見たけど
データが無駄にデカイし
インデックスもやたら膨らむしで
主キーに使うのも考えもんだな
気持ちはわからんでもないが

**NAME IS NULL** · 2021/01/10(日) 16:25:36.71

主キーなら衝突したらわかるでしょ

**NAME IS NULL** · 2021/01/10(日) 18:29:44.20

>>770
衝突しない前提なら、衝突したときのリトライ処理等は不要だ
つまり衝突したときの対処してるかって質問だろ

**NAME IS NULL** · 2021/01/10(日) 18:59:06.79

それはエラーをどう扱うかという話で衝突しない前提ではないよ
ユーザーにリトライを促すような個別の対処はしてなくても集約エラーハンドラで結局対処してる

**NAME IS NULL** · 2021/01/10(日) 20:54:05.63

だから、UUIDが衝突したときに個別の対応してるかって質問なんだが
まあ、お前がやってないだろうことは理解した

GUIDが衝突したって話は聞いたことがある
UUID衝突の可能性はゼロではないんだが、まあ起こったときの重要度次第か

**NAME IS NULL** · 2021/01/10(日) 20:58:18.48

>>773
お前質問者じゃないじゃん

**NAME IS NULL** · 2021/01/10(日) 21:33:58.44

UUIDやULIDって衝突した事を想定した方がいいの？
だったらオートインクリメントで良い気がする。

**NAME IS NULL** · 2021/01/10(日) 21:36:18.27

トランザクションが失敗したらリカバリなりするだろうが、キーの重複が原因の時だけ特にどうこうってのはないんじゃないかね

**NAME IS NULL** · 2021/01/10(日) 22:06:27.15

オートインクリメントのように一箇所で採番できる状況ならUUIDは使わないよ

**NAME IS NULL** · 2021/01/10(日) 22:26:37.20

プロシージャー書いて自前で発番すれば良いのではないか

**NAME IS NULL** · 2021/01/11(月) 18:12:04.80

UUID/ULIDよりも18禁商品マスタのほうがいかにもDB設計っぽい内容にもかかわらずレス数が桁違いになるのはなぜなんだ？

**NAME IS NULL** · 2021/01/11(月) 19:03:34.36

>>747ならどっちが正しいと決まるもんでもないから、追加情報でもない限りそれ以上話が広がらないし
単純に内容がつまらない。

**NAME IS NULL** · 2021/01/11(月) 21:33:51.50

設計スレなのにどっちが正しいか決まるようなものを期待してるのか
理解に苦しむ

**NAME IS NULL** · 2021/01/11(月) 22:15:19.50

質問者はどっちがいいか聞いてるわけだろ？でもどっちでもいいから話はそこでおしまい。

**NAME IS NULL** · 2021/01/11(月) 23:24:18.82

>>779
机上の知識だけでコメントしやすい内容か
設計の経験がないとコメントしにくい内容かの違い
珍しくにぎわってるからいいんじゃないの

**NAME IS NULL** · 2021/01/27(水) 15:50:40.26

QiitaのWeekly Trendで4位に入ってたから読んでみたが・・・
https://qiita.com/abe_masanori/items/1a2b9c1f1069c43237f8

扱ってる題材のレベルが低いのは初心者向けだからいいとしても
こんな問題だらけのデータモデルとユースケース書いて平気な顔してる開発者はやばいよな？

**NAME IS NULL** · 2021/01/27(水) 18:11:58.87

マイクロサービスとかいって、REST API 呼び出しをループで大量に実行しようとする
これの気持ちだけちょっとわかる

やれoop、やれdddのお作法に合わせて
少ない件数でテストしてできました！
とかやる奴

**NAME IS NULL** · 2021/01/27(水) 21:24:38.53

Qiitaとか見てる奴いるんだｗ

**NAME IS NULL** · 2021/01/27(水) 22:06:01.60

会員登録しないとまともに機能しないサイトは検索上位から消しほしいよ

**NAME IS NULL** · 2021/01/27(水) 22:17:56.84

Googleで検索すると上位に出てきてしまうんだよな
判断力がない奴が読むと、とても危険

**NAME IS NULL** · 2021/01/27(水) 23:20:18.99

DB設計には誰も触れないw
>>783は至言

**NAME IS NULL** · 2021/01/27(水) 23:29:01.05

サンプルだし目くじら立てるほどか？

グルグルSQLどころか
ぐるぐるコネクションされて
性能調査に回って来た時には吹いたから
気持ちはまあわかる

コードのオブジェクト指向的
美しさ、べき論を説かれたが
俺はプログラマーじゃないから
ようわからんかった

**NAME IS NULL** · 2021/01/27(水) 23:59:32.65

コードの美しさよりも処理スピードの方が大事

**NAME IS NULL** · 2021/01/28(木) 00:19:06.32

SQLだけでなんとかしようとするやつも困りもの

**NAME IS NULL** · 2021/01/28(木) 00:57:25.39

ネットショップで画面に商品リストとその詳細仕様を表示する処理があったんだ
前任者はどう作ったかというと、まず商品一覧を取得するSQLを発行した
そのSQLが返してくれる商品一覧に対して、一つずつ詳細取得するSQLを発行した
10件位の時は問題がなかった。多分前任者はこれでOKにしたんだろう
ショップがオープンして、100件、1000件と扱うようになった途端、
メチャクチャに処理に時間が掛かるようになった
で、どう直したかというと、商品一覧を取得する段階で、細かく詳細も取得するようにした
詳細取得が商品種類毎に違っていて、SQLは場合分けが必要で複雑になってしまったが
客は結果を見て喜んでOKを出してくれた

なんでこうなったかと考えて見ると、詳細設計書段階で、
取得する手順の記述があったからのようだ
設計書はとてもシンプルで綺麗な記述になっていた

※この話はフィクションです、実在する人物・企業とは関係ありません

**NAME IS NULL** · 2021/01/28(木) 07:25:30.60

1000件の詳細情報を、一度に取得して表示ねぇ...

まあなんにしても、DB設計の話じゃないな

**NAME IS NULL** · 2021/01/28(木) 11:06:31.58

>>785
マイクロサービスに限らず逐次処理と一括処理とでAPIを分けるのが常識なので
テスト以前のAPIのレビュー時に気づくべきことじゃないか？

**NAME IS NULL** · 2021/01/28(木) 13:02:17.02

SQLを直接書いてるのにN+1で問題になるようなコード書くような人間は周りにはいないな

ORM経由のN+1は仕組みをよく理解してない人間がやらかすけど
そういうのも本番環境に出る前には確実に修正される

DB側で検知する仕組み入れとくと確実かもね

**NAME IS NULL** · 2021/01/28(木) 19:08:58.61

>>784
これはヒドイ

プレミアム会員フラグや商品価格を変更できないw
ぐるぐる以前の問題

**NAME IS NULL** · 2021/01/28(木) 20:39:20.13

商品価格変更されたらどうするんだろうと悩ませておいて、問題文の隅っこに
「価格改定の場合は新規に商品IDを発行する」なんて条件が書いてあったりする
情報処理試験のパターン。

**NAME IS NULL** · 2021/01/29(金) 14:26:13.74

>>798
同じ商品に対して複数のPKを発行できるようにするならモデルが違ってくる

**NAME IS NULL** · 2021/01/29(金) 16:10:44.32

情報処理試験を受けさせてるベンダーほどまともなDB設計できないよね

**NAME IS NULL** · 2021/01/29(金) 18:53:57.86

このタイプの派生関係を使う場合は
読み取り用にはViewを用意してやるといい
各SQLで毎回ケアするのは無駄

**NAME IS NULL** · 2021/01/29(金) 22:45:33.21

>>799
>同じ商品に対して複数のPKを発行

意味不明。
「同じ商品に対して複数の商品ID」なら意味が通じなくもないが
その部分は>>784には描かれていない。

**NAME IS NULL** · 2021/01/29(金) 23:19:36.29

>>802
「同じ商品に対して複数の商品ID」を発行するとして
どうやって同じ商品かどうかを判別するの？

**NAME IS NULL** · 2021/01/29(金) 23:26:28.28

どうやってもなにも、「同じ商品」を判別できるデータを持たせるしかないわな。

**NAME IS NULL** · 2021/01/30(土) 00:26:36.49

同じ商品かどうかを判別するための識別子が必要だよね
それを一般的には商品IDと呼ぶことが多いから複数の商品IDじゃなく複数のPKと書いたわけ

名前は別にいいんだけど
同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
それをモデルに描かないのはありえない

それにある商品の標準価格を変えようとすると
対応するプレミアム価格も変更が必要になる
なら別テーブルにする意味ない

**NAME IS NULL** · 2021/01/30(土) 03:02:35.12

一つの商品ID、商品テーブル、価格テ―ブルで良くね?

**NAME IS NULL** · 2021/01/30(土) 08:22:17.42

>>805
>名前は別にいいんだけど
>同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
>それをモデルに描かないのはありえない

そりゃ設計書としてならあり得なんだろうが実際>>784には商品とか
商品名とか描いてないじゃん。そこで説明したいポイントには関係ないから
省略したんだろうが。

>同じ商品かどうかを判別するための識別子が必要だよね
>それを一般的には商品IDと呼ぶことが多いから

一般にはそういうことが多いとしても、「商品ID」は絶対そうでなくては
ならないという決まりも無いわけなんで、そこはちゃんと定義を
確認しなきゃならん。

>複数の商品IDじゃなく複数のPKと書いたわけ

PKってのはテーブルの定義なんでそこは明らかに間違い。
「商品に対する商品ID」か「商品テーブルのPK」じゃなきゃ
意味が通じない。

**NAME IS NULL** · 2021/01/30(土) 11:58:25.05

>>798
>「価格改定の場合は新規に商品IDを発行する」

その場合でも注文データに確定した支払い金額を記録するぞ
バッチ処理でユーザーごとの購入金額を集計するのに
マスタから価格持ってくるような設計はやばい

**NAME IS NULL** · 2021/01/30(土) 12:01:57.13

>>807
わかってないのに無理してレスすんな

**NAME IS NULL** · 2021/01/30(土) 12:23:10.14

子供の喧嘩じゃないんだから、反論があるなら具体的にな

**NAME IS NULL** · 2021/01/30(土) 12:49:10.58

長いからちゃんと読んでないけどあの記事で言いたいのって
ぐるぐる SQLは性能に問題が出るからやめようねって話なんじゃないの？
テーブル設計はあくまで例であって、そこをここで突っ込んでも…

**NAME IS NULL** · 2021/01/30(土) 15:04:12.14

でもレス返してるやつはそれで正しいと思って返してるのでは？

**NAME IS NULL** · 2021/01/30(土) 16:13:55.14

いいも悪いもあれだけで断言できんだろ

**NAME IS NULL** · 2021/01/30(土) 17:35:24.51

>>811
まともなDB設計ならぐるぐるSQLすら発生しないだろ

**NAME IS NULL** · 2021/01/30(土) 18:02:21.65

そしたら件の記事は設計変更しないでぐるぐる解消しているから「まともな設計」ってことになるが

**NAME IS NULL** · 2021/01/30(土) 18:13:42.82

>>790
コードの美しさとは無関係というか両立できる問題じゃないかなあという気がするんだがどうなんだろう
> ぐるぐるコネクションって、ループの内部で都度接続と切断繰り返してる処理であってる？

>>808
現時点の注文（＝買い物かご）と注文履歴は別管理なんじゃねって言う勝手な想像

**NAME IS NULL** · 2021/01/30(土) 18:14:32.10

運用面で破綻しなければそれはそれでよい設計なのでは？
うちの販売システムは発注伝票の内容は全てトランザクションデータとして保存するし
商品マスタは通常もセットも含めて1テーブルだけど

**NAME IS NULL** · 2021/01/30(土) 18:49:31.12

>>806
顧客や顧客種別ごとに単価を管理する場合はそうするのが普通

ただプレミアム会員向けの単価が登録されてなければ標準単価を採用するみたいなロジックはアンチパターンだから普通はやらない

単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する

**NAME IS NULL** · 2021/01/30(土) 23:22:05.33

>>816
コードの美しさ云々は単なるいいわけでしょ
リモートのAPI呼び出しをローカルに閉じた関数呼び出しと同じように扱おうとする連中と同じ

**NAME IS NULL** · 2021/01/30(土) 23:26:08.18

陽キャ先輩「それDBに任せるともっと良くなるかも！」
俺「一瞬で終わって草ァ！SQLすげぇｗｗｗｗｗｗｗｗ」

陰キャ先輩「はぁ…ぐるぐるSQLは止めてください」
俺「あっすみません気を付けます… ぐるぐるって何でしょうか…」
陰キャ先輩「知らないの？スキーマがこうでアプリのコードがこうだとするでしょ」
俺「あっあっはい」
陰キャ先輩「ループがねオーバーヘッドがねマイクロサービスとか言ってる奴等なんて」
俺「はい… はい…」

**NAME IS NULL** · 2021/01/31(日) 05:54:37.13

>>807
>そこで説明したいポイントには関係ないから省略したんだろうが。
そもそも、元のやつの設計が複数の商品IDを発行する設計だと思ってるのか？

つかまあ、あれはほんとのシステムの設計としてはあり得んレベルだけどな
あの記事が言いたかったのはそんなことじゃないだろ

**NAME IS NULL** · 2021/01/31(日) 09:41:56.04

一例を出してこういう処理の仕方はやめましょうっていう内容の記事に対して
本番稼働を前提に設計レビューをしてくれる掲示板

**NAME IS NULL** · 2021/01/31(日) 11:13:07.54

>>818

単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する

これと、価格テーブルが1個であることとは矛盾しない

価格種別を決定するコンテキストがあれば良い

**NAME IS NULL** · 2021/01/31(日) 11:17:15.54

サンプルだからいいってレベルじゃないんだよな
あれを許容できるやつは普段同レベルの設計をしてるとしか思えない

**NAME IS NULL** · 2021/01/31(日) 11:24:40.01

求職サイトだから仕方がない