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

1NAME IS NULL2017/05/22(月) 16:38:31.52ID:???
語れ

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

2NAME IS NULL2017/05/22(月) 17:22:02.30ID:???
1ちょつ

3NAME IS NULL2017/05/22(月) 21:59:23.81ID:???

4NAME IS NULL2017/05/23(火) 09:06:17.88ID:1YMhep2r

5NAME IS NULL2017/05/25(木) 15:57:16.88ID:???
「複合主キーにしろ」野郎、うぜー

6NAME IS NULL2017/05/26(金) 22:01:38.57ID:???
どれのことかよくわからんけど、たぶんバカが逆切れしてるんだろうなぁ。

7NAME IS NULL2017/05/29(月) 19:54:48.57ID:???
おつ!

8NAME IS NULL2017/08/23(水) 00:45:19.03ID:???
カッペラッパー最高

9NAME IS NULL2017/08/25(金) 05:55:35.66ID:???
かっぺラッパー最高

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

11NAME IS NULL2017/10/31(火) 23:55:10.31ID:???
各数値をなにかに使うならカラムを作ればいいし
単なる文字情報なら商品名に突っ込んどけばいい

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

13NAME IS NULL2017/11/01(水) 00:12:16.37ID:???
その例だけ見ると内容量も共通

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

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

14NAME IS NULL2017/11/01(水) 07:07:56.85ID:???
>>13
>そういう分類で別途ククリだす

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

15NAME IS NULL2017/11/01(水) 14:40:35.09ID:???
>>14
「データベース 派生関係」でググって

16NAME IS NULL2017/11/01(水) 16:39:16.89ID:???
>>10
EAV

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

17NAME IS NULL2017/11/01(水) 17:15:33.60ID:???
EAVはRDB的にはほぼ例外なくアンチパターン

18NAME IS NULL2017/11/01(水) 18:05:43.74ID:???
>>17
ならより良い解答してあげて

19NAME IS NULL2017/11/01(水) 18:08:06.97ID:???
jsonで入れとけばよくね?

20NAME IS NULL2017/11/01(水) 19:18:20.98ID:???
>>17
お前みたいな低能にはそうなんだろうな...

21NAME IS NULL2017/11/01(水) 20:18:17.14ID:33PRYza3
ただの入れ物にしていく時代に逆行するパターンだなw

22NAME IS NULL2017/11/01(水) 20:46:47.43ID:???
実際価格コムだとどうしてんだろうね
基本マスタとカテゴリごとのマスタに分けてる感はあるけど

23NAME IS NULL2017/11/01(水) 21:10:54.54ID:???
>>18
派生関係

24NAME IS NULL2017/11/01(水) 21:18:05.38ID:???
>>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

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

25NAME IS NULL2017/11/01(水) 21:46:09.22ID:???
>>23
商品の種類だけテーブルを増やしていくんだな
買った商品一覧を詳細付きで取ってきたい時とかすげぇ面倒そうだ

26NAME IS NULL2017/11/01(水) 21:49:42.43ID:33PRYza3
>>25
そんな要件があると思えない。

27NAME IS NULL2017/11/01(水) 22:24:52.60ID:???
>>26
仮定の話なんで
ちなみにやる事になったらどんな実装で対応する?
後学のために知っておきたい

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

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

30NAME IS NULL2017/11/04(土) 01:17:17.38ID:???
派生マスタってじつは見たことない
たいていカラム増やすか予備カラムにまとめてぶっこんでる

31NAME IS NULL2017/11/04(土) 14:30:10.74ID:???
>>30
>予備カラムにまとめてぶっこんでる
そんなの手抜きシステムだろ

32NAME IS NULL2017/11/06(月) 15:55:51.67ID:???
>>19
そんなの有り?

33NAME IS NULL2017/12/13(水) 20:21:33.68ID:id+unZ0U
名簿みたいなデータではPKを何にしたら良いでしょうか?
電話番号だと電話が無い人もいるし。

34NAME IS NULL2017/12/13(水) 23:20:33.63ID:???
ほんとになにもないなら自分で連番振っとけばいいんじゃね

35NAME IS NULL2017/12/14(木) 10:20:17.61ID:???
まー名寄せというのは名前が付くくらい昔からある根深い問題だよな

36NAME IS NULL2017/12/14(木) 11:24:40.98ID:???
ハッシュを使うのはどうなん?

37NAME IS NULL2017/12/14(木) 22:30:10.07ID:???
同じことだよ。ハッシュで区別できるためには元のデータで区別できなきゃならん。
連番も似たようなもの。

38NAME IS NULL2017/12/15(金) 01:33:41.72ID:???
一般的なハッシュってのは
違う物に対して同じ値を生成するんだぜ
元のデータで区別できたとしても、ハッシュかけた段階で区別できなくなる可能性があるんだが
そんなものを主キーにするとか狂気のさただな

39NAME IS NULL2017/12/15(金) 09:28:07.27ID:???
>>38
>一般的なハッシュってのは
>違う物に対して同じ値を生成するんだぜ
そんなハッシュあるのかw

40NAME IS NULL2017/12/15(金) 11:30:27.39ID:???
まったくないとは言わんが
天文学的に小さいな

41NAME IS NULL2017/12/15(金) 12:21:10.16ID:???
つまりハッシュ値と連番は本質的に全く別物

42NAME IS NULL2017/12/15(金) 12:22:24.34ID:???
ハッシュ衝突は理屈上あるが
元データさえ違うなら心配する確率ではないね
とはいえ、PKに使うものじゃないと思うし連番で十分じゃないかな

43NAME IS NULL2017/12/15(金) 20:41:37.20ID:6QrkU8mN
いや元が同じだったら衝突とは言わんからw

44NAME IS NULL2017/12/15(金) 22:00:00.19ID:???
ハッシュが衝突しないとか言ってる奴はMD5みたいな奴しか知らんのか?
理屈上どころか衝突前提のハッシュなんていくらでもある

45NAME IS NULL2017/12/16(土) 07:09:25.86ID:E1KHECAF
>>44
おまえは何の勘違いをしとるんやw

46NAME IS NULL2017/12/16(土) 08:06:02.76ID:???
>>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

47NAME IS NULL2017/12/16(土) 12:38:08.13ID:???
>>46
で、それ見て何を勘違いしたんやお前はw

48NAME IS NULL2017/12/16(土) 13:13:01.80ID:???
なんだ、単なるレス古事記かよ

49NAME IS NULL2017/12/16(土) 14:38:38.92ID:???
文脈やと思うけどなぁ

50NAME IS NULL2017/12/16(土) 15:28:06.06ID:???
MD5辺りを単にハッシュと書いたアホが引っ込みつかなくなってるだけでしょ

51NAME IS NULL2017/12/16(土) 16:16:42.51ID:???
というか、MD5はハッシュだし
MD5だって衝突の可能性はあるわけだが

52NAME IS NULL2017/12/16(土) 21:36:50.89ID:E1KHECAF
おいおいMD5はハッシュ関数やぞw

53NAME IS NULL2017/12/16(土) 22:34:42.89ID:???
>>52
こんなアホな突っ込み久々に見たわ w

54NAME IS NULL2017/12/16(土) 22:56:10.26ID:E1KHECAF
>>53
やっとわかったわ
お前勘違いやなくそもそも根本的に何もわかっとらんやろw

55NAME IS NULL2017/12/16(土) 23:00:47.03ID:???
友達いないんだろうな...
まあ頑張って一人て吠えてなよ w

56NAME IS NULL2017/12/16(土) 23:06:48.97ID:E1KHECAF
>>55
いやお前がもっと頑張れやw
最初の勢いはどうしたw

57NAME IS NULL2017/12/17(日) 08:05:30.02ID:???
また吠えてるよ...
技術的な話じゃなくなると勢いあるな w

58NAME IS NULL2017/12/17(日) 12:37:49.59ID:???
>>57
え?技術的な話じゃなかったのかw
お前のその深い勘違いの根っこは一体どこにあんねんw

59NAME IS NULL2017/12/17(日) 14:02:17.70ID:???
>>58
俺は技術的な話のつもりだったけど
「勘違い」としか連呼できないアホが絡んできたってだけのこと

60NAME IS NULL2017/12/17(日) 19:39:41.63ID:GmUw4YSY
>>59
しゃあないやろ勘違いをしとるんはお前なんやからw自業自得やぞw

61NAME IS NULL2017/12/18(月) 04:59:23.82ID:???
ほらね w

62NAME IS NULL2017/12/19(火) 16:42:48.07ID:N2E99BBw
>>61
どや?そろそろ耳の火照りもひいた頃合いやろからお前の勘違いを全部さらけだしてみたらどうや?
間違ってるとこおしえたるでw

63NAME IS NULL2017/12/19(火) 19:29:26.17ID:???
>>62
> 間違ってるとこおしえたるでw
書いてからほざけよ w
どうせ頓珍漢なことしか書けないから引っ張ってるだけだろ?

64NAME IS NULL2017/12/19(火) 19:59:07.34ID:N2E99BBw
>>63
アホかとっくにしびれをきらしとるわw
いいから早くお前がハッシュを何だと思ってるのか書けよ
お前の勘違いしてるとこ教えてやるからw

65NAME IS NULL2017/12/19(火) 22:29:33.59ID:???
どうせハッシュ関数とハッシュ値は違うとか言い出すんだろ
文脈で判断しろよ、バーカ w

66NAME IS NULL2017/12/20(水) 08:25:59.98ID:LkqKP4ic
>>65
それはもう教えてやったやつやろw頓珍漢はお前やわw
てかそんなに恥かくの嫌やったらはじめから何も言うなやw
ホンマにカスやなお前w

67NAME IS NULL2017/12/20(水) 08:46:00.54ID:???
言い当てられて顔真っ赤やん w

68NAME IS NULL2017/12/20(水) 08:57:14.74ID:LkqKP4ic
>>67
また動揺してエセ関西弁うつっとるでw恥ずかしいのぉ〜w

69NAME IS NULL2017/12/20(水) 12:55:06.94ID:???
>>68
まだ粘着してるのかよ w
勘違いと言い張るならどこのレス見てどう勘違いしてると思ったのか書けよ
それが書けないからいつまでも勘違いを連呼するしかないんだろ w

70NAME IS NULL2017/12/20(水) 15:28:12.50ID:LkqKP4ic
>>69
お前なあwメッチャ自分の勘違いが気になっとるくせになんで素直に聞けんのやw
粘着しとるのお前やでw恥ずかしいのぉ〜w

71NAME IS NULL2017/12/20(水) 17:47:08.79ID:???
はいはい、具体的なにも指摘できないならいちいち絡んでくるなよ w

72NAME IS NULL2017/12/20(水) 18:50:24.06ID:LkqKP4ic
>>71
何かうやむやにしたいみたいやけど悔しくてレス返さんと気がすまんのやなw
てかそもそも誰もお前がスキル高い奴だなんて思っとらんからそんなに悔しがる意味もないんやけんどなw

73NAME IS NULL2017/12/20(水) 19:09:52.02ID:???

74NAME IS NULL2017/12/20(水) 20:03:30.28ID:???
何のためにもならない罵り合いになってるので、もうやめたら?

75NAME IS NULL2017/12/20(水) 20:29:25.30ID:LkqKP4ic
>>73
まだレス返すんかwどんだけ悔しいんやw
無理してそんな煽りレスばっかしとらんと素直にハッシュについて言えばいいやんけw
教えてやるって何度も言っとるのにw

76NAME IS NULL2017/12/20(水) 21:17:35.06ID:???
>>75
>>46
煽りしかできないアホの出る幕じゃねーよ w

77NAME IS NULL2017/12/21(木) 07:29:56.41ID:m6k27wgo
>>76
おいおい何ふりだしに戻しとるんやw
やっぱり何もわかっとらんから自分の言葉で言えんやんけw
で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
言ってみ?教えてやるからw盛大にバカにした後でやけどなwww

78NAME IS NULL2017/12/21(木) 08:07:26.64ID:???
当事者じゃないけど、うざいよ。

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

79NAME IS NULL2017/12/21(木) 10:05:36.30ID:???
データベースの用途で、グループ分けしたい時に
多対一の変換に意味があるのか?

80NAME IS NULL2017/12/21(木) 10:22:53.47ID:???
>>79
多対1じゃなくて、多対n。結合するときにないぶてきに使われるhash joinとかこの方式だよね。

81NAME IS NULL2017/12/21(木) 10:24:46.30ID:???
衝突前提じゃないハッシュは完全ハッシュとかいわれて普通はただのハッシュとは違う扱いなわけだが

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

82NAME IS NULL2017/12/21(木) 10:49:25.14ID:o/6FHTRS
今日のお弁当にはハッシュドポテトが入っています

83NAME IS NULL2017/12/21(木) 12:54:19.84ID:???
>>77
> で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
前提なしでハッシュって書いたら衝突するケースを想定するのは当たり前
そう言うことを知らなかった>>39が暴れてるだけだろ

84NAME IS NULL2017/12/21(木) 12:57:47.83ID:cIfjA39h
おやおやようやく勘違いの全貌が見えて来よったなw
後で教えたるからなw
とりあえずそれまでみんなで>>81を盛大にバカにしときw

85NAME IS NULL2017/12/21(木) 15:07:28.11ID:???
しつけえよ馬鹿

86NAME IS NULL2017/12/21(木) 15:50:38.56ID:???
で結局33の質問に対して正解は何?

87NAME IS NULL2017/12/21(木) 19:55:49.52ID:???
何の名簿か知らんけど、会社でも社員コードってのがあるんだから>>34で良いじゃん。
何揉めてんだか
>>33はそれの何が不満なんだよ。

88NAME IS NULL2017/12/21(木) 20:28:48.83ID:???
なんだこれ。

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

89NAME IS NULL2017/12/21(木) 21:31:06.81ID:???
>>86
>>87の言う通り社員番号とかのユニークキーがあればそれを使えばいい
なんにもなければ>>34の言うように連番を振るとかyymmdd+枝番とか要件によってユニークな番号を振ればいい
とりあえずハッシュバカは無視でいい w

90NAME IS NULL2017/12/21(木) 22:13:21.18ID:m6k27wgo
>>89
お?バカ少しおとなしくなったやんけw完全ハッシュはどうしたw

91NAME IS NULL2017/12/21(木) 22:40:25.61ID:???
なんだ、ただのキチガイか。

92NAME IS NULL2017/12/21(木) 22:42:05.48ID:???
安易に連番ってのもたいていバカだけどな。

93NAME IS NULL2017/12/21(木) 22:50:31.46ID:???
適切なものがなければ、作らなくて良いと思うが

94NAME IS NULL2017/12/22(金) 00:27:00.22ID:???
>>90
完全ハッシュについて調べてこいよ w

95NAME IS NULL2017/12/22(金) 00:30:58.20ID:???
>>92
もっといい解があるなら示してみてよ

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

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

96NAME IS NULL2017/12/22(金) 00:48:01.41ID:???
PKを指定しなければDB側で良きに計らってくれるんじゃ?

97NAME IS NULL2017/12/22(金) 03:07:52.25ID:???
連番を良きに計らってくれる機能は多くのDBMSで実装されてるが
PKを指定しないときによきに計らってくれるDBMSなんてみたことないわ

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

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

98NAME IS NULL2017/12/22(金) 03:28:06.91ID:???
実際プライマリーキーのないテーブルが作れるんだから
持つべしってことはないでしょ

99NAME IS NULL2017/12/22(金) 05:48:11.28ID:???
住所、氏名を複合PKにするとか

100NAME IS NULL2017/12/22(金) 07:21:44.64ID:KAIeoRcz
>>94
ええでその調子やwビビらんともう少しその勘違い晒せやへたれw

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

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

102NAME IS NULL2017/12/22(金) 08:43:18.68ID:???
>>101
> 個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
> 仕組みも必要。。
そんな当たり前のことを力説されても困るわ w

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

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

104NAME IS NULL2017/12/22(金) 11:01:13.97ID:???
>>103
俺もそう思うんだよね。
連番であってもなくてもいいけど、社員コードが社員の識別に役立てないとでも思ってんのか

105NAME IS NULL2017/12/22(金) 12:45:16.02ID:KAIeoRcz
おいおい>>101>>102は勘違いバカやぞw

106NAME IS NULL2017/12/22(金) 14:56:17.28ID:???
>>105
さっさと、PKにハッシュ値を設定すべき理由を教えてくれや

107NAME IS NULL2017/12/22(金) 18:50:39.54ID:???
>>101,104
要件による前提をかってに決めないで話してくれ

108NAME IS NULL2017/12/22(金) 19:45:03.18ID:KAIeoRcz
>>106
さすが勘違いバカやなwお前には一体何が見えとるんやw

109NAME IS NULL2017/12/22(金) 20:36:34.50ID:???
>>107
この要件は

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

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

110NAME IS NULL2017/12/22(金) 21:19:47.34ID:???
>>103
重要なのはA=1,B=2なのかA=2,B=1なのか特定できてるってこと。
そうじゃない単なるユニークなだけのキーを振っても意味ない。

111NAME IS NULL2017/12/22(金) 22:01:01.41ID:KAIeoRcz
>>110
おまえキチガイのふりしたいみたいやけんどわざとらしすぎていまいち萌えんのうw

112NAME IS NULL2017/12/22(金) 22:24:18.98ID:???
なんか変なのが居ついてるな。

113NAME IS NULL2017/12/22(金) 22:43:39.26ID:???
>>110
すまん、やはりよく分からない
特定できることにどのようなメリットがあるの?

114NAME IS NULL2017/12/22(金) 23:30:49.60ID:???
>>108

>>36
が見えてんな

115NAME IS NULL2017/12/22(金) 23:34:05.23ID:???
でも、もういいよ。消えてくれ。

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

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

117NAME IS NULL2017/12/23(土) 00:05:28.58ID:???
>>116
へーっ。まじっすか。まじはんぱねーっす。

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

118NAME IS NULL2017/12/23(土) 08:01:51.82ID:???
>>113
特定できるとメリットがあるというより、AなのかBなのか判別できないデータじゃ意味ないだろうと。
ユニークキーが存在しない状態と変わらんじゃん。

119NAME IS NULL2017/12/23(土) 11:03:50.26ID:???
たとえば山田太郎さんが二人いて
山田太郎Aと山田太郎Bを区別しないといけないなら
そのためのカラムを持つべき
そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
単なるユニークなだけのキーを振っておけばいい

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

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

120NAME IS NULL2017/12/23(土) 12:25:57.35ID:V+00B+qt
フリだけかと思ったらガチキチっぽいやんコイツw

121NAME IS NULL2017/12/23(土) 12:47:20.20ID:???
>>120
へーっまじっすか。まじはんぱねーっす。早く何に噛み付いてるか教えてくださいよ。

122NAME IS NULL2017/12/23(土) 15:22:28.35ID:???
とりあえずWikipediaの主キーの項を
100回読んできたら?
あとデータベーススペシャリストに合格するくらい勉強したら、良いと思うよ

123NAME IS NULL2017/12/25(月) 21:50:56.03ID:???
>>119
> 山田太郎Aと山田太郎Bを区別しないといけないなら
> そのためのカラムを持つべき

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

124NAME IS NULL2017/12/26(火) 02:36:23.97ID:???
>>123
サロゲートじゃなくて、自然キーで区別できるようなカラムが必要だろって事だろ

125NAME IS NULL2017/12/26(火) 07:14:12.54ID:???
>>123
むしろサロゲートキーは
> そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
> 単なるユニークなだけのキーを振っておけばいい
の方だろ

126NAME IS NULL2017/12/26(火) 08:25:45.48ID:???
>>124,125
なるほど住所や何かで複合主キーにしろという事か
読解力がなくて悪かった

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

127NAME IS NULL2017/12/26(火) 11:22:36.49ID:???
複合PKが正解?

128NAME IS NULL2017/12/26(火) 12:09:06.71ID:???
住所はダメよ
同じ住所の可能性はゼロじゃないから

129NAME IS NULL2017/12/26(火) 12:36:20.97ID:???
だから名寄せは難しいと

130NAME IS NULL2017/12/26(火) 12:59:30.71ID:???
>>127
要件による
てか、何と何の複合でやろうとしてるのかすらわからんのに正解かどうかきかれてもな

131NAME IS NULL2017/12/26(火) 13:00:41.95ID:???
>>128
そもそも住所は引っ越しとか町村合併で結構頻繁に変わるし

132NAME IS NULL2017/12/26(火) 17:44:38.01ID:???
ORMの都合とかで、すべての主キーを単独の連番にってのはみたことあるな

133NAME IS NULL2017/12/26(火) 21:57:54.33ID:???
>>127
複合キーでできるならそれでいいが、ハンドリングしにくいならそのサロゲートでもいい。
ただし複合キーでもユニークに特定できないものはサロゲートにしたところでやっぱりダメ。

134NAME IS NULL2017/12/26(火) 22:43:04.71ID:???
>>130
氏名 住所 年齢
くらいで十分じゃあないの?

135NAME IS NULL2017/12/26(火) 22:58:10.93ID:???
>>134
生年月日ならまだしも年齢とか変わっていくものをPKの一部にするとか変わってるな

136NAME IS NULL2017/12/26(火) 23:03:51.55ID:???
いいじゃん毎年発生するデータなら。健康診断結果テーブルとか。

137NAME IS NULL2017/12/26(火) 23:17:18.41ID:???
それぞれの誕生日に更新しないと

138NAME IS NULL2017/12/27(水) 08:04:26.05ID:???
>>136
Aさんのここ5年間の情報頂戴って言われたらどうするつもりなんだ? w

139NAME IS NULL2017/12/27(水) 08:12:27.79ID:???
やりたいこと次第で「できます」か「できません」のどっちかでしょ?

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

140NAME IS NULL2017/12/27(水) 10:25:59.08ID:???
お前等の自然キーにかける情熱はどこから来るんだ

141NAME IS NULL2017/12/27(水) 12:19:03.35ID:5EZatHLU
情熱てw単なる無理解やんけw

142NAME IS NULL2017/12/27(水) 12:46:24.97ID:???
>>134
年齢を生年月日にするにしても
同姓同名の誕生日も同じ人が
ルームシェアで同じ家に住んでる可能性がある以上
十分とはいえない

143NAME IS NULL2017/12/27(水) 14:18:50.57ID:???
同姓同名、同じ誕生日で同じ場所に住む人が2人居ても良いと思うし、
そういう風にDBに入るなら、間違いではないし誰も困らない

144NAME IS NULL2017/12/27(水) 14:26:47.16ID:???
そもそもの>>33の名簿という要件を満たすのそれ

145NAME IS NULL2017/12/27(水) 14:48:03.83ID:???
まだ続いてんだ、これ。
>>33すら放棄してんのに
お前らヒマなんやな w

146NAME IS NULL2017/12/27(水) 14:55:09.55ID:???
提示されていない条件を仮定しても意味が無いと思うけど

147NAME IS NULL2017/12/27(水) 19:19:41.67ID:lvRR+7xm
氏名も住所も年齢もすべて値が変化するものだと気づかない時点でダメだな。

148NAME IS NULL2017/12/27(水) 21:05:50.80ID:???
この世に変化しないものなんかないんだから主キーだって変化すればいいじゃない

149NAME IS NULL2017/12/27(水) 21:22:32.89ID:???
「昨日?そんな昔の事は忘れた。
明日?そんな先の事は分らない」

150NAME IS NULL2017/12/27(水) 21:23:22.17ID:???
>>146
それな
なのに>>101が連番ではダメと難癖つけたから脱線しただけだよ

151NAME IS NULL2017/12/27(水) 22:01:00.99ID:???
「連番付けとけばいい」「連番じゃダメ」
どっちが一方かだけが提示されていない条件を仮定したかなんて決められるもんかねぇ。

152NAME IS NULL2017/12/27(水) 22:20:42.71ID:???
「連番じゃなきゃダメ」はどこいった?
唯一の条件を問わない正解なのに

153NAME IS NULL2017/12/28(木) 17:05:27.38ID:???
>>146
回答するに当たって条件があるなら示しとかないとな

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

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

154NAME IS NULL2017/12/28(木) 17:17:30.46ID:???
それは「唯一の条件を問わない正解」なんて言っている時点で触っちゃダメな人。

155NAME IS NULL2017/12/29(金) 11:03:53.55ID:dtNZwIie
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

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

NULCDBFZ4S

156NAME IS NULL2017/12/31(日) 10:46:46.28ID:???
DB勉強中です。
Primary Keyがないテーブルを使うと何か問題が起こりますか?

157NAME IS NULL2017/12/31(日) 18:11:01.37ID:rWX012Ww
テーブルが問題を起こすのではない
おまえが問題を起こすのだ

158NAME IS NULL2017/12/31(日) 18:32:52.59ID:???
例えば同姓同名の人がいたとして
その人から自分の電話番号変わったから変更してって言われても
どちらを更新して良いか分からない(=人間)
全部書き換えようとする(=DB)
こんなことが起こる

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

159NAME IS NULL2017/12/31(日) 18:54:16.62ID:XZEULNad
>>158
そういうのは履歴を取る設計にするのが普通なんだよ。

160NAME IS NULL2017/12/31(日) 19:11:39.10ID:???
マスターは最新の状態で良いと思う
そんなに頻繁に変えるとは思わないし
履歴は履歴レコードで残せば

161NAME IS NULL2017/12/31(日) 20:03:47.84ID:???
>>159
お前は何を言ってるんだ?

162NAME IS NULL2017/12/31(日) 20:47:09.37ID:rWX012Ww
>>161
あくまで俺の予想だけど
そういうのは履歴を取る設計にするのが普通なんだよ。
って言ってるんだと思う

163NAME IS NULL2017/12/31(日) 21:23:49.22ID:???
>履歴を取る設計にするのが普通

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

164NAME IS NULL2017/12/31(日) 21:28:58.37ID:???
>>162
>>158からそれが読み取れるとしたらよほど天才か知ったかのアホとしか思えんが w

165NAME IS NULL2017/12/31(日) 21:44:37.10ID:rWX012Ww
>>164
勘違いクンはお口にチャックやでえwwww
おまえほんまにアホやなあwww

166NAME IS NULL2017/12/31(日) 21:49:45.03ID:???
またこのパターンかよ...
具体的になにも指摘できないなら絡んでこなきゃいいのに w

167NAME IS NULL2017/12/31(日) 21:57:51.30ID:rWX012Ww
>>166
絡んできたのお前やろがwww
脳ミソおかあちゃんのアナルに忘れてきたんかお前はwwwww

168NAME IS NULL2017/12/31(日) 22:16:24.92ID:???
       ,、‐'''''''''ヽ、
     /:::::;;-‐-、:::ヽ             _,,,,,,,_
      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;;;''""..   ,,:ヽ/
      \;:::   ヾ';;;;;;;;;;;::''' ...::'':: ,,::::::/\
        `''‐、、__  ̄ ̄   __,,,,、-‐"
.      //:::::/ヽ ̄ ̄ ̄ ̄ノ::::/\
.    / /:::::/  ` ̄ ̄ ̄/:::::/.  \

169NAME IS NULL2018/01/01(月) 14:02:21.33ID:KcPEsTvV
運用の経験がないとデータの変化を追えないとたいへんなのがわからないのだろう。

170NAME IS NULL2018/01/01(月) 15:50:18.06ID:???
データの変化を追えなかった、その経験談良かったらここに書いて貰えます?

171NAME IS NULL2018/01/01(月) 20:56:53.06ID:iMl2Nb4o
>>170
人的データパッチミス、プログラムの変更、追加によるバグが変なデータを作り出す。

172NAME IS NULL2018/01/01(月) 21:23:07.91ID:???
それはすごいシステムだ
そんな所利用したくない

173NAME IS NULL2018/01/01(月) 21:26:43.18ID:???
>>169
ふーん。全てのデータをinsertとフラグ列のupdateとかで更新してくってこと?

174NAME IS NULL2018/01/01(月) 22:30:38.24ID:g9MeygUN
大規模なシステムに関わったことがないと理解できないだろう

175NAME IS NULL2018/01/01(月) 22:32:52.66ID:g9MeygUN
>>173
履歴レコードの話だよ。マスタデータでもトランザクションデータでも追跡できないのは運用で困る。何がどうなったのか他人に説明できないだろうが。

176NAME IS NULL2018/01/01(月) 22:56:14.39ID:QeD1IQaw
トランザクションデータてそれ自体がログやからトランザクションなんやで
トランザクションの記録を更新すんなアホw

177NAME IS NULL2018/01/01(月) 23:08:31.05ID:g9MeygUN
UPDATEと誤解してるのか

178NAME IS NULL2018/01/01(月) 23:08:36.63ID:???
この人のシステム、怖くて触りたくない
よっぽど酷い人たちで開発してそう

179NAME IS NULL2018/01/01(月) 23:10:08.13ID:g9MeygUN
世の中には常に数百人が関わってるシステムがあるんだよ。こういうシステムだと何が起こるかわからない。

180NAME IS NULL2018/01/01(月) 23:41:53.03ID:???
>>156
履歴を記録しろと言い出す謎の勢力が襲い掛かってくる

181NAME IS NULL2018/01/01(月) 23:46:18.18ID:???
履歴が一種のイベントとして成立しているなら記録すべきだよね
(例えば売上とか)
そうじゃないなら必要性が理解できない

182NAME IS NULL2018/01/02(火) 00:05:50.83ID:???
テロリスト集団が巣くっているシステム?

183NAME IS NULL2018/01/02(火) 00:21:32.94ID:???
ここ設計スレだし
履歴が必要なら履歴とるように設計すればいい

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

184NAME IS NULL2018/01/02(火) 00:28:00.40ID:???
トランザクションって言葉のイメージする範囲が広すぎてかみ合ってないところがあるな

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

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

185NAME IS NULL2018/01/02(火) 07:23:53.00ID:???
まあ履歴が必要なシステムもあるんだろうけど>>158からいきなり履歴とか数百人が関わるシステムとか言い出してて笑える

186NAME IS NULL2018/01/08(月) 07:44:30.25ID:???
業務的な必要とSQLの仕様ってだいぶ乖離してるよな

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

187NAME IS NULL2018/01/08(月) 10:32:22.05ID:???
DMLじゃなくてDDL?
業務でどんなSQLを実行してるんだ?

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

188NAME IS NULL2018/01/24(水) 13:49:08.82ID:8ow/svL2
運用中のテーブルにカラムを追加する場合、どこに追加しますか?
末尾に追加しますか?それともデータ型やカラム名が合う場所に追加しますか?


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

189NAME IS NULL2018/01/24(水) 14:29:33.12ID:???
末尾で問題があるのかって話だよ

190NAME IS NULL2018/01/24(水) 15:20:39.28ID:8ow/svL2
>>189
問題はありません。
ですが、DB設計的に揃えるのが通常かな?と思いまして

191NAME IS NULL2018/01/24(水) 17:51:33.77ID:Hghj+DlT
>>190
そもそも間に挿入できると思っているのか?

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

192NAME IS NULL2018/01/24(水) 19:47:51.39ID:???
>列順が変わることを想定していないプログラムへの影響

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

193NAME IS NULL2018/01/24(水) 20:08:03.01ID:???
本来のリレーショナルデータベースなら, 列の順序はないのでは?
実装上で問題があるケースってあるのかな?

194NAME IS NULL2018/01/24(水) 20:09:48.86ID:???
select * を使用禁止にする

195NAME IS NULL2018/01/24(水) 20:38:49.43ID:ibathY67
【30歳で自殺】 スピードスケート代表 ≪ほら死んだ≫ マイトLーヤ「競争は殺人」 【五輪は犯罪】
http://rosie.5ch.net/test/read.cgi/liveplus/1516779817/l50

196NAME IS NULL2018/01/25(木) 16:14:20.92ID:???
たとえばカラム一覧が
id,name,address,telephone,comment,date

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

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

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

197NAME IS NULL2018/01/25(木) 16:16:11.62ID:???
修正。2番めに書いたのが無駄に削ってしまった。
id,name,address,telephone,mobilephone,comment,date

198NAME IS NULL2018/01/25(木) 16:22:13.38ID:???
それは趣味の話であって、設計の話ではない

199NAME IS NULL2018/01/25(木) 17:12:08.82ID:???
>>196
言いたいことはわかるけど、
本来リレーショナルデータベースにはそうした順序性が存在しない

200NAME IS NULL2018/01/25(木) 17:14:48.52ID:???
>>198-199
いやだから、気になりませんか?って話です。
本質とかルールがどうこうではなく、心情的な面で。

201NAME IS NULL2018/01/25(木) 17:22:02.78ID:???
気になるもクソもRDBってのは「集合」を扱うもんなの
そして集合には順序なんて概念はないの

202NAME IS NULL2018/01/25(木) 17:23:25.83ID:???
>>199
もちろん、ユーザに見せるときにはSQLではなくプログラミング言語で調整しているよ

203NAME IS NULL2018/01/25(木) 17:25:46.44ID:???
じゃ、テーブル設計書作ってるときとかphpMyAdminを利用してるときとかなんでも良いです。
順序がないけど順序を視覚化しているツールを使っている時に、
カラム名やデータ型が異なる順番で並んでると気になりませんか?

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

204NAME IS NULL2018/01/25(木) 17:30:24.66ID:???
>>203
気にはなるけどリレーショナルデータベースとはそうしたもんだ

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

205NAME IS NULL2018/01/25(木) 17:32:15.39ID:???
>>204
つまり、
>>196の要件で「携帯電話」を追加したい場合、
id,name,address,telephone,comment,date,mobilephone

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

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

207NAME IS NULL2018/01/25(木) 17:39:52.94ID:???
205はリレーショナルモデルの勉強をした方が良いのでは

208NAME IS NULL2018/01/25(木) 18:03:00.90ID:???
エクセルに切り替えれば解決

209NAME IS NULL2018/01/25(木) 18:05:52.91ID:???
順序にこだわるのは、>>203にも書いたとおり、
仕様書なり設計書なりを見た人物(自分含む)が
誤認しないか?正しく伝わるか?と思ったからです。

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

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

210NAME IS NULL2018/01/25(木) 18:08:44.34ID:???
たとえばMySQL「AFTER」というコードが有るのも、「指定位置に追加したい」
という需要があったからこそ用意されたのではないでしょうか?
そうでなければ末尾でも良いわけです。

211NAME IS NULL2018/01/25(木) 18:12:05.73ID:???
何のためにほとんどのアプリでUIが別途あると思っとる
そういう整形はフロントエンドの役目

212NAME IS NULL2018/01/25(木) 18:13:18.10ID:???
>>209
まさかと思うけど
リレーショナルデータベースをphpMyAdminで直接編集しようとしている?
(そんなはずはない、と思いたい)

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

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

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

213NAME IS NULL2018/01/25(木) 18:19:21.67ID:???
teratailを見ると以下のように回答している人がいました。

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

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

214NAME IS NULL2018/01/25(木) 18:26:41.60ID:???
>>213 DBの実装に依存する
これまでの君の主張は見た目の順序のことだから
的外れの突っ込みだぞ

215NAME IS NULL2018/01/25(木) 18:41:36.73ID:???
どうしてもやりたきゃ
別テーブル作ってそこにコピーしてリネームすれば

216NAME IS NULL2018/01/25(木) 18:54:38.23ID:???
それこそ無駄じゃないですか?

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

217NAME IS NULL2018/01/25(木) 19:13:05.84ID:???
DBに依存する処理だけど、やりたければやれば良いのだと思うよ
>>216 の動機はやはり的はずれだと思うけど
みんなが言っているようにアプリで対応するのじゃ駄目なの?

218NAME IS NULL2018/01/25(木) 19:36:37.81ID:???
まあしかし、心情的には理解できなくもない
最終更新日や削除フラグ(笑)の後ろに項目あると、ああ、あとから追加したんだなと切ない気持になる

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

219NAME IS NULL2018/01/25(木) 19:37:01.16ID:Kd6btbkD
>>216
また馬鹿が調子こいてでまかせ言ってたみたいだなw
迷惑かけてすまんのうw

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

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

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

220NAME IS NULL2018/01/25(木) 19:40:17.60ID:???
>>219
「DBに順序という概念はない」は216だけが言ってるんじゃないかな
そして標準SQLでは, 途中に列を挿入する処理は存在していないんじゃない?

221NAME IS NULL2018/01/25(木) 19:52:49.07ID:???
>>220
少なくとも質問者である私は「DBに順序という概念はない」って言っていません。
回答者がそうおっしゃるから、自身の知識を改めただけです。

222NAME IS NULL2018/01/25(木) 19:55:46.45ID:???
返信が前後しますが、>>218さんみたいな意見があれば「やっぱり切なくなりますよね」
って思うだけです。自分も切なくなるから質問したわけですし。
かといってテーブル作り直すレベルまでもとめていません。
何度も書きますが、MySQLだとカラム同士の間に挿入できるわけですから。

ググっても「こうするべき」的な情報もないので質問したわけですが、
よくわからなくなってきました。もう半端な知識で適当に行きます。
みなさん、色々ありがとうございました。

223NAME IS NULL2018/01/25(木) 19:57:33.96ID:???
>>221
>>216でそう言っているよね? 正解は>>219の通りだけど

>>199>>201>>204 も, みんな同じことを言っていると思う

224NAME IS NULL2018/01/26(金) 02:01:50.61ID:???
>>222
MySQLでしか通用しない小手先をもって「こうするべき」なんて言うやつおらんて

225NAME IS NULL2018/01/26(金) 02:15:25.24ID:???
カラム数が100近くになるというのは、そこからしてメンテ困難な状態でしょう
順序に拘る、気にするよりも設計に問題がなかったか見直した方が良いように思う

226NAME IS NULL2018/01/26(金) 02:18:38.09ID:???
>>222
カラムの順番が重要視される会社で開発しているとしよう
同僚のコードはテストを通っていたが、マージはリジェクトされてしまった
あなたが先にマージしたコードのせいで、カラムの位置が不適切になったためだ
同僚はコードを修正する事より、規約を考えたあなたを殴る事を優先するだろう

227NAME IS NULL2018/01/26(金) 02:35:15.34ID:???
>>218
心情的にはこれに同意だな

実務的な話をするなら、工程による。設計中なら、気の済むようにしたらいいけど、運用後の仕様変更だと、間に挟む為だけにテーブル作り直すとは客に説明できん..

MySQLは使ったことないけど、便利な機能があるんだな

228NAME IS NULL2018/01/26(金) 12:46:04.91ID:pxozcjcA
>>222
後から追加した列だとわかるメリットもあるけどな。

229NAME IS NULL2018/01/26(金) 12:47:20.40ID:pxozcjcA
>>227
それたぶん見かけの問題だと思う。本当にできるとしたら、内部では作り直しをやっているはず。

230NAME IS NULL2018/01/26(金) 13:23:06.33ID:???
>>225
たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
個人的に1対1の関係(必ずJOINする)ならテーブルを分ける必要ないと思います。
それは正規かと違うような。

>>226
会社で順番が重視されるとかはないかと。
ただ個人的に>>203のように思うだけなんで。

>>228
テーブル設計書に追加したカラムはどれか明記してますからね。
それでも確かに末尾に追加した方がわかりやすいとは思います。

DBはMySQL、PostgreSQL、SQLiteぐらいしか知らないので
SQL ServerとかAccessとかはどうかわかりません。
だから私の質問が「こいつ何言ってんだ?」レベルに感じたのだと思います。

231NAME IS NULL2018/01/26(金) 14:12:40.47ID:???
>>230
>たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。

ここ詳しく

232NAME IS NULL2018/01/26(金) 15:30:10.66ID:???
不動産のテーブルって言っても色々考えられるけどな
不動産販売会社の物件管理とか
賃貸マンションの入居者管理とか
あるいは資産としての不動産管理とか

233NAME IS NULL2018/01/26(金) 15:58:11.99ID:???
これも見た目だけの話になるんだろうけど、PKは先頭にないと違和感があるw

234NAME IS NULL2018/01/26(金) 16:21:41.44ID:???
カラムの見た目の位置が気になるのはSELECT *した時だけでしょ?
あとはDESCしたときか
設計書上は途中の場所に書いておいて、DB上は末尾に追加しとくでいいじゃん

あと業務要件で都度カラムが増えるのはさすがに設計がおかしい

235NAME IS NULL2018/01/26(金) 16:28:53.58ID:???
わかる

236NAME IS NULL2018/01/26(金) 20:41:14.34ID:???
実カラム名書くようなレベルの設計書が実テーブルのカラム順序と違うのはないわ

別にどんな分野でもいいけど、要件が変わってないのにカラム増えるのはさすがにおかしい
要件変更があれば当然増える事もあるだろう

237NAME IS NULL2018/01/26(金) 20:45:05.81ID:gcOPp+C3
コーダーにとっては詳細設計が要件だという驚愕の真実w
てか物理設計て言葉くらい覚えようねw

238NAME IS NULL2018/01/26(金) 21:53:37.57ID:HiY2mRrM
【株FX】 トレーダーが経済A級戦犯 ≪朝生ゴミ、経済成長は宗教≫ 世界2/3貧困を救済しろ 【NEET】
http://rosie.5ch.net/test/read.cgi/liveplus/1516959000/l50

239NAME IS NULL2018/01/30(火) 17:06:10.21ID:???
やりすぎ防犯パトロール、特定人物を尾行監視 2009年3月19日19時7分配信 ツカサネット新聞
http://headlines.yahoo.co.jp/hl?a=20090319-00000026-tsuka-soci

この記事で問題になった通称やりすぎ防パトは、創価学会と警察署が引き起こしていたようです

掻い摘んで説明すると

・創価学会は、町内会や老人会、PTA、商店会等の住民組織に関し、学会員が役員になるよう積極的に働きかける運動を
 90年代末から開始し、結果、多くの住民組織で役員が学会員という状況が生まれた

・防犯パトロールの担い手は地域の住民と住民組織で、防犯活動に関する会議や協議会には、住民組織の代表に役員が出席する為
 防犯活動や防パトに、創価学会が間接的に影響力を行使可能となった

・防パトは住民が行う為、住民が不審者や要注意人物にでっち上げられるトラブルが起きていたが
 創価学会はその緩さに目をつけ、住民組織を握っている状況を利用し、嫌がらせ対象者を不審者や要注意人物にでっち上げ
 防パトに尾行や監視、付き纏いをさせるようになった

・防パトは地元警察署との緊密な連携により行われる為、創価学会は警察署幹部を懐柔して取り込んでしまい
 不審者にでっち上げた住民への嫌がらせに署幹部を経由して警察署を加担させるようになった

・主に当該警察署勤務と考えられる創価学会員警察官を動かし、恐らく非番の日に、職権自体ないにもかかわらず
 私服警官を偽装させて管轄内を歩いて回らせ、防犯協力をお願いしますと住民に協力を求めて回り
 防犯とは名ばかりの、単なる嫌がらせを住民らに行わせた(防犯協力と称し依頼して回っていた警察官らの正体は恐らく所轄勤務の学会員警察官)
 ※これに加えて防犯要員が同様のお願いをして回る

・こうして防犯パトロールを悪用し、住民を欺いて嫌がらせをさせつつ、創価学会自体も会員らを動員し、組織的な嫌がらせを連動して行った

つまり警察署に勤務する学会員警察官、警察署幹部、創価学会が通称やりすぎ防犯パトロールの黒幕

詳細は下記スレをご覧下さい
やりすぎ防犯パトロールは創価学会と警察署の仕業だった
https://rio2016.5ch.net/test/read.cgi/bouhan/1516500769/

240NAME IS NULL2018/02/13(火) 16:59:54.49ID:???
>>230
1対”0 or 1”は積極的に分割すべきかどうか検討した方がいいぞ
特にデータ量の多いテーブルは

意図的に非正規化した場合を除けば
カラム数が100を超えるようなテーブルは
本来別途管理すべきエンティティが埋もれてることが大半

241NAME IS NULL2018/02/14(水) 03:12:25.25ID:kUpzGWTP
>>230
テーブルは意味のあるまとまりで作るのであって1:1だから、ひとつのテーブルにまとめてしまうのはかえって、同じテーブルのカラム同士の関連がわからなくなる。

242NAME IS NULL2018/02/14(水) 13:23:36.19ID:???
☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が3分の2を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

243NAME IS NULL2018/02/15(木) 19:48:19.21ID:L39WhMJw
>>241
俺はおまえ、の日本語がわか、らなくなる

244NAME IS NULL2018/02/20(火) 15:44:48.62ID:???
DBになったからといって、なにが違うの
順次編成、ISAM VSAM
DB

項目つけるだけでしょ
それと関連性

245NAME IS NULL2018/02/20(火) 17:15:24.81ID:???
>>244
扱いやすさが桁違い

Comparison of DB2 and VSAM
http://search400.techtarget.com/tip/Why-DB2-is-better-than-VSAM

246NAME IS NULL2018/02/20(火) 19:14:03.16ID:???
さすがにSAMとISAMでは違うだろ
(M)ISAMでちゃんと設計できるならそのままRDBに持っていける気はするけど

247NAME IS NULL2018/02/21(水) 23:27:11.35ID:???
順次SAMは総なめしたり
Trに振りまら混ぜたりたいへんだから違うのはわかりますが

相当まーじとか冗談言っていた時代が懐かしいw

248NAME IS NULL2018/02/21(水) 23:29:59.45ID:???
振り分け

新着レスの表示
レスを投稿する