DB設計を語るスレ 11

**NAME IS NULL** · 2021/08/28(土) 22:08:57.33

語れ

前スレ
DB設計を語るスレ 10
https://mevius.5ch.net/test/read.cgi/db/1495438711/

**NAME IS NULL** · 2023/05/22(月) 11:19:17.69

>>127
ベストな設計なんて世の中に存在しないから
ベターな設計で開発を始めたほうが良いのは至極当たり前のことなんだけど
何を持ってベターな設計と判断するかという判断基準を持ち合わせてないはどうしようもないよね
持ち合わせてたら>>123のような質問しないでしょ？

勉強用の架空の要件に対する設計であっても
考えうる選択肢を出してみてそれぞれどういうメリット・デメリットがあるのかを
自分なりに細かい要件を想定しながらしっかり考えないと設計能力はつかないよ

**NAME IS NULL** · 2023/05/22(月) 11:20:12.26

>>130
そうそうこういう項目をどう管理するかのほうがDB設計的には重要だったりするよね

**NAME IS NULL** · 2023/05/22(月) 12:17:34.06

試しにChatGPTに設計サンプル出してもらったら概ね>>124の形で出てきた
要件をもっと細かく伝えればたたき台としてなら実用可能なものを作ってくれそう

Users: user_id(PK), username, email, password, other user-related fields
MembershipRanks: rank_id(PK), rank_name, rank_description, annual_fee
RankConditions: condition_id(PK), rank_id(FK to MembershipRanks), condition_description, min_purchases
RankBenefits: benefit_id(PK), rank_id(FK to MembershipRanks), benefit_description, increased_points, discount_percentage, free_shipping_enabled
UserMembership: user_id(FK to Users), rank_id(FK to MembershipRanks), acquired_date, expiration_date

**NAME IS NULL** · 2023/05/22(月) 13:31:32.85

言うほど>>124と一緒か？
>>129が言うように会員に会員ランクを定義するのとも違うし、
ベストとかベターの前に色々ありすぎて答えなんて出ないだろ

**NAME IS NULL** · 2023/05/22(月) 14:10:47.79

>>134
>言うほど>>124と一緒か？
ほぼ一緒でしょ
Usersテーブルが>>123の会員テーブルで
UserMembershipが>>123の会員ランクテーブルに相当
特典、加入条件はランクテーブル(MembershipRanks)とは別テーブル管理にして
年会費だけランクテーブルに組み入れてる

といっても俺は124じゃないから124の意図した内容が俺の理解と違ってたら知らんけど

**NAME IS NULL** · 2023/05/22(月) 14:12:37.98

users:id(PK),rank_id(FK),name
ranks:id(PK),name,annual_fee,min_purchases,discount_percentage
user_ranks:id(PK),rank_id(FK),acquired_date, expiration_date

■会員のランクを取得
SELECT users.name,ranks.name FROM users INNER JOIN ranks ON users.rank_id=ranks.id

■会員ランクが有効なユーザーを取得
SELECT users.name FROM user_ranks INNER JOIN users ON user_ranks.user_id=users.id WHERE acquired_date <= '2023-05-22' AND expiration_date >= '2023-05-22'

■特定の会員（user_id:1）への特典を取得
SELECT ranks.discount_percentage FROM ranks INNER JOIN users ON ranks.id=users.rank_id WHERE rand_id='1'

■そのランク（rank_id:1）になる条件を取得
SELECT annual_fee,min_purchases FROM ranks WHERE rand_id='1'

これで良くないか？SQLの実行数も少ないし、わかりやすいと思うんだが。
user_ranksはログみたいな扱いにして、最新のレコードをinsertした後に
usersのrank_idをupdateすればJOIN回数も減るし、サブクエリも必要ない。

**NAME IS NULL** · 2023/05/22(月) 14:34:27.93

>>136
ビジネスルールや運用次第でそれで良い場合もあれば良くない場合もある
主にusers.rank_idをどのタイミングでどう更新するかという問題
お金を払うタイミングと会員ランクを変更するタイミングを常に一致させるようなルールならそれでも可
じゃなければシステム停止してバッチで更新みたいなことが必要になるから普通はDB設計を変える

**NAME IS NULL** · 2023/05/22(月) 14:55:13.80

ポオントサイトだと夜間バッチが普通だと思う
購入額合計が基準値越えたからってランクがその場で上がった経験は無いな

**NAME IS NULL** · 2023/05/22(月) 15:12:49.13

夜間バッチに、参照テーブルみたいなのを用意するのが普通だと思うが。
>>133だと常にUserMembershipを判定しなければいけないし、排他ロックもかかる。
>>136だとユーザー情報にランク情報を紐づけているわけだから、
同時に更新するタイミングはない。
お金を払うタイミングで現在のランクを参照できるわけだから、
お金を払ってる時にランクが変わるという問題もない

**NAME IS NULL** · 2023/05/22(月) 15:22:45.15

>>138
それはバッチで更新されてるかのように見えてるだけでしょ

**NAME IS NULL** · 2023/05/22(月) 15:24:47.54

>>137
たとえば販売管理なら月次のテーブルをもって特定月の売上金額や入金額なんかを持つことがある
ランク付けが月毎に確定するような話なら上の例と同じように特定月のランクがどうなるかを持つような話じゃないかと思う
なので実際のテーブル設計は要件をふまえてするわけだし
ここはそういうスレだから「じゃあこんな場合はどうだろう」とかいろいろ話を膨らませてもいいと思うけど
攻撃的なやりとりはできる限りないほうがいいんじゃないかねぇ

**NAME IS NULL** · 2023/05/22(月) 16:09:37.41

>>141
>ランク付けが月毎に確定するような話なら
ランク付けが基本的に年単位で確定するような話をしてるんだから同じでしょ

**NAME IS NULL** · 2023/05/22(月) 16:16:29.57

>>139
>>>133だと常にUserMembershipを判定しなければいけないし、排他ロックもかかる。
排他ロック？はよくわからないけど必要なロックがかかったところで何か問題がある？

>>136で問題になるのは夜間バッチでusers.rank_idを更新する時にサービスを止めなきゃいけないということ
サービス停止して更新してまたサービス再開するのでも構わないなら>>136でもいいんだけど
サービス停止が伴うから完全自動化するのは難しくて運用負荷が高くなる

バッチ更新の場合でも締めと反映のタイミングをデータでコントロールできるようにするほうが一般的
特にお金のやり取りが絡むランクのアップダウンの場合は

**NAME IS NULL** · 2023/05/22(月) 16:24:11.52

ネットショップで夜更けから

**NAME IS NULL** · 2023/05/22(月) 16:25:08.17

すまん
明け方に３０分程度サービス停止するサイトは結構あるでしょう

**NAME IS NULL** · 2023/05/22(月) 16:25:56.89

>>143
サービス止める＝排他ロックのこと言ってると思ったが、どうやら違うようだな

そもそも、サービス停止する必要ないだろ。
バッチ処理が発生する時間帯は、user_ranksテーブルを読みに行けばいいだけだ

スマホゲームなんかも一緒だぞ。
たとえば俺のやっているドラクエウォークは毎日15時にデータが更新されるけど、
更新の準備はバックグラウンドでやってて、15時に公開（適用開始）という流れだろう。
15時前には当然バッチ処理を行い、会員ランクの判定は終えているはずだ

だから、15時前後でサービスが止まることもなければ、
会員の現在のランクが正確に取得できないこともない

**NAME IS NULL** · 2023/05/22(月) 16:27:45.67

普通は使ってに時間帯にバックアップとか保守作業やってます

**NAME IS NULL** · 2023/05/22(月) 16:28:53.86

>>145
アフィリエイトのA8も毎月1日の16時まではデータ更新時間としている
だから、会員ランクの判定に時間を要すのは特別おかしくはない

**NAME IS NULL** · 2023/05/22(月) 18:48:17.95

>>142
俺の書き方が悪かったと思ってるけど、一定期間ののちランクがきまるならその期間中のランクデータを作るよねって話をしたかっただけさ
販売って自分は買いたからこの場合は大抵月次で締めて請求書出したりするからそう書いただけね

**NAME IS NULL** · 2023/05/22(月) 19:39:00.04

EC-CUBEに会員ランクのプラグインがあるんだが、
画面キャプチャ見ると>>136の設計っぽい
https://www.ec-cube.net/products/detail.php?product_id=2492

ランク更新は手動でもできるって書いてるから、
意外とコストがかかるような処理じゃないのかもな

**NAME IS NULL** · 2023/05/22(月) 20:53:51.42

>>136
細かいことだけど users.rank_id と user_ranks.rank_id が同じ意味ならどちらか削るべきだな。
users と user_ranks を分ける意味もないかも。

**NAME IS NULL** · 2023/05/22(月) 21:18:50.05

>>151
削ったらリレーションできないぞ

**NAME IS NULL** · 2023/05/22(月) 21:46:06.35

users.id と　user_ranks.id があるんだから問題ない。
逆に両方あると更新時異常の危険がある。

余談だけど「リレーション」の使い方がおかしいのはちゃんと学んだことがない証拠。

**NAME IS NULL** · 2023/05/22(月) 23:14:44.67

リレーショナルデータベースでリレーション使ったら駄目なのか・・・

**NAME IS NULL** · 2023/05/22(月) 23:21:53.10

おかしな使い方はな。

**NAME IS NULL** · 2023/05/23(火) 10:39:48.93

>>146
>更新の準備はバックグラウンドでやってて、15時に公開（適用開始）という流れだろう。
>15時前には当然バッチ処理を行い、会員ランクの判定は終えているはずだ
そういうよくある仕組みをサービス停止せずに実現するためには
15時まで有効なデータと15時以降に有効なデータを1ユーザーあたり最低2件を同時に持ってないと無理
それが>>133と>>136の違い

**NAME IS NULL** · 2023/05/23(火) 10:41:39.15

>>154
リレーションとリレーションシップは違うぞ

**NAME IS NULL** · 2023/05/23(火) 10:49:19.20

>>148
アフィリエイトよく知らないけど
新しい会員ランクがリアルタイムで取得できなくても困らないからじゃないの？
毎月1日の0~15時にあった流入についても次の締め処理時に新しいランクのトランザクションとして扱えばいい
送料無料にするかどうかのように各トランザクションで最新の会員ランクが必須になるような処理とは若干種類が違う

**NAME IS NULL** · 2023/05/23(火) 11:42:12.72

Bardさんに聞いたらこのように言われた。

会員ランクは頻繁に参照されるデータですが、会員ランクテーブルとユーザーテーブルを結合して集計すると、パフォーマンスが低下する可能性があります。ユーザーテーブルにランクを保持することで、高速に参照できます。

会員ランクはユーザーのランキングに影響する重要なデータです。ユーザーテーブルに会員ランクを保持することで、他のテーブルとの関連付けが容易になります。

もちろん、ユーザーテーブルに会員ランクを保持する場合は、会員ランクテーブルにデータを挿入したり更新したりするたびに、ユーザーテーブルのランクも更新する必要があります。これはトリガーなどを利用して自動化できます。

**NAME IS NULL** · 2023/05/23(火) 11:59:00.73

あたりまえの事を言われるけどそれが普通じゃないかね
ランクの確定が不定期なら最新のランクを取り出す条件があいまいになるから特定ユーザーの最新ランクをとるのにコストがかかる
月次や年次であれば2023年5月のランクといった指定で最新のランクが取り出せるからコストは少ない

**NAME IS NULL** · 2023/05/23(火) 15:02:02.72

特定の1ユーザーのランクを取得する話と
ユーザーの全数を対象にしたようなレポーティングの話を同列に語ってない？
前者のクエリコストなんて微々たるものだよ

お金を支払えばその時点から即ランクアップするようなビジネスルールなら
>>136のような構造でも問題ないんだけどね

**NAME IS NULL** · 2023/05/23(火) 16:06:00.81

DBの設計次第でビジネスのその後が変わると言っても過言じゃないのに、
あまりにもネット上に情報が少ないよな
今回の会員ランクの話題だって、ググってもピッタリなの出てこないぞ

**NAME IS NULL** · 2023/05/23(火) 16:49:25.79

普通はその情報で商売するし

**NAME IS NULL** · 2023/05/23(火) 18:29:07.47

ピッタリも何も要件としてのランク確定のタイミングがわかれば似たような事例なんていくらでも出てくるでしょ

**NAME IS NULL** · 2023/05/23(火) 18:40:08.05

さてどこから見ようかしら、ネットは広大だわ

**NAME IS NULL** · 2023/05/23(火) 18:50:19.97

>>164
出してくれよ。>>136ですら出してるの見つからないぞ

**NAME IS NULL** · 2023/05/23(火) 19:39:26.70

>>162
ふつうはビジネス要件が先でそれに合わせてDB設計するだろ。
設計だけ持ってきてどうするよ。

**NAME IS NULL** · 2023/05/23(火) 19:46:19.50

>>167
夢みたいなビジネス要件持ち出して失望される人？

**NAME IS NULL** · 2023/05/23(火) 19:49:39.42

ではビジネス要件書いてください、すぐにしばってご覧にいれます

**NAME IS NULL** · 2023/05/23(火) 20:06:29.95

>>168
それって、あんたが要件をまとめたら夢物語になってしまうってこと？

**NAME IS NULL** · 2023/05/23(火) 22:12:02.57

>>170
逆じゃね？

**NAME IS NULL** · 2023/05/23(火) 23:18:08.17

設計の前に要件定義しなきゃならんて話しただけで>>168みたいな反応するのはそういうことなんだろう

**NAME IS NULL** · 2023/05/23(火) 23:56:35.45

現実にはハイレベルのDB設計は要件定義とは切り離せない

**NAME IS NULL** · 2023/05/23(火) 23:59:58.68

そもそも>>167が読み違えてる
ビジネス要件決めないと設計できないなら
ER図公開している人らは、何を持って公開してるのかと
「こういうときはこういう設計」という情報を発信したくて公開してるんだろうに
1から10まで決められないと考察すらできないのは無能の証だぞ

**NAME IS NULL** · 2023/05/24(水) 07:25:16.52

それで>>174みたいな人はユーザーの要望とは違うものでも「これはこういうものなんです（キリッ」
とかいってユーザーともめるようなシステム提供するんですね
わかりますｗ
そもそも公開してる情報なんて実際に動いてるものでもなんでもなく
自分で要件をイメージして作ってるだけでしょ
それを持ち出してきて勝手に相手を無能扱いするほうが怖いわ

**NAME IS NULL** · 2023/05/24(水) 08:52:55.10

イメージの話ししてるのに仕事の話ししてるのお前だろ

**NAME IS NULL** · 2023/05/24(水) 09:56:45.71

仕事の想定もイメージだろ？何勝手に決めてるわけ
もともとはふわっとした質問なんだからDB設計なんて回答する人の経験度合でいくらでも膨らむ話でやり取りすればいいのに
関係ない話持ち出して無能だなんだ決め打ちするやつの方がよっぽどあたおかでしょ

**NAME IS NULL** · 2023/05/24(水) 11:21:54.32

第三者から見れば君たちすごく似た者同士だよ
言ってることもほとんど同じ
仲良くね

**NAME IS NULL** · 2023/05/24(水) 11:25:01.66

仕事募集しているなら、そういう板に移動してやって

**NAME IS NULL** · 2023/05/24(水) 12:08:21.72

なんで急に仕事募集の話になるのかｗ

**NAME IS NULL** · 2023/05/25(木) 01:21:23.01

アクセンチュアとIBMの高給取りが、概念データモデルの意味がわかってなくて、概念データモデルと論理データモデルと物理データモデルのすべてが最終的な成果物と言っているくらいだからなw

**NAME IS NULL** · 2023/05/25(木) 11:00:45.26

逆に言えばそれら理解できなくても問題ないってことだな

**NAME IS NULL** · 2023/05/25(木) 11:35:25.95

>>174
「ビスネス」要件かどうかはともかく
こういうときはこういう設計、の、「こういうとき」がまさに要件だぞ
要件の不明な設計なんて、何の意味もないけど？

まあ往々にして、要件が不明で設計から読み解くことはあるがな

**NAME IS NULL** · 2023/05/25(木) 11:38:42.31

今回の質問者は「こういうとき」については触れてません
皆さん好きに弄ってください、みたいな

**NAME IS NULL** · 2023/05/25(木) 12:54:43.86

>>181
RDBMSへの実装を目的とした論理データモデルや物理データモデルとは違って
概念モデルは組織やプロジェクトや用途によってどういうものを作るかかなり違ってくる

それを成果物に含めるかどうかもプロジェクト次第だが
上流工程で食ってる人ほど成果物に含めたほうがお金になる部分だから
アクセンチュアやIBMが最終成果物に入れるのは至極当然の話

自分の考える「正解」に凝り固まらずもう少し視野を広げてみては？

**NAME IS NULL** · 2023/05/25(木) 13:26:11.97

>>184
普通に「こういうことしたい」に対して「こうすれば？」の意見は数多く出てるぞ
なぜか後半になってビジネス要件とか言い出してるやつがいるけど

**NAME IS NULL** · 2023/05/25(木) 14:54:15.70

>>183
>こういうときはこういう設計、の、「こういうとき」がまさに要件だぞ
「こういうとき」が要件の場合もあればそうでない場合もあるよ
設計選択に影響を及ぼす条件や状況がすべて要件というわけではないからね

それに実践ではDB設計プロセスを通して初めて表面化する要件があるほうが普通だから
ある程度曖昧な条件からでもたたき台となる設計案を提示できる能力ってのはすごく重要

**NAME IS NULL** · 2023/05/25(木) 15:59:02.34

>>187
こういう人が上流工程担当してると満足なもの作れなくて後続の工程担当者に陰で無能扱いされる典型だわな
最後まで荒れるプロジェクトになる典型的な人材ｗ

**NAME IS NULL** · 2023/05/25(木) 16:05:13.47

>>187
こういうときはこういう設計の、こういう時が要件じゃない例を挙げてみてくれ
要件定義を理解してなさそうな人に言うほど一般的なケースだとは思えん

**NAME IS NULL** · 2023/05/25(木) 19:33:12.34

実際にDB設計したことないでしょ
してたらこんな発言するわけない
指示されたことしかできないPGでしょ

**NAME IS NULL** · 2023/05/25(木) 19:39:56.33

指示された通りに作れるPGは優秀

**NAME IS NULL** · 2023/05/26(金) 02:18:22.09

>>185
概念データモデルは、論理データモデル、物理データモデルと違うデータモデルだから、これを残すと整合性が取れていない、ドキュメントとしても意味がないものになる。

概念データモデルは設計時の一時的なもので、論理データモデルができれば捨てるもの。

設計途中のものを残されても、データモデリングというものがわからない日本人には、論理データモデルだと誤解してしまう。

**NAME IS NULL** · 2023/05/26(金) 08:54:55.30

正しい方法が一つだけと決まっているわけではないと思うが意味が分からんなぁ。
概念モデルを残すと整合性が取れないって、その整合性が取れないモデルを基に
論理モデルを作ったということかな？

**NAME IS NULL** · 2023/05/26(金) 09:54:54.36

普通に設計できる人が概念データモデルとそれ以外のデータモデルを間違えるなんてありえないんだが
それをするような人はそもそもわかってないだけでしょ
別に日本人だからとか関係なくね

**NAME IS NULL** · 2023/05/26(金) 20:56:27.16

概念データモデルは設計時の過程で作るもので、なぜか概念データモデルと論理データモデルと物理データモデルは最終的にすべて同じなると思っている自称専門家がいる。

**NAME IS NULL** · 2023/05/26(金) 21:36:07.63

なぜか概念データモデルと論理データモデルと物理データモデルは最終的にすべて同じなると思っている人がいると思ってる人がいる。

**NAME IS NULL** · 2023/05/26(金) 21:41:44.47

異端な主張をするのは自由だけど論拠が無さ過ぎるからそりゃ誰にも相手にされんわ
自称専門家氏が自称専門家呼ばわりしてる人達のほうが常識があるのが手にとるようにわかる

**NAME IS NULL** · 2023/05/26(金) 22:09:28.63

要件定義しなくても設計できるとほざいてた人と同一人物かねえ？

**NAME IS NULL** · 2023/05/26(金) 22:57:10.15

違うけど？

**NAME IS NULL** · 2023/05/26(金) 23:26:24.12

同じってどういう意味で同じっていってるのかしらんが
少なくとも最終的にその三つが整合性がとれないとか、その設計は破綻しとるわ

**NAME IS NULL** · 2023/05/26(金) 23:45:05.50

そこはまあ理解できる範囲だけどな

これから作るシステムの概念モデルと出来上がったシステムの概念モデルが同じになるかというと必ずしもそうじゃない
物理モデルを作る時に論理レベルでの修正が発生したら普通は論理モデルも修正するけど
同じことを概念モデルでもやるかといえばやらないことのほうが多いのが実情だから

**NAME IS NULL** · 2023/05/27(土) 08:46:56.22

概念データモデルまでさかのぼってメンテすることはないでしょ
後の工程で作成するデータモデルはよりシステムにあった内容に落とし込むものだし
なので少なくとも概念データモデルにあるのに論理・物理データモデルにその影すらないというのはありえない

**NAME IS NULL** · 2023/05/27(土) 10:21:15.93

それらのモデルを設計段階の違いとみなすか抽象度の違いとみなすか、それぞれ考え方が違うってことだろ。
概念モデルは単なるラフスケッチだとする流儀もあってもいいと思うがそれしかないってこともないと思う。

**NAME IS NULL** · 2023/05/27(土) 11:49:13.65

>>200
物理データモデルのテーブル定義、外部キーなどのリレーション、その他の制約まで論理データモデルどころか、概念データモデルに反映するから、設計の過程がなくなってタイトル違いのドキュメントを作るらしい。

概念データモデルでのエンティティ名と論理データモデルのエンティティ名は一致するものと一致しないものが混ざり、エンティティ定義は同じ、そのエンティティの属性名は同じなんだって。

**NAME IS NULL** · 2023/05/27(土) 12:29:41.12

それはそれはエキセントリックな方々をお仕事をされてて微笑ましい

**NAME IS NULL** · 2023/05/27(土) 13:03:46.27

>余談だけど「リレーション」の使い方がおかしいのはちゃんと学んだことがない証拠。

あぁ、これ。

**NAME IS NULL** · 2023/05/27(土) 13:54:54.25

>>206
そこは単に手抜きで書いただけ

**NAME IS NULL** · 2023/05/27(土) 16:32:11.30

シェルスクリプトのことをシェルと手抜きで書くみたいな？

いやいやいやｗ

**NAME IS NULL** · 2023/05/27(土) 16:33:45.47

さすがにシェルスクリプトのことをシェルとは言わない。

なんでみんなシェルスクリプトのことをシェル、シェルと言うのかわからないよな。

**NAME IS NULL** · 2023/05/27(土) 16:52:23.10

私はシェルになりたい

**NAME IS NULL** · 2023/05/27(土) 16:58:24.31

WindowsバッチファイルのことをDOSバッチと呼ぶ会社があるけど、なんでDOSなんだよと思っている。

**NAME IS NULL** · 2023/05/27(土) 17:06:31.24

wikipediaをwikiと略すようなものだな。
そういう略し方をしたらバカと思われることを知っている人は当然やらない。

**NAME IS NULL** · 2023/05/27(土) 17:13:01.14

一部の閉鎖的グループだとバカだとか言い出すのかな？

**NAME IS NULL** · 2023/05/27(土) 17:24:17.74

面前では言わんだろ。心の中で思うだけで。

**NAME IS NULL** · 2023/05/27(土) 17:29:59.92

私には、心の中の声が聞こえる！

**NAME IS NULL** · 2023/05/27(土) 17:42:28.43

>>215
気がふれた？

**NAME IS NULL** · 2023/05/27(土) 17:49:01.82

>>212
wikipediaはwikiの一種だから文脈によっては全く問題ない
リレーションシップとリレーションやシェルスクリプトとシェルは
関係はあっても包含関係にはない別のものだからJavaScriptのことをJavaと呼ぶレベルの誤用

とマジレスしてみたけどジョークだったかな？

**NAME IS NULL** · 2023/05/27(土) 18:20:16.24

頭の中ではわかってても書いたり口にしたりしたときに端折ってしまっていることはないこともない
ただそれを指摘されたら親しい間柄なら「ごめんごめんリレーションシップのことね」で済ませればいいと思うが
ここは隙あらば見たいな人が多いから注意しないとなｗ

**NAME IS NULL** · 2023/05/27(土) 18:31:27.06

そこは「ごめん、知らなかった。教えてくれてありがとう。」だろ？

**NAME IS NULL** · 2023/05/27(土) 18:36:45.84

本当、物知りだよねｗｗｗ

**NAME IS NULL** · 2023/05/27(土) 20:25:27.41

結構進んでるからDB設計の話ししてるかと思ったら・・・・

**NAME IS NULL** · 2023/06/07(水) 09:01:55.08

要件定義を突き詰めれば突き詰めるほど、ネットだけでは完結しないね
利用者の声はあまりネットで拾えないから、リアルの経験が必要になる

**NAME IS NULL** · 2023/06/07(水) 22:28:23.68

ネットサービスの要件定義の話ならスレ違いだと思うが

**NAME IS NULL** · 2023/06/08(木) 01:07:19.44

>>221
いちいち読んでないところから読み直すのかよw

**NAME IS NULL** · 2023/06/08(木) 07:48:06.88

お前ら批判ばかりだな

**NAME IS NULL** · 2023/06/19(月) 01:21:03.70

ものを教えるよりケチを付ける方が楽だし、楽しい

**NAME IS NULL** · 2023/06/19(月) 11:50:27.16

教えようよ。損するわけでもないんだし

**NAME IS NULL** · 2023/06/19(月) 20:32:11.12

俺は教えてるよ？聞け。

**NAME IS NULL** · 2023/06/21(水) 16:39:17.93

DB設計をAIに相談したら「要件次第」ってお前らみたいなこと言われるんだけど、
要件ってどこまで突き詰めればいいの？

たとえば、ユーザー数やアクセス頻度などを想定していたとしても
運用していくうちに当初の想定と異なるってケースはよくあるじゃん？
小規模だからテーブル数少なくしてたら、レコードが肥大化したり、
大規模だからテーブルを細かく分けたら、保守が大変になったり。

**NAME IS NULL** · 2023/06/21(水) 17:16:59.27

>>229
人間がわかりやすい単位でテーブルを作ればいい
テーブルが多いとたいへんという感覚がわからない。
データモデルが単にわかりにくいだけじゃないのか？