DB設計を語るスレ 10 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>59
しゃあないやろ勘違いをしとるんはお前なんやからw自業自得やぞw >>61
どや?そろそろ耳の火照りもひいた頃合いやろからお前の勘違いを全部さらけだしてみたらどうや?
間違ってるとこおしえたるでw >>62
> 間違ってるとこおしえたるでw
書いてからほざけよ w
どうせ頓珍漢なことしか書けないから引っ張ってるだけだろ? >>63
アホかとっくにしびれをきらしとるわw
いいから早くお前がハッシュを何だと思ってるのか書けよ
お前の勘違いしてるとこ教えてやるからw どうせハッシュ関数とハッシュ値は違うとか言い出すんだろ
文脈で判断しろよ、バーカ w >>65
それはもう教えてやったやつやろw頓珍漢はお前やわw
てかそんなに恥かくの嫌やったらはじめから何も言うなやw
ホンマにカスやなお前w >>67
また動揺してエセ関西弁うつっとるでw恥ずかしいのぉ〜w >>68
まだ粘着してるのかよ w
勘違いと言い張るならどこのレス見てどう勘違いしてると思ったのか書けよ
それが書けないからいつまでも勘違いを連呼するしかないんだろ w >>69
お前なあwメッチャ自分の勘違いが気になっとるくせになんで素直に聞けんのやw
粘着しとるのお前やでw恥ずかしいのぉ〜w はいはい、具体的なにも指摘できないならいちいち絡んでくるなよ w >>71
何かうやむやにしたいみたいやけど悔しくてレス返さんと気がすまんのやなw
てかそもそも誰もお前がスキル高い奴だなんて思っとらんからそんなに悔しがる意味もないんやけんどなw 何のためにもならない罵り合いになってるので、もうやめたら? >>73
まだレス返すんかwどんだけ悔しいんやw
無理してそんな煽りレスばっかしとらんと素直にハッシュについて言えばいいやんけw
教えてやるって何度も言っとるのにw >>75
>>46
煽りしかできないアホの出る幕じゃねーよ w >>76
おいおい何ふりだしに戻しとるんやw
やっぱり何もわかっとらんから自分の言葉で言えんやんけw
で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
言ってみ?教えてやるからw盛大にバカにした後でやけどなwww 当事者じゃないけど、うざいよ。
ハッシュテーブルのこといってるんじゃないの?グルーピングの用途でハッシュ関数使うって意味で データベースの用途で、グループ分けしたい時に
多対一の変換に意味があるのか? >>79
多対1じゃなくて、多対n。結合するときにないぶてきに使われるhash joinとかこの方式だよね。 衝突前提じゃないハッシュは完全ハッシュとかいわれて普通はただのハッシュとは違う扱いなわけだが
いいかげん具体的な指摘なしで勘違いとしかほざけないやつはうざいわ >>77
> で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
前提なしでハッシュって書いたら衝突するケースを想定するのは当たり前
そう言うことを知らなかった>>39が暴れてるだけだろ おやおやようやく勘違いの全貌が見えて来よったなw
後で教えたるからなw
とりあえずそれまでみんなで>>81を盛大にバカにしときw 何の名簿か知らんけど、会社でも社員コードってのがあるんだから>>34で良いじゃん。
何揉めてんだか
>>33はそれの何が不満なんだよ。 なんだこれ。
PKを連番じゃなくてハッシュ値にすべきって散々煽ってたのか。どんな回答するのかすげー気になるわ。 >>86
>>87の言う通り社員番号とかのユニークキーがあればそれを使えばいい
なんにもなければ>>34の言うように連番を振るとかyymmdd+枝番とか要件によってユニークな番号を振ればいい
とりあえずハッシュバカは無視でいい w >>89
お?バカ少しおとなしくなったやんけw完全ハッシュはどうしたw >>92
もっといい解があるなら示してみてよ
>>93
> 適切なものがなければ、作らなくて良いと思うが
> PKを何にしたら良いでしょうか?
って言ってるのにバカですか? PKを指定しなければDB側で良きに計らってくれるんじゃ? 連番を良きに計らってくれる機能は多くのDBMSで実装されてるが
PKを指定しないときによきに計らってくれるDBMSなんてみたことないわ
と言っといて、ACCESSとか勝手に連番でPK作ってくれた気もするな
すくなくともRDBMSの基本理念においては、すべてのテーブルはPKを持つべしっとなってる 実際プライマリーキーのないテーブルが作れるんだから
持つべしってことはないでしょ >>94
ええでその調子やwビビらんともう少しその勘違い晒せやへたれw >>95
例えば、レコードとして実在の個人を表現したいのに氏名しかないから同姓同名の人が
区別できない、なんてのはそもそもシステム設計の失敗。
それを単に連番振れば解決するかのように言う奴はバカだし有害。
有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
仕組みも必要。。 >>101
> 個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
> 仕組みも必要。。
そんな当たり前のことを力説されても困るわ w >>101
>有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
>(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
>個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
>仕組みも必要。。
すまんが、これって連番振るのと何が違うの? >>103
俺もそう思うんだよね。
連番であってもなくてもいいけど、社員コードが社員の識別に役立てないとでも思ってんのか >>105
さっさと、PKにハッシュ値を設定すべき理由を教えてくれや >>101,104
要件による前提をかってに決めないで話してくれ >>106
さすが勘違いバカやなwお前には一体何が見えとるんやw >>107
この要件は
名簿みたいなデータではPKを何にしたら良いでしょうか?
これ以外質問者からは提示されていない。
ウスラバカのお前こそ勝手に決めつけんな >>103
重要なのはA=1,B=2なのかA=2,B=1なのか特定できてるってこと。
そうじゃない単なるユニークなだけのキーを振っても意味ない。 >>110
おまえキチガイのふりしたいみたいやけんどわざとらしすぎていまいち萌えんのうw >>110
すまん、やはりよく分からない
特定できることにどのようなメリットがあるの? でも、もういいよ。消えてくれ。
わかったよ。ハッシュでPK最高ー! >>114
おまえなあwエセ関西弁使う奴が全部俺やと勘違いしとるやろw
さすが勘違いキングやなwww
てかお前完全に名前を主キーにして大目玉くらうタイプやなw
どんな腐った脳ミソしとったらハッシュを知らんお前をバカにしとる俺と
ハッシュを知らん発言の>>36が同一人物に見えんねんwww >>116
へーっ。まじっすか。まじはんぱねーっす。
自分、すげー尊敬しちゃうんで、何に噛み付いてんのかまじ教えてほしいっす。 >>113
特定できるとメリットがあるというより、AなのかBなのか判別できないデータじゃ意味ないだろうと。
ユニークキーが存在しない状態と変わらんじゃん。 たとえば山田太郎さんが二人いて
山田太郎Aと山田太郎Bを区別しないといけないなら
そのためのカラムを持つべき
そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
単なるユニークなだけのキーを振っておけばいい
今ここで連番を主キーにしろって主張は自然キーの候補がないならって前提だぞ
そもそも主キーが要らないだろって話は別の議論な >>120
へーっまじっすか。まじはんぱねーっす。早く何に噛み付いてるか教えてくださいよ。 とりあえずWikipediaの主キーの項を
100回読んできたら?
あとデータベーススペシャリストに合格するくらい勉強したら、良いと思うよ >>119
> 山田太郎Aと山田太郎Bを区別しないといけないなら
> そのためのカラムを持つべき
横からだが、それがサロゲートキーだろ >>123
サロゲートじゃなくて、自然キーで区別できるようなカラムが必要だろって事だろ >>123
むしろサロゲートキーは
> そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
> 単なるユニークなだけのキーを振っておけばいい
の方だろ >>124,125
なるほど住所や何かで複合主キーにしろという事か
読解力がなくて悪かった
それでも不便な自然キーを優先させようとは理由がない限り思わんが >>127
要件による
てか、何と何の複合でやろうとしてるのかすらわからんのに正解かどうかきかれてもな >>128
そもそも住所は引っ越しとか町村合併で結構頻繁に変わるし ORMの都合とかで、すべての主キーを単独の連番にってのはみたことあるな >>127
複合キーでできるならそれでいいが、ハンドリングしにくいならそのサロゲートでもいい。
ただし複合キーでもユニークに特定できないものはサロゲートにしたところでやっぱりダメ。 >>130
氏名 住所 年齢
くらいで十分じゃあないの? >>134
生年月日ならまだしも年齢とか変わっていくものをPKの一部にするとか変わってるな いいじゃん毎年発生するデータなら。健康診断結果テーブルとか。 >>136
Aさんのここ5年間の情報頂戴って言われたらどうするつもりなんだ? w やりたいこと次第で「できます」か「できません」のどっちかでしょ?
「Aさんは今何歳?」
「今年は西暦何年?」
「今年は昭和何年?」 >>134
年齢を生年月日にするにしても
同姓同名の誕生日も同じ人が
ルームシェアで同じ家に住んでる可能性がある以上
十分とはいえない 同姓同名、同じ誕生日で同じ場所に住む人が2人居ても良いと思うし、
そういう風にDBに入るなら、間違いではないし誰も困らない まだ続いてんだ、これ。
>>33すら放棄してんのに
お前らヒマなんやな w 提示されていない条件を仮定しても意味が無いと思うけど 氏名も住所も年齢もすべて値が変化するものだと気づかない時点でダメだな。 この世に変化しないものなんかないんだから主キーだって変化すればいいじゃない 「昨日?そんな昔の事は忘れた。
明日?そんな先の事は分らない」 >>146
それな
なのに>>101が連番ではダメと難癖つけたから脱線しただけだよ 「連番付けとけばいい」「連番じゃダメ」
どっちが一方かだけが提示されていない条件を仮定したかなんて決められるもんかねぇ。 「連番じゃなきゃダメ」はどこいった?
唯一の条件を問わない正解なのに >>146
回答するに当たって条件があるなら示しとかないとな
>>147
>>101は自然キー(候補キー)の必要性の問題を連番が問題だと勘違いしてるからな
>>152
>「連番じゃなきゃダメ」
そもそもそんな主張がどこにあった? それは「唯一の条件を問わない正解」なんて言っている時点で触っちゃダメな人。 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
NULCDBFZ4S DB勉強中です。
Primary Keyがないテーブルを使うと何か問題が起こりますか? テーブルが問題を起こすのではない
おまえが問題を起こすのだ 例えば同姓同名の人がいたとして
その人から自分の電話番号変わったから変更してって言われても
どちらを更新して良いか分からない(=人間)
全部書き換えようとする(=DB)
こんなことが起こる
普通は一意性を確保するために、
社員IDやら学生IDやらマイナンバーやら
他と重ならないキー情報を用意して、
それをPKにしている。 >>158
そういうのは履歴を取る設計にするのが普通なんだよ。 ■ このスレッドは過去ログ倉庫に格納されています