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** · 2021/08/28(土) 22:10:23.69

SQL楽しい。

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

10月10日の試験、合格できるだろうか。。

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

4年ぶりの新スレ。

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

どこまで保守すれば良いかわからぬ

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

誰か教えてくれ

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

ミックの本読んで勉強中

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

一応、10までやるわ

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

having句と自己結合使ってメジアン求める式が難解

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

辛いのう

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

乙。

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

保守とかもうやらなくてもよくなったんじゃ？

**NAME IS NULL** · 2021/08/29(日) 00:57:57.90

保守要らんのか。。

**NAME IS NULL** · 2021/08/29(日) 01:04:47.43

データベース板は十数年前のスレッドが生きているくらいだからな。

ギャンブル系の板はすぐにスレッドが消える。

**NAME IS NULL** · 2021/08/29(日) 01:06:18.37

いまちょっとだけ確認したら、18年前に立てられた過疎スレがあった。

**NAME IS NULL** · 2021/08/29(日) 02:48:49.84

本当だ、2003か。俺が大学2年の時だわ。時が経つのは早いなぁ

**NAME IS NULL** · 2021/08/29(日) 06:59:30.61

ちょっと見ただけだけどここが一番古かった
もう数ヶ月で20年、歴史を感じるわ

1 MASM 01/12/16 01:40
XOR AX, AX

8086アセンブラで会話しよう。
https://matsuri.5ch.net/test/read.cgi/i4004/1008434418/

**NAME IS NULL** · 2021/08/29(日) 11:39:07.46

スレのライフタイムが1559日とか感慨深いわ。部署異動したばかりの頃だったな。あの時は若かった

**NAME IS NULL** · 2021/08/29(日) 11:40:31.12

>>17
20年前とか、別人だよな。いまや、太って髪が薄くなったオッサン。

**NAME IS NULL** · 2021/08/30(月) 22:17:32.42

過疎過ぎだな。

**NAME IS NULL** · 2021/08/30(月) 22:18:31.51

データベーススペシャリスト試験前なので、先輩方有益な知識くらさい。。

**NAME IS NULL** · 2021/08/30(月) 22:24:36.12

>>21
デブ女を抱くと合格します。

**選挙に行こう** · 2021/09/04(土) 00:48:23.35

ソ連の核は綺麗な核
ポル・ポトはアジア的優しさ
北朝鮮は地上の楽園
珊瑚自作自演事件
南京・慰安婦捏造
教科書書き換え「誤報」事件
朝日・武富士裏献金事件
拉致問題切り捨て
サイレント魔女リティ
風の息遣い
五味ボマー
変態新聞
村木局長犯人扱い
その他人民裁判ならぬマスコミ裁判は数知れず
そしてマスコミお得意の「報道しない自由」

これでも貴方は新聞を信用しますか
これでも貴方は新聞を購読しますか

よく考えて下さい

**NAME IS NULL** · 2021/09/04(土) 01:43:35.61

サンケイ記者って朝日に採用されなかった奴がなるって本当？

**NAME IS NULL** · 2021/09/04(土) 02:24:29.84

>>24
三流新聞だからね。フジサンケイグループはネトウヨから左翼だと攻撃されて、ネトウヨ寄りになったヘタレ。

**NAME IS NULL** · 2021/09/04(土) 12:47:40.08

親会社はフジテレビ

**NAME IS NULL** · 2021/09/12(日) 18:36:04.79

スペシャリスト試験1ヶ月切って胃が上がってきたっす( ´Д`)y━･~~

**NAME IS NULL** · 2021/09/23(木) 05:13:50.03

あと18日。午後2は何とか仕上げられるかな

**NAME IS NULL** · 2021/09/23(木) 20:20:47.04

疲れた。試験受からぬかもしれぬ(´･ω･`)

**NAME IS NULL** · 2021/10/13(水) 12:35:54.41

落ちたか？

**NAME IS NULL** · 2021/10/17(日) 09:57:42.62

>>30
落ちたわ(´・ω・`)

**NAME IS NULL** · 2021/10/18(月) 10:23:59.29

そっか、次がんばれ。

**NAME IS NULL** · 2021/12/10(金) 09:54:04.29

ブログとか文章を書いていると自動的に下書きされる仕組みがあれます。
あれって、同じテーブルに下書き用のフラグをつけてるのでしょうか？
それとも下書き用のテーブルを用意しているのでしょうか？

**NAME IS NULL** · 2021/12/10(金) 11:10:10.21

それはWebシステム側の仕組みだから
DBはそれに応じて対応する

**NAME IS NULL** · 2021/12/10(金) 15:27:30.67

>>34
Webシステム側の仕組みとしても、下書き用のデータを保存する必要がありますよね？
その保存に関するDB設計を訪ねているのですが・・・

**NAME IS NULL** · 2021/12/10(金) 15:30:14.07

>>33
下書き用テーブルに何か意味があるなら使ってみたら

**NAME IS NULL** · 2021/12/10(金) 15:44:42.40

そんなん設計方針によるだろ
お行儀よくいくならテーブル分けたほうがいいけど、実態としては同じテーブルのことが多いんじゃない
published_at的なカラムがnot null &過去なら後悔っていうロジックにするんじゃね

**NAME IS NULL** · 2021/12/10(金) 15:45:36.70

ブログの更新をどのような手順で行うのか
下書きの保持期間はどのくらいなのか
そのセッションで破棄するのか、数日間保持するのか
公開ページは､公開後に更新しないのか
更新や修正の履歴は残すのか
など、色々あるから

**NAME IS NULL** · 2021/12/10(金) 16:51:08.87

WordPressは同一テーブルに保存する
だから無駄なレコードが増えまくる

**NAME IS NULL** · 2021/12/10(金) 17:26:21.34

公開済み記事を中途半端に編集して一旦下書き保存とか
バージョン管理が必要なら別テーブルのほうがスッキリする

編集中の新バージョンの記事から旧バージョンの記事へのリンクをもたせて
バージョン管理することもできなくはないが諸々の処理が非効率になる

**NAME IS NULL** · 2021/12/11(土) 11:03:18.19

システム側の問題だけど、自動保存は後始末が気になるな
どうしても余計なログが溜まっていくわけだし
cronなんかでわざわざ期限指定削除するのもあれだし

**NAME IS NULL** · 2021/12/11(土) 14:32:09.42

後始末も要件次第
いろいろやり方はある

>>38が書いてるのと同じことだけど
DB設計はきちんと要件を決めることからやらないと

**NAME IS NULL** · 2021/12/11(土) 18:22:10.80

要件次第っていい出したら議論の放棄にしか見えんな

「俺はAだ。だけどBもある。その他いろいろ」
って見解ならわからんでもないが

**NAME IS NULL** · 2021/12/11(土) 18:39:12.30

「フラグをつける場合もあるし、下書き用のテーブルを用意する場合もある」

こう回答すると質問者の意に適うんだろうか
それなら聞かなくても良かったにならないか？

**NAME IS NULL** · 2021/12/11(土) 19:19:59.77

それって単に相手の言葉を引用してるだけじゃん
それなら答えなくても良かったにならないか？

**NAME IS NULL** · 2021/12/11(土) 19:23:13.31

データモデルを本当のプロに任せないプロジェクトが多すぎるんだよなあ。

**NAME IS NULL** · 2021/12/11(土) 19:25:42.35

「牛丼食べたいがどうしたらいい？」
って質問してるやつに、予算や場所や味の好みを聞くようなもんだな

普通に吉野家、松屋、自分で作る、コンビニで買う、冷凍食品を使う
など、それぞれが思うことを言えばいいだけなのに

**NAME IS NULL** · 2021/12/11(土) 20:08:28.64

>>45
与えられた条件だとそういう回答しか返せないって事だろ
それぐらい理解しなよ

>>47
そういう奴に吉野家って言うと味がどうのとか言い出すから

**NAME IS NULL** · 2021/12/11(土) 22:18:44.16

>>43
要件次第ってのは往々にして「もうちょっと考えろや」の婉曲表現なんだよ
どういう点を考えなきゃいけないかもわからないようならそれを質問しろ

流れを見る限りかなり親切なほうだと思うぞ

**NAME IS NULL** · 2021/12/11(土) 22:40:49.50

>「牛丼食べたいがどうしたらいい？」
>って質問してるやつに、予算や場所や味の好みを聞くようなもんだな

要件っていう言葉の意味を理解してないなw

牛丼食べたいなら食べればいいじゃん
なんでそんなことわざわざ聞くの？
どうしたらいいかなんでわからないの？

**NAME IS NULL** · 2021/12/12(日) 00:05:34.74

そこを聞くのがSIerだろう

**NAME IS NULL** · 2021/12/12(日) 01:35:28.32

要件を明確にしないやつにろくなやつがいないから防御本能が働くのかもな

**NAME IS NULL** · 2021/12/12(日) 23:47:20.93

ここで回答してるのはSIerが業務でやってるわけじゃない
質問者は客じゃない

まともな回答がほしいなら要件は質問者がまとめて提示すべきで、要件次第って言われてるってことは
それだけじゃ答えようがないからもうちょっと詳しく条件書けってことだ

**NAME IS NULL** · 2022/01/08(土) 12:19:00.62

お前ら和歌山県出身の下村拓郎様（35歳、元自衛隊）をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ

**NAME IS NULL** · 2022/01/08(土) 20:30:13.82

ｎ；ｎのデータベースを作りたいです。
具体的にはパソコン部品と症状です。
簡単なケースとして
　フリーズする→CPU
　再起動する→CPU
みたいなデータです。
該当パーツを選ぶと関係する症状が出てくる。症状を選ぶと該当するパーツが出てくるという感じです
出来ればwebサイトにて構築したいのです。
難しければEXCELで。
ACCESSだとライセンスの問題が出てきてしまうのでACCESSは最後の最後の手段で
こんなサイトで作れるよとか
こんなソフトあるよ等アドバイスいただければ幸いです。
よろしくお願いしますm(__)m

**NAME IS NULL** · 2022/01/09(日) 05:39:32.50

>>55
Excelでパソコン部品と対応する症状の列を作って、存在する全ての組み合わせ入れてからフィルターかければいいんじゃね？

使う場所や目的がわからないけどさ

**NAME IS NULL** · 2022/01/09(日) 11:21:16.40

>>55
データベースならどんなやつでも作れるよ
設計スレなので設計の話をするとパーツ、症状、パーツと症状の組み合わせ、の3つのテーブルを作ればいいだけ

ちなみに「フリーズする」とか「再起動する」症状の原因はドライバだったり
アプリケーションだったりパーツとは関係ないことが大半
なので手間かけてWebサイト作るよりもまずはExcelでまとめたほうがよさそう

**NAME IS NULL** · 2022/01/09(日) 11:26:01.77

何か部品と症状をタブ区切りにしてgrepやawk使って出来そうな気がする

**NAME IS NULL** · 2022/01/09(日) 22:53:18.78

>>56-58
ありがとうございます。
一番手軽なのは56番さんのやり方ですね
57番さんの言う通りソフト要因は当然ありますね
56＆57番さん
手軽にアプリケーション不要で誰でもどこからでも参照、検索出来るようにしたいと思い
webアプリケーション？web上に構築したくて質問させていただきました。
とりあえずEXCELでデータ入力してどこかに構築出来そうなアテが出来たら移行してみたいと思います。
ありがとうございましたm(__)m

**NAME IS NULL** · 2022/02/18(金) 23:12:05.70

プロフィールなどの設計で画像カラムが必要な場合、
1つの画像ならプロフィールテーブルに1つあれば十分ですが、
複数画像なら別テーブルにしますよね？
その際、「一覧に表示する画像（サムネイル）」はどうやって決めるのでしょうか？
画像テーブルにフラグでもつけるのでしょうか？

**NAME IS NULL** · 2022/02/18(金) 23:17:35.30

DB設計として

■プロフィールテーブル
ID｜名前
■画像テーブル
ID｜プロフィールID｜ファイル名｜フラグ

としたら、
SELECT * FROM プロフィール INNER JOIN 画像　ON プロフィール.ID=画像.プロフィールID WHERE フラグ＝1

みたいな感じで絞り込めば良さそうな気はしますが

**NAME IS NULL** · 2022/02/19(土) 02:04:25.88

とりあえずはそれでもいいのかもしれないが実際設計するなら
プロフィールと画像の関係/ビジネスルール、画像データの使い方(CRUD)、データ件数、要求性能なんかをまず明らかにしてから考える

例えば
プロフィール1個につき必ず1つサムネイル用の画像が必要か？
一覧に表示する画像はプロフィール1個につき1つだけか？

**NAME IS NULL** · 2022/02/19(土) 08:06:38.62

>>62
なるほど。要件が増えるにつれてテーブル設計も変わってくるわけですね。
ただ、画像テーブルをわけることである程度は対応できそうです。
>>61の設計ならサムネイル用の画像が複数になっても
「サムネイル」というカラムにチェックが入ればいい形にできるし、
一覧に表示する画像が増えても同様かと。

画像ってつい1つのテーブルにまとめがちですが、
「画像01、画像02・・・」みたいなカラムで対応しているアプリも多いので、
もっと深く要件を追求して考えなければけませんね

**NAME IS NULL** · 2022/02/19(土) 13:07:07.13

>なるほど。要件が増えるにつれてテーブル設計も変わってくるわけですね。
要件が増えたわけではなく>>62に書いてるのは最初の設計段階で明らかにしておくべきこと

プロフィール1つに対して複数の画像を紐付けたい場合
プロフィールと画像でテーブルを分けるのはRDBの場合は当たり前
その2つのテーブルをどういう設計にするかは要件次第

性能目的で1テーブルに非正規化する場合が全くないわけではないがかなり特殊なケース
そういう場合でも普通は正規化した構造を先に考える

**NAME IS NULL** · 2022/02/19(土) 13:51:18.95

>>60
> その際、「一覧に表示する画像（サムネイル）」はどうやって決めるのでしょうか？
それを決めるのが要件定義

> 画像テーブルにフラグでもつけるのでしょうか？
それは実装だから要件が決まったらまたおいで

**NAME IS NULL** · 2022/02/23(水) 14:56:20.38

要件によっていろんな形の設計がありうるから
こういうのはDB設計力を高めるには結構いいお題

**NAME IS NULL** · 2022/02/24(木) 11:01:46.54

>>60
タイムスタンプ

**NAME IS NULL** · 2022/03/02(水) 00:21:11.73

ＨｅｉｄｉＳＱＬの作者があっさりMaterializedView非対応だとのべて逃げてしまった
５年前
そんなばかな

ひょっとしてMaterializedViewってアンチパターンなのか？

**NAME IS NULL** · 2022/03/17(木) 06:57:42.06

恥ずかしい話なんだが20年くらいPGやっててDB設計やSQLが苦手でいつもできるやつにまかせてたんだけどやっぱ一から勉強しないとダメだなって思ってるんだけど最低限これできれば恥かかないよってのあったら色々おせーてください

**NAME IS NULL** · 2022/03/17(木) 17:04:05.20

SQL
レベル1: データの作成/更新/抽出やテーブル/ビュー/インデックスの作成/変更ができるようになる
レベル2: 実行プランが読めるようになる
レベル3: クエリのチューニングができるようになる

レベル1はその辺のドリル形式とかの入門書で比較的すぐに身につく

レベル2はRDBのアーキテクチャ理解が必須なので教科書的な本かベンダー資格で勉強するといいと思う
教科書的な本はこういうやつ。DB設計の基礎とも重なる部分
https://www.ohmsha.co.jp/book/9784274225161/

レベル3は実践 + チューニングに特化した本とかで知識を増やせばいいと思う
↓このサイトの内容やこの人が書いてる本はオススメ
https://use-the-index-luke.com/

DB設計は上でいうSQLのレベル2になってからはじめればいい

**NAME IS NULL** · 2022/03/17(木) 18:18:52.56

20年PGやってれば、自分でみてよい設計か悪い設計か判断つくだろうに

>>70
つか歴20年でさすがにレベル1もクリアしてなければ恥ずかしいとかいうレベルじゃないぞｗ

**NAME IS NULL** · 2022/03/17(木) 18:24:00.02

＞いつもできるやつにまかせてた

相当えらい人なんではないかな？

**NAME IS NULL** · 2022/03/17(木) 19:43:06.27

てか、そのできる奴とやらにどういう処理なのか聞けば良くね？

**NAME IS NULL** · 2022/03/17(木) 21:16:26.49

>>71
SQLが苦手という人はだいたいレベル1が満足にできないもんよ
ちなみにSQLが得意とアピールする人も大半はレベル1の人なので要注意

プログラマー歴10年以上でも実行プランはコストだけ見る人とか
インデックス使ってそうかどうかくらいしか分からない人のほうが多い
その辺を見るのにベンダー資格はある程度役に立つ

**NAME IS NULL** · 2022/03/18(金) 10:35:46.15

得意なんて言葉使ってる人はこれに限らず普通のレベルでしょ（人並程度ですとかわらん）

**NAME IS NULL** · 2022/03/18(金) 11:57:45.97

>>75
君は日本語能力が普通のレベルに達してないね

**NAME IS NULL** · 2022/03/20(日) 15:03:20.97

調べれば調べるほどわからんことが出てきていつになっても得意なんて言えない

**NAME IS NULL** · 2022/03/21(月) 00:06:16.03

「あなたの得意な技術は何ですか？」
「調べれば調べるほどわからんことが出てきていつになっても得意なんて言えないです」
「。。。。。(ハイ、不採用っと)」

**NAME IS NULL** · 2022/03/21(月) 03:13:56.04

流石にそんな馬鹿正直には言わんよw

**NAME IS NULL** · 2022/03/22(火) 01:33:40.94

>>78
面接官は阿呆だから、個人差を軽視するんだよなあ。

なぜか特定のことしかできない人間をその道のプロだと思い込んでしまう。

**NAME IS NULL** · 2022/03/22(火) 02:07:42.35

君が阿呆な面接官しか見たことないのはなぜか考えようねw

**NAME IS NULL** · 2022/03/22(火) 11:16:01.61

良い質問だ、今度面接に来た奴に出してみる

**NAME IS NULL** · 2022/09/08(木) 13:38:01.86

Yは4

**NAME IS NULL** · 2022/09/10(土) 10:00:03.75

面接官が理解できる範疇で答えないとダメなのは確かなこと。

**NAME IS NULL** · 2023/03/23(木) 12:43:47.04

DB設計の初歩について教えてください。
ECサイトのproductsテーブルの設計で以下の様なデータがあった場合には、後述するテーブルの様に正規化するのが正しいでしょうか？
|id|商品名 |型番|色|容量|
|id|iPhone14 Pro Max| MQ993J/A| Deep Purple |128GB|
|id|iPhone14 Pro Max| MQ9E3J/A| Deep Purple |256GB|
|id|iPhone14 Pro Max| MQ983J/A| Gold |128GB|
|id|iPhone14 Pro Max| MQ9D3J/A| Gold |256GB|
|id|iPhone14 Pro Max| MQ973J/A| Silver |128GB|
|id|iPhone14 Pro Max| MQ9C3J/A| Silver |256GB|
|id|iPhone14 Pro Max| MQ963J/A| Space Black |128GB|
|id|iPhone14 Pro Max| MQ9A3J/A| Space Black |256GB|
|id|iPhone14 Pro |MQ0F3J/A| Deep Purple |128GB|
|id|iPhone14 Pro |MQ173J/A| Deep Purple |256GB|
|id|iPhone14 Pro |MQ073J/A| Gold |128GB|
|id|iPhone14 Pro |MQ173J/A| Gold |256GB|
|id|iPhone14 Pro |MQ013J/A| Silver |128GB|
|id|iPhone14 Pro |MQ0Y3J/A| Silver |256GB|
|id|iPhone14 |MR3Q3J/A| Yellow |128GB|
|id|iPhone14 |MR3R3J/A| Yellow |256GB|
|id|iPhone14 |MPVJ3J/A| Blue |128GB|
|id|iPhone14 |MPWN3J/A| Blue |256GB|
|id|iPhone14 |MPUD3J/A| Midnight |128GB|
|id|iPhone14 |MPVW3J/A| Midnight |256GB|
|id|iPhone14 |MPWV3J/A| Midnight |512GB|

商品テーブル
id 商品名
1 iPhone14 Pro Max
2 iPhone14 Pro
3 iPhone14

色テーブル
id 色
1 Deep Purple
2 Gold
3 Silver
4 Space Black
5 Yellow
..more

容量テーブル
id 容量
1 64GB
2 128GB
3 256GB
4 512GB
5 1TB

商品詳細テーブル
id 商品ID 型番色ID 容量ID
1 1 MQ993J/A 1 2
2 1 MQ9E3J/A 1 3
3 1 MQ9J3J/A 1 4
4 1 MQ9N3J/A 1 5
5 1 MQ983J/A 2 2
6 1 MQ9D3J/A 2 3
7 1 MQ9H3J/A 2 4
8 1 MQ9M3J/A 2 5
.....more

**NAME IS NULL** · 2023/03/23(木) 21:46:48.18

よくｗからないならとりあえず第三正規形にしとけ、というのはよく言われる話。
とはいえ正しく正規化をするにはそれなりの知識は必要だな。
>>85を見る限り正規化とは関係ないテーブル分割も混じっているし。

**NAME IS NULL** · 2023/03/24(金) 16:22:52.88

>>85
商品詳細テーブルの型番がユニークでIDと型番が1対1であれば
一応は第三正規形とみなせるので正規化の練習問題なら概ねいいと思う
実戦なら検索と更新の方法や扱う商品の種類など様々な状況に依存するから単純な正解はない

**NAME IS NULL** · 2023/03/24(金) 16:24:28.93

ECサイトで商品管理の一番中心となる商品マスタは「商品詳細テーブル」にあたるもので
このテーブルで自社が管理する商品番号から特定の商品を一意に特定できるようにする

でも「商品詳細テーブル」という命名とカラムの並べ方からそういう認識ではなさそうに見えたのが少し気になったところ

**NAME IS NULL** · 2023/03/24(金) 16:43:27.62

商品詳細テーブルが何か違うと思う
idはともあれ、商品IDが1固定というのは変

**NAME IS NULL** · 2023/03/24(金) 18:35:45.73

>>85
商品詳細テーブルに書いてる例が全部iPhone14 Pro Maxだから1

**NAME IS NULL** · 2023/03/24(金) 19:33:46.97

>>85
キーや関数従属性の正確なところがわからないと確実ではないが
たぶん分割前のproductsテーブルのままでも第三正規形。
その分割自体は正規化とは直接関係ない。

**NAME IS NULL** · 2023/03/24(金) 23:09:43.98

確かに言われてみれば最初のテーブルが全カラムをカバーできてるということなら第三正規形と言えそうだね

現実には機種や色は書いてる以外の属性が入ってくるだろうから第三正規形でも分割が必要かもしれないのと
色や容量は機種によって取りうる組み合わせに制約があるから第五正規形までを考えるとその組み合わせが表現できるテーブルを作ることになる

**NAME IS NULL** · 2023/03/24(金) 23:25:50.90

>現実には機種や色は書いてる以外の属性が入ってくるだろうから第三正規形でも分割が必要かもしれないのと

そういうのを正規化で分割し終わった結果があのテーブルかもよ

**NAME IS NULL** · 2023/03/25(土) 01:17:58.97

>>93
Deep PurpleとかをFKの値として使ってるってこと？
それは試験問題でしかありえなくない？

**NAME IS NULL** · 2023/03/25(土) 09:32:28.88

>>94
色に従属する他の属性があるなら別テーブルにするだろうし必要に応じてFKを設定することもあるだろう。
文字列のキーが現実的じゃないってことかな？どちらにしても正規化とは別の話だと思うが。

**NAME IS NULL** · 2023/03/27(月) 05:13:43.88

基本的な SQL 文法をある程度理解して、小さいアプリを作ってるレベルなんですが、
そこそこ大規模な DB も設計してみたいのです。
設計の参考にしたいので、テーブル設計を公開している Web サービスがあれば教えて頂けないでしょうか？

**NAME IS NULL** · 2023/03/27(月) 11:10:45.81

StackOverflowとかWebサービスではないけどRedmineとかは参考になると思う
和製ならEC-CUBEとかもDBスキーマ見れる
ただしかなり微妙

**NAME IS NULL** · 2023/03/28(火) 06:46:47.78

>>96
古本でいろんなものが安く手に入る。
出版はかなり前のものだが、いまだに売れ続けている。

ネットよりももっと専門家が書いている一般書籍の方が信頼できる。

**NAME IS NULL** · 2023/03/28(火) 10:34:51.77

>>97
>和製ならEC-CUBEとかもDBスキーマ見れる
EC-CUBEを見ればこの程度でもいいのかという自信がつくw

**NAME IS NULL** · 2023/03/28(火) 19:13:03.36

翔泳社のデータベースマガジンを書籍化したものなど、古い本だがいまでも考え方はかわらない。

**NAME IS NULL** · 2023/03/28(火) 22:36:51.48

グラス片手にみたいなやつかｗ
あれは読んで損はないけど設計未経験者向けの教科書的内容だから
ああいうのベースでそのまま大規模の設計とかしたらクビ飛ぶぞ

**NAME IS NULL** · 2023/03/28(火) 22:56:04.50

>>101
それじゃない。

とにかくいろんな人間が書いた過去の本を読めばいい。

実務経験のない講師やら、実務経験の少ない人間が書いたやつはダメだ。

しかし、そういうダメな教科書的なことしか言わない人間の本を読むのも重要。

何がどうダメなのかを理解していないとな。

**NAME IS NULL** · 2023/03/28(火) 22:58:35.34

>>101
翔泳社だけでも「データベース」で検索すれば、データモデリング関連の本はたくさん出てくる。

https://www.shoeisha.co.jp/search?search=%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9&p=4

**NAME IS NULL** · 2023/03/28(火) 23:01:53.85

翔泳社で「データモデリング」で検索するとこんな出てくる。

https://www.shoeisha.co.jp/search?search=%E3%83%87%E3%83%BC%E3%82%BF%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0

俺はこの中の本の数冊は昔から持っている。

**NAME IS NULL** · 2023/03/28(火) 23:03:59.08

「実践的データモデリング入門」は書かれた時代が違うから、高い有料のモデリングツールを使う説明になっている部分があるが、内容は悪くないうえにモデリングツールを単にいまの主流に読み替えればいいだけ。

**NAME IS NULL** · 2023/03/28(火) 23:05:52.90

単に古い本というだけで排除してしまう無能、キータでも読んでいればよい

実践的データモデリング入門 (DB Magazine SELECTION) https://amzn.asia/d/2MXR5YU

**NAME IS NULL** · 2023/03/29(水) 12:09:18.98

急に一人で会話はじめてマジキモいな

**NAME IS NULL** · 2023/03/29(水) 13:31:43.26

ここには君一人しかいない

**NAME IS NULL** · 2023/03/31(金) 19:50:21.66

>>107
それ日本人独特の日本人はみんな同じという変な考え方

外国では自分と他人はやること、なすことをが違うので、気持ち悪いなどとは言わないし、何も思わない。

この業界にいるなら、少しは日本人に寄せない外国人とやっているはずだ。
もしそういう外国人を知らないなら、この業界はきついぞ。

**NAME IS NULL** · 2023/04/07(金) 22:12:13.79

まるで求人担当の人みたいな物言い

**NAME IS NULL** · 2023/04/11(火) 20:07:58.35

日本にいる外国人と仕事をしたことねえんだろうな。
何もかも違うことをして、言い争いになって、最後は完成していないがお金をよこせと言う。

**NAME IS NULL** · 2023/04/11(火) 20:44:35.40

完成までの残り作業はお前が頑張れ

**NAME IS NULL** · 2023/04/11(火) 22:50:41.17

>>112
外国人に来てもらっても、さらにひどくなるだけ。日本人を教育した方がはるかによい。

- · 2023/04/13(木) 01:51:22.60

以下のサンプルのような正規化前のCSVを正規化されたDBに
振り分けるようにインポートするのは可能でしょうか？
（事前に部署テーブルにデータは定義されている前提です。）

## CSV
id, name, division
1, 佐藤, 営業
2, 鈴木, 営業
3, 高橋, 経理
4, 田中, 人事

## DB
### 社員テーブル
id, name, division_id
1, 佐藤, 1
2, 鈴木, 1
3, 高橋, 2
4, 田中, 3

### 部署テーブル
id, division_name
1, 営業
2, 経理
3, 人事

**NAME IS NULL** · 2023/04/13(木) 03:54:31.92

>>114
設計とは関係ないような・・・
CSVを一時テーブルに取り込んでからSELECT INTOがおすすめ

**NAME IS NULL** · 2023/04/14(金) 02:02:43.38

>>114
CSVのデータが想定外だった場合の考慮がなさすぎる。

プログラムでゴリゴリやりたいなら、やればいいと思うが、元データをいきなり加工してしまうのは、システムの設計としては、どの段階でおかしかったのか、わからない手順になるので完成によくない設計思想。

**NAME IS NULL** · 2023/04/14(金) 10:05:17.25

書かれてないことを指摘するのは良いが、
＞（事前に部署テーブルにデータは定義されている前提です。）
と言っている以上、それを尊重した方が良い

**NAME IS NULL** · 2023/04/14(金) 15:09:55.69

>>117
言いたいことはよくわかるんだけどその前提を書いた意図は
部署テーブルも生成しながらインポートしたいわけではないということを伝えたかっただけで
部署テーブルに存在しない部署名がCSVには絶対出てこないという意味ではないと思うよ

部署名だけでなくidの問題なんかもあるから>>116の1行目の指摘はまあ普通
ただ元データを加工するわけではないし
振り分けながらインポートしてもどの段階でおかしくなったのかも普通にわかるので
後半の指摘はいつも通り的外れだなと思う

**NAME IS NULL** · 2023/04/14(金) 15:18:13.52

>>114のような処理内容ならSSISとかのETLツール使えば
GUI操作だけでエラーハンドリングなんかも含めて簡単にバッチ処理が作れるけど
ツールの使い方を覚えるの必要があるからSQLだけでやる方法で十分ならそれに越したことはない

**NAME IS NULL** · 2023/04/14(金) 15:45:14.15

質問が微妙スギだけど
・部署テーブルは情報登録済み
・やりたいのはCSVから社員テーブルへのインポート
・社員テーブルにインポートするときは部署名から部署IDに変換したい
であれば普通に部署IDのカラムはSELECT id 部署テーブル WHERE division_name = CSVのdivision でとってくればいいんじゃねと思うけど
ワークテーブルにいったんいれてからの　INSERT ～ SELECT でもいいと思うけどね
つかこれってSQL質問スレの話題じゃないのか

**NAME IS NULL** · 2023/04/14(金) 16:41:46.31

なるほどDB設計関係なさそうなのにここに書いたのはSQL質問スレがないからだったのか
納得

**NAME IS NULL** · 2023/04/17(月) 21:21:43.06

：2021/08/28(土) 22:08:57.33

**NAME IS NULL** · 2023/05/21(日) 11:30:33.67

会員ランクに関するテーブル設計で悩んでいます。
よくある「ブロンズ会員」「シルバー会員」「ゴールド会員」というのを実現したい場合、

会員　　　｜ID、名前
会員ランク｜ID、会員ID、ランクID、開始日時、終了日時
ランク　　　｜ID、ランク名

というテーブル設計で実現できます。
ただ、
「ブロンズ会員なら購入金額から○％割引」
「シルバー会員になるには購入回数が○回以上」
「ゴールド会員の年会費は○円」

のような条件を入れたい場合、どのテーブルにカラムを用意するべきでしょうか？
ランクテーブルに入れるのか、ランク条件テーブルに入れるのか、
また、会員への付与と会員になる条件を同じテーブルにしても良いのか？
など、悩む部分が多いです。

最終的な要件によると思いますが、
会員ランクを設計したことがある人がいれば、考え方を教えてください。

**NAME IS NULL** · 2023/05/21(日) 12:29:24.30

>また、会員への付与と会員になる条件を同じテーブルにしても良いのか？

そこ迷うならまずは別で考えるべきだね。
例として挙げられた条件はそれぞれランクに対する特典、加入条件、年会費とかになると思うけど
まずはそれぞれがなにを表すのか明確にしたうえでランクとの関係を検討する。
例えばランクに対する年会費が1つだけ必ず存在するなら同じテーブルに収めてしまってもいいかもしれないし、
特典が複数考えられるならそれは別テーブルにするしかない。

**NAME IS NULL** · 2023/05/21(日) 13:53:34.63

>>124
ありがとうございます。
特典は用途が違うので別にした方が良さそうですね。
今のところ割引率しか考えていませんが、
ランク更新時にポイントの付与や、送料無料なども入れたいです。

また条件は「ランクになるための条件」という意味なので、
同じテーブルでも良さそうですね。

考えがまとまりました。ありがとうございました。

**NAME IS NULL** · 2023/05/21(日) 15:09:12.58

DB設計で難しいところは
「ビジネスルール・将来のための柔軟性」と
「アプリ・DB構造の複雑性」のトレードオフの判断

例えば会員ランクに開始終了日時をもたせてるのは
「会員XXXはY月Z日からはゴールド会員」のような未来予約ができるようにするため思うんだけど
こういう種類の柔軟性が特典・加入条件・年会費に必要かどうかを
ビジネス要求と実装の両面から判断しないといけない

仮にランクになるための条件が増えたりした場合に
その要件が決まってからアプリだけでなくDBを改修したのでも十分だと判断したなら
別テーブルで行持ちにせずに同じテーブルで列持ちにしたのでもOK

**NAME IS NULL** · 2023/05/21(日) 16:48:20.23

>>126
そこが難しいですね。
冷静に考えると、ビジネス要求を想定するなら
最小限の構成からスタートする方が良いと思います。
なぜなら、実際にスタートしてみないとわからないからです。

何日も悩んでベストの設計をひねり出すよりも、
ベターな設計で開発を始めた方が良い気がするんですよね。
極論を言えば、ビジネスとして成立するのであれば
上級のエンジニアに任せるという手もありますし。

今私はテーブル設計の勉強をしているだけで、
ビジネス用途として考えてないので、色々と想定していますが。

**NAME IS NULL** · 2023/05/22(月) 03:53:10.85

>>123
ER図を書いてみれば、わかりにくさに気づくよ。

**NAME IS NULL** · 2023/05/22(月) 09:53:15.09

会員ランクの用途が不明だけど、自分なら会員に会員ランクの情報を定義すると思う
（会員ランクから最新の情報を取得するにはコストがかかるため）
会員ランク自体は履歴参照程度に使うだけにするかね
この設計をふまえて
「ブロンズ会員なら購入金額から○％割引」
「シルバー会員になるには購入回数が○回以上」
「ゴールド会員の年会費は○円」
こちらは全てランクに項目を持つようにすれば結果的に拾いたい情報は会員とランクだけでOK
まあいろんな考えがあるから試行錯誤するといいかもね

**NAME IS NULL** · 2023/05/22(月) 11:01:43.06

各会員の購入回数やらゴールド会員年会費納付年月日やら

**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

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