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/22(金) 08:14:52.49

>>95
例えば、レコードとして実在の個人を表現したいのに氏名しかないから同姓同名の人が
区別できない、なんてのはそもそもシステム設計の失敗。
それを単に連番振れば解決するかのように言う奴はバカだし有害。

有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
仕組みも必要。。

**NAME IS NULL** · 2017/12/22(金) 08:43:18.68

>>101
> 個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
> 仕組みも必要。。
そんな当たり前のことを力説されても困るわ w

**NAME IS NULL** · 2017/12/22(金) 10:45:03.07

>>101
>有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
>(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
>個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
>仕組みも必要。。

すまんが、これって連番振るのと何が違うの？

**NAME IS NULL** · 2017/12/22(金) 11:01:13.97

>>103
俺もそう思うんだよね。
連番であってもなくてもいいけど、社員コードが社員の識別に役立てないとでも思ってんのか

**NAME IS NULL** · 2017/12/22(金) 12:45:16.02

おいおい>>101と>>102は勘違いバカやぞw

**NAME IS NULL** · 2017/12/22(金) 14:56:17.28

>>105
さっさと、PKにハッシュ値を設定すべき理由を教えてくれや

**NAME IS NULL** · 2017/12/22(金) 18:50:39.54

>>101,104
要件による前提をかってに決めないで話してくれ

**NAME IS NULL** · 2017/12/22(金) 19:45:03.18

>>106
さすが勘違いバカやなwお前には一体何が見えとるんやw

**NAME IS NULL** · 2017/12/22(金) 20:36:34.50

>>107
この要件は

名簿みたいなデータではPKを何にしたら良いでしょうか？

これ以外質問者からは提示されていない。
ウスラバカのお前こそ勝手に決めつけんな

**NAME IS NULL** · 2017/12/22(金) 21:19:47.34

>>103
重要なのはA=1,B=2なのかA=2,B=1なのか特定できてるってこと。
そうじゃない単なるユニークなだけのキーを振っても意味ない。

**NAME IS NULL** · 2017/12/22(金) 22:01:01.41

>>110
おまえキチガイのふりしたいみたいやけんどわざとらしすぎていまいち萌えんのうw

**NAME IS NULL** · 2017/12/22(金) 22:24:18.98

なんか変なのが居ついてるな。

**NAME IS NULL** · 2017/12/22(金) 22:43:39.26

>>110
すまん、やはりよく分からない
特定できることにどのようなメリットがあるの？

**NAME IS NULL** · 2017/12/22(金) 23:30:49.60

>>108

>>36
が見えてんな

**NAME IS NULL** · 2017/12/22(金) 23:34:05.23

でも、もういいよ。消えてくれ。

わかったよ。ハッシュでPK最高ー！

**NAME IS NULL** · 2017/12/22(金) 23:53:46.12

>>114
おまえなあwエセ関西弁使う奴が全部俺やと勘違いしとるやろw
さすが勘違いキングやなwww
てかお前完全に名前を主キーにして大目玉くらうタイプやなw
どんな腐った脳ミソしとったらハッシュを知らんお前をバカにしとる俺と
ハッシュを知らん発言の>>36が同一人物に見えんねんwww

**NAME IS NULL** · 2017/12/23(土) 00:05:28.58

>>116
へーっ。まじっすか。まじはんぱねーっす。

自分、すげー尊敬しちゃうんで、何に噛み付いてんのかまじ教えてほしいっす。

**NAME IS NULL** · 2017/12/23(土) 08:01:51.82

>>113
特定できるとメリットがあるというより、AなのかBなのか判別できないデータじゃ意味ないだろうと。
ユニークキーが存在しない状態と変わらんじゃん。

**NAME IS NULL** · 2017/12/23(土) 11:03:50.26

たとえば山田太郎さんが二人いて
山田太郎Aと山田太郎Bを区別しないといけないなら
そのためのカラムを持つべき
そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
単なるユニークなだけのキーを振っておけばいい

今ここで連番を主キーにしろって主張は自然キーの候補がないならって前提だぞ

そもそも主キーが要らないだろって話は別の議論な

**NAME IS NULL** · 2017/12/23(土) 12:25:57.35

フリだけかと思ったらガチキチっぽいやんコイツw

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