DB設計を語るスレ 11
>>138
それはバッチで更新されてるかのように見えてるだけでしょ >>137
たとえば販売管理なら月次のテーブルをもって特定月の売上金額や入金額なんかを持つことがある
ランク付けが月毎に確定するような話なら上の例と同じように特定月のランクがどうなるかを持つような話じゃないかと思う
なので実際のテーブル設計は要件をふまえてするわけだし
ここはそういうスレだから「じゃあこんな場合はどうだろう」とかいろいろ話を膨らませてもいいと思うけど
攻撃的なやりとりはできる限りないほうがいいんじゃないかねぇ >>141
>ランク付けが月毎に確定するような話なら
ランク付けが基本的に年単位で確定するような話をしてるんだから同じでしょ >>139
>>>133だと常にUserMembershipを判定しなければいけないし、排他ロックもかかる。
排他ロック?はよくわからないけど必要なロックがかかったところで何か問題がある?
>>136で問題になるのは夜間バッチでusers.rank_idを更新する時にサービスを止めなきゃいけないということ
サービス停止して更新してまたサービス再開するのでも構わないなら>>136でもいいんだけど
サービス停止が伴うから完全自動化するのは難しくて運用負荷が高くなる
バッチ更新の場合でも締めと反映のタイミングをデータでコントロールできるようにするほうが一般的
特にお金のやり取りが絡むランクのアップダウンの場合は すまん
明け方に30分程度サービス停止するサイトは結構あるでしょう >>143
サービス止める=排他ロックのこと言ってると思ったが、どうやら違うようだな
そもそも、サービス停止する必要ないだろ。
バッチ処理が発生する時間帯は、user_ranksテーブルを読みに行けばいいだけだ
スマホゲームなんかも一緒だぞ。
たとえば俺のやっているドラクエウォークは毎日15時にデータが更新されるけど、
更新の準備はバックグラウンドでやってて、15時に公開(適用開始)という流れだろう。
15時前には当然バッチ処理を行い、会員ランクの判定は終えているはずだ
だから、15時前後でサービスが止まることもなければ、
会員の現在のランクが正確に取得できないこともない 普通は使ってに時間帯にバックアップとか保守作業やってます >>145
アフィリエイトのA8も毎月1日の16時まではデータ更新時間としている
だから、会員ランクの判定に時間を要すのは特別おかしくはない >>142
俺の書き方が悪かったと思ってるけど、一定期間ののちランクがきまるならその期間中のランクデータを作るよねって話をしたかっただけさ
販売って自分は買いたからこの場合は大抵月次で締めて請求書出したりするからそう書いただけね EC-CUBEに会員ランクのプラグインがあるんだが、
画面キャプチャ見ると>>136の設計っぽい
https://www.ec-cube.net/products/detail.php?product_id=2492
ランク更新は手動でもできるって書いてるから、
意外とコストがかかるような処理じゃないのかもな >>136
細かいことだけど users.rank_id と user_ranks.rank_id が同じ意味ならどちらか削るべきだな。
users と user_ranks を分ける意味もないかも。 users.id と user_ranks.id があるんだから問題ない。
逆に両方あると更新時異常の危険がある。
余談だけど「リレーション」の使い方がおかしいのはちゃんと学んだことがない証拠。 リレーショナルデータベースでリレーション使ったら駄目なのか・・・ >>146
>更新の準備はバックグラウンドでやってて、15時に公開(適用開始)という流れだろう。
>15時前には当然バッチ処理を行い、会員ランクの判定は終えているはずだ
そういうよくある仕組みをサービス停止せずに実現するためには
15時まで有効なデータと15時以降に有効なデータを1ユーザーあたり最低2件を同時に持ってないと無理
それが>>133と>>136の違い >>154
リレーションとリレーションシップは違うぞ >>148
アフィリエイトよく知らないけど
新しい会員ランクがリアルタイムで取得できなくても困らないからじゃないの?
毎月1日の0~15時にあった流入についても次の締め処理時に新しいランクのトランザクションとして扱えばいい
送料無料にするかどうかのように各トランザクションで最新の会員ランクが必須になるような処理とは若干種類が違う Bardさんに聞いたらこのように言われた。
会員ランクは頻繁に参照されるデータですが、会員ランクテーブルとユーザーテーブルを結合して集計すると、パフォーマンスが低下する可能性があります。ユーザーテーブルにランクを保持することで、高速に参照できます。
会員ランクはユーザーのランキングに影響する重要なデータです。ユーザーテーブルに会員ランクを保持することで、他のテーブルとの関連付けが容易になります。
もちろん、ユーザーテーブルに会員ランクを保持する場合は、会員ランクテーブルにデータを挿入したり更新したりするたびに、ユーザーテーブルのランクも更新する必要があります。これはトリガーなどを利用して自動化できます。 あたりまえの事を言われるけどそれが普通じゃないかね
ランクの確定が不定期なら最新のランクを取り出す条件があいまいになるから特定ユーザーの最新ランクをとるのにコストがかかる
月次や年次であれば2023年5月のランクといった指定で最新のランクが取り出せるからコストは少ない 特定の1ユーザーのランクを取得する話と
ユーザーの全数を対象にしたようなレポーティングの話を同列に語ってない?
前者のクエリコストなんて微々たるものだよ
お金を支払えばその時点から即ランクアップするようなビジネスルールなら
>>136のような構造でも問題ないんだけどね DBの設計次第でビジネスのその後が変わると言っても過言じゃないのに、
あまりにもネット上に情報が少ないよな
今回の会員ランクの話題だって、ググってもピッタリなの出てこないぞ ピッタリも何も要件としてのランク確定のタイミングがわかれば似たような事例なんていくらでも出てくるでしょ >>164
出してくれよ。>>136ですら出してるの見つからないぞ >>162
ふつうはビジネス要件が先でそれに合わせてDB設計するだろ。
設計だけ持ってきてどうするよ。 >>167
夢みたいなビジネス要件持ち出して失望される人? ではビジネス要件書いてください、すぐにしばってご覧にいれます >>168
それって、あんたが要件をまとめたら夢物語になってしまうってこと? 設計の前に要件定義しなきゃならんて話しただけで>>168みたいな反応するのはそういうことなんだろう 現実にはハイレベルのDB設計は要件定義とは切り離せない そもそも>>167が読み違えてる
ビジネス要件決めないと設計できないなら
ER図公開している人らは、何を持って公開してるのかと
「こういうときはこういう設計」という情報を発信したくて公開してるんだろうに
1から10まで決められないと考察すらできないのは無能の証だぞ それで>>174みたいな人はユーザーの要望とは違うものでも「これはこういうものなんです(キリッ」
とかいってユーザーともめるようなシステム提供するんですね
わかりますw
そもそも公開してる情報なんて実際に動いてるものでもなんでもなく
自分で要件をイメージして作ってるだけでしょ
それを持ち出してきて勝手に相手を無能扱いするほうが怖いわ イメージの話ししてるのに仕事の話ししてるのお前だろ 仕事の想定もイメージだろ?何勝手に決めてるわけ
もともとはふわっとした質問なんだからDB設計なんて回答する人の経験度合でいくらでも膨らむ話でやり取りすればいいのに
関係ない話持ち出して無能だなんだ決め打ちするやつの方がよっぽどあたおかでしょ 第三者から見れば君たちすごく似た者同士だよ
言ってることもほとんど同じ
仲良くね アクセンチュアとIBMの高給取りが、概念データモデルの意味がわかってなくて、概念データモデルと論理データモデルと物理データモデルのすべてが最終的な成果物と言っているくらいだからなw 逆に言えばそれら理解できなくても問題ないってことだな >>174
「ビスネス」要件かどうかはともかく
こういうときはこういう設計、の、「こういうとき」がまさに要件だぞ
要件の不明な設計なんて、何の意味もないけど?
まあ往々にして、要件が不明で設計から読み解くことはあるがな 今回の質問者は「こういうとき」については触れてません
皆さん好きに弄ってください、みたいな >>181
RDBMSへの実装を目的とした論理データモデルや物理データモデルとは違って
概念モデルは組織やプロジェクトや用途によってどういうものを作るかかなり違ってくる
それを成果物に含めるかどうかもプロジェクト次第だが
上流工程で食ってる人ほど成果物に含めたほうがお金になる部分だから
アクセンチュアやIBMが最終成果物に入れるのは至極当然の話
自分の考える「正解」に凝り固まらずもう少し視野を広げてみては? >>184
普通に「こういうことしたい」に対して「こうすれば?」の意見は数多く出てるぞ
なぜか後半になってビジネス要件とか言い出してるやつがいるけど >>183
>こういうときはこういう設計、の、「こういうとき」がまさに要件だぞ
「こういうとき」が要件の場合もあればそうでない場合もあるよ
設計選択に影響を及ぼす条件や状況がすべて要件というわけではないからね
それに実践ではDB設計プロセスを通して初めて表面化する要件があるほうが普通だから
ある程度曖昧な条件からでもたたき台となる設計案を提示できる能力ってのはすごく重要 >>187
こういう人が上流工程担当してると満足なもの作れなくて後続の工程担当者に陰で無能扱いされる典型だわな
最後まで荒れるプロジェクトになる典型的な人材w >>187
こういうときはこういう設計の、こういう時が要件じゃない例を挙げてみてくれ
要件定義を理解してなさそうな人に言うほど一般的なケースだとは思えん 実際にDB設計したことないでしょ
してたらこんな発言するわけない
指示されたことしかできないPGでしょ >>185
概念データモデルは、論理データモデル、物理データモデルと違うデータモデルだから、これを残すと整合性が取れていない、ドキュメントとしても意味がないものになる。
概念データモデルは設計時の一時的なもので、論理データモデルができれば捨てるもの。
設計途中のものを残されても、データモデリングというものがわからない日本人には、論理データモデルだと誤解してしまう。 正しい方法が一つだけと決まっているわけではないと思うが意味が分からんなぁ。
概念モデルを残すと整合性が取れないって、その整合性が取れないモデルを基に
論理モデルを作ったということかな? 普通に設計できる人が概念データモデルとそれ以外のデータモデルを間違えるなんてありえないんだが
それをするような人はそもそもわかってないだけでしょ
別に日本人だからとか関係なくね 概念データモデルは設計時の過程で作るもので、なぜか概念データモデルと論理データモデルと物理データモデルは最終的にすべて同じなると思っている自称専門家がいる。 なぜか概念データモデルと論理データモデルと物理データモデルは最終的にすべて同じなると思っている人がいると思ってる人がいる。 異端な主張をするのは自由だけど論拠が無さ過ぎるからそりゃ誰にも相手にされんわ
自称専門家氏が自称専門家呼ばわりしてる人達のほうが常識があるのが手にとるようにわかる 要件定義しなくても設計できるとほざいてた人と同一人物かねえ? 同じってどういう意味で同じっていってるのかしらんが
少なくとも最終的にその三つが整合性がとれないとか、その設計は破綻しとるわ そこはまあ理解できる範囲だけどな
これから作るシステムの概念モデルと出来上がったシステムの概念モデルが同じになるかというと必ずしもそうじゃない
物理モデルを作る時に論理レベルでの修正が発生したら普通は論理モデルも修正するけど
同じことを概念モデルでもやるかといえばやらないことのほうが多いのが実情だから 概念データモデルまでさかのぼってメンテすることはないでしょ
後の工程で作成するデータモデルはよりシステムにあった内容に落とし込むものだし
なので少なくとも概念データモデルにあるのに論理・物理データモデルにその影すらないというのはありえない それらのモデルを設計段階の違いとみなすか抽象度の違いとみなすか、それぞれ考え方が違うってことだろ。
概念モデルは単なるラフスケッチだとする流儀もあってもいいと思うがそれしかないってこともないと思う。 >>200
物理データモデルのテーブル定義、外部キーなどのリレーション、その他の制約まで論理データモデルどころか、概念データモデルに反映するから、設計の過程がなくなってタイトル違いのドキュメントを作るらしい。
概念データモデルでのエンティティ名と論理データモデルのエンティティ名は一致するものと一致しないものが混ざり、エンティティ定義は同じ、そのエンティティの属性名は同じなんだって。 それはそれはエキセントリックな方々をお仕事をされてて微笑ましい >余談だけど「リレーション」の使い方がおかしいのはちゃんと学んだことがない証拠。
あぁ、これ。 シェルスクリプトのことをシェルと手抜きで書くみたいな?
いやいやいやw さすがにシェルスクリプトのことをシェルとは言わない。
なんでみんなシェルスクリプトのことをシェル、シェルと言うのかわからないよな。 WindowsバッチファイルのことをDOSバッチと呼ぶ会社があるけど、なんでDOSなんだよと思っている。 wikipediaをwikiと略すようなものだな。
そういう略し方をしたらバカと思われることを知っている人は当然やらない。 一部の閉鎖的グループだとバカだとか言い出すのかな? >>212
wikipediaはwikiの一種だから文脈によっては全く問題ない
リレーションシップとリレーションやシェルスクリプトとシェルは
関係はあっても包含関係にはない別のものだからJavaScriptのことをJavaと呼ぶレベルの誤用
とマジレスしてみたけどジョークだったかな? 頭の中ではわかってても書いたり口にしたりしたときに端折ってしまっていることはないこともない
ただそれを指摘されたら親しい間柄なら「ごめんごめんリレーションシップのことね」で済ませればいいと思うが
ここは隙あらば見たいな人が多いから注意しないとなw そこは「ごめん、知らなかった。教えてくれてありがとう。」だろ? 結構進んでるからDB設計の話ししてるかと思ったら・・・・ 要件定義を突き詰めれば突き詰めるほど、ネットだけでは完結しないね
利用者の声はあまりネットで拾えないから、リアルの経験が必要になる ネットサービスの要件定義の話ならスレ違いだと思うが >>221
いちいち読んでないところから読み直すのかよw DB設計をAIに相談したら「要件次第」ってお前らみたいなこと言われるんだけど、
要件ってどこまで突き詰めればいいの?
たとえば、ユーザー数やアクセス頻度などを想定していたとしても
運用していくうちに当初の想定と異なるってケースはよくあるじゃん?
小規模だからテーブル数少なくしてたら、レコードが肥大化したり、
大規模だからテーブルを細かく分けたら、保守が大変になったり。 >>229
人間がわかりやすい単位でテーブルを作ればいい
テーブルが多いとたいへんという感覚がわからない。
データモデルが単にわかりにくいだけじゃないのか? AIは人間から学習しててケースバイケースだと断って始まる記事がほとんどだからな >>229
>たとえば、ユーザー数やアクセス頻度などを想定していたとしても
そういう性能要件は逆に設計初期段階では気にしすぎない方がいい。 >>232
じゃ、要件次第ってのは何を見ればいいの? データベースに入れる必要があるデータにはどいういうものがあってそれらの意味や関係がどうなっているか。 >>229
>要件ってどこまで突き詰めればいいの?
要件がすべて出揃って固まってから初めてDB設計をしようとしちゃダメ
ハイレベルのDB設計は要件定義と同時並行で進めるものなので
DB設計上が要件をもっと突き詰めなければいけない状況が出てきたらその都度深めていく
小規模だからテーブル数を少なくとか大規模だからテーブルを細かく分けるというのは意味がわからない
設計時の想定と全く異なる状況になって設計が合わなくなったなら変更すればいいじゃん
最初から当然予測しておくべき変化だったのかどうかは設計力向上のためには重要なポイントにはなるけど >>235
何かやりたいことができたとき、それをどう実現するか考えるだろ?
DB設計とプログラミングを同時に構想すると思うが、
見通しが立たないなら同時並行で進められないじゃん
設計後に「その要件無理だよ」ってなったらどうするのよ >>236
DB設計とプログラミングを同時に構想?
設計後にってのはよくわからんが
設計中に要件が実現不可だって判明したなら
要件を変えるかプロジェクトを中止するしかないじゃん 開発途中に仕様が変わるなんてことは普通にあるから最初から完璧なものを求めなくてもいいと思うけど
作るシステムがどんな運用をしたいかは最初の時点で分かるからそれをまとめるのが要件定義だし
そこから落とし込むのが設計では?
要件にないものを設計する必要はないんだから要件次第っていうのは当たり前だと思うが