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/05/22(月) 17:22:02.30

１ちょつ

**NAME IS NULL** · 2017/05/22(月) 21:59:23.81

乙

**NAME IS NULL** · 2017/05/23(火) 09:06:17.88

乙

**NAME IS NULL** · 2017/05/25(木) 15:57:16.88

「複合主キーにしろ」野郎、うぜー

**NAME IS NULL** · 2017/05/26(金) 22:01:38.57

どれのことかよくわからんけど、たぶんバカが逆切れしてるんだろうなぁ。

**NAME IS NULL** · 2017/05/29(月) 19:54:48.57

おつ！

**NAME IS NULL** · 2017/08/23(水) 00:45:19.03

カッペラッパー最高

**NAME IS NULL** · 2017/08/25(金) 05:55:35.66

かっぺラッパー最高

**NAME IS NULL** · 2017/10/31(火) 23:10:54.44

例えば食料品の情報をテーブルに入れるとすると
キッコーマン醤油 500ml 300円塩分8%
ネスカフェ 300g 450円
菊正宗 1.8L 1000円アルコール度数15
こんなデータだと、商品名や単価は各データに共通ですが、それ以外は共通点が有りません。
こう言う場合どんなカラムを持つテーブルを作成すべきですか?

**NAME IS NULL** · 2017/10/31(火) 23:55:10.31

各数値をなにかに使うならカラムを作ればいいし
単なる文字情報なら商品名に突っ込んどけばいい

**NAME IS NULL** · 2017/11/01(水) 00:01:10.65

>>11
＞各数値をなにかに使うならカラムを作ればいいし
商品名単価塩分アルコール度数、、、
みたいにするって事ですか?
＞単なる文字情報なら商品名に突っ込んどけばいい
それだと例えば 15<アルコール度数みたいな検索がやり辛いですよね？

**NAME IS NULL** · 2017/11/01(水) 00:12:16.37

その例だけ見ると内容量も共通

アルコール度数や塩分濃度みたいな商品の詳細情報で
精度・性能ともに高いレベルのフィルタリングが必須なら
そういう分類で別途ククリだす

価格.comの検索とかで
商品カテゴリ毎に詳細検索できる項目を別途用意してるよね
あのイメージ

**NAME IS NULL** · 2017/11/01(水) 07:07:56.85

>>13
＞そういう分類で別途ククリだす
＞
＞価格.comの検索とかで
＞商品カテゴリ毎に詳細検索できる項目を別途用意してるよね
＞あのイメージ
まだよくわからないんですが、一つのテーブルでは無くて、複数のテーブルに分けるようなイメージですか？
そうだとしても、よく分かりません。

**NAME IS NULL** · 2017/11/01(水) 14:40:35.09

>>14
「データベース派生関係」でググって

**NAME IS NULL** · 2017/11/01(水) 16:39:16.89

>>10
EAV

商品 (商品ID, 商品名, 単価)
商品属性 (商品ID, 属性名, 値, 単位)

**NAME IS NULL** · 2017/11/01(水) 17:15:33.60

EAVはRDB的にはほぼ例外なくアンチパターン

**NAME IS NULL** · 2017/11/01(水) 18:05:43.74

>>17
ならより良い解答してあげて

**NAME IS NULL** · 2017/11/01(水) 18:08:06.97

jsonで入れとけばよくね？

**NAME IS NULL** · 2017/11/01(水) 19:18:20.98

>>17
お前みたいな低能にはそうなんだろうな...

**NAME IS NULL** · 2017/11/01(水) 20:18:17.14

ただの入れ物にしていく時代に逆行するパターンだなw

**NAME IS NULL** · 2017/11/01(水) 20:46:47.43

実際価格コムだとどうしてんだろうね
基本マスタとカテゴリごとのマスタに分けてる感はあるけど

**NAME IS NULL** · 2017/11/01(水) 21:10:54.54

>>18
派生関係

**NAME IS NULL** · 2017/11/01(水) 21:18:05.38

>>22
金融商品やプロバイダは別として
家電やPC系は共通マスタと派生マスタで管理してると思うよ
パフォーマンスのための最適化は別途してるかもしれないけどね

http://kakaku.com/pc/note-pc/itemlist.aspx?pdf_Spec101=39
http://kakaku.com/kaden/lcd-tv/itemlist.aspx?pdf_Spec301=42-46

↑この辺比べるとよく分かる

**NAME IS NULL** · 2017/11/01(水) 21:46:09.22

>>23
商品の種類だけテーブルを増やしていくんだな
買った商品一覧を詳細付きで取ってきたい時とかすげぇ面倒そうだ

**NAME IS NULL** · 2017/11/01(水) 21:49:42.43

>>25
そんな要件があると思えない。

**NAME IS NULL** · 2017/11/01(水) 22:24:52.60

>>26
仮定の話なんで
ちなみにやる事になったらどんな実装で対応する？
後学のために知っておきたい

10 · 2017/11/01(水) 22:58:04.66

皆さんありがとうございました。
>>24
この価格コムの場合、
[最安価格][売れ筋][レビュー評価][クチコミ件数][登録日][スペック情報]
のようにしておいて、
[スペック情報]の部分でパソコンやテレビなどのカテゴリーの事なる製品の
情報を保管するわけですね。
そう言うのを共通マスタと派生マスタと言うんですか？
ググって勉強してみます。
疑問点があればまた質問しますので、よろしくお願いいたします。

24 · 2017/11/01(水) 23:50:31.77

自分で言っといてなんだが共通マスタと派生マスタという呼び方はあまり一般的ではないかも
>>22の書いてる基本マスタとカテゴリ別マスタみたいな呼び方のほうが多いかもね
とりあえずデータベースの派生関係とか継承でググれば解説してるサイト出てくるよ

**NAME IS NULL** · 2017/11/04(土) 01:17:17.38

派生マスタってじつは見たことない
たいていカラム増やすか予備カラムにまとめてぶっこんでる

**NAME IS NULL** · 2017/11/04(土) 14:30:10.74

>>30
>予備カラムにまとめてぶっこんでる
そんなの手抜きシステムだろ

**NAME IS NULL** · 2017/11/06(月) 15:55:51.67

>>19
そんなの有り？

**NAME IS NULL** · 2017/12/13(水) 20:21:33.68

名簿みたいなデータではPKを何にしたら良いでしょうか？
電話番号だと電話が無い人もいるし。

**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というように
個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
仕組みも必要。。