DB設計を語るスレ 10 [無断転載禁止]©2ch.net

**NAME IS NULL** · 2017/05/22(月) 16:38:31.52

語れ

前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/

**NAME IS NULL** · 2017/12/23(土) 12:47:20.20

>>120
へーっまじっすか。まじはんぱねーっす。早く何に噛み付いてるか教えてくださいよ。

**NAME IS NULL** · 2017/12/23(土) 15:22:28.35

とりあえずWikipediaの主キーの項を
100回読んできたら？
あとデータベーススペシャリストに合格するくらい勉強したら、良いと思うよ

**NAME IS NULL** · 2017/12/25(月) 21:50:56.03

>>119
> 山田太郎Aと山田太郎Bを区別しないといけないなら
> そのためのカラムを持つべき

横からだが、それがサロゲートキーだろ

**NAME IS NULL** · 2017/12/26(火) 02:36:23.97

>>123
サロゲートじゃなくて、自然キーで区別できるようなカラムが必要だろって事だろ

**NAME IS NULL** · 2017/12/26(火) 07:14:12.54

>>123
むしろサロゲートキーは
> そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
> 単なるユニークなだけのキーを振っておけばいい
の方だろ

**NAME IS NULL** · 2017/12/26(火) 08:25:45.48

>>124,125
なるほど住所や何かで複合主キーにしろという事か
読解力がなくて悪かった

それでも不便な自然キーを優先させようとは理由がない限り思わんが

**NAME IS NULL** · 2017/12/26(火) 11:22:36.49

複合PKが正解？

**NAME IS NULL** · 2017/12/26(火) 12:09:06.71

住所はダメよ
同じ住所の可能性はゼロじゃないから

**NAME IS NULL** · 2017/12/26(火) 12:36:20.97

だから名寄せは難しいと

**NAME IS NULL** · 2017/12/26(火) 12:59:30.71

>>127
要件による
てか、何と何の複合でやろうとしてるのかすらわからんのに正解かどうかきかれてもな

**NAME IS NULL** · 2017/12/26(火) 13:00:41.95

>>128
そもそも住所は引っ越しとか町村合併で結構頻繁に変わるし

**NAME IS NULL** · 2017/12/26(火) 17:44:38.01

ORMの都合とかで、すべての主キーを単独の連番にってのはみたことあるな

**NAME IS NULL** · 2017/12/26(火) 21:57:54.33

>>127
複合キーでできるならそれでいいが、ハンドリングしにくいならそのサロゲートでもいい。
ただし複合キーでもユニークに特定できないものはサロゲートにしたところでやっぱりダメ。

**NAME IS NULL** · 2017/12/26(火) 22:43:04.71

>>130
氏名住所年齢
くらいで十分じゃあないの？

**NAME IS NULL** · 2017/12/26(火) 22:58:10.93

>>134
生年月日ならまだしも年齢とか変わっていくものをPKの一部にするとか変わってるな

**NAME IS NULL** · 2017/12/26(火) 23:03:51.55

いいじゃん毎年発生するデータなら。健康診断結果テーブルとか。

**NAME IS NULL** · 2017/12/26(火) 23:17:18.41

それぞれの誕生日に更新しないと

**NAME IS NULL** · 2017/12/27(水) 08:04:26.05

>>136
Aさんのここ５年間の情報頂戴って言われたらどうするつもりなんだ？ w

**NAME IS NULL** · 2017/12/27(水) 08:12:27.79

やりたいこと次第で「できます」か「できません」のどっちかでしょ？

「Aさんは今何歳？」
「今年は西暦何年？」
「今年は昭和何年？」

**NAME IS NULL** · 2017/12/27(水) 10:25:59.08

お前等の自然キーにかける情熱はどこから来るんだ

**NAME IS NULL** · 2017/12/27(水) 12:19:03.35

情熱てw単なる無理解やんけw

**NAME IS NULL** · 2017/12/27(水) 12:46:24.97

>>134
年齢を生年月日にするにしても
同姓同名の誕生日も同じ人が
ルームシェアで同じ家に住んでる可能性がある以上
十分とはいえない

**NAME IS NULL** · 2017/12/27(水) 14:18:50.57

同姓同名、同じ誕生日で同じ場所に住む人が2人居ても良いと思うし、
そういう風にDBに入るなら、間違いではないし誰も困らない

**NAME IS NULL** · 2017/12/27(水) 14:26:47.16

そもそもの>>33の名簿という要件を満たすのそれ

**NAME IS NULL** · 2017/12/27(水) 14:48:03.83

まだ続いてんだ、これ。
>>33すら放棄してんのに
お前らヒマなんやな w

**NAME IS NULL** · 2017/12/27(水) 14:55:09.55

提示されていない条件を仮定しても意味が無いと思うけど

**NAME IS NULL** · 2017/12/27(水) 19:19:41.67

氏名も住所も年齢もすべて値が変化するものだと気づかない時点でダメだな。

**NAME IS NULL** · 2017/12/27(水) 21:05:50.80

この世に変化しないものなんかないんだから主キーだって変化すればいいじゃない

**NAME IS NULL** · 2017/12/27(水) 21:22:32.89

「昨日？そんな昔の事は忘れた。
明日？そんな先の事は分らない」

**NAME IS NULL** · 2017/12/27(水) 21:23:22.17

>>146
それな
なのに>>101が連番ではダメと難癖つけたから脱線しただけだよ

**NAME IS NULL** · 2017/12/27(水) 22:01:00.99

「連番付けとけばいい」「連番じゃダメ」
どっちが一方かだけが提示されていない条件を仮定したかなんて決められるもんかねぇ。

**NAME IS NULL** · 2017/12/27(水) 22:20:42.71

「連番じゃなきゃダメ」はどこいった？
唯一の条件を問わない正解なのに

**NAME IS NULL** · 2017/12/28(木) 17:05:27.38

>>146
回答するに当たって条件があるなら示しとかないとな

>>147
>>101は自然キー（候補キー）の必要性の問題を連番が問題だと勘違いしてるからな

>>152
>「連番じゃなきゃダメ」
そもそもそんな主張がどこにあった？

**NAME IS NULL** · 2017/12/28(木) 17:17:30.46

それは「唯一の条件を問わない正解」なんて言っている時点で触っちゃダメな人。

**NAME IS NULL** · 2017/12/29(金) 11:03:53.55

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

NULCDBFZ4S

**NAME IS NULL** · 2017/12/31(日) 10:46:46.28

DB勉強中です。
Primary Keyがないテーブルを使うと何か問題が起こりますか？

**NAME IS NULL** · 2017/12/31(日) 18:11:01.37

テーブルが問題を起こすのではない
おまえが問題を起こすのだ

**NAME IS NULL** · 2017/12/31(日) 18:32:52.59

例えば同姓同名の人がいたとして
その人から自分の電話番号変わったから変更してって言われても
どちらを更新して良いか分からない（＝人間）
全部書き換えようとする（＝DB）
こんなことが起こる

普通は一意性を確保するために、
社員IDやら学生IDやらマイナンバーやら
他と重ならないキー情報を用意して、
それをPKにしている。

**NAME IS NULL** · 2017/12/31(日) 18:54:16.62

>>158
そういうのは履歴を取る設計にするのが普通なんだよ。

**NAME IS NULL** · 2017/12/31(日) 19:11:39.10

マスターは最新の状態で良いと思う
そんなに頻繁に変えるとは思わないし
履歴は履歴レコードで残せば

**NAME IS NULL** · 2017/12/31(日) 20:03:47.84

>>159
お前は何を言ってるんだ？

**NAME IS NULL** · 2017/12/31(日) 20:47:09.37

>>161
あくまで俺の予想だけど
そういうのは履歴を取る設計にするのが普通なんだよ。
って言ってるんだと思う

**NAME IS NULL** · 2017/12/31(日) 21:23:49.22

>履歴を取る設計にするのが普通

すっげーー含蓄のある台詞でした
来年はこれを使おう

**NAME IS NULL** · 2017/12/31(日) 21:28:58.37

>>162
>>158からそれが読み取れるとしたらよほど天才か知ったかのアホとしか思えんが w

**NAME IS NULL** · 2017/12/31(日) 21:44:37.10

>>164
勘違いクンはお口にチャックやでえwwww
おまえほんまにアホやなあwww

**NAME IS NULL** · 2017/12/31(日) 21:49:45.03

またこのパターンかよ...
具体的になにも指摘できないなら絡んでこなきゃいいのに w

**NAME IS NULL** · 2017/12/31(日) 21:57:51.30

>>166
絡んできたのお前やろがwww
脳ミソおかあちゃんのアナルに忘れてきたんかお前はwwwww

**NAME IS NULL** · 2017/12/31(日) 22:16:24.92

　　　　　　 ,､‐'''''''''ヽ､
　　　　　/:::::;;-‐-､:::ヽ　　　　　　　　　　　 _,,,,,,,_
　　　　 l::::::l　　_,,､-‐"iiiiiilllllllllllliiiiii､__ゞ:::::::::::｀ヽ,
　　　　　ヽ::｀／: :::..: iiiiiilllll||llllliiiiii: : : : ヽｲ~`ヽ:::::::i
. 　　　　　／;,..-;;;;;;;;;,,,,, : l|l: : : : : : : : : : : : : ＼　ﾉ:::::}
　　　　 /: /: : ""　　""::::.....　;;/´: ｀ヽ : : : : : :ヽ:::ノ
.　　　　 !: : : .,,ぇzv､..,::;:　　:::: '^W;;a=z_: : : : : : :.!
　　　　 |: : : :.`'':::.:;;'`::.;　　 .:.:: 　-z-a:、,, : ::＜iiii|
　　　　 |: :　　　　　 ::.　　 ..:::::..　`.':::':::''^ ´ : : : :.|　　　みんないいこだから
　　　　|:::.....　　　 .;''　　 '::::::;;i;..　　　　　 ..:;; : : :i　　　　けんかはやめよう
　　　　/:.ト;;;;;;;;.......'ヾ　::.::;iii;;ノ: :..　　　 ..;;,.イ: : :.i
　　￣|: ::';;;`':::;'　　　,,、`,,'　　'::::;;,,,,;;;::'''::::＜iii/
.　　　／!.: ::.　　ヽ.'',,,,::;;;v;;;;;:....　　　''''　　:-─/─
　　　　　ヽ　:.　.... ヾ;i;f",,i",_i.j;;;''"".. 　　,,:ヽ／
　　　　　　＼;:::　　ヾ';;;;;;;;;;;::'''　...::'':: ,,::::::／＼
　　　　　　｀''‐､､__ ￣￣　　　__,,,,､-‐"
.　　　　　／/:::::/ヽ￣￣￣￣ノ::::/＼
.　　　　／　/:::::/　｀￣￣￣/:::::/.　　＼

**NAME IS NULL** · 2018/01/01(月) 14:02:21.33

運用の経験がないとデータの変化を追えないとたいへんなのがわからないのだろう。

**NAME IS NULL** · 2018/01/01(月) 15:50:18.06

データの変化を追えなかった、その経験談良かったらここに書いて貰えます？

**NAME IS NULL** · 2018/01/01(月) 20:56:53.06

>>170
人的データパッチミス、プログラムの変更、追加によるバグが変なデータを作り出す。

**NAME IS NULL** · 2018/01/01(月) 21:23:07.91

それはすごいシステムだ
そんな所利用したくない

**NAME IS NULL** · 2018/01/01(月) 21:26:43.18

>>169
ふーん。全てのデータをinsertとフラグ列のupdateとかで更新してくってこと？

**NAME IS NULL** · 2018/01/01(月) 22:30:38.24

大規模なシステムに関わったことがないと理解できないだろう

**NAME IS NULL** · 2018/01/01(月) 22:32:52.66

>>173
履歴レコードの話だよ。マスタデータでもトランザクションデータでも追跡できないのは運用で困る。何がどうなったのか他人に説明できないだろうが。

**NAME IS NULL** · 2018/01/01(月) 22:56:14.39

トランザクションデータてそれ自体がログやからトランザクションなんやで
トランザクションの記録を更新すんなアホw

**NAME IS NULL** · 2018/01/01(月) 23:08:31.05

UPDATEと誤解してるのか

**NAME IS NULL** · 2018/01/01(月) 23:08:36.63

この人のシステム、怖くて触りたくない
よっぽど酷い人たちで開発してそう

**NAME IS NULL** · 2018/01/01(月) 23:10:08.13

世の中には常に数百人が関わってるシステムがあるんだよ。こういうシステムだと何が起こるかわからない。

**NAME IS NULL** · 2018/01/01(月) 23:41:53.03

>>156
履歴を記録しろと言い出す謎の勢力が襲い掛かってくる

**NAME IS NULL** · 2018/01/01(月) 23:46:18.18

履歴が一種のイベントとして成立しているなら記録すべきだよね
（例えば売上とか）
そうじゃないなら必要性が理解できない

**NAME IS NULL** · 2018/01/02(火) 00:05:50.83

テロリスト集団が巣くっているシステム？

**NAME IS NULL** · 2018/01/02(火) 00:21:32.94

ここ設計スレだし
履歴が必要なら履歴とるように設計すればいい

履歴とるように設計されてないから苦労したとかならしらんから
運用の話は別スレでやってくれ

**NAME IS NULL** · 2018/01/02(火) 00:28:00.40

トランザクションって言葉のイメージする範囲が広すぎてかみ合ってないところがあるな

単にマスタじゃないデータという意味合いでトランザクションって言ってる場合があるけど
この場合は当然そのテーブルが更新されたりする

もっと狭い意味でトランザクションって言ってるなら、トランザクションなんだから追加しかありえないだろ
それを更新するとかありえないって設計もある

**NAME IS NULL** · 2018/01/02(火) 07:23:53.00

まあ履歴が必要なシステムもあるんだろうけど>>158からいきなり履歴とか数百人が関わるシステムとか言い出してて笑える

**NAME IS NULL** · 2018/01/08(月) 07:44:30.25

業務的な必要とＳＱＬの仕様ってだいぶ乖離してるよな

ＤＤＬは基本１件ずつしか触れないようにしといてほしかった
手動で操作するのこわい

**NAME IS NULL** · 2018/01/08(月) 10:32:22.05

DMLじゃなくてDDL?
業務でどんなSQLを実行してるんだ？

まあDMLにしても1件ずつとかありえんけどな
SQLは手続き型じゃないんだよ

**NAME IS NULL** · 2018/01/24(水) 13:49:08.82

運用中のテーブルにカラムを追加する場合、どこに追加しますか？
末尾に追加しますか？それともデータ型やカラム名が合う場所に追加しますか？

くだ質ですが、気になるので教えてください。

**NAME IS NULL** · 2018/01/24(水) 14:29:33.12

末尾で問題があるのかって話だよ

**NAME IS NULL** · 2018/01/24(水) 15:20:39.28

>>189
問題はありません。
ですが、DB設計的に揃えるのが通常かな？と思いまして

**NAME IS NULL** · 2018/01/24(水) 17:51:33.77

>>190
そもそも間に挿入できると思っているのか？

列順が変わることを想定していないプログラムへの影響、列順が違うのだけなのに運用を止める、データの移行のミス等、面倒なことばかりで普通はやらない。

**NAME IS NULL** · 2018/01/24(水) 19:47:51.39

>列順が変わることを想定していないプログラムへの影響

さすがにそこまでは面倒見きれんw

**NAME IS NULL** · 2018/01/24(水) 20:08:03.01

本来のリレーショナルデータベースなら, 列の順序はないのでは？
実装上で問題があるケースってあるのかな？

**NAME IS NULL** · 2018/01/24(水) 20:09:48.86

select * を使用禁止にする

**NAME IS NULL** · 2018/01/24(水) 20:38:49.43

【30歳で自殺】　スピードスケート代表　≪ほら死んだ≫　マイトＬーヤ「競争は殺人」　【五輪は犯罪】
http://rosie.5ch.net/test/read.cgi/liveplus/1516779817/l50

**NAME IS NULL** · 2018/01/25(木) 16:14:20.92

たとえばカラム一覧が
id,name,address,telephone,comment,date

だとする。そして「携帯電話」を追加したい。
こういった要件の場合、
id,name,address,tel,mobilephone,comment,date

ってしたくならないか？
id,name,address,telephone,comment,date,mobilephone

だとなんか納まりが悪いじゃん

**NAME IS NULL** · 2018/01/25(木) 16:16:11.62

修正。2番めに書いたのが無駄に削ってしまった。
id,name,address,telephone,mobilephone,comment,date

**NAME IS NULL** · 2018/01/25(木) 16:22:13.38

それは趣味の話であって、設計の話ではない

**NAME IS NULL** · 2018/01/25(木) 17:12:08.82

>>196
言いたいことはわかるけど、
本来リレーショナルデータベースにはそうした順序性が存在しない

**NAME IS NULL** · 2018/01/25(木) 17:14:48.52

>>198-199
いやだから、気になりませんか？って話です。
本質とかルールがどうこうではなく、心情的な面で。

**NAME IS NULL** · 2018/01/25(木) 17:22:02.78

気になるもクソもRDBってのは「集合」を扱うもんなの
そして集合には順序なんて概念はないの

**NAME IS NULL** · 2018/01/25(木) 17:23:25.83

>>199
もちろん、ユーザに見せるときにはSQLではなくプログラミング言語で調整しているよ

**NAME IS NULL** · 2018/01/25(木) 17:25:46.44

じゃ、テーブル設計書作ってるときとかphpMyAdminを利用してるときとかなんでも良いです。
順序がないけど順序を視覚化しているツールを使っている時に、
カラム名やデータ型が異なる順番で並んでると気になりませんか？

単に気持ちの問題ならどうでもよくても、仕様書にした場合、
順序がバラバラだとミスや勘違いの原因になりやすいのではないでしょうか？

**NAME IS NULL** · 2018/01/25(木) 17:30:24.66

>>203
気にはなるけどリレーショナルデータベースとはそうしたもんだ

仕様とはまったく別の話
ある順序通りに列を並べたいというのが仕様にあればアプリ側で対応すべき話であって
その順序をDBに持ち込むことがおかしい

**NAME IS NULL** · 2018/01/25(木) 17:32:15.39

>>204
つまり、
>>196の要件で「携帯電話」を追加したい場合、
id,name,address,telephone,comment,date,mobilephone

で良いということですか？
これは順序も何も考えて無くて、単に末尾に追加しているだけです。

**NAME IS NULL** · 2018/01/25(木) 17:38:50.08

>>205
何度も言っているように、DBはそれで良い
というか、そこで順序にこだわることがおかしい
ユーザ側に見せる時には、プログラミング言語(JavaやC#やPHPでもなんでも)で調整すべき

**NAME IS NULL** · 2018/01/25(木) 17:39:52.94

205はリレーショナルモデルの勉強をした方が良いのでは

**NAME IS NULL** · 2018/01/25(木) 18:03:00.90

エクセルに切り替えれば解決

**NAME IS NULL** · 2018/01/25(木) 18:05:52.91

順序にこだわるのは、>>203にも書いたとおり、
仕様書なり設計書なりを見た人物（自分含む）が
誤認しないか？正しく伝わるか？と思ったからです。

過去にカラム追加が必要だと思ってたら、既にあったということがありました。
正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
とかく順序を意識して行いと、そういった不具合や誤認が生まれます。

リレーショナルデータベースとしては何が正しいか・正しくないかではなく、
扱うのは人間です。人間にわかりやすいのが一番だと思っています。
その上で出た疑問です。

**NAME IS NULL** · 2018/01/25(木) 18:08:44.34

たとえばMySQL「AFTER」というコードが有るのも、「指定位置に追加したい」
という需要があったからこそ用意されたのではないでしょうか？
そうでなければ末尾でも良いわけです。

**NAME IS NULL** · 2018/01/25(木) 18:12:05.73

何のためにほとんどのアプリでUIが別途あると思っとる
そういう整形はフロントエンドの役目

**NAME IS NULL** · 2018/01/25(木) 18:13:18.10

>>209
まさかと思うけど
リレーショナルデータベースをphpMyAdminで直接編集しようとしている？
(そんなはずはない、と思いたい)

>カラム追加が必要だと思ってたら、既にあったということがありました
というのは、単にモデリングの欠陥を言っているだけで、

>正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
これもよくあるアンチパターンで、1テーブル100カラムというのはほとんどが設計ミス

>人間にわかりやすいのが一番だと思っています
とか言い訳しているけど、単なる知識不足にすぎないのでは

**NAME IS NULL** · 2018/01/25(木) 18:19:21.67

teratailを見ると以下のように回答している人がいました。

「カラム位置のパフォーマンスへの影響ですが、一般的にRDBMSは可変長カラムを後ろに持っていった方が性能は良いです。可変長カラムより後ろのカラムに対しては、実際のデータ長を見て毎回オフセットを計算する必要があるためです。」

これを読み解くと、カラム位置って大事じゃないんですかね？
この回答者が間違っていると言われればそれまでですが。

**NAME IS NULL** · 2018/01/25(木) 18:26:41.60

>>213 DBの実装に依存する
これまでの君の主張は見た目の順序のことだから
的外れの突っ込みだぞ

**NAME IS NULL** · 2018/01/25(木) 18:41:36.73

どうしてもやりたきゃ
別テーブル作ってそこにコピーしてリネームすれば

**NAME IS NULL** · 2018/01/25(木) 18:54:38.23

それこそ無駄じゃないですか？

MySQLに順序変更に関するコマンドがある以上、
私の質問ってそんな的外れじゃないと思うんですけどね
「DBに順序という概念はない」っていう意味はわかりますけども。

**NAME IS NULL** · 2018/01/25(木) 19:13:05.84

DBに依存する処理だけど、やりたければやれば良いのだと思うよ
>>216 の動機はやはり的はずれだと思うけど
みんなが言っているようにアプリで対応するのじゃ駄目なの？

**NAME IS NULL** · 2018/01/25(木) 19:36:37.81

まあしかし、心情的には理解できなくもない
最終更新日や削除フラグ(笑)の後ろに項目あると、ああ、あとから追加したんだなと切ない気持になる

ＤＢＭＳ的にはカラムは後ろにしか追加できない場合がほとんどだろうけど
ＧＵＩ系の管理ツールだとテーブル作り直して間に追加したかのごとくしてくれる物もあるぞ

**NAME IS NULL** · 2018/01/25(木) 19:37:01.16

>>216
また馬鹿が調子こいてでまかせ言ってたみたいだなw
迷惑かけてすまんのうw

×：「DBに順序という概念はない」
○：「関係モデルに順序という概念はない」

RDBMSの標準SQLでは定義された列の順番が存在する

よってお前の質問は全く的外れではないし
後から途中に列を挿入するという仕様変更も間違いではない

**NAME IS NULL** · 2018/01/25(木) 19:40:17.60

>>219
「DBに順序という概念はない」は216だけが言ってるんじゃないかな
そして標準SQLでは, 途中に列を挿入する処理は存在していないんじゃない？

**NAME IS NULL** · 2018/01/25(木) 19:52:49.07

>>220
少なくとも質問者である私は「DBに順序という概念はない」って言っていません。
回答者がそうおっしゃるから、自身の知識を改めただけです。