X
DB設計を語るスレ 11
0002NAME IS NULL
垢版 |
2021/08/28(土) 22:10:23.69ID:P8TnL8ql
SQL楽しい。
0003NAME IS NULL
垢版 |
2021/08/28(土) 22:10:54.49ID:P8TnL8ql
10月10日の試験、合格できるだろうか。。
0004NAME IS NULL
垢版 |
2021/08/28(土) 22:11:22.77ID:P8TnL8ql
4年ぶりの新スレ。
0005NAME IS NULL
垢版 |
2021/08/28(土) 22:11:39.15ID:P8TnL8ql
どこまで保守すれば良いかわからぬ
0006NAME IS NULL
垢版 |
2021/08/28(土) 22:11:55.37ID:P8TnL8ql
誰か教えてくれ
0007NAME IS NULL
垢版 |
2021/08/28(土) 22:13:12.80ID:P8TnL8ql
ミックの本読んで勉強中
0008NAME IS NULL
垢版 |
2021/08/28(土) 22:14:23.02ID:P8TnL8ql
一応、10までやるわ
0009NAME IS NULL
垢版 |
2021/08/28(土) 22:16:09.82ID:P8TnL8ql
having句と自己結合使ってメジアン求める式が難解
0010NAME IS NULL
垢版 |
2021/08/28(土) 22:16:28.93ID:P8TnL8ql
辛いのう
0012NAME IS NULL
垢版 |
2021/08/28(土) 22:36:16.29ID:???
保守とかもうやらなくてもよくなったんじゃ？
0013NAME IS NULL
垢版 |
2021/08/29(日) 00:57:57.90ID:???
保守要らんのか。。
0014NAME IS NULL
垢版 |
2021/08/29(日) 01:04:47.43ID:vESMB477
データベース板は十数年前のスレッドが生きているくらいだからな。

ギャンブル系の板はすぐにスレッドが消える。
0015NAME IS NULL
垢版 |
2021/08/29(日) 01:06:18.37ID:vESMB477
いまちょっとだけ確認したら、18年前に立てられた過疎スレがあった。
0016NAME IS NULL
垢版 |
2021/08/29(日) 02:48:49.84ID:???
本当だ、2003か。俺が大学2年の時だわ。時が経つのは早いなぁ
0018NAME IS NULL
垢版 |
2021/08/29(日) 11:39:07.46ID:ns1fXrgZ
スレのライフタイムが1559日とか感慨深いわ。部署異動したばかりの頃だったな。あの時は若かった
0019NAME IS NULL
垢版 |
2021/08/29(日) 11:40:31.12ID:ns1fXrgZ
>>17
20年前とか、別人だよな。いまや、太って髪が薄くなったオッサン。
0020NAME IS NULL
垢版 |
2021/08/30(月) 22:17:32.42ID:umkyPM8I
過疎過ぎだな。
0021NAME IS NULL
垢版 |
2021/08/30(月) 22:18:31.51ID:umkyPM8I
データベーススペシャリスト試験前なので、先輩方有益な知識くらさい。。
0022NAME IS NULL
垢版 |
2021/08/30(月) 22:24:36.12ID:KytOSBee
>>21
デブ女を抱くと合格します。
0023選挙に行こう
垢版 |
2021/09/04(土) 00:48:23.35ID:???
ソ連の核は綺麗な核
ポル・ポトはアジア的優しさ
北朝鮮は地上の楽園
珊瑚自作自演事件
南京・慰安婦捏造
教科書書き換え「誤報」事件
朝日・武富士裏献金事件
拉致問題切り捨て
サイレント魔女リティ
風の息遣い
五味ボマー
変態新聞
村木局長犯人扱い
その他人民裁判ならぬマスコミ裁判は数知れず
そしてマスコミお得意の「報道しない自由」

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

よく考えて下さい
0024NAME IS NULL
垢版 |
2021/09/04(土) 01:43:35.61ID:???
サンケイ記者って朝日に採用されなかった奴がなるって本当？
0025NAME IS NULL
垢版 |
2021/09/04(土) 02:24:29.84ID:3tayR9G7
>>24
三流新聞だからね。フジサンケイグループはネトウヨから左翼だと攻撃されて、ネトウヨ寄りになったヘタレ。
0026NAME IS NULL
垢版 |
2021/09/04(土) 12:47:40.08ID:???
親会社はフジテレビ
0027NAME IS NULL
垢版 |
2021/09/12(日) 18:36:04.79ID:xQ4OhZ56
スペシャリスト試験1ヶ月切って胃が上がってきたっす( ´Д`)y━･~~
0028NAME IS NULL
垢版 |
2021/09/23(木) 05:13:50.03ID:uj7rDnPQ
あと18日。午後2は何とか仕上げられるかな
0029NAME IS NULL
垢版 |
2021/09/23(木) 20:20:47.04ID:KxDKEqBY
疲れた。試験受からぬかもしれぬ(´･ω･`)
0032NAME IS NULL
垢版 |
2021/10/18(月) 10:23:59.29ID:???
そっか、次がんばれ。
0033NAME IS NULL
垢版 |
2021/12/10(金) 09:54:04.29ID:h7CMVbmD
ブログとか文章を書いていると自動的に下書きされる仕組みがあれます。
あれって、同じテーブルに下書き用のフラグをつけてるのでしょうか？
それとも下書き用のテーブルを用意しているのでしょうか？
0034NAME IS NULL
垢版 |
2021/12/10(金) 11:10:10.21ID:???
それはWebシステム側の仕組みだから
DBはそれに応じて対応する
0035NAME IS NULL
垢版 |
2021/12/10(金) 15:27:30.67ID:h7CMVbmD
>>34
Webシステム側の仕組みとしても、下書き用のデータを保存する必要がありますよね？
その保存に関するDB設計を訪ねているのですが・・・
0036NAME IS NULL
垢版 |
2021/12/10(金) 15:30:14.07ID:???
>>33
下書き用テーブルに何か意味があるなら使ってみたら
0037NAME IS NULL
垢版 |
2021/12/10(金) 15:44:42.40ID:0njbUPaS
そんなん設計方針によるだろ
お行儀よくいくならテーブル分けたほうがいいけど、実態としては同じテーブルのことが多いんじゃない
published_at的なカラムがnot null &過去なら後悔っていうロジックにするんじゃね
0038NAME IS NULL
垢版 |
2021/12/10(金) 15:45:36.70ID:???
ブログの更新をどのような手順で行うのか
下書きの保持期間はどのくらいなのか
そのセッションで破棄するのか、数日間保持するのか
公開ページは､公開後に更新しないのか
更新や修正の履歴は残すのか
など、色々あるから
0039NAME IS NULL
垢版 |
2021/12/10(金) 16:51:08.87ID:???
WordPressは同一テーブルに保存する
だから無駄なレコードが増えまくる
0040NAME IS NULL
垢版 |
2021/12/10(金) 17:26:21.34ID:???
公開済み記事を中途半端に編集して一旦下書き保存とか
バージョン管理が必要なら別テーブルのほうがスッキリする

編集中の新バージョンの記事から旧バージョンの記事へのリンクをもたせて
バージョン管理することもできなくはないが諸々の処理が非効率になる
0041NAME IS NULL
垢版 |
2021/12/11(土) 11:03:18.19ID:???
システム側の問題だけど、自動保存は後始末が気になるな
どうしても余計なログが溜まっていくわけだし
cronなんかでわざわざ期限指定削除するのもあれだし
0042NAME IS NULL
垢版 |
2021/12/11(土) 14:32:09.42ID:???
後始末も要件次第
いろいろやり方はある

>>38が書いてるのと同じことだけど
DB設計はきちんと要件を決めることからやらないと
0043NAME IS NULL
垢版 |
2021/12/11(土) 18:22:10.80ID:???
要件次第っていい出したら議論の放棄にしか見えんな

「俺はAだ。だけどBもある。その他いろいろ」
って見解ならわからんでもないが
0044NAME IS NULL
垢版 |
2021/12/11(土) 18:39:12.30ID:???
「フラグをつける場合もあるし、下書き用のテーブルを用意する場合もある」

こう回答すると質問者の意に適うんだろうか
それなら聞かなくても良かったにならないか？
0045NAME IS NULL
垢版 |
2021/12/11(土) 19:19:59.77ID:???
それって単に相手の言葉を引用してるだけじゃん
それなら答えなくても良かったにならないか？
0046NAME IS NULL
垢版 |
2021/12/11(土) 19:23:13.31ID:Q+pUaU76
データモデルを本当のプロに任せないプロジェクトが多すぎるんだよなあ。
0047NAME IS NULL
垢版 |
2021/12/11(土) 19:25:42.35ID:???
「牛丼食べたいがどうしたらいい？」
って質問してるやつに、予算や場所や味の好みを聞くようなもんだな

普通に吉野家、松屋、自分で作る、コンビニで買う、冷凍食品を使う
など、それぞれが思うことを言えばいいだけなのに
0048NAME IS NULL
垢版 |
2021/12/11(土) 20:08:28.64ID:???
>>45
与えられた条件だとそういう回答しか返せないって事だろ
それぐらい理解しなよ

>>47
そういう奴に吉野家って言うと味がどうのとか言い出すから
0049NAME IS NULL
垢版 |
2021/12/11(土) 22:18:44.16ID:???
>>43
要件次第ってのは往々にして「もうちょっと考えろや」の婉曲表現なんだよ
どういう点を考えなきゃいけないかもわからないようならそれを質問しろ

流れを見る限りかなり親切なほうだと思うぞ
0050NAME IS NULL
垢版 |
2021/12/11(土) 22:40:49.50ID:???
>「牛丼食べたいがどうしたらいい？」
>って質問してるやつに、予算や場所や味の好みを聞くようなもんだな

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

牛丼食べたいなら食べればいいじゃん
なんでそんなことわざわざ聞くの？
どうしたらいいかなんでわからないの？
0051NAME IS NULL
垢版 |
2021/12/12(日) 00:05:34.74ID:???
そこを聞くのがSIerだろう
0052NAME IS NULL
垢版 |
2021/12/12(日) 01:35:28.32ID:???
要件を明確にしないやつにろくなやつがいないから防御本能が働くのかもな
0053NAME IS NULL
垢版 |
2021/12/12(日) 23:47:20.93ID:???
ここで回答してるのはSIerが業務でやってるわけじゃない
質問者は客じゃない

まともな回答がほしいなら要件は質問者がまとめて提示すべきで、要件次第って言われてるってことは
それだけじゃ答えようがないからもうちょっと詳しく条件書けってことだ
0054NAME IS NULL
垢版 |
2022/01/08(土) 12:19:00.62ID:hBrjjHmk
お前ら和歌山県出身の下村拓郎様（35歳、元自衛隊）をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ
0055NAME IS NULL
垢版 |
2022/01/08(土) 20:30:13.82ID:l94tCt7+
ｎ；ｎのデータベースを作りたいです。
具体的にはパソコン部品と症状です。
簡単なケースとして
　フリーズする→CPU
　再起動する→CPU
みたいなデータです。
該当パーツを選ぶと関係する症状が出てくる。症状を選ぶと該当するパーツが出てくるという感じです
出来ればwebサイトにて構築したいのです。
難しければEXCELで。
ACCESSだとライセンスの問題が出てきてしまうのでACCESSは最後の最後の手段で
こんなサイトで作れるよとか
こんなソフトあるよ等アドバイスいただければ幸いです。
よろしくお願いしますm(__)m
0056NAME IS NULL
垢版 |
2022/01/09(日) 05:39:32.50ID:2+VaCmDS
>>55
Excelでパソコン部品と対応する症状の列を作って、存在する全ての組み合わせ入れてからフィルターかければいいんじゃね？

使う場所や目的がわからないけどさ
0057NAME IS NULL
垢版 |
2022/01/09(日) 11:21:16.40ID:???
>>55
データベースならどんなやつでも作れるよ
設計スレなので設計の話をするとパーツ、症状、パーツと症状の組み合わせ、の3つのテーブルを作ればいいだけ

ちなみに「フリーズする」とか「再起動する」症状の原因はドライバだったり
アプリケーションだったりパーツとは関係ないことが大半
なので手間かけてWebサイト作るよりもまずはExcelでまとめたほうがよさそう
0058NAME IS NULL
垢版 |
2022/01/09(日) 11:26:01.77ID:???
何か部品と症状をタブ区切りにしてgrepやawk使って出来そうな気がする
0059NAME IS NULL
垢版 |
2022/01/09(日) 22:53:18.78ID:EooB3qgr
>>56-58
ありがとうございます。
一番手軽なのは56番さんのやり方ですね
57番さんの言う通りソフト要因は当然ありますね
56＆57番さん
手軽にアプリケーション不要で誰でもどこからでも参照、検索出来るようにしたいと思い
webアプリケーション？web上に構築したくて質問させていただきました。
とりあえずEXCELでデータ入力してどこかに構築出来そうなアテが出来たら移行してみたいと思います。
ありがとうございましたm(__)m
0060NAME IS NULL
垢版 |
2022/02/18(金) 23:12:05.70ID:bnx9nLc6
プロフィールなどの設計で画像カラムが必要な場合、
1つの画像ならプロフィールテーブルに1つあれば十分ですが、
複数画像なら別テーブルにしますよね？
その際、「一覧に表示する画像（サムネイル）」はどうやって決めるのでしょうか？
画像テーブルにフラグでもつけるのでしょうか？
0061NAME IS NULL
垢版 |
2022/02/18(金) 23:17:35.30ID:???
DB設計として

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

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

みたいな感じで絞り込めば良さそうな気はしますが
0062NAME IS NULL
垢版 |
2022/02/19(土) 02:04:25.88ID:???
とりあえずはそれでもいいのかもしれないが実際設計するなら
プロフィールと画像の関係/ビジネスルール、画像データの使い方(CRUD)、データ件数、要求性能なんかをまず明らかにしてから考える

例えば
プロフィール1個につき必ず1つサムネイル用の画像が必要か？
一覧に表示する画像はプロフィール1個につき1つだけか？
0063NAME IS NULL
垢版 |
2022/02/19(土) 08:06:38.62ID:???
>>62
なるほど。要件が増えるにつれてテーブル設計も変わってくるわけですね。
ただ、画像テーブルをわけることである程度は対応できそうです。
>>61の設計ならサムネイル用の画像が複数になっても
「サムネイル」というカラムにチェックが入ればいい形にできるし、
一覧に表示する画像が増えても同様かと。

画像ってつい1つのテーブルにまとめがちですが、
「画像01、画像02・・・」みたいなカラムで対応しているアプリも多いので、
もっと深く要件を追求して考えなければけませんね
0064NAME IS NULL
垢版 |
2022/02/19(土) 13:07:07.13ID:???
>なるほど。要件が増えるにつれてテーブル設計も変わってくるわけですね。
要件が増えたわけではなく>>62に書いてるのは最初の設計段階で明らかにしておくべきこと

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

性能目的で1テーブルに非正規化する場合が全くないわけではないがかなり特殊なケース
そういう場合でも普通は正規化した構造を先に考える
0065NAME IS NULL
垢版 |
2022/02/19(土) 13:51:18.95ID:???
>>60
> その際、「一覧に表示する画像（サムネイル）」はどうやって決めるのでしょうか？
それを決めるのが要件定義

> 画像テーブルにフラグでもつけるのでしょうか？
それは実装だから要件が決まったらまたおいで
0066NAME IS NULL
垢版 |
2022/02/23(水) 14:56:20.38ID:???
要件によっていろんな形の設計がありうるから
こういうのはDB設計力を高めるには結構いいお題
0068NAME IS NULL
垢版 |
2022/03/02(水) 00:21:11.73ID:???
ＨｅｉｄｉＳＱＬの作者があっさりMaterializedView非対応だとのべて逃げてしまった
５年前
そんなばかな

ひょっとしてMaterializedViewってアンチパターンなのか？
0069NAME IS NULL
垢版 |
2022/03/17(木) 06:57:42.06ID:???
恥ずかしい話なんだが20年くらいPGやっててDB設計やSQLが苦手でいつもできるやつにまかせてたんだけどやっぱ一から勉強しないとダメだなって思ってるんだけど最低限これできれば恥かかないよってのあったら色々おせーてください
0070NAME IS NULL
垢版 |
2022/03/17(木) 17:04:05.20ID:???
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になってからはじめればいい
0071NAME IS NULL
垢版 |
2022/03/17(木) 18:18:52.56ID:???
20年PGやってれば、自分でみてよい設計か悪い設計か判断つくだろうに

>>70
つか歴20年でさすがにレベル1もクリアしてなければ恥ずかしいとかいうレベルじゃないぞｗ
0072NAME IS NULL
垢版 |
2022/03/17(木) 18:24:00.02ID:???
＞いつもできるやつにまかせてた

相当えらい人なんではないかな？
0073NAME IS NULL
垢版 |
2022/03/17(木) 19:43:06.27ID:???
てか、そのできる奴とやらにどういう処理なのか聞けば良くね？
0074NAME IS NULL
垢版 |
2022/03/17(木) 21:16:26.49ID:???
>>71
SQLが苦手という人はだいたいレベル1が満足にできないもんよ
ちなみにSQLが得意とアピールする人も大半はレベル1の人なので要注意

プログラマー歴10年以上でも実行プランはコストだけ見る人とか
インデックス使ってそうかどうかくらいしか分からない人のほうが多い
その辺を見るのにベンダー資格はある程度役に立つ
0075NAME IS NULL
垢版 |
2022/03/18(金) 10:35:46.15ID:???
得意なんて言葉使ってる人はこれに限らず普通のレベルでしょ（人並程度ですとかわらん）
0076NAME IS NULL
垢版 |
2022/03/18(金) 11:57:45.97ID:???
>>75
君は日本語能力が普通のレベルに達してないね
0077NAME IS NULL
垢版 |
2022/03/20(日) 15:03:20.97ID:???
調べれば調べるほどわからんことが出てきていつになっても得意なんて言えない
0078NAME IS NULL
垢版 |
2022/03/21(月) 00:06:16.03ID:???
「あなたの得意な技術は何ですか？」
「調べれば調べるほどわからんことが出てきていつになっても得意なんて言えないです」
「。。。。。(ハイ、不採用っと)」
0079NAME IS NULL
垢版 |
2022/03/21(月) 03:13:56.04ID:???
流石にそんな馬鹿正直には言わんよw
0080NAME IS NULL
垢版 |
2022/03/22(火) 01:33:40.94ID:3HuGVN9a
>>78
面接官は阿呆だから、個人差を軽視するんだよなあ。

なぜか特定のことしかできない人間をその道のプロだと思い込んでしまう。
0081NAME IS NULL
垢版 |
2022/03/22(火) 02:07:42.35ID:???
君が阿呆な面接官しか見たことないのはなぜか考えようねw
0082NAME IS NULL
垢版 |
2022/03/22(火) 11:16:01.61ID:???
良い質問だ、今度面接に来た奴に出してみる
0083NAME IS NULL
垢版 |
2022/09/08(木) 13:38:01.86ID:/QbvZDF4
Yは4
0084NAME IS NULL
垢版 |
2022/09/10(土) 10:00:03.75ID:6PvLNR0d
面接官が理解できる範疇で答えないとダメなのは確かなこと。
0085NAME IS NULL
垢版 |
2023/03/23(木) 12:43:47.04ID:???
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
0086NAME IS NULL
垢版 |
2023/03/23(木) 21:46:48.18ID:???
よくｗからないならとりあえず第三正規形にしとけ、というのはよく言われる話。
とはいえ正しく正規化をするにはそれなりの知識は必要だな。
>>85を見る限り正規化とは関係ないテーブル分割も混じっているし。
0087NAME IS NULL
垢版 |
2023/03/24(金) 16:22:52.88ID:???
>>85
商品詳細テーブルの型番がユニークでIDと型番が1対1であれば
一応は第三正規形とみなせるので正規化の練習問題なら概ねいいと思う
実戦なら検索と更新の方法や扱う商品の種類など様々な状況に依存するから単純な正解はない
0088NAME IS NULL
垢版 |
2023/03/24(金) 16:24:28.93ID:???
ECサイトで商品管理の一番中心となる商品マスタは「商品詳細テーブル」にあたるもので
このテーブルで自社が管理する商品番号から特定の商品を一意に特定できるようにする

でも「商品詳細テーブル」という命名とカラムの並べ方からそういう認識ではなさそうに見えたのが少し気になったところ
0089NAME IS NULL
垢版 |
2023/03/24(金) 16:43:27.62ID:???
商品詳細テーブルが何か違うと思う
idはともあれ、商品IDが1固定というのは変
0090NAME IS NULL
垢版 |
2023/03/24(金) 18:35:45.73ID:???
>>85
商品詳細テーブルに書いてる例が全部iPhone14 Pro Maxだから1
0091NAME IS NULL
垢版 |
2023/03/24(金) 19:33:46.97ID:???
>>85
キーや関数従属性の正確なところがわからないと確実ではないが
たぶん分割前のproductsテーブルのままでも第三正規形。
その分割自体は正規化とは直接関係ない。
0092NAME IS NULL
垢版 |
2023/03/24(金) 23:09:43.98ID:???
確かに言われてみれば最初のテーブルが全カラムをカバーできてるということなら第三正規形と言えそうだね

現実には機種や色は書いてる以外の属性が入ってくるだろうから第三正規形でも分割が必要かもしれないのと
色や容量は機種によって取りうる組み合わせに制約があるから第五正規形までを考えるとその組み合わせが表現できるテーブルを作ることになる
0093NAME IS NULL
垢版 |
2023/03/24(金) 23:25:50.90ID:???
>現実には機種や色は書いてる以外の属性が入ってくるだろうから第三正規形でも分割が必要かもしれないのと

そういうのを正規化で分割し終わった結果があのテーブルかもよ
0094NAME IS NULL
垢版 |
2023/03/25(土) 01:17:58.97ID:???
>>93
Deep PurpleとかをFKの値として使ってるってこと？
それは試験問題でしかありえなくない？
0095NAME IS NULL
垢版 |
2023/03/25(土) 09:32:28.88ID:???
>>94
色に従属する他の属性があるなら別テーブルにするだろうし必要に応じてFKを設定することもあるだろう。
文字列のキーが現実的じゃないってことかな？どちらにしても正規化とは別の話だと思うが。
0096NAME IS NULL
垢版 |
2023/03/27(月) 05:13:43.88ID:heX8rl2o
基本的な SQL 文法をある程度理解して、小さいアプリを作ってるレベルなんですが、
そこそこ大規模な DB も設計してみたいのです。
設計の参考にしたいので、テーブル設計を公開している Web サービスがあれば教えて頂けないでしょうか？
0097NAME IS NULL
垢版 |
2023/03/27(月) 11:10:45.81ID:???
StackOverflowとかWebサービスではないけどRedmineとかは参考になると思う
和製ならEC-CUBEとかもDBスキーマ見れる
ただしかなり微妙
0098NAME IS NULL
垢版 |
2023/03/28(火) 06:46:47.78ID:jxesX9VZ
>>96
古本でいろんなものが安く手に入る。
出版はかなり前のものだが、いまだに売れ続けている。

ネットよりももっと専門家が書いている一般書籍の方が信頼できる。
0099NAME IS NULL
垢版 |
2023/03/28(火) 10:34:51.77ID:???
>>97
>和製ならEC-CUBEとかもDBスキーマ見れる
EC-CUBEを見ればこの程度でもいいのかという自信がつくw
0100NAME IS NULL
垢版 |
2023/03/28(火) 19:13:03.36ID:jxesX9VZ
翔泳社のデータベースマガジンを書籍化したものなど、古い本だがいまでも考え方はかわらない。
新着レスの表示
レスを投稿する

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