板検索:
DB設計を語るスレ 9 (1002)
まとめビュー
1
NAME IS NULL[sage]   投稿日:2015/10/13 19:46:12  ID:???.net(860)


2
NAME IS NULL[sage]   投稿日:2015/10/13 20:53:04  ID:???.net(860)
で、削除フラグはどうするべき?
コメント1件

3
NAME IS NULL[sage]   投稿日:2015/10/13 21:00:33  ID:???.net(860)
一般的な解はない。
削除フラグが最適な設計ではないにもかかわらず削除フラグを使っていることがあるというだけの話。

4
NAME IS NULL[sage]   投稿日:2015/10/13 21:10:13  ID:???.net(860)
削除フラグと同等の意味を持つカラム(例えば認証キーとか)を
同一テーブルに保つ設計も結構見るよね

5
NAME IS NULL[sage]   投稿日:2015/10/13 23:04:05  ID:???.net(860)
みんなDB設計の基礎知識ってどこで仕入れてるんだ
ミック本読んでるからミック本基準法の知識しかないけど、
中にはミック本駄目って人もいるわけだし、
そういった人はどこで知識仕入れてるんだ
コメント1件

6
NAME IS NULL[sage]   投稿日:2015/10/14 07:46:01  ID:???.net(860)
ググるしかない

7
NAME IS NULL[sage]   投稿日:2015/10/14 10:16:20  ID:???.net(860)
>5
奥野幹也の本お薦め。
Joe Celko本もお薦め。
あと、渡辺幸三の本が評判良い(業務システム向け)。
それから、SQLアンチパターンとアート・オブ・SQL。

8
NAME IS NULL[sage]   投稿日:2015/10/14 12:39:54  ID:???.net(860)
お前らが最良のアンチパターンだぜ

9
NAME IS NULL[sage]   投稿日:2015/10/14 13:52:41  ID:???.net(860)
キモイ

10
NAME IS NULL[sage]   投稿日:2015/10/14 23:20:17  ID:???.net(860)
蒸し返そう。

>2
そのフラグが概念設計上のエンティティの消滅を意味するならば、新規設計でそんなもの
導入すべきじゃない。
そうではない単なるフラグなら好きにする。ただし誤解を招く危険があるので名前は変えて
おいた方がよい。
コメント1件


11
NAME IS NULL[sage]   投稿日:2015/10/15 15:19:21  ID:???.net(860)
一概に「エンティティの消滅」といっても、大抵は「時間経過によるイベント」だったりするんですけどね

12
NAME IS NULL[sage]   投稿日:2015/10/15 17:31:07  ID:???.net(860)
それをエンティティの消滅と呼ぶことがあるのが驚きだ

13
NAME IS NULL[sage]   投稿日:2015/10/15 17:49:43  ID:???.net(860)
エンティティの消滅とは何かね

14
NAME IS NULL[sage]   投稿日:2015/10/15 17:52:47  ID:???.net(860)
エンティティとは何かね

15
NAME IS NULL[sage]   投稿日:2015/10/15 18:23:55  ID:???.net(860)
時系列で変化するデータの増減とリレーショナルモデルは相性が悪い

16
NAME IS NULL[sage]   投稿日:2015/10/15 20:13:13  ID:???.net(860)
だが使わざるを得ない

17
NAME IS NULL[sage]   投稿日:2015/10/15 22:16:13  ID:???.net(860)
仮にリレーショナルモデルが相対的に相性が悪いとして、相性がいいデータモデルって何?
コメント1件

18
NAME IS NULL[sage]   投稿日:2015/10/16 00:17:18  ID:???.net(860)
時系列変化データも普通に扱ってるから相性の悪さが分からない。
なんか設計おかしいんじゃないだろか。
コメント1件

19
NAME IS NULL[sage]   投稿日:2015/10/16 06:19:59  ID:???.net(860)
>17
亜空間恒常性変換してからリレーショナルモデルにマッピングすれば大丈夫
コメント1件

20
NAME IS NULL[sage]   投稿日:2015/10/16 08:01:54  ID:???.net(860)
>19
お前自分で言葉の意味理解してないだろw

21
NAME IS NULL[sage]   投稿日:2015/10/16 09:31:08  ID:???.net(860)
会員同士がメッセージのやりとりをする仕組みを作っています。
送受信内容は全て履歴として残す仕様なのですが、
送信先の会員が退会している場合、宛名が空欄になっています。
空欄だと誰に送信したか分からないので、どう設計すればいいか悩んでいます。

A)メッセージ送信時に宛名も保存する
B)前スレで議題に出ていたような削除フラグや履歴テーブルを使う
C)空欄のままにする
D)その他

どうするのがベターかアドバイスください。
コメント1件

22
NAME IS NULL[sage]   投稿日:2015/10/16 10:39:38  ID:???.net(860)
>18
『理論から学ぶデータベース実戦入門』 P182から引用
> リレーションは集合です。よって、各要素同士に順序はありません。し
> かし、履歴にはどちらが古いのか、新しいのかという順序が存在します。
> すなわち、履歴データをRDB上で扱うには、そもそもリレーションとして
> 表現できるかどうか、という本質的な関門が立ちはだかっているのです。

目次から引用。興味があるなら買って読んでみて。
> 第9章
>  履歴データとうまく付き合う
> 9.1 履歴データの問題点
>  世界は履歴データで溢れている
>  履歴とリレーショナルモデルの相性問題
>  履歴データの具体例
>  履歴データの何が問題になるのか
>  リレーションと時間軸の直交性
>  NULLの可能性
>  特定の行だけ意味が違う
> 9.2 履歴データに対する解決策
>  リレーションを分割する
>  最もシンプルな分割方法
>  外部キーが使用できない
>  2つのテーブルの整合性
>  重複した行を許容する
>  サロゲートキー
>  未来の価格はどうすべきか
> 9.3 履歴データのアンチパターン
>  フラグを立てる
>  Column フラグのお化け
>  手続き型として実装する
> Column テーブルを分けたときの物理的なメリット ....................................... 197
コメント8件

23
NAME IS NULL[sage]   投稿日:2015/10/16 12:23:27  ID:???.net(860)
興味あるけど高いな・・・

24
NAME IS NULL[sage]   投稿日:2015/10/16 12:34:55  ID:???.net(860)
理論的な集合そのものには順序はないが、
その要素間に順序を定義することには何の問題もない。
何のことはない、「履歴データを扱うのは難しい」ってのをちょっと格好つけて言ってるだけw
コメント3件

25
NAME IS NULL[sage]   投稿日:2015/10/16 12:35:51  ID:???.net(860)
3,000円位で高いとか・・・

26
NAME IS NULL[sage]   投稿日:2015/10/16 13:12:54  ID:???.net(860)
>24
> 理論的な集合そのものには順序はないが、
> その要素間に順序を定義することには何の問題もない。

『理論から学ぶデータベース実戦入門』 P.184から引用
> 時間軸と直交していないものは、そもそもリレーションとは呼べません。
> リレーションとは、ある時点における事実の集合だからです。リレーショ
> ンの要件を満たしていないことは、1NFになっていないとも言い換えられ
> ます。つまり、そのようなリレーションの要件を満たさないテーブルに対
> するクエリは、リレーショナルモデルから逸脱したものとなります。

というような問題が発生する場合がある。
どういう場合にそのような問題が発生し、どう対処すればいいのかなどは、本買って読んでくれ。
ステマじゃないけど、この本の著者のファンだからお薦めはする。

なお、俺がこの本から引用するのはこれで最後。
引用しすぎるとアレだし。
コメント2件

27
18[sage]   投稿日:2015/10/16 13:29:40  ID:???.net(860)
>22
ええっと、つまるところ相性は悪いが設計はできるということでいいのかな。
特別相性が悪いと思ったことはないけど、面倒といえば面倒かな。
コメント1件

28
NAME IS NULL[sage]   投稿日:2015/10/16 13:47:13  ID:???.net(860)
>27
> 特別相性が悪いと思ったことはないけど
それは多分、複雑なクエリを使ったり、LIMITや集約関数などの本来リレーショナルモデルに
対する演算ではないものを使ったり、外部結合してIS NOT NULLで拾ったりするのが前提に
なってるからじゃないかな。

そういうの無しでクエリが発行できる、正規化されたきれいなリレーショナルモデルとして
設計できない(場合がある)というのが「問題」。

29
NAME IS NULL[sage]   投稿日:2015/10/16 19:23:45  ID:???.net(860)
>26
だからその本の作者がバカなんだろ。
俺達が扱っているのは集合ではない。
テーブルだ。

30
NAME IS NULL[sage]   投稿日:2015/10/16 20:03:25  ID:???.net(860)
http://www.slideshare.net/nippondanji/db-engineerstudyanim
スライド公開されてた、ありがてぇ

履歴については銀の弾丸はないよという単純な話に読めるが
本では違うのかな?

31
NAME IS NULL[sage]   投稿日:2015/10/16 20:17:43  ID:???.net(860)
>21
単に空白が嫌でなにか適当に入ってりゃいい
って言うなら
> A)メッセージ送信時に宛名も保存する
でいいだろ

32
NAME IS NULL[sage]   投稿日:2015/10/16 21:26:14  ID:???.net(860)
>22
それは単にレコードの順序で時系列を表現することはできないって言ってるだけだろ。
もしそれだけで時系列データが苦手ってことになるなら、順序関係や大小関係を持った情報の表現
全部苦手ってことになるわ。
そこは、テーブルを「Excelの表みたいなもの」って思っちゃうような初心者に向けた説明だろ。実際、
orderを指定しないとinsert順に出てくるように見える場合もあるからそう思い込む初心者もいる。

と思ったら

>26
> リレーションとは、ある時点における事実の集合だからです。

この著者がおかしいような気がしてきた。
コメント3件

33
NAME IS NULL[sage]   投稿日:2015/10/16 22:35:33  ID:???.net(860)
そもそも履歴を扱うことの難しさは、時間軸という
ある意味得体の知れないパラメーターを、その他の次元と同列に
扱わなければいけない事に由来する物であり、
それは、集合論だから特別に難しいという事ではなく
現在の科学的知識において普遍的に難しい問題なのである。

そうとは言え、システム要件という適用範囲を限定された檻の中では、
時間軸という得体の知れない物でも容易に表現出来る事はある。

つまり、リレーショナルモデルという原理主義に固執しすぎると
見える物でも見えなくなっちゃうよ!っつー事なんだ。
エンジニアだったら理論より実践だろ。

34
NAME IS NULL[sage]   投稿日:2015/10/16 23:32:16  ID:???.net(860)
以上、他の人には見えないものが見える人のご高説でした。

35
NAME IS NULL[sage]   投稿日:2015/10/16 23:56:22  ID:???.net(860)
>32
抜粋方法がヘタだっただけじゃないかなきっと。
著者みてないかもしれないけど奥野さんだよ。

36
NAME IS NULL[sage]   投稿日:2015/10/17 05:50:58  ID:???.net(860)
>32
> リレーションとは、ある時点における事実の集合だからです。

別にそれはおかしいとは思わんけどな
あんたが言うように、単に
> 順序関係や大小関係を持った情報
なんだし

37
NAME IS NULL[sage]   投稿日:2015/10/17 08:03:18  ID:???.net(860)
「ある時点における(その過去も含む)事実」ということならまぁ違和感はないな。
ただしその場合、「未来以外全部」ということだから別にリレーションに限った話じゃないけどな。

38
NAME IS NULL[sage]   投稿日:2015/10/17 08:28:49  ID:???.net(860)
履歴扱うのってSQL的にも難しくならないか?

例えば会員制の掲示板があったとして、誰がどのレスを投稿したかを知りたい時に、

レステーブル
└ユーザーテーブル

として結合関係になるわけだけど、退会したユーザーにも対応するためには

レステーブル
└ユーザーテーブル
└ユーザー履歴テーブル

みたいにしなきゃいけない。(またはサブクエリ使うとか)

こんな事になるなら、削除フラグつけて参照させた方が
よほど便利で分かりやすく、パフォーマンス的にも良くなると思うんだよなぁ
コメント2件

39
NAME IS NULL[sage]   投稿日:2015/10/17 09:04:40  ID:???.net(860)
>38
ユーザーテーブルとユーザー履歴テーブルって何者?
何がどういう理由でmust beなの?
SQL持ち出すならDDLとDMLで説明してくれ
コメント1件

40
NAME IS NULL[sage]   投稿日:2015/10/17 09:17:44  ID:???.net(860)
>39
今まで履歴テーブルの話してたんだから、
1から10まで説明しなくても理解してくれよ・・・

41
NAME IS NULL[sage]   投稿日:2015/10/17 10:00:08  ID:???.net(860)
>38
最初のテーブル構成で退会時に対応できないというのは、暗黙にユーザーエンティティの寿命を
「入会から退会まで」としているからだな。

 ユーザーテーブル(現入会者のみ)

これに削除フラグを追加して

 ユーザーテーブル(現入会者のみ) + 論理削除

とするのは、エンティティの寿命が曖昧になるので概念設計としてはよくない。
ここはエンティティの意味を変更して

 ユーザーテーブル(入会したことがある者) + 状態(在籍|退会)

とすべき。
(結果的にテーブルの形としてはほとんど同じになるとしても)

そのうえで、前スレで挙がったように退会時に削除しなければならない情報があるのであれば、
それらを分離して

 ユーザーテーブル(入会したことがある者)
 └会員情報(退会時に削除)

とすればよい。
コメント4件

42
NAME IS NULL[sage]   投稿日:2015/10/17 19:13:20  ID:???.net(860)
俺も>41に同意なんだけど
削除フラグの話を続けたい人って、こんな単純な解決方法にも反論はないの?

43
NAME IS NULL[sage]   投稿日:2015/10/17 19:53:32  ID:???.net(860)
えっと、削除フラグ≠状態 って認識でいいの?
実際の使い方を想定すると、どっちも同じような意味合いに感じるんだけど。

44
NAME IS NULL[sage]   投稿日:2015/10/17 19:56:14  ID:???.net(860)
ちょっと書き方が悪かった。
ユーザーテーブルに「状態」ってカラムを用意して、
これが0なら停止、1なら有効、2なら退会
っていう意味を与えても問題ない(=削除フラグとは違う)ってこと?

俺は昔からこういうやり方してたんだけど、
削除フラグと同じじゃないか?と感じて、違う方法を模索してるんだが。
コメント2件

45
NAME IS NULL[sage]   投稿日:2015/10/17 20:04:14  ID:???.net(860)
あんたら、いっその事削除フラグ専用のスレでも建てたらどうだ?

46
NAME IS NULL[sage]   投稿日:2015/10/17 20:36:52  ID:???.net(860)
永続化させるデータに状態を持たせないという事は
参照が必要になった時に必ず状態の再計算が必要になる訳で
それにかかるコストは結局、データを永続化させたいという要求とは
相反する結果になるんじゃないか?

47
NAME IS NULL[sage]   投稿日:2015/10/17 20:53:35  ID:???.net(860)
計算によって状態が決定できるなら、その状態を計算元情報以外に(フラグとして)持つのは
基本的には間違ってる
パフォーマンスのための正規化崩しとしては最も見られるパターンではあるけどな

永続化させるデータに状態を持たせるかどうかは、そのデータが状態を持ってるかどうか
つまり何度も言われるように要件次第

異なる状態のデータをどう格納するかがテーブル設計
フラグ付けたり、テーブルを移動させたり、実装方法はいろいろ
そこだけ見て良し悪しとか判断できない

48
NAME IS NULL[sage]   投稿日:2015/10/17 22:17:32  ID:???.net(860)
>44
論理削除の否定は、モデルとテーブル設計の間にギャップがあるのは良くないって話だからねぇ。
>44のDBで概念設計上も「退会したユーザー」が存在し得るんであればそれで問題ないかと。
逆に言うと、テーブル設計だけ見て「これは削除フラグだからやめたほうが良い」なんてことも
言えない。
要は>10
コメント2件

49
NAME IS NULL[sage]   投稿日:2015/10/18 08:30:08  ID:???.net(860)
>48
「退会したユーザーは存在させたくない」
けど
「名前は参照させたい」

って場合はどうなるの?
やっぱり履歴テーブルに移行させて、そこから参照するの?

割りとこういう要件って多いと思うんだよ。
「ユーザーデータ全てを残したくはないが、名前ぐらいは残して、
 そのユーザーが投稿(利用)した別テーブルと参照させたい」って。
コメント12件

50
NAME IS NULL[sage]   投稿日:2015/10/18 08:48:44  ID:???.net(860)
話がループしてるぞ。そのへんのやり方は>41に書いてある。
読んでも理解できないならあきらめろ。
コメント1件

51
NAME IS NULL[sage]   投稿日:2015/10/18 09:11:25  ID:???.net(860)
でもでもだって厨が多いんだよ

52
NAME IS NULL[sage]   投稿日:2015/10/18 09:27:29  ID:???.net(860)
>「退会したユーザーは存在させたくない」

そもそもここからね。
「ユーザー」と名前がつくテーブルにレコードを残しておきたくないという
気分的なものなのか、あるいは何か具体的な要件を想定しているのか。
たぶん本人もちゃんと考えていないんだろう。
コメント1件

53
NAME IS NULL[sage]   投稿日:2015/10/18 10:54:20  ID:???.net(860)
個人情報保護の観点に立つなら、至極まっとうな措置だぞ
コメント2件

54
NAME IS NULL[sage]   投稿日:2015/10/18 11:14:56  ID:???.net(860)
おまえは

>「退会したユーザーは存在させたくない」

これを勝手に個人情報の削除のことだと思い込んで的外れな設計しちゃうタイプだな。
コメント1件

55
NAME IS NULL[sage]   投稿日:2015/10/18 12:00:54  ID:???.net(860)
削除フラグの要否について語るスレ [転載禁止]©2ch.net
削除フラグの要否について語るスレ

専用スレを立てるに値するぐらい話題が盛り上がっているので、立てました

56
NAME IS NULL[sage]   投稿日:2015/10/18 12:23:16  ID:???.net(860)
話題が盛り上がるたびに専スレ立ててたら本スレで話す内容がなくなるが。
てか、今だって他の話題なんかねーだろ。

57
NAME IS NULL[sage]   投稿日:2015/10/18 13:03:50  ID:???.net(860)
>52>54
じゃ、何が個人情報には当たらないんだ?
ユーザー情報(メールアドレス、電話番号、住所等)は個人情報だから、
ユーザーテーブルに残したくないってのは、至極まっとうな考え方だろ。

批判だけして「こうするorこう考えてる」って意見を出せないじゃん。
コメント6件

58
NAME IS NULL[sage]   投稿日:2015/10/18 13:37:39  ID:???.net(860)
ユーザーから個人情報の削除要求来たらどうするんだ?嘘つくのか?
コメント1件

59
NAME IS NULL[sage]   投稿日:2015/10/18 14:03:11  ID:???.net(860)
>57
おまえ的外れすぎ。個人情報が何かって話をしているわけじゃない。
たとえば「退会したユーザーの電話番号は削除する」という具体的な要件があれば

「退会したユーザーは存在させたくない」

じゃなくて

「電話番号が削除された退会したユーザーが存在する」

でいいわけだ。それなら>49みたいな疑問は生じないはず。
コメント2件

60
NAME IS NULL[sage]   投稿日:2015/10/18 14:13:18  ID:???.net(860)
退会時に個人情報を消したい
ユーザーの存在は消したくない

どこに悩む要素があるんだ

61
NAME IS NULL[sage]   投稿日:2015/10/18 15:15:39  ID:???.net(860)
>59
電話番号も含めて、個人情報は全部消さないと駄目だよ
コメント1件

62
NAME IS NULL[sage]   投稿日:2015/10/18 15:20:43  ID:???.net(860)
この頓珍漢ぶりはBTS君のような気がしてきた。

63
NAME IS NULL[sage]   投稿日:2015/10/18 15:28:54  ID:???.net(860)
最初からずっとBTSさんだろ
「常識」が「まっとう」に変わったけどw

64
NAME IS NULL[sage]   投稿日:2015/10/18 16:04:26  ID:???.net(860)
削除フラグの話は以降はこちらで

削除フラグの要否について語るスレ

65
NAME IS NULL[sage]   投稿日:2015/10/18 18:28:20  ID:???.net(860)
>59
だから、その場合はユーザーテーブルにならないわけだろ?
”電話番号が削除された退会したユーザーが存在する”テーブルが必要なわけだ。

それに関しては何も思わないのか?
コメント3件

66
NAME IS NULL[sage]   投稿日:2015/10/18 18:43:44  ID:???.net(860)
www
ここまでくると香ばしさを通り越して清々しいな

67
NAME IS NULL[sage]   投稿日:2015/10/18 19:41:16  ID:???.net(860)
それこそユーザの定義次第なんだが
個人情報が削除されようが、退会されようが、ユーザーはユーザーなんだから
ユーザーテーブルに存在して何の疑問があるんだか

俺の思うユーザーの定義以外はあり得ないって思考から離れられない人なんだろうな
コメント3件

68
NAME IS NULL[sage]   投稿日:2015/10/18 19:53:28  ID:???.net(860)
"ログイン中のユーザーが存在するテーブル"
"ログアウトしたユーザーが存在するテーブル"
"チケットを発行したユーザーが存在するテーブル"
"チケットの担当者のユーザーが存在するテーブル"
"チケットを発行してかつ担当者になってるユーザーが存在するテーブル"
"今お風呂に入っているユーザーが存在するテーブル"
"明日早いから早めに寝てしまったユーザーが存在するテーブル"
..........

という事なのかな?

69
NAME IS NULL[sage]   投稿日:2015/10/18 20:57:20  ID:???.net(860)
>67
まぁ待て。頭ごなしに「お前はこうだ!」って決めつけたり、煽るのをまず直そうや。
あんたが人の意見を柔軟に受け入れられない奴を恥ずかしいと感じるなら、
自分もそれと同じような言動は控えよう。

んで、確実に俺以外の人間も「個人情報は削除するべきでは?」
って答えてるわけだが、それは見ないようにしてるのかい?
そこの疑問に対して「おかしいのでは?」って意見を頭ごなしに否定する以外の
論理的で冷静な意見が聞きたいなぁ。
コメント2件

70
NAME IS NULL[sage]   投稿日:2015/10/18 21:02:15  ID:???.net(860)
ああそうそう、自演だと思われないために言っておくが、
>53>58>61
は違う人だよ。
複数人が「個人情報は削除するべきでは?」って意見しているわけで、
一方的に頓珍漢な事を言っているわけではないというのは理解してくれ。
コメント1件

71
NAME IS NULL[sage]   投稿日:2015/10/18 21:08:16  ID:???.net(860)
また訳の分からない事を言い出した
なんなのコイツ

72
NAME IS NULL[sage]   投稿日:2015/10/18 21:17:46  ID:???.net(860)
だからそれだって

73
NAME IS NULL[sage]   投稿日:2015/10/18 21:41:07  ID:???.net(860)
個人情報を語るスレが必要そうだな

74
NAME IS NULL[]   投稿日:2015/10/18 21:49:26  ID:B8dX4Ff1.net
>70
>53,58,61はどれも同じ文体で1行カキコも共通している
つまり「個人情報は削除するべきでは?」って意見してるのは
2名だけって事でいいのかな?

自分は「要件しだい」だと考えるよ
もしもオンラインショッピングのように利用者の住所や電話番号が記録されるシステムであれば、
個人情報の流出は社会問題に直結するから確実に削除すべき
しかしBTS(バグ追跡システム)であれば、ほとんどのケースで削除する必要はない

ああそうそう、自演だと思われないために言っておくが、自分は>67とは違う人だよ
複数人が「個人情報は削除するべきという断定はおかしいのでは?」って意見しているわけで、
一方的に頓珍漢な事を言っているわけではないというのは理解してくれ

75
NAME IS NULL[sage]   投稿日:2015/10/18 22:01:28  ID:???.net(860)
健全でない言葉が含まれているため表示しません 内容を確認する

76
NAME IS NULL[sage]   投稿日:2015/10/18 22:11:10  ID:???.net(860)
>69
なんでこう話が捻じ曲がるかねぇ。
他の人は「削除すべきもの」を削除できるようにする方法を説明している。
あんたのシステムで「個人情報」が「削除すべきもの」なのであればそうすればいいだけ。
「個人情報は削除するべきでは?」って聞かれても「すれば?」としか言いようがない。

77
NAME IS NULL[sage]   投稿日:2015/10/18 22:50:26  ID:???.net(860)
名前は個人情報だから消さないといけない
名前が消えるとカオスになって困る

どうすればいいんだ!!!って駄々こねてるだけ?
コメント1件

78
67[sage]   投稿日:2015/10/18 22:59:27  ID:???.net(860)
>69
一応言っとくが、>67>65に対するレスだけど
論理的で冷静な意見を言っといてやる

>それは見ないようにしてるのかい?
どこに、個人情報が削除するべきかどうかなんてエクスキューズがあるのかね

>そこの疑問に対して「おかしいのでは?」って意見を頭ごなしに否定する
意味が分からん
おかしいって意見ってのは、個人情報を削除するのがおかしいって?それとも個人情報を削除しないのがおかしいって?
どっちにしても、それを否定も肯定もしてないけど

79
NAME IS NULL[sage]   投稿日:2015/10/19 00:09:02  ID:???.net(860)
「りんごが5個とみかんが3個あります。足したらいくつでしょう?」という問題がわからないというので
足し算を教えてやったら、「バナナだったらどうなんだ?」と言われた。
「バナナは関係ない」と言ったら「バナナを否定するのか」と言われた。
そんな気分。

80
NAME IS NULL[sage]   投稿日:2015/10/19 00:23:58  ID:???.net(860)
話をずらすのがうまいのか意識せずにずれてしまうのか。
個人情報は削除する。
ユーザは削除しない。
削除フラグは使わない。
という要件を満たす対応案はもう出てるよな。
何が気に入らないんだ?
コメント1件

81
NAME IS NULL[sage]   投稿日:2015/10/19 08:16:54  ID:???.net(860)
>77
それを「ダダ」って捉えるから荒れるんじゃないか?

実際にそのエクスキューズは出てくるだろ。

・個人情報は削除したい
・ただ、その個人情報は他のテーブルから参照されている
 削除すると参照元の名前欄などが空欄になる

この問題について「なぜ?」という質問に対して
「タダこねてるだけ」ってのはおかしいと思うんだよなぁ。

てか、お前らの投稿見てて無理に煽ったり貶したり馬鹿にする意味が分からん。
全く生産性がないだろうし、自分も嫌な気になるだろ。
コメント2件

82
NAME IS NULL[sage]   投稿日:2015/10/19 08:19:37  ID:???.net(860)
>80
馬鹿な俺に教えてくれ。

・個人情報は削除する
→「個人情報が入ってるテーブルの対象レコードを削除すればいいよね」

・ユーザは削除しない
→「ファ!?個人情報を削除するんじゃないの?」

・削除フラグは使わない
→「それは分かるし対案も出てる。でも、上記2つは相対しないのでは?」

この疑問を持つこと自体駄目か?ダダか?

83
NAME IS NULL[sage]   投稿日:2015/10/19 09:00:21  ID:???.net(860)
個人情報とユーザーは別物じゃないの?
個人情報は個人を特定できるものだから、電話番号とか住所は消して名前(ユーザー)だけ残す
名前だけでは個人を特定できないので残しておいても問題は無さそうだけど
コメント2件

84
NAME IS NULL[sage]   投稿日:2015/10/19 09:15:04  ID:???.net(860)
>83
消すってどうやって?UPDATEでNULLにするのか?
あるいは、そもそもテーブルを分けてるのか?
コメント1件

85
NAME IS NULL[sage]   投稿日:2015/10/19 09:19:26  ID:???.net(860)
それは要件によって変わりそうだけど
その辺のネトゲとかであるメアドあればアカウント復帰できるやつなら
別テーブルに移動してるんだろうね
復帰したら元のテーブルに戻す感じで

一概にこうしろという答えはないと思うよ
とにかく個人を特定できないようにすればいいわけだし
コメント1件

86
NAME IS NULL[sage]   投稿日:2015/10/19 09:30:29  ID:???.net(860)
>85
ネトゲってそういうの多いね。モバゲーとか即復活できる。
あれって、削除フラグじゃないのか?って思うんだけど、
履歴テーブルに移してるのかなあ
コメント1件

87
NAME IS NULL[sage]   投稿日:2015/10/19 09:32:40  ID:???.net(860)
削除フラグかもしれんけど確認できないのでなんとも言えん
企業・顧客によって個人情報の扱いなんてコロッと変わるし、
DBAのスキル次第でも変わりそうだけどね

88
NAME IS NULL[sage]   投稿日:2015/10/19 12:33:51  ID:???.net(860)
>81
答が出てる事に意味不明な問いかけをするから荒れるんじゃないだろうか?

という自分の誤りの可能性について考えてみた事はあるかね?
コメント1件

89
NAME IS NULL[sage]   投稿日:2015/10/19 12:37:43  ID:???.net(860)
>88
答えが出てねーじゃん。
新たに「こういう時はどうするの?」
って聞いても受け入れないんだから。
コメント2件

90
NAME IS NULL[sage]   投稿日:2015/10/19 12:39:09  ID:???.net(860)
>81
むしろ馬鹿な俺に教えてくれ。

> この問題について「なぜ?」という質問
その質問を詳しく教えて欲しい。
コメント1件

91
NAME IS NULL[sage]   投稿日:2015/10/19 12:43:28  ID:???.net(860)
>89
新たでないという可能性について考えた事はないのかね?
コメント1件

92
NAME IS NULL[sage]   投稿日:2015/10/19 12:59:27  ID:???.net(860)
同じこと繰り返してるようにしか見えない状態

93
NAME IS NULL[sage]   投稿日:2015/10/19 13:04:35  ID:???.net(860)
>83
名前も個人情報だから、消さないと駄目
コメント1件

94
NAME IS NULL[sage]   投稿日:2015/10/19 13:06:00  ID:???.net(860)
>89
質問したいなら、「こういうとき」を、DBのスキーマと要求仕様を添えて質問しろ。
コメント1件

95
NAME IS NULL[sage]   投稿日:2015/10/19 13:09:22  ID:???.net(860)
>86
退会した後、同じメールアドレスで新規に登録してみると分かる。
これができないと言うことは、
おそらく移動はしていないんだろうな。
コメント1件

96
NAME IS NULL[sage]   投稿日:2015/10/19 13:10:55  ID:???.net(860)
>95
想像力なさすぎというか、設計経験なさすぎというか。
コメント1件

97
NAME IS NULL[sage]   投稿日:2015/10/19 13:11:50  ID:???.net(860)
>93
名前だけでは個人特定できないでしょ
コメント1件

98
NAME IS NULL[sage]   投稿日:2015/10/19 13:13:45  ID:???.net(860)
>90
少なくとも>49>57>65は俺がレスした。

>91-92
その「自分の中では解決している。知らない人がいるのは知らん」
って価値観はなんなの?みんなで掲示板使ってんじゃん。

>94
>49だと足りないならどこまで説明すれば納得するんだ?
1から10までは説明できないと言ったら、俺が悪くなるのか?
コメント3件

99
NAME IS NULL[sage]   投稿日:2015/10/19 13:21:37  ID:???.net(860)
>97
個人情報の保護に関する法律の定義では、生存する個人に関する情報であって、
当該情報に含まれる氏名、生年月日その他の記述等により「特定の個人を識別
することができるもの」(他の情報と容易に照合することができ、それにより
特定の個人を識別することができることとなるもの=例えば学籍番号など=を含
む)をいう。つまり、上記に該当しない情報であっても、「勤務場所」や「生
年月日」といった「複数の情報の組み合わせ」により、「その個人を特定し得
る情報」も個人情報である。

100
NAME IS NULL[sage]   投稿日:2015/10/19 13:25:07  ID:???.net(860)
>96
書いてあるとおり、
ネトゲに登録し、退会し、同じアドレスで新規登録してみ
想像力でも設計系経験でもなく、単なる事実なんだけど。
こもってないでたまには外に出てみたら?
コメント1件

101
NAME IS NULL[sage]   投稿日:2015/10/19 13:35:28  ID:???.net(860)
>100
> おそらく移動はしていないんだろうな。
これが
> 想像力なさすぎというか、設計経験なさすぎというか。
って言ってるんだよ。
コメント1件

102
NAME IS NULL[sage]   投稿日:2015/10/19 13:39:22  ID:???.net(860)
>98
> 1から10までは説明できないと言ったら、俺が悪くなるのか?
お前も、設計経験なさすぎというか。
他人が判断できるだけの最小限の情報を示すこともできないんだろ?

他人が判断できないのはお前のせい。なのでお前が悪い。

103
NAME IS NULL[sage]   投稿日:2015/10/19 13:41:12  ID:???.net(860)
ちなみに、>49>57>65でも全然足りない。

あと、要求仕様と実装詳細の区別はちゃんと付いてるのか?

104
NAME IS NULL[sage]   投稿日:2015/10/19 13:42:24  ID:???.net(860)

105
NAME IS NULL[sage]   投稿日:2015/10/19 13:43:00  ID:???.net(860)
>101-103
お前、さっきから誰にでも噛み付いてるなw
何か嫌なことあった?たまには散歩でもしてみたら?
コメント1件

106
NAME IS NULL[sage]   投稿日:2015/10/19 13:46:20  ID:???.net(860)
>105
誰にでもって、アホ二人にだよ。
一人なのかもしれんが。
コメント1件

107
NAME IS NULL[sage]   投稿日:2015/10/19 13:51:13  ID:???.net(860)
>106
噛み付いてるのは認めるのなw

108
NAME IS NULL[sage]   投稿日:2015/10/19 13:54:33  ID:???.net(860)
アホにはちゃんとお前アホって言ってやらんとな。
前スレから延々この話題が続いてるのは、アホどものせいだろ。

109
NAME IS NULL[sage]   投稿日:2015/10/19 14:00:27  ID:???.net(860)
まず自分に言い聞かせような
コメント1件

110
NAME IS NULL[sage]   投稿日:2015/10/19 14:04:00  ID:???.net(860)
>109
そういうメタ議論はやめようぜ。

111
NAME IS NULL[sage]   投稿日:2015/10/19 14:06:45  ID:???.net(860)
>98
> その「自分の中では解決している。知らない人がいるのは知らん」
> って価値観はなんなの?みんなで掲示板使ってんじゃん。
最近こういう奴多いね。
俺はわからない、俺がわかるまでお前ら説明しろ、そうする責任がお前らにはある、って奴。

112
NAME IS NULL[sage]   投稿日:2015/10/19 14:11:53  ID:???.net(860)
説明できないなら、しなくていいんじゃない?
コメント1件

113
NAME IS NULL[sage]   投稿日:2015/10/19 14:23:33  ID:???.net(860)
×説明できない
◯説明する必要がない

114
NAME IS NULL[sage]   投稿日:2015/10/19 14:32:29  ID:???.net(860)
>112
こういう奴も多くてうんざりする。

お前らが説明しないのは、説明できないからって奴。
コメント1件

115
NAME IS NULL[sage]   投稿日:2015/10/19 14:37:15  ID:???.net(860)
>84
> 消すってどうやって?UPDATEでNULLにするのか?
> あるいは、そもそもテーブルを分けてるのか?

おいおい、いまさら何言ってるんだよ・・・
コメント1件

116
NAME IS NULL[sage]   投稿日:2015/10/19 14:38:48  ID:???.net(860)
個人情報を削除すべきかどうかは、

要件次第

117
NAME IS NULL[sage]   投稿日:2015/10/19 14:42:29  ID:???.net(860)
>115
最近こういう奴も多いよね。
一部だけ切り取ってハッキリと何が駄目なの言わない奴。
とにかく全部否定すればお前バカ・俺すげー出来るっって思ってるの
コメント2件

118
NAME IS NULL[sage]   投稿日:2015/10/19 14:44:37  ID:???.net(860)
>114
それなら無視で良いんじゃないか?
わざわ馬鹿にする意味が分からん。

119
NAME IS NULL[sage]   投稿日:2015/10/19 14:48:31  ID:???.net(860)
要件無視してやらかすDBAがいそうなスレはここですか?

120
NAME IS NULL[sage]   投稿日:2015/10/19 14:55:49  ID:???.net(860)
>98
>49の疑問に対する答えが出てないってことか。

ユーザは削除するが名前は削除しないって場合、それはユーザの削除ではないということは分かる?
ユーザではない何かを削除するという行為になるわけだから、
その削除対象となる情報をユーザから切り離せばいいじゃん?

というのが前スレでも、このスレでも繰り返し出てる答えだけど、
それでも
> その「自分の中では解決している。知らない人がいるのは知らん」
> って価値観はなんなの?みんなで掲示板使ってんじゃん。
という考えが出るということは、その回答では不満だということだよね。

質問に不備があるんじゃないか?
コメント3件

121
NAME IS NULL[sage]   投稿日:2015/10/19 15:01:15  ID:???.net(860)
>117
さすがに今の流れでそれは逆効果だよ。ほんとにいまさらだもん。
過去ログ読めよと。

122
NAME IS NULL[sage]   投稿日:2015/10/19 15:03:37  ID:???.net(860)
0から教えないと伝わらないような人は素直で勉強不足・経験不足では

123
120[sage]   投稿日:2015/10/19 15:03:59  ID:???.net(860)
あ、念のため。
ユーザ名はユーザ情報に含むべきという前提で書いたので、そのつもりで読んでもらえればと。

124
NAME IS NULL[sage]   投稿日:2015/10/19 15:13:38  ID:???.net(860)
>120
>ユーザは削除するが名前は削除しないって場合、それはユーザの削除ではないということは分かる?

とするとね、>57こっちの疑問に行き着くのよ。
ちゃんとこのスレ見てたら分かると思ったんだが。
ま、それは良いや。また言い争いになりそうなんで折れる。

>その削除対象となる情報をユーザから切り離せばいいじゃん?

つまり、

・ユーザー情報(ユーザ名、パスワード)と個人情報(名前、住所、電話番号など)に分ける
のが正しい設計って解釈でいいの?これも前スレで答え見つからないわけだが。
もし答えてるならレス番教えてくれ。もう一度見返すから。
コメント7件

125
124[sage]   投稿日:2015/10/19 15:15:08  ID:???.net(860)
あ、念のため。
1対1でも場合によってはテーブルを分ける設計があるって理解してるんで。

126
NAME IS NULL[sage]   投稿日:2015/10/19 15:20:28  ID:???.net(860)
>124
> とするとね、>57こっちの疑問に行き着くのよ。

>57
> じゃ、何が個人情報には当たらないんだ?

この流れ、お前に中では筋が通ってるのかも知れないが、第三者にはさっぱりわからん流れなんだが。

127
120[sage]   投稿日:2015/10/19 15:20:58  ID:???.net(860)
>124
ユーザ削除時に一部(今回なら名前だね)を残し、他は削除するという場合にどういう設計をするのかという話と、
何を個人情報とするかという話は関係ない。
一見関係ありそうに思えるかもしれないけれど、設計手法には影響を与えないことは分かるかな。
どっちのテーブルに置くかというそれだけの話。

> もし答えてるならレス番教えてくれ。もう一度見返すから。
このスレだと>41が関連レスしてくれてるけど、前スレでレスしたやつはこれ。

DB設計を語るスレ 8 [転載禁止](c)2ch.net
DB設計を語るスレ 8

887 名前:NAME IS NULL[sage] 投稿日:2015/10/08(木) 12:37:37.91 ID:???
なんだよユーザ名残さないといけないのかよ。
そんな隠し要件あるなら、
ユーザテーブル(ユーザ名を含み、ユーザ削除時に削除しない)
ユーザ属性テーブル(ユーザ名以外の情報。認証情報やらなにやら。ユーザ削除時に削除する)
ってしなきゃいけないな。
コメント2件

128
NAME IS NULL[sage]   投稿日:2015/10/19 15:22:59  ID:???.net(860)
>124
> ユーザー情報(ユーザ名、パスワード)と個人情報(名前、住所、電話番号など)に分ける
のが正しい設計って解釈でいいの?
だからさー、それこそ「要件次第」なんだって。
何が正しい設計なんかない。

いつまで同じようなループさせれば気が済むんだ?

129
NAME IS NULL[sage]   投稿日:2015/10/19 15:25:31  ID:???.net(860)
前スレからわけわからんこと延々続けてるの、こいつなのかも

いつまでたっても収束しない
コメント1件

130
124[sage]   投稿日:2015/10/19 15:32:22  ID:???.net(860)
>129
安心しろ。同じこと何度も書くのは糞面倒だから他人だ。

>127
「一見関係ありそうに思える」って認めちゃってるけど、
だったら疑問として出てくる分には問題ないんじゃないか?
これも、俺個人だけが「個人情報どうなるの?」って問題視してねーわな。

まぁ良い。これも折れる。お前が正しい。

で、前スレの887のレス番があんたの「過去の答え」なんだな?
じゃ、>124の後半で意見したのが「正しい設計」で良いんだな?

まず、この解釈の確認をさせてくれ。
この後に、この設計について問題点を指摘する。
コメント2件

131
NAME IS NULL[sage]   投稿日:2015/10/19 15:32:58  ID:???.net(860)
>117
> 一部だけ切り取ってハッキリと何が駄目なの言わない奴。
なんで、何が駄目なのか具体的に指摘しなきゃならないんだよ。
誰もが無料で添削してくれるなんて思うなよ。
コメント1件

132
NAME IS NULL[sage]   投稿日:2015/10/19 15:34:02  ID:???.net(860)
>130
> この後に、この設計について問題点を指摘する。

しなくていいから。
お前のショボイ設計論なんぞ聞きたくない。
コメント1件

133
NAME IS NULL[sage]   投稿日:2015/10/19 15:36:15  ID:???.net(860)
>132
お前さっきから噛みつきまくってるけどどうした?www

134
NAME IS NULL[sage]   投稿日:2015/10/19 15:36:35  ID:???.net(860)
確かに、誰も頼んでないことをする必要はないね

135
NAME IS NULL[sage]   投稿日:2015/10/19 15:37:27  ID:???.net(860)
>131
添削?
「文章・答案などをけずったり書き加えたりして直し、いっそう良くすること。」
ってググったら出てくるんだけど、お前らのレスのどこが添削?
頭ごなしに批判してるだけじゃん
コメント1件

136
NAME IS NULL[sage]   投稿日:2015/10/19 15:38:20  ID:???.net(860)
要するに、他人にきちんと仕様を説明できないやつが、俺の設計が正しいことを承認してくれって暴れてるってことだな。
コメント1件

137
NAME IS NULL[sage]   投稿日:2015/10/19 15:39:21  ID:???.net(860)
>135
だから、添削なんかしないよって言ってんじゃん
それすら理解できないのか?
コメント1件

138
NAME IS NULL[sage]   投稿日:2015/10/19 15:39:36  ID:???.net(860)
>136
それ両方に言えるよね。質問者が納得してないのに「俺の言葉が正しい。受け入れろ」って言ってるだけじゃん
コメント1件

139
NAME IS NULL[sage]   投稿日:2015/10/19 15:39:58  ID:???.net(860)
>137
ああ、そうだね。添削せずに煽ってるだけだったw

140
120[sage]   投稿日:2015/10/19 15:40:00  ID:???.net(860)
>130
別に指摘して欲しいわけじゃなくて、それを書いた時点では、
BTSの人に対して、こうすれば問題ないんじゃないのって提示しただけだよ。
あの人と違う人だっていうなら、問題視する点も異なってくるはずだし、それが要件次第ってことだよ。
コメント1件

141
124[sage]   投稿日:2015/10/19 15:41:36  ID:???.net(860)
>140
いや、指摘して欲しいと思ってるなんて解釈してないよ。
ただ、俺があんたの答えに疑問に思ってるだけだから。
その疑問すら受け入れてもらえないの?
コメント1件

142
NAME IS NULL[sage]   投稿日:2015/10/19 15:43:07  ID:???.net(860)
>138
要するに、お前は
> 俺はわからない、俺がわかるまでお前ら説明しろ、そうする責任がお前らにはある、って奴。
って暴れてるだけだってことに気付よ。
コメント1件

143
120[sage]   投稿日:2015/10/19 15:43:25  ID:???.net(860)
>141
問題は要件次第でいくらでも出てくるはずなのでどうぞ。
コメント1件

144
124[sage]   投稿日:2015/10/19 15:44:22  ID:???.net(860)
>143
えっと、第三者の目で「おかしくない?」って横槍入れちゃうのはダメなの?
もちろん、要件次第って言い出したら何でもそうなっちゃうけど・・・
コメント2件

145
NAME IS NULL[sage]   投稿日:2015/10/19 15:45:31  ID:???.net(860)
>142
無視するって選択肢が君には残されてると思うんだけど

146
NAME IS NULL[sage]   投稿日:2015/10/19 15:46:45  ID:???.net(860)
大元の疑問に戻るが、

>48
> 「退会したユーザーは存在させたくない」
> けど
> 「名前は参照させたい」
>
> って場合はどうなるの?
実装方法として、どういう選択肢があるのかは、前スレにあるから読み返せ。

> やっぱり履歴テーブルに移行させて、そこから参照するの?
そんな唯一解はないし、ベストプラクティスのようなものもない。
コメント1件

147
120[sage]   投稿日:2015/10/19 15:48:00  ID:???.net(860)
>144
全然問題ないよ。同一要件でってこと?
あの段階だと、BTSにおいてユーザを削除するが、名前は残したいという要件だっけ。
個人情報だから削除しなきゃって話もまだだったように思うし、他システムとの連携の話もまだだったかな。
コメント2件

148
NAME IS NULL[sage]   投稿日:2015/10/19 15:48:47  ID:???.net(860)
そして、ユーザの属性を「ユーザ削除」されたときに、物理的に消し去るべきかどうかというのは、
まさに要件次第で、データベース設計の話とは関係ない。
コメント1件

149
NAME IS NULL[sage]   投稿日:2015/10/19 15:49:55  ID:???.net(860)
>147
> 個人情報だから削除しなきゃって話もまだだったように思うし、他システムとの連携の話もまだだったかな。
それは、データベース設計と何か関係ある話?
コメント1件

150
120[sage]   投稿日:2015/10/19 15:50:41  ID:???.net(860)
>149
運用段階の話だね。運用段階で検討すべきことを設計フェーズに持ち込もうとしていたので、それは違うよって話をしたように思う。

151
124[sage]   投稿日:2015/10/19 15:52:26  ID:???.net(860)
>147
まずBTSの話をしてないので同一視しないでくれw

>49が初出のレス(横槍)なわけで、
>146のいう「ベストプラクティスなんて存在しない」は十分理解出来てる。

ただ、120自身には答えとして存在する。
それは否定しないし、自分の型を持っているわけだから認める。
だったら他人がその答えに対して疑問を投げかけても良いだろ?

俺は>124の後半に書いたように
「削除するテーブルとしないテーブルを分ける」って考えは悪く無いと思うよ。
でも、それに対して参照する場合はどうするの?ってところに
「その場合はこうするよ」って意見を貰えてないから、ここまで長引くと思うんだよ。

もちろん、120がそこまで言ったつもりで、俺が理解できてないのなら、素直に自分の非を認める。
コメント1件

152
NAME IS NULL[sage]   投稿日:2015/10/19 15:52:38  ID:???.net(860)
>144
> もちろん、要件次第って言い出したら何でもそうなっちゃうけど・・・
そんなことはない。

現に過去スレでデータベース設計の話はきちんとされている。
概念設計も、物理設計も。

今回、要件次第、要件次第と言われるのは、「こういう要件の時に」という限定がなされないから。
コメント2件

153
NAME IS NULL[sage]   投稿日:2015/10/19 15:52:59  ID:???.net(860)
>148
要件次第で設計が変わりうるので、一概に設計と関係ないとはいえないかと
コメント1件

154
NAME IS NULL[sage]   投稿日:2015/10/19 15:56:54  ID:???.net(860)
>152
あのさ、DB設計って設計すればいいやってもんじゃないと思うんだよ。
設計したその先を考えるべきだと思うんだよ(少なくとも自分はそう思ってる)

だからこそ削除フラグや論理削除って考え方が生まれたわけだろ?

155
NAME IS NULL[sage]   投稿日:2015/10/19 15:58:08  ID:???.net(860)
>153
要件次第で設計が変わるのだから、要件を明確にせずに設計の話はできないということなんだが。

156
124[sage]   投稿日:2015/10/19 15:58:15  ID:???.net(860)
>152
少なくとも>49で「こういう要件の時は?」って質問してますけど・・・
コメント1件

157
120[sage]   投稿日:2015/10/19 16:00:54  ID:???.net(860)
>151
ないものを参照することはできないというだけでは不満かな。
ないものを参照させろということなら、それは削除しちゃいけないものとなる。

>49の「名前は参照させたい」という要件を満たすなら、
>124
> ・ユーザー情報(ユーザ名、パスワード)と個人情報(名前、住所、電話番号など)に分ける
という分割ではなく、ユーザ情報に「名前」を入れる。

というのが、>127でも引用した過去レスの内容。
コメント1件

158
124[sage]   投稿日:2015/10/19 16:04:30  ID:???.net(860)
>157
いや、不満じゃないよ。それも1つの答え出し、俺もどっちかというとそうしてるかな。(物理削除して名前を空欄にしてたり)

過去レスを引用した部分は分かった。
ただ、テーブルが2つになる事で開発の手間が増えるとか、
SQL発行回数が多くなってパフォーマンス的にどうなんだ?
って指摘は、「DB設計には関係ないから指摘するな」って解釈で良いの?
コメント2件

159
NAME IS NULL[sage]   投稿日:2015/10/19 16:05:51  ID:???.net(860)
>156
>49だと足りないということでしょう。

> 「退会したユーザーは存在させたくない」
> けど
> 「名前は参照させたい」
というのが要件だとしたら、

> やっぱり履歴テーブルに移行させて、そこから参照するの?
が妥当かどうかは判断できない。

別に削除フラグで実装してもいいし。
コメント2件

160
NAME IS NULL[sage]   投稿日:2015/10/19 16:06:48  ID:???.net(860)
>158
> ただ、テーブルが2つになる事で開発の手間が増えるとか、
> SQL発行回数が多くなってパフォーマンス的にどうなんだ?
> って指摘は、「DB設計には関係ないから指摘するな」って解釈で良いの?

え、今更そんなレベルなの?

本読め。
コメント1件

161
124[sage]   投稿日:2015/10/19 16:08:51  ID:???.net(860)
>159
その部分だけじゃなくて後半の「」も見て欲しかったけど、
まぁ、「それなら削除フラグで実装してもいい」は実りある答えだと思うよ。

削除フラグが頭ごなしに否定されている感覚を受けたからね。
でも、「要件次第で使ってもいいし使う場合もある」んなら、問題ないんじゃないかな。

162
124[sage]   投稿日:2015/10/19 16:11:16  ID:???.net(860)
>160
インデックスがどうだ、JOINがどうだの話してるんじゃないだが。
ま、いい。気の済むまで煽れ。
コメント1件

163
NAME IS NULL[sage]   投稿日:2015/10/19 16:15:01  ID:???.net(860)
>162
じゃあ、何の話がしたいんだよ?

今年削除フラグがバズったおかげで、かなりの議論がブログ等でなされてるし、
俺が>22で上げた書籍でも詳しく解説されてる。

それ以外の何かを議論したいなら、ちゃんとした疑問を提示してくれ。
コメント2件

164
124[sage]   投稿日:2015/10/19 16:17:47  ID:???.net(860)
>163
もういいよ。>120とお互い名前欄入れてレスし合ってたから読み返してくれ。

少なくとも>49のレスを見て、>159は自分なりの意見をした。
これが正しいか否かはともかく、159は削除フラグを否定してない。

おそらく早い段階でこの回答が来てるなら、
「こういう要件なら削除フラグでも良いのか」で終わってた話だよ。
無駄に煽り合いする必要もなく、こっちも2レスで済んでた。
コメント1件

165
NAME IS NULL[sage]   投稿日:2015/10/19 16:24:52  ID:???.net(860)
>164
俺としては、>49だけではどうすべきかというのは言えないというのがわかってくれればそれでいいよ。
(そして、他の多数の人もそのようなことを言ってるんだと思う)

君と>120がどういうやりとりをしてたのかを読めというのは、正直言って勘弁して欲しい。

また、>163で言った「それ以外の議論」がしたいのなら、別途どうぞ。
コメント1件

166
124[sage]   投稿日:2015/10/19 16:27:29  ID:???.net(860)
>165
あんたさ、自分が>22の書籍上げたって書いてるけど、
その下のレスまで読んでないだろ?
俺と似たような疑問呈したレスが有るぞ(さすがに俺の自演じゃないからなw

結局、スレ見返さず他人の意見を受け入れないのは自分じゃん。
コメント1件

167
NAME IS NULL[sage]   投稿日:2015/10/19 16:29:25  ID:???.net(860)
>166
> あんたさ、自分が>22の書籍上げたって書いてるけど、
> その下のレスまで読んでないだろ?
レス番を明示してくれ。

> 結局、スレ見返さず他人の意見を受け入れないのは自分じゃん。
はて、他人の意見を受け入れなかった記憶はないんだが・・・。
コメント1件

168
NAME IS NULL[sage]   投稿日:2015/10/19 16:32:16  ID:???.net(860)
>32とかのことかな?

読んだけど、まあ>22の本本でよとしか言えない。

169
124[sage]   投稿日:2015/10/19 16:32:33  ID:???.net(860)
>167
自分は見返すのを拒否して、人にはレス番指示かw

>24-33の流れ見ればいいんじゃねーの。
履歴テーブル扱うことの難しさについて話し合ってるわ。

んで、俺も履歴テーブルにするのは難しいと思ってるよ。
だから、120に>158でテーブルが2つになる事に対する疑問があるわけだし。

ま、次どんなレス来るかもおおよそ検討がつくからこの辺で名無しに戻ります。
コメント1件

170
NAME IS NULL[sage]   投稿日:2015/10/19 16:37:54  ID:???.net(860)
>169
> >24-33の流れ見ればいいんじゃねーの。
> 履歴テーブル扱うことの難しさについて話し合ってるわ。
それは読んだよ。

> テーブルが2つになる事に対する疑問
というのが、

> ただ、テーブルが2つになる事で開発の手間が増えるとか、
> SQL発行回数が多くなってパフォーマンス的にどうなんだ?
ということだったら、>22の書籍に解説があるし、「削除フラグ」に関するブログでも多数言及されてる。

それ以外の何か?
コメント1件

171
NAME IS NULL[sage]   投稿日:2015/10/19 16:45:47  ID:???.net(860)
マジでどうでもいい議論だったな

172
NAME IS NULL[sage]   投稿日:2015/10/19 16:47:03  ID:???.net(860)
つか、テーブルが2つになると、なんで
> SQL発行回数が多くなって
ってなるんだよ?

そこだけ説明して離脱してくれよ
コメント2件

173
NAME IS NULL[sage]   投稿日:2015/10/19 16:47:32  ID:???.net(860)
>170
そのブログに辿り着けるググり方教えてくれ。
「削除フラグ」「削除フラグ DB設計」では無理だった。
そのブログ読んでから疑問があるなら意見する
コメント1件

174
NAME IS NULL[sage]   投稿日:2015/10/19 16:48:04  ID:???.net(860)
>172
deleteしてinsertするからでしょ

175
NAME IS NULL[sage]   投稿日:2015/10/19 16:49:55  ID:???.net(860)
>172
元々1つのが2つにする時点で多くなると思うが

176
NAME IS NULL[sage]   投稿日:2015/10/19 16:51:54  ID:???.net(860)
>173
削除フラグ
論理削除
物理削除
デメリット
アンチパターン

などをいくつか組み合わせてググってくれ。
あと、>22は特にお薦めだから、金あるなら読んでみてくれ。

177
NAME IS NULL[sage]   投稿日:2015/10/19 16:52:35  ID:???.net(860)
176が意外と良い奴でワロタww

178
NAME IS NULL[sage]   投稿日:2015/10/19 16:52:58  ID:???.net(860)
あ、あとこのキーワードもか。

"論理削除 Casual Talks"

179
NAME IS NULL[sage]   投稿日:2015/10/19 17:59:42  ID:???.net(860)
えらく伸びてると思ったら...
新しい話が一つも無い

結局、今までの話を理解してなかった人に、懇切丁寧な人が付き合って上げてただけ
前もあったな、理解力不足な人が暴れてたってのが
3年ROMってろ文化は過去のものなのかね
コメント1件

180
NAME IS NULL[sage]   投稿日:2015/10/19 18:02:30  ID:???.net(860)
このスレいるやつみんな有休かな?

181
NAME IS NULL[sage]   投稿日:2015/10/19 18:35:56  ID:???.net(860)
煽り系質問はこりごり。

182
NAME IS NULL[sage]   投稿日:2015/10/19 18:37:59  ID:???.net(860)
煽り系回答もこりごり。
コメント1件

183
NAME IS NULL[sage]   投稿日:2015/10/19 18:39:55  ID:???.net(860)
>179
仲間内で馴れ合いたいだけなら2ちゃんの意味ないんじゃない?
このスレが他人の質問を一切受け付け無いってのなら別だけど
過去スレ見る限りそうじゃないんだがなぁ

184
NAME IS NULL[sage]   投稿日:2015/10/19 18:47:36  ID:???.net(860)
>182
> いや、不満じゃないよ。それも1つの答え出し、俺もどっちかというとそうしてるかな。(物理削除して名前を空欄にしてたり)
これには閉口するよね。
あ、根底から覆すんだなって。
コメント2件

185
NAME IS NULL[sage]   投稿日:2015/10/19 18:50:25  ID:???.net(860)
煽り系回答ってどれなんだろ?
コメント1件

186
NAME IS NULL[sage]   投稿日:2015/10/19 19:06:05  ID:???.net(860)
>185
>184こういうのじゃね?
明らかに一部だけ抜けだして、かつ自分の意見も書かずに否定だけしてるの。
コメント1件

187
NAME IS NULL[sage]   投稿日:2015/10/19 19:07:42  ID:???.net(860)
>184
もしかして「名前を空欄」ってDBのカラムを空欄って思っちゃいました?
さすがにそれはないですよw
というかやりとり見てたらそうは解釈出来ないと思うんですが、
本当に3年ROMられてました?
コメント1件

188
NAME IS NULL[sage]   投稿日:2015/10/19 19:11:48  ID:???.net(860)
>187
名前を残す要件前提で話してたのにってことだよ。

189
NAME IS NULL[sage]   投稿日:2015/10/19 19:14:03  ID:???.net(860)
>186
それ回答じゃないよ

190
NAME IS NULL[sage]   投稿日:2015/10/19 19:42:03  ID:???.net(860)
なんかもう訳わからんw

191
NAME IS NULL[sage]   投稿日:2015/10/19 20:29:36  ID:???.net(860)
名前と書き込み内容から、個人を特定する可能性もあると思うんだ
やはり名前も消さないと駄目だろう
コメント1件

192
NAME IS NULL[sage]   投稿日:2015/10/19 20:37:23  ID:???.net(860)
名前は個人情報でしょ。
同姓同名もいるから個人情報にあたらないという教育をしてる会社はないと信じたいけれど。

193
NAME IS NULL[sage]   投稿日:2015/10/19 21:54:29  ID:???.net(860)
幻のアンチパターン第29章 個人情報潔癖症

個人情報の取り扱いに神経質となるあまり、
例として挙げられたユーザーテーブルに
含まれる個人情報にばかり執着し論点を見失ってしまう事

194
NAME IS NULL[sage]   投稿日:2015/10/20 07:44:42  ID:???.net(860)
なんか自己完結したようだが、結局、自分のやり方を認めてもらいたい、正当化したい
ってことだったのかね。
せっかく説明してやってもそれを頑なに理解しようとしない態度もそう考えると腑に落ちる。
コメント1件

195
NAME IS NULL[sage]   投稿日:2015/10/20 12:44:04  ID:???.net(860)
>194
逆じゃね?せっかくの説明に「どうして?」って訪ねても
「いいからこうしろよ。理解できないなら馬鹿」って言ってるだけじゃん。
現にお前の上3つが個人情報について語ってるけど、
言うなら三者三様の考え方があるわけで、
それを無視して「理解できない馬鹿」ってレッテル貼りしてるだけにしか見えないが
コメント3件

196
NAME IS NULL[sage]   投稿日:2015/10/20 12:59:17  ID:???.net(860)
そんな流れあったかな

197
NAME IS NULL[sage]   投稿日:2015/10/20 13:05:20  ID:???.net(860)
>195
このスレでまだ暴れるつもり?

198
NAME IS NULL[sage]   投稿日:2015/10/20 13:08:03  ID:???.net(860)
>195
> 現にお前の上3つが個人情報について語ってるけど、
馬鹿すぎて無視されてるだけだろ

199
NAME IS NULL[sage]   投稿日:2015/10/20 14:21:28  ID:???.net(860)
> 「いいからこうしろよ。

被害妄想まで始まったぞ

200
NAME IS NULL[sage]   投稿日:2015/10/20 14:28:34  ID:???.net(860)
まだいるかなどうかな。
>124の人が最終的に理解した内容って、つまりは>41にかかれてることで、
そしてそれは>49の直後、>50のレスで終了してたんじゃないの?
コメント1件

201
NAME IS NULL[sage]   投稿日:2015/10/20 14:34:03  ID:???.net(860)
>200
だよなぁ。
まず前スレからこのスレの先頭あたりまで読んでから議論に参加してくれって感じ。

202
NAME IS NULL[sage]   投稿日:2015/10/20 14:35:29  ID:???.net(860)
>195
> 現にお前の上3つが個人情報について語ってるけど、
個人情報についてどうすべきかというのは、データベース設計とは関係ありませんね。

203
NAME IS NULL[sage]   投稿日:2015/10/20 14:47:36  ID:???.net(860)
>191が例の人の予感

204
NAME IS NULL[sage]   投稿日:2015/10/20 20:43:51  ID:???.net(860)
「どこまで個人情報だ」とか「どこまで消せばいい」とか客と話すべき事を
なぜここで語りたいのか心底理解出来ん

205
NAME IS NULL[sage]   投稿日:2015/10/20 21:14:50  ID:???.net(860)
・抽象的な説明が理解できなくて自分の問題に応用できない
・そしてそれを自分の頭のせいにしたくなくて必死に「自分の問題は特殊だ」と訴えている

206
NAME IS NULL[sage]   投稿日:2015/10/20 21:36:31  ID:???.net(860)
しつこいなぁとおもうけど、自演の可能性があるからなぁ

207
NAME IS NULL[sage]   投稿日:2015/10/20 22:51:59  ID:???.net(860)
わざわざそのためのスレを立ててくれた人が居るんだから、そこでやれバカ

208
NAME IS NULL[sage]   投稿日:2015/10/20 23:08:59  ID:???.net(860)
削除フラグの話終わったよ。
んで、専用スレ立てるほうがおかしい。
何をそこでやれというのか。

209
NAME IS NULL[]   投稿日:2015/10/22 22:59:14  ID:72sKbAfY.net
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

210
NAME IS NULL[sage]   投稿日:2015/10/31 03:06:44  ID:???.net(860)
また自演だったか

211
NAME IS NULL[]   投稿日:2015/11/12 18:00:26  ID:KLB1Ae4f.net
「1日に100万レコード増える場合のテーブル設計」
https://teratail.com/questions/18942
というのが先々週ぐらいにバズったのですが、皆さんはどう思いますか?

1日に数十〜100万レコード増える場合は、
ここで回答されているポイントを踏まえて設計し直せば良いんですかね?

例えば、アクセスログの集計とかポイントのやり取りに関する
DB設計も似たような解釈で良いんですかね?

いまいち回答がわかりづらいので、DB板の皆さんに聞いてみたいと思います。

212
NAME IS NULL[sage]   投稿日:2015/11/12 20:26:42  ID:???.net(860)
どこでバズったんですか?

213
NAME IS NULL[sage]   投稿日:2015/11/14 11:41:40  ID:???.net(860)
金融系DB作ったことある人ならわかるけど
「過去データ保持の考え方」とか「INSERTは遅くてもいい」で興味持っただけの人だと思う

214
NAME IS NULL[sage]   投稿日:2015/11/15 22:46:53  ID:???.net(860)
DB初心者です。Sqlite使用。
everythingのようにストレージファイルを管理したいんだけど
Updateとかしないで一旦全部削除してから
ファイル構造をぶっ込んだほうがいいですか?
なぜならファイル名やパスが変更されるので同一ファイルかどうかの判別が難しい。
この場合、ジャンルテーブルなどとの関連付けをやり直しになるんだろうけど。

215
NAME IS NULL[sage]   投稿日:2015/11/16 10:23:10  ID:???.net(860)
eveerythingというのが何かしらないけど、フォルダに格納しているファイル一覧について
DB化している。
んで、時たまフォルダの移動とか削除とかもあったりするので、一旦全部削除後再作成
というのをしてるよ
コメント1件

216
NAME IS NULL[sage]   投稿日:2015/11/16 13:32:27  ID:???.net(860)
職種別、資格別、スキル別の平均最低月給リスト(ほぼ毎日更新)
http://jobinjapan.jp/cate/
全掲載求人109,160件の平均最低月給195,800円

データベースエンジニアの求人 の平均最低月給229,900円
http://jobinjapan.jp/job-listing/keyword-database-engineers.html

やったね!!

217
NAME IS NULL[sage]   投稿日:2015/11/16 16:56:09  ID:???.net(860)
>215
やっぱり全部削除でいいんですね!
ありがとうございます!

218
NAME IS NULL[sage]   投稿日:2015/11/16 17:28:09  ID:???.net(860)
evernoteのようなサービスを作ろうと思うのですが、テーブル設計で悩んでいます

usersテーブル / id, username, password
notebooksテーブル / id, user_id, title
notesテーブル / id, notebook_id, user_id, title, body
tagsテーブル / id, user_id, name(unique)

以上が必要なテーブルだと思うのですが、
ノート、タグ、ユーザーのひも付けの仕方に悩んでいます

pivotテーブル / id, user_id, note_id, tag_id を作るか
いっそtagsテーブルにuser_idとnote_idを持たせようかと思っています

どちらがいいのか、またはまったく別のいい方法があれば教えていただきたいです。
よろしくお願いします。
コメント1件

219
NAME IS NULL[sage]   投稿日:2015/11/16 17:32:14  ID:???.net(860)
タグは中間テーブル作ったほうがいいよ。その方が変更しやすくなる。
user_tags/id,user_id,tag_id
コメント1件

220
NAME IS NULL[sage]   投稿日:2015/11/16 17:44:52  ID:???.net(860)
tag table: note_id, tag_id

221
NAME IS NULL[sage]   投稿日:2015/11/16 17:47:03  ID:???.net(860)
>218
> notesテーブル / id, notebook_id, user_id, title, body
user_idは不要かな

222
NAME IS NULL[sage]   投稿日:2015/12/01 06:58:52  ID:???.net(860)
>219
ユーザとタグの n対n 関係の中間テーブルなら、id カラムは不要
user_id, tag_id を PK にすればいい
場合によっては逆順のユニークインデックスもつけてね

223
名無しさん@そうだ選挙に行こう[]   投稿日:2015/12/14 15:12:26  ID:LwQRJZzM.net(2)
mysqlでウェブアプリを作っていて
12あるカラムの中身1つ1つと対になるようなサブフィールドのようなものが欲しいのですが分からなくて迷っています。

例えば
主キーカラムが id で 1 の行に、カラムがc1, c2,,, c12まであるとしたら(id 2 にも同様にc1〜c12まであります。)

c1_status, c2_status,,,といったようにちょっとしたそれぞれc1, c2,,,の中身に対する状態を記録するカラムが欲しいのです。
この場合テーブルを分けたほうが設計として良いでしょうか?
それとも同じテーブルに12個カラムを追加したほうがいいのでしょうか。

普段呼び出すのはc1〜c12で、_statusのカラムはそんなに頻繁には使いません。
何かアドバイスをいただけないでしょうか、お願いします。
コメント1件

224
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 16:26:16  ID:???.net(860)
>223
そんな抽象的な要件では、何が良い設計なのかなど判断できない。

225
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 16:31:17  ID:???.net(860)
何の前提条件もなしに考えるのなら、

--
table_a (id, c1, c2. ..., c12, status1, status2, ..., status12)
--
table_a(id, c1, c2. ..., c12)
status(table_a_id, s1, s2, ..., s12)
--
table_a(id, c1, c2. ..., c12)
status(table_a_id, index, status)
(c2のstatusなら、index=2)
--
table_a(id, c1, c2. ..., c12)
status(table_a_id, c_name, status)
(indexではなく、名前を使う)
--
などが考えられるが、どれがいいとは言えない。
コメント1件

226
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 16:38:47  ID:???.net(860)
というか、そもそも
table_a(id, c1, c2. ..., c12)
という構造すら良い設計なのかどうかあやしい。
table_b(id, data)
table_b(id, some_data, data)
のように、1レコード1データの方が良い場合もある。
コメント1件

227
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 19:07:29  ID:???.net(860)
ちょっと確かにあやふやすぎましたすみません

>225
とても参考になります
そして考え直すと、確かに>226さんの言う通りでした。
というのも、c*は増える可能性もあるかもしれないな、と。

なので考えたのが
table_a(id, otherdata)
table_b(id, index, status, maindata)
こうしようかなと思ったのですが
table_bのidはtable_a.idをそのまま使うことになるので

例えば c1、c2までしかないとしてtable_a.idに紐付かせると

table_b.id=1, index=1, status=something, maingdata=something
table_b.id=1, index=2, status=something, maingdata=something

table_b.id=2, index=1, status=something, maingdata=something
table_b.id=2, index=2, status=something, maingdata=something

こうなりますが、この場合プライマリーキーはtable_bに設定しないということになるのでしょうか?
一意な値が1つもないように思います。
table_a.id=1 で table_b.index=1 という組み合わせは1つしか存在し得ませんが。
コメント1件

228
名無しさん@そうだ選挙に行こう[]   投稿日:2015/12/14 19:18:27  ID:LwQRJZzM.net(2)
連投ですみませんが、下記サイトも読みまして、それでも疑問が解決しませんでした。
http://www.flint.jp/blog/?entry=23
一番下にある設計message_targetテーブルで

target INTEGER PRIMARY KEY メッセージ識別子 (message.id)

と書いてますがその下の実際にデータを格納している例では
message_targetテーブルのカラム名が

message index type username

となっており、messageの欄がmessageテーブル(私の場合で言うtable_a)のidが入っています。
これはどういうことなんですか?
コメント2件

229
NAME IS NULL[sage]   投稿日:2015/12/15 00:27:11  ID:???.net(860)
>227
> table_a.id=1 で table_b.index=1 という組み合わせは1つしか存在し得ませんが。
なので、それをキーにするよ。複合プライマリキーっていう。
コメント1件

230
NAME IS NULL[sage]   投稿日:2015/12/15 00:31:13  ID:???.net(860)
>228
その直前にテーブルレイアウトあるけど、
messageじゃなくてtargetの誤記だろうね。
でも、通常message_idとかにする。targetなんて突拍子もないカラム名つけるのは誰もが困るイマイチ設計
コメント1件

231
NAME IS NULL[sage]   投稿日:2015/12/15 01:20:08  ID:???.net(860)
>229
複合プライマリキー勉強になります。

>230
そうかとも思いましたが、message_targetのtargetカラムにPRIMARY KEYを設定するのは不可能じゃないですか?
実際下の例でmessageがtargetの誤記だとすると 21 が2つありますし。

targetの説明に、メッセージ識別子 (message.id) とあるので、
もしかしてmessageテーブルのidを引っ張ってきてmessage_targetテーブルに入れ込んでうまいことやってくれる方法でもあるのかなと思ったのですが
まぁそれでもmessageというカラム名っぽく書いてあるのはおかしいですよね…。

とりあえず私の設計は複合プライマリキーを調べつつやっていきますありがとうございます。
コメント1件

232
NAME IS NULL[sage]   投稿日:2015/12/15 03:27:02  ID:???.net(860)
>231
http://prntscr.com/9e4z4y
この赤枠のところには罫線がないよ

とにかくもっと基礎知識をつけるべき

233
NAME IS NULL[sage]   投稿日:2015/12/15 13:29:12  ID:???.net(860)
>228
まだ見てるかどうかわからんけど。

そういう素性もしれないレベルも良くわからないブログを読んで時間を消耗するより、
入門書1,2冊買って勉強した方がいいぞ。
コメント1件

234
NAME IS NULL[sage]   投稿日:2015/12/15 15:18:10  ID:???.net(860)
>233
早速注文しようと思います。
mysqlしか使ったことありませんが、データベースについて書かれてるもので概論を学ぶならなんでもいいですよね?
わりかし新しめで評価高そうなこの2つにします。どっちもミックって人ですね。

おうちで学べるデータベースのきほん
http://www.amazon.co.jp/dp/479813516X/
SQL実践入門──高速でわかりやすいクエリの書き方
http://www.amazon.co.jp/dp/4774173010/
コメント1件

235
NAME IS NULL[sage]   投稿日:2015/12/15 15:21:28  ID:???.net(860)
日本語でググると、素性知れない怪しい記事ばっかりヒットするけど、
英語で検索すると有名どころの開発者の記事がヒットすること多いよ
StackOverFlow でも開発者本人が回答してるのとか結構ある
日本のナレッジコミュニティの質はやばすぎるw

236
NAME IS NULL[sage]   投稿日:2015/12/15 16:06:34  ID:???.net(860)
>234
毛嫌いする人がいたりするけど、ミック氏はお勧め。
あと日本人では奥野 幹也氏の『データベース実戦入門』(ちょっと高度)。

鉄板はJoe Celko。
『プログラマのためのSQL 第4版』が良いが、初心者には厳しいかも。

237
NAME IS NULL[]   投稿日:2015/12/19 16:52:43  ID:oyjo6SxH.net
データベース関係について語り合うならおすすめ。
よかったら、「blngs」で検索してみて!

238
NAME IS NULL[sage]   投稿日:2015/12/23 18:08:08  ID:???.net(860)
設計について学びたいんですがおすすめの本ってありませんか?
本で取り扱うデータベースは問いません
設計について学べる本を教えてください

239
NAME IS NULL[]   投稿日:2016/02/04 22:10:35  ID:iYCEtTbs.net
ECサイトを例として、注文テーブルがあるとします。
これに運営後、支払い方法と手数料に関するカラムが必要になったとして、

A)注文テーブルに支払い方法と手数料用のカラムを追加する
B)注文支払いテーブルを作って、注文テーブルと結合する

のどっちが管理しやすいですか?
プログラミング的には1つのテーブルにまとめた方が取り扱いやすいのですが、
その場合、既に運用しているDB設計を変える(カラム追加する)
必要があるので気になっています。
コメント1件

240
NAME IS NULL[]   投稿日:2016/02/04 22:19:23  ID:vrajJNnU.net(2)
>239
支払い方法に手数料があるなら、支払い方法テーブルを作る。
コメント1件

241
NAME IS NULL[]   投稿日:2016/02/04 22:22:19  ID:vrajJNnU.net(2)
支払い方法と手数料がまったく関係ない項目なら分けない。

242
NAME IS NULL[sage]   投稿日:2016/02/05 01:04:06  ID:???.net(860)
プログラミング的にやりやすいかどうかで判断するのは最後の手段。
運用前後関係なく、そこを曲げたらだめ。
コメント2件

243
239[sage]   投稿日:2016/02/05 01:53:13  ID:???.net(860)
>240-241
今までは銀行振込だったのが、代引きや郵便振替など、別の支払方法が増えた
と解釈していただければと思います。

支払い方法が保存されているテーブルが別にあるとして、
注文に対して新たに必要なカラムは
「支払い方法テーブルID」「手数料」になるかと思います。

前者2行の通り、手数料がある場合もあるけど無い場合もある。
無い場合は0かNULL(この場合は0かと思います)になります。

となると、やっぱり注文支払い方法テーブルが必要なんですかね?

>242
確かにそうなんですが、後からカスタマイズする手間暇コストも気になります
1テーブルのカラム呼び出しだけなら簡単ですからねぇ・・・
コメント1件

244
NAME IS NULL[sage]   投稿日:2016/02/05 04:16:26  ID:???.net(860)
> プログラミング的には1つのテーブルにまとめた方が取り扱いやすいのですが、
に対して
> プログラミング的にやりやすいかどうかで判断するのは最後の手段
というレスがついたから、テーブルを分割すべきといわれているように思ったってことなのかな。

245
NAME IS NULL[]   投稿日:2016/02/05 07:20:41  ID:m9Az/ZYB.net(2)
>243
支払い方法が変わらなくても、手数料の金額は変わる可能性があるよね。

難しいことは言わないけど、トランザクションデータに持つのは、マスタデータになるうるデータをトランザクションデータとして持つことになる。

データによって支払い方法と手数料の組み合わせか1対1でないなら、上記のことはあてはまらないけど。

246
NAME IS NULL[]   投稿日:2016/02/05 12:21:10  ID:AioVhB5K.net
>242
仕様に対して適切なデータ構造であれば、自ずとブログラミングも簡単になるもの。
逆もまた然り。

247
NAME IS NULL[]   投稿日:2016/02/05 22:32:59  ID:m9Az/ZYB.net(2)
データモデリングはE-R図だけ見て業務が見えなければ失敗。

248
239[sage]   投稿日:2016/02/06 14:57:43  ID:???.net(860)
皆さん有り難うございます。もう少し考えて一番やりやすい方法でやってみます。

249
NAME IS NULL[sage]   投稿日:2016/02/08 23:55:13  ID:???.net(860)
興味本位で聞くんだけど、テーブル数とインデックス数の比率ってどれくらい?
用途によって違うだろうから、簡単に用途も書いてもらえるとうれしい。
ちなみにうちは所謂OLTPのDBでテーブル約200:インデックス約1000だわ。1対5ってとこ。
減らしたいけど減らせない。
コメント1件

250
NAME IS NULL[sage]   投稿日:2016/02/08 23:56:50  ID:???.net(860)
それこそ書き込み中心と読み込み中心でテーブル単位で違うでしょ
コメント1件

251
NAME IS NULL[]   投稿日:2016/02/09 00:09:27  ID:4ybKm805.net(3)
>249
実際には使われてないインデックスを洗い出せば?
コメント1件

252
NAME IS NULL[]   投稿日:2016/02/09 00:14:09  ID:4ybKm805.net(3)
>250
それを言うなら、一度に大量のレコードを検索するかしないかだろ。

253
NAME IS NULL[sage]   投稿日:2016/02/09 00:14:41  ID:???.net(860)
>251
うん、それもやる予定ではいる。ちょっとそれどころじゃなくて進められてないんだけど…
コメント1件

254
NAME IS NULL[]   投稿日:2016/02/09 00:31:03  ID:4ybKm805.net(3)
主キー以外で絞り込む検索がそんなにあるとは思えない。

インデックスを作れば速くなると思って安易に乱造している可能性もある。

255
NAME IS NULL[sage]   投稿日:2016/02/09 03:47:14  ID:???.net(860)
うちとこはマスタが多いから平均すると 1:2 いくかどうかかなぁ。
コメント1件

256
NAME IS NULL[sage]   投稿日:2016/02/09 03:49:40  ID:???.net(860)
あ、PKもひとつのインデックスとしてカウントしたけど、よかったかな。

257
NAME IS NULL[sage]   投稿日:2016/02/09 04:16:25  ID:???.net(860)
OLTPでテーブルあたり5個は多いような気がするなぁ
5個もインデックス必要ならテーブル分割も検討した方が良いような気がする
あくまで根拠のない個人的な感想だけどな

258
NAME IS NULL[sage]   投稿日:2016/02/09 07:05:13  ID:???.net(860)
>255
平均だとうちもそんなもん
PK のみって言うテーブルも多いし
平均で5は明らかに多すぎる様に思う

259
NAME IS NULL[]   投稿日:2016/02/09 07:19:20  ID:JcT1gAvw.net(2)
別に多くたってたいした問題じゃないだろ。

260
NAME IS NULL[]   投稿日:2016/02/09 07:21:12  ID:JcT1gAvw.net(2)
設計時にたくさん作らないといけない状況になるなら、データモデリングがおかしいんだよ。

261
NAME IS NULL[sage]   投稿日:2016/02/09 10:36:59  ID:???.net(860)
>253
> うん、それもやる予定ではいる。ちょっとそれどころじゃなくて進められてないんだけど…
何のデータベース使ってるか知らないけど、大抵はクエリ一発で全インデックスのヒット率を
取得できると思うぞ。

262
NAME IS NULL[]   投稿日:2016/02/11 09:32:59  ID:8EE+OOiZ.net(2)
もしわかれば教えてください。
BIツール的な利用イメージで、集約された情報からの検索を考えた場合に、
どんな条件で検索されるかもわからないから、正規化せずに1つのテーブルに全項目持っておけば
固有なプログラムつくる必要ないかなーと。検索条件に合致する行だけを取り出せばいい。
まぁRDBだとindexとか冗長とかいろいろあるけど、それをうまく実現可能なDBってあります?
コメント2件

263
NAME IS NULL[]   投稿日:2016/02/11 09:44:08  ID:x69Y51xP.net(4)
>262
SQLが変わり、データ量が増えるだけです。
コメント1件

264
NAME IS NULL[]   投稿日:2016/02/11 09:45:54  ID:x69Y51xP.net(4)
>262
むしろ専用の検索プログラムが必要になりますね。

265
NAME IS NULL[]   投稿日:2016/02/11 09:51:06  ID:x69Y51xP.net(4)
普通はBIツール用に業務DBからデータウェアハウスを作ります。

266
NAME IS NULL[]   投稿日:2016/02/11 14:15:46  ID:8EE+OOiZ.net(2)
>263 264 265

1テーブルに持てば、selectする項目とwhere句の条件項目が変わるだけでは。
動的SQLで吸収すれば検索プログラムは1つで済むし。joinとかいらないし。
データウェアハウスをどう構えるかって話。
コメント1件

267
NAME IS NULL[sage]   投稿日:2016/02/11 15:03:21  ID:???.net(860)
自分がいいと思うならそうすれば〜?
それで問題ないかも知れないし
問題あっても困るのは俺じゃないしな

268
NAME IS NULL[]   投稿日:2016/02/11 20:42:33  ID:x69Y51xP.net(4)
>266
分からないから質問したんじゃないの?

思ったようにやればいいよ。

データを持ち直してSQLを変えて、さらにそのSQLが不定って、最初から元のDBのビューでいいんじゃないの?

だいたいBIツールがなんだか分かってる?

269
NAME IS NULL[]   投稿日:2016/02/24 22:22:34  ID:1LNjXYAL.net
では皆さんBI大喜利どうぞ

270
NAME IS NULL[sage]   投稿日:2016/02/25 20:06:39  ID:???.net(860)
歌さん、あなた突然倒れて2週間眠ったままだったのよ

271
NAME IS NULL[]   投稿日:2016/02/29 10:24:17  ID:Bh4c8Jux.net
プログラム板で質問したのですが、数日待っても回答がなかったので、こちらでも質問させてください。

「ループ内でクエリを書いてはいけない」(ミック氏銘々(?)のぐるぐる系クエリは書いてはいけない)と
いうことが説明されている、初心者向けの書籍はありますか?

私が初心者ということではなく、初心者にまず与える書籍を探しています。

『SQL実践入門』には記載されていることはわかっていますが、他の章のレベルが高いため、初心者
向けには厳しいと思っています。
コメント4件

272
NAME IS NULL[sage]   投稿日:2016/02/29 11:38:32  ID:???.net(860)
すみません、書き込むスレを間違えたので、正しいスレに移動します。

273
NAME IS NULL[sage]   投稿日:2016/02/29 14:37:54  ID:???.net(860)
> 私が初心者ということではなく、初心者にまず与える書籍を探しています。
別に初心者に書籍を与えるまでもなく、説明をしてあげればいいのにと思う。
コメント2件

274
NAME IS NULL[sage]   投稿日:2016/02/29 14:51:58  ID:???.net(860)
>273
> 別に初心者に書籍を与えるまでもなく、説明をしてあげればいいのにと思う。
私は初心者に教える暇がないので、そのような書籍があればまず最初の一冊目として
推薦したいのです。

275
NAME IS NULL[sage]   投稿日:2016/02/29 14:52:44  ID:???.net(860)
その程度の暇も取れないのなら数日がかりで本を探すのなんてやめなさいな。

276
NAME IS NULL[sage]   投稿日:2016/02/29 14:55:24  ID:???.net(860)
てか、このやり取りをする暇がありさえすれば説明できる内容だよね。
コメント1件

277
NAME IS NULL[sage]   投稿日:2016/02/29 15:06:54  ID:???.net(860)
相手は一人ではないし、それぞれ知ってることも知らないこともあります。

例えばループ内でクエリを書かないということ一つとっても、解決方は多数あり
個人個人に教えるのは非効率です。

278
NAME IS NULL[sage]   投稿日:2016/02/29 15:10:18  ID:???.net(860)
誤解されたかもしれませんが、初心者というのは「基本的なことはわかっているが
例えばループ内でクエリを書いてはいけないなどの穴がある」ような人じゃなくて、
基本的なことも知らない初心者を想定してください。

最悪、JOINもSUMも知らない初心者です。

279
NAME IS NULL[sage]   投稿日:2016/02/29 15:15:08  ID:???.net(860)
かかわらいほうがいい

推薦図書/必読書のためのスレッド 78 [転載禁止](c)2ch.net
推薦図書/必読書のためのスレッド 78 /プログラム板
コメント1件

280
NAME IS NULL[sage]   投稿日:2016/02/29 15:40:22  ID:???.net(860)
>279
そのスレでは>271以外の奴が全員ど素人。
知ってれば教えてやりたいが、初心者向けの書籍なんかもう何年も読んでないんでわからん。
コメント3件

281
NAME IS NULL[sage]   投稿日:2016/02/29 15:47:22  ID:???.net(860)
>280
> 知ってれば教えてやりたいが、初心者向けの書籍なんかもう何年も読んでないんでわからん。
だよなぁ
この板に来る奴は、初心者で書籍も読まないような奴か、ベテランのどちらか
でかい本屋に行って、自分で探すしかないのでは

282
NAME IS NULL[sage]   投稿日:2016/02/29 15:56:57  ID:???.net(860)
言われてみれば、SQLアンチパターンにのってても良さそうなんだけどのってないな

283
NAME IS NULL[sage]   投稿日:2016/02/29 15:58:44  ID:???.net(860)
SQLのアンチパターンじゃないからね。
コメント1件

284
NAME IS NULL[sage]   投稿日:2016/02/29 16:01:14  ID:???.net(860)
>283
あ、なるほど
納得

285
NAME IS NULL[sage]   投稿日:2016/02/29 16:10:39  ID:???.net(860)
>276
ループしないようにするためには、JOINから始まってsubqueryや分析関数(Window関数)、再帰クエリや
SQLパズルに載っているようなトリッキーなクエリに至るまで、さまざまな手段がある。

クエリをループさせては駄目なことを教えるのは簡単だけど、解決法を教えるのは時間がかかると思うよ。
まぁ、本を多数読むしかないかね。
コメント1件

286
NAME IS NULL[sage]   投稿日:2016/02/29 16:12:41  ID:???.net(860)
なもんで、ループ内クエリは避けたほうがよい場合がほとんどであるということが記載されているような
初心者向けSQL本を探すぐらいなら、その項目は別途説明という形を取ったほうが余程いいと思う。

それも本で済ませたいということならアルゴリズム本も読ませて
計算量についての素養も身につけさせておけばいいんじゃない?

>285
それらも網羅した初心者向けの書籍を欲していると?
コメント1件

287
NAME IS NULL[sage]   投稿日:2016/02/29 16:20:59  ID:???.net(860)
>286
なんでそれだけ別途説明にしろって思うのか、よくわかんないんだけど。
説明がのってる書籍があるなら、それ与えれば終了でしょ。
っていうか、あるんじゃないの?俺はしらんけど。

288
NAME IS NULL[sage]   投稿日:2016/02/29 16:26:43  ID:???.net(860)
ここの人たちって口だけで大して本読まないからみんな知らないよ
コメント1件

289
NAME IS NULL[sage]   投稿日:2016/02/29 16:27:33  ID:???.net(860)
読んだこと無いけど、「絵本で学ぶSQL」的な本と『SQL実践入門』のあわせ技にすれば解決じゃね?

290
NAME IS NULL[sage]   投稿日:2016/02/29 16:29:45  ID:???.net(860)
つか、スレ違いのレスにコメント付けるんじゃねぇ >273
お前のせいでこのスレが書籍スレになったじゃねーか

291
NAME IS NULL[sage]   投稿日:2016/02/29 16:32:44  ID:???.net(860)
移動元、移動先を書いてない質問主にも問題があるとは思わんかね。

292
NAME IS NULL[sage]   投稿日:2016/02/29 16:33:30  ID:???.net(860)
本屋に行って自分で探せ、で終了。
コメント1件

293
NAME IS NULL[sage]   投稿日:2016/02/29 16:46:42  ID:???.net(860)
>288
まぁ、これだろな
板人口も少ないし

294
NAME IS NULL[sage]   投稿日:2016/02/29 16:56:49  ID:???.net(860)
Kindle KDPネタにすれば

295
NAME IS NULL[sage]   投稿日:2016/02/29 17:24:29  ID:???.net(860)
ここで書く暇があれば自分で資料作ればいいと思うの
コメント1件

296
NAME IS NULL[sage]   投稿日:2016/02/29 17:26:57  ID:???.net(860)
>295
知らないことがループの件だけだったらそうすればいいね

297
NAME IS NULL[sage]   投稿日:2016/02/29 18:07:42  ID:???.net(860)
計算量とSQLの実装と設計の話の組合せなので、
1冊で済ますのはなかなか厳しいような。

とりあえず「プログラマのためのSQL」と「PofEAA」くらいかな。
コメント2件

298
NAME IS NULL[sage]   投稿日:2016/02/29 18:24:10  ID:???.net(860)
>292
> 本屋に行って自分で探せ、で終了。
おっしゃる通りですね。

ただ、現状は、業務命令として探せといわれてるのではなく、見つかるなら提案しようというレベルですので、
ちょっと腰が重くなりがちです。

299
NAME IS NULL[sage]   投稿日:2016/02/29 18:30:32  ID:???.net(860)
>297
> とりあえず「プログラマのためのSQL」と「PofEAA」くらいかな。
実は、『プログラマのためのSQL』には、「ループ内でクエリを書いてはいけない」ということが
書かれてないんです。というか、クライアントサイドの話はほぼないんですね。

みなさん、どこで「ループ内でクエリを書いてはいけない」ことを学んだんでしょうか。
私は・・・ちょっと・・・思い出せません。
コメント1件

300
298[sage]   投稿日:2016/02/29 19:01:10  ID:???.net(860)
>299
テキストで読んだ記憶はないなあ。

確かに『プログラマのためのSQL」に
「クライアントサイド」(←SQLを利用するプログラムという解釈でいいよね?)
の話はないですね。

そのあたりをパターン化したものを紹介した書籍としてPofEAAを挙げました。

301
NAME IS NULL[sage]   投稿日:2016/02/29 20:51:26  ID:???.net(860)

302
NAME IS NULL[sage]   投稿日:2016/02/29 21:09:49  ID:???.net(860)
おっさんから一言言わせてもらうと
今のお子様本渡したら消化早いけど全く覚えてないよ

303
NAME IS NULL[sage]   投稿日:2016/02/29 21:21:47  ID:???.net(860)
>280
本人乙

304
NAME IS NULL[sage]   投稿日:2016/02/29 21:56:21  ID:???.net(860)
「ループ内でクエリを書いてはいけない」とか言われた事ないけどな

そもそもループ内でクエリ書くなとか、つまるところホストアプリでやるべきかSQLでやるべきかって話だろ
すくなくともSQL初心者が考えるような事じゃないよ
コメント3件

305
NAME IS NULL[sage]   投稿日:2016/02/29 22:02:20  ID:???.net(860)
なんでそういう書籍が無いかというと、「ループ内でクエリを書いてはいけない」ってのが真ではないから。
コメント1件

306
NAME IS NULL[sage]   投稿日:2016/02/29 22:09:40  ID:???.net(860)
レビューで指摘するか、性能を気にするなら性能試験をやってで最適化すればいい話
質問主は素人なんだろ
コメント1件

307
NAME IS NULL[sage]   投稿日:2016/02/29 23:08:09  ID:???.net(860)
断定できる話じゃないしね
設計段階で不明なら試験するしかにい
コメント1件

308
NAME IS NULL[sage]   投稿日:2016/02/29 23:15:57  ID:???.net(860)
そしてまた、「向こうのスレでは回答をもらえなかったので…」というパターン。

309
NAME IS NULL[sage]   投稿日:2016/02/29 23:38:15  ID:???.net(860)
どこいっても根拠の無い断定意見と検証しろ的回答しかこないね

310
NAME IS NULL[sage]   投稿日:2016/03/01 00:15:32  ID:???.net(860)
どこいってもそうなら質問の方がおかしかったんだと気付け

311
NAME IS NULL[sage]   投稿日:2016/03/01 01:08:30  ID:???.net(860)

312
NAME IS NULL[sage]   投稿日:2016/03/01 01:10:37  ID:???.net(860)
2重書き込みのため表示しません 内容を確認する

313
NAME IS NULL[sage]   投稿日:2016/03/01 09:45:47  ID:???.net(860)
>271は素人の教条主義といってるだけなのだが、俺様もつけるかw

314
NAME IS NULL[sage]   投稿日:2016/03/01 10:04:48  ID:???.net(860)
>304
あっちのスレでもこっちのスレでも、こいつが暴れてるのな

315
NAME IS NULL[sage]   投稿日:2016/03/01 10:08:02  ID:???.net(860)
>306
> レビューで指摘するか、
最初から正しいコードをかけてれば、レビューで指摘することもない。

> 性能を気にするなら性能試験をやってで最適化すればいい話
「最適化」じゃなくて、適切なクエリとコード書けという話だ。

> 質問主は素人なんだろ
お前が名。
コメント1件

316
NAME IS NULL[sage]   投稿日:2016/03/01 10:09:04  ID:???.net(860)
>307
> 設計段階で不明なら試験するしかにい
試験するしかないとか言ってるのがど素人の証拠だよ。

317
NAME IS NULL[sage]   投稿日:2016/03/01 10:26:19  ID:???.net(860)
>304
> そもそもループ内でクエリ書くなとか、つまるところホストアプリでやるべきかSQLでやるべきかって話だろ
さすがに釣りじゃないの?

あと、クライアントコードの話はスレ違いなので。

318
NAME IS NULL[sage]   投稿日:2016/03/01 13:19:50  ID:???.net(860)
>305
> なんでそういう書籍が無いかというと、「ループ内でクエリを書いてはいけない」ってのが真ではないから。
『SQL実践入門』にはあるんですが・・・
コメント2件

319
NAME IS NULL[sage]   投稿日:2016/03/01 13:57:42  ID:???.net(860)
>315
やっぱり素人w

320
NAME IS NULL[sage]   投稿日:2016/03/01 14:08:20  ID:???.net(860)
過疎板荒らすな

321
NAME IS NULL[sage]   投稿日:2016/03/01 14:15:57  ID:???.net(860)
プロの俺様が今まで「ループ内でクエリを書いてはいけない」なんて言われたこと内のだから、それが真であるはずがない

322
NAME IS NULL[sage]   投稿日:2016/03/01 14:18:42  ID:???.net(860)
>318
時間がないから本を与えることで解決したいというのはわかった。
本を1冊に絞らなければならない理由もあるの?

323
NAME IS NULL[sage]   投稿日:2016/03/01 14:33:40  ID:???.net(860)
「この物語はフィクションであり、実在の人物・団体とは一切関係ありません」

設計書には、「商品マスターから指定された条件にマッチする商品コードを取得する」、
「取得した商品コード一覧から販売テーブルを検索し販売実績を取得する」とあって、
実装を担当するコーダーは忠実にそのステップ通りに書きあげた。

100種程度の商品マスターと、それぞれ20〜40程度の販売履歴を作成し、試験を
実施した結果、問題なく処理できると判定された。

実際に使い始め、しばらく経つと商品マスターが数千種〜1万種、販売履歴も多くなり、
異様に処理が重くなった、画面表示が何分も待たされてしまうようになったと、顧客から
クレームが入り、原因の調査が始まった。(つづきません)
コメント4件

324
NAME IS NULL[sage]   投稿日:2016/03/01 14:46:22  ID:???.net(860)
今でもそんな90年代みたいなクラサバモデル存在するのか
コメント1件

325
NAME IS NULL[sage]   投稿日:2016/03/01 14:50:25  ID:???.net(860)
あるんじゃないの
まあどこで絞り込んでるかの話よね?
コメント1件

326
NAME IS NULL[sage]   投稿日:2016/03/01 15:07:43  ID:???.net(860)
>325
> まあどこで絞り込んでるかの話よね?
いいえ

327
NAME IS NULL[sage]   投稿日:2016/03/01 15:24:21  ID:???.net(860)
>324
モデリング?何それ?リレーション?何それ?的なDBはまだまだある

328
NAME IS NULL[sage]   投稿日:2016/03/01 15:37:34  ID:???.net(860)
営業の失敗例だろ

329
NAME IS NULL[sage]   投稿日:2016/03/01 15:44:40  ID:???.net(860)
1万種の商品を一度に画面に表示してはいけないという例かな。
コメント1件

330
NAME IS NULL[sage]   投稿日:2016/03/01 15:55:57  ID:???.net(860)
フィクションの世界ということで

実際にはそのうち100件弱の商品を選んで表示する時らしい。
ユーザーから見たときは、各行がじわりじわりと表示されていたとかいないとか。
コメント2件

331
NAME IS NULL[sage]   投稿日:2016/03/01 15:56:19  ID:???.net(860)
「実装しかしないコーダー」というのだけで、俺にはファンタジーに見えるわ

332
NAME IS NULL[sage]   投稿日:2016/03/01 15:57:38  ID:???.net(860)
>323
何がしたいんだよお前は

333
NAME IS NULL[sage]   投稿日:2016/03/01 16:09:35  ID:???.net(860)
>330
もともと100件弱のテストをしたときは速度問題なかったんだよね。
つまり、商品コード取得クエリ1回+販売実績取得クエリ100回の構成で。

となると販売テーブルの商品コードにちゃんとインデックス貼ってるか、
そして使われているかを確認すべき状況かなぁ。
コメント7件

334
NAME IS NULL[sage]   投稿日:2016/03/01 16:14:21  ID:???.net(860)
JOINして取得するコードに変更しろよ

335
NAME IS NULL[sage]   投稿日:2016/03/01 16:15:00  ID:???.net(860)
いくらフィクションでもループにクエリ入れたくらいでそんな遅くはならんわ
全件取得して手元でフィルターかけてたら遅いだろうけど

336
NAME IS NULL[sage]   投稿日:2016/03/01 16:22:56  ID:???.net(860)
indexさえ張ってればループ内でクエリ発行しても問題ないだろ、と言いたいのかな

337
NAME IS NULL[sage]   投稿日:2016/03/01 16:26:31  ID:???.net(860)
インデックス張った上で、普通にJOINかサブクエリ使え
コメント1件

338
NAME IS NULL[sage]   投稿日:2016/03/01 16:29:09  ID:???.net(860)
>297
PofEAAって、初心者には無茶ですやん。

339
NAME IS NULL[sage]   投稿日:2016/03/01 16:49:23  ID:???.net(860)
>333
突っ込みどころ多すぎて、マジレスなのか釣りなのか判定不能なレベル
コメント2件

340
NAME IS NULL[sage]   投稿日:2016/03/01 17:47:06  ID:???.net(860)
このスレ初心者な奴が多いみたいだけど、このスレはクライアントアプリの設計を語るスレじゃありませんので。

341
NAME IS NULL[sage]   投稿日:2016/03/01 17:48:41  ID:???.net(860)
>323
想定見積件数が甘かったってだけだろ

今の回線とPC速度考えれば数万でも何分もかかるとは思えんと言うのは置いといて
さすがにその処理をホストアプリでやるのは不適切だけど
それに誰も気づかないで本番リリースする体制が一番の問題だな

342
NAME IS NULL[sage]   投稿日:2016/03/01 18:03:20  ID:???.net(860)
単なるかまってちゃんかもね

343
NAME IS NULL[sage]   投稿日:2016/03/01 18:05:55  ID:???.net(860)
相手したら負け。

344
NAME IS NULL[sage]   投稿日:2016/03/01 18:32:58  ID:???.net(860)
これは酷い (数年ぶりに書いた)

345
NAME IS NULL[sage]   投稿日:2016/03/01 20:10:39  ID:???.net(860)
>339
クエリ発行回数が変わらないにもかかわらず、異様に遅くなるということは
DB設計に問題があると判断できる。
その状況において、ループ内クエリを排除したところで、
ゆくゆくはユーザが体感するほどのパフォーマンス低下をむかえることになる。
つまり問題が表面化するのが速いか遅いかの違いでしかなかった。

もちろんループ内クエリを排除し、かつ、DB設計を適切なものにするべきだけれど、
ループ内クエリのみが悪という事例ではないはずだよ。
コメント7件

346
NAME IS NULL[sage]   投稿日:2016/03/01 21:44:13  ID:???.net(860)
>318
ダメだとは書いてないだろ。その本は利点と欠点の両方を挙げて説明してる。

347
NAME IS NULL[sage]   投稿日:2016/03/01 22:30:09  ID:???.net(860)
>345
> クエリ発行回数が変わらないにもかかわらず
ふぁ?
コメント1件

348
NAME IS NULL[sage]   投稿日:2016/03/01 23:14:05  ID:???.net(860)
1クエリで取得した方が速いものをわざわざ複数回のクエリで取得する奴はバカ。
そこまではいいが、1クエリにすりゃ何でも速くなると思ってる奴もバカ。

349
NAME IS NULL[sage]   投稿日:2016/03/02 00:30:43  ID:???.net(860)
>347
えっ状況理解できてない?

350
NAME IS NULL[sage]   投稿日:2016/03/02 10:16:24  ID:???.net(860)
あきらめろ。

「プロの俺様が今まで「ループ内でクエリを書いてはいけない」なんて言われたこと内のだから、それが真であるはずがない」

に賛同する奴はいない。

351
NAME IS NULL[sage]   投稿日:2016/03/02 10:20:32  ID:???.net(860)
>345
> クエリ発行回数が変わらないにもかかわらず、異様に遅くなるということは
> DB設計に問題があると判断できる。
は?
O(n^2)だからデータ数が多くなって問題が顕在化したというケースもあるだろ。
つまり、コードに問題があるケース。
コメント3件

352
NAME IS NULL[sage]   投稿日:2016/03/02 10:50:27  ID:???.net(860)
>345
> その状況において、ループ内クエリを排除したところで、
> ゆくゆくはユーザが体感するほどのパフォーマンス低下をむかえることになる。
> つまり問題が表面化するのが速いか遅いかの違いでしかなかった。
商品1万種×販売実績1,000万くらいだとしたら、普通にクエリ書いて適切なインデックス貼れば
パフォーマンス低下なんておこらんでしょ。
コメント1件

353
NAME IS NULL[sage]   投稿日:2016/03/02 10:59:06  ID:???.net(860)
スレ違いだということに、いつになったら気づくのか

354
NAME IS NULL[sage]   投稿日:2016/03/02 11:38:15  ID:???.net(860)
俺様には無理

355
NAME IS NULL[sage]   投稿日:2016/03/02 12:07:59  ID:???.net(860)
まず、ふさわしい話題を提供してから

356
NAME IS NULL[sage]   投稿日:2016/03/02 13:03:41  ID:???.net(860)
JOIN使うと死んじゃう病の人なの?

357
NAME IS NULL[sage]   投稿日:2016/03/02 13:09:16  ID:???.net(860)
>351
> 設計書には、「商品マスターから指定された条件にマッチする商品コードを取得する」、
> 「取得した商品コード一覧から販売テーブルを検索し販売実績を取得する」とあって、
> 実装を担当するコーダーは忠実にそのステップ通りに書きあげた。

>352
>333
コメント2件

358
NAME IS NULL[sage]   投稿日:2016/03/02 13:14:12  ID:???.net(860)
JOIN使うと死んじゃう病の人なの?
コメント1件

359
NAME IS NULL[sage]   投稿日:2016/03/02 13:14:59  ID:???.net(860)
>358
JOIN使っても遅くなることに気づけてないのかな
コメント1件

360
NAME IS NULL[sage]   投稿日:2016/03/02 13:16:08  ID:???.net(860)
>357
要するに、ループ内でクエリ発行しても問題ないと主張したいだけなんだな。

アホらし。
コメント1件

361
NAME IS NULL[sage]   投稿日:2016/03/02 13:17:04  ID:???.net(860)
>359
O(n)もO(n^2)もO(log n)も同じなんですね。
コメント2件

362
NAME IS NULL[sage]   投稿日:2016/03/02 13:20:22  ID:???.net(860)
>360
ループ内クエリを排除すべきとも書いたが。

>361
リリース当初とパフォーマンスが異様に低下した時点でのクエリ発行回数が同じというのは理解できたかな。
まず>329でO(n)の話かなと探りを入れたら>330でそうではないとのこと。
コメント1件

363
NAME IS NULL[sage]   投稿日:2016/03/02 13:25:05  ID:???.net(860)
>357
> >351
> > 設計書には、「商品マスターから指定された条件にマッチする商品コードを取得する」、
> > 「取得した商品コード一覧から販売テーブルを検索し販売実績を取得する」とあって、
> > 実装を担当するコーダーは忠実にそのステップ通りに書きあげた。
だったら、そのコードの設計が悪いね。
コメント1件

364
NAME IS NULL[sage]   投稿日:2016/03/02 13:29:28  ID:???.net(860)
>362
お前いったい誰と何の話してんの?

>339
> 突っ込みどころ多すぎて、マジレスなのか釣りなのか判定不能なレベル

>345
> クエリ発行回数が変わらないにもかかわらず、異様に遅くなるということは
> DB設計に問題があると判断できる。

>351
> は?
> O(n^2)だからデータ数が多くなって問題が顕在化したというケースもあるだろ。
> つまり、コードに問題があるケース。

要するに、>345の「〜と判断できる」がおかしいといってるわけ。

「異様に遅くなる」の原因は、
・ループ内でクエリを発行しているため
・インデックスがないため
の複合。

365
NAME IS NULL[sage]   投稿日:2016/03/02 13:35:15  ID:???.net(860)
念のため言っとくけど、

> ・インデックスがないため
これがO(n)の原因だからな。

366
NAME IS NULL[sage]   投稿日:2016/03/02 13:35:50  ID:???.net(860)
>363
そうだよ。少なくともコードの設計も悪い。
しかしそれだけならリリース当初に比べて「異様に遅く」なることは考えにくい。

とするとクエリの速度が著しく低下していることが予想されるので、>333となる。

367
NAME IS NULL[sage]   投稿日:2016/03/02 13:38:15  ID:???.net(860)
一番悪いのがコード(の設計)なんだが

368
NAME IS NULL[sage]   投稿日:2016/03/02 13:38:55  ID:???.net(860)
インデックスが貼られていない状況でもJOINしてれば遅くならないという考えでいいのかな
コメント1件

369
NAME IS NULL[sage]   投稿日:2016/03/02 13:40:26  ID:???.net(860)
適切なインデックスがありさえすれば、ホストコードでN+1問題が起こっても問題ないと。
コメント1件

370
NAME IS NULL[sage]   投稿日:2016/03/02 13:41:41  ID:???.net(860)
>368
> インデックスが貼られていない状況でもJOINしてれば遅くならないという考えでいいのかな
ホストコードでループするよりはまし。
コメント1件

371
NAME IS NULL[sage]   投稿日:2016/03/02 13:45:06  ID:???.net(860)
一体誰と闘ってるんだろう。
素直にJOINにしとけばいいのに。
コメント1件

372
NAME IS NULL[sage]   投稿日:2016/03/02 13:45:33  ID:???.net(860)
>369
リリース時点では速度要件を満たしていた。
ループ対象はいずれも100件程度。

適切なインデックスがあり、かつ使われていれば異様に遅くなることは考えにくく、
速度要件も満たしたままだっただろうということ。

リリース時点でのアプリが要件を満たしているもののイマイチ遅いのはループ内クエリの影響だろう。

>370
ましだが、遅くなる。
> その状況において、ループ内クエリを排除したところで、
> ゆくゆくはユーザが体感するほどのパフォーマンス低下をむかえることになる。
> つまり問題が表面化するのが速いか遅いかの違いでしかなかった。
コメント3件

373
NAME IS NULL[sage]   投稿日:2016/03/02 13:47:37  ID:???.net(860)
>372
> リリース時点では速度要件を満たしていた。

そもそも、これが大間違いなんだよ。
リリース時点でも性能要件は満たしていなかった。

ただそういうこと。

374
NAME IS NULL[sage]   投稿日:2016/03/02 13:48:41  ID:???.net(860)
>372
> 適切なインデックスがあり、かつ使われていれば異様に遅くなることは考えにくく、
> 速度要件も満たしたままだっただろうということ。

だったらなんでORM界隈でN+1問題が話題になるんだろうね。
彼らのデータベースにはインデックスがないのかね。

375
NAME IS NULL[sage]   投稿日:2016/03/02 13:55:57  ID:???.net(860)
>372
その「イマイチ遅い」というのが、100ms VS 1,000msだったりするんだけどね。

で、ボタンクリックから画面表示まで、httpリクエストからレスポンス完了までで累積すると
300ms VS 5,000msとかになるわけ。
コメント1件

376
NAME IS NULL[sage]   投稿日:2016/03/02 13:57:00  ID:???.net(860)
>375
リリース時点での話だよね。
事例でいくと5000msでユーザは許容していたということになる。
コメント1件

377
NAME IS NULL[sage]   投稿日:2016/03/02 14:01:14  ID:???.net(860)
>376
リリース時点での性能要件を満たすかどうか判定できる情報は出してないんでしょ。
100レコードでしか動作させてないんだから。

だから、5,000msをユーザが容認するかどうかなんてわからないじゃん。
まぁ、容認しないと思うけど。

378
NAME IS NULL[sage]   投稿日:2016/03/02 14:04:41  ID:???.net(860)
性能要件ってね、想定されるデータボリュームに対する応答速度を規定しないと意味ないの。

> 100種程度の商品マスターと、それぞれ20〜40程度の販売履歴を作成し

これがもう全然駄目。
性能要件を満たすかどうかを判定するなら、少なくともレコード数の条件くらいは満たしてないと。

379
NAME IS NULL[sage]   投稿日:2016/03/02 14:10:00  ID:???.net(860)
あらら、性能試験を理解していないことが証明されてしまった「俺様」

380
NAME IS NULL[sage]   投稿日:2016/03/02 14:27:29  ID:???.net(860)
たしかに性能要件という言葉を使ったのは失敗。
リリース時点では客からクレームが出るほど遅くはなかったのは事実。

JOINにしていれば件数が増えてもクレームが出るほど遅くはならずにすんだかもしれないけれど、
インデックス貼ってないんだとすれば、度合いの違いこそあれ件数に応じて速度が低下するのは予想できるよね。

性能試験を行ってれば、コード設計DB設計どちらにもミスがあることに気づけたと思う。

繰り返すけど、ループ内クエリが問題ないとは一度も書いてないよ。
コメント4件

381
NAME IS NULL[sage]   投稿日:2016/03/02 14:31:32  ID:???.net(860)
>380
>337で答え書いてるのに、何と闘ってるの?
コメント1件

382
NAME IS NULL[sage]   投稿日:2016/03/02 14:37:45  ID:???.net(860)
>380
> 度合いの違いこそあれ件数に応じて速度が低下するのは予想できるよね。
その速度の低下具合が、ループ内クエリにしてるか、JOINで一括取得してるかで全然違うんだが。
コメント1件

383
NAME IS NULL[sage]   投稿日:2016/03/02 14:43:53  ID:???.net(860)
>380
データベースの基本からやり直した方が良いよ。

E.F.Coddのお言葉:
> 「関係操作では、関係全体をまとめて操作の対象とする。目的は繰り返し(ループ)をなくすることである。
> いやしくも末端利用者の生産性を考えようというのであれば、この要件を欠くことはできないし、応用
> プログラマの生産性向上に有益であることも明らかである。」

クライアントでループしてデータを個別取得するなんて論外。
コメント1件

384
NAME IS NULL[sage]   投稿日:2016/03/02 14:51:51  ID:???.net(860)
>380
> リリース時点では客からクレームが出るほど遅くはなかったのは事実。

まだ言いますか。
性能を評価できるデータを出していなかっただけでしょ。
クライアントは機能外要件のことなんか気づかないことが多いんだから、こちらから言わないとね。
コメント1件

385
NAME IS NULL[sage]   投稿日:2016/03/02 15:02:22  ID:???.net(860)
> リリース時点では客からクレームが出るほど遅くはなかったのは事実。
客:なんか最近システムが重いんですが
俺様:調査します(調査費用Get)
俺様:データが想定以上に多くなっていますね。パフォーマンスを改善する改修をします?
客:お願いします
俺様:(改修費用Get)

386
NAME IS NULL[sage]   投稿日:2016/03/02 15:51:39  ID:???.net(860)
>381
それと同じことしか書いてない

>382
そうだね。でもインデックスを作成していなければやはり遅くなるからDB設計の不具合も修正すべき

>383
そうだね。ループ内クエリが問題ないとは書いてないよ。

>384
> 実際に使い始め、しばらく経つと〜異様に処理が重くなった
当初は問題ない応答速度だったと予想できる。
コメント2件

387
NAME IS NULL[sage]   投稿日:2016/03/02 15:57:34  ID:???.net(860)
>386
> それと同じことしか書いてない
じゃ、うざいんでレス止めて
コメント1件

388
NAME IS NULL[sage]   投稿日:2016/03/02 15:58:48  ID:???.net(860)
レビューはしってるのかな

389
NAME IS NULL[sage]   投稿日:2016/03/02 16:00:15  ID:???.net(860)
>386
> それと同じことしか書いてない
嘘つけ
お前、「プロの俺様が今まで「ループ内でクエリを書いてはいけない」なんて言われたこと内のだから、それが真であるはずがない」の俺様だろ
コメント2件

390
NAME IS NULL[sage]   投稿日:2016/03/02 16:00:18  ID:???.net(860)
>387
>333 >345でそのことを書いてんだけど、むしろ突っかかられてるんですがそれは。
コメント1件

391
NAME IS NULL[sage]   投稿日:2016/03/02 16:00:34  ID:???.net(860)
>389
うわ、まったくの他人
コメント1件

392
NAME IS NULL[sage]   投稿日:2016/03/02 16:02:22  ID:???.net(860)
>390
> >333 >345でそのことを書いてんだけど、むしろ突っかかられてるんですがそれは。
いやいやいや、違うこと(頓珍漢)なこと書いてんじゃん
お前が変なこと書かなければ、何かを言われることもない

393
NAME IS NULL[sage]   投稿日:2016/03/02 16:03:01  ID:???.net(860)
>391
残念
アホが一人かと思ったら二人いたのか

394
NAME IS NULL[sage]   投稿日:2016/03/02 16:03:10  ID:???.net(860)

395
NAME IS NULL[sage]   投稿日:2016/03/02 16:05:24  ID:???.net(860)
キモいわ

396
NAME IS NULL[sage]   投稿日:2016/03/02 16:08:48  ID:???.net(860)
最初から遅いのはループ内クエリのせいで、
件数が増えたときに劣化するのは適切なインデックスがないから。

異様に遅くなったのは適切なインデックスがないことによるパフォーマンス低下を、
ループ内クエリが増幅させた結果。
コメント1件

397
NAME IS NULL[sage]   投稿日:2016/03/02 16:15:44  ID:???.net(860)
>396
何度もそれ言われてるのに、さらに話を展開させたがるのは、一体何を主張したいのか

398
NAME IS NULL[sage]   投稿日:2016/03/02 16:20:23  ID:???.net(860)
これが言いたいんだと思うけど。

>333
> もともと100件弱のテストをしたときは速度問題なかったんだよね。

>361
> リリース当初

>371
> リリース時点では速度要件を満たしていた。

そんなの何の意味もないのに。

399
NAME IS NULL[sage]   投稿日:2016/03/02 16:21:00  ID:???.net(860)
安価間違えまくっとるw

400
NAME IS NULL[sage]   投稿日:2016/03/02 16:23:06  ID:???.net(860)
なので、リリース当初は問題なかったのだから、ループ内でクエリ発行しても問題ないだろ、
という主張をしたいのだと思ったが、そうでないとすると一体何だったのか。
コメント1件

401
NAME IS NULL[sage]   投稿日:2016/03/02 16:30:11  ID:???.net(860)
>304-310が承認欲求で暴れてるのだと思ったが。
コメント1件

402
NAME IS NULL[sage]   投稿日:2016/03/02 16:46:22  ID:???.net(860)
>400
適切なインデックスがあればリリース当初と比べて異様に遅くなるということはなかっただろうね。

>401
その中にもいないよ。外れてばかりだね
コメント1件

403
NAME IS NULL[sage]   投稿日:2016/03/02 16:51:27  ID:???.net(860)
>402
> 適切なインデックスがあればリリース当初と比べて異様に遅くなるということはなかっただろうね。
最初に性能測定してれば、リリース当初から問題があることがわかっただろうがね。
コメント1件

404
NAME IS NULL[sage]   投稿日:2016/03/02 16:57:31  ID:???.net(860)
どう見てもど素人でした。
ありがとうございました。

405
NAME IS NULL[sage]   投稿日:2016/03/02 16:59:53  ID:???.net(860)
>403
最初に性能測定をしていない状態でリリースし、問題が発生し、その調査を行うというストーリーが前提でしょ
コメント1件

406
NAME IS NULL[sage]   投稿日:2016/03/02 17:13:38  ID:???.net(860)
>405
だったら、Slow Queryログを見るのがまずやること。
残念なことに、thresholdを500msとかにしとくと、ループ内クエリの場合ログが出力されない
場合がある(累積処理時間が長いだけで、個々のクエリは100msかそこらで終わってたり)

次にコードを見て該当クエリを発見し、実行計画を調べる。
今回の場合は、そこでコードが糞ってすぐわかるが。

インデックスが使われてるかどうかだけじゃ、わからないことがあるんだよ。
ほれ、適切なインデックスが使われてるにも関わらず遅いクエリの例。
http://explain.depesz.com/s/1icN
コメント2件

407
NAME IS NULL[sage]   投稿日:2016/03/02 17:23:30  ID:???.net(860)
>406
まったくそのとおり。
クエリ発行回数が変わっていないという情報も加味すれば
個々のクエリが遅くなっている可能性が高まるよね。
(もちろんコードも悪いよ。コードも悪いが、それのみじゃ異様に遅くはならない)

状況的にもnested loopが使われることもないクエリだろう。
コメント2件

408
NAME IS NULL[sage]   投稿日:2016/03/02 17:24:27  ID:???.net(860)
コードが悪いんだったら、まずそこから改善しようよ・・・
コメント1件

409
NAME IS NULL[sage]   投稿日:2016/03/02 17:27:07  ID:???.net(860)
>406
ちなみにこの糞クエリは、俺様が書き直したら2,000msから50msくらいになったわ。

410
NAME IS NULL[sage]   投稿日:2016/03/02 17:43:00  ID:???.net(860)
俺様登場

411
NAME IS NULL[sage]   投稿日:2016/03/02 17:45:09  ID:???.net(860)
>408
運用中のサービスに対して、
・インデックスを作成すればリリース当初とさほど変わらないレスポンスに戻る
・コードを修正すれば速度が改善される
 →この結果リリース当初よりも速くなるか、リリース当初よりも遅くなるかの判断はまだできない
という二つの対応方法があって、二つともやるべきだと。

それなら、先にやれるのはインデックス作成でしょ。
コード修正優先なの?


> ユーザーから見たときは、各行がじわりじわりと表示されていたとかいないとか。
ということだから、1件取得表示するのに200ms近くかかっているかもしれない。

インデックスを作成しない場合、商品コードをもとに販売テーブルを検索する機能がほかにあれば
それらも少なからず影響を受けているんだろう。
コメント3件

412
NAME IS NULL[sage]   投稿日:2016/03/02 17:48:30  ID:???.net(860)
インデックスなんてあって当たり前なんで
インデックス作成しよう、なんて意見が出ること自体異常
コメント1件

413
NAME IS NULL[sage]   投稿日:2016/03/02 17:50:31  ID:???.net(860)
>411
ははぁ、動いてるコードは触るな教の人だな。
俺なら絶対にコードも修正するから、既存コードを速くすることなんてしないよ。
コメント1件

414
NAME IS NULL[sage]   投稿日:2016/03/02 17:51:42  ID:???.net(860)
どうせ後から後からSlow Query, Slow Responseが多発するんだろうからさ、
問題が見つかったら元から改善しとかないと。

415
NAME IS NULL[sage]   投稿日:2016/03/02 17:54:10  ID:???.net(860)
>412
それがないから起こった事象だととらえるのが自然じゃないかな。
適切なインデックスはあるはずだし、ループ内クエリそれのみが問題だとするならそう主張すればいいと思うよ。

>413
触るななんて書いてない。なんでそう曲解するんだろ。
ところで、コードを修正するけど既存コードを速くしないってどういうこと?
コメント1件

416
NAME IS NULL[sage]   投稿日:2016/03/02 17:54:14  ID:???.net(860)
>411
>  →この結果リリース当初よりも速くなるか、リリース当初よりも遅くなるかの判断はまだできない
まだ言ってんの?
速くなるに決まってるじゃん。
遅くなるとしたらなんでよ?
コメント1件

417
NAME IS NULL[sage]   投稿日:2016/03/02 17:55:26  ID:???.net(860)
>416
結合カラムにインデックスがないから
コメント1件

418
NAME IS NULL[sage]   投稿日:2016/03/02 17:57:10  ID:???.net(860)
>415
> ところで、コードを修正するけど既存コードを速くしないってどういうこと?
「既存コードで」の間違い。

419
NAME IS NULL[sage]   投稿日:2016/03/02 17:58:33  ID:???.net(860)
>417
もともとインデックスが無い場合の話だろ?
何言ってるの?
コメント1件

420
NAME IS NULL[sage]   投稿日:2016/03/02 18:01:19  ID:???.net(860)
>419
だからJOINにしたところで、JOINも少なからずパフォーマンス低下しているといってる。
nested loop joinされちゃうよね、と。

421
NAME IS NULL[sage]   投稿日:2016/03/02 18:02:33  ID:???.net(860)
ちなみに販売テーブル.商品コードにインデックスがあるかどうかは>333で俺が予想したものに過ぎないよ。

422
NAME IS NULL[sage]   投稿日:2016/03/02 18:02:59  ID:???.net(860)
うわ、「クエリ実行回数が多いのが大問題」というのがわかってなかった
コメント1件

423
NAME IS NULL[sage]   投稿日:2016/03/02 18:03:47  ID:???.net(860)
>422
それが大問題になるほどO/RMのコストを無視できないのなら、開発段階の100回発行時点で気づくだろと。
コメント1件

424
NAME IS NULL[sage]   投稿日:2016/03/02 18:26:40  ID:???.net(860)
>423
レコード数が多くなったのが問題を引き起こしたんだよ。

お前の為にコード書いてやったわ。

table1: 400行くらい
table2: 40万行くらい

table1のうちの59レコードに対するtable2のレコードを取得する。

select table1してループ内クエリでselect table2するコード:
$ time hoge

real 0m3.466s
user 0m0.261s
sys 0m0.044s
(ループ1回あたり60ms弱)

table1とtable2をjoinするコード:
$ time fuga

real 0m0.176s
user 0m0.069s
sys 0m0.033s

後者のクエリの実行計画等:
http://explain.depesz.com/s/26VK

わかったか、アホめ。
コメント2件

425
NAME IS NULL[sage]   投稿日:2016/03/02 18:29:49  ID:???.net(860)
ちなみに、プログラムが動くサーバとDBは同じサーバ内だからな。
ネットワークのレイテンシが問題というわけではない。

426
NAME IS NULL[sage]   投稿日:2016/03/02 18:38:09  ID:???.net(860)
>424
前者の実行計画は普通にseq scanかな。
index作成するとどうなるの
コメント1件

427
NAME IS NULL[sage]   投稿日:2016/03/02 18:41:55  ID:???.net(860)
>426
自分でt試せ、アホが。
コメント2件

428
NAME IS NULL[sage]   投稿日:2016/03/02 20:23:55  ID:???.net(860)
>どこいっても根拠の無い断定意見と検証しろ的回答しかこないね

429
NAME IS NULL[sage]   投稿日:2016/03/02 20:35:28  ID:???.net(860)
上でJOINがどうこうって話が出てきて不思議に思ってたんだが、こんなアホな例を想定してたのか。
WHERE key = ... の繰り返しと WHERE key IN ( ... ) 1回で済ませるのとのどっちが速いかって話かと思ってた。>311

430
NAME IS NULL[sage]   投稿日:2016/03/02 21:59:16  ID:???.net(860)
クエリのコストだけ。

A table_1 から100件抽出
B table_2 から1件抽出
C トータル (A + B*100)
D join

●インデックスなし
table_1件数 table_2件数 各時間
100 100*100 A 0.09msec B 1.8msec C 180.09msec D 20msec
500 500*1000 A 0.17msec B 86msec C 8600.17msec D 666msec
10000 10000*5000 A 2.2msec B 15900msec C 1590002.2msec D 64800msec

●インデックスあり
table_1件数 table_2件数 各時間
100 100*100 インデックスあり A 0.09msec B 0.09msec C 9.09msec D 19msec
500 500*1000 インデックスあり A 0.17msec B 0.76msec C 76.17msec D 200msec
10000 10000*5000 インデックスあり A 2.2msec B 3msec C 302.2msec D 971msec

インデックスを作らない場合はCはかなり遅くなり、Dもまた遅くなる
インデックスを作る場合はCもDも異様に遅くなりはしない。

比較対象はひとまず、インデックスなしのD(コード改善のみ) と インデックスありのC(インデックス作成のみ)でいいよね。

データ件数が多い場合、コード改善のみだと64800msec、インデックス作成のみだと302msec。

※Cの場合はこれにくわえてDBアクセスライブラリのコストがデータ件数によらず100回分余分に足される

431
NAME IS NULL[]   投稿日:2016/03/02 22:12:22  ID:ymvRmzXh.net
フレッシュマンに贈るデータベースプログラミング入門スレかここはw

432
NAME IS NULL[sage]   投稿日:2016/03/02 22:43:53  ID:???.net(860)
あ、Dはもちろん商品コード100件分抽出。

433
NAME IS NULL[sage]   投稿日:2016/03/03 04:30:46  ID:???.net(860)
新人教育で教えてもらった高説を垂れ流してる子は>323と同一人物なの?

434
NAME IS NULL[sage]   投稿日:2016/03/03 07:07:33  ID:???.net(860)
この言い合いに負けたら
しんじゃうんだろうなってぐらい必死で
笑えるな

435
NAME IS NULL[sage]   投稿日:2016/03/03 09:48:36  ID:???.net(860)

436
NAME IS NULL[sage]   投稿日:2016/03/03 10:15:34  ID:???.net(860)
>435
違うよ。
俺様=>271=>424だ。途中で人格変えたがな。

>411みたいなアホの相手するの面倒なんで、書籍を探してるってわけ。
コメント2件

437
NAME IS NULL[sage]   投稿日:2016/03/03 10:40:49  ID:???.net(860)
いい加減にしましょうね

438
NAME IS NULL[sage]   投稿日:2016/03/03 10:48:39  ID:???.net(860)
杓子定規でループで使うなと言ったって身につかんわ
こういうケースではこうするという事例さえ覚えていけば応用効くっしょ
コメント1件

439
NAME IS NULL[sage]   投稿日:2016/03/03 11:10:36  ID:???.net(860)
>436
は?何勝手に俺様騙ってんだよ、俺が俺様だ

440
NAME IS NULL[]   投稿日:2016/03/03 12:27:20  ID:BwEBd+t3.net
ふざけるな、お前が俺様なら俺様は何様だって言うんだよ!

441
NAME IS NULL[sage]   投稿日:2016/03/03 15:52:44  ID:???.net(860)
自演臭がすごいので次スレからはID表示にしよか。
コメント1件

442
NAME IS NULL[sage]   投稿日:2016/03/03 16:10:49  ID:???.net(860)
ID表示してもごまかすやつがいる

443
NAME IS NULL[sage]   投稿日:2016/03/03 17:06:54  ID:???.net(860)
でも効果がないわけではない

444
NAME IS NULL[sage]   投稿日:2016/03/03 17:15:58  ID:???.net(860)
次スレって言っても半年後くらいだろ
覚えてる奴いないレベルw


445
NAME IS NULL[sage]   投稿日:2016/03/03 17:20:18  ID:???.net(860)
新人教育で教えてもらった高説ってどの話?

446
NAME IS NULL[sage]   投稿日:2016/03/03 17:38:24  ID:???.net(860)
>438
> こういうケースではこうするという事例さえ覚えていけば応用効くっしょ

そんなめんどくさいことしなくていいよ。

「ループ内でクエリを発行するな」
これだけでいい。

447
NAME IS NULL[sage]   投稿日:2016/03/03 17:39:28  ID:???.net(860)
>441
ID表示にできるんならしようぜ

448
NAME IS NULL[sage]   投稿日:2016/03/03 17:46:40  ID:???.net(860)

449
NAME IS NULL[sage]   投稿日:2016/03/03 17:47:20  ID:???.net(860)
プリペアドステートメントでループでパラメタ変えながら呼ぶやつはどうなの
コメント1件

450
NAME IS NULL[sage]   投稿日:2016/03/03 17:50:20  ID:???.net(860)
世の中にはindexの存在も知らずに、データベース関連のプログラム書いてる人もいるみいだからね
http://blog.xao.jp/blog/mysql/mysql%E3%81%AE%E8%B6%85%E9%81%85%E...
こんな人、ごろごろいそう
コメント1件

451
NAME IS NULL[sage]   投稿日:2016/03/03 17:51:47  ID:???.net(860)
ってスレ違いか
この手の話は、やっぱム板なのかな

452
NAME IS NULL[sage]   投稿日:2016/03/03 17:53:08  ID:???.net(860)
インデックスを作るのを後回しにしてロジック直すのが根本的な対応だと思ってる人もいたようで

453
NAME IS NULL[sage]   投稿日:2016/03/03 17:53:35  ID:???.net(860)

454
NAME IS NULL[sage]   投稿日:2016/03/03 17:54:41  ID:???.net(860)
ム板ならID出るし、続きやりたい人は移動よろ

455
NAME IS NULL[sage]   投稿日:2016/03/03 17:56:19  ID:???.net(860)

456
NAME IS NULL[sage]   投稿日:2016/03/03 18:02:30  ID:???.net(860)
100回くらいなら、ループしても問題ないと思ったんだが。
PostgreSQL+PHPで試した。

for ($i = 0; $i < 100; $i++) {
  $sql = 'SELECT CURRENT_DATE';
  $stmt = $db->query($sql);
  $row = $stmt->fetch(PDO::FETCH_ASSOC);
}
実行時間 0.077秒

457
NAME IS NULL[sage]   投稿日:2016/03/03 18:08:19  ID:???.net(860)
>450
DBMS固有の仕様を知らなかったという記事を、indexの存在を知らない人の記事だと読み替える技術に感服
コメント1件

458
NAME IS NULL[sage]   投稿日:2016/03/03 18:22:05  ID:???.net(860)
>457
固有じゃないよ
大抵そうでしょ
絡むの順番大事
コメント1件

459
NAME IS NULL[sage]   投稿日:2016/03/03 18:26:40  ID:???.net(860)
>458
カラムの順番は大事だけど、この記事のケースだと少なくともPostgreSQLだったらindexは使われるよ。
MySQLが特殊なのか、PostgreSQLが特殊なのかはわからないけど。

460
NAME IS NULL[sage]   投稿日:2016/03/03 18:28:05  ID:???.net(860)
いい加減、適当なこと言うの止めろよ

461
NAME IS NULL[sage]   投稿日:2016/03/03 18:37:43  ID:???.net(860)
MySQLがこんなひどい仕様だとは知ららなかったわ、、、

462
NAME IS NULL[sage]   投稿日:2016/03/03 18:46:53  ID:???.net(860)
MySQLがひどい仕様だという表現はいかがなものかと。
有名な拡張であるgroup by に指定していないカラムを集約関数抜きに抽出できるのは、支持される側面もある。
気持ち悪いだろと非難される側面でもあるけれど。
PostgreSQLはいつぞやにその拡張を部分的に取り込んだりしたよ。
コメント1件

463
NAME IS NULL[sage]   投稿日:2016/03/03 21:15:11  ID:???.net(860)
>436
なんで>280を抜かすw

464
NAME IS NULL[sage]   投稿日:2016/03/04 08:30:42  ID:???.net(860)
>462
指定しなくても一意であることが分かっている列を指定しなくてもいいのは便利だが、
ひどいのはそこじゃないからな。
一意制約条件なんかを見て(標準でも独自でもいい)指定可能列を制限する。
そこまでやってたらMySQLスゲーって言って貰えるよ。

465
NAME IS NULL[sage]   投稿日:2016/03/04 14:28:53  ID:???.net(860)
どうでもいいけど、「カラム」なのか「フィールド」なのかどっち使うべきなの?
参考書とかではフィールドだけど、ネットではカラムが多い気がする
コメント1件

466
NAME IS NULL[sage]   投稿日:2016/03/04 17:14:02  ID:???.net(860)
>465
大抵のDBだとadd columnだから、カラムでいいんじゃないの

467
NAME IS NULL[sage]   投稿日:2016/03/04 23:32:18  ID:???.net(860)
話は変わるけど

DB設計の入門書

を教えて
コメント1件

468
NAME IS NULL[sage]   投稿日:2016/03/04 23:45:00  ID:???.net(860)
「達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ」

ってのがググった中で一番多く話題になってた
だが、俺的には物足りないけど。
コメント1件

469
NAME IS NULL[sage]   投稿日:2016/03/04 23:50:46  ID:???.net(860)
>468
ありがとう

470
NAME IS NULL[sage]   投稿日:2016/03/05 00:37:42  ID:???.net(860)
入門が終わったら応用効かせられるよう頑張ればいいさ

471
NAME IS NULL[sage]   投稿日:2016/03/06 19:00:38  ID:???.net(860)
>467
漢の人の本なんかいいんじゃないか
コメント1件

472
NAME IS NULL[sage]   投稿日:2016/03/07 18:35:04  ID:???.net(860)
>471
それ入門書じゃない
コメント1件

473
NAME IS NULL[sage]   投稿日:2016/03/07 19:28:51  ID:???.net(860)
>472
技評の本は、入門と書いてあっても、中身は初心者を寄せ付けませんw

聞いた話によると、著者の考えたタイトルは大抵ボツになるそうで、出版社からは入門と付けられてしまうらしい。

タイトルに入門と書いてあるだけで、1割から2割売り上げ伸びるとのことだよ

474
NAME IS NULL[sage]   投稿日:2016/03/08 14:26:04  ID:???.net(860)
そんなに差があるのか。
入門や初心者本って類似品が多いから、あまり売れないと思ってたよ

475
NAME IS NULL[sage]   投稿日:2016/03/08 18:05:30  ID:???.net(860)
入門者レベルが一番パイがでかいからな

476
NAME IS NULL[sage]   投稿日:2016/03/08 18:08:46  ID:???.net(860)
『グラス片手にデータベース設計』というのがいいらしい
読んでないけど

477
NAME IS NULL[sage]   投稿日:2016/03/08 21:19:35  ID:???.net(860)
どっかの雑誌に連載してたやつか?
コメント1件

478
NAME IS NULL[sage]   投稿日:2016/03/08 21:58:40  ID:???.net(860)
そういう本が出てるよ

479
NAME IS NULL[sage]   投稿日:2016/03/08 23:46:11  ID:???.net(860)
>477
DBマガジン

480
NAME IS NULL[]   投稿日:2016/03/09 00:12:49  ID:Vr1C3X/7.net
最近はめちゃくちゃなデータモデルが流行っているのか?
コメント1件

481
NAME IS NULL[sage]   投稿日:2016/03/09 03:23:17  ID:???.net(860)
例えば?

482
NAME IS NULL[sage]   投稿日:2016/03/11 18:38:46  ID:???.net(860)
id

483
NAME IS NULL[sage]   投稿日:2016/03/22 18:15:13  ID:???.net(860)
自然キーに関する質問です。
自然キーを使う場合(で、基本的にコードがキーになる場合)、
table_a: {a_code(PK), ...}
table_b: {a_code(PK), b_code(PK), ...}
table_c: {a_code(PK), b_code(PK), c_code(PK), ...}
みたいなことになることが多いと思うんですが、
* それはそういうものだからそうしろ
* それはお前の勘違い
のどちらなんでしょうか。

484
NAME IS NULL[sage]   投稿日:2016/03/22 21:03:42  ID:???.net(860)
何が聞きたいのかわからない

自然キーなら複合キーになる事が多いって事?
ならそれはそういうものだろう
コメント1件


485
NAME IS NULL[sage]   投稿日:2016/03/22 21:28:25  ID:???.net(860)
>480
RDB設計からKVS設計は色々違和感あるな
RDBだけでゴミ設計なんて数多くあるけど

486
NAME IS NULL[]   投稿日:2016/03/22 22:50:55  ID:XCbF2Frf.net
データモデリングができる要員を確保しないプロジェクトが多すぎる。

DBAも勉強しないやつらばかりだし。

487
NAME IS NULL[sage]   投稿日:2016/03/23 11:05:10  ID:???.net(860)
>484
> 何が聞きたいのかわからない
> 自然キーなら複合キーになる事が多いって事?
うーん、多いか少ないかが疑問なのではなく、多くなっても親テーブル(というと語弊があるかも)の主キーを
引きずって子テーブルを作るのが普通なのかなというのが疑問です。

table_cが何かの要求で、それに対する結果テーブルが必要なとき、
table_c: {a_code(PK), b_code(PK), c_code(PK), some_column(PK), ...}
とやっていくと、どんどん主キーカラムが増えてくんです。

そういうのは普通なんでしょうか。
それとも何か他の手段があるんでしょうか。
コメント1件

488
NAME IS NULL[sage]   投稿日:2016/03/23 11:23:32  ID:???.net(860)
外部キーの話をしてるのかな?
よくわからん、、、もうちょっと具体的な例を・・・
コメント1件

489
NAME IS NULL[]   投稿日:2016/03/23 12:34:09  ID:wWOU9ETa.net
>487
自然キーてそういうもん
回避策とか考えるとそれは必然的に代理キーになる
面倒くさいのは混在してるDBだな
コメント1件

490
NAME IS NULL[sage]   投稿日:2016/03/23 13:09:26  ID:???.net(860)
>488
例えば、路線があって(既に路線コード="0001"〜が割り振られている)、路線上に測定点(既に路線毎に
"0001"〜が割り振られている)があるとき、
路線: {路線コード(PK), ...}
測定点: {路線コード(PK), 測定点コード(PK), ...}

これにたいして、測定の発注があり(路線と測定点を選択する)、
測定発注: {発注コード(PK), ...}
発注測定点: {発注コード(PK), 路線コード(PK), 測定点コード(PK), ...}

測定は複数あり
測定: {測定コード(PK), ...}

発注測定点ごとに複数の測定を行い
発注測定点測定: {発注コード(PK), 路線コード(PK), 測定点コード(PK), 測定コード(PK), ...}

発注測定点測定ごとに結果があるとき、
測定結果: {発注コード(PK), 路線コード(PK), 測定点コード(PK), 測定コード(PK), ...}

みたいな設計を自分ならすると思うんですが、何か間違ってるきがするんです。
コメント2件

491
NAME IS NULL[sage]   投稿日:2016/03/23 13:18:58  ID:???.net(860)
>489
> 回避策とか考えるとそれは必然的に代理キーになる
本とかブログとか見ると、代理キーは使うなという人が多くて、使うのに躊躇しています。

492
NAME IS NULL[sage]   投稿日:2016/03/23 13:26:04  ID:???.net(860)
>490
俺ならサロゲートキーを使うな

493
NAME IS NULL[sage]   投稿日:2016/03/23 15:51:20  ID:???.net(860)
>490
その例、完全に想像上の産物なのか、過去のプロジェクトあつかったものなのか、これから作る
プロジェクトのものなのかわからないけど、「路線廃止」とか「測定点廃止」のこと考えとかないと
死ぬよ。

494
NAME IS NULL[sage]   投稿日:2016/03/23 16:22:34  ID:???.net(860)
廃止されたら削除フラグに1立てとけばいいよ

495
NAME IS NULL[sage]   投稿日:2016/03/23 16:39:01  ID:???.net(860)
それはこっちで

削除フラグの要否について語るスレ [転載禁止](c)2ch.net
削除フラグの要否について語るスレ

496
NAME IS NULL[sage]   投稿日:2016/03/23 17:06:32  ID:???.net(860)
自分が言った食べ物屋さんを管理したい
・住所 not null
・店名 not null
・タイプ(たこ焼き屋、焼き鳥屋、飲み屋、バーなどいくつも増やしていく予定) not null
・軽度と緯度 not null
・HP

こういう場合いつもなら1テーブルに全てのカラムを突っ込んで作ってたんですが、
先輩方ならテーブルとカラムをどのように作るのかアドバイスをください
コメント5件

497
NAME IS NULL[sage]   投稿日:2016/03/23 17:18:17  ID:???.net(860)
>496
いつ行ったかはいらんの?
コメント1件

498
NAME IS NULL[sage]   投稿日:2016/03/23 17:18:50  ID:???.net(860)
>496
1テーブルでいいと思うよ。

499
NAME IS NULL[sage]   投稿日:2016/03/23 17:29:20  ID:???.net(860)
>407
仮にそれを管理するなら別テーブルにすべきだと思うが、ただそれはデータベース設計の話ではなく要件定義の話なのでスレ違いだ。

500
NAME IS NULL[sage]   投稿日:2016/03/23 17:29:59  ID:???.net(860)
そのうち何度も何度も同じ項目を書くようになったら気がつくだろうしそれからでいいね

501
NAME IS NULL[sage]   投稿日:2016/03/23 17:30:13  ID:???.net(860)
>407
>497

502
NAME IS NULL[]   投稿日:2016/03/23 17:31:30  ID:O0URZ4Cw.net
>496
タイプをマスタテーブルとして分離するくらいだな。

503
NAME IS NULL[sage]   投稿日:2016/03/23 18:35:44  ID:???.net(860)
>496
単に行った店を管理するだけならそれでいいと思う
まあ、Excel でもいいと思うが...
何を食べたとか、値段とか、うまかったとかの情報は要らんの?

504
NAME IS NULL[sage]   投稿日:2016/03/23 18:41:50  ID:???.net(860)
ぼっちで行っても嫌そうな顔をされなかったか、も欲しい

505
NAME IS NULL[sage]   投稿日:2016/03/23 19:06:57  ID:???.net(860)
かわいい店員がいたかどうかも追加で

公開すれば意外と需要があるかもw

506
NAME IS NULL[sage]   投稿日:2016/03/23 19:44:53  ID:???.net(860)
>496
おれはgooglemapで管理してる
コメント1件

507
NAME IS NULL[]   投稿日:2016/03/23 20:15:01  ID:Y1xGecwA.net
               【TPP断固反対(嘘)】   自由ホランチョ党   【スタンフォード(嘘)】



              安倍首相がスタンフォード大前で「嘘つき安倍は帰れ!」と抗議を受ける
                     https://www.youtube.com/watch?v=HkMjwggu3ko
  安倍総理、麻生副総理も経歴詐称? 海外留学の経歴が削除されていた! 「学歴詐称」は公職選挙法違反


                 【日本の金正恩】      安倍寛信      【安倍晋三の兄】

   復活した電力会社の原発広告に文化人や芸能人がまたぞろ登場して原発をPR! 500万円の高額ギャラも    勝間和代 三橋貴明 佐藤優
       三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信 三菱重工の重役でもあるらしい
     これがフクイチで核弾頭ミサイルを製造していた疑惑がある 書けばツイッターで速攻削除されている
                 ネットにおける言論統制は、非公然で陰湿に進んでいるようです
                 https://twitter.com/toka iamada/status/664017453324726272


                                  山本太郎

                           先ず真のテロリズムと戦うべき!
汚染物質をバラ撒き、国民を無理心中へと巻き込む政治家、経済団体等をテロ指定、資産凍結するのが筋ではないか!


                             【だってお金欲しいもん〜】

               今朝、辺野古で新基地建設に反対するママの会メンバーに対して、
            機動隊員が「お前たちには汚い血が流れている」などと暴言を吐いたそうです。
       自分のやっていることを「だってお金欲しいもん〜」「俺の写真を待ち受けにしろ」とも (顔写真)
               https://twitter.com/MothersNoWar/status/690357793702940672

508
NAME IS NULL[sage]   投稿日:2016/03/23 22:58:13  ID:???.net(860)
タイプをマスタとして分離するかどうかは正規化と関係ないけどね
コメント2件

509
NAME IS NULL[sage]   投稿日:2016/03/23 23:04:16  ID:???.net(860)
>506
GoogleMapのURL入れたいな

510
NAME IS NULL[]   投稿日:2016/03/23 23:07:43  ID:MmqjKcCk.net
>508
正規化なんて分かってないやつがすぐ言う言葉だよな。

511
NAME IS NULL[sage]   投稿日:2016/03/23 23:37:41  ID:???.net(860)
またこいつか

512
NAME IS NULL[sage]   投稿日:2016/03/24 02:16:58  ID:???.net(860)
半年以上書き込みないのにMongoがまだ上のほうにあるなんて・・・
この板全然機能してないね
はてMongoの話したかったんだけどどうしたものか・・・
コメント1件

513
NAME IS NULL[sage]   投稿日:2016/03/24 05:40:54  ID:???.net(860)
>512
Mongoいいよな
RDB脳でも直感的に使える
でもKVSの主流からは外れてる感じが凄いんだよねぇ

514
NAME IS NULL[sage]   投稿日:2016/03/24 09:12:45  ID:???.net(860)
>508
SQLアンチパターンにあったな
31フレーバーだっけ

515
NAME IS NULL[sage]   投稿日:2016/03/31 14:37:59  ID:???.net(860)
新人に手っ取り早く仕込まなきゃいかんのだが
実際やって一番腕上がったなって実感できたことって何だった?
コメント1件

516
NAME IS NULL[]   投稿日:2016/03/31 14:44:49  ID:dIu8YOjZ.net(3)
>515
新人って新卒のことか?

517
NAME IS NULL[sage]   投稿日:2016/03/31 14:50:57  ID:???.net(860)
郵便番号辞書の取り込みと検索システム、、、あんま設計の比重高くないか

518
NAME IS NULL[sage]   投稿日:2016/03/31 15:52:43  ID:???.net(860)
仮で、社員管理システムとか本の貸出履歴の設計とかさせればいいんじゃね
本にもテーマになること多いし。

519
NAME IS NULL[sage]   投稿日:2016/03/31 15:59:52  ID:???.net(860)
会議室予約というのも役に立つし、それなりに面白いぞ

520
NAME IS NULL[sage]   投稿日:2016/03/31 16:05:47  ID:???.net(860)
何を作るにしても、プロダクションレベルにするのは無理だろうね

521
NAME IS NULL[]   投稿日:2016/03/31 16:06:44  ID:dIu8YOjZ.net(3)
どういうレベルの新人なのか分からないと話にならない。

522
NAME IS NULL[]   投稿日:2016/03/31 16:08:10  ID:dIu8YOjZ.net(3)
そもそもDB設計がまともにできる人がいないのに何いってんの?

523
NAME IS NULL[sage]   投稿日:2016/03/31 16:44:55  ID:???.net(860)
RDBとは何かw

524
NAME IS NULL[sage]   投稿日:2016/03/31 16:45:37  ID:???.net(860)
実際に何かやらせるより、書籍与えて勉強させる方がよっぽどいい

525
NAME IS NULL[]   投稿日:2016/03/31 20:30:43  ID:VSMU+gxH.net
なにが「新人に仕込まなきゃいかん」だよ
素直に自分が勉強したいから教えてくださいって言えよw

526
NAME IS NULL[sage]   投稿日:2016/03/31 22:16:18  ID:???.net(860)
書籍与えても読解力がないと身につかないからなぁ。
それより課題与えて目に見える形で学ばせる方が身につく

527
NAME IS NULL[sage]   投稿日:2016/03/31 22:20:53  ID:???.net(860)
書籍与えてみる
自分で考えて作らせてみる
懇切丁寧に説明して作らせてみる
諦める

528
NAME IS NULL[sage]   投稿日:2016/03/31 22:26:28  ID:???.net(860)
新人教育ありまーすw
コメント1件

529
NAME IS NULL[sage]   投稿日:2016/03/31 22:41:09  ID:???.net(860)
>528
うちなんて新人教育前面に押し出してるけど全部俺に押し付けるだけだし
コメント1件

530
NAME IS NULL[sage]   投稿日:2016/03/31 22:49:48  ID:???.net(860)
>529
ご苦労様

531
NAME IS NULL[sage]   投稿日:2016/04/03 13:06:44  ID:???.net(860)
こういうことをやる時はこういう設計にするっていうサンプルが載ってるサイトありませんか?
コメント2件

532
NAME IS NULL[sage]   投稿日:2016/04/03 14:14:33  ID:???.net(860)
チャート式DB設計w

533
NAME IS NULL[sage]   投稿日:2016/04/03 17:05:36  ID:???.net(860)
そういうサイトって意外とないよな
前に海外サイトであった気がするけど、だいぶ前に更新止まってた

534
NAME IS NULL[]   投稿日:2016/04/03 17:35:42  ID:fk/TJrkc.net
>531
ない。

オブジェクト指向設計と同じようにクラスをテーブルに見立てて、意味のある単位で項目をまとめて、リレーションを作る。

正解がないので基本的にはいろんなシステムを見ていないと難しい。

535
NAME IS NULL[sage]   投稿日:2016/04/03 17:49:09  ID:???.net(860)
ゆとりに優しくしろよw

536
NAME IS NULL[sage]   投稿日:2016/04/03 18:59:07  ID:???.net(860)
健全でない言葉が含まれているため表示しません 内容を確認する

537
NAME IS NULL[sage]   投稿日:2016/04/03 19:04:02  ID:???.net(860)
知らないならレスしないでください

538
NAME IS NULL[]   投稿日:2016/04/03 20:29:45  ID:wqLTVuK2.net(6)
正規化にこだわるな。

運用・保守を考えると冗長的にデータを持っていた方がいい。

データ量が多くなることをおそれるな。

重複したデータを別に持っていてもいい。

無理に外部キー制約を作るな。

リレーションにこだわるな。
コメント1件

539
NAME IS NULL[]   投稿日:2016/04/03 20:31:48  ID:wqLTVuK2.net(6)
ER図を見ただけで業務がある程度、想像できないデータモデルはクソである。

540
NAME IS NULL[]   投稿日:2016/04/03 20:42:38  ID:DppsG1GM.net(3)
正規化は絶対

運用・保守を考えると冗長なデータは将来の破綻を持たらす

データ量の増加は即座にあらゆるコストの増加に直結する

重複した…事はもう言わん

たった一つの外部キーが将来の重大な事故を防ぐかもしれない

リレーションにこだ…わる……な???何のこっちゃそりゃwww
コメント1件

541
NAME IS NULL[]   投稿日:2016/04/03 20:56:19  ID:wqLTVuK2.net(6)
>540
こういうのばっかりだからおかしなことになる。
コメント1件

542
NAME IS NULL[sage]   投稿日:2016/04/03 20:56:34  ID:???.net(860)
>538これってほんとにIT系の仕事してる奴なのか?
学生ならいいんだけど、どうも耳年増の学生って感じでもない
まともな教育受けられなかったんだなぁって亀田兄弟見てるのに近い感じで可哀想

543
NAME IS NULL[]   投稿日:2016/04/03 20:57:32  ID:wqLTVuK2.net(6)
DBA馬鹿って恐ろしいよね。

544
NAME IS NULL[]   投稿日:2016/04/03 21:01:19  ID:wqLTVuK2.net(6)
開発経験がないから、良かったのか悪かったのかわからない。

謎の教科書通りに作って自己満足。

545
NAME IS NULL[sage]   投稿日:2016/04/03 21:06:48  ID:???.net(860)
運用・保守を考えたら冗長化なんありえんだろ…
コメント1件

546
NAME IS NULL[]   投稿日:2016/04/03 21:13:58  ID:DppsG1GM.net(3)
>541
なあに〜おかしなことって〜ねえおせ〜てよ〜www

547
NAME IS NULL[]   投稿日:2016/04/03 21:29:58  ID:wqLTVuK2.net(6)
>545
冗長化するんじゃなくて、場合によっては冗長的な方がいい場合がある。

常に同期を取らなくてもいいんだよ。
システムがそういう設計なら。

同じデータに対して、別の目的で同時にアクセスされることがあるなら、まとめてしまわない方が、シンプルな設計のアプリケーションになる。

いろいろ書いてもいいけど、理解できないだろうからな。
コメント5件

548
NAME IS NULL[sage]   投稿日:2016/04/03 21:46:35  ID:???.net(860)
楽しい人生だな

549
NAME IS NULL[sage]   投稿日:2016/04/03 21:46:43  ID:???.net(860)
イレギュラーな事例をさも当たり前に語られてもな

550
NAME IS NULL[sage]   投稿日:2016/04/03 21:55:45  ID:???.net(860)
理解できないのと説明出来ないのは別な話だな
簡単に説明できない設計は根本からおかしい

551
NAME IS NULL[]   投稿日:2016/04/03 22:04:14  ID:DppsG1GM.net(3)
こいつはいつもフワッとした事しか言わんからツッコミ甲斐がないな、盛り上がらん奴や

552
NAME IS NULL[sage]   投稿日:2016/04/04 12:26:39  ID:???.net(860)
>547
夜間バッチとかの話?

553
NAME IS NULL[sage]   投稿日:2016/04/04 14:50:31  ID:???.net(860)
>547
いちいち読み込まなくていいから効率が良いってことですか?
そこで使うデータはそこで準備しとけば重複してもいいじゃんって感じでやっちゃって構わないってこと?
コメント2件

554
NAME IS NULL[sage]   投稿日:2016/04/04 18:09:56  ID:???.net(860)
>553
好きにやれや

555
NAME IS NULL[sage]   投稿日:2016/04/05 12:48:00  ID:???.net(860)
>553
一つ確実なのは
よくわからない状態なら >547 みたいな意見は無視した方がいい
ってこと

556
NAME IS NULL[]   投稿日:2016/04/05 12:50:09  ID:AGJq+Z7+.net
もう1つ確実なのは、よく分かってる奴は>547を無視してるってこと

557
NAME IS NULL[sage]   投稿日:2016/04/05 13:27:50  ID:???.net(860)
単なるかまってちゃんなんだと思うが、マジな可能性も極小だがある

558
NAME IS NULL[sage]   投稿日:2016/04/05 14:22:24  ID:???.net(860)
ネットで有名な詭弁のガイドラインってあったな
極めて限定された特殊な状況を、さも一般的な事ととらえてる可能性もある
わかって言ってるなら詭弁なんだろうけど、マジで信じてる人はどうすればいいんだろうなぁ

まあなんにせよ冗長化と冗長的の違いは俺には理解できないが
コメント1件

559
NAME IS NULL[sage]   投稿日:2016/04/05 15:48:21  ID:???.net(860)
>547
> いろいろ書いてもいいけど、理解できないだろうからな。

つか、既に書かれてることすら、俺らには理解できないんですが。

560
NAME IS NULL[sage]   投稿日:2016/04/05 16:25:55  ID:???.net(860)
>558
マジならこわい

561
NAME IS NULL[sage]   投稿日:2016/04/05 18:04:58  ID:???.net(860)
みんな必死すぎw

562
NAME IS NULL[sage]   投稿日:2016/04/05 18:13:32  ID:???.net(860)
確かに。知識ないやつを一斉に叩いて優越感に浸るほど滑稽な事はない。
単に相手にしなければいいだけ。
コメント1件

563
NAME IS NULL[sage]   投稿日:2016/04/05 19:27:49  ID:???.net(860)
知識がないと断定しちゃいけないと思うが。
いろいろ書いてもらわないことには判断できないし、機会があれば書いてくれるんじゃないのかな。

564
NAME IS NULL[sage]   投稿日:2016/04/06 00:28:32  ID:???.net(860)
DBエンジニアって頭いいと思うんだけど、意地悪な人が多いよね。神様みたいな人が困ったときに教えてくれて助かってこのスレというか、その神に感謝してるけど他はゴミだよね?
コメント2件

565
NAME IS NULL[sage]   投稿日:2016/04/06 00:31:50  ID:???.net(860)
>564
DBに限った話ではないさ

566
NAME IS NULL[sage]   投稿日:2016/04/06 03:04:46  ID:???.net(860)
そのときに助けたのが自分だったらいいなぁとぼんやり思う

567
NAME IS NULL[sage]   投稿日:2016/04/06 10:24:43  ID:???.net(860)
>562
× 知識ないやつ
○ 知識があると勘違いし、なおかつ他人を馬鹿にする奴

だから叩かれるんだよ。

568
NAME IS NULL[sage]   投稿日:2016/04/06 12:56:09  ID:???.net(860)
レスは自分を映す鏡
自分のレスがいつもバカに目をつけられて叩かれると感じるなら
自分のレスに問題がないかも考えた方がいい
コメント1件

569
NAME IS NULL[sage]   投稿日:2016/04/06 13:23:24  ID:???.net(860)
>564
2ch以外のQ&Aサイト知らないのかな?
一度行ってみ?
神だらけで腰ぬかすぞ
コメント1件

570
NAME IS NULL[sage]   投稿日:2016/04/06 13:27:19  ID:???.net(860)
>569
プログラマー専門のサイトも利用したけど、的中回答がなかったよ。
知恵袋やOKウェイブ全然レベル低いじゃん。

ここで降臨した神は、一撃で的中だよ。だから2chは消えてないんだよ。
ここの中にとんでもない人がいるたから。今もいるか知らないけど。感謝しかない。

他の人達は自分で調べろ、外で聞け。基礎からやり直し!と罵倒してきた。
ピンポイントで局所的にどうしてもわからない箇所が、素人レベルの人には多いよ。
そこを的確に教えてくれるって神だから。
コメント5件

571
NAME IS NULL[sage]   投稿日:2016/04/06 13:30:42  ID:???.net(860)
的中って、、、クイズかよw

572
NAME IS NULL[sage]   投稿日:2016/04/06 14:24:42  ID:???.net(860)
>570
Q&Aサイトの探し方もわからんのか(罵倒

573
NAME IS NULL[sage]   投稿日:2016/04/06 14:27:41  ID:???.net(860)
>570
> 他の人達は自分で調べろ、外で聞け。基礎からやり直し!と罵倒してきた。

山のようにあるQA系スレが、そのような内容で埋まってないのはなぜなのか、
ちょっと考えてみるといい。
まさに>568だな。

574
NAME IS NULL[sage]   投稿日:2016/04/06 14:35:44  ID:???.net(860)
>570
> ピンポイントで局所的にどうしてもわからない箇所が、素人レベルの人には多いよ。
違うね。
素人レベルで多いのは、以下のパターン。

「hogeがわからないんですが・・・」
→は?なんでhogeしたいの?
→hogeってどういうこと?もっと詳しく教えて
→hogeとかねーよ
→日本語でOK
「知らない人は黙っててください」

「hogeがわからないんですが・・・」
→は?なんでhogeしたいの?
(以下何回かのやりとり)
「Aを実現するためにhogeしようとしてるんですが・・・」
→それを先に言えよ。Aならhogeじゃ駄目だ
「hogeがわからないんですが・・・」
→自分で調べろ糞が

575
NAME IS NULL[sage]   投稿日:2016/04/06 14:43:47  ID:???.net(860)
>570
「ここ」ってDB設計スレのこと?

> 他の人達は自分で調べろ、外で聞け。基礎からやり直し!と罵倒してきた。
他のスレだとそんなことめったに起こらんが。例えば、
SQL質疑応答スレ 16問目 [転載禁止](c)2ch.net
SQL質疑応答スレ 16問目

DB設計スレ限定の話だと、しったかな奴が時々いついちゃうから荒れやすいかもな。
コメント2件

576
NAME IS NULL[sage]   投稿日:2016/04/06 14:48:11  ID:???.net(860)
「hogeがエラーになるんですが・・・」
→なんでエラーメッセージ貼らないの
「(エラーメッセージを貼る)」
→そのエラーメッセージをググったら、トップがその解決方法じゃねーか!

577
NAME IS NULL[sage]   投稿日:2016/04/06 14:59:41  ID:???.net(860)
>575
ごめん質問して神様降臨したのそっちだね。
本当に感謝しております。DB楽しいです!
コメント1件

578
NAME IS NULL[sage]   投稿日:2016/04/06 15:53:54  ID:???.net(860)
初心者ならteratailがいいと思う

579
NAME IS NULL[sage]   投稿日:2016/04/06 16:36:02  ID:???.net(860)
>570
> ここで降臨した神は、一撃で的中だよ。だから2chは消えてないんだよ。
君にレスしたその人以外の、普通に回答してる人たちをおとしめてるという自覚はあるのかね。

580
NAME IS NULL[sage]   投稿日:2016/04/06 17:44:08  ID:???.net(860)
そもそも語るスレで一撃的中とか
初めから回答が決まってるなら議論の余地がないだろ

581
NAME IS NULL[]   投稿日:2016/04/06 22:59:38  ID:bOn0CikI.net(7)
他人の書き込み批判ばかりで、中身のないスレw
コメント1件

582
NAME IS NULL[]   投稿日:2016/04/06 23:01:01  ID:bOn0CikI.net(7)
>575
そっちにもこっちにも書いてますが?

583
NAME IS NULL[]   投稿日:2016/04/06 23:09:12  ID:bOn0CikI.net(7)
大規模なシステムに関わったことがないと分かんないことが多いと思うよ。

しかもいろんな立場から見た場合、こうすべきと言われていることが必ずもいいわけではない。

閉じたシステム、止められるシステム、使ってる人が少ないシステムならガチガチのRDB理論でやっても問題ないけど、そんなチンケなシステムなら、そもそもDB設計なんてむしろ適当でもいいんだよ。
コメント1件

584
NAME IS NULL[]   投稿日:2016/04/06 23:30:25  ID:Kgoj/5an.net(3)
>581
批判ばかりで中身のない代表がお前なのだが…

大体システムなんてのは規模が大きくなるほど多くの制約を設けなければ制御しきれなくなる
お前の言ってる事は「制御しきれなくなったからとりあえず場当たり的にやっちゃえば簡単じゃん」て事中にはそれで妥協してしまう人間もいるが広く普遍的に受け入れられる考えではない
コメント1件

585
NAME IS NULL[]   投稿日:2016/04/06 23:34:37  ID:bOn0CikI.net(7)
>584
それこそ閉じたシステムのことだろ。
コメント1件

586
NAME IS NULL[]   投稿日:2016/04/06 23:47:16  ID:Kgoj/5an.net(3)
>585
それこそって何のことだよ?
大体お前は何をもって「閉じたシステム」と言ってるのだ?
「閉じたシステム」でないシステムに理論が通用しないと考えるのはなぜだ?

やっぱり中身がないふわふわ君だなお前
コメント1件

587
NAME IS NULL[]   投稿日:2016/04/06 23:50:04  ID:bOn0CikI.net(7)
>586
データを直したことないのかな?
コメント1件

588
NAME IS NULL[]   投稿日:2016/04/06 23:51:30  ID:bOn0CikI.net(7)
入れ物のことばっかりで、データの運用のことを全然考えてないように思われる。

589
NAME IS NULL[]   投稿日:2016/04/06 23:55:29  ID:Kgoj/5an.net(3)
>587
いきなり話飛んでるし…

自分の考えを喧伝したかったら少しは考えて話せよふわふわ君
お前相手じゃ議論にもならんわ
コメント1件

590
NAME IS NULL[]   投稿日:2016/04/06 23:58:15  ID:bOn0CikI.net(7)
>589
批判ばかりw

自分に言われていると思ってるやつって何なの?
コメント1件

591
NAME IS NULL[sage]   投稿日:2016/04/07 00:12:41  ID:???.net(860)
お前の設計みたいなゴミDBで苦労させられてるからほんと死んで欲しいわ

592
NAME IS NULL[sage]   投稿日:2016/04/07 04:58:55  ID:???.net(860)
データの手メンテなんて、何かが間違ってなければ発生しないわけで

もしかして、データの手メンテをデータの運用だと考えている奴がいるのだろうか
そりゃそんな運用を考えてるなら設計が多少適当でも良いだろうな

時々、大規模になるほど、制約を緩くするべきだって主張する奴がいるけど
どういう経験をしたらそう言う主張になるのか理解も想像もできんな

593
NAME IS NULL[sage]   投稿日:2016/04/07 05:20:50  ID:???.net(860)
>577
どんな質問だったの?

594
NAME IS NULL[sage]   投稿日:2016/04/07 05:29:31  ID:???.net(860)
>590
珍しく相手してくれてるんだからそう無碍にしてはいけないよ。

595
NAME IS NULL[sage]   投稿日:2016/04/07 08:18:25  ID:???.net(860)
要件示さずにあーだこーだ言ってる奴は大抵知ったか
試験に出るかもしれないので覚えておくように

596
NAME IS NULL[sage]   投稿日:2016/04/07 10:39:50  ID:???.net(860)
>583
> 閉じたシステム、止められるシステム、使ってる人が少ないシステムならガチガチのRDB理論でやっても問題ないけど、そんなチンケなシステムなら、そもそもDB設計なんてむしろ適当でもいいんだよ。
適当にやるより、過去のベストプラクティスに則って機械的に設計した方が工数も少なく、
性能上のリスクも少なく、運用工数も一般に抑えられると思うがね。

597
NAME IS NULL[sage]   投稿日:2016/04/07 11:06:23  ID:???.net(860)
table hoge (
  hoge_id text,
  tags array[],
  contents json
)
こういうテーブルが存在すると、このテーブルに関連するコードを書く奴全てが不幸になる。
システムの規模なんか関係ないよ。
コメント1件

598
NAME IS NULL[sage]   投稿日:2016/04/07 11:46:52  ID:???.net(860)
初心者に書かせるとかなりの率でそれやるんだよなあ

599
NAME IS NULL[sage]   投稿日:2016/04/07 12:26:10  ID:???.net(860)
>tags array[],

これ、データ型に配列(それも可変)ってことですか?
コメント1件

600
NAME IS NULL[sage]   投稿日:2016/04/07 13:19:51  ID:???.net(860)
>599
滅多に使わないから間違えた。
tags array[]じゃなくてtags text[]だった。

> これ、データ型に配列(それも可変)ってことですか?
そう。

601
NAME IS NULL[sage]   投稿日:2016/04/11 11:59:37  ID:???.net(860)
イケメン芸能人愛用中!!ミニセグウェイ!!
https://www.youtube.com/watch?v=BLj2H95-ITA0

602
NAME IS NULL[sage]   投稿日:2016/04/11 15:20:24  ID:???.net(860)
>597
SQLアンチパターンのジェイウォークですか?
コメント1件

603
NAME IS NULL[sage]   投稿日:2016/04/11 16:44:32  ID:???.net(860)
SQLアンチパターンの何にあたるかがわからないと、思考が一歩も進まないという病

604
NAME IS NULL[sage]   投稿日:2016/04/11 17:18:52  ID:???.net(860)
>602
に該当するかは議論の余地があるよね。
ジェイウォークのデメリットが適用される場合とされない場合がある。

605
NAME IS NULL[sage]   投稿日:2016/04/17 21:12:11  ID:???.net(860)
知恵をお貸し下さい。
複数の部署のシステムを開発する場合、データベースは部署ごとに分けますか?
それともシステム単位で分けますか?
環境はSQLServerです。

私は、社員マスタ等共通するものは分けて別DBとする。
後は部署ごとにDBファイルを分けてその部署に関するものは、
全部そのDB内にテーブルを作成しようかなと思っていたのですが、
部署の基幹となるシステムのテーブルと、ツール的なものに使用する簡易なテーブルとが
ごちゃごちゃになってしまいそうで、悩んでいます。
一般的に、どういう設計が好ましいのか、皆さんの意見をお聞かせ下さい。
よろしくお願いいたします。
コメント2件


606
NAME IS NULL[sage]   投稿日:2016/04/17 21:27:08  ID:???.net(860)
>605
システムの規模とか各部署の連携業務あるとかないとか解らないと…
コメント1件

607
NAME IS NULL[sage]   投稿日:2016/04/17 21:41:10  ID:???.net(860)
>606
すみません、全体としては全部署の業務管理システムのようなものでそこそこの規模になると思います。
商品等各部署で共通する商品もあれば、その部署だけで使用する商品等もあります
売り上げや、業務の進捗管理等連携する部分もそれなりにあるのですが、
一つのDBにまとめるとテーブル数も多くなり、繁雑になるのではないかと思ったのですが、
システム単位になるとツールの類等含めるとDBファイルの数も多くなり、
システム開発側が面倒になるのではないかと思い、一般的?というか
皆さんならどういう設計にするかを、お聞きしたいと思いました。

608
NAME IS NULL[sage]   投稿日:2016/04/17 22:06:37  ID:???.net(860)
SQLServer久しく触ってないのであれだが・・・
DB分けの必要性があるなら別だが、DB分けよりスキーマ分けのが運用はシンプルになると思う
設計部分は俺なら共通項をdbo.親として、部門別拡張を部門.子として定義で依存関係作ったりするかな

609
NAME IS NULL[]   投稿日:2016/04/17 22:09:13  ID:qcQ5QTkR.net
DB設計ではなくDBMS物理設計だな。

610
NAME IS NULL[sage]   投稿日:2016/04/18 11:47:39  ID:???.net(860)
全部署の業務管理システムで部署ごとにDB分けるとか無いわ
全部署の集計や部署間のやりとりするたびに、DB連携させるのか?
そっちの方が手間だぞ

一つのDBにしようが、複数DBにしようが、総テーブル数は変わらんだろ
むしろ完全な複数DBにすればDBごとに重複するテーブルが必要になるから
そっちの方がテーブルは増えるだろ

611
NAME IS NULL[sage]   投稿日:2016/04/18 13:19:03  ID:???.net(860)
>605
システム単位に分割したとき、例えば社員マスタの変更はどうやるかなどの問題がでてくるよ。

612
NAME IS NULL[sage]   投稿日:2016/04/18 15:01:10  ID:???.net(860)
共通のテーブルを持つDBを作るって書いてるから
重複するから増えるとかは気にしなくていいんじゃない?
リンクサーバーまじめに使ったこと無いから問題なく運用できるのかどうかわからないけど。

とはいえ、そうそう分ける必要は無いんじゃないかと思うよ。
ダイアグラムとか活用するといい。

613
NAME IS NULL[sage]   投稿日:2016/04/28 12:17:57  ID:???.net(860)
音楽ファイル名(文字列、unique、not null)
音楽のタイトル(文字列、unique、not null)
音楽の歌詞(文字列)

日付の管理は不要です
この場合どういうテーブル構造にしたらいいですか?

テーブル名:music
カラム:title,filename,lyric

こんな感じだとダメですか?正規化したほうがいいですか?
idなくてもいいと思ったんですがあったほうがいいですか?
コメント3件

614
NAME IS NULL[sage]   投稿日:2016/04/28 13:45:40  ID:???.net(860)
>613
ファイル名をPKにすればいいよ。
ちなみにタイトルはuniqueじゃないと思う。

615
NAME IS NULL[sage]   投稿日:2016/04/29 02:14:33  ID:???.net(860)
>613
それが正規化されてるかどうかすら判断できないわけで
その程度の説明なら、それでやってみればとしか言えないんじゃね

id付けるかどうかは、開発方法にもよるから何とも
なくてもいいと思ったんならそれでいいんじゃね
やっぱり必要だったと思ったらその時付ければ良いんじゃね

616
NAME IS NULL[]   投稿日:2016/04/29 03:15:06  ID:/rx9RsqQ.net
>613
音楽のタイトルはかぶります。

617
NAME IS NULL[sage]   投稿日:2016/04/29 08:42:50  ID:???.net(860)
音楽のタイトルがユニークだと色々な人の「さくら」が「さくら_1」とか「さくら_2」になっちゃうぜ

618
フーテンの虎次郎[sage]   投稿日:2016/04/29 09:12:53  ID:???.net(860)
さくら、帰ったよ

619
NAME IS NULL[sage]   投稿日:2016/04/29 10:04:15  ID:???.net(860)
ファイル名とタイトルで複合PKのつもりなんじゃね?アルバム1ファイルとか。

620
NAME IS NULL[sage]   投稿日:2016/04/29 11:03:23  ID:???.net(860)
まず音楽ファイルのプロパティ見るという考えは無いのか...

621
NAME IS NULL[sage]   投稿日:2016/04/29 13:45:54  ID:???.net(860)
ないです(ないです)

622
NAME IS NULL[sage]   投稿日:2016/04/29 16:53:18  ID:???.net(860)
タイトルとファイル名を1:nの関係にすれば解決

623
NAME IS NULL[]   投稿日:2016/05/10 17:03:36  ID:XkKxf3hC.net
01.Life Time Respect original mix
02.Life Time Respect 2008
03.Life Time Respect English ver.
04.Life Time Respect a cappella ver.
05.Life Time Respect Tokyo ver.
06.Life Time Respect Disco ver.
07.Life Time Respect T.K remix

624
NAME IS NULL[]   投稿日:2016/05/12 05:26:11  ID:HmbS4CfD.net
データモデル・DB論理・物理設計スレ [無断転載禁止]&#169;2ch.net
データモデル・DB論理・物理設計スレ

625
NAME IS NULL[sage]   投稿日:2016/05/18 21:20:19  ID:???.net(860)
月額1000円くらいのレンサバって、毎秒どれくらいの処理出来るもんなの?

626
NAME IS NULL[]   投稿日:2016/05/18 22:18:05  ID:/7EcImwJ.net(2)
OSがCentOSだと過程して俺の計算だと0.00039くらい
コメント1件

627
NAME IS NULL[sage]   投稿日:2016/05/18 22:42:55  ID:???.net(860)
>626
逆数で教えてケロ

628
NAME IS NULL[sage]   投稿日:2016/05/18 22:50:17  ID:???.net(860)
SQLスレもここも、なんでスレチの話題ばっかなんだよw

629
NAME IS NULL[]   投稿日:2016/05/18 23:15:48  ID:/7EcImwJ.net(2)
健全でない言葉が含まれているため表示しません 内容を確認する

630
NAME IS NULL[sage]   投稿日:2016/05/18 23:18:06  ID:???.net(860)
イ、イ、インデックスを
は、は、張るんだな

631
NAME IS NULL[]   投稿日:2016/05/19 11:02:46  ID:id6StyEG.net
日本マイクロソフト人事部の西川昌邦(さいかわまさくに)は人殺しだ!!
「あなたのような従業員は会社のパフォーマンスにとってマイナスなので早く死んでください」
などと自殺教唆を公然と行った!!
丁寧に言えば何を言ってもいいというものではない!!これはヤクザや借金取りが脅迫をする時に
「いついつまでに金一億円をお振り込みください。間違った判断をなされないことを期待しています」
と発言するのと同じレベルだ!!
「しかもそれを注意してやったら世間はわれわれの味方だ。文句があるなら訴えてきたらよろしい。メールを電番を公開したければ
どうぞご自由に。世論はわれわれを賛辞するするメールを送付するだろう」
などとイカ様気取りも大概にしろという発言を行った!!
抗議先 日本マイクロソフト人事本部 西川昌邦
masaikaw@microsoft.com
090-2541-1718

632
NAME IS NULL[sage]   投稿日:2016/06/09 18:07:53  ID:???.net(860)
スレチの話題すらなくなり、スレが死んだ

633
NAME IS NULL[]   投稿日:2016/06/14 21:41:48  ID:cHMlzAQx.net
多言語の情報をテーブルに格納したい場合、どう設計するのがベターでしょうか?

A)多言語分のカラムを作る
ja_title、en_title のように必要な言語用のカラムを全て用意する

B)言語選択カラムのみ追加して1つのテーブルで処理する
id|type|title
1 |ja  |こんにちは
2 |en |hello
みたいなテーブル設計です。

C)テーブル自体を分ける
ja_profile、en_profile
みたいなテーブル名にします。ただ言語が増えるとテーブルも増えて大変だと思います。

おそらくBパターンが最適かと思いますが、
単一参照テーブルっぽくなるんじゃないかな?とも感じています。
よい設計の知恵があれば教えてください。よろしくお願いします。
コメント6件

634
NAME IS NULL[sage]   投稿日:2016/06/14 21:48:10  ID:???.net(860)
スキーマわければ?

635
NAME IS NULL[]   投稿日:2016/06/14 21:53:46  ID:Y5TYhKNt.net(2)
>633
「こんにちは」だけでいいならそれでもいいがw

636
NAME IS NULL[]   投稿日:2016/06/14 21:56:36  ID:Y5TYhKNt.net(2)
>633
それでどうやって英語と日本語の対応が分かると思うのか?

637
NAME IS NULL[sage]   投稿日:2016/06/14 23:04:35  ID:???.net(860)
>633
A)が一番簡単そうだが。

638
NAME IS NULL[sage]   投稿日:2016/06/14 23:05:41  ID:???.net(860)
Aが一番簡単ではあるが、カラム数や言語が増えると倍々で増えていくぞ

639
NAME IS NULL[sage]   投稿日:2016/06/14 23:14:50  ID:???.net(860)
Bだと文字コードの関係で格納できない場合もあるのか。
UTF-8にしてれば大丈夫だと思ったが、そうでもないんだな
コメント1件

640
NAME IS NULL[sage]   投稿日:2016/06/14 23:32:29  ID:???.net(860)
どうデータが発生してそれをどう使うのかがわからないのに、どの持ち方が最適かなんて
決められるわけないだろう。

641
NAME IS NULL[sage]   投稿日:2016/06/15 07:20:18  ID:???.net(860)
多言語って言っても大抵 日本語 + 英語 のバイリンガルですむからなぁ
そう割りきれば A) だな
本気で多言語やるなら B) 一択

642
NAME IS NULL[sage]   投稿日:2016/06/15 08:53:03  ID:???.net(860)
>633
sys.messages を参考にすると良いよ
コメント1件

643
NAME IS NULL[sage]   投稿日:2016/06/15 10:13:52  ID:???.net(860)
駅とかだと、英語・中国語・韓国語が多いな
単純にテーブル上のカラム×3にすると大変そうだな
Bのだと文字コード関係の問題がありそうだし、
ここは単純にデータベース自体分けるのが得策か?

644
NAME IS NULL[sage]   投稿日:2016/06/15 17:55:07  ID:???.net(860)
テーブルに直接文字列格納するんじゃなくて
文字列すべてにID振って、言語コード+IDで文字列を引っ張るリソース形式
検索を考慮しないならこれが一番じゃね

645
633[sage]   投稿日:2016/06/16 09:31:34  ID:???.net(860)
皆さん、色んなご意見ありがとうございます。
特別、ベターな方法ってないんですかね
最近は多言語化サイトが求められてるし、システム開発でも必要だと思うのですが、
DB設計をどうするかの情報ってほぼ無いので悩みます。

もう少し考えてみます。ご意見ありがとうございました。
コメント1件

646
NAME IS NULL[sage]   投稿日:2016/06/16 20:30:55  ID:???.net(860)
>645
> DB設計をどうするかの情報ってほぼ無いので悩みます。
本でもサイトでもいくらでもあるだろ
どんな要件にも対応できる魔法の設計方法を知りたいとかなら知らんけど
コメント3件

647
NAME IS NULL[]   投稿日:2016/06/16 20:52:52  ID:6DGXXQo5.net
まあ答えを教えろとかお子ちゃまなんだろ。

648
NAME IS NULL[sage]   投稿日:2016/06/16 22:03:09  ID:???.net(860)
>646
多言語化に対するDB設計の基本って本に書かれてます?
書かれてるのをご存知なら教えてください。
「達人に学ぶDB設計 徹底指南書」やら「グラス片手にデータベース設計」やら
売れてるのは持ってるのですが、全て把握してないので
いくらでもあるのでしたら見てみます。よろしくお願いします。
コメント1件

649
NAME IS NULL[]   投稿日:2016/06/16 22:45:35  ID:WYhuCtJz.net(2)
とこまで言葉を登録するつもりなのか?

Helloとこんにちはを関連付けたいなら1レコードで持てよ。

ただ画面の項目名なら画面単位のレコードにするとかしろよ。

要件がなければ応えようがない。
コメント1件

650
NAME IS NULL[sage]   投稿日:2016/06/16 22:48:39  ID:???.net(860)
>648
だから要件書けよ
言語の数とかレコード数とかメッセージで検索するのかとか

651
NAME IS NULL[sage]   投稿日:2016/06/16 22:50:13  ID:???.net(860)
>649-650
これ>633だけじゃ駄目なんですか?
コメント1件

652
NAME IS NULL[sage]   投稿日:2016/06/16 22:53:44  ID:???.net(860)
あと、本やサイトがいくらでもあるってお話なので勉強したいのですが。
別に答えや設計を代わりに考えてくれという質問じゃなくて、
「私は3パターン考えましたけど、皆さんはどうしてますか?」という相談なのですが。
要件次第や状況によって変わる、ってお話なら無限に話が広がるので、
>633で例を出して、「どう思いますか?」と言った問いかけなのですが

653
NAME IS NULL[sage]   投稿日:2016/06/16 22:57:38  ID:???.net(860)
表示文字だけなら言語ファイル対応でDB関係ないし
1データが複数言語で定義されるのかか言語間で関係ないのかとか
色々前提足らんよ
コメント1件

654
NAME IS NULL[sage]   投稿日:2016/06/16 23:11:07  ID:???.net(860)
>653
分かりました。
では、サイト上にお知らせを表示するためのDBとします。

○多言語化前の構成
テーブル名:news
フィールド名:id、title、body、date

○条件
・1つのお知らせに対して同じ内容の複数言語を登録させたい
・URLで表示する言語を切り替え(つまり、英語ページなら英語のデータのみ表示)
・複数言語にまたがって検索する事はない
・英語、中国語、韓国語、フランス語、スペイン語を登録する可能性あり

こういうのでいかがでしょうか?
コメント3件

655
NAME IS NULL[sage]   投稿日:2016/06/16 23:13:29  ID:???.net(860)
>651
人の話を聞けよ...

656
NAME IS NULL[]   投稿日:2016/06/16 23:28:44  ID:WYhuCtJz.net(2)
>654
「お知らせ」って何?

657
NAME IS NULL[sage]   投稿日:2016/06/16 23:40:16  ID:???.net(860)
>654
DB化必須ならbで十分じゃね?
俺ならお知らせだし検索不要として
html書かせて有効管理だけするかな
コメント1件

658
NAME IS NULL[sage]   投稿日:2016/06/17 04:36:26  ID:???.net(860)
>複数言語にまたがって検索する事はない
単一の言語でなら検索するの?
その言語ってのは指定の言語一つだけなの?すべての言語なの?
何を検索して、何を得たいの?

659
NAME IS NULL[sage]   投稿日:2016/06/17 11:42:05  ID:???.net(860)
興味があって同じテーブルに異なる言語を登録できるか試したらできた(PostgreSQL)
他のDBも普通にできるのかな?

select * from hoge
aaa | bbb

---------+----------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------
aaa | Primare Liga C Gruppe wurde im franzosischen Sportstadion von Vorstadten Paris Saint-Denis auf dem 16. auf einer europaischen Meisterschaft d
er siebente Tag des Fusballs durchgefuhrt.
bbb | ??? ???? 1??? ?? ??? ?? ??? ??(【?】・【???】)?? ???? 17?, 2016? ???? ???? ????? ??? ???
? ????? ??? ????.
(2 行)
コメント1件

660
NAME IS NULL[sage]   投稿日:2016/06/17 11:42:35  ID:???.net(860)
あ、文字化けした

661
NAME IS NULL[sage]   投稿日:2016/06/17 12:58:05  ID:???.net(860)
>657-658
過去のお知らせとか検索できたら良いなって思いまして。
複数言語にまたいで検索はないですね。それだとおかしくなると思うし。

>659
MySQLも大丈夫ですね。基本的にUTF-8にしてると問題ないかと思います。
(問題ある言語もあるかも・・・

多言語化を勉強しているのは、なんかのニュースで見たのですが、
外国人が観光などで日本にきてサイトを見ても、日本語ばかりでよくわからないし、
英語版でも間違っている事が多くて困ってると言った話を聞いたからなんです。
また、東南アジアや欧州からの旅行者は英語読めない事もあるそうで、
英語版だけだと駄目で、多言語に対応する必要があるそうなんですね。

で、多言語化する場合のDB設計はどうなるんだろう?どうするんだろう?
と思ったのがきっかけです。

それでググッたり手持ちのDB設計の本を見ても具体的に書いてない。
>646さんいわく、いくらでもあるそうなんで教えてほしいのですが。
コメント1件

662
NAME IS NULL[sage]   投稿日:2016/06/17 14:22:20  ID:???.net(860)
>661
だからな他のひとが言ってるようにデータベースで管理する必要もないかもしれない。
コメント1件

663
NAME IS NULL[]   投稿日:2016/06/17 14:23:16  ID:qx3Jcvsl.net
書いてないんじゃなくてそこを考えるのがキミの仕事。
コメント1件

664
NAME IS NULL[sage]   投稿日:2016/06/17 15:46:58  ID:???.net(860)
>662
>654はあくまで例ですよ。多言語化を勉強する上で要件出せって言われたので、
無理やり一般的な要件を想像して書いただけです。
それを「DB必要ない」と言われたら、勉強のしようがないじゃないですか。

>663
いや、>646さんが「いくらでもある」って言われてるので、
いくらでもある内のひとつを教えてほしいだけなんですが。
私のググり方が悪いだけかもしれないし。
コメント1件

665
NAME IS NULL[sage]   投稿日:2016/06/17 16:14:09  ID:???.net(860)
>664
だんだんうざくなってきてるぞ。

たとえば、「データベース 多言語対応 設計」でググると、1ページ目でいくつも見つかる気がするのだが。
コメント2件

666
NAME IS NULL[sage]   投稿日:2016/06/17 18:18:15  ID:???.net(860)
すげえ高飛車w

667
NAME IS NULL[sage]   投稿日:2016/06/17 18:42:31  ID:???.net(860)
技術者の基本スキル「ググる」が出来てないならDB設計はまだ早い

668
NAME IS NULL[sage]   投稿日:2016/06/17 18:56:47  ID:???.net(860)
>665
それでググってみたんですけどねぇ・・。

うざいという事なので、これにて失礼します。
アドバイスいただいた方、ありがとうございました。
コメント3件

669
NAME IS NULL[sage]   投稿日:2016/06/17 19:01:09  ID:???.net(860)
設計方法を学んだなら、自分で要件を整理して設計すれば良いだけなんだが

やり方をいくら教えても、それが理解出来ないで、ズバリそのものの答えを求める
ああ、ゆとり教育の弊害ってこれなのかと

670
NAME IS NULL[sage]   投稿日:2016/06/17 19:35:23  ID:???.net(860)
>668
絶対ググってねーだろ w
>665 のワードでググったらトップにドンピシャの質問あって笑たわ
http://q.hatena.ne.jp/touch/1226110815
コメント2件

671
NAME IS NULL[sage]   投稿日:2016/06/21 16:51:51  ID:???.net(860)
>670
文字コードが一つであるという前提がついた今、
> TABLE単位で設定できるなら、あとで別の言語(TABLE)が増える可能性を見越して、「@テーブル単位で増やす」が無難でしょう。
> 文字コードに依存するデータをbinary形式で格納し、そのFIELDの文字コードを別FIELDに格納する以下のような構造にすれば、「@単純にフィールドを増やす」も可能でしょう。
のどちらかになるんだけど、それでよいと思ってるから「ドンピシャ」って思ってるんだよね。

>668
bのままだと早々に言われているように、
> 1つのお知らせに対して同じ内容の複数言語を登録させたい
という意図を表現できていない。
そのあたりも見越したフォローは >642 で早々に出ている。

ただ >639 が気がかり。
コメント1件

672
NAME IS NULL[sage]   投稿日:2016/06/21 16:54:50  ID:???.net(860)
もういいだろ

673
NAME IS NULL[sage]   投稿日:2016/06/21 19:54:26  ID:???.net(860)
>671
ドンピシャの「質問」って言ってるだけで回答には触れてないけど...
人の話をあまり聞かないタイプなのかな?

674
NAME IS NULL[sage]   投稿日:2016/06/22 02:41:14  ID:???.net(860)
いくらでもある内のひとつでいいなら、検索結果トップのページにも書いてあるよ
というつもりでリンクを貼ったのかと思ったけど、そういう言葉が出てくることもないんだね。

675
NAME IS NULL[sage]   投稿日:2016/06/22 08:39:48  ID:???.net(860)
そんな意図じゃねーよ
って書いてあるのにバカじゃね?

676
NAME IS NULL[]   投稿日:2016/06/22 09:22:54  ID:R029ES8c.net
答えを教えろとかやめろよw

677
NAME IS NULL[sage]   投稿日:2016/06/22 16:00:32  ID:???.net(860)
回答者じゃない>670に噛みついても何もいいことない

678
NAME IS NULL[sage]   投稿日:2016/06/22 18:20:28  ID:???.net(860)
何について議論しているのか

679
NAME IS NULL[sage]   投稿日:2016/06/22 18:29:02  ID:???.net(860)
>668
> それでググってみたんですけどねぇ・・。

ですけど、なんなの?
というのが注目のまと

680
NAME IS NULL[]   投稿日:2016/06/30 01:00:17  ID:kJxYJKSQ.net
マ イ ン ド コ ン ト ロ ー ル の手法

・沢山の人が、偏った意見を一貫して支持する
 偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
 誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法

偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い

靖 国 参 拝、皇 族、国 旗 国 歌、神 社 神 道を嫌う カ ル ト

10人に一人は カ ル ト か 外 国 人

「ガ ス ラ イ テ ィ ン グ」 で 検 索 を !

681
NAME IS NULL[sage]   投稿日:2016/07/06 17:23:17  ID:???.net(860)
有用性は分からんけど
読んでて面白いスレだなここ

682
NAME IS NULL[sage]   投稿日:2016/08/14 10:55:58  ID:???.net(860)
データベースの設計についてまったく知識がないんですが
初心者におすすめの本ありませんか?
コメント1件

683
NAME IS NULL[sage]   投稿日:2016/08/14 19:38:03  ID:???.net(860)
>682
とりあえずいきなり作ったほうがいいよ。
その後から、基礎の本読むと入りやすいじゃん。
このスレの連中は、いきなり基礎を叩きこもうとしてくるから気をつけな!

684
NAME IS NULL[sage]   投稿日:2016/09/22 06:22:05  ID:???.net(860)
SQLアンチパターン 6章ポリモーフィック関連
バグ(Bugsテーブル)にも機能リクエスト(FeatureRequestsテーブル)にも
コメントをつけられるようにしたいから、Commentsテーブルにissue_type(Bugs or FeatureRequestsの値を取る)
を持たせておいて、それによって参照先テーブルを切り替えるというやつ。
これって単にBugCommentsテーブルとFeatureRequestCommentsテーブルに分けるという解決策じゃダメなのかね?
http://qiita.com/suguru/items/d6d3ebe7b867c5009231

685
NAME IS NULL[sage]   投稿日:2016/09/23 12:51:26  ID:???.net(860)
そういう解決策になってないということなのかね?

686
NAME IS NULL[sage]   投稿日:2016/09/23 13:36:34  ID:???.net(860)
データベースの選び方について質問したい場合はどこで質問したらいいんでしょうか?

687
NAME IS NULL[sage]   投稿日:2016/09/23 14:40:11  ID:???.net(860)
各ベンダーのスレで
「このDBMSつかえねーんだけど他にいいのある?」って聞けばいいよ

688
NAME IS NULL[sage]   投稿日:2016/09/23 14:43:04  ID:???.net(860)
ここでいいんじゃないかな

689
NAME IS NULL[sage]   投稿日:2016/09/23 20:12:34  ID:???.net(860)
主なものは無料のものが出てるから一通り自分で試せば良いんじゃね。まさか会社で使うものをここで聞くってわけでもないだろうし。

690
NAME IS NULL[sage]   投稿日:2016/09/24 01:03:48  ID:???.net(860)
SQLアンチパターン 7章 マルチカラムアトリビュート
普通tagって多対多にしない?
1対多だと、既存のタグをリストアップするのにSELECT DISTINCTか何か必要になってしまうけど
http://qiita.com/mizunokura/items/a9be12e0eddcf5d90f07

691
NAME IS NULL[sage]   投稿日:2016/09/26 01:26:05  ID:???.net(860)
データベースなんてどれ選んでも同じ
そもそもデータベースが必要なのか

692
NAME IS NULL[sage]   投稿日:2016/10/03 12:26:01  ID:???.net(860)
123.1234567890
整数部が3桁、
小数部が10桁くらいの実数値をDBに入れる場合、
カラムは実数にすべきでしょうか?
文字列にすると何か問題ありますか?
コメント4件

693
NAME IS NULL[sage]   投稿日:2016/10/03 12:49:34  ID:???.net(860)
>692
その要件だけだと
好きにすればいい
としか言いようがない

694
NAME IS NULL[sage]   投稿日:2016/10/03 14:07:18  ID:???.net(860)
>692
それだけなら問題無いけど他要件次第というのはあります

695
NAME IS NULL[sage]   投稿日:2016/10/03 15:08:34  ID:???.net(860)
ソートしたり範囲指定するなら小数点位置固定でもない限り実数のがいいし
連結すること多ければ文字列のがいいかもね

696
NAME IS NULL[sage]   投稿日:2016/10/04 07:21:41  ID:???.net(860)
>692
要件次第だけど整数部と小数部を別カラムでもいいかもね

697
NAME IS NULL[sage]   投稿日:2016/10/04 16:42:19  ID:???.net(860)
>692
なんで文字列にしたいの?
コメント1件

698
NAME IS NULL[sage]   投稿日:2016/10/04 23:11:46  ID:???.net(860)
理論から学ぶデータベース実践入門読んでるけど、2章の述語論理の所だけよくわからんわ
正規化の説明なんかは分かりやすいんだが(´・ω・`)

699
NAME IS NULL[sage]   投稿日:2016/10/05 02:35:55  ID:???.net(860)
>697
DB初心者で、文字列型しか使ったことが無いので。
コメント1件

700
NAME IS NULL[sage]   投稿日:2016/10/05 21:58:12  ID:???.net(860)
そしたら全部文字列型で

701
NAME IS NULL[sage]   投稿日:2016/10/06 01:01:07  ID:???.net(860)
文字数制限するかしないか
varcharかtext型かをいつも悩むんだけど

702
NAME IS NULL[sage]   投稿日:2016/10/06 02:28:52  ID:???.net(860)
DBMSにもよるけど、textはvarcharに比べて機能的に制限があったりするから
varcharで行けるならtextなんて使わん

703
NAME IS NULL[sage]   投稿日:2016/10/06 08:01:45  ID:???.net(860)
保存形式違くて検索にも響くし

704
NAME IS NULL[sage]   投稿日:2016/10/06 09:44:02  ID:???.net(860)
>699
それならむしろ実数型使った方が良いと思うぞ

あえて数値を文字列で持つのは
ソート順やSQL上でのキャスト/変換など考慮出来る人がやるようなものだし

705
NAME IS NULL[sage]   投稿日:2016/10/06 11:57:31  ID:???.net(860)
せっかくだから色々な型使おうぜ

706
NAME IS NULL[sage]   投稿日:2016/10/11 22:38:04  ID:???.net(860)
業務でdb設計を自己流でやってたやつが系統的に学ぶのにいい本ってあります?
これくらい読んどけカスみたいなのがいいです

707
NAME IS NULL[sage]   投稿日:2016/10/18 04:46:29  ID:???.net(860)
PofEAA?
コメント1件

708
NAME IS NULL[]   投稿日:2016/10/25 11:03:57  ID:sYfDHjNx.net
会員同士がメッセージの交換を出来るシステムを作っています。

Aという会員とBという会員がいて、
Aが退会したら、会員Bのメッセージボードには「退会した会員」とだけ表示します。

この仕様について相談ですが、
この条件ですと会員Bは「誰にメッセージを送ったかわからない」問題があります。
もう退会した会員なので良いかもしれませんが、少々気持ち悪いかもしれません。

じゃ、メッセージ送信した時点での名前を保存するとします。
しかし、名前の編集ができる仕様なので、別名にされると困ります。

どのような設計にすれば上記の問題を解消できるのでしょうか?
汎用的なやり方・考え方を教えてください。よろしくお願い致します。
コメント1件

709
NAME IS NULL[sage]   投稿日:2016/10/25 11:11:18  ID:???.net(860)
ちなみに現在のテーブル設計は以下のようにしています。

id:(ID)pk
user_id:(会員ID)fk
subject:(送信者)
body:(本文)
datetime:(送信日時)
checked:(確認した日時)
status:(ステータス。表示・非表示)

710
NAME IS NULL[sage]   投稿日:2016/10/25 11:13:45  ID:???.net(860)
すみません。少し間違えました。

id:(ID)pk
user_id:(送信した会員ID)fk
user_to_id:(送信先の会員ID)fk
subject:(送信者)
body:(本文)
datetime:(送信日時)
checked:(確認した日時)
status:(ステータス。表示・非表示)

711
NAME IS NULL[sage]   投稿日:2016/10/25 11:15:59  ID:???.net(860)
>708
退会した会員の名前が再利用可能かどうかで
コメント1件

712
708[sage]   投稿日:2016/10/25 11:24:39  ID:???.net(860)
>711
再利用可能というのは、

会員Aの山田太郎さんが会員情報編集ページで、「山下太郎」にし、
また編集して「佐藤太郎にし」、やっぱり戻したいので「山田太郎」

とした時に、「山田太郎には出来ない」という意味でしょうか?
そうであればそこまで考えていません。自由に名前の編集が出来るのを想定しています。

713
NAME IS NULL[sage]   投稿日:2016/10/25 11:35:42  ID:???.net(860)
退会後に、誰かがその名前を名乗れると言うことですね?
同じ名前が複数存在する場合も、当然発生しますよね

自分がメッセージを送った相手が、間違いなくその人であるって
送信者はどうやって判断しますか?
コメント1件

714
708[sage]   投稿日:2016/10/25 11:43:56  ID:???.net(860)
>713
そうなんです。そういう問題が発生します。
どういう設計にすれば良いのでしょうか?
コメント1件

715
NAME IS NULL[sage]   投稿日:2016/10/25 12:53:55  ID:???.net(860)
何のためのidだよ?
退会したかどうかなんて退会日時を記録しときゃいいだろ

「退会した会員」表示だって
なんでその表示だけで済ますんだよ?
相手名表示+「退会した会員」表記でいいじゃんか

716
NAME IS NULL[sage]   投稿日:2016/10/25 13:01:17  ID:???.net(860)
>714
・user_idはシステムの生存期間を通してユニークにする(一度使われたuser_idは使えない)
・user_idの変更は不可
・氏名は変更可能(システム内で重複可能)
・よってユーザーを一意に決定するのはuser_idのみ
・ユーザーが退会してもuserレコードは削除しない
・あるいはuser_archiveテーブルに移動する
・退会したユーザの氏名を表示するかどうかは要件次第
コメント1件

717
708[sage]   投稿日:2016/10/25 13:09:16  ID:???.net(860)
>716
なるほど。

・ユーザーが退会してもuserレコードは削除しない
・あるいはuser_archiveテーブルに移動する

これは良いですね。前者が削除フラグで後者が履歴テーブルですね。
退会した会員にはメッセージを送れなくするだけなので、
「山田太郎(退会済み)」とすれば足りると思います。

とすれば、
message、user、user_archiveの3つのテーブルを結合する必要がありそうですね。

718
NAME IS NULL[sage]   投稿日:2016/10/25 16:46:14  ID:???.net(860)
userテーブルにアカウントの有効性を示すカラム追加で良くない?
あるいは715の退会日時の有無で判定とか
結合が気になるならテーブルを増やさなくても良いかと
コメント1件

719
708[sage]   投稿日:2016/10/25 17:45:45  ID:???.net(860)
>718
userテーブルを716さんの意見を踏まえて以下のようにしたとします。

id:(ID)pk
name:(名前)
email:(メールアドレス、ログインでも使用)
password:(パスワード)
status:(ステータス、有効|停止|退会)
created:(登録日時)
modified:(更新日時)
deleted:(退会日時)

これで思ったのですが、退会日時って必要ですかね?
システム的に更新したらmodifiedが変わるようになっているのですが、
statusを退会にした時は更新日時が上書きされるから、それで良いと思うのですが。
管理画面でstatusを変える場合も日付が更新されるわけですし。
コメント1件

720
NAME IS NULL[sage]   投稿日:2016/10/25 20:03:51  ID:???.net(860)
>719
status で退会示すなら deleted は見なくてもいい
コメント1件

721
708[sage]   投稿日:2016/10/25 20:16:11  ID:???.net(860)
>720
ですよね。退会フラグっぽくするならそうします。

722
NAME IS NULL[sage]   投稿日:2016/10/26 00:23:37  ID:???.net(860)
脱線するかもだけど、708の「誰にメッセージを送ったかわからない」問題って退会したときだけじゃなくない?
名前自由に変えられるなら、Aさんが実は退会してなくて名前変えただけなのに、Bさんは「Aがいなくなって知らない人に送ってる、誤送信?システム障害?」ってならんかな
上で書いてる、送信時の名前を保存する案は上手くはないけどそういうことじゃないの、って思った

723
NAME IS NULL[sage]   投稿日:2016/10/26 01:03:56  ID:???.net(860)
サロゲートキーってローカルとか作る場所一か所なら簡単だけど
複数が拠点あって、マスター登録をどこでもして、
サーバー経由して他の拠点が作ったマスター受信したりする場合
ナチュラルキーじゃねえと色々無理出るよね。
必ずサーバーにしか作成しないってなら大丈夫だけど。
コメント1件

724
NAME IS NULL[sage]   投稿日:2016/10/26 01:22:59  ID:???.net(860)
何言っとるのキミ?

725
NAME IS NULL[sage]   投稿日:2016/10/26 01:49:43  ID:???.net(860)
図を描かずに文字だけでは無理があったようなので例を出すと、
例えば部門マスタ。
ナチュラルキー部門コードのものをプライマリキーとせず
ユニーク制約だけにしておき、
自動インクリメントをプライマリキーで各店で作らせると

拠点A、ID:5 部門コード:ABC001 部門名:ABCあ
拠点B、ID:13 部門コード:ABC001 部門名:ABCい
拠点C、ID:54 部門コード:ABC001 部門名:ABCう
とかなるような場合。

これをサーバーに登録させ、それを受信することが難しい。
拠点Aで登録したものを最初にサーバーに登録した場合
サーバーには「部門名:ABCあ」が登録される。
そのあと拠点Cが送信した場合、このレコードを更新したいが
IDではできないので結局ナチュラルキーですることになる。
しかし、それではそもそも変更が容易なために
サロゲートキーにしてたのに
拠点ではナチュラルキーの変更ができなくなり、
サロゲートキーを使う意味がなくなる。

726
NAME IS NULL[sage]   投稿日:2016/10/26 04:21:35  ID:???.net(860)
何が難しいのかわからん
プライマリキーであるサロゲートキーが全拠点で一意になるように、拠点間で番号帯をわけたら解決するってんじゃないの?
SQLserverのレプリケーションならmsdnにそうしろって書いてるけど

727
NAME IS NULL[sage]   投稿日:2016/10/26 10:46:49  ID:???.net(860)
プライマリキーの重複を防ぐってならそれだけで可能だけど、
俺の言ってる問題はそこではなく、
上の例がIDが10000ずつ振られていて

拠点A、ID:10015 部門コード:ABC001 部門名:ABCあ
拠点B、ID:20015 部門コード:ABC001 部門名:ABCあ
拠点C、ID:30015 部門コード:ABC001 部門名:ABCあ

とかの場合、サーバーに1レコードしか登録したくないわけだ。
このまま普通に登録したら3レコードそっくりなのが登録される。
それでは最新のものを使う場合、更新日付などのカラムが必要になる。
サーバーに1レコードにするにはサーバーのテーブルを
ナチュラルキーで判定せざるを得ない。
コメント1件

728
NAME IS NULL[sage]   投稿日:2016/10/26 11:15:20  ID:???.net(860)
>727
そういう仕組みだと、
> 拠点A、ID:10015 部門コード:ABC001 部門名:営業部
> 拠点B、ID:20015 部門コード:ABC001 部門名:企画部
> 拠点C、ID:30015 部門コード:ABC001 部門名:経理部
と登録されることだってありえるんだが、それはどう考えてるの?
コメント1件

729
NAME IS NULL[sage]   投稿日:2016/10/26 11:47:08  ID:???.net(860)
>728
一番最後に更新かけた所ので全拠点上書きする感じ。
部門・部門名は全拠点で共通認識。
商品コードとかの例のほうがよかったか。
コメント1件

730
NAME IS NULL[sage]   投稿日:2016/10/26 12:58:05  ID:???.net(860)
>729
なにをどう上書きするんだ?
拠点Cが最後に登録された場合、こうするのか?
update sections set id = 30015, 部門名 = '経理部' where 部門コード = 'ABC001'とするのか?
(これはPKが更新可能という意味でよろしくない)

> 拠点A、ID:10015 部門コード:ABC001 部門名:営業部
> 拠点C、ID:30015 部門コード:ABD001 部門名:営業部
と登録されていたらどうするんだ?
コメント1件

731
NAME IS NULL[sage]   投稿日:2016/10/26 13:03:45  ID:???.net(860)
実はこれ、サロゲートキーじゃなくてたとえば部門コードをPKとしても、同じ問題が発生するんだよね。

> 拠点A、部門コード:ABC001 部門名:営業部
> 拠点B、部門コード:ABC001 部門名:企画部
と登録される場合もあるし、
> 拠点A、部門コード:ABC001 部門名:営業部
> 拠点B、部門コード:ABD001 部門名:営業部
と登録されることもある。
コメント1件

732
NAME IS NULL[sage]   投稿日:2016/10/26 13:29:42  ID:???.net(860)
複数拠点のどこででもデータの登録・変更・削除が可能だと、データの同期とか競合の解消とか難しそう

733
NAME IS NULL[sage]   投稿日:2016/10/26 13:47:25  ID:???.net(860)
三拠点ともABC001なのか、記述誤りかと思った
SQLserverしか知らんが、あれのマージレプリケーションならできそうだけど、競合を検出したときのルール決めとアプリケーション側での対応が必要なんだよな
扱いきれそうにないし、そんな要件もなかったし使ったことないや

734
NAME IS NULL[sage]   投稿日:2016/10/26 13:58:24  ID:???.net(860)
拠点AでABC001を登録したあとに、(まだ拠点Bに連携されてなくて)拠点BでもABC001を登録しようとしたらどう動いてほしいの?
先勝ち(拠点Bの操作はユニーク制約違反で失敗)なのか
後勝ち(一テーブルにユニーク制約が複数あった場合、どれか一つでも違反したらその制約をキーにデリートインサート)か

735
NAME IS NULL[sage]   投稿日:2016/10/26 14:00:32  ID:???.net(860)
>730
拠点Cが最後に登録された時、
IDが存在しないならそのクエリになるよね。
IDが存在する場合は正直どう書いたらいいかわからん。

>> 拠点A、ID:10015 部門コード:ABC001 部門名:営業部
>> 拠点C、ID:30015 部門コード:ABD001 部門名:営業部
>と登録されていたらどうするんだ?

このABD001ってのが新規で作られたレコードなら
他の項目が同じであろうと全拠点に追加すべきで、
ABC001からABD001へ変更したものなら
全拠点のABC001をABD001へ変えるべきという動作。

ちなみに>731のようなケースも当然発生する。
現在の運用ではプライマリキーを部門コードとして、
間違ったものは削除フラグ項目を更新し使わなくしている。
これならどこでも作れるし、全体で同じものを使える。

> 拠点A、部門コード:ABC001 部門名:営業部
> 拠点B、部門コード:ABC001 部門名:企画部
このようなケースでは全体として正しい方と
決められた方で最終更新をし上書きされる。

> 拠点A、部門コード:ABC001 部門名:営業部
> 拠点B、部門コード:ABD001 部門名:営業部
このケースでは使わないコードのほうを削除フラグを立てさせ、
使うほうをデータ受信登録して使わせるという感じ。
DELETEしてしまわないのは、他のテーブルですでに使っている場合
削除済みではあるが、一応出すことができるようにしてある。(苦しい所だが)

そして>723の結論に至った。
×複数が拠点 ○複数の拠点
コメント1件

736
NAME IS NULL[sage]   投稿日:2016/10/26 14:09:54  ID:???.net(860)
俺の場合は、マスタ原本を保持するデータベースサーバに接続可能なときのみマスタメンテを使えるようにして、そのデータベースに対してのみ更新するようにした。
更新の波及はトランザクションレベルの即時レプリケーションで。

トランザクションデータはUUIDをサロゲートキーにした。
コメント2件

737
NAME IS NULL[sage]   投稿日:2016/10/26 14:14:04  ID:???.net(860)
>736
俺もそうするかな
マスタは好きに弄くらせたら統制とれんし

738
NAME IS NULL[sage]   投稿日:2016/10/26 19:50:24  ID:???.net(860)
システム外から与えられる、あるいは持ち出すならそれはもはやナチュラルキーとして扱うべきだな。

739
NAME IS NULL[sage]   投稿日:2016/10/26 20:59:23  ID:???.net(860)
根本はデータの分散と競合の問題で、キーの種類関係ないな
コメント1件

740
NAME IS NULL[sage]   投稿日:2016/10/26 23:17:54  ID:???.net(860)
共通でCRUDするデータはナチュラルキーか、一ヶ所で管理、
SELECTのみの履歴データのようなものはサロゲートキーで外に出せるってとこかね。

741
NAME IS NULL[sage]   投稿日:2016/10/27 01:12:31  ID:???.net(860)
>707
カメだけど買った
ありがとうございました

742
NAME IS NULL[sage]   投稿日:2016/10/27 08:37:02  ID:???.net(860)
>735
すでにあちこちにあるシステムを無理矢理統合してるとか言うならわかるけど新規でそんなシステム組んでたら単なるバカでしょ

> このようなケースでは全体として正しい方と
> 決められた方で最終更新をし上書きされる。

> このケースでは使わないコードのほうを削除フラグを立てさせ、

要するにどこかで人間の判断が入ってるんだろ?
登録時の手順をきちんと決めればいいだけのように気がする
まあ社内の力関係とかで無理って言う事情があるのかもしれないけど

>739
だね
コメント1件

743
NAME IS NULL[]   投稿日:2016/10/27 10:25:18  ID:oEDm5n89.net
>742
ネット障害やサーバー障害に強く、
単体として切り離して継続稼働もできるから断言はできない。
むしろパッケージなら普通な設計。
コメント1件

744
NAME IS NULL[sage]   投稿日:2016/10/27 12:50:25  ID:???.net(860)
>743
> ネット障害やサーバー障害に強く、
> 単体として切り離して継続稼働もできるから断言はできない。
そう言うのは >736 のようにマスターの複製をローカルに持てばいいだけ

> むしろパッケージなら普通な設計。
どこの糞パッケージだよ
名前だしてみ
コメント1件

745
NAME IS NULL[sage]   投稿日:2016/10/27 13:10:31  ID:???.net(860)
皆さんは管理画面などの操作ログってDBに保存しますか?
INSERT・UPDATE・DELETEは保存した方が良い気がしていますが、
どこまで保存するべきかで悩んでいます。

要件・規模によるでしょうが、一般的な考え方があれば教えてください。
コメント2件

746
NAME IS NULL[sage]   投稿日:2016/10/27 13:35:48  ID:???.net(860)
>744
分からんやつだな・・・黙っててくれると助かる。
根本的に論点が違うんだよ。
各拠点で登録更新は自由にできる前提の話だぞ。
かつ、そのデータを共有するってことで話してるのだ。

マスターの複製をローカルに持った所で、
障害中に新たに100件必要になったら
障害直るまで待つとか通らない世界の話ということだ。
コメント3件

747
NAME IS NULL[sage]   投稿日:2016/10/27 13:48:38  ID:???.net(860)
> 障害直るまで待つとか通らない世界の話
横からだけど、それってつまり普通のシステムだと思うよ
コメント1件

748
NAME IS NULL[sage]   投稿日:2016/10/27 13:55:56  ID:???.net(860)
>745
要件・規模によるってのが一般的かと
証跡残すことは自分を守ることにも繋がるから残せるだけ残すのも手だよ
コメント2件

749
NAME IS NULL[sage]   投稿日:2016/10/27 17:58:32  ID:???.net(860)
>746
> 各拠点で登録更新は自由にできる前提の話だぞ。
> かつ、そのデータを共有するってことで話してるのだ。
だから、それが実現できてるパッケージって例えば何?
普通の設計なんだからいくつもあるんでしょ?

750
NAME IS NULL[sage]   投稿日:2016/10/27 18:17:51  ID:???.net(860)
こ、、、これから作るニダ

751
NAME IS NULL[sage]   投稿日:2016/10/27 18:32:16  ID:???.net(860)
>746
言い換えると承認されていないマスターデータを使って成果物を作成しないといけないということだよね。
そのローカルで登録したマスターデータは、後にサーバに接続して同期した時にrejectされる可能性もあるんだから。
なくはないと思うけど、一般的とは思えない。

752
NAME IS NULL[sage]   投稿日:2016/10/27 19:07:48  ID:???.net(860)
>746
できもしない要件請け負って結局運用回避って名目で現場が苦労するシステム作ってなにどや顔してるんだよ w
マスターを各拠点で自由に更新って聞いた時点で身構えるのが普通だよ

753
NAME IS NULL[sage]   投稿日:2016/10/27 19:18:48  ID:???.net(860)
>745
管理画面を誰が操作するかにもよるかな
保守員とかのある程度わかってる人が操作ならあまり細かくは必要ないと思うけど不特定多数が操作するようなものなら残しておいた方がいいと思う
昔製品サポートやってたけど利用者のなにもしてませんって言う言葉は信用できないと思った方がいい
悪意とかじゃなくて無意識の操作は覚えてないのでヒアリングではどうしようもない
そう言うときはログが頼りになる
常時とれなくても何かの設定でとれる仕組みはあった方がいい
コメント1件

754
sage[]   投稿日:2016/10/27 20:02:13  ID:fYkFiAQ1.net

755
NAME IS NULL[sage]   投稿日:2016/10/27 21:23:29  ID:???.net(860)
>747
普通のシステムだよな。
きっとWEBのサービスしか知らないのだろう。

756
745[sage]   投稿日:2016/10/27 21:49:00  ID:???.net(860)
>748>753

ありがとうございます。
確かに753さんが言うようなケースって多々あるんですよね
誰かが必ず何かをしてバグやエラーが発生しているんです。

とはいえ、全てのデータを記録出来ないし、
記録するとなればすぐにDBが圧迫してしまう気がします。

なもんで、管理者IDと操作画面のURLと日時だけ記録すれば良いと思うのですが、
それだけでも大丈夫でしょうか?
コメント1件

757
NAME IS NULL[sage]   投稿日:2016/10/27 22:08:18  ID:???.net(860)
だから >748だろ

758
NAME IS NULL[sage]   投稿日:2016/10/27 22:27:04  ID:???.net(860)
バグやエラーが出るならそれはもはや作りの問題だろ。
操作ログを取る前にエラーが発生したときのエラーログを取れ。

759
745[sage]   投稿日:2016/10/27 23:42:08  ID:???.net(860)
エラーログはもちろんとってるのですが、テキストベースなために分かりづらいんですよね・・・

760
NAME IS NULL[sage]   投稿日:2016/10/28 00:13:25  ID:???.net(860)
ええ・・・ワガママやな
ログの種類を厳選するのではなく、ログの取得方法を工夫すべきでは?

761
NAME IS NULL[sage]   投稿日:2016/10/28 02:15:21  ID:???.net(860)
>756
今出てる問題を改善するのに操作画面と管理者と日時が特定出来れば充分なの?
まずはそこから、でもいいけど
コメント1件

762
745[sage]   投稿日:2016/10/28 08:31:29  ID:???.net(860)
>761
非エンジニア(デザイナーとか営業の人とか)が見て、
「こいつが操作したからこうなったんだな」というのが
最低限わかればいいと思うんです。

別に私のプロジェクトだけじゃなくても、
非エンジニア向けのログの取り方・見せ方と言うのは大事だと思うので。
コメント1件

763
NAME IS NULL[sage]   投稿日:2016/10/28 13:17:16  ID:???.net(860)
>762
理解。非エンジニア向けですね
欲をいうと登録/更新/削除と、重要なところはその画面のキー情報(社員コード/商品コード/受注番号etc)
ログとる仕組み作るのも大変だから予算との都合で取捨
コメント1件

764
NAME IS NULL[sage]   投稿日:2016/10/28 13:20:50  ID:???.net(860)
あ、画面のキー情報の例は社員マスタ画面/商品マスタ画面/受注画面とそれぞれ違う画面のつもりでかいてますん

765
NAME IS NULL[sage]   投稿日:2016/10/28 14:43:07  ID:???.net(860)
>763
ログ出力というのがファイル出力することだとしたら、データベースに出力する方法をお薦めする。
理由は、
・データ操作と監査データ登録を同じトランザクションで実行できる(双方の乖離が絶対に発生しない)
・データベースのバックアップで監査データもバックアップできる
・監査データテーブルには、データベースの仕組みで権限設定ができる
・万一、一つのデータベースと複数のアプリケーションサーバという構成になっても、監査データは1箇所に集まる
コメント1件

766
NAME IS NULL[sage]   投稿日:2016/10/28 20:22:28  ID:???.net(860)
>765
テキストなんてやだよw特定めんどいし
仕組み上ファイルにはくしかなくても最終的には収集してデータベースに持ちたい

767
NAME IS NULL[sage]   投稿日:2016/10/28 22:20:47  ID:???.net(860)
どう読んでもテキストをやめてDBに記録しろって推奨してるように見えるのだが。

768
745[sage]   投稿日:2016/10/28 23:09:08  ID:???.net(860)
みなさん、いろいろとありがとうございました。

とりあえず各ページの読み込みログを取得するようにしました。
最低限の、管理者ID、IPアドレス、リファラ、アクセス日時を取得して
この内容でどの程度の管理ができるのか、
どの程度ログが肥大化するのか見たいと思います。
コメント1件

769
768[]   投稿日:2016/11/03 19:30:18  ID:r6OR5gCg.net
再度気になることがありますので相談したいと思います。

当初、>768このように考えていたのですが、
管理画面ではない、公開サイトのログやメールログもDBで管理したいとなりました。

この場合、単純に
・管理ログテーブル
・ユーザーログテーブル
・メールログテーブル

と、3つのテーブルを追加するというのを考えているのですが、
ログって一括で見ないとどこが原因かわからない時もあります。
(Apacheのログは1つのファイルに書き込まれますし

かと言って1つのテーブルにまとめると、
ID|管理者ID|ユーザーID|メールアドレス|IPアドレス|リファラ|日時
みたいになり、ログによってはNULLになるカラムが多く出てきますし、
テーブル自体の肥大化も気になります。(ログテーションすればいいだけでしょうが・・・

こういったケースの場合、どうテーブル設計するのが良いのでしょうか?
コメント1件

770
NAME IS NULL[sage]   投稿日:2016/11/04 01:39:20  ID:???.net(860)
一括で見たいならビュー用意して、3テーブルのselectをunionでくっつけちゃえば
一括でみるより別々にみたほうが分かりやすい気がするから俺なら一つのテーブルにはしない
コメント1件

771
768[sage]   投稿日:2016/11/04 09:04:57  ID:???.net(860)
>770
なるほど。確かに分けて一つにするのは色々方法がありますが、
1つを分けるのは大変ですね。

自分のような設計ベタの場合、ついテーブルの数を減らしたくなるのですが、
DBを使ってるわけですし、テーブルの数よりも効率化と保守性を考えて設計します。
アドバイスありがとうございました。

772
NAME IS NULL[sage]   投稿日:2016/11/04 09:09:33  ID:???.net(860)
>769
それらのログをどう使いたいかに依ると思う

Apache みたいにどう動いているかを見るためのログならまとめた方がいいし、フィールドを細かく分ける必要はなくて人間しか見ないからテキストで持っておけばいい

例えば誰がたくさんメールを使ってるかとかも見たいと言うなら分けとかないと面倒になる
コメント1件

773
768[sage]   投稿日:2016/11/04 11:01:22  ID:???.net(860)
>772
一番は保守性ですね。例えば

・誰が操作したか
・メールが送信されたか否か

の2点を管理画面などで見られたら十分だと思います。
サーバログのようにテキストベースだとログ解析能力が必要です。
しかし、DBにしてHTML上に表示すれば誰が見ても分かります。

おそらくエンドユーザーからの問い合わせで多いのは
「メールが届いていない」「情報が更新されていない」「削除されている」
などの不具合かと思います。

メールに関して言えば、sendmailでもSMTPでもDBに送信した事実を保存しておけば、
「○月○日○時○分にメールが送信されています。
 届いていないということは、ご使用のプロバイダや迷惑メールフォルダ等をご確認ください」
といったサポートが出来ると思います。(開発者ではなくても
コメント1件

774
768[sage]   投稿日:2016/11/04 11:05:37  ID:???.net(860)
あと、もちろんテキストログで保存しておいて
cronで定期的にDBにinsertする方法もあると思います。
ログの肥大化や負荷がどうこう気にするなら、この方が良いかもしれません。

自分の経験上、ログは「トラブルがあった時に見る」程度で
転ばぬ先の杖的存在なのですが、欠かせないものでもあると思うので、
しっかりログ管理については勉強したいと思います。

775
NAME IS NULL[sage]   投稿日:2016/11/04 14:20:52  ID:???.net(860)
>773
> の2点を管理画面などで見られたら十分だと思います。
そりゃそう言う要件あるなら当然別々に管理するのが楽だろ
悩む理由がわからん

776
NAME IS NULL[]   投稿日:2016/11/07 11:26:05  ID:0I/PzWKI.net
スマホゲーム見てて思うのですが、課金ってどうテーブル設計してるんですかね?
単純にアイテムを買うだけなら、購入履歴に追加するだけで良いと思うのですが、
利用期間や日数に応じて課金する仕組みもあります。

これって「利用料(30日)600円」というような商品を作って購入履歴に追加するのか、
アイテム購入履歴テーブルとは別に、利用履歴テーブルみたいなの作るんですかね?

ユーザーテーブル
└アイテム購入履歴テーブル<=>アイテムテーブル
└利用履歴テーブル<=>利用期間テーブル?

みたいな設計を想像しているのですが、なんか違う気もする

そして購入したアイテムは使った(減った)という動作が必要なわけだから、
また別のテーブル(アイテム使用テーブル?)が必要になると思うし、
ものすごい数のテーブルになりそうで、設計が難しそうですね
コメント1件

777
NAME IS NULL[sage]   投稿日:2016/11/07 11:58:45  ID:???.net(860)
無理せずテーブル一つにまとめられるじゃん


778
776[sage]   投稿日:2016/11/07 13:36:21  ID:???.net(860)
ちょっと設計考えてみました。(ズレてたらすみません

■会員テーブル
ID|名前|
1 |名無し

■商品テーブル
ID|商品種別|商品名  |価格
1 |アイテム|武器    |100
2 |アイテム|防具    |200
3 |利用課金|30日利用|500
4 |利用課金|60日利用|900

■利用課金テーブル
ID|商品ID|利用日数
1 |3    |30
2 |4    |60

■購入履歴
ID|会員ID|商品ID|価格 |購入日
1 |1    |1     |100 |2016-10-29
2 |1    |1     |100 |2016-10-30
3 |1    |2     |200 |2016-10-31
4 |1    |4     |900 |2016-11-01

■請求履歴
ID|会員ID|請求額|請求日   |状態
1 |1    |400  |2016-11-01|支払待ち

779
776[sage]   投稿日:2016/11/07 13:39:49  ID:???.net(860)
このテーブル設計を考えたのですが、以下の疑問がわきます

1)会員の名無しが利用できるか否かをどうやって判定するのか?
2)アイテムを使用した後は使用履歴テーブルを作るのか?
 それとも購入履歴にカラムを追加するのか?
3)請求履歴は購入履歴の内容を合算した金額なわけですが、
  購入に対して支払った・キャンセルしたというのはどう判定するのか?
 購入履歴にカラムを追加するのか?支払い、キャンセルテーブルを作るのか?

そもそもこの基本設計が間違っている場合はご指摘ください

780
NAME IS NULL[sage]   投稿日:2016/11/07 13:54:24  ID:???.net(860)
カラムを追加しようと思ったときはまずテーブルの追加を思い出そう

781
NAME IS NULL[sage]   投稿日:2016/11/07 14:03:30  ID:???.net(860)
>776
スマホゲームなら、30日利用権とかは基本前払い(購入完了で権利発生)。
コメント1件

782
NAME IS NULL[sage]   投稿日:2016/11/07 14:12:49  ID:???.net(860)
まあ、参考程度に

会員テーブルと商品マスター(実装されている商品の一覧と属性、有効期限、価格)、
購入済商品テーブル(会員が購入された商品、購入日)
購入履歴はいらない気がする
1)会員の名無しが利用できるか否か
  購入済み商品テーブルに、会員ID、商品IDのレコードがあれば利用できると思う。
2)アイテムを使用した後は使用履歴テーブルを作るのか?
 それとも購入履歴にカラムを追加するのか?
  購入したアイテムに有効期限、使用回数制限があるなら、購入済商品テーブルにその項目を追加する。

3)請求履歴は購入履歴の内容を合算した金額
  ゲームって購入時に即時支払いしてませんか?
  後払いになる場合は、購入済み商品テーブルに決済済かどうかの情報持たせて、
  決済日に未決済の商品をユーザーごとに集計すればできそう。
コメント1件

783
NAME IS NULL[sage]   投稿日:2016/11/07 14:23:23  ID:???.net(860)
途中使用で日割り返金も発生する可能性あるし
期間アイテムは効力が発生してる期間がわかる別データを蓄積すべき

784
776[sage]   投稿日:2016/11/07 14:25:45  ID:???.net(860)
>781
そうでした。スマホゲームは基本的に前払いなんですね。

>782
かなり詳しくありがとうございます!ただ、色々と疑問がわきます。
まず、1なんですが、購入履歴を「購入済み商品テーブル」と置き換えて
以下のような処理を考えました。

【2016/11/07時点で利用期間内かを調べる】

1)利用課金テーブルから商品IDを取得
SELECT 商品ID,利用日数 FROM 利用課金テーブル

商品ID3,4が該当

2)企業ID・1の購入履歴から該当する履歴を取得
SELECT 購入履歴ID,購入日 FROM 購入履歴 WHERE 企業ID=1 AND 商品ID IN("3", "4")

ID4が該当

3)該当した購入が利用期間内か調べる
SELECT 購入ID FROM 購入テーブル
WHERE NOW() < DATE_ADD(購入日,INTERVAL 60)

該当するので、企業ID・1の名無しは2016/11/07時点で利用できる

というSQLの流れを想定したのですが、これおかしくないですかね?
SQL3回発行してるし、プログラムとかで日数を取得しなきゃいけません。
コメント1件

785
NAME IS NULL[sage]   投稿日:2016/11/07 14:31:11  ID:???.net(860)
>784
購入済み商品テーブルに商品購入日があれば
その購入済み商品が現在使えるかどうかは
判断できるんじゃないですか?
コメント1件

786
776[sage]   投稿日:2016/11/07 14:32:48  ID:???.net(860)
↑の3)はおかしいですね
SELECT 購入ID FROM 購入履歴テーブル
WHERE 企業ID=1 AND NOW() < DATE_ADD(購入日,INTERVAL 60)

こうかな。

>購入したアイテムに有効期限、使用回数制限があるなら、購入済商品テーブルにその項目を追加する

購入済みのテーブルにアイテムの情報って持たないほうがいいんじゃないですか?
アイテム(商品)の種類に応じて必要なカラムが変わると思いますし。
コメント1件

787
776[sage]   投稿日:2016/11/07 14:35:01  ID:???.net(860)
>785
そうなんですが、どう購入日と比較するかが問題です。

商品によって利用期間日数が異なる場合、
まず、購入した商品の利用期間日数を取得して、
その日数の範囲内の購入履歴があるか調べるって流れになると思うんです。
コメント1件

788
776[sage]   投稿日:2016/11/07 14:41:40  ID:???.net(860)
なんか会員が企業になってますね・・。
ググりながらコピペしてたんで間違いました。会員の事だと変換ください。

789
NAME IS NULL[sage]   投稿日:2016/11/07 15:24:00  ID:???.net(860)
>786
>購入済みのテーブルにアイテムの情報って持たないほうがいいんじゃないですか?

購入した日付はユーザーごとにそれぞれ違うので購入した商品とセットにした方がいいと思います
同様に使用回数制限がある場合は、何回使っているか、商品とセットにした方がいいですね
会員がそのアイテムを使用すれば、購入済商品テーブルの該当商品の使用回数を減算していけばいいと
なります。

>787
購入済商品テーブルに購入した日付が入って入れば購入履歴はいらないんじゃないですか?
利用期間日数が異なって、その都度計算するのが煩わしいということなら、有効期限日を
テーブルに持たせればいいと思います

会員が現在使用可能な商品は、購入済商品テーブルから、
その会員IDと有効期限日前の、使用回数が0でない商品を検索すれば1回で済みます
コメント1件

790
776[sage]   投稿日:2016/11/07 15:38:14  ID:???.net(860)
>789
ありがとうございます。
改めて皆さんのアドバイスを元にテーブル設計してみました。

■会員テーブル
ID|名前|
1 |名無し

■商品テーブル
ID|商品種別|商品名  |価格 |使用回数
1 |アイテム|武器    |100 |5
2 |アイテム|防具    |200 |3
3 |利用課金|30日利用 |500 |1
4 |利用課金|60日利用 |900 |1


■利用課金テーブル
ID|商品ID|利用日数
1 |3    |30
2 |4    |60

■購入履歴
ID|会員ID|商品ID|価格|使用回数|状態  |購入日  |有効期限
1 |1    |1    |100 |5    |キャンセル|2016-10-29|NULL
2 |1    |1    |100 |5    |済み    |2016-10-30|NULL
3 |1    |2    |200 |3    |済み    |2016-10-31|NULL
4 |1    |4    |900 |1    |済み    |2016-11-01|2016-12-30

※スマホゲームだと支払った後に使用できるので、キャンセルは無いかと思いますが、
 一応、状態カラムを追加しました。

これだと、「会員ID・1の名無しは現在利用できるのか?」は探しやすいと思います。

791
NAME IS NULL[sage]   投稿日:2016/11/08 11:56:23  ID:???.net(860)
ユーザーまたは運営に表示する情報という視点で

・課金商品
 ゲーム内通貨 200 \2000
 ゲーム内通貨 500 \4000

・販売アイテム
 報酬3倍5個セット  価格40
 報酬3倍10個セット 価格70

ゲーム内通貨200を購入
5個セットを1つ, 10個セットを2つ購入
1個使用

・ゲーム内通貨履歴
 2016-11-08 11:00 ゲーム内通貨購入 +200 残額200 \2000
 2016-11-08 11:05 アイテム購入   -180 残額20

・アイテム購入履歴
 2016-11-08 11:05 報酬3倍5個セット  x1 40 計40
 2016-11-08 11:05 報酬3倍10個セット x2 70 計140

・アイテム欄
 報酬3倍 x24

・アカウント
 ゲーム内通貨残額 20
 報酬3倍使用中 期限12:10

テーブル設計とアプリの処理はそこから逆算

バグでデータ異常になった際の回復手段として
履歴テーブルは「基本insertのみ+冗長性高め」がオススメ
また、現在情報と履歴を分離しておくと
古い履歴をバックアップ&削除出来るようになる
コメント3件

792
776[sage]   投稿日:2016/11/08 13:08:30  ID:???.net(860)
>791
課金商品と販売アイテムは分けるんだけど、
履歴として統合させるって考え方はすごく参考になります。
今までの私ならそれぞれの履歴テーブルを作っていました。

また、履歴関係は「基本insertのみ+冗長性高め」というのも無い視点でした。
deleteやupdateさせてしまいがちですが、insertだけだと確かに管理しやすいです。

スマホゲームに限らず、課金・購入関係の設計というのは難しいので、
色んなパターンを想定しながら勉強します。ありがとうございました。

793
NAME IS NULL[sage]   投稿日:2016/11/08 13:12:36  ID:???.net(860)
バグの発生を前提に設計するってどうなんでしょうね

794
NAME IS NULL[sage]   投稿日:2016/11/08 13:37:32  ID:???.net(860)
フェイルセーフはあったほうがいいだろ
というか「現在値」を持つテーブルは壊れても復旧できるように
作っとかないと取り返しつかんくなるぞ
コメント1件

795
NAME IS NULL[sage]   投稿日:2016/11/08 14:01:56  ID:???.net(860)
>794
> というか「現在値」を持つテーブルは壊れても復旧できるように
> 作っとかないと取り返しつかんくなるぞ
普通は、「現在値」を持つのは、バグによるデータ不整合発生に備えるためじゃないよね。

796
NAME IS NULL[sage]   投稿日:2016/11/08 14:22:57  ID:???.net(860)
不整合発生に備えるために持つ
っていう話を誰かしてるか?
コメント1件

797
NAME IS NULL[sage]   投稿日:2016/11/08 14:29:51  ID:???.net(860)
まあ計算で出るものをわざわざ持たせるにはそれなりの理由が必要だよね

798
NAME IS NULL[sage]   投稿日:2016/11/08 14:34:27  ID:???.net(860)
>796
>791で「バグでデータ異常になった際」
というのが、データ不整合の話だと受け取ったが。

799
NAME IS NULL[sage]   投稿日:2016/11/08 15:05:21  ID:???.net(860)
バグによるデータ異常が頻発する環境にいるから、スキーマにフェールセーフの概念を入れておくべしという考えに至ったのだろう

800
NAME IS NULL[sage]   投稿日:2016/11/08 17:37:41  ID:???.net(860)
つか、バグ前提ならあらゆるデータ異常が考えられるわけで、それを設計に入れ込むなんて無理じゃないか?
コメント1件

801
NAME IS NULL[sage]   投稿日:2016/11/08 17:40:51  ID:???.net(860)
むしろリスクを考慮しない方が不思議
顧客情報および取引履歴などは災害も考慮して
遠隔地バックアップするところもある

操作ミスやデータ連携に起因する場合もあるし
誤請求が起きた際に対象の特定不可なんてことになったら悲惨

幸いにもそういった問題が起きたことは無いが
だからといって考慮しないというのはちょっと
コメント1件

802
NAME IS NULL[sage]   投稿日:2016/11/08 17:47:33  ID:???.net(860)
>800
完璧を求めて「何もしない」になるパターン?

803
NAME IS NULL[sage]   投稿日:2016/11/08 18:30:32  ID:???.net(860)
>801
>791の例だと、「アイテムを販売したのに売上レコードが登録されないバグ」とか、「何かを更新・削除しようとしたら意図しないレコードまでが対象になった」とかいろいろあるじゃん。
そういうのはデータベース設計には含められないよって事。

「誤請求」も、それがデータ内容がおかしい(請求処理コードは正しい)のが原因の場合もあれば、データ内容は正しいが請求処理コードがおかしい場合もある。
いずれにしても、データベース設計では救えない。
コメント1件

804
NAME IS NULL[sage]   投稿日:2016/11/08 18:32:58  ID:???.net(860)
「フェイルセーフ」をどういう意味で使ってるのかわからなけど、まぁ一般にバグによりデータがおかしくなったら、正しかった時点までデータを戻して、コード修正後REDOするかマニュアルで対処するしかないだろうね。

805
NAME IS NULL[sage]   投稿日:2016/11/08 18:36:39  ID:???.net(860)
あとは、データベースの仕組みで、データの一貫性が保たれるようにする。
ユニーク制約つけるとか、外部キー設定するとか、check制約付けるとか、計算結果をキャッシュするならトリガーでそれを行って同一トランザクションで正しい値がセットされるのを保証するとか。

806
NAME IS NULL[sage]   投稿日:2016/11/08 18:44:09  ID:???.net(860)
>803
>「アイテムを販売したのに売上レコードが登録されないバグ」

例:
売上レコードの登録 + 未反映レコードIDの登録
 → 未反映売上レコードを元に現在値を更新
※アーカイブログと同じ考え方

>「何かを更新・削除しようとしたら意図しないレコードまでが対象になった」

例:
insertのみ
コメント1件

807
NAME IS NULL[sage]   投稿日:2016/11/09 10:27:36  ID:???.net(860)
たまにupdateもdeleteも不要派がでてくるよね
コメント1件

808
NAME IS NULL[sage]   投稿日:2016/11/09 10:58:07  ID:???.net(860)
理由があってそう言ってるからね

809
NAME IS NULL[sage]   投稿日:2016/11/09 11:06:30  ID:???.net(860)
テンポラルテーブルとか出てきたけど
なんかまだ信用できないというか使えてない
コメント1件

810
NAME IS NULL[sage]   投稿日:2016/11/09 11:50:19  ID:???.net(860)
>807
履歴テーブルの情報消失リスクを下げるという話の流れな
現在値は何かあっても履歴から回復出来るから普通に更新する

長期間/小範囲の異常が後から判明するケースは
リストアやリカバリでは基本的に対処出来ない
コメント1件

811
NAME IS NULL[sage]   投稿日:2016/11/09 12:14:48  ID:???.net(860)
>809
パフォーマンスの都合で中間データを置くのに使う
一時表を使わずともDBMS側で色々キャッシュは掛かるから
使わない方が好ましいが、いざという時のため知っておいて損はないよ
コメント1件


812
NAME IS NULL[]   投稿日:2016/11/09 13:11:02  ID:oH9jZGKW.net(3)
バグによるデータ異常の話なんだが、バグでINSERTできていないとか誤った値でINSERTしたなどはないことになってるな
コメント1件

813
NAME IS NULL[]   投稿日:2016/11/09 13:14:37  ID:oH9jZGKW.net(3)
>810
前段と後段で話が矛盾してるだろ

長期間/小範囲の異常が後から判明したときにリストアやリカバリでも対処できなければ、現在値だって回復できないだろ
というか、そういう状態の時は、現在値すら正しいかどうかもわからん
コメント1件

814
NAME IS NULL[]   投稿日:2016/11/09 13:17:00  ID:oH9jZGKW.net(3)
データベースの内容にいつでも誤りが発生する可能性があるなら、別の手段でトランザクションを再現できるしくみろ作っておくとか、データ異常を検出する仕組みを作るべきだろ

まあ、普通はデータベースの内容には誤りはないという前提でコードを書くんだが

815
NAME IS NULL[sage]   投稿日:2016/11/09 13:33:31  ID:???.net(860)
>811
テンポラリーじゃなくてテンポラル表ね
テーブルにデータの変更履歴が残って、
ある時間でSELECTするとその時の値が出てくるやつ
http://www.oracle.com/technetwork/jp/database/application-developme...
https://msdn.microsoft.com/ja-jp/library/dn935015.aspx
コメント1件

816
NAME IS NULL[sage]   投稿日:2016/11/09 13:34:20  ID:???.net(860)
>812
それが>806で発生した場合どうなるか少しでも考えてみた?

>813-814
不良セクタ的な話でもしてるのか?話がズレすぎ

817
NAME IS NULL[sage]   投稿日:2016/11/09 19:41:16  ID:???.net(860)
バグという言葉で想像してるレイヤーが広すぎるから話が収束するわけがないわ

818
NAME IS NULL[sage]   投稿日:2016/11/12 00:44:54  ID:???.net(860)
>815
テーブル単体でみてもどのトランザクションか特定するの難しいな
トランザクションIDのカラムがあればまだなんとか
REDOログのバックアップから解析できれば最強だと思うんだけどな

819
NAME IS NULL[sage]   投稿日:2016/11/13 13:05:54  ID:???.net(860)
課金とか履歴の話ししてるから相談なんだけど、
取り消しとかキャンセルはどう扱ったら良いの?

状態の変更で済ますの?
それとも「履歴テーブルは事実のみ残す」として、updateやdeleteはせずに、
別テーブル(キャンセルテーブル)とか作るの?
コメント1件

820
NAME IS NULL[sage]   投稿日:2016/11/13 15:16:05  ID:???.net(860)
それこそ要件と設計方針次第だろ

たんに取り消しとかキャンセルとか言われても
それが取り消されている事実だけがわかれば良いのなら単なる状態変更で良いかもしれんが
いつ誰がどういう理由で取り消したのか分からないと困るとか
取り消しを取り消したときその事実が分からないと困るとか言われたらどうするよ

821
NAME IS NULL[sage]   投稿日:2016/11/13 18:44:41  ID:???.net(860)
ここで例になってる課金の場合なら「誰がいつ取り消したか?」は必要だよなぁ。
とすれば、別テーブルか。

それか、課金テーブルの方に状態カラムを追加して、状態変更するけども、
履歴テーブルも使用するパターンか。

汎用性を重視するなら後者か。

822
NAME IS NULL[sage]   投稿日:2016/11/14 10:51:42  ID:???.net(860)
それを履歴と呼ぶかログと呼ぶか証跡と呼ぶかはともかく
金が絡むものは全部残すようにしとかないと大事故になりそう

823
NAME IS NULL[sage]   投稿日:2016/11/14 11:41:08  ID:???.net(860)
>819
どれを選ぶかは要件次第だけど
選択肢としては赤伝方式もある

同じテーブルにマイナス金額で取り消しの行を作る
関連付けのため取り消し対象の一意キーも持つ
コメント1件

824
NAME IS NULL[sage]   投稿日:2016/11/14 12:06:43  ID:???.net(860)
>823
それのメリットってなんなの?
状態変更→履歴追加と変わらないと思うし、
むしろマイナス値加える方が無駄が多くなると思うんだが
(マイナスじゃない場合は0かNULLだろうし

825
NAME IS NULL[sage]   投稿日:2016/11/14 12:10:15  ID:???.net(860)
そりゃ要件次第
履歴と状態に分けるのが無駄なケースもあるでしょ
うちのペイメントログなんかそんな感じだよ
コメント1件

826
NAME IS NULL[sage]   投稿日:2016/11/14 12:13:45  ID:???.net(860)
>825
よかったら、どういう要件でそうしてるのか教えてくれない?話せる範囲でいいから。

827
NAME IS NULL[sage]   投稿日:2016/11/14 12:42:44  ID:???.net(860)
つまるろころ赤伝は「取り消し」なのかって話だな
売上金額的にはマイナスしたいが、売り上げた事実そのものはなくさない

たんにマイナスの売り上げだととらえられなくもないから
普通に売り上げテーブルに追加するのは当然

つか普通に業務システムやってれば赤伝が必要な要件なんていくらでもあると思うが

828
NAME IS NULL[sage]   投稿日:2016/11/14 13:07:36  ID:???.net(860)
赤伝が必要な業務システムをやったことがない

829
NAME IS NULL[sage]   投稿日:2016/11/14 13:22:59  ID:???.net(860)
取消が業務上発生するなら赤伝のほうがいいし
取消はメンテナンスの一種という要件なら削除フラグでもいいかもしれん

830
NAME IS NULL[sage]   投稿日:2016/11/14 13:26:39  ID:???.net(860)
うちは月次確定前の入力ミスは直接の修正や論理削除が可能
確定後だったり顧客都合の場合は赤伝で事由入力が必須
メリット云々でなく単にユーザー企業からの要請

831
NAME IS NULL[]   投稿日:2016/11/14 19:31:39  ID:CaXG621e.net
なにまた削除フラグやってんのか

832
NAME IS NULL[sage]   投稿日:2016/11/14 20:15:25  ID:???.net(860)
月次とかで一旦締めちゃうからその後の訂正は赤伝でやるって言うのは多くの企業でやってると思う
まあ経理関係の業務に関わらないと知らないのも無理はない
締めたデータで税金とか色々計算するから元データをホイホイ変えられると困るからね

833
NAME IS NULL[]   投稿日:2016/11/15 00:36:38  ID:5C6At6yC.net(2)
POSジャーナルとかだと、黒に対する赤黒反転させたデータを自動で作って相殺してるね。
赤黒はUPDATE日付、UPDATE_PG名、CREATE日付、CREATE_PG名のカラムがあれば追えるんじゃない?

834
NAME IS NULL[sage]   投稿日:2016/11/15 00:44:27  ID:???.net(860)
経理関連は黒赤がいい
絶対に間違えられないとこだからデータの更新自体したくない(処理済みフラグとかは除いて)

835
NAME IS NULL[]   投稿日:2016/11/15 01:12:59  ID:5C6At6yC.net(2)
日々、一億件を超えるデータが飛んでくるとこがあり、
調査でSQL投げても30分は帰ってこなかったなぁ
ちなにみそのテーブルのカラム数は700近かった・・・
コメント1件

836
NAME IS NULL[sage]   投稿日:2016/11/15 01:27:08  ID:???.net(860)
まともに把握してるやつ居なさそうw

837
NAME IS NULL[sage]   投稿日:2016/11/15 06:00:02  ID:???.net(860)
糞設計やな

838
NAME IS NULL[sage]   投稿日:2016/11/15 07:03:26  ID:???.net(860)
>835
一億件程度のデータは今時ままあるけどカラム数 700 はさすがに何か間違ってる気がする

839
NAME IS NULL[sage]   投稿日:2016/11/15 11:58:37  ID:???.net(860)
700って
なんだろ、汎用機とか全然違うシステムの資産をそのまま持ってきたとか?
1レコード1ページか、あるいは8KBに納まってなさそうそんなテーブル扱ったことないな


840
NAME IS NULL[sage]   投稿日:2016/11/15 12:00:02  ID:???.net(860)
ああごめんSQLserverのスレと勘違いしてた
8KBのくだりはなしで

841
NAME IS NULL[sage]   投稿日:2016/11/15 12:03:28  ID:???.net(860)
日に一億超はすごいと思う

842
NAME IS NULL[sage]   投稿日:2016/11/15 14:02:48  ID:???.net(860)
1秒に1000件を超える勢いで24時間か、そりゃ規模がでかすぎて普通に対応してたら厳しいわ

843
フーテンの虎次郎[sage]   投稿日:2016/11/15 17:46:41  ID:???.net(860)
1157件毎秒

844
NAME IS NULL[sage]   投稿日:2016/11/15 18:07:59  ID:???.net(860)
http://www.fujitsu.com/jp/solutions/infrastructure/construction/dwh/...
>今後、これがすべてスマートメーターに置き換わると、年間で約1200億レコードものデータが生み出される

そういう規模になってくるとテーブル云々どころか
リレーショナルDBかグラフ型DBかみたいなレベルからの設計になるんだろうな
何かちょっと楽しそう

845
NAME IS NULL[]   投稿日:2016/11/16 19:51:08  ID:BwtU0UQt.net
私は元創価の会員でした。
すぐ隣に防衛省の背広組の官舎があるのですが、
自分の家の窓にUSB接続のwebカムを貼り付けて、そこの動画を撮影し続け、
学会本部に送っていました。

別に大したものは写っていません。ゴミだしとか奥さんが子供を遊ばせている所とか。
官舎が老朽化して使われなくなってから、
今まで法人税(うちは自営業です)をほぼ払わなくても済んでいたのが、
もう守ってやれないのでこれからは満額申告するように言われました。
納得がいかないと言うと、君は自業自得で餓鬼地獄に落ちる、
朝夕南無妙法蓮華経と三千回ずつ唱えて心をきれいにしなさいと言われ
馬鹿らしくなって脱会しました。

それ以来、どこへ行くにもぞろ目ナンバーの車につけまわされたり大変な日々です。
全ては自分の出来心から起きた事で、どこに訴えて出ると言う訳にもいかないのですが、
何とかしてあの人たちと縁を切った上で新しい始まりを迎える方法はないんだろうか。

846
NAME IS NULL[sage]   投稿日:2016/11/16 20:48:12  ID:???.net(860)
ここにコピペって誰得?

847
NAME IS NULL[]   投稿日:2016/11/16 22:32:02  ID:m5+ecl6T.net
700カラムの使い方がこんな感じだったかと
 前半300までは全てのデータ区分で使用
 300-350まではデータ区分Aで使用
 350-400まではデータ区分Bで使用
 400-450まではデータ区分Cで使用

   ・
いにしえの資産でOccuresっぽい使い方してた名残かな
あと区分ABCでテーブル分けるよりこの方が表領域が少なくて済むと聞いたけど・・・データが見難い

848
NAME IS NULL[sage]   投稿日:2016/11/16 23:25:35  ID:???.net(860)
OCCURSとはなつかしいCOBOLで使ってたな
データベースなに使ってるか知らんが、表領域小さいのはわかるけどディスクIOとメモリは無駄に負荷かかってそう

849
NAME IS NULL[sage]   投稿日:2016/11/16 23:43:06  ID:???.net(860)
テーブルが1対1になるのを極端に嫌う人っているよね

850
NAME IS NULL[sage]   投稿日:2016/11/17 01:07:31  ID:???.net(860)
本来複数レコード分をOCCURSで1レコードにして一気に読むんだから
IO負荷は下がるだろ
区分分けで無駄なデータ読み込むのはOCCURSとはまた別の話だし

851
NAME IS NULL[sage]   投稿日:2016/11/23 21:15:21  ID:???.net(860)
2chBEのソースコードがリークされ酷すぎる実装がバレる、なお流出の原因は.gitディレクトリ
別スレッドへのリンク(タイトル情報なし/ニュー速(嫌儲)板)

852
NAME IS NULL[sage]   投稿日:2016/12/10 17:06:46  ID:???.net(860)
商品名1
商品名2
...
商品名50
みたいな文字列型のカラムを持つ単純なテーブルがあり、
そこに商品の数も保持したいのです。
追加で50個のint型のカラム
商品数1
商品数2
...
商品数50
を追加するのが良いかと思うのですが、カラム数が100個にもなります。

そこで例えばCの構造体みたいな

 string 商品名
 int 数

をペアで一つのカラムに保存するなどは出来ませんか?
それなら50カラムで足りると思います。
コメント4件

853
NAME IS NULL[sage]   投稿日:2016/12/10 18:38:32  ID:???.net(860)
商品(商品名, 商品数)
で50行商品を挿入じゃダメなん?

854
NAME IS NULL[sage]   投稿日:2016/12/10 19:45:26  ID:???.net(860)
>852
構造がおかしい
商品増えたらどうすんの?

855
NAME IS NULL[sage]   投稿日:2016/12/10 20:59:46  ID:???.net(860)
>852
「データベース 正規化」で検索

856
NAME IS NULL[sage]   投稿日:2016/12/10 21:35:12  ID:???.net(860)
>852
レス古事記乙
コメント1件

857
NAME IS NULL[sage]   投稿日:2016/12/10 21:57:46  ID:???.net(860)
>856
非道な文言

858
NAME IS NULL[]   投稿日:2016/12/10 22:14:55  ID:gS9WP37z.net
データーの中身がスゴイ気になる

859
NAME IS NULL[sage]   投稿日:2016/12/11 14:38:35  ID:???.net(860)
>852
商品名\t数
これでバッチリ

商品名A\t数A\t商品名B\t数B\…
で1カラムにまとめればスッキリ
コメント1件

860
NAME IS NULL[]   投稿日:2016/12/11 15:04:22  ID:hv2Rs4Dw.net

861
NAME IS NULL[sage]   投稿日:2016/12/11 15:47:43  ID:???.net(860)
>859
なるほど
そうします

862
NAME IS NULL[sage]   投稿日:2016/12/11 16:57:31  ID:???.net(860)
UPDATE処理がめちゃくちゃ大変そうやな

863
NAME IS NULL[sage]   投稿日:2016/12/11 18:48:30  ID:???.net(860)
はい解決、次行こう

864
NAME IS NULL[]   投稿日:2016/12/12 21:18:43  ID:eeDavYCt.net
ヤフオクの取引ナビみたいに、1対1でやりとりする掲示板の設計を考えています。
まず単純にやりとりテーブルのカラムを
ID|送信した会員ID|受信した会員ID|メッセージ|日付|既読日

と考えたのですが、掲示板なので送受信の投稿を一画面で表示したいので
これだと自分が送信した場合、受信した場合の履歴しか閲覧できません。

なにか良い考え方・設計の仕方はないでしょうか?
コメント1件

865
NAME IS NULL[sage]   投稿日:2016/12/13 00:39:40  ID:???.net(860)
>これだと自分が送信した場合、受信した場合の履歴しか閲覧できません。
それ以外に何を表示したいの?
コメント1件

866
NAME IS NULL[sage]   投稿日:2016/12/13 01:14:29  ID:???.net(860)
>865
ヤフオクの取引ナビって、1画面で送信受信が一緒に表示されるんです。
表示は2ちゃんの掲示板みたいな感じです。
なので、メールみたいに受信BOX・送信BOXみたいに設計すると実現できません。
コメント1件

867
NAME IS NULL[sage]   投稿日:2016/12/13 01:38:52  ID:???.net(860)
>866
送信と受信を時間でソートして表示すればいいだけだろ

868
NAME IS NULL[sage]   投稿日:2016/12/13 09:36:19  ID:???.net(860)
select
  case
    when 送信した会員ID = (自分) then '送信'
    when 受信した会員ID = (自分) then '受信'
  end as 送受信,
  h.*
from テーブル h where
  送信した会員ID = (自分) or 受信した会員ID = (自分)
order by
  日付

869
NAME IS NULL[sage]   投稿日:2016/12/13 09:59:57  ID:???.net(860)
>864殿
請求書:10マソ、ただし、コーディング代として
月末締めの翌々月払いにてお願いします

敬白

870
NAME IS NULL[sage]   投稿日:2016/12/13 12:14:50  ID:???.net(860)
掲示板風に使うならテーブルも掲示板風にすればいいだけじゃねーの?

・掲示板テーブル
・掲示板の利用者テーブル
・掲示板のコメントテーブル

ってして、オークションが終わった後に掲示板テーブルにinsertして、
そのIDを利用者テーブルに会員IDを2レコード(出品・落札者分)追加する
そしてコメント投稿する時は利用者テーブルから掲示板IDを取得して投稿する。

これなら868みたいなコストがかかる糞コードを書かなくても良くなる
コメント1件

871
NAME IS NULL[sage]   投稿日:2016/12/13 14:17:54  ID:???.net(860)
もっと糞にしてどーするw

872
NAME IS NULL[sage]   投稿日:2016/12/13 14:24:53  ID:???.net(860)
どこが?
コメント1件

873
NAME IS NULL[sage]   投稿日:2016/12/13 20:15:42  ID:???.net(860)
>872
2レコード追加する辺りかな
コメント1件

874
NAME IS NULL[sage]   投稿日:2016/12/14 00:38:07  ID:???.net(860)
>873
追加しないとやり取りできねーだろw

875
NAME IS NULL[sage]   投稿日:2016/12/14 00:43:42  ID:???.net(860)
ま、1対1と固定されてるから、利用者テーブルは必要ないか。
掲示板テーブルに作成者と対象者の会員IDを保存する形か

876
NAME IS NULL[sage]   投稿日:2016/12/14 01:14:10  ID:???.net(860)
>870
こういうこと?

やり取りテーブル
やり取りID|送信者ID|受信者ID|メッセージ送信日時|既読日時

会員別やりとりテーブル(やり取りの最初に送受信者で1
会員ID|やり取りID|送受信区分

会員別やり取りテーブルに送受信者の2レコード作っとけば、参照だけなら少ないコストでいけるかな

877
NAME IS NULL[]   投稿日:2016/12/14 04:10:03  ID:NT2Erum8.net(5)
iTunesのランキングを日付毎に取得して保存したいです

どのような設計が一番効率的でしょうか?
コメント2件

878
NAME IS NULL[]   投稿日:2016/12/14 04:33:12  ID:NT2Erum8.net(5)
用件定義
・ランキングは日変動
・アプリを指定すると、順位の推移を表示

3日間考えましたがどのような設計をすればいいかわかりませんでした

よろしくお願いします

879
NAME IS NULL[sage]   投稿日:2016/12/14 04:57:53  ID:???.net(860)
>877
>iTunesのランキングを
どこで見られる?

880
NAME IS NULL[]   投稿日:2016/12/14 08:10:04  ID:NT2Erum8.net(5)
ここです
http://www.apple.com/jp/itunes/charts/paid-apps/

順位推移をうつすためにはどのような設計がベストですか?
例えばアプリ名からそのアプリの順位推移
ランキング1位を指定すると歴代1位のアプリが表示

のようなことをしたいです
コメント1件

881
NAME IS NULL[sage]   投稿日:2016/12/14 09:38:18  ID:???.net(860)
>877
>iTunesのランキングを日付毎に取得して保存したいです
取得して保存する機能はもう完成しているのか?

882
NAME IS NULL[sage]   投稿日:2016/12/14 11:25:22  ID:???.net(860)
>880
そのままでいいんじゃないか?
ランキング (日付, 順位, アプリ名)

アプリの順位推移:
select * from ランキング where アプリ名 = 'hoge'

歴代1位:
select * from ランキング where 順位 = 1

毎日100レコード追加だと1年で36,500レコードしか生成されないので、インデックスはつけなくても大丈夫だろう。

883
NAME IS NULL[]   投稿日:2016/12/14 16:12:52  ID:NT2Erum8.net(5)
例えば10位まで365日保存するとしたら

日付 順位 アプリ

このテーブルを360個つくるということでしょうか?
それとも同じテーブルに3600個保存ですか?

頭悪くて申し訳ないですが、ご鞭撻おねがいします

884
NAME IS NULL[sage]   投稿日:2016/12/14 16:35:32  ID:???.net(860)
いやいや、一つのテーブルにINSERTするということ。

それはそうと、この件が単なるお勉強ではなくある程度の利便性も求めるなら、
保存するのは他の項目も含めてしておいた方がいいと思う。

例えば無料アプリtop10を取得すると、
https://itunes.apple.com/jp/rss/topfreeapplications/limit=10/json
・AppleがつけたアプリID
・カテゴリ
・リリース日
・有料アプリなら価格
・説明
・作者
とかいろいろ取得できるし。

885
NAME IS NULL[sage]   投稿日:2016/12/14 17:14:45  ID:???.net(860)
運用中にテーブル増やす仕様を考えるのは始めてから半年以内の初心者しかやらん
テーブルを追加できることが種目的なケースは別だけど

886
NAME IS NULL[]   投稿日:2016/12/14 21:56:15  ID:NT2Erum8.net(5)
頭悪くてごめんなさい。どうしても想像が膨らまないです
たとえば
ID 日付 順位 アプリ
1 14日 1位  パズドラ
2 14日 2位  モンスト

を取得したとして、15日はどう追加すればいいですか?

ID 日付 順位 アプリ
1 14日 1位  パズドラ
2 14日 2位  モンスト
3 15日 2位  パズドラ
4 15日 1位  モンスト

これだとなんか違う気がするんです…
 
コメント1件

887
NAME IS NULL[sage]   投稿日:2016/12/14 22:35:57  ID:???.net(860)
そこでソートだよ
ORDER BY 日付, 順位 にすれば

14日 1位  パズドラ
14日 2位  モンスト
:
15日 1位  モンスト
15日 2位  パズドラ
:
って出てきて望み通りだろ

888
NAME IS NULL[sage]   投稿日:2016/12/14 22:37:26  ID:???.net(860)
>886

その上でなぜ違うと感じるか
言葉で表現してみて。
なぜを重ねて本質的な
部分を追及して
あなたが実現したいことが
あるから感じることがあるはず。

889
NAME IS NULL[]   投稿日:2016/12/15 18:55:18  ID:41h8Tsky.net
昨今の著作権違反に対して、
不正登録などの通報を受け付ける機能をサイトにつけようと思います。

2ちゃんみたいに複数の掲示板や動画や画像コンテンツなどあるのですが、
コンテンツ分だけテーブルを用意するとテーブルが増えすぎてしまいます。
かといって、1テーブルにURLや通報コメントだけ保存するのも分かりづらいです。

通報機能をサイトに組み込んでいる方、どのように設計しているか教えてください。
コメント3件

890
NAME IS NULL[sage]   投稿日:2016/12/15 19:51:30  ID:???.net(860)
>889
なぜテーブル数を気にする?
テーブル数から上流の設計する気?
コメント1件

891
NAME IS NULL[]   投稿日:2016/12/15 19:56:24  ID:XdecS2Pq.net
著作権の前に己の馬鹿さを学んだらどうだ

892
NAME IS NULL[sage]   投稿日:2016/12/16 03:10:55  ID:???.net(860)
>890
コンテンツが増える毎にテーブル増えるって変じゃねーか?
並行してプログラムの工数も増えるだろうし、
同じテーブル・プログラムをコピペしているようなもんじゃん

893
NAME IS NULL[sage]   投稿日:2016/12/16 04:46:55  ID:???.net(860)
コンテンツってのがどのレベルのものを指して言っているのかはっきりしないから議論が正しくかみ合わんだろ
画像1枚を指して言ってるのかもしれんし、htmlの単位かもしれんし、フォルダやサイト単位かもしれん

894
NAME IS NULL[sage]   投稿日:2016/12/16 08:52:56  ID:???.net(860)
>889
>通報機能をサイトに組み込んでいる方、
例えばどんなサイト?
参考となるサイトを教えてくれ

895
NAME IS NULL[sage]   投稿日:2016/12/16 09:36:40  ID:???.net(860)
>889
>1テーブルにURLや通報コメントだけ保存するのも分かりづらいです。

分かりづらいという感覚がよく分からない

896
NAME IS NULL[]   投稿日:2016/12/16 11:20:28  ID:EKNyVeG1.net

897
NAME IS NULL[sage]   投稿日:2016/12/16 17:34:13  ID:???.net(860)
通報されたデータをどう見ようとしてるのかな
コストかけてちゃんとした機能作るんじゃなくて、csvにはいて担当者にわたすとかテーブル直で見させるとか考えてそうだが
まともに作るならそのあたりのことは機能設計進めれば見えてくるからな

898
NAME IS NULL[sage]   投稿日:2016/12/16 20:06:38  ID:???.net(860)
ちょっと何を言いたいのか分からない

899
NAME IS NULL[sage]   投稿日:2016/12/17 13:56:10  ID:???.net(860)
通報フォームでメール受信したらいんじゃね?
コメント1件

900
NAME IS NULL[sage]   投稿日:2016/12/20 20:08:31  ID:???.net(860)
>899
いや転送の方がシンプルに実装出来る
コメント1件

901
NAME IS NULL[sage]   投稿日:2016/12/20 21:43:05  ID:???.net(860)
>900
どっちでもいいけど、わざわざDBはさむ意味なくねーか?

902
NAME IS NULL[sage]   投稿日:2016/12/21 00:48:08  ID:???.net(860)
記録と分類のためにはDBに通報内容を保存するのもありだろう

903
NAME IS NULL[]   投稿日:2016/12/21 01:09:47  ID:zEZY0OoR.net
以前、こんなデータの持ちかたしてるDB見たんだ

発行SEQno1 100,102,103,104,….
発行SEQno2 200,205,223,244,….




2カラムしかなくて、2カラム目はデータをカンマ区切りで横持ち。
この持ち方による恩恵って何があるんだろ?
コメント3件

904
NAME IS NULL[sage]   投稿日:2016/12/21 01:55:33  ID:???.net(860)
もともとDBではなくシーケンシャルファイルでデータ持たせていた名残ではないだろうか

905
NAME IS NULL[sage]   投稿日:2016/12/21 07:02:20  ID:???.net(860)
>903
単純にリレーションを知らんだけかも
まあそのデータをどう使うかがわからんとなんとも言えないわな

906
NAME IS NULL[sage]   投稿日:2016/12/21 11:13:23  ID:???.net(860)
>903
・データ(ファイル)サイズがコンパクト
・KVSに移行しやすい

907
NAME IS NULL[sage]   投稿日:2016/12/21 18:33:05  ID:???.net(860)
テーブルレイアウトに関係なく項目を保存できる

908
NAME IS NULL[]   投稿日:2016/12/21 19:38:36  ID:rpLdLInk.net
アプリケーションにとって興味のあるデータがcsvの行そのものならごく自然な実装だろう
>903の情報だけで先入観を持ってあれやこれや考えてしまった奴は失格

909
sage[]   投稿日:2016/12/21 20:01:21  ID:C/hwpI+i.net

910
NAME IS NULL[sage]   投稿日:2016/12/25 08:51:55  ID:???.net(860)
「なぜアイウエオ順に改められないのか」
http://headlines.yahoo.co.jp/hl?a=20161224-00000027-it_nlab-sci
https://www.taro.org/2016/12/%e3%81%84%e3%82%8d%e3%81%84%e3%82%8d%...
河野太郎議員が年金事務所の「イロハ順」を問題提起

年金事務所におけるファイルの整理方法について疑問点を指摘。
「アイウエオ順」ではなく「イロハ順」を使用していることについて
今後調査する意向を示しています。

911
NAME IS NULL[]   投稿日:2016/12/28 15:10:25  ID:aQmnKv8v.net
上場会社(約3800社)の株価を毎日記録したいのですが
3800分のテーブルを作るのかひとつのテーブルに纏めるのかどちらがいいのでしょうか?
1年で約243日なので243レコードです

内容は前者と後者で
日付, 株価
日付, コード, 株価
になります

データの利用は一社ごとにするので、○日に○○円の会社を検索等はしないです
コメント4件

912
NAME IS NULL[sage]   投稿日:2016/12/28 15:55:46  ID:???.net(860)
どっちが手間かで決めればいい

913
NAME IS NULL[sage]   投稿日:2016/12/28 16:36:29  ID:???.net(860)
>911
仕様と設計がリンクしてるかそれ?

914
NAME IS NULL[sage]   投稿日:2016/12/28 17:23:33  ID:???.net(860)
テーブル3つだな

915
NAME IS NULL[sage]   投稿日:2016/12/28 17:47:44  ID:???.net(860)
なんで3つ

916
NAME IS NULL[sage]   投稿日:2016/12/28 18:24:15  ID:???.net(860)
>911
新規上場や上場廃止があればその度にテーブルの数が増減すんのか?
コメント1件

917
NAME IS NULL[sage]   投稿日:2016/12/28 18:59:34  ID:???.net(860)
そらおまえ統廃合による読み替え用の多対多テーブルよ

918
NAME IS NULL[sage]   投稿日:2016/12/28 19:44:26  ID:???.net(860)
>916
するわけないだろ
作って放置だ
沸いての?
コメント1件

919
NAME IS NULL[sage]   投稿日:2016/12/28 19:50:41  ID:???.net(860)
つーかさー、おまえら何気取ってテーブルとか言ってんだよ
日本人なら表って言え

920
NAME IS NULL[sage]   投稿日:2016/12/28 21:27:59  ID:???.net(860)
>918
>作って放置だ


作って放置なテーブル、どんな意味があんだ。
頭、糸引いて腐ってんの?
コメント1件

921
NAME IS NULL[sage]   投稿日:2016/12/28 21:32:26  ID:???.net(860)
だからただの表だろお前ら

922
NAME IS NULL[sage]   投稿日:2016/12/28 21:56:16  ID:???.net(860)
>920
発酵してるよ。

923
NAME IS NULL[]   投稿日:2016/12/29 14:38:10  ID:j+hAywaT.net

924
NAME IS NULL[sage]   投稿日:2017/01/02 23:36:17  ID:???.net(860)
テーブル1つで十分じゃねーの?

925
NAME IS NULL[sage]   投稿日:2017/01/03 07:08:07  ID:???.net(860)
テーブル 3800 とかネタだろ

926
NAME IS NULL[sage]   投稿日:2017/01/03 14:09:57  ID:???.net(860)
たかが表を扱ってるだけなのに何をうだうだいってるのかな

927
NAME IS NULL[sage]   投稿日:2017/01/04 10:50:48  ID:???.net(860)
まあまあ
運用で同じカラムのテーブルが増減する設計をする人なんて
DB触って3ヶ月以内の人しかいないからだいじょぶ

928
NAME IS NULL[sage]   投稿日:2017/01/04 14:08:26  ID:???.net(860)
ファイル3800個だとありな気がしてくる
コメント1件

929
NAME IS NULL[sage]   投稿日:2017/01/04 19:04:03  ID:???.net(860)
>911
複数市場に同時に上場している銘柄はどーすんの?(東証&名証 etc)
まぁ>911の例でいうならカラム一つ市場区分設けて同じ銘柄でも別テーブルにするのか。だったらもっと増えるなw
コメント1件

930
NAME IS NULL[sage]   投稿日:2017/01/04 19:07:10  ID:???.net(860)
>929訂正

カラム一つ市場区分設けて同じテーブルにはせず、別テーブルにするのか。だったらもっと増えるなw

931
NAME IS NULL[sage]   投稿日:2017/01/04 21:06:10  ID:???.net(860)
>928
そりゃ普通にあるでしょ...

932
NAME IS NULL[sage]   投稿日:2017/01/19 19:05:15  ID:???.net(860)
ユーザー登録のあるシステムを組むにあたってユーザーが2種類いる場合
テーブルは分けるべきでしょうか?

例えば、Amazon マーケットプレイスのような
販売ユーザーと購入ユーザーの2種類のユーザーが存在する
このような場合のテーブル設計についてご教示いただけると有り難いです。

システムにより違いはあると思いますが
一般的にはどうなってるのかを知りたくて質問しました。
よろしくお願いします。
コメント2件

933
NAME IS NULL[sage]   投稿日:2017/01/19 19:26:38  ID:???.net(860)
>932
> 例えば、Amazon マーケットプレイスのような
> 販売ユーザーと購入ユーザーの2種類のユーザーが存在する
そのケースなら販売と購入で管理する項目がかなり違うだろうから分けるのが自然な気がする
販売と購入で同じユーザーIDでやりたいとかならログイン管理のためのテーブルを別に持つとかもあるかもね
一般的には要件によるとしか言えんわな
コメント1件

934
NAME IS NULL[sage]   投稿日:2017/01/19 19:31:14  ID:???.net(860)
>933
やはり分ける方が自然ですよね
ご回答ありがとうございます。

935
NAME IS NULL[sage]   投稿日:2017/01/19 21:56:23  ID:???.net(860)
>932
一般的はあなたの問題を複雑にするよ

936
NAME IS NULL[sage]   投稿日:2017/01/20 17:29:07  ID:???.net(860)
サーバ移行のプロジェクトでいくつかのシステムのデータベースみてるんだけど、そのうちのひとつがテーブル10000超えてる
なんかを分析するシステムなんだが、やる都度テーブル作って削除する仕組みがない
ディスク増やしましょうバックアップ時間長くなります、なんてお客さんに言いたくないんだが主菅する部署が影響度調査嫌がってどうにもならん
放置はやめてけれ
コメント1件

937
NAME IS NULL[sage]   投稿日:2017/01/21 20:32:17  ID:???.net(860)
以前いた場所で似たようなことしてたな
新規にテーブル初くらかったが、
集計し分析する都度テーブルにレコードを追加してた
その時にしか使わないレコードなのに、ずっと放置
だんだん重くなるばかり。こっそり古いレコード削除してた

938
NAME IS NULL[sage]   投稿日:2017/01/21 22:15:42  ID:???.net(860)
>936
つHadoop

939
NAME IS NULL[sage]   投稿日:2017/01/25 22:18:08  ID:???.net(860)

板復帰(OK!:Gather .dat file OK:moving DAT 188 -> 173:Get subject.txt OK:Check subject.txt 188 -> 188:Overwrite OK)2.95, 2.16, 1.89
age subject:188 dat:173 rebuild OK!

940
NAME IS NULL[sage]   投稿日:2017/01/31 10:14:19  ID:???.net(860)
台帳にユーザーが任意の項目名で追加情報置けるようにした場合
メタテーブル的にするかKVSみたいにするか悩む

941
NAME IS NULL[sage]   投稿日:2017/02/21 19:47:38  ID:???.net(860)
本当に任意なら今だとJSONでやっちゃうかなぁ

942
NAME IS NULL[sage]   投稿日:2017/02/26 23:08:30  ID:???.net(860)
暇だったから過去レス見返してるけど、ほんと難しいな
課金の話とかややこしすぎ。けど、有名スマホアプリだともっと複雑なんだろうなぁ。

結論的には「要件次第」ってなるんだろうけど、
運用してると要件が後から変わってきちゃったりして、
最初にどこまで要件定義するかが後の設計に大きく関わる。

最初から何千・何億のレコードが入ることを想定した設計って
あらかじめ利用者が数万単位で想定できないと無理だし
テストも含めてそこまで考えるべきなのかなって思ったりして難しい

943
NAME IS NULL[]   投稿日:2017/03/15 22:05:29  ID:OuNraHqT.net
データベースとは直接関わりはないのですが、ER図の延長で、umlのクラス図で質問です。
うまく伝えにくいのですが、2つのクラス間に線がひいてあり、その線の途中から他のクラスに線が引いてあるのはなんて言うのでしょうか?

&#9723;----------&#9723;
|
&#9723;

944
NAME IS NULL[sage]   投稿日:2017/03/24 13:16:49  ID:???.net(860)
関連クラスかな

945
NAME IS NULL[sage]   投稿日:2017/04/13 21:55:50  ID:???.net(860)
データベースの設計について質問です

ファイルをデータベース化したいと思い設計しているのですがこういう感じでどうでしょうか?
fileid integer、hash text、name text、length integer、type integer、lastModified textといった表にしたいのですが
主キーはfileidです、正規化がよくわからず、以下のようなテーブルを考えて結合して表示させようと考えているのですがどうでしょうか?
fileid、hash
fileid、name
fileid、length
fileid、type
fileid、lastModified

946
NAME IS NULL[sage]   投稿日:2017/04/13 23:04:13  ID:???.net(860)
バラバラにする意図は?
コメント3件

947
NAME IS NULL[sage]   投稿日:2017/04/13 23:54:46  ID:???.net(860)
>946
正規化を知らない人は答えないで下さい
コメント2件

948
NAME IS NULL[sage]   投稿日:2017/04/13 23:58:33  ID:???.net(860)
何でもかんでもバラバラにするのは正規化と言わない

949
NAME IS NULL[sage]   投稿日:2017/04/14 00:00:51  ID:???.net(860)
主キーのfileldが分かればhash, name, length, type, lastModifiledを分ける必要は無い

950
NAME IS NULL[sage]   投稿日:2017/04/14 00:01:35  ID:???.net(860)
ごめん、正確には
主キーのfileldが分かればhash, name, length, type, lastModifiledが分かるならわざわざ分ける(正規化する)必要は無い

951
NAME IS NULL[sage]   投稿日:2017/04/14 00:02:51  ID:???.net(860)
けど要件次第で分けないといけないから>946のように要件聞く人もいるのに>947のレスを見る限り、
欲しい答えは帰ってこないだろうね

952
NAME IS NULL[sage]   投稿日:2017/04/14 00:06:17  ID:???.net(860)
主キーが一致する複数レコードがあると言うことかな?

953
NAME IS NULL[sage]   投稿日:2017/04/14 00:15:35  ID:???.net(860)
どうでもいいけど lastModified は datetime とかにしようよ...
コメント3件

954
NAME IS NULL[sage]   投稿日:2017/04/14 06:38:02  ID:???.net(860)
>953
同じテーブルに格納するからtextなんでは
まぁ普通のdbはこんなテーブル作らないね
コメント2件

955
NAME IS NULL[sage]   投稿日:2017/04/14 07:12:52  ID:???.net(860)
>954
> 同じテーブルに格納するからtextなんでは
意味不明なんだが...

956
NAME IS NULL[sage]   投稿日:2017/04/14 08:40:56  ID:???.net(860)
>954
???

957
NAME IS NULL[sage]   投稿日:2017/04/14 12:18:02  ID:???.net(860)
>953
話が発散するのでどうでもいいとこに口を出さないで下さい
コメント1件

958
NAME IS NULL[sage]   投稿日:2017/04/14 12:20:04  ID:???.net(860)
>957
なんやお前

959
NAME IS NULL[sage]   投稿日:2017/04/14 12:41:36  ID:???.net(860)
頭ん中が発散してるんだろ
もしかしたら既に発酵してるのかも知れんが w

960
945[]   投稿日:2017/04/14 20:34:36  ID:JLgv9GUw.net
返信遅れました。>947,957は自分じゃないです

>946
正規化を意識して、列を追加したりする可能性があるのでこういう設計になりました
ご指摘などありましたらお願いします

>953
書き忘れていました、C#でsqliteを使用してdbを作るつもりです
sqliteでdateTimeって使えますか?仕様見たけどなかったもので・・・
コメント1件

961
NAME IS NULL[sage]   投稿日:2017/04/14 22:29:35  ID:???.net(860)
「正規化」って何なのか、ちゃんと勉強しようよ。

962
NAME IS NULL[sage]   投稿日:2017/04/14 23:43:38  ID:???.net(860)
俺様に意見は無用

963
NAME IS NULL[sage]   投稿日:2017/04/15 02:07:53  ID:???.net(860)
>960
正規化の勉強から始めようやで

964
NAME IS NULL[sage]   投稿日:2017/04/15 08:17:35  ID:???.net(860)
列ごとにテーブルを作るのはメンテナンスが大変なのでお勧めできないかな。性能面で圧倒的に不利だしね。
正規化のメリットは「無駄を排除できる」てのが大きいと思うけど、さすがに本末転倒な気がする。

965
NAME IS NULL[sage]   投稿日:2017/04/20 21:45:00  ID:???.net(860)
>1
ねっとりしゃぶれよDB

966
ich1[]   投稿日:2017/04/21 16:39:00  ID:R/eXxgbc.net
https://goo.gl/q9Ml0S
これは嘘でしょ?本当だったら落ち込むわ。。

967
NAME IS NULL[]   投稿日:2017/05/17 14:29:51
将来的にメインテーブルにカラムを追加したいといます。
メインテーブルの設計は変えたくないので、補助用のテーブルを作って結合します。
補助用のテーブル、「テーブル名_options」というのを作ったとして、どう設計しますか?

A)テーブル名_optionsに、カラムが必要になる度に追加する
B)テーブル名_optionsを単一参照テーブルにする
C)テーブル名_optionsではなく、目的に応じたテーブルを作り、それだけのカラムを用意する

ご意見ください。お願いします。
コメント2件

968
NAME IS NULL[sage]   投稿日:2017/05/17 18:18:45
>967
SQL EAV
でググれ
コメント1件

969
NAME IS NULL[sage]   投稿日:2017/05/17 18:20:36
>967
「options jsonb」を追加する
コメント1件

970
967[sage]   投稿日:2017/05/17 18:32:14
>968
ググったのですが、いわゆるBのことですよね?

>969
すみません。こちらはググってもよく分かりません。
どいうことでしょうか?もう少し詳細を教えて下さい。
コメント2件

971
NAME IS NULL[sage]   投稿日:2017/05/17 19:00:10
>970
> ググったのですが、いわゆるBのことですよね?
俺のレスから12分しかたってないわけだが
ヒットしたページを何ページも読め
可変属性をどう扱うべきかが、EAVに関連して語られてることが多い

972
NAME IS NULL[sage]   投稿日:2017/05/17 19:02:34
>970
> どいうことでしょうか?もう少し詳細を教えて下さい。
969じゃないが、jsonb型のoptionsカラムを追加しろということかと
postgres以外にサポートしているDBがあるかどうか知らないが

973
NAME IS NULL[sage]   投稿日:2017/05/17 19:22:58
mysqlでは5.7でjsonが扱えるようになったそうで(自分が使ってるのは5.6なんでそこらへんは全然知りませんが)

974
NAME IS NULL[]   投稿日:2017/05/18 01:00:05
以下のようなクラスがあったとして、DBはどう設計するのが正しいのでしょうか?
1.TweetとReTweetは別テーブルにする
2.同じテーブルにして使わないフィールドはnull埋め
3.その他

class TweetBase{
&#160; &#160; id:int;
&#160; &#160; user:int;
&#160; &#160; date:Date;
}

class Tweet extends TweetBase{
&#160; &#160; text:string;
}

class ReTweet extends TweetBase{
&#160; &#160; //RTしたツイートのID
&#160; &#160; tweet:number;
}

975
NAME IS NULL[]   投稿日:2017/05/18 01:00:46
ここunicodeダメなのか…全スペで

class TweetBase{
  id:int;
  user:int;
  date:Date;
}

class Tweet extends TweetBase{
  text:string;
}

class ReTweet extends TweetBase{
  //RTしたツイートのID
  tweet:number;
}
コメント6件

976
NAME IS NULL[sage]   投稿日:2017/05/18 08:23:24
>975
そのままテーブルにしちゃえばいいんじゃね?
-- SQL-Server
create table TweetBase (
 id int identity (1,1) primary key,
 user int,
 date:Date
);
create table Tweet (
 TweetBase int not null references TweetBase(Id),
 text nvarchar(max)
);
create table ReTweet (
 TweetBase int not null references TweetBase(Id),
 -- RTしたツイートのID
 tweet int not null references TweetBase(Id)
);
コメント1件

977
NAME IS NULL[]   投稿日:2017/05/18 17:42:36
>976
外部キーで親を持つって事か
その発想はなかった
ありがとう

978
NAME IS NULL[sage]   投稿日:2017/05/18 18:10:50
>975
そもそも、この設計がダメダメ
共通の親クラスを持つ意味がない

たとえば、
・tweetを削除する
・retweetを削除する
を実装するとき、どこにどう実装するのか想像すればわかるだろう

979
NAME IS NULL[]   投稿日:2017/05/18 18:25:40
じゃあどうするのが正解?

980
NAME IS NULL[sage]   投稿日:2017/05/18 19:09:16
ダメだしできる俺かっけー

ってか w

せめて模範解答でも示してるならまだかっこはつくけどね
コメント1件

981
NAME IS NULL[sage]   投稿日:2017/05/18 22:49:16
スーパータイプ/サブタイプの問題は情処試験の定番だな。
一般的な解は3種類くらいあるからググってみろす。

982
NAME IS NULL[sage]   投稿日:2017/05/18 22:51:09
スキーマレスSQL使って全部ぶっこめばおk

983
NAME IS NULL[sage]   投稿日:2017/05/19 11:22:53
>980
普通に別クラスで実装
継承して良いのは、リスコフの置換原則に沿っている場合に限る
コメント1件

984
NAME IS NULL[sage]   投稿日:2017/05/19 20:14:19
俺ならクラス1個だな・・・
一応ケースバイケースだけどそれくらいならnullでいいだろ
コメント1件

985
NAME IS NULL[sage]   投稿日:2017/05/19 21:12:25
>975だけからはリスコフの置換原則に適うかそうでないか判断できんだろう。
コメント1件

986
NAME IS NULL[sage]   投稿日:2017/05/19 22:16:24
>983
どこが沿ってないのか詳しく書けるよね?
コメント1件

987
NAME IS NULL[]   投稿日:2017/05/19 22:39:04
>984
「そのくらい」じゃなくて分かりやすいように例示しただけで実際はもっと複雑
リスコフの置換原則は大丈夫
コメント1件

988
NAME IS NULL[sage]   投稿日:2017/05/19 23:11:32
>987
> 実際はもっと複雑
だからケースバイケースって言われてるんだろ
どんだけ複雑かなんてお前にしかわからんのだし

989
NAME IS NULL[sage]   投稿日:2017/05/19 23:47:37
>975
私なら再帰構造にしますよ。

Oracleで確認

--テーブル作成
DROP TABLE TWEET;
DROP TABLE TWEET_REL;
CREATE TABLE TWEET
(ID NUMBER NOT NULL,
MSG VARCHAR2(100) NOT NULL
);
CREATE TABLE TWEET_REL
(ID NUMBER NOT NULL, --リツイートID
PID NUMBER NOT NULL --リツイート元のツイートID
);
コメント2件

990
NAME IS NULL[sage]   投稿日:2017/05/21 21:50:51
クラス設計の良し悪しはスレ違いだしどうでもいいんだが
この手のやつはORM前提かどうかで変わると思うんだが

ORMごとに継承関係のあるクラスに対するテーブル設計のベストプラクティスとかないのか?

ORMを前提にテーブル設計を変えるのは本末転倒だって話もあるがな

991
NAME IS NULL[sage]   投稿日:2017/05/22 10:38:01
>985
> >975だけからはリスコフの置換原則に適うかそうでないか判断できんだろう。
今回の"Twitter"が実存するTwitterなら、tweet != retweetなのは明らか
tweetに対するメソッドと、retweetに対するメソッドを、>975のクラス構成でどこに実装すべきかを
考えれば、リスコフの置換原則に沿ってないのは明らか

992
NAME IS NULL[sage]   投稿日:2017/05/22 10:41:17
>986
> どこが沿ってないのか詳しく書けるよね?
逆にどこが沿ってるのか書いてみろ

993
NAME IS NULL[sage]   投稿日:2017/05/22 11:22:50
クラスから考えるからおかしくなるんじゃね?
ふつうにこれじゃ駄目なん?
table tweet (id, user, tweet_date, tweet_text, ...その他のtweetの属性)
table retweet (user, retweet_date, tweet_id)
コメント1件

994
NAME IS NULL[sage]   投稿日:2017/05/22 12:15:51
リスコフの置換原則か、勉強になるな、うん

995
NAME IS NULL[sage]   投稿日:2017/05/22 13:24:07
リスコフの置換原則と書かれるとどんな原則なんじゃいと思うかもしれないが、要はis-a関係かどうかって話なだけ。
あと、OOのクラスの継承と、データベースのテーブル継承は別だから、ごっちゃにして話すのよくない。

996
NAME IS NULL[sage]   投稿日:2017/05/22 13:34:39
>989
これのどこが再帰構造なんだろうか・・・

997
NAME IS NULL[sage]   投稿日:2017/05/22 15:36:17
>993
これ以外考えられん

998
NAME IS NULL[sage]   投稿日:2017/05/22 16:16:51
次スレヨロ

999
NAME IS NULL[sage]   投稿日:2017/05/22 16:21:24
よろよろ

1000
NAME IS NULL[sage]   投稿日:2017/05/22 16:26:22
>989
ORM脳

1001
1001[]   投稿日:0000/00/00 00:00:00
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 586日 20時間 40分 11秒

1002
1002[]   投稿日:0000/00/00 00:00:00
2ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 2ちゃんねる専用ブラウザからの広告除去
★ 2ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/

▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

データベース板 タイトル検索

このスレッドが人気です(実況系)
実況 ◆ テレビ朝日 47965 グローバル大下 (472)テレ朝実況
バイキングとグッディ★1 (583)フジ実況
実況 ◆ TBSテレビ 27717 江藤愛が北朝鮮と天気 (292)TBS実況
NHK総合を常に実況し続けるスレ 134137 天気下り坂 (406)NHK実況
実況 ◆ フジテレビ 83451 視聴率低下もノンストップ! (707)フジ実況
羽鳥慎一モーニングショー★6 (963)テレ朝実況
実況 ◆ 日本テレビ 55285 (1000)NTV実況
ビビット 5/24(水) ★1 (842)TBS実況
このスレッドが人気です(ニュース系)
【テロ等準備罪】「訂正するまで、安倍首相に書いたすべての単語を維持する」 ケナタッチ国連特別報告者が菅官房長官の抗議に再反論★5 (877)ニュー速+
【宅配】ヤマト値上げが裏目に? 運送会社化するアマゾン★3 (742)ニュー速+
【芸能】NEWS手越祐也のLINEアカウント流出か ”コネチケ”発覚でファンが騒然 (980)音楽・芸能ニュース
【テロ等準備罪】「訂正するまで、安倍首相に書いたすべての単語を維持する」 ケナタッチ国連特別報告者が菅官房長官の抗議に再反論★4 (1000)ニュー速+
【家庭】「夫はやっていない家の仕事がたくさん!」夫が家事と思っていない『名もなき家事』が存在。やっているのは9割が妻 (1000)ニュー速+
【社会】煎餅に金属片、女児けが 亀田製菓公表せず (188)ニュー速+
【家庭】「夫はやっていない家の仕事がたくさん!」夫が家事と思っていない『名もなき家事』が存在。やっているのは9割が妻★2 (370)ニュー速+
【宅配】ヤマト値上げが裏目に? 運送会社化するアマゾン★2 (1000)ニュー速+
データベース板の人気スレ
Oracle 質問総合スレ12 (763)
DB設計を語るスレ 9 (1002)
SQL初心者質問スレ (649)
PostgreSQL Part.11 (218)
Oracle 質問総合スレ9 (986)
MySQL 総合 Part24 (1010)
Oracle 質問総合スレ10 (1014)
SQL質疑応答スレ 15問目 (1013)
SQL質疑応答スレ 17問目 (331)
[test] 書き込みテスト 専用スレッド [テスト] (384)
MySQL 総合 Part25 (893)
Microsoft SQL Server 総合スレ 11 (402)
♪つっかもうぜ!DB! (65)
はじまりです。 (584)
XML統合スレッド (397)
SQLite Part.10 (601)
頼むから正規化しろよ 第二正規形 (288)
RDBMS比較総合スレ 【サーバ】 (115)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
広告


首都圏の方、ソフトバンク光オススメですよ


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード:差分取得 - 正常取得 - 14件 - 取得完了