X
DB設計を語るスレ 11
0101NAME IS NULL
垢版 |
2023/03/28(火) 22:36:51.48ID:???
グラス片手にみたいなやつかｗ
あれは読んで損はないけど設計未経験者向けの教科書的内容だから
ああいうのベースでそのまま大規模の設計とかしたらクビ飛ぶぞ
0102NAME IS NULL
垢版 |
2023/03/28(火) 22:56:04.50ID:jxesX9VZ
>>101
それじゃない。

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

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

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

何がどうダメなのかを理解していないとな。
0105NAME IS NULL
垢版 |
2023/03/28(火) 23:03:59.08ID:jxesX9VZ
「実践的データモデリング入門」は書かれた時代が違うから、高い有料のモデリングツールを使う説明になっている部分があるが、内容は悪くないうえにモデリングツールを単にいまの主流に読み替えればいいだけ。
0106NAME IS NULL
垢版 |
2023/03/28(火) 23:05:52.90ID:jxesX9VZ
単に古い本というだけで排除してしまう無能、キータでも読んでいればよい

実践的データモデリング入門 (DB Magazine SELECTION) https://amzn.asia/d/2MXR5YU
0107NAME IS NULL
垢版 |
2023/03/29(水) 12:09:18.98ID:???
急に一人で会話はじめてマジキモいな
0108NAME IS NULL
垢版 |
2023/03/29(水) 13:31:43.26ID:???
ここには君一人しかいない
0109NAME IS NULL
垢版 |
2023/03/31(金) 19:50:21.66ID:pblyzaz3
>>107
それ日本人独特の日本人はみんな同じという変な考え方

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

この業界にいるなら、少しは日本人に寄せない外国人とやっているはずだ。
もしそういう外国人を知らないなら、この業界はきついぞ。
0110NAME IS NULL
垢版 |
2023/04/07(金) 22:12:13.79ID:???
まるで求人担当の人みたいな物言い
0111NAME IS NULL
垢版 |
2023/04/11(火) 20:07:58.35ID:+S9P9M6L
日本にいる外国人と仕事をしたことねえんだろうな。
何もかも違うことをして、言い争いになって、最後は完成していないがお金をよこせと言う。
0112NAME IS NULL
垢版 |
2023/04/11(火) 20:44:35.40ID:???
完成までの残り作業はお前が頑張れ
0113NAME IS NULL
垢版 |
2023/04/11(火) 22:50:41.17ID:+S9P9M6L
>>112
外国人に来てもらっても、さらにひどくなるだけ。日本人を教育した方がはるかによい。
0114-
垢版 |
2023/04/13(木) 01:51:22.60ID:bc2hwxFd
以下のサンプルのような正規化前の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, 人事
0115NAME IS NULL
垢版 |
2023/04/13(木) 03:54:31.92ID:???
>>114
設計とは関係ないような・・・
CSVを一時テーブルに取り込んでからSELECT INTOがおすすめ
0116NAME IS NULL
垢版 |
2023/04/14(金) 02:02:43.38ID:+wdNjIQU
>>114
CSVのデータが想定外だった場合の考慮がなさすぎる。

プログラムでゴリゴリやりたいなら、やればいいと思うが、元データをいきなり加工してしまうのは、システムの設計としては、どの段階でおかしかったのか、わからない手順になるので完成によくない設計思想。
0117NAME IS NULL
垢版 |
2023/04/14(金) 10:05:17.25ID:???
書かれてないことを指摘するのは良いが、
＞（事前に部署テーブルにデータは定義されている前提です。）
と言っている以上、それを尊重した方が良い
0118NAME IS NULL
垢版 |
2023/04/14(金) 15:09:55.69ID:???
>>117
言いたいことはよくわかるんだけどその前提を書いた意図は
部署テーブルも生成しながらインポートしたいわけではないということを伝えたかっただけで
部署テーブルに存在しない部署名がCSVには絶対出てこないという意味ではないと思うよ

部署名だけでなくidの問題なんかもあるから>>116の1行目の指摘はまあ普通
ただ元データを加工するわけではないし
振り分けながらインポートしてもどの段階でおかしくなったのかも普通にわかるので
後半の指摘はいつも通り的外れだなと思う
0119NAME IS NULL
垢版 |
2023/04/14(金) 15:18:13.52ID:???
>>114のような処理内容ならSSISとかのETLツール使えば
GUI操作だけでエラーハンドリングなんかも含めて簡単にバッチ処理が作れるけど
ツールの使い方を覚えるの必要があるからSQLだけでやる方法で十分ならそれに越したことはない
0120NAME IS NULL
垢版 |
2023/04/14(金) 15:45:14.15ID:???
質問が微妙スギだけど
・部署テーブルは情報登録済み
・やりたいのはCSVから社員テーブルへのインポート
・社員テーブルにインポートするときは部署名から部署IDに変換したい
であれば普通に部署IDのカラムはSELECT id 部署テーブル WHERE division_name = CSVのdivision でとってくればいいんじゃねと思うけど
ワークテーブルにいったんいれてからの　INSERT ～ SELECT でもいいと思うけどね
つかこれってSQL質問スレの話題じゃないのか
0121NAME IS NULL
垢版 |
2023/04/14(金) 16:41:46.31ID:???
なるほどDB設計関係なさそうなのにここに書いたのはSQL質問スレがないからだったのか
納得
0122NAME IS NULL
垢版 |
2023/04/17(月) 21:21:43.06ID:???
：2021/08/28(土) 22:08:57.33
0123NAME IS NULL
垢版 |
2023/05/21(日) 11:30:33.67ID:ikWPMqDN
会員ランクに関するテーブル設計で悩んでいます。
よくある「ブロンズ会員」「シルバー会員」「ゴールド会員」というのを実現したい場合、

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

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

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

最終的な要件によると思いますが、
会員ランクを設計したことがある人がいれば、考え方を教えてください。
0124NAME IS NULL
垢版 |
2023/05/21(日) 12:29:24.30ID:???
>また、会員への付与と会員になる条件を同じテーブルにしても良いのか？

そこ迷うならまずは別で考えるべきだね。
例として挙げられた条件はそれぞれランクに対する特典、加入条件、年会費とかになると思うけど
まずはそれぞれがなにを表すのか明確にしたうえでランクとの関係を検討する。
例えばランクに対する年会費が1つだけ必ず存在するなら同じテーブルに収めてしまってもいいかもしれないし、
特典が複数考えられるならそれは別テーブルにするしかない。
0125NAME IS NULL
垢版 |
2023/05/21(日) 13:53:34.63ID:???
>>124
ありがとうございます。
特典は用途が違うので別にした方が良さそうですね。
今のところ割引率しか考えていませんが、
ランク更新時にポイントの付与や、送料無料なども入れたいです。

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

考えがまとまりました。ありがとうございました。
0126NAME IS NULL
垢版 |
2023/05/21(日) 15:09:12.58ID:???
DB設計で難しいところは
「ビジネスルール・将来のための柔軟性」と
「アプリ・DB構造の複雑性」のトレードオフの判断

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

仮にランクになるための条件が増えたりした場合に
その要件が決まってからアプリだけでなくDBを改修したのでも十分だと判断したなら
別テーブルで行持ちにせずに同じテーブルで列持ちにしたのでもOK
0127NAME IS NULL
垢版 |
2023/05/21(日) 16:48:20.23ID:???
>>126
そこが難しいですね。
冷静に考えると、ビジネス要求を想定するなら
最小限の構成からスタートする方が良いと思います。
なぜなら、実際にスタートしてみないとわからないからです。

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

今私はテーブル設計の勉強をしているだけで、
ビジネス用途として考えてないので、色々と想定していますが。
0128NAME IS NULL
垢版 |
2023/05/22(月) 03:53:10.85ID:2W+4hjqK
>>123
ER図を書いてみれば、わかりにくさに気づくよ。
0129NAME IS NULL
垢版 |
2023/05/22(月) 09:53:15.09ID:???
会員ランクの用途が不明だけど、自分なら会員に会員ランクの情報を定義すると思う
（会員ランクから最新の情報を取得するにはコストがかかるため）
会員ランク自体は履歴参照程度に使うだけにするかね
この設計をふまえて
「ブロンズ会員なら購入金額から○％割引」
「シルバー会員になるには購入回数が○回以上」
「ゴールド会員の年会費は○円」
こちらは全てランクに項目を持つようにすれば結果的に拾いたい情報は会員とランクだけでOK
まあいろんな考えがあるから試行錯誤するといいかもね
0130NAME IS NULL
垢版 |
2023/05/22(月) 11:01:43.06ID:???
各会員の購入回数やらゴールド会員年会費納付年月日やら
0131NAME IS NULL
垢版 |
2023/05/22(月) 11:19:17.69ID:???
>>127
ベストな設計なんて世の中に存在しないから
ベターな設計で開発を始めたほうが良いのは至極当たり前のことなんだけど
何を持ってベターな設計と判断するかという判断基準を持ち合わせてないはどうしようもないよね
持ち合わせてたら>>123のような質問しないでしょ？

勉強用の架空の要件に対する設計であっても
考えうる選択肢を出してみてそれぞれどういうメリット・デメリットがあるのかを
自分なりに細かい要件を想定しながらしっかり考えないと設計能力はつかないよ
0132NAME IS NULL
垢版 |
2023/05/22(月) 11:20:12.26ID:???
>>130
そうそうこういう項目をどう管理するかのほうがDB設計的には重要だったりするよね
0133NAME IS NULL
垢版 |
2023/05/22(月) 12:17:34.06ID:???
試しに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
0134NAME IS NULL
垢版 |
2023/05/22(月) 13:31:32.85ID:???
言うほど>>124と一緒か？
>>129が言うように会員に会員ランクを定義するのとも違うし、
ベストとかベターの前に色々ありすぎて答えなんて出ないだろ
0135NAME IS NULL
垢版 |
2023/05/22(月) 14:10:47.79ID:???
>>134
>言うほど>>124と一緒か？
ほぼ一緒でしょ
Usersテーブルが>>123の会員テーブルで
UserMembershipが>>123の会員ランクテーブルに相当
特典、加入条件はランクテーブル(MembershipRanks)とは別テーブル管理にして
年会費だけランクテーブルに組み入れてる

といっても俺は124じゃないから124の意図した内容が俺の理解と違ってたら知らんけど
0136NAME IS NULL
垢版 |
2023/05/22(月) 14:12:37.98ID:???
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回数も減るし、サブクエリも必要ない。
0137NAME IS NULL
垢版 |
2023/05/22(月) 14:34:27.93ID:???
>>136
ビジネスルールや運用次第でそれで良い場合もあれば良くない場合もある
主にusers.rank_idをどのタイミングでどう更新するかという問題
お金を払うタイミングと会員ランクを変更するタイミングを常に一致させるようなルールならそれでも可
じゃなければシステム停止してバッチで更新みたいなことが必要になるから普通はDB設計を変える
0138NAME IS NULL
垢版 |
2023/05/22(月) 14:55:13.80ID:???
ポオントサイトだと夜間バッチが普通だと思う
購入額合計が基準値越えたからってランクがその場で上がった経験は無いな
0139NAME IS NULL
垢版 |
2023/05/22(月) 15:12:49.13ID:???
夜間バッチに、参照テーブルみたいなのを用意するのが普通だと思うが。
>>133だと常にUserMembershipを判定しなければいけないし、排他ロックもかかる。
>>136だとユーザー情報にランク情報を紐づけているわけだから、
同時に更新するタイミングはない。
お金を払うタイミングで現在のランクを参照できるわけだから、
お金を払ってる時にランクが変わるという問題もない
0140NAME IS NULL
垢版 |
2023/05/22(月) 15:22:45.15ID:???
>>138
それはバッチで更新されてるかのように見えてるだけでしょ
0141NAME IS NULL
垢版 |
2023/05/22(月) 15:24:47.54ID:???
>>137
たとえば販売管理なら月次のテーブルをもって特定月の売上金額や入金額なんかを持つことがある
ランク付けが月毎に確定するような話なら上の例と同じように特定月のランクがどうなるかを持つような話じゃないかと思う
なので実際のテーブル設計は要件をふまえてするわけだし
ここはそういうスレだから「じゃあこんな場合はどうだろう」とかいろいろ話を膨らませてもいいと思うけど
攻撃的なやりとりはできる限りないほうがいいんじゃないかねぇ
0142NAME IS NULL
垢版 |
2023/05/22(月) 16:09:37.41ID:???
>>141
>ランク付けが月毎に確定するような話なら
ランク付けが基本的に年単位で確定するような話をしてるんだから同じでしょ
0143NAME IS NULL
垢版 |
2023/05/22(月) 16:16:29.57ID:???
>>139
>>>133だと常にUserMembershipを判定しなければいけないし、排他ロックもかかる。
排他ロック？はよくわからないけど必要なロックがかかったところで何か問題がある？

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

バッチ更新の場合でも締めと反映のタイミングをデータでコントロールできるようにするほうが一般的
特にお金のやり取りが絡むランクのアップダウンの場合は
0144NAME IS NULL
垢版 |
2023/05/22(月) 16:24:11.52ID:???
ネットショップで夜更けから
0145NAME IS NULL
垢版 |
2023/05/22(月) 16:25:08.17ID:???
すまん
明け方に３０分程度サービス停止するサイトは結構あるでしょう
0146NAME IS NULL
垢版 |
2023/05/22(月) 16:25:56.89ID:???
>>143
サービス止める＝排他ロックのこと言ってると思ったが、どうやら違うようだな

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

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

だから、15時前後でサービスが止まることもなければ、
会員の現在のランクが正確に取得できないこともない
0147NAME IS NULL
垢版 |
2023/05/22(月) 16:27:45.67ID:???
普通は使ってに時間帯にバックアップとか保守作業やってます
0148NAME IS NULL
垢版 |
2023/05/22(月) 16:28:53.86ID:???
>>145
アフィリエイトのA8も毎月1日の16時まではデータ更新時間としている
だから、会員ランクの判定に時間を要すのは特別おかしくはない
0149NAME IS NULL
垢版 |
2023/05/22(月) 18:48:17.95ID:???
>>142
俺の書き方が悪かったと思ってるけど、一定期間ののちランクがきまるならその期間中のランクデータを作るよねって話をしたかっただけさ
販売って自分は買いたからこの場合は大抵月次で締めて請求書出したりするからそう書いただけね
0151NAME IS NULL
垢版 |
2023/05/22(月) 20:53:51.42ID:???
>>136
細かいことだけど users.rank_id と user_ranks.rank_id が同じ意味ならどちらか削るべきだな。
users と user_ranks を分ける意味もないかも。
0152NAME IS NULL
垢版 |
2023/05/22(月) 21:18:50.05ID:???
>>151
削ったらリレーションできないぞ
0153NAME IS NULL
垢版 |
2023/05/22(月) 21:46:06.35ID:???
users.id と　user_ranks.id があるんだから問題ない。
逆に両方あると更新時異常の危険がある。

余談だけど「リレーション」の使い方がおかしいのはちゃんと学んだことがない証拠。
0154NAME IS NULL
垢版 |
2023/05/22(月) 23:14:44.67ID:???
リレーショナルデータベースでリレーション使ったら駄目なのか・・・
0155NAME IS NULL
垢版 |
2023/05/22(月) 23:21:53.10ID:???
おかしな使い方はな。
0156NAME IS NULL
垢版 |
2023/05/23(火) 10:39:48.93ID:???
>>146
>更新の準備はバックグラウンドでやってて、15時に公開（適用開始）という流れだろう。
>15時前には当然バッチ処理を行い、会員ランクの判定は終えているはずだ
そういうよくある仕組みをサービス停止せずに実現するためには
15時まで有効なデータと15時以降に有効なデータを1ユーザーあたり最低2件を同時に持ってないと無理
それが>>133と>>136の違い
0157NAME IS NULL
垢版 |
2023/05/23(火) 10:41:39.15ID:???
>>154
リレーションとリレーションシップは違うぞ
0158NAME IS NULL
垢版 |
2023/05/23(火) 10:49:19.20ID:???
>>148
アフィリエイトよく知らないけど
新しい会員ランクがリアルタイムで取得できなくても困らないからじゃないの？
毎月1日の0~15時にあった流入についても次の締め処理時に新しいランクのトランザクションとして扱えばいい
送料無料にするかどうかのように各トランザクションで最新の会員ランクが必須になるような処理とは若干種類が違う
0159NAME IS NULL
垢版 |
2023/05/23(火) 11:42:12.72ID:???
Bardさんに聞いたらこのように言われた。

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

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

もちろん、ユーザーテーブルに会員ランクを保持する場合は、会員ランクテーブルにデータを挿入したり更新したりするたびに、ユーザーテーブルのランクも更新する必要があります。これはトリガーなどを利用して自動化できます。
0160NAME IS NULL
垢版 |
2023/05/23(火) 11:59:00.73ID:???
あたりまえの事を言われるけどそれが普通じゃないかね
ランクの確定が不定期なら最新のランクを取り出す条件があいまいになるから特定ユーザーの最新ランクをとるのにコストがかかる
月次や年次であれば2023年5月のランクといった指定で最新のランクが取り出せるからコストは少ない
0161NAME IS NULL
垢版 |
2023/05/23(火) 15:02:02.72ID:???
特定の1ユーザーのランクを取得する話と
ユーザーの全数を対象にしたようなレポーティングの話を同列に語ってない？
前者のクエリコストなんて微々たるものだよ

お金を支払えばその時点から即ランクアップするようなビジネスルールなら
>>136のような構造でも問題ないんだけどね
0162NAME IS NULL
垢版 |
2023/05/23(火) 16:06:00.81ID:???
DBの設計次第でビジネスのその後が変わると言っても過言じゃないのに、
あまりにもネット上に情報が少ないよな
今回の会員ランクの話題だって、ググってもピッタリなの出てこないぞ
0163NAME IS NULL
垢版 |
2023/05/23(火) 16:49:25.79ID:???
普通はその情報で商売するし
0164NAME IS NULL
垢版 |
2023/05/23(火) 18:29:07.47ID:???
ピッタリも何も要件としてのランク確定のタイミングがわかれば似たような事例なんていくらでも出てくるでしょ
0165NAME IS NULL
垢版 |
2023/05/23(火) 18:40:08.05ID:???
さてどこから見ようかしら、ネットは広大だわ
0166NAME IS NULL
垢版 |
2023/05/23(火) 18:50:19.97ID:???
>>164
出してくれよ。>>136ですら出してるの見つからないぞ
0167NAME IS NULL
垢版 |
2023/05/23(火) 19:39:26.70ID:???
>>162
ふつうはビジネス要件が先でそれに合わせてDB設計するだろ。
設計だけ持ってきてどうするよ。
0168NAME IS NULL
垢版 |
2023/05/23(火) 19:46:19.50ID:???
>>167
夢みたいなビジネス要件持ち出して失望される人？
0169NAME IS NULL
垢版 |
2023/05/23(火) 19:49:39.42ID:???
ではビジネス要件書いてください、すぐにしばってご覧にいれます
0170NAME IS NULL
垢版 |
2023/05/23(火) 20:06:29.95ID:???
>>168
それって、あんたが要件をまとめたら夢物語になってしまうってこと？
0172NAME IS NULL
垢版 |
2023/05/23(火) 23:18:08.17ID:???
設計の前に要件定義しなきゃならんて話しただけで>>168みたいな反応するのはそういうことなんだろう
0173NAME IS NULL
垢版 |
2023/05/23(火) 23:56:35.45ID:???
現実にはハイレベルのDB設計は要件定義とは切り離せない
0174NAME IS NULL
垢版 |
2023/05/23(火) 23:59:58.68ID:???
そもそも>>167が読み違えてる
ビジネス要件決めないと設計できないなら
ER図公開している人らは、何を持って公開してるのかと
「こういうときはこういう設計」という情報を発信したくて公開してるんだろうに
1から10まで決められないと考察すらできないのは無能の証だぞ
0175NAME IS NULL
垢版 |
2023/05/24(水) 07:25:16.52ID:???
それで>>174みたいな人はユーザーの要望とは違うものでも「これはこういうものなんです（キリッ」
とかいってユーザーともめるようなシステム提供するんですね
わかりますｗ
そもそも公開してる情報なんて実際に動いてるものでもなんでもなく
自分で要件をイメージして作ってるだけでしょ
それを持ち出してきて勝手に相手を無能扱いするほうが怖いわ
0176NAME IS NULL
垢版 |
2023/05/24(水) 08:52:55.10ID:???
イメージの話ししてるのに仕事の話ししてるのお前だろ
0177NAME IS NULL
垢版 |
2023/05/24(水) 09:56:45.71ID:???
仕事の想定もイメージだろ？何勝手に決めてるわけ
もともとはふわっとした質問なんだからDB設計なんて回答する人の経験度合でいくらでも膨らむ話でやり取りすればいいのに
関係ない話持ち出して無能だなんだ決め打ちするやつの方がよっぽどあたおかでしょ
0178NAME IS NULL
垢版 |
2023/05/24(水) 11:21:54.32ID:???
第三者から見れば君たちすごく似た者同士だよ
言ってることもほとんど同じ
仲良くね
0179NAME IS NULL
垢版 |
2023/05/24(水) 11:25:01.66ID:???
仕事募集しているなら、そういう板に移動してやって
0180NAME IS NULL
垢版 |
2023/05/24(水) 12:08:21.72ID:???
なんで急に仕事募集の話になるのかｗ
0181NAME IS NULL
垢版 |
2023/05/25(木) 01:21:23.01ID:CAQoWwdr
アクセンチュアとIBMの高給取りが、概念データモデルの意味がわかってなくて、概念データモデルと論理データモデルと物理データモデルのすべてが最終的な成果物と言っているくらいだからなw
0182NAME IS NULL
垢版 |
2023/05/25(木) 11:00:45.26ID:???
逆に言えばそれら理解できなくても問題ないってことだな
0183NAME IS NULL
垢版 |
2023/05/25(木) 11:35:25.95ID:???
>>174
「ビスネス」要件かどうかはともかく
こういうときはこういう設計、の、「こういうとき」がまさに要件だぞ
要件の不明な設計なんて、何の意味もないけど？

まあ往々にして、要件が不明で設計から読み解くことはあるがな
0184NAME IS NULL
垢版 |
2023/05/25(木) 11:38:42.31ID:???
今回の質問者は「こういうとき」については触れてません
皆さん好きに弄ってください、みたいな
0185NAME IS NULL
垢版 |
2023/05/25(木) 12:54:43.86ID:???
>>181
RDBMSへの実装を目的とした論理データモデルや物理データモデルとは違って
概念モデルは組織やプロジェクトや用途によってどういうものを作るかかなり違ってくる

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

自分の考える「正解」に凝り固まらずもう少し視野を広げてみては？
0186NAME IS NULL
垢版 |
2023/05/25(木) 13:26:11.97ID:???
>>184
普通に「こういうことしたい」に対して「こうすれば？」の意見は数多く出てるぞ
なぜか後半になってビジネス要件とか言い出してるやつがいるけど
0187NAME IS NULL
垢版 |
2023/05/25(木) 14:54:15.70ID:???
>>183
>こういうときはこういう設計、の、「こういうとき」がまさに要件だぞ
「こういうとき」が要件の場合もあればそうでない場合もあるよ
設計選択に影響を及ぼす条件や状況がすべて要件というわけではないからね

それに実践ではDB設計プロセスを通して初めて表面化する要件があるほうが普通だから
ある程度曖昧な条件からでもたたき台となる設計案を提示できる能力ってのはすごく重要
0188NAME IS NULL
垢版 |
2023/05/25(木) 15:59:02.34ID:???
>>187
こういう人が上流工程担当してると満足なもの作れなくて後続の工程担当者に陰で無能扱いされる典型だわな
最後まで荒れるプロジェクトになる典型的な人材ｗ
0189NAME IS NULL
垢版 |
2023/05/25(木) 16:05:13.47ID:???
>>187
こういうときはこういう設計の、こういう時が要件じゃない例を挙げてみてくれ
要件定義を理解してなさそうな人に言うほど一般的なケースだとは思えん
0190NAME IS NULL
垢版 |
2023/05/25(木) 19:33:12.34ID:???
実際にDB設計したことないでしょ
してたらこんな発言するわけない
指示されたことしかできないPGでしょ
0191NAME IS NULL
垢版 |
2023/05/25(木) 19:39:56.33ID:???
指示された通りに作れるPGは優秀
0192NAME IS NULL
垢版 |
2023/05/26(金) 02:18:22.09ID:egPJEgSO
>>185
概念データモデルは、論理データモデル、物理データモデルと違うデータモデルだから、これを残すと整合性が取れていない、ドキュメントとしても意味がないものになる。

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

設計途中のものを残されても、データモデリングというものがわからない日本人には、論理データモデルだと誤解してしまう。
0193NAME IS NULL
垢版 |
2023/05/26(金) 08:54:55.30ID:???
正しい方法が一つだけと決まっているわけではないと思うが意味が分からんなぁ。
概念モデルを残すと整合性が取れないって、その整合性が取れないモデルを基に
論理モデルを作ったということかな？
0194NAME IS NULL
垢版 |
2023/05/26(金) 09:54:54.36ID:???
普通に設計できる人が概念データモデルとそれ以外のデータモデルを間違えるなんてありえないんだが
それをするような人はそもそもわかってないだけでしょ
別に日本人だからとか関係なくね
0195NAME IS NULL
垢版 |
2023/05/26(金) 20:56:27.16ID:lIsQEkEz
概念データモデルは設計時の過程で作るもので、なぜか概念データモデルと論理データモデルと物理データモデルは最終的にすべて同じなると思っている自称専門家がいる。
0196NAME IS NULL
垢版 |
2023/05/26(金) 21:36:07.63ID:???
なぜか概念データモデルと論理データモデルと物理データモデルは最終的にすべて同じなると思っている人がいると思ってる人がいる。
0197NAME IS NULL
垢版 |
2023/05/26(金) 21:41:44.47ID:???
異端な主張をするのは自由だけど論拠が無さ過ぎるからそりゃ誰にも相手にされんわ
自称専門家氏が自称専門家呼ばわりしてる人達のほうが常識があるのが手にとるようにわかる
0198NAME IS NULL
垢版 |
2023/05/26(金) 22:09:28.63ID:???
要件定義しなくても設計できるとほざいてた人と同一人物かねえ？
0200NAME IS NULL
垢版 |
2023/05/26(金) 23:26:24.12ID:???
同じってどういう意味で同じっていってるのかしらんが
少なくとも最終的にその三つが整合性がとれないとか、その設計は破綻しとるわ
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況