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/13(水) 23:20:33.63

ほんとになにもないなら自分で連番振っとけばいいんじゃね

**NAME IS NULL** · 2017/12/14(木) 10:20:17.61

まー名寄せというのは名前が付くくらい昔からある根深い問題だよな

**NAME IS NULL** · 2017/12/14(木) 11:24:40.98

ハッシュを使うのはどうなん？

**NAME IS NULL** · 2017/12/14(木) 22:30:10.07

同じことだよ。ハッシュで区別できるためには元のデータで区別できなきゃならん。
連番も似たようなもの。

**NAME IS NULL** · 2017/12/15(金) 01:33:41.72

一般的なハッシュってのは
違う物に対して同じ値を生成するんだぜ
元のデータで区別できたとしても、ハッシュかけた段階で区別できなくなる可能性があるんだが
そんなものを主キーにするとか狂気のさただな

**NAME IS NULL** · 2017/12/15(金) 09:28:07.27

>>38
>一般的なハッシュってのは
>違う物に対して同じ値を生成するんだぜ
そんなハッシュあるのかｗ

**NAME IS NULL** · 2017/12/15(金) 11:30:27.39

まったくないとは言わんが
天文学的に小さいな

**NAME IS NULL** · 2017/12/15(金) 12:21:10.16

つまりハッシュ値と連番は本質的に全く別物

**NAME IS NULL** · 2017/12/15(金) 12:22:24.34

ハッシュ衝突は理屈上あるが
元データさえ違うなら心配する確率ではないね
とはいえ、PKに使うものじゃないと思うし連番で十分じゃないかな

**NAME IS NULL** · 2017/12/15(金) 20:41:37.20

いや元が同じだったら衝突とは言わんからw

**NAME IS NULL** · 2017/12/15(金) 22:00:00.19

ハッシュが衝突しないとか言ってる奴はMD5みたいな奴しか知らんのか？
理屈上どころか衝突前提のハッシュなんていくらでもある

**NAME IS NULL** · 2017/12/16(土) 07:09:25.86

>>44
おまえは何の勘違いをしとるんやw

**NAME IS NULL** · 2017/12/16(土) 08:06:02.76

>>45
はあ？
衝突前提のハッシュ知らんのか？
せめてここでも見とけよ
https://ja.m.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0

**NAME IS NULL** · 2017/12/16(土) 12:38:08.13

>>46
で、それ見て何を勘違いしたんやお前はw

**NAME IS NULL** · 2017/12/16(土) 13:13:01.80

なんだ、単なるレス古事記かよ

**NAME IS NULL** · 2017/12/16(土) 14:38:38.92

文脈やと思うけどなぁ

**NAME IS NULL** · 2017/12/16(土) 15:28:06.06

MD5辺りを単にハッシュと書いたアホが引っ込みつかなくなってるだけでしょ

**NAME IS NULL** · 2017/12/16(土) 16:16:42.51

というか、MD5はハッシュだし
MD5だって衝突の可能性はあるわけだが

**NAME IS NULL** · 2017/12/16(土) 21:36:50.89

おいおいMD5はハッシュ関数やぞw

**NAME IS NULL** · 2017/12/16(土) 22:34:42.89

>>52
こんなアホな突っ込み久々に見たわ w

**NAME IS NULL** · 2017/12/16(土) 22:56:10.26

>>53
やっとわかったわ
お前勘違いやなくそもそも根本的に何もわかっとらんやろw

**NAME IS NULL** · 2017/12/16(土) 23:00:47.03

友達いないんだろうな...
まあ頑張って一人て吠えてなよ w

**NAME IS NULL** · 2017/12/16(土) 23:06:48.97

>>55
いやお前がもっと頑張れやw
最初の勢いはどうしたw

**NAME IS NULL** · 2017/12/17(日) 08:05:30.02

また吠えてるよ...
技術的な話じゃなくなると勢いあるな w

**NAME IS NULL** · 2017/12/17(日) 12:37:49.59

>>57
え？技術的な話じゃなかったのかw
お前のその深い勘違いの根っこは一体どこにあんねんw

**NAME IS NULL** · 2017/12/17(日) 14:02:17.70

>>58
俺は技術的な話のつもりだったけど
「勘違い」としか連呼できないアホが絡んできたってだけのこと

**NAME IS NULL** · 2017/12/17(日) 19:39:41.63

>>59
しゃあないやろ勘違いをしとるんはお前なんやからw自業自得やぞw

**NAME IS NULL** · 2017/12/18(月) 04:59:23.82

ほらね w

**NAME IS NULL** · 2017/12/19(火) 16:42:48.07

>>61
どや？そろそろ耳の火照りもひいた頃合いやろからお前の勘違いを全部さらけだしてみたらどうや？
間違ってるとこおしえたるでw

**NAME IS NULL** · 2017/12/19(火) 19:29:26.17

>>62
> 間違ってるとこおしえたるでw
書いてからほざけよ w
どうせ頓珍漢なことしか書けないから引っ張ってるだけだろ？

**NAME IS NULL** · 2017/12/19(火) 19:59:07.34

>>63
アホかとっくにしびれをきらしとるわw
いいから早くお前がハッシュを何だと思ってるのか書けよ
お前の勘違いしてるとこ教えてやるからw

**NAME IS NULL** · 2017/12/19(火) 22:29:33.59

どうせハッシュ関数とハッシュ値は違うとか言い出すんだろ
文脈で判断しろよ、バーカ w

**NAME IS NULL** · 2017/12/20(水) 08:25:59.98

>>65
それはもう教えてやったやつやろw頓珍漢はお前やわw
てかそんなに恥かくの嫌やったらはじめから何も言うなやw
ホンマにカスやなお前w

**NAME IS NULL** · 2017/12/20(水) 08:46:00.54

言い当てられて顔真っ赤やん w

**NAME IS NULL** · 2017/12/20(水) 08:57:14.74

>>67
また動揺してエセ関西弁うつっとるでw恥ずかしいのぉ～w

**NAME IS NULL** · 2017/12/20(水) 12:55:06.94

>>68
まだ粘着してるのかよ w
勘違いと言い張るならどこのレス見てどう勘違いしてると思ったのか書けよ
それが書けないからいつまでも勘違いを連呼するしかないんだろ w

**NAME IS NULL** · 2017/12/20(水) 15:28:12.50

>>69
お前なあwメッチャ自分の勘違いが気になっとるくせになんで素直に聞けんのやw
粘着しとるのお前やでw恥ずかしいのぉ～w

**NAME IS NULL** · 2017/12/20(水) 17:47:08.79

はいはい、具体的なにも指摘できないならいちいち絡んでくるなよ w

**NAME IS NULL** · 2017/12/20(水) 18:50:24.06

>>71
何かうやむやにしたいみたいやけど悔しくてレス返さんと気がすまんのやなw
てかそもそも誰もお前がスキル高い奴だなんて思っとらんからそんなに悔しがる意味もないんやけんどなw

**NAME IS NULL** · 2017/12/20(水) 19:09:52.02

>>72
>>71

**NAME IS NULL** · 2017/12/20(水) 20:03:30.28

何のためにもならない罵り合いになってるので、もうやめたら？

**NAME IS NULL** · 2017/12/20(水) 20:29:25.30

>>73
まだレス返すんかwどんだけ悔しいんやw
無理してそんな煽りレスばっかしとらんと素直にハッシュについて言えばいいやんけw
教えてやるって何度も言っとるのにw

**NAME IS NULL** · 2017/12/20(水) 21:17:35.06

>>75
>>46
煽りしかできないアホの出る幕じゃねーよ w

**NAME IS NULL** · 2017/12/21(木) 07:29:56.41

>>76
おいおい何ふりだしに戻しとるんやw
やっぱり何もわかっとらんから自分の言葉で言えんやんけw
で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
言ってみ？教えてやるからw盛大にバカにした後でやけどなwww

**NAME IS NULL** · 2017/12/21(木) 08:07:26.64

当事者じゃないけど、うざいよ。

ハッシュテーブルのこといってるんじゃないの？グルーピングの用途でハッシュ関数使うって意味で

**NAME IS NULL** · 2017/12/21(木) 10:05:36.30

データベースの用途で、グループ分けしたい時に
多対一の変換に意味があるのか？

**NAME IS NULL** · 2017/12/21(木) 10:22:53.47

>>79
多対1じゃなくて、多対n。結合するときにないぶてきに使われるhash joinとかこの方式だよね。

**NAME IS NULL** · 2017/12/21(木) 10:24:46.30

衝突前提じゃないハッシュは完全ハッシュとかいわれて普通はただのハッシュとは違う扱いなわけだが

いいかげん具体的な指摘なしで勘違いとしかほざけないやつはうざいわ

**NAME IS NULL** · 2017/12/21(木) 10:49:25.14

今日のお弁当にはハッシュドポテトが入っています

**NAME IS NULL** · 2017/12/21(木) 12:54:19.84

>>77
> で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
前提なしでハッシュって書いたら衝突するケースを想定するのは当たり前
そう言うことを知らなかった>>39が暴れてるだけだろ

**NAME IS NULL** · 2017/12/21(木) 12:57:47.83

おやおやようやく勘違いの全貌が見えて来よったなw
後で教えたるからなw
とりあえずそれまでみんなで>>81を盛大にバカにしときw

**NAME IS NULL** · 2017/12/21(木) 15:07:28.11

しつけえよ馬鹿

**NAME IS NULL** · 2017/12/21(木) 15:50:38.56

で結局33の質問に対して正解は何？

**NAME IS NULL** · 2017/12/21(木) 19:55:49.52

何の名簿か知らんけど、会社でも社員コードってのがあるんだから>>34で良いじゃん。
何揉めてんだか
>>33はそれの何が不満なんだよ。

**NAME IS NULL** · 2017/12/21(木) 20:28:48.83

なんだこれ。

PKを連番じゃなくてハッシュ値にすべきって散々煽ってたのか。どんな回答するのかすげー気になるわ。

**NAME IS NULL** · 2017/12/21(木) 21:31:06.81

>>86
>>87の言う通り社員番号とかのユニークキーがあればそれを使えばいい
なんにもなければ>>34の言うように連番を振るとかyymmdd+枝番とか要件によってユニークな番号を振ればいい
とりあえずハッシュバカは無視でいい w

**NAME IS NULL** · 2017/12/21(木) 22:13:21.18

>>89
お？バカ少しおとなしくなったやんけw完全ハッシュはどうしたw

**NAME IS NULL** · 2017/12/21(木) 22:40:25.61

なんだ、ただのキチガイか。

**NAME IS NULL** · 2017/12/21(木) 22:42:05.48

安易に連番ってのもたいていバカだけどな。

**NAME IS NULL** · 2017/12/21(木) 22:50:31.46

適切なものがなければ、作らなくて良いと思うが

**NAME IS NULL** · 2017/12/22(金) 00:27:00.22

>>90
完全ハッシュについて調べてこいよ w

**NAME IS NULL** · 2017/12/22(金) 00:30:58.20

>>92
もっといい解があるなら示してみてよ

>>93
> 適切なものがなければ、作らなくて良いと思うが

> PKを何にしたら良いでしょうか？
って言ってるのにバカですか？

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

PKを指定しなければDB側で良きに計らってくれるんじゃ？

**NAME IS NULL** · 2017/12/22(金) 03:07:52.25

連番を良きに計らってくれる機能は多くのDBMSで実装されてるが
PKを指定しないときによきに計らってくれるDBMSなんてみたことないわ

と言っといて、ACCESSとか勝手に連番でPK作ってくれた気もするな

すくなくともRDBMSの基本理念においては、すべてのテーブルはPKを持つべしっとなってる

**NAME IS NULL** · 2017/12/22(金) 03:28:06.91

実際プライマリーキーのないテーブルが作れるんだから
持つべしってことはないでしょ

**NAME IS NULL** · 2017/12/22(金) 05:48:11.28

住所、氏名を複合PKにするとか

**NAME IS NULL** · 2017/12/22(金) 07:21:44.64

>>94
ええでその調子やwビビらんともう少しその勘違い晒せやへたれw

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