DB設計を語るスレ 9 [転載禁止]©5ch.io
レス数が1000を超えています。これ以上書き込みはできません。
0001NAME IS NULL
2015/10/13(火) 19:46:12.50ID:???前スレ
DB設計を語るスレ 8
http://peace.2ch.net/test/read.cgi/db/1424250550/
0002NAME IS NULL
2015/10/13(火) 20:53:04.93ID:???0003NAME IS NULL
2015/10/13(火) 21:00:33.56ID:???削除フラグが最適な設計ではないにもかかわらず削除フラグを使っていることがあるというだけの話。
0004NAME IS NULL
2015/10/13(火) 21:10:13.03ID:???同一テーブルに保つ設計も結構見るよね
0005NAME IS NULL
2015/10/13(火) 23:04:05.10ID:???ミック本読んでるからミック本基準法の知識しかないけど、
中にはミック本駄目って人もいるわけだし、
そういった人はどこで知識仕入れてるんだ
0006NAME IS NULL
2015/10/14(水) 07:46:01.55ID:???0007NAME IS NULL
2015/10/14(水) 10:16:20.65ID:???奥野幹也の本お薦め。
Joe Celko本もお薦め。
あと、渡辺幸三の本が評判良い（業務システム向け）。
それから、SQLアンチパターンとアート・オブ・SQL。
0008NAME IS NULL
2015/10/14(水) 12:39:54.09ID:???0009NAME IS NULL
2015/10/14(水) 13:52:41.68ID:???0010NAME IS NULL
2015/10/14(水) 23:20:17.74ID:???>>2
そのフラグが概念設計上のエンティティの消滅を意味するならば、新規設計でそんなもの
導入すべきじゃない。
そうではない単なるフラグなら好きにする。ただし誤解を招く危険があるので名前は変えて
おいた方がよい。
0011NAME IS NULL
2015/10/15(木) 15:19:21.86ID:???0012NAME IS NULL
2015/10/15(木) 17:31:07.44ID:???0013NAME IS NULL
2015/10/15(木) 17:49:43.62ID:???0014NAME IS NULL
2015/10/15(木) 17:52:47.75ID:???0015NAME IS NULL
2015/10/15(木) 18:23:55.79ID:???0016NAME IS NULL
2015/10/15(木) 20:13:13.52ID:???0017NAME IS NULL
2015/10/15(木) 22:16:13.73ID:???0018NAME IS NULL
2015/10/16(金) 00:17:18.89ID:???なんか設計おかしいんじゃないだろか。
0019NAME IS NULL
2015/10/16(金) 06:19:59.71ID:???亜空間恒常性変換してからリレーショナルモデルにマッピングすれば大丈夫
0020NAME IS NULL
2015/10/16(金) 08:01:54.03ID:???お前自分で言葉の意味理解してないだろw
0021NAME IS NULL
2015/10/16(金) 09:31:08.75ID:???送受信内容は全て履歴として残す仕様なのですが、
送信先の会員が退会している場合、宛名が空欄になっています。
空欄だと誰に送信したか分からないので、どう設計すればいいか悩んでいます。
A）メッセージ送信時に宛名も保存する
B）前スレで議題に出ていたような削除フラグや履歴テーブルを使う
C）空欄のままにする
D）その他
どうするのがベターかアドバイスください。
0022NAME IS NULL
2015/10/16(金) 10:39:38.03ID:???『理論から学ぶデータベース実戦入門』 P182から引用
> リレーションは集合です。よって、各要素同士に順序はありません。し
> かし、履歴にはどちらが古いのか、新しいのかという順序が存在します。
> すなわち、履歴データをRDB上で扱うには、そもそもリレーションとして
> 表現できるかどうか、という本質的な関門が立ちはだかっているのです。
目次から引用。興味があるなら買って読んでみて。
> 第9章
> 履歴データとうまく付き合う
> 9.1 履歴データの問題点
> 世界は履歴データで溢れている
> 履歴とリレーショナルモデルの相性問題
> 履歴データの具体例
> 履歴データの何が問題になるのか
> リレーションと時間軸の直交性
> NULLの可能性
> 特定の行だけ意味が違う
> 9.2 履歴データに対する解決策
> リレーションを分割する
> 最もシンプルな分割方法
> 外部キーが使用できない
> 2つのテーブルの整合性
> 重複した行を許容する
> サロゲートキー
> 未来の価格はどうすべきか
> 9.3 履歴データのアンチパターン
> フラグを立てる
> Column フラグのお化け
> 手続き型として実装する
> Column テーブルを分けたときの物理的なメリット ....................................... 197
0023NAME IS NULL
2015/10/16(金) 12:23:27.36ID:???0024NAME IS NULL
2015/10/16(金) 12:34:55.97ID:???その要素間に順序を定義することには何の問題もない。
何のことはない、「履歴データを扱うのは難しい」ってのをちょっと格好つけて言ってるだけｗ
0025NAME IS NULL
2015/10/16(金) 12:35:51.56ID:???0026NAME IS NULL
2015/10/16(金) 13:12:54.90ID:???> 理論的な集合そのものには順序はないが、
> その要素間に順序を定義することには何の問題もない。
『理論から学ぶデータベース実戦入門』 P.184から引用
> 時間軸と直交していないものは、そもそもリレーションとは呼べません。
> リレーションとは、ある時点における事実の集合だからです。リレーショ
> ンの要件を満たしていないことは、1NFになっていないとも言い換えられ
> ます。つまり、そのようなリレーションの要件を満たさないテーブルに対
> するクエリは、リレーショナルモデルから逸脱したものとなります。
というような問題が発生する場合がある。
どういう場合にそのような問題が発生し、どう対処すればいいのかなどは、本買って読んでくれ。
ステマじゃないけど、この本の著者のファンだからお薦めはする。
なお、俺がこの本から引用するのはこれで最後。
引用しすぎるとアレだし。
002718
2015/10/16(金) 13:29:40.81ID:???ええっと、つまるところ相性は悪いが設計はできるということでいいのかな。
特別相性が悪いと思ったことはないけど、面倒といえば面倒かな。
0028NAME IS NULL
2015/10/16(金) 13:47:13.23ID:???> 特別相性が悪いと思ったことはないけど
それは多分、複雑なクエリを使ったり、LIMITや集約関数などの本来リレーショナルモデルに
対する演算ではないものを使ったり、外部結合してIS NOT NULLで拾ったりするのが前提に
なってるからじゃないかな。
そういうの無しでクエリが発行できる、正規化されたきれいなリレーショナルモデルとして
設計できない（場合がある）というのが「問題」。
0029NAME IS NULL
2015/10/16(金) 19:23:45.45ID:???だからその本の作者がバカなんだろ。
俺達が扱っているのは集合ではない。
テーブルだ。
0030NAME IS NULL
2015/10/16(金) 20:03:25.90ID:???スライド公開されてた、ありがてぇ
履歴については銀の弾丸はないよという単純な話に読めるが
本では違うのかな？
0031NAME IS NULL
2015/10/16(金) 20:17:43.45ID:???単に空白が嫌でなにか適当に入ってりゃいい
って言うなら
> A）メッセージ送信時に宛名も保存する
でいいだろ
0032NAME IS NULL
2015/10/16(金) 21:26:14.79ID:???それは単にレコードの順序で時系列を表現することはできないって言ってるだけだろ。
もしそれだけで時系列データが苦手ってことになるなら、順序関係や大小関係を持った情報の表現
全部苦手ってことになるわ。
そこは、テーブルを「Excelの表みたいなもの」って思っちゃうような初心者に向けた説明だろ。実際、
orderを指定しないとinsert順に出てくるように見える場合もあるからそう思い込む初心者もいる。
と思ったら
>>26
> リレーションとは、ある時点における事実の集合だからです。
この著者がおかしいような気がしてきた。
0033NAME IS NULL
2015/10/16(金) 22:35:33.31ID:???ある意味得体の知れないパラメーターを、その他の次元と同列に
扱わなければいけない事に由来する物であり、
それは、集合論だから特別に難しいという事ではなく
現在の科学的知識において普遍的に難しい問題なのである。
そうとは言え、システム要件という適用範囲を限定された檻の中では、
時間軸という得体の知れない物でも容易に表現出来る事はある。
つまり、リレーショナルモデルという原理主義に固執しすぎると
見える物でも見えなくなっちゃうよ！っつー事なんだ。
エンジニアだったら理論より実践だろ。
0034NAME IS NULL
2015/10/16(金) 23:32:16.75ID:???0035NAME IS NULL
2015/10/16(金) 23:56:22.79ID:???抜粋方法がヘタだっただけじゃないかなきっと。
著者みてないかもしれないけど奥野さんだよ。
0036NAME IS NULL
2015/10/17(土) 05:50:58.32ID:???> リレーションとは、ある時点における事実の集合だからです。
別にそれはおかしいとは思わんけどな
あんたが言うように、単に
> 順序関係や大小関係を持った情報
なんだし
0037NAME IS NULL
2015/10/17(土) 08:03:18.45ID:???ただしその場合、「未来以外全部」ということだから別にリレーションに限った話じゃないけどな。
0038NAME IS NULL
2015/10/17(土) 08:28:49.10ID:???例えば会員制の掲示板があったとして、誰がどのレスを投稿したかを知りたい時に、
レステーブル
└ユーザーテーブル
として結合関係になるわけだけど、退会したユーザーにも対応するためには
レステーブル
└ユーザーテーブル
└ユーザー履歴テーブル
みたいにしなきゃいけない。（またはサブクエリ使うとか）
こんな事になるなら、削除フラグつけて参照させた方が
よほど便利で分かりやすく、パフォーマンス的にも良くなると思うんだよなぁ
0039NAME IS NULL
2015/10/17(土) 09:04:40.80ID:???ユーザーテーブルとユーザー履歴テーブルって何者？
何がどういう理由でmust beなの？
SQL持ち出すならDDLとDMLで説明してくれ
0040NAME IS NULL
2015/10/17(土) 09:17:44.29ID:???今まで履歴テーブルの話してたんだから、
1から10まで説明しなくても理解してくれよ・・・
0041NAME IS NULL
2015/10/17(土) 10:00:08.40ID:???最初のテーブル構成で退会時に対応できないというのは、暗黙にユーザーエンティティの寿命を
「入会から退会まで」としているからだな。
ユーザーテーブル(現入会者のみ)
これに削除フラグを追加して
ユーザーテーブル(現入会者のみ) + 論理削除
とするのは、エンティティの寿命が曖昧になるので概念設計としてはよくない。
ここはエンティティの意味を変更して
ユーザーテーブル(入会したことがある者) + 状態(在籍|退会)
とすべき。
(結果的にテーブルの形としてはほとんど同じになるとしても)
そのうえで、前スレで挙がったように退会時に削除しなければならない情報があるのであれば、
それらを分離して
ユーザーテーブル(入会したことがある者)
└会員情報(退会時に削除)
とすればよい。
0042NAME IS NULL
2015/10/17(土) 19:13:20.44ID:???削除フラグの話を続けたい人って、こんな単純な解決方法にも反論はないの？
0043NAME IS NULL
2015/10/17(土) 19:53:32.03ID:???実際の使い方を想定すると、どっちも同じような意味合いに感じるんだけど。
0044NAME IS NULL
2015/10/17(土) 19:56:14.48ID:???ユーザーテーブルに「状態」ってカラムを用意して、
これが0なら停止、1なら有効、2なら退会
っていう意味を与えても問題ない（＝削除フラグとは違う）ってこと？
俺は昔からこういうやり方してたんだけど、
削除フラグと同じじゃないか？と感じて、違う方法を模索してるんだが。
0045NAME IS NULL
2015/10/17(土) 20:04:14.40ID:???0046NAME IS NULL
2015/10/17(土) 20:36:52.16ID:???参照が必要になった時に必ず状態の再計算が必要になる訳で
それにかかるコストは結局、データを永続化させたいという要求とは
相反する結果になるんじゃないか？
0047NAME IS NULL
2015/10/17(土) 20:53:35.30ID:???基本的には間違ってる
パフォーマンスのための正規化崩しとしては最も見られるパターンではあるけどな
永続化させるデータに状態を持たせるかどうかは、そのデータが状態を持ってるかどうか
つまり何度も言われるように要件次第
異なる状態のデータをどう格納するかがテーブル設計
フラグ付けたり、テーブルを移動させたり、実装方法はいろいろ
そこだけ見て良し悪しとか判断できない
0048NAME IS NULL
2015/10/17(土) 22:17:32.79ID:???論理削除の否定は、モデルとテーブル設計の間にギャップがあるのは良くないって話だからねぇ。
>>44のDBで概念設計上も「退会したユーザー」が存在し得るんであればそれで問題ないかと。
逆に言うと、テーブル設計だけ見て「これは削除フラグだからやめたほうが良い」なんてことも
言えない。
要は>>10
0049NAME IS NULL
2015/10/18(日) 08:30:08.01ID:???「退会したユーザーは存在させたくない」
けど
「名前は参照させたい」
って場合はどうなるの？
やっぱり履歴テーブルに移行させて、そこから参照するの？
割りとこういう要件って多いと思うんだよ。
「ユーザーデータ全てを残したくはないが、名前ぐらいは残して、
そのユーザーが投稿（利用）した別テーブルと参照させたい」って。
0050NAME IS NULL
2015/10/18(日) 08:48:44.46ID:???読んでも理解できないならあきらめろ。
0051NAME IS NULL
2015/10/18(日) 09:11:25.72ID:???0052NAME IS NULL
2015/10/18(日) 09:27:29.81ID:???そもそもここからね。
「ユーザー」と名前がつくテーブルにレコードを残しておきたくないという
気分的なものなのか、あるいは何か具体的な要件を想定しているのか。
たぶん本人もちゃんと考えていないんだろう。
0053NAME IS NULL
2015/10/18(日) 10:54:20.02ID:???0054NAME IS NULL
2015/10/18(日) 11:14:56.27ID:???>「退会したユーザーは存在させたくない」
これを勝手に個人情報の削除のことだと思い込んで的外れな設計しちゃうタイプだな。
0055NAME IS NULL
2015/10/18(日) 12:00:54.70ID:???http://peace.2ch.net/test/read.cgi/db/1445137179/
専用スレを立てるに値するぐらい話題が盛り上がっているので、立てました
0056NAME IS NULL
2015/10/18(日) 12:23:16.51ID:???てか、今だって他の話題なんかねーだろ。
0057NAME IS NULL
2015/10/18(日) 13:03:50.93ID:???じゃ、何が個人情報には当たらないんだ？
ユーザー情報（メールアドレス、電話番号、住所等）は個人情報だから、
ユーザーテーブルに残したくないってのは、至極まっとうな考え方だろ。
批判だけして「こうするorこう考えてる」って意見を出せないじゃん。
0058NAME IS NULL
2015/10/18(日) 13:37:39.84ID:???0059NAME IS NULL
2015/10/18(日) 14:03:11.89ID:???おまえ的外れすぎ。個人情報が何かって話をしているわけじゃない。
たとえば「退会したユーザーの電話番号は削除する」という具体的な要件があれば
「退会したユーザーは存在させたくない」
じゃなくて
「電話番号が削除された退会したユーザーが存在する」
でいいわけだ。それなら>>49みたいな疑問は生じないはず。
0060NAME IS NULL
2015/10/18(日) 14:13:18.31ID:???ユーザーの存在は消したくない
どこに悩む要素があるんだ
0061NAME IS NULL
2015/10/18(日) 15:15:39.11ID:???電話番号も含めて、個人情報は全部消さないと駄目だよ
0062NAME IS NULL
2015/10/18(日) 15:20:43.42ID:???0063NAME IS NULL
2015/10/18(日) 15:28:54.71ID:???「常識」が「まっとう」に変わったけどｗ
0064NAME IS NULL
2015/10/18(日) 16:04:26.26ID:???削除フラグの要否について語るスレ
http://peace.2ch.net/test/read.cgi/db/1445137179/
0065NAME IS NULL
2015/10/18(日) 18:28:20.14ID:???だから、その場合はユーザーテーブルにならないわけだろ？
”電話番号が削除された退会したユーザーが存在する”テーブルが必要なわけだ。
それに関しては何も思わないのか？
0066NAME IS NULL
2015/10/18(日) 18:43:44.95ID:???ここまでくると香ばしさを通り越して清々しいな
0067NAME IS NULL
2015/10/18(日) 19:41:16.43ID:???個人情報が削除されようが、退会されようが、ユーザーはユーザーなんだから
ユーザーテーブルに存在して何の疑問があるんだか
俺の思うユーザーの定義以外はあり得ないって思考から離れられない人なんだろうな
0068NAME IS NULL
2015/10/18(日) 19:53:28.53ID:???"ログアウトしたユーザーが存在するテーブル"
"チケットを発行したユーザーが存在するテーブル"
"チケットの担当者のユーザーが存在するテーブル"
"チケットを発行してかつ担当者になってるユーザーが存在するテーブル"
"今お風呂に入っているユーザーが存在するテーブル"
"明日早いから早めに寝てしまったユーザーが存在するテーブル"
..........
という事なのかな？
0069NAME IS NULL
2015/10/18(日) 20:57:20.73ID:???まぁ待て。頭ごなしに「お前はこうだ！」って決めつけたり、煽るのをまず直そうや。
あんたが人の意見を柔軟に受け入れられない奴を恥ずかしいと感じるなら、
自分もそれと同じような言動は控えよう。
んで、確実に俺以外の人間も「個人情報は削除するべきでは？」
って答えてるわけだが、それは見ないようにしてるのかい？
そこの疑問に対して「おかしいのでは？」って意見を頭ごなしに否定する以外の
論理的で冷静な意見が聞きたいなぁ。
0070NAME IS NULL
2015/10/18(日) 21:02:15.83ID:???>>53、>>58、>>61
は違う人だよ。
複数人が「個人情報は削除するべきでは？」って意見しているわけで、
一方的に頓珍漢な事を言っているわけではないというのは理解してくれ。
0071NAME IS NULL
2015/10/18(日) 21:08:16.85ID:???なんなのコイツ
0072NAME IS NULL
2015/10/18(日) 21:17:46.25ID:???0073NAME IS NULL
2015/10/18(日) 21:41:07.09ID:???0074NAME IS NULL
2015/10/18(日) 21:49:26.36ID:B8dX4Ff1>>53,58,61はどれも同じ文体で１行カキコも共通している
つまり「個人情報は削除するべきでは？」って意見してるのは
２名だけって事でいいのかな？
自分は「要件しだい」だと考えるよ
もしもオンラインショッピングのように利用者の住所や電話番号が記録されるシステムであれば、
個人情報の流出は社会問題に直結するから確実に削除すべき
しかしBTS(バグ追跡システム)であれば、ほとんどのケースで削除する必要はない
ああそうそう、自演だと思われないために言っておくが、自分は>>67とは違う人だよ
複数人が「個人情報は削除するべきという断定はおかしいのでは？」って意見しているわけで、
一方的に頓珍漢な事を言っているわけではないというのは理解してくれ
0075NAME IS NULL
2015/10/18(日) 22:01:28.22ID:???0076NAME IS NULL
2015/10/18(日) 22:11:10.19ID:???なんでこう話が捻じ曲がるかねぇ。
他の人は「削除すべきもの」を削除できるようにする方法を説明している。
あんたのシステムで「個人情報」が「削除すべきもの」なのであればそうすればいいだけ。
「個人情報は削除するべきでは？」って聞かれても「すれば？」としか言いようがない。
0077NAME IS NULL
2015/10/18(日) 22:50:26.98ID:???名前が消えるとカオスになって困る
どうすればいいんだ！！！って駄々こねてるだけ？
007867
2015/10/18(日) 22:59:27.57ID:???一応言っとくが、>>67は>>65に対するレスだけど
論理的で冷静な意見を言っといてやる
>それは見ないようにしてるのかい？
どこに、個人情報が削除するべきかどうかなんてエクスキューズがあるのかね
>そこの疑問に対して「おかしいのでは？」って意見を頭ごなしに否定する
意味が分からん
おかしいって意見ってのは、個人情報を削除するのがおかしいって？それとも個人情報を削除しないのがおかしいって？
どっちにしても、それを否定も肯定もしてないけど
0079NAME IS NULL
2015/10/19(月) 00:09:02.88ID:???足し算を教えてやったら、「バナナだったらどうなんだ？」と言われた。
「バナナは関係ない」と言ったら「バナナを否定するのか」と言われた。
そんな気分。
0080NAME IS NULL
2015/10/19(月) 00:23:58.33ID:???個人情報は削除する。
ユーザは削除しない。
削除フラグは使わない。
という要件を満たす対応案はもう出てるよな。
何が気に入らないんだ？
0081NAME IS NULL
2015/10/19(月) 08:16:54.14ID:???それを「ダダ」って捉えるから荒れるんじゃないか？
実際にそのエクスキューズは出てくるだろ。
・個人情報は削除したい
・ただ、その個人情報は他のテーブルから参照されている
削除すると参照元の名前欄などが空欄になる
この問題について「なぜ？」という質問に対して
「タダこねてるだけ」ってのはおかしいと思うんだよなぁ。
てか、お前らの投稿見てて無理に煽ったり貶したり馬鹿にする意味が分からん。
全く生産性がないだろうし、自分も嫌な気になるだろ。
0082NAME IS NULL
2015/10/19(月) 08:19:37.72ID:???馬鹿な俺に教えてくれ。
・個人情報は削除する
→「個人情報が入ってるテーブルの対象レコードを削除すればいいよね」
・ユーザは削除しない
→「ファ！？個人情報を削除するんじゃないの？」
・削除フラグは使わない
→「それは分かるし対案も出てる。でも、上記2つは相対しないのでは？」
この疑問を持つこと自体駄目か？ダダか？
0083NAME IS NULL
2015/10/19(月) 09:00:21.94ID:???個人情報は個人を特定できるものだから、電話番号とか住所は消して名前(ユーザー)だけ残す
名前だけでは個人を特定できないので残しておいても問題は無さそうだけど
0084NAME IS NULL
2015/10/19(月) 09:15:04.29ID:???消すってどうやって？UPDATEでNULLにするのか？
あるいは、そもそもテーブルを分けてるのか？
0085NAME IS NULL
2015/10/19(月) 09:19:26.26ID:???その辺のネトゲとかであるメアドあればアカウント復帰できるやつなら
別テーブルに移動してるんだろうね
復帰したら元のテーブルに戻す感じで
一概にこうしろという答えはないと思うよ
とにかく個人を特定できないようにすればいいわけだし
0086NAME IS NULL
2015/10/19(月) 09:30:29.53ID:???ネトゲってそういうの多いね。モバゲーとか即復活できる。
あれって、削除フラグじゃないのか？って思うんだけど、
履歴テーブルに移してるのかなあ
0087NAME IS NULL
2015/10/19(月) 09:32:40.67ID:???企業・顧客によって個人情報の扱いなんてコロッと変わるし、
DBAのスキル次第でも変わりそうだけどね
0088NAME IS NULL
2015/10/19(月) 12:33:51.67ID:???答が出てる事に意味不明な問いかけをするから荒れるんじゃないだろうか？
という自分の誤りの可能性について考えてみた事はあるかね？
0089NAME IS NULL
2015/10/19(月) 12:37:43.23ID:???答えが出てねーじゃん。
新たに「こういう時はどうするの？」
って聞いても受け入れないんだから。
0090NAME IS NULL
2015/10/19(月) 12:39:09.37ID:???むしろ馬鹿な俺に教えてくれ。
> この問題について「なぜ？」という質問
その質問を詳しく教えて欲しい。
0091NAME IS NULL
2015/10/19(月) 12:43:28.22ID:???新たでないという可能性について考えた事はないのかね？
0092NAME IS NULL
2015/10/19(月) 12:59:27.25ID:???0093NAME IS NULL
2015/10/19(月) 13:04:35.25ID:???名前も個人情報だから、消さないと駄目
0094NAME IS NULL
2015/10/19(月) 13:06:00.11ID:???質問したいなら、「こういうとき」を、DBのスキーマと要求仕様を添えて質問しろ。
0095NAME IS NULL
2015/10/19(月) 13:09:22.41ID:???退会した後、同じメールアドレスで新規に登録してみると分かる。
これができないと言うことは、
おそらく移動はしていないんだろうな。
0096NAME IS NULL
2015/10/19(月) 13:10:55.16ID:???想像力なさすぎというか、設計経験なさすぎというか。
0097NAME IS NULL
2015/10/19(月) 13:11:50.88ID:???名前だけでは個人特定できないでしょ
0098NAME IS NULL
2015/10/19(月) 13:13:45.96ID:???少なくとも>>49、>>57、>>65は俺がレスした。
>>91-92
その「自分の中では解決している。知らない人がいるのは知らん」
って価値観はなんなの？みんなで掲示板使ってんじゃん。
>>94
>>49だと足りないならどこまで説明すれば納得するんだ？
1から10までは説明できないと言ったら、俺が悪くなるのか？
0099NAME IS NULL
2015/10/19(月) 13:21:37.87ID:???個人情報の保護に関する法律の定義では、生存する個人に関する情報であって、
当該情報に含まれる氏名、生年月日その他の記述等により「特定の個人を識別
することができるもの」（他の情報と容易に照合することができ、それにより
特定の個人を識別することができることとなるもの=例えば学籍番号など=を含
む）をいう。つまり、上記に該当しない情報であっても、「勤務場所」や「生
年月日」といった「複数の情報の組み合わせ」により、「その個人を特定し得
る情報」も個人情報である。
0100NAME IS NULL
2015/10/19(月) 13:25:07.92ID:???書いてあるとおり、
ネトゲに登録し、退会し、同じアドレスで新規登録してみ
想像力でも設計系経験でもなく、単なる事実なんだけど。
こもってないでたまには外に出てみたら？
0101NAME IS NULL
2015/10/19(月) 13:35:28.76ID:???> おそらく移動はしていないんだろうな。
これが
> 想像力なさすぎというか、設計経験なさすぎというか。
って言ってるんだよ。
0102NAME IS NULL
2015/10/19(月) 13:39:22.99ID:???> 1から10までは説明できないと言ったら、俺が悪くなるのか？
お前も、設計経験なさすぎというか。
他人が判断できるだけの最小限の情報を示すこともできないんだろ？
他人が判断できないのはお前のせい。なのでお前が悪い。
0103NAME IS NULL
2015/10/19(月) 13:41:12.87ID:???あと、要求仕様と実装詳細の区別はちゃんと付いてるのか？
0104NAME IS NULL
2015/10/19(月) 13:42:24.76ID:???削除フラグの要否について語るスレ
http://peace.2ch.net/test/read.cgi/db/1445137179/
0105NAME IS NULL
2015/10/19(月) 13:43:00.80ID:???お前、さっきから誰にでも噛み付いてるなw
何か嫌なことあった？たまには散歩でもしてみたら？
0106NAME IS NULL
2015/10/19(月) 13:46:20.84ID:???誰にでもって、アホ二人にだよ。
一人なのかもしれんが。
0107NAME IS NULL
2015/10/19(月) 13:51:13.59ID:???噛み付いてるのは認めるのなw
0108NAME IS NULL
2015/10/19(月) 13:54:33.87ID:???前スレから延々この話題が続いてるのは、アホどものせいだろ。
0109NAME IS NULL
2015/10/19(月) 14:00:27.92ID:???0110NAME IS NULL
2015/10/19(月) 14:04:00.03ID:???そういうメタ議論はやめようぜ。
0111NAME IS NULL
2015/10/19(月) 14:06:45.62ID:???> その「自分の中では解決している。知らない人がいるのは知らん」
> って価値観はなんなの？みんなで掲示板使ってんじゃん。
最近こういう奴多いね。
俺はわからない、俺がわかるまでお前ら説明しろ、そうする責任がお前らにはある、って奴。
0112NAME IS NULL
2015/10/19(月) 14:11:53.99ID:???0113NAME IS NULL
2015/10/19(月) 14:23:33.48ID:???◯説明する必要がない
0114NAME IS NULL
2015/10/19(月) 14:32:29.08ID:???こういう奴も多くてうんざりする。
お前らが説明しないのは、説明できないからって奴。
0115NAME IS NULL
2015/10/19(月) 14:37:15.35ID:???> 消すってどうやって？UPDATEでNULLにするのか？
> あるいは、そもそもテーブルを分けてるのか？
おいおい、いまさら何言ってるんだよ・・・
0116NAME IS NULL
2015/10/19(月) 14:38:48.88ID:???要件次第
0117NAME IS NULL
2015/10/19(月) 14:42:29.34ID:???最近こういう奴も多いよね。
一部だけ切り取ってハッキリと何が駄目なの言わない奴。
とにかく全部否定すればお前バカ・俺すげー出来るっって思ってるの
0118NAME IS NULL
2015/10/19(月) 14:44:37.34ID:???それなら無視で良いんじゃないか？
わざわ馬鹿にする意味が分からん。
0119NAME IS NULL
2015/10/19(月) 14:48:31.76ID:???0120NAME IS NULL
2015/10/19(月) 14:55:49.90ID:???>>49の疑問に対する答えが出てないってことか。
ユーザは削除するが名前は削除しないって場合、それはユーザの削除ではないということは分かる？
ユーザではない何かを削除するという行為になるわけだから、
その削除対象となる情報をユーザから切り離せばいいじゃん？
というのが前スレでも、このスレでも繰り返し出てる答えだけど、
それでも
> その「自分の中では解決している。知らない人がいるのは知らん」
> って価値観はなんなの？みんなで掲示板使ってんじゃん。
という考えが出るということは、その回答では不満だということだよね。
質問に不備があるんじゃないか？
0121NAME IS NULL
2015/10/19(月) 15:01:15.84ID:???さすがに今の流れでそれは逆効果だよ。ほんとにいまさらだもん。
過去ログ読めよと。
0122NAME IS NULL
2015/10/19(月) 15:03:37.19ID:???0123120
2015/10/19(月) 15:03:59.72ID:???ユーザ名はユーザ情報に含むべきという前提で書いたので、そのつもりで読んでもらえればと。
0124NAME IS NULL
2015/10/19(月) 15:13:38.63ID:???>ユーザは削除するが名前は削除しないって場合、それはユーザの削除ではないということは分かる？
とするとね、>>57こっちの疑問に行き着くのよ。
ちゃんとこのスレ見てたら分かると思ったんだが。
ま、それは良いや。また言い争いになりそうなんで折れる。
>その削除対象となる情報をユーザから切り離せばいいじゃん？
つまり、
・ユーザー情報（ユーザ名、パスワード）と個人情報（名前、住所、電話番号など）に分ける
のが正しい設計って解釈でいいの？これも前スレで答え見つからないわけだが。
もし答えてるならレス番教えてくれ。もう一度見返すから。
0125124
2015/10/19(月) 15:15:08.99ID:???1対1でも場合によってはテーブルを分ける設計があるって理解してるんで。
0126NAME IS NULL
2015/10/19(月) 15:20:28.66ID:???> とするとね、>>57こっちの疑問に行き着くのよ。
>>57
> じゃ、何が個人情報には当たらないんだ？
この流れ、お前に中では筋が通ってるのかも知れないが、第三者にはさっぱりわからん流れなんだが。
0127120
2015/10/19(月) 15:20:58.83ID:???ユーザ削除時に一部(今回なら名前だね)を残し、他は削除するという場合にどういう設計をするのかという話と、
何を個人情報とするかという話は関係ない。
一見関係ありそうに思えるかもしれないけれど、設計手法には影響を与えないことは分かるかな。
どっちのテーブルに置くかというそれだけの話。
> もし答えてるならレス番教えてくれ。もう一度見返すから。
このスレだと>>41が関連レスしてくれてるけど、前スレでレスしたやつはこれ。
DB設計を語るスレ 8 [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/db/1424250550/887
887 名前：NAME IS NULL[sage] 投稿日：2015/10/08(木) 12:37:37.91 ID:???
なんだよユーザ名残さないといけないのかよ。
そんな隠し要件あるなら、
ユーザテーブル(ユーザ名を含み、ユーザ削除時に削除しない)
ユーザ属性テーブル(ユーザ名以外の情報。認証情報やらなにやら。ユーザ削除時に削除する)
ってしなきゃいけないな。
0128NAME IS NULL
2015/10/19(月) 15:22:59.05ID:???> ユーザー情報（ユーザ名、パスワード）と個人情報（名前、住所、電話番号など）に分ける
のが正しい設計って解釈でいいの？
だからさー、それこそ「要件次第」なんだって。
何が正しい設計なんかない。
いつまで同じようなループさせれば気が済むんだ？
0129NAME IS NULL
2015/10/19(月) 15:25:31.29ID:???いつまでたっても収束しない
0130124
2015/10/19(月) 15:32:22.17ID:???安心しろ。同じこと何度も書くのは糞面倒だから他人だ。
>>127
「一見関係ありそうに思える」って認めちゃってるけど、
だったら疑問として出てくる分には問題ないんじゃないか？
これも、俺個人だけが「個人情報どうなるの？」って問題視してねーわな。
まぁ良い。これも折れる。お前が正しい。
で、前スレの887のレス番があんたの「過去の答え」なんだな？
じゃ、>>124の後半で意見したのが「正しい設計」で良いんだな？
まず、この解釈の確認をさせてくれ。
この後に、この設計について問題点を指摘する。
0131NAME IS NULL
2015/10/19(月) 15:32:58.94ID:???> 一部だけ切り取ってハッキリと何が駄目なの言わない奴。
なんで、何が駄目なのか具体的に指摘しなきゃならないんだよ。
誰もが無料で添削してくれるなんて思うなよ。
0132NAME IS NULL
2015/10/19(月) 15:34:02.13ID:???> この後に、この設計について問題点を指摘する。
しなくていいから。
お前のショボイ設計論なんぞ聞きたくない。
0133NAME IS NULL
2015/10/19(月) 15:36:15.22ID:???お前さっきから噛みつきまくってるけどどうした？www
0134NAME IS NULL
2015/10/19(月) 15:36:35.25ID:???0135NAME IS NULL
2015/10/19(月) 15:37:27.54ID:???添削？
「文章・答案などをけずったり書き加えたりして直し、いっそう良くすること。」
ってググったら出てくるんだけど、お前らのレスのどこが添削？
頭ごなしに批判してるだけじゃん
0136NAME IS NULL
2015/10/19(月) 15:38:20.39ID:???0137NAME IS NULL
2015/10/19(月) 15:39:21.97ID:???だから、添削なんかしないよって言ってんじゃん
それすら理解できないのか？
0138NAME IS NULL
2015/10/19(月) 15:39:36.25ID:???それ両方に言えるよね。質問者が納得してないのに「俺の言葉が正しい。受け入れろ」って言ってるだけじゃん
0139NAME IS NULL
2015/10/19(月) 15:39:58.09ID:???ああ、そうだね。添削せずに煽ってるだけだったw
0140120
2015/10/19(月) 15:40:00.98ID:???別に指摘して欲しいわけじゃなくて、それを書いた時点では、
BTSの人に対して、こうすれば問題ないんじゃないのって提示しただけだよ。
あの人と違う人だっていうなら、問題視する点も異なってくるはずだし、それが要件次第ってことだよ。
0141124
2015/10/19(月) 15:41:36.19ID:???いや、指摘して欲しいと思ってるなんて解釈してないよ。
ただ、俺があんたの答えに疑問に思ってるだけだから。
その疑問すら受け入れてもらえないの？
0142NAME IS NULL
2015/10/19(月) 15:43:07.80ID:???要するに、お前は
> 俺はわからない、俺がわかるまでお前ら説明しろ、そうする責任がお前らにはある、って奴。
って暴れてるだけだってことに気付よ。
0144124
2015/10/19(月) 15:44:22.10ID:???えっと、第三者の目で「おかしくない？」って横槍入れちゃうのはダメなの？
もちろん、要件次第って言い出したら何でもそうなっちゃうけど・・・
0145NAME IS NULL
2015/10/19(月) 15:45:31.86ID:???無視するって選択肢が君には残されてると思うんだけど
0146NAME IS NULL
2015/10/19(月) 15:46:45.55ID:???>>48
> 「退会したユーザーは存在させたくない」
> けど
> 「名前は参照させたい」
>
> って場合はどうなるの？
実装方法として、どういう選択肢があるのかは、前スレにあるから読み返せ。
> やっぱり履歴テーブルに移行させて、そこから参照するの？
そんな唯一解はないし、ベストプラクティスのようなものもない。
0147120
2015/10/19(月) 15:48:00.52ID:???全然問題ないよ。同一要件でってこと？
あの段階だと、BTSにおいてユーザを削除するが、名前は残したいという要件だっけ。
個人情報だから削除しなきゃって話もまだだったように思うし、他システムとの連携の話もまだだったかな。
0148NAME IS NULL
2015/10/19(月) 15:48:47.37ID:???まさに要件次第で、データベース設計の話とは関係ない。
0149NAME IS NULL
2015/10/19(月) 15:49:55.10ID:???> 個人情報だから削除しなきゃって話もまだだったように思うし、他システムとの連携の話もまだだったかな。
それは、データベース設計と何か関係ある話？
0150120
2015/10/19(月) 15:50:41.05ID:???運用段階の話だね。運用段階で検討すべきことを設計フェーズに持ち込もうとしていたので、それは違うよって話をしたように思う。
0151124
2015/10/19(月) 15:52:26.53ID:???まずBTSの話をしてないので同一視しないでくれw
>>49が初出のレス（横槍）なわけで、
>>146のいう「ベストプラクティスなんて存在しない」は十分理解出来てる。
ただ、120自身には答えとして存在する。
それは否定しないし、自分の型を持っているわけだから認める。
だったら他人がその答えに対して疑問を投げかけても良いだろ？
俺は>>124の後半に書いたように
「削除するテーブルとしないテーブルを分ける」って考えは悪く無いと思うよ。
でも、それに対して参照する場合はどうするの？ってところに
「その場合はこうするよ」って意見を貰えてないから、ここまで長引くと思うんだよ。
もちろん、120がそこまで言ったつもりで、俺が理解できてないのなら、素直に自分の非を認める。
0152NAME IS NULL
2015/10/19(月) 15:52:38.35ID:???> もちろん、要件次第って言い出したら何でもそうなっちゃうけど・・・
そんなことはない。
現に過去スレでデータベース設計の話はきちんとされている。
概念設計も、物理設計も。
今回、要件次第、要件次第と言われるのは、「こういう要件の時に」という限定がなされないから。
0153NAME IS NULL
2015/10/19(月) 15:52:59.71ID:???要件次第で設計が変わりうるので、一概に設計と関係ないとはいえないかと
0154NAME IS NULL
2015/10/19(月) 15:56:54.62ID:???あのさ、DB設計って設計すればいいやってもんじゃないと思うんだよ。
設計したその先を考えるべきだと思うんだよ（少なくとも自分はそう思ってる）
だからこそ削除フラグや論理削除って考え方が生まれたわけだろ？
0155NAME IS NULL
2015/10/19(月) 15:58:08.04ID:???要件次第で設計が変わるのだから、要件を明確にせずに設計の話はできないということなんだが。
0157120
2015/10/19(月) 16:00:54.95ID:???ないものを参照することはできないというだけでは不満かな。
ないものを参照させろということなら、それは削除しちゃいけないものとなる。
>>49の「名前は参照させたい」という要件を満たすなら、
>>124の
> ・ユーザー情報（ユーザ名、パスワード）と個人情報（名前、住所、電話番号など）に分ける
という分割ではなく、ユーザ情報に「名前」を入れる。
というのが、>>127でも引用した過去レスの内容。
0158124
2015/10/19(月) 16:04:30.49ID:???いや、不満じゃないよ。それも1つの答え出し、俺もどっちかというとそうしてるかな。（物理削除して名前を空欄にしてたり）
過去レスを引用した部分は分かった。
ただ、テーブルが2つになる事で開発の手間が増えるとか、
SQL発行回数が多くなってパフォーマンス的にどうなんだ？
って指摘は、「DB設計には関係ないから指摘するな」って解釈で良いの？
0159NAME IS NULL
2015/10/19(月) 16:05:51.45ID:???>>49だと足りないということでしょう。
> 「退会したユーザーは存在させたくない」
> けど
> 「名前は参照させたい」
というのが要件だとしたら、
> やっぱり履歴テーブルに移行させて、そこから参照するの？
が妥当かどうかは判断できない。
別に削除フラグで実装してもいいし。
0160NAME IS NULL
2015/10/19(月) 16:06:48.22ID:???> ただ、テーブルが2つになる事で開発の手間が増えるとか、
> SQL発行回数が多くなってパフォーマンス的にどうなんだ？
> って指摘は、「DB設計には関係ないから指摘するな」って解釈で良いの？
え、今更そんなレベルなの？
本読め。
0161124
2015/10/19(月) 16:08:51.01ID:???その部分だけじゃなくて後半の「」も見て欲しかったけど、
まぁ、「それなら削除フラグで実装してもいい」は実りある答えだと思うよ。
削除フラグが頭ごなしに否定されている感覚を受けたからね。
でも、「要件次第で使ってもいいし使う場合もある」んなら、問題ないんじゃないかな。
0163NAME IS NULL
2015/10/19(月) 16:15:01.07ID:???じゃあ、何の話がしたいんだよ？
今年削除フラグがバズったおかげで、かなりの議論がブログ等でなされてるし、
俺が>>22で上げた書籍でも詳しく解説されてる。
それ以外の何かを議論したいなら、ちゃんとした疑問を提示してくれ。
0164124
2015/10/19(月) 16:17:47.93ID:???もういいよ。>>120とお互い名前欄入れてレスし合ってたから読み返してくれ。
少なくとも>>49のレスを見て、>>159は自分なりの意見をした。
これが正しいか否かはともかく、159は削除フラグを否定してない。
おそらく早い段階でこの回答が来てるなら、
「こういう要件なら削除フラグでも良いのか」で終わってた話だよ。
無駄に煽り合いする必要もなく、こっちも2レスで済んでた。
0165NAME IS NULL
2015/10/19(月) 16:24:52.04ID:???俺としては、>>49だけではどうすべきかというのは言えないというのがわかってくれればそれでいいよ。
（そして、他の多数の人もそのようなことを言ってるんだと思う）
君と>>120がどういうやりとりをしてたのかを読めというのは、正直言って勘弁して欲しい。
また、>>163で言った「それ以外の議論」がしたいのなら、別途どうぞ。
0166124
2015/10/19(月) 16:27:29.79ID:???あんたさ、自分が>>22の書籍上げたって書いてるけど、
その下のレスまで読んでないだろ？
俺と似たような疑問呈したレスが有るぞ（さすがに俺の自演じゃないからなw
結局、スレ見返さず他人の意見を受け入れないのは自分じゃん。
0167NAME IS NULL
2015/10/19(月) 16:29:25.98ID:???> あんたさ、自分が>>22の書籍上げたって書いてるけど、
> その下のレスまで読んでないだろ？
レス番を明示してくれ。
> 結局、スレ見返さず他人の意見を受け入れないのは自分じゃん。
はて、他人の意見を受け入れなかった記憶はないんだが・・・。
0168NAME IS NULL
2015/10/19(月) 16:32:16.81ID:???読んだけど、まあ>>22の本本でよとしか言えない。
0169124
2015/10/19(月) 16:32:33.51ID:???自分は見返すのを拒否して、人にはレス番指示かw
>>24-33の流れ見ればいいんじゃねーの。
履歴テーブル扱うことの難しさについて話し合ってるわ。
んで、俺も履歴テーブルにするのは難しいと思ってるよ。
だから、120に>>158でテーブルが2つになる事に対する疑問があるわけだし。
ま、次どんなレス来るかもおおよそ検討がつくからこの辺で名無しに戻ります。
0170NAME IS NULL
2015/10/19(月) 16:37:54.97ID:???> >>24-33の流れ見ればいいんじゃねーの。
> 履歴テーブル扱うことの難しさについて話し合ってるわ。
それは読んだよ。
> テーブルが2つになる事に対する疑問
というのが、
> ただ、テーブルが2つになる事で開発の手間が増えるとか、
> SQL発行回数が多くなってパフォーマンス的にどうなんだ？
ということだったら、>>22の書籍に解説があるし、「削除フラグ」に関するブログでも多数言及されてる。
それ以外の何か？
0171NAME IS NULL
2015/10/19(月) 16:45:47.82ID:???0172NAME IS NULL
2015/10/19(月) 16:47:03.69ID:???> SQL発行回数が多くなって
ってなるんだよ？
そこだけ説明して離脱してくれよ
0173NAME IS NULL
2015/10/19(月) 16:47:32.89ID:???そのブログに辿り着けるググり方教えてくれ。
「削除フラグ」「削除フラグ DB設計」では無理だった。
そのブログ読んでから疑問があるなら意見する
0174NAME IS NULL
2015/10/19(月) 16:48:04.00ID:???deleteしてinsertするからでしょ
0175NAME IS NULL
2015/10/19(月) 16:49:55.72ID:???元々1つのが2つにする時点で多くなると思うが
0176NAME IS NULL
2015/10/19(月) 16:51:54.93ID:???削除フラグ
論理削除
物理削除
デメリット
アンチパターン
などをいくつか組み合わせてググってくれ。
あと、>>22は特にお薦めだから、金あるなら読んでみてくれ。
0177NAME IS NULL
2015/10/19(月) 16:52:35.34ID:???0178NAME IS NULL
2015/10/19(月) 16:52:58.51ID:???"論理削除 Casual Talks"
0179NAME IS NULL
2015/10/19(月) 17:59:42.49ID:???新しい話が一つも無い
結局、今までの話を理解してなかった人に、懇切丁寧な人が付き合って上げてただけ
前もあったな、理解力不足な人が暴れてたってのが
３年ROMってろ文化は過去のものなのかね
0180NAME IS NULL
2015/10/19(月) 18:02:30.85ID:???0181NAME IS NULL
2015/10/19(月) 18:35:56.16ID:???0182NAME IS NULL
2015/10/19(月) 18:37:59.75ID:???0183NAME IS NULL
2015/10/19(月) 18:39:55.11ID:???仲間内で馴れ合いたいだけなら2ちゃんの意味ないんじゃない？
このスレが他人の質問を一切受け付け無いってのなら別だけど
過去スレ見る限りそうじゃないんだがなぁ
0184NAME IS NULL
2015/10/19(月) 18:47:36.61ID:???> いや、不満じゃないよ。それも1つの答え出し、俺もどっちかというとそうしてるかな。（物理削除して名前を空欄にしてたり）
これには閉口するよね。
あ、根底から覆すんだなって。
0185NAME IS NULL
2015/10/19(月) 18:50:25.51ID:???0186NAME IS NULL
2015/10/19(月) 19:06:05.22ID:???>>184こういうのじゃね？
明らかに一部だけ抜けだして、かつ自分の意見も書かずに否定だけしてるの。
0187NAME IS NULL
2015/10/19(月) 19:07:42.70ID:???もしかして「名前を空欄」ってDBのカラムを空欄って思っちゃいました？
さすがにそれはないですよw
というかやりとり見てたらそうは解釈出来ないと思うんですが、
本当に３年ROMられてました？
0188NAME IS NULL
2015/10/19(月) 19:11:48.53ID:???名前を残す要件前提で話してたのにってことだよ。
0189NAME IS NULL
2015/10/19(月) 19:14:03.14ID:???それ回答じゃないよ
0190NAME IS NULL
2015/10/19(月) 19:42:03.44ID:???0191NAME IS NULL
2015/10/19(月) 20:29:36.35ID:???やはり名前も消さないと駄目だろう
0192NAME IS NULL
2015/10/19(月) 20:37:23.09ID:???同姓同名もいるから個人情報にあたらないという教育をしてる会社はないと信じたいけれど。
0193NAME IS NULL
2015/10/19(月) 21:54:29.76ID:???個人情報の取り扱いに神経質となるあまり、
例として挙げられたユーザーテーブルに
含まれる個人情報にばかり執着し論点を見失ってしまう事
0194NAME IS NULL
2015/10/20(火) 07:44:42.53ID:???ってことだったのかね。
せっかく説明してやってもそれを頑なに理解しようとしない態度もそう考えると腑に落ちる。
0195NAME IS NULL
2015/10/20(火) 12:44:04.89ID:???逆じゃね？せっかくの説明に「どうして？」って訪ねても
「いいからこうしろよ。理解できないなら馬鹿」って言ってるだけじゃん。
現にお前の上3つが個人情報について語ってるけど、
言うなら三者三様の考え方があるわけで、
それを無視して「理解できない馬鹿」ってレッテル貼りしてるだけにしか見えないが
0196NAME IS NULL
2015/10/20(火) 12:59:17.18ID:???0197NAME IS NULL
2015/10/20(火) 13:05:20.25ID:???このスレでまだ暴れるつもり？
0198NAME IS NULL
2015/10/20(火) 13:08:03.91ID:???> 現にお前の上3つが個人情報について語ってるけど、
馬鹿すぎて無視されてるだけだろ
0199NAME IS NULL
2015/10/20(火) 14:21:28.32ID:???被害妄想まで始まったぞ
0200NAME IS NULL
2015/10/20(火) 14:28:34.86ID:???>>124の人が最終的に理解した内容って、つまりは>>41にかかれてることで、
そしてそれは>>49の直後、>>50のレスで終了してたんじゃないの？
0201NAME IS NULL
2015/10/20(火) 14:34:03.22ID:???だよなぁ。
まず前スレからこのスレの先頭あたりまで読んでから議論に参加してくれって感じ。
0202NAME IS NULL
2015/10/20(火) 14:35:29.99ID:???> 現にお前の上3つが個人情報について語ってるけど、
個人情報についてどうすべきかというのは、データベース設計とは関係ありませんね。
0203NAME IS NULL
2015/10/20(火) 14:47:36.92ID:???0204NAME IS NULL
2015/10/20(火) 20:43:51.50ID:???なぜここで語りたいのか心底理解出来ん
0205NAME IS NULL
2015/10/20(火) 21:14:50.55ID:???・そしてそれを自分の頭のせいにしたくなくて必死に「自分の問題は特殊だ」と訴えている
0206NAME IS NULL
2015/10/20(火) 21:36:31.23ID:???0207NAME IS NULL
2015/10/20(火) 22:51:59.09ID:???0208NAME IS NULL
2015/10/20(火) 23:08:59.22ID:???んで、専用スレ立てるほうがおかしい。
何をそこでやれというのか。
0209NAME IS NULL
2015/10/22(木) 22:59:14.39ID:72sKbAfY総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
0210NAME IS NULL
2015/10/31(土) 03:06:44.29ID:???0211NAME IS NULL
2015/11/12(木) 18:00:26.36ID:KLB1Ae4fhttps://teratail.com/questions/18942
というのが先々週ぐらいにバズったのですが、皆さんはどう思いますか？
1日に数十〜100万レコード増える場合は、
ここで回答されているポイントを踏まえて設計し直せば良いんですかね？
例えば、アクセスログの集計とかポイントのやり取りに関する
DB設計も似たような解釈で良いんですかね？
いまいち回答がわかりづらいので、DB板の皆さんに聞いてみたいと思います。
0212NAME IS NULL
2015/11/12(木) 20:26:42.75ID:???0213NAME IS NULL
2015/11/14(土) 11:41:40.92ID:???「過去データ保持の考え方」とか「INSERTは遅くてもいい」で興味持っただけの人だと思う
0214NAME IS NULL
2015/11/15(日) 22:46:53.81ID:???everythingのようにストレージファイルを管理したいんだけど
Updateとかしないで一旦全部削除してから
ファイル構造をぶっ込んだほうがいいですか？
なぜならファイル名やパスが変更されるので同一ファイルかどうかの判別が難しい。
この場合、ジャンルテーブルなどとの関連付けをやり直しになるんだろうけど。
0215NAME IS NULL
2015/11/16(月) 10:23:10.55ID:???DB化している。
んで、時たまフォルダの移動とか削除とかもあったりするので、一旦全部削除後再作成
というのをしてるよ
0216NAME IS NULL
2015/11/16(月) 13:32:27.45ID:???http://jobinjapan.jp/cate/
全掲載求人109,160件の平均最低月給195,800円
データベースエンジニアの求人 の平均最低月給229,900円
http://jobinjapan.jp/job-listing/keyword-database-engineers.html
やったね！！
0217NAME IS NULL
2015/11/16(月) 16:56:09.02ID:???やっぱり全部削除でいいんですね！
ありがとうございます！
0218NAME IS NULL
2015/11/16(月) 17:28:09.87ID:???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を持たせようかと思っています
どちらがいいのか、またはまったく別のいい方法があれば教えていただきたいです。
よろしくお願いします。
0219NAME IS NULL
2015/11/16(月) 17:32:14.41ID:???user_tags/id,user_id,tag_id
0220NAME IS NULL
2015/11/16(月) 17:44:52.19ID:???0221NAME IS NULL
2015/11/16(月) 17:47:03.84ID:???> notesテーブル / id, notebook_id, user_id, title, body
user_idは不要かな
0222NAME IS NULL
2015/12/01(火) 06:58:52.05ID:???ユーザとタグの n対n 関係の中間テーブルなら、id カラムは不要
user_id, tag_id を PK にすればいい
場合によっては逆順のユニークインデックスもつけてね
0223名無しさん＠そうだ選挙に行こう
2015/12/14(月) 15:12:26.50ID:LwQRJZzM12あるカラムの中身1つ1つと対になるようなサブフィールドのようなものが欲しいのですが分からなくて迷っています。
例えば
主キーカラムが id で 1 の行に、カラムがc1, c2,,, c12まであるとしたら（id 2 にも同様にc1〜c12まであります。）
c1_status, c2_status,,,といったようにちょっとしたそれぞれc1, c2,,,の中身に対する状態を記録するカラムが欲しいのです。
この場合テーブルを分けたほうが設計として良いでしょうか？
それとも同じテーブルに12個カラムを追加したほうがいいのでしょうか。
普段呼び出すのはc1〜c12で、_statusのカラムはそんなに頻繁には使いません。
何かアドバイスをいただけないでしょうか、お願いします。
0224名無しさん＠そうだ選挙に行こう
2015/12/14(月) 16:26:16.56ID:???そんな抽象的な要件では、何が良い設計なのかなど判断できない。
0225名無しさん＠そうだ選挙に行こう
2015/12/14(月) 16:31:17.05ID:???--
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ではなく、名前を使う）
--
などが考えられるが、どれがいいとは言えない。
0226名無しさん＠そうだ選挙に行こう
2015/12/14(月) 16:38:47.59ID:???table_a(id, c1, c2. ..., c12)
という構造すら良い設計なのかどうかあやしい。
table_b(id, data)
table_b(id, some_data, data)
のように、1レコード1データの方が良い場合もある。
0227名無しさん＠そうだ選挙に行こう
2015/12/14(月) 19:07:29.19ID:???>>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つしか存在し得ませんが。
0228名無しさん＠そうだ選挙に行こう
2015/12/14(月) 19:18:27.95ID:LwQRJZzMhttp://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が入っています。
これはどういうことなんですか？
0229NAME IS NULL
2015/12/15(火) 00:27:11.72ID:???> table_a.id=1 で table_b.index=1 という組み合わせは1つしか存在し得ませんが。
なので、それをキーにするよ。複合プライマリキーっていう。
0230NAME IS NULL
2015/12/15(火) 00:31:13.88ID:???その直前にテーブルレイアウトあるけど、
messageじゃなくてtargetの誤記だろうね。
でも、通常message_idとかにする。targetなんて突拍子もないカラム名つけるのは誰もが困るイマイチ設計
0231NAME IS NULL
2015/12/15(火) 01:20:08.78ID:???複合プライマリキー勉強になります。
>>230
そうかとも思いましたが、message_targetのtargetカラムにPRIMARY KEYを設定するのは不可能じゃないですか？
実際下の例でmessageがtargetの誤記だとすると 21 が2つありますし。
targetの説明に、メッセージ識別子 (message.id) とあるので、
もしかしてmessageテーブルのidを引っ張ってきてmessage_targetテーブルに入れ込んでうまいことやってくれる方法でもあるのかなと思ったのですが
まぁそれでもmessageというカラム名っぽく書いてあるのはおかしいですよね…。
とりあえず私の設計は複合プライマリキーを調べつつやっていきますありがとうございます。
0232NAME IS NULL
2015/12/15(火) 03:27:02.41ID:???http://prntscr.com/9e4z4y
この赤枠のところには罫線がないよ
とにかくもっと基礎知識をつけるべき
0233NAME IS NULL
2015/12/15(火) 13:29:12.75ID:???まだ見てるかどうかわからんけど。
そういう素性もしれないレベルも良くわからないブログを読んで時間を消耗するより、
入門書1,2冊買って勉強した方がいいぞ。
0234NAME IS NULL
2015/12/15(火) 15:18:10.21ID:???早速注文しようと思います。
mysqlしか使ったことありませんが、データベースについて書かれてるもので概論を学ぶならなんでもいいですよね？
わりかし新しめで評価高そうなこの2つにします。どっちもミックって人ですね。
おうちで学べるデータベースのきほん
http://www.amazon.co.jp/o/ASIN/479813516X/
SQL実践入門──高速でわかりやすいクエリの書き方
http://www.amazon.co.jp/o/ASIN/4774173010/
0235NAME IS NULL
2015/12/15(火) 15:21:28.26ID:???英語で検索すると有名どころの開発者の記事がヒットすること多いよ
StackOverFlow でも開発者本人が回答してるのとか結構ある
日本のナレッジコミュニティの質はやばすぎるｗ
0236NAME IS NULL
2015/12/15(火) 16:06:34.66ID:???毛嫌いする人がいたりするけど、ミック氏はお勧め。
あと日本人では奥野 幹也氏の『データベース実戦入門』（ちょっと高度）。
鉄板はJoe Celko。
『プログラマのためのSQL 第4版』が良いが、初心者には厳しいかも。
0237NAME IS NULL
2015/12/19(土) 16:52:43.92ID:oyjo6SxHよかったら、「blngs」で検索してみて！
0238NAME IS NULL
2015/12/23(水) 18:08:08.23ID:???本で取り扱うデータベースは問いません
設計について学べる本を教えてください
0239NAME IS NULL
2016/02/04(木) 22:10:35.93ID:iYCEtTbsこれに運営後、支払い方法と手数料に関するカラムが必要になったとして、
A）注文テーブルに支払い方法と手数料用のカラムを追加する
B）注文支払いテーブルを作って、注文テーブルと結合する
のどっちが管理しやすいですか？
プログラミング的には1つのテーブルにまとめた方が取り扱いやすいのですが、
その場合、既に運用しているDB設計を変える（カラム追加する）
必要があるので気になっています。
0240NAME IS NULL
2016/02/04(木) 22:19:23.89ID:vrajJNnU支払い方法に手数料があるなら、支払い方法テーブルを作る。
0241NAME IS NULL
2016/02/04(木) 22:22:19.92ID:vrajJNnU0242NAME IS NULL
2016/02/05(金) 01:04:06.48ID:???運用前後関係なく、そこを曲げたらだめ。
0243239
2016/02/05(金) 01:53:13.62ID:???今までは銀行振込だったのが、代引きや郵便振替など、別の支払方法が増えた
と解釈していただければと思います。
支払い方法が保存されているテーブルが別にあるとして、
注文に対して新たに必要なカラムは
「支払い方法テーブルID」「手数料」になるかと思います。
前者2行の通り、手数料がある場合もあるけど無い場合もある。
無い場合は0かNULL（この場合は0かと思います）になります。
となると、やっぱり注文支払い方法テーブルが必要なんですかね？
>>242
確かにそうなんですが、後からカスタマイズする手間暇コストも気になります
1テーブルのカラム呼び出しだけなら簡単ですからねぇ・・・
0244NAME IS NULL
2016/02/05(金) 04:16:26.64ID:???に対して
> プログラミング的にやりやすいかどうかで判断するのは最後の手段
というレスがついたから、テーブルを分割すべきといわれているように思ったってことなのかな。
0245NAME IS NULL
2016/02/05(金) 07:20:41.17ID:m9Az/ZYB支払い方法が変わらなくても、手数料の金額は変わる可能性があるよね。
難しいことは言わないけど、トランザクションデータに持つのは、マスタデータになるうるデータをトランザクションデータとして持つことになる。
データによって支払い方法と手数料の組み合わせか1対1でないなら、上記のことはあてはまらないけど。
0246NAME IS NULL
2016/02/05(金) 12:21:10.82ID:AioVhB5K仕様に対して適切なデータ構造であれば、自ずとブログラミングも簡単になるもの。
逆もまた然り。
0247NAME IS NULL
2016/02/05(金) 22:32:59.11ID:m9Az/ZYB0248239
2016/02/06(土) 14:57:43.07ID:???0249NAME IS NULL
2016/02/08(月) 23:55:13.21ID:???用途によって違うだろうから、簡単に用途も書いてもらえるとうれしい。
ちなみにうちは所謂OLTPのDBでテーブル約200：インデックス約1000だわ。1対5ってとこ。
減らしたいけど減らせない。
0250NAME IS NULL
2016/02/08(月) 23:56:50.85ID:???0251NAME IS NULL
2016/02/09(火) 00:09:27.02ID:4ybKm805実際には使われてないインデックスを洗い出せば？
0252NAME IS NULL
2016/02/09(火) 00:14:09.87ID:4ybKm805それを言うなら、一度に大量のレコードを検索するかしないかだろ。
0253NAME IS NULL
2016/02/09(火) 00:14:41.25ID:???うん、それもやる予定ではいる。ちょっとそれどころじゃなくて進められてないんだけど…
0254NAME IS NULL
2016/02/09(火) 00:31:03.46ID:4ybKm805インデックスを作れば速くなると思って安易に乱造している可能性もある。
0255NAME IS NULL
2016/02/09(火) 03:47:14.25ID:???0256NAME IS NULL
2016/02/09(火) 03:49:40.70ID:???0257NAME IS NULL
2016/02/09(火) 04:16:25.13ID:???5個もインデックス必要ならテーブル分割も検討した方が良いような気がする
あくまで根拠のない個人的な感想だけどな
0258NAME IS NULL
2016/02/09(火) 07:05:13.91ID:???平均だとうちもそんなもん
PK のみって言うテーブルも多いし
平均で５は明らかに多すぎる様に思う
0259NAME IS NULL
2016/02/09(火) 07:19:20.31ID:JcT1gAvw0260NAME IS NULL
2016/02/09(火) 07:21:12.67ID:JcT1gAvw0261NAME IS NULL
2016/02/09(火) 10:36:59.85ID:???> うん、それもやる予定ではいる。ちょっとそれどころじゃなくて進められてないんだけど…
何のデータベース使ってるか知らないけど、大抵はクエリ一発で全インデックスのヒット率を
取得できると思うぞ。
0262NAME IS NULL
2016/02/11(木) 09:32:59.47ID:8EE+OOiZＢＩツール的な利用イメージで、集約された情報からの検索を考えた場合に、
どんな条件で検索されるかもわからないから、正規化せずに1つのテーブルに全項目持っておけば
固有なプログラムつくる必要ないかなーと。検索条件に合致する行だけを取り出せばいい。
まぁＲＤＢだとindexとか冗長とかいろいろあるけど、それをうまく実現可能なＤＢってあります？
0263NAME IS NULL
2016/02/11(木) 09:44:08.73ID:x69Y51xPSQLが変わり、データ量が増えるだけです。
0264NAME IS NULL
2016/02/11(木) 09:45:54.77ID:x69Y51xPむしろ専用の検索プログラムが必要になりますね。
0265NAME IS NULL
2016/02/11(木) 09:51:06.80ID:x69Y51xP0266NAME IS NULL
2016/02/11(木) 14:15:46.98ID:8EE+OOiZ1テーブルに持てば、selectする項目とwhere句の条件項目が変わるだけでは。
動的SQLで吸収すれば検索プログラムは1つで済むし。joinとかいらないし。
データウェアハウスをどう構えるかって話。
0267NAME IS NULL
2016/02/11(木) 15:03:21.99ID:???それで問題ないかも知れないし
問題あっても困るのは俺じゃないしな
0268NAME IS NULL
2016/02/11(木) 20:42:33.91ID:x69Y51xP分からないから質問したんじゃないの？
思ったようにやればいいよ。
データを持ち直してSQLを変えて、さらにそのSQLが不定って、最初から元のDBのビューでいいんじゃないの？
だいたいBIツールがなんだか分かってる？
0269NAME IS NULL
2016/02/24(水) 22:22:34.79ID:1LNjXYAL0270NAME IS NULL
2016/02/25(木) 20:06:39.30ID:???0271NAME IS NULL
2016/02/29(月) 10:24:17.57ID:Bh4c8Jux「ループ内でクエリを書いてはいけない」（ミック氏銘々(?)のぐるぐる系クエリは書いてはいけない）と
いうことが説明されている、初心者向けの書籍はありますか？
私が初心者ということではなく、初心者にまず与える書籍を探しています。
『SQL実践入門』には記載されていることはわかっていますが、他の章のレベルが高いため、初心者
向けには厳しいと思っています。
0272NAME IS NULL
2016/02/29(月) 11:38:32.73ID:???0273NAME IS NULL
2016/02/29(月) 14:37:54.43ID:???別に初心者に書籍を与えるまでもなく、説明をしてあげればいいのにと思う。
0274NAME IS NULL
2016/02/29(月) 14:51:58.25ID:???> 別に初心者に書籍を与えるまでもなく、説明をしてあげればいいのにと思う。
私は初心者に教える暇がないので、そのような書籍があればまず最初の一冊目として
推薦したいのです。
0275NAME IS NULL
2016/02/29(月) 14:52:44.87ID:???0276NAME IS NULL
2016/02/29(月) 14:55:24.08ID:???0277NAME IS NULL
2016/02/29(月) 15:06:54.72ID:???例えばループ内でクエリを書かないということ一つとっても、解決方は多数あり
個人個人に教えるのは非効率です。
0278NAME IS NULL
2016/02/29(月) 15:10:18.46ID:???例えばループ内でクエリを書いてはいけないなどの穴がある」ような人じゃなくて、
基本的なことも知らない初心者を想定してください。
最悪、JOINもSUMも知らない初心者です。
0279NAME IS NULL
2016/02/29(月) 15:15:08.62ID:???推薦図書/必読書のためのスレッド 78 [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1447165038/404
0280NAME IS NULL
2016/02/29(月) 15:40:22.25ID:???そのスレでは>>271以外の奴が全員ど素人。
知ってれば教えてやりたいが、初心者向けの書籍なんかもう何年も読んでないんでわからん。
0281NAME IS NULL
2016/02/29(月) 15:47:22.46ID:???> 知ってれば教えてやりたいが、初心者向けの書籍なんかもう何年も読んでないんでわからん。
だよなぁ
この板に来る奴は、初心者で書籍も読まないような奴か、ベテランのどちらか
でかい本屋に行って、自分で探すしかないのでは
0282NAME IS NULL
2016/02/29(月) 15:56:57.26ID:???0283NAME IS NULL
2016/02/29(月) 15:58:44.07ID:???0284NAME IS NULL
2016/02/29(月) 16:01:14.87ID:???あ、なるほど
納得
0285NAME IS NULL
2016/02/29(月) 16:10:39.68ID:???ループしないようにするためには、JOINから始まってsubqueryや分析関数(Window関数)、再帰クエリや
SQLパズルに載っているようなトリッキーなクエリに至るまで、さまざまな手段がある。
クエリをループさせては駄目なことを教えるのは簡単だけど、解決法を教えるのは時間がかかると思うよ。
まぁ、本を多数読むしかないかね。
0286NAME IS NULL
2016/02/29(月) 16:12:41.35ID:???初心者向けSQL本を探すぐらいなら、その項目は別途説明という形を取ったほうが余程いいと思う。
それも本で済ませたいということならアルゴリズム本も読ませて
計算量についての素養も身につけさせておけばいいんじゃない？
>>285
それらも網羅した初心者向けの書籍を欲していると？
0287NAME IS NULL
2016/02/29(月) 16:20:59.57ID:???なんでそれだけ別途説明にしろって思うのか、よくわかんないんだけど。
説明がのってる書籍があるなら、それ与えれば終了でしょ。
っていうか、あるんじゃないの？俺はしらんけど。
0288NAME IS NULL
2016/02/29(月) 16:26:43.76ID:???0289NAME IS NULL
2016/02/29(月) 16:27:33.72ID:???0290NAME IS NULL
2016/02/29(月) 16:29:45.29ID:???お前のせいでこのスレが書籍スレになったじゃねーか
0291NAME IS NULL
2016/02/29(月) 16:32:44.25ID:???0292NAME IS NULL
2016/02/29(月) 16:33:30.52ID:???0293NAME IS NULL
2016/02/29(月) 16:46:42.98ID:???まぁ、これだろな
板人口も少ないし
0294NAME IS NULL
2016/02/29(月) 16:56:49.11ID:???0295NAME IS NULL
2016/02/29(月) 17:24:29.12ID:???0296NAME IS NULL
2016/02/29(月) 17:26:57.60ID:???知らないことがループの件だけだったらそうすればいいね
0297NAME IS NULL
2016/02/29(月) 18:07:42.17ID:???1冊で済ますのはなかなか厳しいような。
とりあえず「プログラマのためのSQL」と「PofEAA」くらいかな。
0298NAME IS NULL
2016/02/29(月) 18:24:10.15ID:???> 本屋に行って自分で探せ、で終了。
おっしゃる通りですね。
ただ、現状は、業務命令として探せといわれてるのではなく、見つかるなら提案しようというレベルですので、
ちょっと腰が重くなりがちです。
0299NAME IS NULL
2016/02/29(月) 18:30:32.73ID:???> とりあえず「プログラマのためのSQL」と「PofEAA」くらいかな。
実は、『プログラマのためのSQL』には、「ループ内でクエリを書いてはいけない」ということが
書かれてないんです。というか、クライアントサイドの話はほぼないんですね。
みなさん、どこで「ループ内でクエリを書いてはいけない」ことを学んだんでしょうか。
私は・・・ちょっと・・・思い出せません。
0300298
2016/02/29(月) 19:01:10.87ID:???テキストで読んだ記憶はないなあ。
確かに『プログラマのためのSQL」に
「クライアントサイド」(←SQLを利用するプログラムという解釈でいいよね？)
の話はないですね。
そのあたりをパターン化したものを紹介した書籍としてPofEAAを挙げました。
0301NAME IS NULL
2016/02/29(月) 20:51:26.81ID:???データベース雑誌・書籍
http://peace.2ch.net/test/read.cgi/db/1057410827/191
0302NAME IS NULL
2016/02/29(月) 21:09:49.27ID:???今のお子様本渡したら消化早いけど全く覚えてないよ
0303NAME IS NULL
2016/02/29(月) 21:21:47.75ID:???本人乙
0304NAME IS NULL
2016/02/29(月) 21:56:21.99ID:???そもそもループ内でクエリ書くなとか、つまるところホストアプリでやるべきかSQLでやるべきかって話だろ
すくなくともSQL初心者が考えるような事じゃないよ
0305NAME IS NULL
2016/02/29(月) 22:02:20.13ID:???0306NAME IS NULL
2016/02/29(月) 22:09:40.39ID:???質問主は素人なんだろ
0307NAME IS NULL
2016/02/29(月) 23:08:09.11ID:???設計段階で不明なら試験するしかにい
0308NAME IS NULL
2016/02/29(月) 23:15:57.67ID:???0309NAME IS NULL
2016/02/29(月) 23:38:15.35ID:???0310NAME IS NULL
2016/03/01(火) 00:15:32.34ID:???0311NAME IS NULL
2016/03/01(火) 01:08:30.90ID:???0312NAME IS NULL
2016/03/01(火) 01:10:37.02ID:???0313NAME IS NULL
2016/03/01(火) 09:45:47.08ID:???0314NAME IS NULL
2016/03/01(火) 10:04:48.41ID:???あっちのスレでもこっちのスレでも、こいつが暴れてるのな
0315NAME IS NULL
2016/03/01(火) 10:08:02.51ID:???> レビューで指摘するか、
最初から正しいコードをかけてれば、レビューで指摘することもない。
> 性能を気にするなら性能試験をやってで最適化すればいい話
「最適化」じゃなくて、適切なクエリとコード書けという話だ。
> 質問主は素人なんだろ
お前が名。
0316NAME IS NULL
2016/03/01(火) 10:09:04.20ID:???> 設計段階で不明なら試験するしかにい
試験するしかないとか言ってるのがど素人の証拠だよ。
0317NAME IS NULL
2016/03/01(火) 10:26:19.48ID:???> そもそもループ内でクエリ書くなとか、つまるところホストアプリでやるべきかSQLでやるべきかって話だろ
さすがに釣りじゃないの？
あと、クライアントコードの話はスレ違いなので。
0318NAME IS NULL
2016/03/01(火) 13:19:50.86ID:???> なんでそういう書籍が無いかというと、「ループ内でクエリを書いてはいけない」ってのが真ではないから。
『SQL実践入門』にはあるんですが・・・
0319NAME IS NULL
2016/03/01(火) 13:57:42.63ID:???やっぱり素人ｗ
0320NAME IS NULL
2016/03/01(火) 14:08:20.19ID:???0321NAME IS NULL
2016/03/01(火) 14:15:57.91ID:???0322NAME IS NULL
2016/03/01(火) 14:18:42.17ID:???時間がないから本を与えることで解決したいというのはわかった。
本を1冊に絞らなければならない理由もあるの？
0323NAME IS NULL
2016/03/01(火) 14:33:40.41ID:???設計書には、「商品マスターから指定された条件にマッチする商品コードを取得する」、
「取得した商品コード一覧から販売テーブルを検索し販売実績を取得する」とあって、
実装を担当するコーダーは忠実にそのステップ通りに書きあげた。
１００種程度の商品マスターと、それぞれ２０〜４０程度の販売履歴を作成し、試験を
実施した結果、問題なく処理できると判定された。
実際に使い始め、しばらく経つと商品マスターが数千種〜１万種、販売履歴も多くなり、
異様に処理が重くなった、画面表示が何分も待たされてしまうようになったと、顧客から
クレームが入り、原因の調査が始まった。（つづきません）
0324NAME IS NULL
2016/03/01(火) 14:46:22.34ID:???0325NAME IS NULL
2016/03/01(火) 14:50:25.88ID:???まあどこで絞り込んでるかの話よね？
0326NAME IS NULL
2016/03/01(火) 15:07:43.58ID:???> まあどこで絞り込んでるかの話よね？
いいえ
0327NAME IS NULL
2016/03/01(火) 15:24:21.12ID:???モデリング？何それ？リレーション？何それ？的なDBはまだまだある
0328NAME IS NULL
2016/03/01(火) 15:37:34.29ID:???0329NAME IS NULL
2016/03/01(火) 15:44:40.66ID:???0330NAME IS NULL
2016/03/01(火) 15:55:57.37ID:???実際にはそのうち１００件弱の商品を選んで表示する時らしい。
ユーザーから見たときは、各行がじわりじわりと表示されていたとかいないとか。
0331NAME IS NULL
2016/03/01(火) 15:56:19.37ID:???0332NAME IS NULL
2016/03/01(火) 15:57:38.45ID:???何がしたいんだよお前は
0333NAME IS NULL
2016/03/01(火) 16:09:35.76ID:???もともと100件弱のテストをしたときは速度問題なかったんだよね。
つまり、商品コード取得クエリ1回+販売実績取得クエリ100回の構成で。
となると販売テーブルの商品コードにちゃんとインデックス貼ってるか、
そして使われているかを確認すべき状況かなぁ。
0334NAME IS NULL
2016/03/01(火) 16:14:21.09ID:???0335NAME IS NULL
2016/03/01(火) 16:15:00.44ID:???全件取得して手元でフィルターかけてたら遅いだろうけど
0336NAME IS NULL
2016/03/01(火) 16:22:56.53ID:???0337NAME IS NULL
2016/03/01(火) 16:26:31.38ID:???0338NAME IS NULL
2016/03/01(火) 16:29:09.10ID:???PofEAAって、初心者には無茶ですやん。
0339NAME IS NULL
2016/03/01(火) 16:49:23.52ID:???突っ込みどころ多すぎて、マジレスなのか釣りなのか判定不能なレベル
0340NAME IS NULL
2016/03/01(火) 17:47:06.23ID:???0341NAME IS NULL
2016/03/01(火) 17:48:41.19ID:???想定見積件数が甘かったってだけだろ
今の回線とPC速度考えれば数万でも何分もかかるとは思えんと言うのは置いといて
さすがにその処理をホストアプリでやるのは不適切だけど
それに誰も気づかないで本番リリースする体制が一番の問題だな
0342NAME IS NULL
2016/03/01(火) 18:03:20.36ID:???0343NAME IS NULL
2016/03/01(火) 18:05:55.99ID:???0344NAME IS NULL
2016/03/01(火) 18:32:58.23ID:???0345NAME IS NULL
2016/03/01(火) 20:10:39.00ID:???クエリ発行回数が変わらないにもかかわらず、異様に遅くなるということは
DB設計に問題があると判断できる。
その状況において、ループ内クエリを排除したところで、
ゆくゆくはユーザが体感するほどのパフォーマンス低下をむかえることになる。
つまり問題が表面化するのが速いか遅いかの違いでしかなかった。
もちろんループ内クエリを排除し、かつ、DB設計を適切なものにするべきだけれど、
ループ内クエリのみが悪という事例ではないはずだよ。
0346NAME IS NULL
2016/03/01(火) 21:44:13.93ID:???ダメだとは書いてないだろ。その本は利点と欠点の両方を挙げて説明してる。
0347NAME IS NULL
2016/03/01(火) 22:30:09.95ID:???> クエリ発行回数が変わらないにもかかわらず
ふぁ？
0348NAME IS NULL
2016/03/01(火) 23:14:05.11ID:???そこまではいいが、1クエリにすりゃ何でも速くなると思ってる奴もバカ。
0349NAME IS NULL
2016/03/02(水) 00:30:43.40ID:???えっ状況理解できてない？
0350NAME IS NULL
2016/03/02(水) 10:16:24.80ID:???「プロの俺様が今まで「ループ内でクエリを書いてはいけない」なんて言われたこと内のだから、それが真であるはずがない」
に賛同する奴はいない。
0351NAME IS NULL
2016/03/02(水) 10:20:32.28ID:???> クエリ発行回数が変わらないにもかかわらず、異様に遅くなるということは
> DB設計に問題があると判断できる。
は？
O(n^2)だからデータ数が多くなって問題が顕在化したというケースもあるだろ。
つまり、コードに問題があるケース。
0352NAME IS NULL
2016/03/02(水) 10:50:27.91ID:???> その状況において、ループ内クエリを排除したところで、
> ゆくゆくはユーザが体感するほどのパフォーマンス低下をむかえることになる。
> つまり問題が表面化するのが速いか遅いかの違いでしかなかった。
商品1万種×販売実績1,000万くらいだとしたら、普通にクエリ書いて適切なインデックス貼れば
パフォーマンス低下なんておこらんでしょ。
0353NAME IS NULL
2016/03/02(水) 10:59:06.79ID:???0354NAME IS NULL
2016/03/02(水) 11:38:15.11ID:???0355NAME IS NULL
2016/03/02(水) 12:07:59.64ID:???0356NAME IS NULL
2016/03/02(水) 13:03:41.24ID:???0357NAME IS NULL
2016/03/02(水) 13:09:16.60ID:???> 設計書には、「商品マスターから指定された条件にマッチする商品コードを取得する」、
> 「取得した商品コード一覧から販売テーブルを検索し販売実績を取得する」とあって、
> 実装を担当するコーダーは忠実にそのステップ通りに書きあげた。
>>352
>>333
0358NAME IS NULL
2016/03/02(水) 13:14:12.36ID:???0359NAME IS NULL
2016/03/02(水) 13:14:59.41ID:???JOIN使っても遅くなることに気づけてないのかな
0360NAME IS NULL
2016/03/02(水) 13:16:08.51ID:???要するに、ループ内でクエリ発行しても問題ないと主張したいだけなんだな。
アホらし。
0361NAME IS NULL
2016/03/02(水) 13:17:04.88ID:???O(n)もO(n^2)もO(log n)も同じなんですね。
0362NAME IS NULL
2016/03/02(水) 13:20:22.66ID:???ループ内クエリを排除すべきとも書いたが。
>>361
リリース当初とパフォーマンスが異様に低下した時点でのクエリ発行回数が同じというのは理解できたかな。
まず>>329でO(n)の話かなと探りを入れたら>>330でそうではないとのこと。
0363NAME IS NULL
2016/03/02(水) 13:25:05.91ID:???> >>351
> > 設計書には、「商品マスターから指定された条件にマッチする商品コードを取得する」、
> > 「取得した商品コード一覧から販売テーブルを検索し販売実績を取得する」とあって、
> > 実装を担当するコーダーは忠実にそのステップ通りに書きあげた。
だったら、そのコードの設計が悪いね。
0364NAME IS NULL
2016/03/02(水) 13:29:28.37ID:???お前いったい誰と何の話してんの？
>>339
> 突っ込みどころ多すぎて、マジレスなのか釣りなのか判定不能なレベル
↓
>>345
> クエリ発行回数が変わらないにもかかわらず、異様に遅くなるということは
> DB設計に問題があると判断できる。
↓
>>351
> は？
> O(n^2)だからデータ数が多くなって問題が顕在化したというケースもあるだろ。
> つまり、コードに問題があるケース。
要するに、>>345の「〜と判断できる」がおかしいといってるわけ。
「異様に遅くなる」の原因は、
・ループ内でクエリを発行しているため
・インデックスがないため
の複合。
0365NAME IS NULL
2016/03/02(水) 13:35:15.66ID:???> ・インデックスがないため
これがO(n)の原因だからな。
0366NAME IS NULL
2016/03/02(水) 13:35:50.25ID:???そうだよ。少なくともコードの設計も悪い。
しかしそれだけならリリース当初に比べて「異様に遅く」なることは考えにくい。
とするとクエリの速度が著しく低下していることが予想されるので、>>333となる。
0367NAME IS NULL
2016/03/02(水) 13:38:15.13ID:???0368NAME IS NULL
2016/03/02(水) 13:38:55.33ID:???0369NAME IS NULL
2016/03/02(水) 13:40:26.18ID:???0370NAME IS NULL
2016/03/02(水) 13:41:41.67ID:???> インデックスが貼られていない状況でもJOINしてれば遅くならないという考えでいいのかな
ホストコードでループするよりはまし。
0371NAME IS NULL
2016/03/02(水) 13:45:06.37ID:???素直にJOINにしとけばいいのに。
0372NAME IS NULL
2016/03/02(水) 13:45:33.25ID:???リリース時点では速度要件を満たしていた。
ループ対象はいずれも100件程度。
適切なインデックスがあり、かつ使われていれば異様に遅くなることは考えにくく、
速度要件も満たしたままだっただろうということ。
リリース時点でのアプリが要件を満たしているもののイマイチ遅いのはループ内クエリの影響だろう。
>>370
ましだが、遅くなる。
> その状況において、ループ内クエリを排除したところで、
> ゆくゆくはユーザが体感するほどのパフォーマンス低下をむかえることになる。
> つまり問題が表面化するのが速いか遅いかの違いでしかなかった。
0373NAME IS NULL
2016/03/02(水) 13:47:37.37ID:???> リリース時点では速度要件を満たしていた。
そもそも、これが大間違いなんだよ。
リリース時点でも性能要件は満たしていなかった。
ただそういうこと。
0374NAME IS NULL
2016/03/02(水) 13:48:41.65ID:???> 適切なインデックスがあり、かつ使われていれば異様に遅くなることは考えにくく、
> 速度要件も満たしたままだっただろうということ。
だったらなんでORM界隈でN+1問題が話題になるんだろうね。
彼らのデータベースにはインデックスがないのかね。
0375NAME IS NULL
2016/03/02(水) 13:55:57.36ID:???その「イマイチ遅い」というのが、100ms VS 1,000msだったりするんだけどね。
で、ボタンクリックから画面表示まで、httpリクエストからレスポンス完了までで累積すると
300ms VS 5,000msとかになるわけ。
0376NAME IS NULL
2016/03/02(水) 13:57:00.91ID:???リリース時点での話だよね。
事例でいくと5000msでユーザは許容していたということになる。
0377NAME IS NULL
2016/03/02(水) 14:01:14.71ID:???リリース時点での性能要件を満たすかどうか判定できる情報は出してないんでしょ。
100レコードでしか動作させてないんだから。
だから、5,000msをユーザが容認するかどうかなんてわからないじゃん。
まぁ、容認しないと思うけど。
0378NAME IS NULL
2016/03/02(水) 14:04:41.17ID:???> １００種程度の商品マスターと、それぞれ２０〜４０程度の販売履歴を作成し
これがもう全然駄目。
性能要件を満たすかどうかを判定するなら、少なくともレコード数の条件くらいは満たしてないと。
0379NAME IS NULL
2016/03/02(水) 14:10:00.57ID:???0380NAME IS NULL
2016/03/02(水) 14:27:29.78ID:???リリース時点では客からクレームが出るほど遅くはなかったのは事実。
JOINにしていれば件数が増えてもクレームが出るほど遅くはならずにすんだかもしれないけれど、
インデックス貼ってないんだとすれば、度合いの違いこそあれ件数に応じて速度が低下するのは予想できるよね。
性能試験を行ってれば、コード設計DB設計どちらにもミスがあることに気づけたと思う。
繰り返すけど、ループ内クエリが問題ないとは一度も書いてないよ。
0381NAME IS NULL
2016/03/02(水) 14:31:32.25ID:???>>337で答え書いてるのに、何と闘ってるの？
0382NAME IS NULL
2016/03/02(水) 14:37:45.88ID:???> 度合いの違いこそあれ件数に応じて速度が低下するのは予想できるよね。
その速度の低下具合が、ループ内クエリにしてるか、JOINで一括取得してるかで全然違うんだが。
0383NAME IS NULL
2016/03/02(水) 14:43:53.68ID:???データベースの基本からやり直した方が良いよ。
E.F.Coddのお言葉：
> 「関係操作では、関係全体をまとめて操作の対象とする。目的は繰り返し（ループ）をなくすることである。
> いやしくも末端利用者の生産性を考えようというのであれば、この要件を欠くことはできないし、応用
> プログラマの生産性向上に有益であることも明らかである。」
クライアントでループしてデータを個別取得するなんて論外。
0384NAME IS NULL
2016/03/02(水) 14:51:51.88ID:???> リリース時点では客からクレームが出るほど遅くはなかったのは事実。
まだ言いますか。
性能を評価できるデータを出していなかっただけでしょ。
クライアントは機能外要件のことなんか気づかないことが多いんだから、こちらから言わないとね。
0385NAME IS NULL
2016/03/02(水) 15:02:22.00ID:???客：なんか最近システムが重いんですが
俺様：調査します（調査費用Get）
俺様：データが想定以上に多くなっていますね。パフォーマンスを改善する改修をします？
客：お願いします
俺様：（改修費用Get)
0386NAME IS NULL
2016/03/02(水) 15:51:39.95ID:???それと同じことしか書いてない
>>382
そうだね。でもインデックスを作成していなければやはり遅くなるからDB設計の不具合も修正すべき
>>383
そうだね。ループ内クエリが問題ないとは書いてないよ。
>>384
> 実際に使い始め、しばらく経つと〜異様に処理が重くなった
当初は問題ない応答速度だったと予想できる。
0387NAME IS NULL
2016/03/02(水) 15:57:34.02ID:???> それと同じことしか書いてない
じゃ、うざいんでレス止めて
0388NAME IS NULL
2016/03/02(水) 15:58:48.71ID:???0389NAME IS NULL
2016/03/02(水) 16:00:15.07ID:???> それと同じことしか書いてない
嘘つけ
お前、「プロの俺様が今まで「ループ内でクエリを書いてはいけない」なんて言われたこと内のだから、それが真であるはずがない」の俺様だろ
0390NAME IS NULL
2016/03/02(水) 16:00:18.54ID:???>>333 >>345でそのことを書いてんだけど、むしろ突っかかられてるんですがそれは。
0391NAME IS NULL
2016/03/02(水) 16:00:34.33ID:???うわ、まったくの他人
0392NAME IS NULL
2016/03/02(水) 16:02:22.26ID:???> >>333 >>345でそのことを書いてんだけど、むしろ突っかかられてるんですがそれは。
いやいやいや、違うこと（頓珍漢）なこと書いてんじゃん
お前が変なこと書かなければ、何かを言われることもない
0393NAME IS NULL
2016/03/02(水) 16:03:01.52ID:???残念
アホが一人かと思ったら二人いたのか
0394NAME IS NULL
2016/03/02(水) 16:03:10.70ID:???http://prntscr.com/aa56kp 一応
0395NAME IS NULL
2016/03/02(水) 16:05:24.22ID:???0396NAME IS NULL
2016/03/02(水) 16:08:48.04ID:???件数が増えたときに劣化するのは適切なインデックスがないから。
異様に遅くなったのは適切なインデックスがないことによるパフォーマンス低下を、
ループ内クエリが増幅させた結果。
0397NAME IS NULL
2016/03/02(水) 16:15:44.88ID:???何度もそれ言われてるのに、さらに話を展開させたがるのは、一体何を主張したいのか
0398NAME IS NULL
2016/03/02(水) 16:20:23.27ID:???>>333
> もともと100件弱のテストをしたときは速度問題なかったんだよね。
>>361
> リリース当初
>>371
> リリース時点では速度要件を満たしていた。
そんなの何の意味もないのに。
0399NAME IS NULL
2016/03/02(水) 16:21:00.39ID:???0400NAME IS NULL
2016/03/02(水) 16:23:06.58ID:???という主張をしたいのだと思ったが、そうでないとすると一体何だったのか。
0401NAME IS NULL
2016/03/02(水) 16:30:11.77ID:???0402NAME IS NULL
2016/03/02(水) 16:46:22.46ID:???適切なインデックスがあればリリース当初と比べて異様に遅くなるということはなかっただろうね。
>>401
その中にもいないよ。外れてばかりだね
0403NAME IS NULL
2016/03/02(水) 16:51:27.63ID:???> 適切なインデックスがあればリリース当初と比べて異様に遅くなるということはなかっただろうね。
最初に性能測定してれば、リリース当初から問題があることがわかっただろうがね。
0404NAME IS NULL
2016/03/02(水) 16:57:31.29ID:???ありがとうございました。
0405NAME IS NULL
2016/03/02(水) 16:59:53.65ID:???最初に性能測定をしていない状態でリリースし、問題が発生し、その調査を行うというストーリーが前提でしょ
0406NAME IS NULL
2016/03/02(水) 17:13:38.38ID:???だったら、Slow Queryログを見るのがまずやること。
残念なことに、thresholdを500msとかにしとくと、ループ内クエリの場合ログが出力されない
場合がある（累積処理時間が長いだけで、個々のクエリは100msかそこらで終わってたり）
次にコードを見て該当クエリを発見し、実行計画を調べる。
今回の場合は、そこでコードが糞ってすぐわかるが。
インデックスが使われてるかどうかだけじゃ、わからないことがあるんだよ。
ほれ、適切なインデックスが使われてるにも関わらず遅いクエリの例。
http://explain.depesz.com/s/1icN
0407NAME IS NULL
2016/03/02(水) 17:23:30.61ID:???まったくそのとおり。
クエリ発行回数が変わっていないという情報も加味すれば
個々のクエリが遅くなっている可能性が高まるよね。
(もちろんコードも悪いよ。コードも悪いが、それのみじゃ異様に遅くはならない)
状況的にもnested loopが使われることもないクエリだろう。
0408NAME IS NULL
2016/03/02(水) 17:24:27.50ID:???0409NAME IS NULL
2016/03/02(水) 17:27:07.63ID:???ちなみにこの糞クエリは、俺様が書き直したら2,000msから50msくらいになったわ。
0410NAME IS NULL
2016/03/02(水) 17:43:00.43ID:???0411NAME IS NULL
2016/03/02(水) 17:45:09.26ID:???運用中のサービスに対して、
・インデックスを作成すればリリース当初とさほど変わらないレスポンスに戻る
・コードを修正すれば速度が改善される
→この結果リリース当初よりも速くなるか、リリース当初よりも遅くなるかの判断はまだできない
という二つの対応方法があって、二つともやるべきだと。
それなら、先にやれるのはインデックス作成でしょ。
コード修正優先なの？
> ユーザーから見たときは、各行がじわりじわりと表示されていたとかいないとか。
ということだから、1件取得表示するのに200ms近くかかっているかもしれない。
インデックスを作成しない場合、商品コードをもとに販売テーブルを検索する機能がほかにあれば
それらも少なからず影響を受けているんだろう。
0412NAME IS NULL
2016/03/02(水) 17:48:30.13ID:???インデックス作成しよう、なんて意見が出ること自体異常
0413NAME IS NULL
2016/03/02(水) 17:50:31.24ID:???ははぁ、動いてるコードは触るな教の人だな。
俺なら絶対にコードも修正するから、既存コードを速くすることなんてしないよ。
0414NAME IS NULL
2016/03/02(水) 17:51:42.60ID:???問題が見つかったら元から改善しとかないと。
0415NAME IS NULL
2016/03/02(水) 17:54:10.32ID:???それがないから起こった事象だととらえるのが自然じゃないかな。
適切なインデックスはあるはずだし、ループ内クエリそれのみが問題だとするならそう主張すればいいと思うよ。
>>413
触るななんて書いてない。なんでそう曲解するんだろ。
ところで、コードを修正するけど既存コードを速くしないってどういうこと？
0416NAME IS NULL
2016/03/02(水) 17:54:14.43ID:???> →この結果リリース当初よりも速くなるか、リリース当初よりも遅くなるかの判断はまだできない
まだ言ってんの？
速くなるに決まってるじゃん。
遅くなるとしたらなんでよ？
0417NAME IS NULL
2016/03/02(水) 17:55:26.52ID:???結合カラムにインデックスがないから
0418NAME IS NULL
2016/03/02(水) 17:57:10.19ID:???> ところで、コードを修正するけど既存コードを速くしないってどういうこと？
「既存コードで」の間違い。
0419NAME IS NULL
2016/03/02(水) 17:58:33.83ID:???もともとインデックスが無い場合の話だろ？
何言ってるの？
0420NAME IS NULL
2016/03/02(水) 18:01:19.19ID:???だからJOINにしたところで、JOINも少なからずパフォーマンス低下しているといってる。
nested loop joinされちゃうよね、と。
0421NAME IS NULL
2016/03/02(水) 18:02:33.37ID:???0422NAME IS NULL
2016/03/02(水) 18:02:59.85ID:???0423NAME IS NULL
2016/03/02(水) 18:03:47.21ID:???それが大問題になるほどO/RMのコストを無視できないのなら、開発段階の100回発行時点で気づくだろと。
0424NAME IS NULL
2016/03/02(水) 18:26:40.17ID:???レコード数が多くなったのが問題を引き起こしたんだよ。
お前の為にコード書いてやったわ。
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
わかったか、アホめ。
0425NAME IS NULL
2016/03/02(水) 18:29:49.72ID:???ネットワークのレイテンシが問題というわけではない。
0426NAME IS NULL
2016/03/02(水) 18:38:09.47ID:???前者の実行計画は普通にseq scanかな。
index作成するとどうなるの
0427NAME IS NULL
2016/03/02(水) 18:41:55.95ID:???自分でｔ試せ、アホが。
0428NAME IS NULL
2016/03/02(水) 20:23:55.27ID:???0429NAME IS NULL
2016/03/02(水) 20:35:28.20ID:???WHERE key = ... の繰り返しと WHERE key IN ( ... ) 1回で済ませるのとのどっちが速いかって話かと思ってた。>>311
0430NAME IS NULL
2016/03/02(水) 21:59:16.83ID:???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回分余分に足される
0431NAME IS NULL
2016/03/02(水) 22:12:22.70ID:ymvRmzXh0432NAME IS NULL
2016/03/02(水) 22:43:53.92ID:???0433NAME IS NULL
2016/03/03(木) 04:30:46.04ID:???0434NAME IS NULL
2016/03/03(木) 07:07:33.64ID:???しんじゃうんだろうなってぐらい必死で
笑えるな
0435NAME IS NULL
2016/03/03(木) 09:48:36.15ID:???0436NAME IS NULL
2016/03/03(木) 10:15:34.11ID:???違うよ。
俺様=>>271=>>424だ。途中で人格変えたがな。
>>411みたいなアホの相手するの面倒なんで、書籍を探してるってわけ。
0437NAME IS NULL
2016/03/03(木) 10:40:49.66ID:???0438NAME IS NULL
2016/03/03(木) 10:48:39.38ID:???こういうケースではこうするという事例さえ覚えていけば応用効くっしょ
0439NAME IS NULL
2016/03/03(木) 11:10:36.67ID:???は？何勝手に俺様騙ってんだよ、俺が俺様だ
0440NAME IS NULL
2016/03/03(木) 12:27:20.23ID:BwEBd+t30441NAME IS NULL
2016/03/03(木) 15:52:44.61ID:???0442NAME IS NULL
2016/03/03(木) 16:10:49.17ID:???0443NAME IS NULL
2016/03/03(木) 17:06:54.08ID:???0444NAME IS NULL
2016/03/03(木) 17:15:58.35ID:???覚えてる奴いないレベルｗ
0445NAME IS NULL
2016/03/03(木) 17:20:18.49ID:???0446NAME IS NULL
2016/03/03(木) 17:38:24.22ID:???> こういうケースではこうするという事例さえ覚えていけば応用効くっしょ
そんなめんどくさいことしなくていいよ。
「ループ内でクエリを発行するな」
これだけでいい。
0447NAME IS NULL
2016/03/03(木) 17:39:28.99ID:???ID表示にできるんならしようぜ
0448NAME IS NULL
2016/03/03(木) 17:46:40.04ID:???0449NAME IS NULL
2016/03/03(木) 17:47:20.86ID:???0450NAME IS NULL
2016/03/03(木) 17:50:20.48ID:???http://blog.xao.jp/blog/mysql/mysql%E3%81%AE%E8%B6%85%E9%81%85%E3%81%84select%E3%81%8C%E5%8A%87%E7%9A%84%E3%81%AB%E6%97%A9%E3%81%8F%E3%81%AA%E3%81%A3%E3%81%9F/
こんな人、ごろごろいそう
0451NAME IS NULL
2016/03/03(木) 17:51:47.17ID:???この手の話は、やっぱム板なのかな
0452NAME IS NULL
2016/03/03(木) 17:53:08.05ID:???0453NAME IS NULL
2016/03/03(木) 17:53:35.18ID:???データベースプログラミング全般スレ
http://echo.2ch.net/test/read.cgi/tech/1097295557/
0454NAME IS NULL
2016/03/03(木) 17:54:41.57ID:???0455NAME IS NULL
2016/03/03(木) 17:56:19.53ID:???>>427
0456NAME IS NULL
2016/03/03(木) 18:02:30.39ID:???PostgreSQL+PHPで試した。
for ($i = 0; $i < 100; $i++) {
$sql = 'SELECT CURRENT_DATE';
$stmt = $db->query($sql);
$row = $stmt->fetch(PDO::FETCH_ASSOC);
}
実行時間 0.077秒
0457NAME IS NULL
2016/03/03(木) 18:08:19.42ID:???DBMS固有の仕様を知らなかったという記事を、indexの存在を知らない人の記事だと読み替える技術に感服
0458NAME IS NULL
2016/03/03(木) 18:22:05.82ID:???固有じゃないよ
大抵そうでしょ
絡むの順番大事
0459NAME IS NULL
2016/03/03(木) 18:26:40.12ID:???カラムの順番は大事だけど、この記事のケースだと少なくともPostgreSQLだったらindexは使われるよ。
MySQLが特殊なのか、PostgreSQLが特殊なのかはわからないけど。
0460NAME IS NULL
2016/03/03(木) 18:28:05.32ID:???0461NAME IS NULL
2016/03/03(木) 18:37:43.64ID:???0462NAME IS NULL
2016/03/03(木) 18:46:53.24ID:???有名な拡張であるgroup by に指定していないカラムを集約関数抜きに抽出できるのは、支持される側面もある。
気持ち悪いだろと非難される側面でもあるけれど。
PostgreSQLはいつぞやにその拡張を部分的に取り込んだりしたよ。
0463NAME IS NULL
2016/03/03(木) 21:15:11.16ID:???なんで>>280を抜かすｗ
0464NAME IS NULL
2016/03/04(金) 08:30:42.36ID:???指定しなくても一意であることが分かっている列を指定しなくてもいいのは便利だが、
ひどいのはそこじゃないからな。
一意制約条件なんかを見て(標準でも独自でもいい)指定可能列を制限する。
そこまでやってたらMySQLスゲーって言って貰えるよ。
0465NAME IS NULL
2016/03/04(金) 14:28:53.98ID:???参考書とかではフィールドだけど、ネットではカラムが多い気がする
0466NAME IS NULL
2016/03/04(金) 17:14:02.24ID:???大抵のDBだとadd columnだから、カラムでいいんじゃないの
0467NAME IS NULL
2016/03/04(金) 23:32:18.28ID:???DB設計の入門書
を教えて
0468NAME IS NULL
2016/03/04(金) 23:45:00.64ID:???ってのがググった中で一番多く話題になってた
だが、俺的には物足りないけど。
0469NAME IS NULL
2016/03/04(金) 23:50:46.45ID:???ありがとう
0470NAME IS NULL
2016/03/05(土) 00:37:42.64ID:???0471NAME IS NULL
2016/03/06(日) 19:00:38.67ID:???漢の人の本なんかいいんじゃないか
0472NAME IS NULL
2016/03/07(月) 18:35:04.56ID:???それ入門書じゃない
0473NAME IS NULL
2016/03/07(月) 19:28:51.24ID:???技評の本は、入門と書いてあっても、中身は初心者を寄せ付けませんw
聞いた話によると、著者の考えたタイトルは大抵ボツになるそうで、出版社からは入門と付けられてしまうらしい。
タイトルに入門と書いてあるだけで、1割から2割売り上げ伸びるとのことだよ
0474NAME IS NULL
2016/03/08(火) 14:26:04.36ID:???入門や初心者本って類似品が多いから、あまり売れないと思ってたよ
0475NAME IS NULL
2016/03/08(火) 18:05:30.81ID:???0476NAME IS NULL
2016/03/08(火) 18:08:46.53ID:???読んでないけど
0477NAME IS NULL
2016/03/08(火) 21:19:35.54ID:???0478NAME IS NULL
2016/03/08(火) 21:58:40.81ID:???0479NAME IS NULL
2016/03/08(火) 23:46:11.91ID:???DBマガジン
0480NAME IS NULL
2016/03/09(水) 00:12:49.02ID:Vr1C3X/70481NAME IS NULL
2016/03/09(水) 03:23:17.54ID:???0482NAME IS NULL
2016/03/11(金) 18:38:46.40ID:???0483NAME IS NULL
2016/03/22(火) 18:15:13.55ID:???自然キーを使う場合（で、基本的にコードがキーになる場合）、
table_a: {a_code(PK), ...}
table_b: {a_code(PK), b_code(PK), ...}
table_c: {a_code(PK), b_code(PK), c_code(PK), ...}
みたいなことになることが多いと思うんですが、
* それはそういうものだからそうしろ
* それはお前の勘違い
のどちらなんでしょうか。
0484NAME IS NULL
2016/03/22(火) 21:03:42.87ID:???自然キーなら複合キーになる事が多いって事？
ならそれはそういうものだろう
0485NAME IS NULL
2016/03/22(火) 21:28:25.21ID:???RDB設計からKVS設計は色々違和感あるな
RDBだけでゴミ設計なんて数多くあるけど
0486NAME IS NULL
2016/03/22(火) 22:50:55.78ID:XCbF2FrfDBAも勉強しないやつらばかりだし。
0487NAME IS NULL
2016/03/23(水) 11:05:10.59ID:???> 何が聞きたいのかわからない
> 自然キーなら複合キーになる事が多いって事？
うーん、多いか少ないかが疑問なのではなく、多くなっても親テーブル（というと語弊があるかも）の主キーを
引きずって子テーブルを作るのが普通なのかなというのが疑問です。
table_cが何かの要求で、それに対する結果テーブルが必要なとき、
table_c: {a_code(PK), b_code(PK), c_code(PK), some_column(PK), ...}
とやっていくと、どんどん主キーカラムが増えてくんです。
そういうのは普通なんでしょうか。
それとも何か他の手段があるんでしょうか。
0488NAME IS NULL
2016/03/23(水) 11:23:32.20ID:???よくわからん、、、もうちょっと具体的な例を・・・
0489NAME IS NULL
2016/03/23(水) 12:34:09.70ID:wWOU9ETa自然キーてそういうもん
回避策とか考えるとそれは必然的に代理キーになる
面倒くさいのは混在してるDBだな
0490NAME IS NULL
2016/03/23(水) 13:09:26.97ID:???例えば、路線があって（既に路線コード="0001"〜が割り振られている）、路線上に測定点（既に路線毎に
"0001"〜が割り振られている）があるとき、
路線: {路線コード(PK), ...}
測定点: {路線コード(PK), 測定点コード(PK), ...}
これにたいして、測定の発注があり（路線と測定点を選択する）、
測定発注: {発注コード(PK), ...}
発注測定点: {発注コード(PK), 路線コード(PK), 測定点コード(PK), ...}
測定は複数あり
測定: {測定コード(PK), ...}
発注測定点ごとに複数の測定を行い
発注測定点測定: {発注コード(PK), 路線コード(PK), 測定点コード(PK), 測定コード(PK), ...}
発注測定点測定ごとに結果があるとき、
測定結果: {発注コード(PK), 路線コード(PK), 測定点コード(PK), 測定コード(PK), ...}
みたいな設計を自分ならすると思うんですが、何か間違ってるきがするんです。
0491NAME IS NULL
2016/03/23(水) 13:18:58.64ID:???> 回避策とか考えるとそれは必然的に代理キーになる
本とかブログとか見ると、代理キーは使うなという人が多くて、使うのに躊躇しています。
0492NAME IS NULL
2016/03/23(水) 13:26:04.68ID:???俺ならサロゲートキーを使うな
0493NAME IS NULL
2016/03/23(水) 15:51:20.96ID:???その例、完全に想像上の産物なのか、過去のプロジェクトあつかったものなのか、これから作る
プロジェクトのものなのかわからないけど、「路線廃止」とか「測定点廃止」のこと考えとかないと
死ぬよ。
0494NAME IS NULL
2016/03/23(水) 16:22:34.40ID:???0495NAME IS NULL
2016/03/23(水) 16:39:01.58ID:???削除フラグの要否について語るスレ [転載禁止](c)2ch.net
http://echo.2ch.net/test/read.cgi/db/1445137179/
0496NAME IS NULL
2016/03/23(水) 17:06:32.33ID:???・住所 not null
・店名 not null
・タイプ（たこ焼き屋、焼き鳥屋、飲み屋、バーなどいくつも増やしていく予定） not null
・軽度と緯度 not null
・HP
こういう場合いつもなら1テーブルに全てのカラムを突っ込んで作ってたんですが、
先輩方ならテーブルとカラムをどのように作るのかアドバイスをください
0497NAME IS NULL
2016/03/23(水) 17:18:17.03ID:???いつ行ったかはいらんの？
0498NAME IS NULL
2016/03/23(水) 17:18:50.32ID:???1テーブルでいいと思うよ。
0499NAME IS NULL
2016/03/23(水) 17:29:20.40ID:???仮にそれを管理するなら別テーブルにすべきだと思うが、ただそれはデータベース設計の話ではなく要件定義の話なのでスレ違いだ。
0500NAME IS NULL
2016/03/23(水) 17:29:59.13ID:???0501NAME IS NULL
2016/03/23(水) 17:30:13.66ID:???正 >>497
0502NAME IS NULL
2016/03/23(水) 17:31:30.25ID:O0URZ4Cwタイプをマスタテーブルとして分離するくらいだな。
0503NAME IS NULL
2016/03/23(水) 18:35:44.07ID:???単に行った店を管理するだけならそれでいいと思う
まあ、Excel でもいいと思うが...
何を食べたとか、値段とか、うまかったとかの情報は要らんの？
0504NAME IS NULL
2016/03/23(水) 18:41:50.83ID:???0505NAME IS NULL
2016/03/23(水) 19:06:57.72ID:???公開すれば意外と需要があるかもw
0506NAME IS NULL
2016/03/23(水) 19:44:53.38ID:???おれはgooglemapで管理してる
0507NAME IS NULL
2016/03/23(水) 20:15:01.68ID:Y1xGecwA安倍首相がスタンフォード大前で「嘘つき安倍は帰れ！」と抗議を受ける
https://www.youtube.com/watch?v=HkMjwggu3ko
安倍総理、麻生副総理も経歴詐称？ 海外留学の経歴が削除されていた！ 「学歴詐称」は公職選挙法違反
【日本の金正恩】 安倍寛信 【安倍晋三の兄】
復活した電力会社の原発広告に文化人や芸能人がまたぞろ登場して原発をPR！ 500万円の高額ギャラも 勝間和代 三橋貴明 佐藤優
三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信 三菱重工の重役でもあるらしい
これがフクイチで核弾頭ミサイルを製造していた疑惑がある 書けばツイッターで速攻削除されている
ネットにおける言論統制は、非公然で陰湿に進んでいるようです
https://twitter.com/toka iamada/status/664017453324726272
山本太郎
先ず真のテロリズムと戦うべき！
汚染物質をバラ撒き、国民を無理心中へと巻き込む政治家、経済団体等をテロ指定、資産凍結するのが筋ではないか！
【だってお金欲しいもん〜】
今朝、辺野古で新基地建設に反対するママの会メンバーに対して、
機動隊員が「お前たちには汚い血が流れている」などと暴言を吐いたそうです。
自分のやっていることを「だってお金欲しいもん〜」「俺の写真を待ち受けにしろ」とも （顔写真）
https://twitter.com/MothersNoWar/status/690357793702940672
0508NAME IS NULL
2016/03/23(水) 22:58:13.79ID:???0509NAME IS NULL
2016/03/23(水) 23:04:16.77ID:???GoogleMapのURL入れたいな
0510NAME IS NULL
2016/03/23(水) 23:07:43.81ID:MmqjKcCk正規化なんて分かってないやつがすぐ言う言葉だよな。
0511NAME IS NULL
2016/03/23(水) 23:37:41.32ID:???0512NAME IS NULL
2016/03/24(木) 02:16:58.69ID:???この板全然機能してないね
はてMongoの話したかったんだけどどうしたものか・・・
0513NAME IS NULL
2016/03/24(木) 05:40:54.55ID:???Mongoいいよな
RDB脳でも直感的に使える
でもKVSの主流からは外れてる感じが凄いんだよねぇ
0514NAME IS NULL
2016/03/24(木) 09:12:45.32ID:???SQLアンチパターンにあったな
31フレーバーだっけ
0515NAME IS NULL
2016/03/31(木) 14:37:59.15ID:???実際やって一番腕上がったなって実感できたことって何だった？
0516NAME IS NULL
2016/03/31(木) 14:44:49.22ID:dIu8YOjZ新人って新卒のことか？
0517NAME IS NULL
2016/03/31(木) 14:50:57.70ID:???0518NAME IS NULL
2016/03/31(木) 15:52:43.00ID:???本にもテーマになること多いし。
0519NAME IS NULL
2016/03/31(木) 15:59:52.39ID:???0520NAME IS NULL
2016/03/31(木) 16:05:47.51ID:???0521NAME IS NULL
2016/03/31(木) 16:06:44.99ID:dIu8YOjZ0522NAME IS NULL
2016/03/31(木) 16:08:10.83ID:dIu8YOjZ0523NAME IS NULL
2016/03/31(木) 16:44:55.85ID:???0524NAME IS NULL
2016/03/31(木) 16:45:37.23ID:???0525NAME IS NULL
2016/03/31(木) 20:30:43.54ID:VSMU+gxH素直に自分が勉強したいから教えてくださいって言えよw
0526NAME IS NULL
2016/03/31(木) 22:16:18.82ID:???それより課題与えて目に見える形で学ばせる方が身につく
0527NAME IS NULL
2016/03/31(木) 22:20:53.58ID:???自分で考えて作らせてみる
懇切丁寧に説明して作らせてみる
諦める
0528NAME IS NULL
2016/03/31(木) 22:26:28.98ID:???0529NAME IS NULL
2016/03/31(木) 22:41:09.13ID:???うちなんて新人教育前面に押し出してるけど全部俺に押し付けるだけだし
0530NAME IS NULL
2016/03/31(木) 22:49:48.48ID:???ご苦労様
0531NAME IS NULL
2016/04/03(日) 13:06:44.15ID:???0532NAME IS NULL
2016/04/03(日) 14:14:33.18ID:???0533NAME IS NULL
2016/04/03(日) 17:05:36.60ID:???前に海外サイトであった気がするけど、だいぶ前に更新止まってた
0534NAME IS NULL
2016/04/03(日) 17:35:42.91ID:fk/TJrkcない。
オブジェクト指向設計と同じようにクラスをテーブルに見立てて、意味のある単位で項目をまとめて、リレーションを作る。
正解がないので基本的にはいろんなシステムを見ていないと難しい。
0535NAME IS NULL
2016/04/03(日) 17:49:09.59ID:???0536NAME IS NULL
2016/04/03(日) 18:59:07.39ID:???YES → 【ヒットした？】 ─ YES → なら聞くなよ。死ね。
／ ＼
【検索した？】 NO → なら、ねぇよ。死ね。
＼
NO → 死ね。
0537NAME IS NULL
2016/04/03(日) 19:04:02.42ID:???0538NAME IS NULL
2016/04/03(日) 20:29:45.86ID:wqLTVuK2運用・保守を考えると冗長的にデータを持っていた方がいい。
データ量が多くなることをおそれるな。
重複したデータを別に持っていてもいい。
無理に外部キー制約を作るな。
リレーションにこだわるな。
0539NAME IS NULL
2016/04/03(日) 20:31:48.19ID:wqLTVuK20540NAME IS NULL
2016/04/03(日) 20:42:38.94ID:DppsG1GM運用・保守を考えると冗長なデータは将来の破綻を持たらす
データ量の増加は即座にあらゆるコストの増加に直結する
重複した…事はもう言わん
たった一つの外部キーが将来の重大な事故を防ぐかもしれない
リレーションにこだ…わる……な？？？何のこっちゃそりゃwww
0541NAME IS NULL
2016/04/03(日) 20:56:19.37ID:wqLTVuK2こういうのばっかりだからおかしなことになる。
0542NAME IS NULL
2016/04/03(日) 20:56:34.01ID:???学生ならいいんだけど、どうも耳年増の学生って感じでもない
まともな教育受けられなかったんだなぁって亀田兄弟見てるのに近い感じで可哀想
0543NAME IS NULL
2016/04/03(日) 20:57:32.35ID:wqLTVuK20544NAME IS NULL
2016/04/03(日) 21:01:19.48ID:wqLTVuK2謎の教科書通りに作って自己満足。
0545NAME IS NULL
2016/04/03(日) 21:06:48.45ID:???0546NAME IS NULL
2016/04/03(日) 21:13:58.70ID:DppsG1GMなあに〜おかしなことって〜ねえおせ〜てよ〜www
0547NAME IS NULL
2016/04/03(日) 21:29:58.26ID:wqLTVuK2冗長化するんじゃなくて、場合によっては冗長的な方がいい場合がある。
常に同期を取らなくてもいいんだよ。
システムがそういう設計なら。
同じデータに対して、別の目的で同時にアクセスされることがあるなら、まとめてしまわない方が、シンプルな設計のアプリケーションになる。
いろいろ書いてもいいけど、理解できないだろうからな。
0548NAME IS NULL
2016/04/03(日) 21:46:35.23ID:???0549NAME IS NULL
2016/04/03(日) 21:46:43.49ID:???0550NAME IS NULL
2016/04/03(日) 21:55:45.80ID:???簡単に説明できない設計は根本からおかしい
0551NAME IS NULL
2016/04/03(日) 22:04:14.52ID:DppsG1GM0552NAME IS NULL
2016/04/04(月) 12:26:39.46ID:???夜間バッチとかの話？
0553NAME IS NULL
2016/04/04(月) 14:50:31.67ID:???いちいち読み込まなくていいから効率が良いってことですか？
そこで使うデータはそこで準備しとけば重複してもいいじゃんって感じでやっちゃって構わないってこと？
0554NAME IS NULL
2016/04/04(月) 18:09:56.03ID:???好きにやれや
0555NAME IS NULL
2016/04/05(火) 12:48:00.20ID:???一つ確実なのは
よくわからない状態なら >>547 みたいな意見は無視した方がいい
ってこと
0556NAME IS NULL
2016/04/05(火) 12:50:09.36ID:AGJq+Z7+0557NAME IS NULL
2016/04/05(火) 13:27:50.03ID:???0558NAME IS NULL
2016/04/05(火) 14:22:24.13ID:???極めて限定された特殊な状況を、さも一般的な事ととらえてる可能性もある
わかって言ってるなら詭弁なんだろうけど、マジで信じてる人はどうすればいいんだろうなぁ
まあなんにせよ冗長化と冗長的の違いは俺には理解できないが
0559NAME IS NULL
2016/04/05(火) 15:48:21.86ID:???> いろいろ書いてもいいけど、理解できないだろうからな。
つか、既に書かれてることすら、俺らには理解できないんですが。
0560NAME IS NULL
2016/04/05(火) 16:25:55.52ID:???マジならこわい
0561NAME IS NULL
2016/04/05(火) 18:04:58.42ID:???0562NAME IS NULL
2016/04/05(火) 18:13:32.04ID:???単に相手にしなければいいだけ。
0563NAME IS NULL
2016/04/05(火) 19:27:49.35ID:???いろいろ書いてもらわないことには判断できないし、機会があれば書いてくれるんじゃないのかな。
0564NAME IS NULL
2016/04/06(水) 00:28:32.06ID:???0565NAME IS NULL
2016/04/06(水) 00:31:50.97ID:???DBに限った話ではないさ
0566NAME IS NULL
2016/04/06(水) 03:04:46.34ID:???0567NAME IS NULL
2016/04/06(水) 10:24:43.86ID:???× 知識ないやつ
○ 知識があると勘違いし、なおかつ他人を馬鹿にする奴
だから叩かれるんだよ。
0568NAME IS NULL
2016/04/06(水) 12:56:09.85ID:???自分のレスがいつもバカに目をつけられて叩かれると感じるなら
自分のレスに問題がないかも考えた方がいい
0569NAME IS NULL
2016/04/06(水) 13:23:24.27ID:???2ch以外のQ&Aサイト知らないのかな？
一度行ってみ？
神だらけで腰ぬかすぞ
0570NAME IS NULL
2016/04/06(水) 13:27:19.49ID:???プログラマー専門のサイトも利用したけど、的中回答がなかったよ。
知恵袋やOKウェイブ全然レベル低いじゃん。
ここで降臨した神は、一撃で的中だよ。だから2chは消えてないんだよ。
ここの中にとんでもない人がいるたから。今もいるか知らないけど。感謝しかない。
他の人達は自分で調べろ、外で聞け。基礎からやり直し！と罵倒してきた。
ピンポイントで局所的にどうしてもわからない箇所が、素人レベルの人には多いよ。
そこを的確に教えてくれるって神だから。
0571NAME IS NULL
2016/04/06(水) 13:30:42.82ID:???0572NAME IS NULL
2016/04/06(水) 14:24:42.59ID:???Q&Aサイトの探し方もわからんのか（罵倒
0573NAME IS NULL
2016/04/06(水) 14:27:41.32ID:???> 他の人達は自分で調べろ、外で聞け。基礎からやり直し！と罵倒してきた。
山のようにあるQA系スレが、そのような内容で埋まってないのはなぜなのか、
ちょっと考えてみるといい。
まさに>>568だな。
0574NAME IS NULL
2016/04/06(水) 14:35:44.64ID:???> ピンポイントで局所的にどうしてもわからない箇所が、素人レベルの人には多いよ。
違うね。
素人レベルで多いのは、以下のパターン。
「hogeがわからないんですが・・・」
→は？なんでhogeしたいの？
→hogeってどういうこと？もっと詳しく教えて
→hogeとかねーよ
→日本語でOK
「知らない人は黙っててください」
「hogeがわからないんですが・・・」
→は？なんでhogeしたいの？
（以下何回かのやりとり）
「Aを実現するためにhogeしようとしてるんですが・・・」
→それを先に言えよ。Aならhogeじゃ駄目だ
「hogeがわからないんですが・・・」
→自分で調べろ糞が
0575NAME IS NULL
2016/04/06(水) 14:43:47.83ID:???「ここ」ってDB設計スレのこと？
> 他の人達は自分で調べろ、外で聞け。基礎からやり直し！と罵倒してきた。
他のスレだとそんなことめったに起こらんが。例えば、
SQL質疑応答スレ 16問目 [転載禁止](c)2ch.net
http://echo.2ch.net/test/read.cgi/db/1447160858/
DB設計スレ限定の話だと、しったかな奴が時々いついちゃうから荒れやすいかもな。
0576NAME IS NULL
2016/04/06(水) 14:48:11.55ID:???→なんでエラーメッセージ貼らないの
「（エラーメッセージを貼る）」
→そのエラーメッセージをググったら、トップがその解決方法じゃねーか！
0577NAME IS NULL
2016/04/06(水) 14:59:41.24ID:???ごめん質問して神様降臨したのそっちだね。
本当に感謝しております。DB楽しいです！
0578NAME IS NULL
2016/04/06(水) 15:53:54.54ID:???0579NAME IS NULL
2016/04/06(水) 16:36:02.44ID:???> ここで降臨した神は、一撃で的中だよ。だから2chは消えてないんだよ。
君にレスしたその人以外の、普通に回答してる人たちをおとしめてるという自覚はあるのかね。
0580NAME IS NULL
2016/04/06(水) 17:44:08.84ID:???初めから回答が決まってるなら議論の余地がないだろ
0581NAME IS NULL
2016/04/06(水) 22:59:38.81ID:bOn0CikI0582NAME IS NULL
2016/04/06(水) 23:01:01.44ID:bOn0CikIそっちにもこっちにも書いてますが？
0583NAME IS NULL
2016/04/06(水) 23:09:12.54ID:bOn0CikIしかもいろんな立場から見た場合、こうすべきと言われていることが必ずもいいわけではない。
閉じたシステム、止められるシステム、使ってる人が少ないシステムならガチガチのRDB理論でやっても問題ないけど、そんなチンケなシステムなら、そもそもDB設計なんてむしろ適当でもいいんだよ。
0584NAME IS NULL
2016/04/06(水) 23:30:25.55ID:Kgoj/5an批判ばかりで中身のない代表がお前なのだが…
大体システムなんてのは規模が大きくなるほど多くの制約を設けなければ制御しきれなくなる
お前の言ってる事は「制御しきれなくなったからとりあえず場当たり的にやっちゃえば簡単じゃん」て事中にはそれで妥協してしまう人間もいるが広く普遍的に受け入れられる考えではない
0585NAME IS NULL
2016/04/06(水) 23:34:37.39ID:bOn0CikIそれこそ閉じたシステムのことだろ。
0586NAME IS NULL
2016/04/06(水) 23:47:16.16ID:Kgoj/5anそれこそって何のことだよ？
大体お前は何をもって「閉じたシステム」と言ってるのだ？
「閉じたシステム」でないシステムに理論が通用しないと考えるのはなぜだ？
やっぱり中身がないふわふわ君だなお前
0587NAME IS NULL
2016/04/06(水) 23:50:04.38ID:bOn0CikIデータを直したことないのかな？
0588NAME IS NULL
2016/04/06(水) 23:51:30.52ID:bOn0CikI0589NAME IS NULL
2016/04/06(水) 23:55:29.07ID:Kgoj/5anいきなり話飛んでるし…
自分の考えを喧伝したかったら少しは考えて話せよふわふわ君
お前相手じゃ議論にもならんわ
0590NAME IS NULL
2016/04/06(水) 23:58:15.14ID:bOn0CikI批判ばかりw
自分に言われていると思ってるやつって何なの？
0591NAME IS NULL
2016/04/07(木) 00:12:41.09ID:???0592NAME IS NULL
2016/04/07(木) 04:58:55.98ID:???もしかして、データの手メンテをデータの運用だと考えている奴がいるのだろうか
そりゃそんな運用を考えてるなら設計が多少適当でも良いだろうな
時々、大規模になるほど、制約を緩くするべきだって主張する奴がいるけど
どういう経験をしたらそう言う主張になるのか理解も想像もできんな
0593NAME IS NULL
2016/04/07(木) 05:20:50.91ID:???どんな質問だったの？
0594NAME IS NULL
2016/04/07(木) 05:29:31.57ID:???珍しく相手してくれてるんだからそう無碍にしてはいけないよ。
0595NAME IS NULL
2016/04/07(木) 08:18:25.00ID:???試験に出るかもしれないので覚えておくように
0596NAME IS NULL
2016/04/07(木) 10:39:50.17ID:???> 閉じたシステム、止められるシステム、使ってる人が少ないシステムならガチガチのRDB理論でやっても問題ないけど、そんなチンケなシステムなら、そもそもDB設計なんてむしろ適当でもいいんだよ。
適当にやるより、過去のベストプラクティスに則って機械的に設計した方が工数も少なく、
性能上のリスクも少なく、運用工数も一般に抑えられると思うがね。
0597NAME IS NULL
2016/04/07(木) 11:06:23.08ID:???hoge_id text,
tags array[],
contents json
)
こういうテーブルが存在すると、このテーブルに関連するコードを書く奴全てが不幸になる。
システムの規模なんか関係ないよ。
0598NAME IS NULL
2016/04/07(木) 11:46:52.07ID:???0599NAME IS NULL
2016/04/07(木) 12:26:10.27ID:???これ、データ型に配列（それも可変）ってことですか？
0600NAME IS NULL
2016/04/07(木) 13:19:51.88ID:???滅多に使わないから間違えた。
tags array[]じゃなくてtags text[]だった。
> これ、データ型に配列（それも可変）ってことですか？
そう。
0601NAME IS NULL
2016/04/11(月) 11:59:37.13ID:???https://www.youtube.com/watch?v=BLj2H95-ITA0
0602NAME IS NULL
2016/04/11(月) 15:20:24.66ID:???SQLアンチパターンのジェイウォークですか？
0603NAME IS NULL
2016/04/11(月) 16:44:32.73ID:???0604NAME IS NULL
2016/04/11(月) 17:18:52.34ID:???に該当するかは議論の余地があるよね。
ジェイウォークのデメリットが適用される場合とされない場合がある。
0605NAME IS NULL
2016/04/17(日) 21:12:11.53ID:???複数の部署のシステムを開発する場合、データベースは部署ごとに分けますか？
それともシステム単位で分けますか？
環境はSQLServerです。
私は、社員マスタ等共通するものは分けて別DBとする。
後は部署ごとにDBファイルを分けてその部署に関するものは、
全部そのDB内にテーブルを作成しようかなと思っていたのですが、
部署の基幹となるシステムのテーブルと、ツール的なものに使用する簡易なテーブルとが
ごちゃごちゃになってしまいそうで、悩んでいます。
一般的に、どういう設計が好ましいのか、皆さんの意見をお聞かせ下さい。
よろしくお願いいたします。
0606NAME IS NULL
2016/04/17(日) 21:27:08.21ID:???システムの規模とか各部署の連携業務あるとかないとか解らないと…
0607NAME IS NULL
2016/04/17(日) 21:41:10.28ID:???すみません、全体としては全部署の業務管理システムのようなものでそこそこの規模になると思います。
商品等各部署で共通する商品もあれば、その部署だけで使用する商品等もあります
売り上げや、業務の進捗管理等連携する部分もそれなりにあるのですが、
一つのDBにまとめるとテーブル数も多くなり、繁雑になるのではないかと思ったのですが、
システム単位になるとツールの類等含めるとDBファイルの数も多くなり、
システム開発側が面倒になるのではないかと思い、一般的？というか
皆さんならどういう設計にするかを、お聞きしたいと思いました。
0608NAME IS NULL
2016/04/17(日) 22:06:37.48ID:???DB分けの必要性があるなら別だが、DB分けよりスキーマ分けのが運用はシンプルになると思う
設計部分は俺なら共通項をdbo.親として、部門別拡張を部門.子として定義で依存関係作ったりするかな
0609NAME IS NULL
2016/04/17(日) 22:09:13.52ID:qcQ5QTkR0610NAME IS NULL
2016/04/18(月) 11:47:39.53ID:???全部署の集計や部署間のやりとりするたびに、DB連携させるのか？
そっちの方が手間だぞ
一つのDBにしようが、複数DBにしようが、総テーブル数は変わらんだろ
むしろ完全な複数DBにすればDBごとに重複するテーブルが必要になるから
そっちの方がテーブルは増えるだろ
0611NAME IS NULL
2016/04/18(月) 13:19:03.60ID:???システム単位に分割したとき、例えば社員マスタの変更はどうやるかなどの問題がでてくるよ。
0612NAME IS NULL
2016/04/18(月) 15:01:10.79ID:???重複するから増えるとかは気にしなくていいんじゃない？
リンクサーバーまじめに使ったこと無いから問題なく運用できるのかどうかわからないけど。
とはいえ、そうそう分ける必要は無いんじゃないかと思うよ。
ダイアグラムとか活用するといい。
0613NAME IS NULL
2016/04/28(木) 12:17:57.44ID:???音楽のタイトル(文字列、unique、not null)
音楽の歌詞(文字列)
日付の管理は不要です
この場合どういうテーブル構造にしたらいいですか？
テーブル名:music
カラム:title,filename,lyric
こんな感じだとダメですか？正規化したほうがいいですか？
idなくてもいいと思ったんですがあったほうがいいですか？
0614NAME IS NULL
2016/04/28(木) 13:45:40.12ID:???ファイル名をPKにすればいいよ。
ちなみにタイトルはuniqueじゃないと思う。
0615NAME IS NULL
2016/04/29(金) 02:14:33.58ID:???それが正規化されてるかどうかすら判断できないわけで
その程度の説明なら、それでやってみればとしか言えないんじゃね
id付けるかどうかは、開発方法にもよるから何とも
なくてもいいと思ったんならそれでいいんじゃね
やっぱり必要だったと思ったらその時付ければ良いんじゃね
0616NAME IS NULL
2016/04/29(金) 03:15:06.26ID:/rx9RsqQ音楽のタイトルはかぶります。
0617NAME IS NULL
2016/04/29(金) 08:42:50.09ID:???0618フーテンの虎次郎
2016/04/29(金) 09:12:53.43ID:???0619NAME IS NULL
2016/04/29(金) 10:04:15.81ID:???0620NAME IS NULL
2016/04/29(金) 11:03:23.20ID:???0621NAME IS NULL
2016/04/29(金) 13:45:54.13ID:???0622NAME IS NULL
2016/04/29(金) 16:53:18.83ID:???0623NAME IS NULL
2016/05/10(火) 17:03:36.35ID:XkKxf3hC02.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
0624NAME IS NULL
2016/05/12(木) 05:26:11.67ID:HmbS4CfDhttp://echo.2ch.net/test/read.cgi/db/1462998353/
0625NAME IS NULL
2016/05/18(水) 21:20:19.94ID:???0626NAME IS NULL
2016/05/18(水) 22:18:05.74ID:/7EcImwJ0627NAME IS NULL
2016/05/18(水) 22:42:55.75ID:???逆数で教えてケロ
0628NAME IS NULL
2016/05/18(水) 22:50:17.37ID:???0629NAME IS NULL
2016/05/18(水) 23:15:48.29ID:/7EcImwJ0630NAME IS NULL
2016/05/18(水) 23:18:06.02ID:???は、は、張るんだな
0631NAME IS NULL
2016/05/19(木) 11:02:46.41ID:id6StyEG「あなたのような従業員は会社のパフォーマンスにとってマイナスなので早く死んでください」
などと自殺教唆を公然と行った！！
丁寧に言えば何を言ってもいいというものではない！！これはヤクザや借金取りが脅迫をする時に
「いついつまでに金一億円をお振り込みください。間違った判断をなされないことを期待しています」
と発言するのと同じレベルだ！！
「しかもそれを注意してやったら世間はわれわれの味方だ。文句があるなら訴えてきたらよろしい。メールを電番を公開したければ
どうぞご自由に。世論はわれわれを賛辞するするメールを送付するだろう」
などとイカ様気取りも大概にしろという発言を行った！！
抗議先 日本マイクロソフト人事本部 西川昌邦
[email protected]
090-2541-1718
0632NAME IS NULL
2016/06/09(木) 18:07:53.93ID:???0633NAME IS NULL
2016/06/14(火) 21:41:48.13ID:cHMlzAQxA）多言語分のカラムを作る
ja_title、en_title のように必要な言語用のカラムを全て用意する
B）言語選択カラムのみ追加して1つのテーブルで処理する
id｜type｜title
1 ｜ja ｜こんにちは
2 ｜en ｜hello
みたいなテーブル設計です。
C）テーブル自体を分ける
ja_profile、en_profile
みたいなテーブル名にします。ただ言語が増えるとテーブルも増えて大変だと思います。
おそらくBパターンが最適かと思いますが、
単一参照テーブルっぽくなるんじゃないかな？とも感じています。
よい設計の知恵があれば教えてください。よろしくお願いします。
0634NAME IS NULL
2016/06/14(火) 21:48:10.63ID:???0635NAME IS NULL
2016/06/14(火) 21:53:46.43ID:Y5TYhKNt「こんにちは」だけでいいならそれでもいいがw
0636NAME IS NULL
2016/06/14(火) 21:56:36.21ID:Y5TYhKNtそれでどうやって英語と日本語の対応が分かると思うのか？
0637NAME IS NULL
2016/06/14(火) 23:04:35.08ID:???A）が一番簡単そうだが。
0638NAME IS NULL
2016/06/14(火) 23:05:41.73ID:???0639NAME IS NULL
2016/06/14(火) 23:14:50.57ID:???UTF-8にしてれば大丈夫だと思ったが、そうでもないんだな
0640NAME IS NULL
2016/06/14(火) 23:32:29.70ID:???決められるわけないだろう。
0641NAME IS NULL
2016/06/15(水) 07:20:18.84ID:???そう割りきれば A) だな
本気で多言語やるなら B) 一択
0642NAME IS NULL
2016/06/15(水) 08:53:03.65ID:???sys.messages を参考にすると良いよ
0643NAME IS NULL
2016/06/15(水) 10:13:52.86ID:???単純にテーブル上のカラム×3にすると大変そうだな
Bのだと文字コード関係の問題がありそうだし、
ここは単純にデータベース自体分けるのが得策か？
0644NAME IS NULL
2016/06/15(水) 17:55:07.17ID:???文字列すべてにID振って、言語コード+IDで文字列を引っ張るリソース形式
検索を考慮しないならこれが一番じゃね
0645633
2016/06/16(木) 09:31:34.91ID:???特別、ベターな方法ってないんですかね
最近は多言語化サイトが求められてるし、システム開発でも必要だと思うのですが、
DB設計をどうするかの情報ってほぼ無いので悩みます。
もう少し考えてみます。ご意見ありがとうございました。
0646NAME IS NULL
2016/06/16(木) 20:30:55.45ID:???> DB設計をどうするかの情報ってほぼ無いので悩みます。
本でもサイトでもいくらでもあるだろ
どんな要件にも対応できる魔法の設計方法を知りたいとかなら知らんけど
0647NAME IS NULL
2016/06/16(木) 20:52:52.04ID:6DGXXQo50648NAME IS NULL
2016/06/16(木) 22:03:09.66ID:???多言語化に対するDB設計の基本って本に書かれてます？
書かれてるのをご存知なら教えてください。
「達人に学ぶDB設計 徹底指南書」やら「グラス片手にデータベース設計」やら
売れてるのは持ってるのですが、全て把握してないので
いくらでもあるのでしたら見てみます。よろしくお願いします。
0649NAME IS NULL
2016/06/16(木) 22:45:35.13ID:WYhuCtJzHelloとこんにちはを関連付けたいなら1レコードで持てよ。
ただ画面の項目名なら画面単位のレコードにするとかしろよ。
要件がなければ応えようがない。
0650NAME IS NULL
2016/06/16(木) 22:48:39.70ID:???だから要件書けよ
言語の数とかレコード数とかメッセージで検索するのかとか
0651NAME IS NULL
2016/06/16(木) 22:50:13.29ID:???これ>>633だけじゃ駄目なんですか？
0652NAME IS NULL
2016/06/16(木) 22:53:44.91ID:???別に答えや設計を代わりに考えてくれという質問じゃなくて、
「私は3パターン考えましたけど、皆さんはどうしてますか？」という相談なのですが。
要件次第や状況によって変わる、ってお話なら無限に話が広がるので、
>>633で例を出して、「どう思いますか？」と言った問いかけなのですが
0653NAME IS NULL
2016/06/16(木) 22:57:38.78ID:???１データが複数言語で定義されるのかか言語間で関係ないのかとか
色々前提足らんよ
0654NAME IS NULL
2016/06/16(木) 23:11:07.65ID:???分かりました。
では、サイト上にお知らせを表示するためのDBとします。
○多言語化前の構成
テーブル名：news
フィールド名：id、title、body、date
○条件
・1つのお知らせに対して同じ内容の複数言語を登録させたい
・URLで表示する言語を切り替え（つまり、英語ページなら英語のデータのみ表示）
・複数言語にまたがって検索する事はない
・英語、中国語、韓国語、フランス語、スペイン語を登録する可能性あり
こういうのでいかがでしょうか？
0655NAME IS NULL
2016/06/16(木) 23:13:29.71ID:???人の話を聞けよ...
0656NAME IS NULL
2016/06/16(木) 23:28:44.20ID:WYhuCtJz「お知らせ」って何？
0657NAME IS NULL
2016/06/16(木) 23:40:16.29ID:???DB化必須ならbで十分じゃね？
俺ならお知らせだし検索不要として
html書かせて有効管理だけするかな
0658NAME IS NULL
2016/06/17(金) 04:36:26.99ID:???単一の言語でなら検索するの？
その言語ってのは指定の言語一つだけなの？すべての言語なの？
何を検索して、何を得たいの？
0659NAME IS NULL
2016/06/17(金) 11:42:05.64ID:???他の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 行)
0660NAME IS NULL
2016/06/17(金) 11:42:35.72ID:???0661NAME IS NULL
2016/06/17(金) 12:58:05.69ID:???過去のお知らせとか検索できたら良いなって思いまして。
複数言語にまたいで検索はないですね。それだとおかしくなると思うし。
>>659
MySQLも大丈夫ですね。基本的にUTF-8にしてると問題ないかと思います。
（問題ある言語もあるかも・・・
多言語化を勉強しているのは、なんかのニュースで見たのですが、
外国人が観光などで日本にきてサイトを見ても、日本語ばかりでよくわからないし、
英語版でも間違っている事が多くて困ってると言った話を聞いたからなんです。
また、東南アジアや欧州からの旅行者は英語読めない事もあるそうで、
英語版だけだと駄目で、多言語に対応する必要があるそうなんですね。
で、多言語化する場合のDB設計はどうなるんだろう？どうするんだろう？
と思ったのがきっかけです。
それでググッたり手持ちのDB設計の本を見ても具体的に書いてない。
>>646さんいわく、いくらでもあるそうなんで教えてほしいのですが。
0662NAME IS NULL
2016/06/17(金) 14:22:20.53ID:???だからな他のひとが言ってるようにデータベースで管理する必要もないかもしれない。
0663NAME IS NULL
2016/06/17(金) 14:23:16.22ID:qx3Jcvsl0664NAME IS NULL
2016/06/17(金) 15:46:58.69ID:???>>654はあくまで例ですよ。多言語化を勉強する上で要件出せって言われたので、
無理やり一般的な要件を想像して書いただけです。
それを「DB必要ない」と言われたら、勉強のしようがないじゃないですか。
>>663
いや、>>646さんが「いくらでもある」って言われてるので、
いくらでもある内のひとつを教えてほしいだけなんですが。
私のググり方が悪いだけかもしれないし。
0665NAME IS NULL
2016/06/17(金) 16:14:09.26ID:???だんだんうざくなってきてるぞ。
たとえば、「データベース 多言語対応 設計」でググると、1ページ目でいくつも見つかる気がするのだが。
0666NAME IS NULL
2016/06/17(金) 18:18:15.87ID:???0667NAME IS NULL
2016/06/17(金) 18:42:31.38ID:???0668NAME IS NULL
2016/06/17(金) 18:56:47.80ID:???それでググってみたんですけどねぇ・・。
うざいという事なので、これにて失礼します。
アドバイスいただいた方、ありがとうございました。
0669NAME IS NULL
2016/06/17(金) 19:01:09.02ID:???やり方をいくら教えても、それが理解出来ないで、ズバリそのものの答えを求める
ああ、ゆとり教育の弊害ってこれなのかと
0670NAME IS NULL
2016/06/17(金) 19:35:23.40ID:???絶対ググってねーだろ w
>>665 のワードでググったらトップにドンピシャの質問あって笑たわ
http://q.hatena.ne.jp/touch/1226110815
0671NAME IS NULL
2016/06/21(火) 16:51:51.76ID:???文字コードが一つであるという前提がついた今、
> TABLE単位で設定できるなら、あとで別の言語（TABLE）が増える可能性を見越して、「＠テーブル単位で増やす」が無難でしょう。
> 文字コードに依存するデータをbinary形式で格納し、そのFIELDの文字コードを別FIELDに格納する以下のような構造にすれば、「＠単純にフィールドを増やす」も可能でしょう。
のどちらかになるんだけど、それでよいと思ってるから「ドンピシャ」って思ってるんだよね。
>>668
bのままだと早々に言われているように、
> 1つのお知らせに対して同じ内容の複数言語を登録させたい
という意図を表現できていない。
そのあたりも見越したフォローは >>642 で早々に出ている。
ただ >>639 が気がかり。
0672NAME IS NULL
2016/06/21(火) 16:54:50.00ID:???0673NAME IS NULL
2016/06/21(火) 19:54:26.59ID:???ドンピシャの「質問」って言ってるだけで回答には触れてないけど...
人の話をあまり聞かないタイプなのかな？
0674NAME IS NULL
2016/06/22(水) 02:41:14.18ID:???というつもりでリンクを貼ったのかと思ったけど、そういう言葉が出てくることもないんだね。
0675NAME IS NULL
2016/06/22(水) 08:39:48.31ID:???って書いてあるのにバカじゃね？
0676NAME IS NULL
2016/06/22(水) 09:22:54.60ID:R029ES8c0677NAME IS NULL
2016/06/22(水) 16:00:32.48ID:???0678NAME IS NULL
2016/06/22(水) 18:20:28.89ID:???0679NAME IS NULL
2016/06/22(水) 18:29:02.86ID:???> それでググってみたんですけどねぇ・・。
ですけど、なんなの？
というのが注目のまと
0680NAME IS NULL
2016/06/30(木) 01:00:17.12ID:kJxYJKSQ・沢山の人が、偏った意見を一貫して支持する
偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法
・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法
偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い
靖 国 参 拝、皇 族、国 旗 国 歌、神 社 神 道を嫌う カ ル ト
10人に一人は カ ル ト か 外 国 人
「ガ ス ラ イ テ ィ ン グ」 で 検 索 を ！
0681NAME IS NULL
2016/07/06(水) 17:23:17.91ID:???読んでて面白いスレだなここ
0682NAME IS NULL
2016/08/14(日) 10:55:58.28ID:???初心者におすすめの本ありませんか？
0683NAME IS NULL
2016/08/14(日) 19:38:03.94ID:???とりあえずいきなり作ったほうがいいよ。
その後から、基礎の本読むと入りやすいじゃん。
このスレの連中は、いきなり基礎を叩きこもうとしてくるから気をつけな！
0684NAME IS NULL
2016/09/22(木) 06:22:05.65ID:???バグ（Bugsテーブル）にも機能リクエスト（FeatureRequestsテーブル）にも
コメントをつけられるようにしたいから、Commentsテーブルにissue_type（Bugs or FeatureRequestsの値を取る）
を持たせておいて、それによって参照先テーブルを切り替えるというやつ。
これって単にBugCommentsテーブルとFeatureRequestCommentsテーブルに分けるという解決策じゃダメなのかね？
http://qiita.com/suguru/items/d6d3ebe7b867c5009231
0685NAME IS NULL
2016/09/23(金) 12:51:26.69ID:???0686NAME IS NULL
2016/09/23(金) 13:36:34.05ID:???0687NAME IS NULL
2016/09/23(金) 14:40:11.29ID:???「このDBMSつかえねーんだけど他にいいのある？」って聞けばいいよ
0688NAME IS NULL
2016/09/23(金) 14:43:04.74ID:???0689NAME IS NULL
2016/09/23(金) 20:12:34.26ID:???0690NAME IS NULL
2016/09/24(土) 01:03:48.09ID:???普通tagって多対多にしない？
1対多だと、既存のタグをリストアップするのにSELECT DISTINCTか何か必要になってしまうけど
http://qiita.com/mizunokura/items/a9be12e0eddcf5d90f07
0691NAME IS NULL
2016/09/26(月) 01:26:05.21ID:???そもそもデータベースが必要なのか
0692NAME IS NULL
2016/10/03(月) 12:26:01.82ID:???整数部が3桁、
小数部が10桁くらいの実数値をDBに入れる場合、
カラムは実数にすべきでしょうか？
文字列にすると何か問題ありますか？
0693NAME IS NULL
2016/10/03(月) 12:49:34.69ID:???その要件だけだと
好きにすればいい
としか言いようがない
0694NAME IS NULL
2016/10/03(月) 14:07:18.19ID:???それだけなら問題無いけど他要件次第というのはあります
0695NAME IS NULL
2016/10/03(月) 15:08:34.52ID:???連結すること多ければ文字列のがいいかもね
0696NAME IS NULL
2016/10/04(火) 07:21:41.02ID:???要件次第だけど整数部と小数部を別カラムでもいいかもね
0697NAME IS NULL
2016/10/04(火) 16:42:19.55ID:???なんで文字列にしたいの？
0698NAME IS NULL
2016/10/04(火) 23:11:46.49ID:???正規化の説明なんかは分かりやすいんだが(´・ω・`)
0699NAME IS NULL
2016/10/05(水) 02:35:55.02ID:???DB初心者で、文字列型しか使ったことが無いので。
0700NAME IS NULL
2016/10/05(水) 21:58:12.08ID:???0701NAME IS NULL
2016/10/06(木) 01:01:07.79ID:???varcharかtext型かをいつも悩むんだけど
0702NAME IS NULL
2016/10/06(木) 02:28:52.49ID:???varcharで行けるならtextなんて使わん
0703NAME IS NULL
2016/10/06(木) 08:01:45.35ID:???0704NAME IS NULL
2016/10/06(木) 09:44:02.29ID:???それならむしろ実数型使った方が良いと思うぞ
あえて数値を文字列で持つのは
ソート順やSQL上でのキャスト/変換など考慮出来る人がやるようなものだし
0705NAME IS NULL
2016/10/06(木) 11:57:31.94ID:???0706NAME IS NULL
2016/10/11(火) 22:38:04.15ID:???これくらい読んどけカスみたいなのがいいです
0707NAME IS NULL
2016/10/18(火) 04:46:29.28ID:???0708NAME IS NULL
2016/10/25(火) 11:03:57.85ID:sYfDHjNxAという会員とBという会員がいて、
Aが退会したら、会員Bのメッセージボードには「退会した会員」とだけ表示します。
この仕様について相談ですが、
この条件ですと会員Bは「誰にメッセージを送ったかわからない」問題があります。
もう退会した会員なので良いかもしれませんが、少々気持ち悪いかもしれません。
じゃ、メッセージ送信した時点での名前を保存するとします。
しかし、名前の編集ができる仕様なので、別名にされると困ります。
どのような設計にすれば上記の問題を解消できるのでしょうか？
汎用的なやり方・考え方を教えてください。よろしくお願い致します。
0709NAME IS NULL
2016/10/25(火) 11:11:18.21ID:???id：（ID）pk
user_id：（会員ID）fk
subject：（送信者）
body：（本文）
datetime：（送信日時）
checked：（確認した日時）
status：（ステータス。表示・非表示）
0710NAME IS NULL
2016/10/25(火) 11:13:45.43ID:???id：（ID）pk
user_id：（送信した会員ID）fk
user_to_id：（送信先の会員ID）fk
subject：（送信者）
body：（本文）
datetime：（送信日時）
checked：（確認した日時）
status：（ステータス。表示・非表示）
0711NAME IS NULL
2016/10/25(火) 11:15:59.89ID:???退会した会員の名前が再利用可能かどうかで
0712708
2016/10/25(火) 11:24:39.18ID:???再利用可能というのは、
会員Aの山田太郎さんが会員情報編集ページで、「山下太郎」にし、
また編集して「佐藤太郎にし」、やっぱり戻したいので「山田太郎」
とした時に、「山田太郎には出来ない」という意味でしょうか？
そうであればそこまで考えていません。自由に名前の編集が出来るのを想定しています。
0713NAME IS NULL
2016/10/25(火) 11:35:42.17ID:???同じ名前が複数存在する場合も、当然発生しますよね
自分がメッセージを送った相手が、間違いなくその人であるって
送信者はどうやって判断しますか？
0715NAME IS NULL
2016/10/25(火) 12:53:55.16ID:???退会したかどうかなんて退会日時を記録しときゃいいだろ
「退会した会員」表示だって
なんでその表示だけで済ますんだよ？
相手名表示＋「退会した会員」表記でいいじゃんか
0716NAME IS NULL
2016/10/25(火) 13:01:17.28ID:???・user_idはシステムの生存期間を通してユニークにする（一度使われたuser_idは使えない）
・user_idの変更は不可
・氏名は変更可能（システム内で重複可能）
・よってユーザーを一意に決定するのはuser_idのみ
・ユーザーが退会してもuserレコードは削除しない
・あるいはuser_archiveテーブルに移動する
・退会したユーザの氏名を表示するかどうかは要件次第
0717708
2016/10/25(火) 13:09:16.55ID:???なるほど。
・ユーザーが退会してもuserレコードは削除しない
・あるいはuser_archiveテーブルに移動する
これは良いですね。前者が削除フラグで後者が履歴テーブルですね。
退会した会員にはメッセージを送れなくするだけなので、
「山田太郎（退会済み）」とすれば足りると思います。
とすれば、
message、user、user_archiveの3つのテーブルを結合する必要がありそうですね。
0718NAME IS NULL
2016/10/25(火) 16:46:14.29ID:???あるいは715の退会日時の有無で判定とか
結合が気になるならテーブルを増やさなくても良いかと
0719708
2016/10/25(火) 17:45:45.82ID:???userテーブルを716さんの意見を踏まえて以下のようにしたとします。
id：（ID）pk
name：（名前）
email：（メールアドレス、ログインでも使用）
password：（パスワード）
status：（ステータス、有効｜停止｜退会）
created：（登録日時）
modified：（更新日時）
deleted：（退会日時）
これで思ったのですが、退会日時って必要ですかね？
システム的に更新したらmodifiedが変わるようになっているのですが、
statusを退会にした時は更新日時が上書きされるから、それで良いと思うのですが。
管理画面でstatusを変える場合も日付が更新されるわけですし。
0720NAME IS NULL
2016/10/25(火) 20:03:51.47ID:???status で退会示すなら deleted は見なくてもいい
0722NAME IS NULL
2016/10/26(水) 00:23:37.47ID:???名前自由に変えられるなら、Aさんが実は退会してなくて名前変えただけなのに、Bさんは「Aがいなくなって知らない人に送ってる、誤送信？システム障害？」ってならんかな
上で書いてる、送信時の名前を保存する案は上手くはないけどそういうことじゃないの、って思った
0723NAME IS NULL
2016/10/26(水) 01:03:56.97ID:???複数が拠点あって、マスター登録をどこでもして、
サーバー経由して他の拠点が作ったマスター受信したりする場合
ナチュラルキーじゃねえと色々無理出るよね。
必ずサーバーにしか作成しないってなら大丈夫だけど。
0724NAME IS NULL
2016/10/26(水) 01:22:59.54ID:???0725NAME IS NULL
2016/10/26(水) 01:49:43.50ID:???例えば部門マスタ。
ナチュラルキー部門コードのものをプライマリキーとせず
ユニーク制約だけにしておき、
自動インクリメントをプライマリキーで各店で作らせると
拠点A、ID:5 部門コード:ABC001 部門名:ABCあ
拠点B、ID:13 部門コード:ABC001 部門名:ABCい
拠点C、ID:54 部門コード:ABC001 部門名:ABCう
とかなるような場合。
これをサーバーに登録させ、それを受信することが難しい。
拠点Aで登録したものを最初にサーバーに登録した場合
サーバーには「部門名:ABCあ」が登録される。
そのあと拠点Cが送信した場合、このレコードを更新したいが
IDではできないので結局ナチュラルキーですることになる。
しかし、それではそもそも変更が容易なために
サロゲートキーにしてたのに
拠点ではナチュラルキーの変更ができなくなり、
サロゲートキーを使う意味がなくなる。
0726NAME IS NULL
2016/10/26(水) 04:21:35.16ID:???プライマリキーであるサロゲートキーが全拠点で一意になるように、拠点間で番号帯をわけたら解決するってんじゃないの？
SQLserverのレプリケーションならmsdnにそうしろって書いてるけど
0727NAME IS NULL
2016/10/26(水) 10:46:49.42ID:???俺の言ってる問題はそこではなく、
上の例がIDが10000ずつ振られていて
拠点A、ID:10015 部門コード:ABC001 部門名:ABCあ
拠点B、ID:20015 部門コード:ABC001 部門名:ABCあ
拠点C、ID:30015 部門コード:ABC001 部門名:ABCあ
とかの場合、サーバーに1レコードしか登録したくないわけだ。
このまま普通に登録したら3レコードそっくりなのが登録される。
それでは最新のものを使う場合、更新日付などのカラムが必要になる。
サーバーに1レコードにするにはサーバーのテーブルを
ナチュラルキーで判定せざるを得ない。
0728NAME IS NULL
2016/10/26(水) 11:15:20.73ID:???そういう仕組みだと、
> 拠点A、ID:10015 部門コード:ABC001 部門名:営業部
> 拠点B、ID:20015 部門コード:ABC001 部門名:企画部
> 拠点C、ID:30015 部門コード:ABC001 部門名:経理部
と登録されることだってありえるんだが、それはどう考えてるの？
0729NAME IS NULL
2016/10/26(水) 11:47:08.98ID:???一番最後に更新かけた所ので全拠点上書きする感じ。
部門・部門名は全拠点で共通認識。
商品コードとかの例のほうがよかったか。
0730NAME IS NULL
2016/10/26(水) 12:58:05.79ID:???なにをどう上書きするんだ？
拠点Cが最後に登録された場合、こうするのか？
update sections set id = 30015, 部門名 = '経理部' where 部門コード = 'ABC001'とするのか？
（これはPKが更新可能という意味でよろしくない）
> 拠点A、ID:10015 部門コード:ABC001 部門名:営業部
> 拠点C、ID:30015 部門コード:ABD001 部門名:営業部
と登録されていたらどうするんだ？
0731NAME IS NULL
2016/10/26(水) 13:03:45.20ID:???> 拠点A、部門コード:ABC001 部門名:営業部
> 拠点B、部門コード:ABC001 部門名:企画部
と登録される場合もあるし、
> 拠点A、部門コード:ABC001 部門名:営業部
> 拠点B、部門コード:ABD001 部門名:営業部
と登録されることもある。
0732NAME IS NULL
2016/10/26(水) 13:29:42.29ID:???0733NAME IS NULL
2016/10/26(水) 13:47:25.70ID:???SQLserverしか知らんが、あれのマージレプリケーションならできそうだけど、競合を検出したときのルール決めとアプリケーション側での対応が必要なんだよな
扱いきれそうにないし、そんな要件もなかったし使ったことないや
0734NAME IS NULL
2016/10/26(水) 13:58:24.61ID:???先勝ち（拠点Bの操作はユニーク制約違反で失敗）なのか
後勝ち（一テーブルにユニーク制約が複数あった場合、どれか一つでも違反したらその制約をキーにデリートインサート）か
0735NAME IS NULL
2016/10/26(水) 14:00:32.52ID:???拠点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の結論に至った。
×複数が拠点 ○複数の拠点
0736NAME IS NULL
2016/10/26(水) 14:09:54.54ID:???更新の波及はトランザクションレベルの即時レプリケーションで。
トランザクションデータはUUIDをサロゲートキーにした。
0737NAME IS NULL
2016/10/26(水) 14:14:04.43ID:???俺もそうするかな
マスタは好きに弄くらせたら統制とれんし
0738NAME IS NULL
2016/10/26(水) 19:50:24.60ID:???0739NAME IS NULL
2016/10/26(水) 20:59:23.11ID:???0740NAME IS NULL
2016/10/26(水) 23:17:54.55ID:???SELECTのみの履歴データのようなものはサロゲートキーで外に出せるってとこかね。
0741NAME IS NULL
2016/10/27(木) 01:12:31.18ID:???カメだけど買った
ありがとうございました
0742NAME IS NULL
2016/10/27(木) 08:37:02.74ID:???すでにあちこちにあるシステムを無理矢理統合してるとか言うならわかるけど新規でそんなシステム組んでたら単なるバカでしょ
> このようなケースでは全体として正しい方と
> 決められた方で最終更新をし上書きされる。
> このケースでは使わないコードのほうを削除フラグを立てさせ、
要するにどこかで人間の判断が入ってるんだろ？
登録時の手順をきちんと決めればいいだけのように気がする
まあ社内の力関係とかで無理って言う事情があるのかもしれないけど
>>739
だね
0743NAME IS NULL
2016/10/27(木) 10:25:18.20ID:oEDm5n89ネット障害やサーバー障害に強く、
単体として切り離して継続稼働もできるから断言はできない。
むしろパッケージなら普通な設計。
0744NAME IS NULL
2016/10/27(木) 12:50:25.56ID:???> ネット障害やサーバー障害に強く、
> 単体として切り離して継続稼働もできるから断言はできない。
そう言うのは >>736 のようにマスターの複製をローカルに持てばいいだけ
> むしろパッケージなら普通な設計。
どこの糞パッケージだよ
名前だしてみ
0745NAME IS NULL
2016/10/27(木) 13:10:31.58ID:???INSERT・UPDATE・DELETEは保存した方が良い気がしていますが、
どこまで保存するべきかで悩んでいます。
要件・規模によるでしょうが、一般的な考え方があれば教えてください。
0746NAME IS NULL
2016/10/27(木) 13:35:48.19ID:???分からんやつだな・・・黙っててくれると助かる。
根本的に論点が違うんだよ。
各拠点で登録更新は自由にできる前提の話だぞ。
かつ、そのデータを共有するってことで話してるのだ。
マスターの複製をローカルに持った所で、
障害中に新たに100件必要になったら
障害直るまで待つとか通らない世界の話ということだ。
0747NAME IS NULL
2016/10/27(木) 13:48:38.38ID:???横からだけど、それってつまり普通のシステムだと思うよ
0748NAME IS NULL
2016/10/27(木) 13:55:56.52ID:???要件・規模によるってのが一般的かと
証跡残すことは自分を守ることにも繋がるから残せるだけ残すのも手だよ
0749NAME IS NULL
2016/10/27(木) 17:58:32.12ID:???> 各拠点で登録更新は自由にできる前提の話だぞ。
> かつ、そのデータを共有するってことで話してるのだ。
だから、それが実現できてるパッケージって例えば何？
普通の設計なんだからいくつもあるんでしょ？
0750NAME IS NULL
2016/10/27(木) 18:17:51.00ID:???0751NAME IS NULL
2016/10/27(木) 18:32:16.75ID:???言い換えると承認されていないマスターデータを使って成果物を作成しないといけないということだよね。
そのローカルで登録したマスターデータは、後にサーバに接続して同期した時にrejectされる可能性もあるんだから。
なくはないと思うけど、一般的とは思えない。
0752NAME IS NULL
2016/10/27(木) 19:07:48.27ID:???できもしない要件請け負って結局運用回避って名目で現場が苦労するシステム作ってなにどや顔してるんだよ w
マスターを各拠点で自由に更新って聞いた時点で身構えるのが普通だよ
0753NAME IS NULL
2016/10/27(木) 19:18:48.52ID:???管理画面を誰が操作するかにもよるかな
保守員とかのある程度わかってる人が操作ならあまり細かくは必要ないと思うけど不特定多数が操作するようなものなら残しておいた方がいいと思う
昔製品サポートやってたけど利用者のなにもしてませんって言う言葉は信用できないと思った方がいい
悪意とかじゃなくて無意識の操作は覚えてないのでヒアリングではどうしようもない
そう言うときはログが頼りになる
常時とれなくても何かの設定でとれる仕組みはあった方がいい
0754sage
2016/10/27(木) 20:02:13.69ID:fYkFiAQ1https://www.youtube.com/watch?v=NJYs5GTmdcg
0755NAME IS NULL
2016/10/27(木) 21:23:29.89ID:???普通のシステムだよな。
きっとWEBのサービスしか知らないのだろう。
0756745
2016/10/27(木) 21:49:00.34ID:???ありがとうございます。
確かに753さんが言うようなケースって多々あるんですよね
誰かが必ず何かをしてバグやエラーが発生しているんです。
とはいえ、全てのデータを記録出来ないし、
記録するとなればすぐにDBが圧迫してしまう気がします。
なもんで、管理者IDと操作画面のURLと日時だけ記録すれば良いと思うのですが、
それだけでも大丈夫でしょうか？
0757NAME IS NULL
2016/10/27(木) 22:08:18.94ID:???0758NAME IS NULL
2016/10/27(木) 22:27:04.68ID:???操作ログを取る前にエラーが発生したときのエラーログを取れ。
0759745
2016/10/27(木) 23:42:08.73ID:???0760NAME IS NULL
2016/10/28(金) 00:13:25.69ID:???ログの種類を厳選するのではなく、ログの取得方法を工夫すべきでは？
0761NAME IS NULL
2016/10/28(金) 02:15:21.71ID:???今出てる問題を改善するのに操作画面と管理者と日時が特定出来れば充分なの？
まずはそこから、でもいいけど
0762745
2016/10/28(金) 08:31:29.30ID:???非エンジニア（デザイナーとか営業の人とか）が見て、
「こいつが操作したからこうなったんだな」というのが
最低限わかればいいと思うんです。
別に私のプロジェクトだけじゃなくても、
非エンジニア向けのログの取り方・見せ方と言うのは大事だと思うので。
0763NAME IS NULL
2016/10/28(金) 13:17:16.27ID:???理解。非エンジニア向けですね
欲をいうと登録/更新/削除と、重要なところはその画面のキー情報（社員コード/商品コード/受注番号etc）
ログとる仕組み作るのも大変だから予算との都合で取捨
0764NAME IS NULL
2016/10/28(金) 13:20:50.22ID:???0765NAME IS NULL
2016/10/28(金) 14:43:07.37ID:???ログ出力というのがファイル出力することだとしたら、データベースに出力する方法をお薦めする。
理由は、
・データ操作と監査データ登録を同じトランザクションで実行できる（双方の乖離が絶対に発生しない）
・データベースのバックアップで監査データもバックアップできる
・監査データテーブルには、データベースの仕組みで権限設定ができる
・万一、一つのデータベースと複数のアプリケーションサーバという構成になっても、監査データは1箇所に集まる
0766NAME IS NULL
2016/10/28(金) 20:22:28.56ID:???テキストなんてやだよw特定めんどいし
仕組み上ファイルにはくしかなくても最終的には収集してデータベースに持ちたい
0767NAME IS NULL
2016/10/28(金) 22:20:47.01ID:???0768745
2016/10/28(金) 23:09:08.89ID:???とりあえず各ページの読み込みログを取得するようにしました。
最低限の、管理者ID、IPアドレス、リファラ、アクセス日時を取得して
この内容でどの程度の管理ができるのか、
どの程度ログが肥大化するのか見たいと思います。
0769768
2016/11/03(木) 19:30:18.10ID:r6OR5gCg当初、>>768このように考えていたのですが、
管理画面ではない、公開サイトのログやメールログもDBで管理したいとなりました。
この場合、単純に
・管理ログテーブル
・ユーザーログテーブル
・メールログテーブル
と、3つのテーブルを追加するというのを考えているのですが、
ログって一括で見ないとどこが原因かわからない時もあります。
（Apacheのログは1つのファイルに書き込まれますし
かと言って1つのテーブルにまとめると、
ID｜管理者ID｜ユーザーID｜メールアドレス｜IPアドレス｜リファラ｜日時
みたいになり、ログによってはNULLになるカラムが多く出てきますし、
テーブル自体の肥大化も気になります。（ログテーションすればいいだけでしょうが・・・
こういったケースの場合、どうテーブル設計するのが良いのでしょうか？
0770NAME IS NULL
2016/11/04(金) 01:39:20.42ID:???一括でみるより別々にみたほうが分かりやすい気がするから俺なら一つのテーブルにはしない
0771768
2016/11/04(金) 09:04:57.79ID:???なるほど。確かに分けて一つにするのは色々方法がありますが、
1つを分けるのは大変ですね。
自分のような設計ベタの場合、ついテーブルの数を減らしたくなるのですが、
DBを使ってるわけですし、テーブルの数よりも効率化と保守性を考えて設計します。
アドバイスありがとうございました。
0772NAME IS NULL
2016/11/04(金) 09:09:33.46ID:???それらのログをどう使いたいかに依ると思う
Apache みたいにどう動いているかを見るためのログならまとめた方がいいし、フィールドを細かく分ける必要はなくて人間しか見ないからテキストで持っておけばいい
例えば誰がたくさんメールを使ってるかとかも見たいと言うなら分けとかないと面倒になる
0773768
2016/11/04(金) 11:01:22.93ID:???一番は保守性ですね。例えば
・誰が操作したか
・メールが送信されたか否か
の2点を管理画面などで見られたら十分だと思います。
サーバログのようにテキストベースだとログ解析能力が必要です。
しかし、DBにしてHTML上に表示すれば誰が見ても分かります。
おそらくエンドユーザーからの問い合わせで多いのは
「メールが届いていない」「情報が更新されていない」「削除されている」
などの不具合かと思います。
メールに関して言えば、sendmailでもSMTPでもDBに送信した事実を保存しておけば、
「○月○日○時○分にメールが送信されています。
届いていないということは、ご使用のプロバイダや迷惑メールフォルダ等をご確認ください」
といったサポートが出来ると思います。（開発者ではなくても
0774768
2016/11/04(金) 11:05:37.60ID:???cronで定期的にDBにinsertする方法もあると思います。
ログの肥大化や負荷がどうこう気にするなら、この方が良いかもしれません。
自分の経験上、ログは「トラブルがあった時に見る」程度で
転ばぬ先の杖的存在なのですが、欠かせないものでもあると思うので、
しっかりログ管理については勉強したいと思います。
0775NAME IS NULL
2016/11/04(金) 14:20:52.75ID:???> の2点を管理画面などで見られたら十分だと思います。
そりゃそう言う要件あるなら当然別々に管理するのが楽だろ
悩む理由がわからん
0776NAME IS NULL
2016/11/07(月) 11:26:05.63ID:0I/PzWKI単純にアイテムを買うだけなら、購入履歴に追加するだけで良いと思うのですが、
利用期間や日数に応じて課金する仕組みもあります。
これって「利用料（30日）600円」というような商品を作って購入履歴に追加するのか、
アイテム購入履歴テーブルとは別に、利用履歴テーブルみたいなの作るんですかね？
ユーザーテーブル
└アイテム購入履歴テーブル<=>アイテムテーブル
└利用履歴テーブル<=>利用期間テーブル？
みたいな設計を想像しているのですが、なんか違う気もする
そして購入したアイテムは使った（減った）という動作が必要なわけだから、
また別のテーブル（アイテム使用テーブル？）が必要になると思うし、
ものすごい数のテーブルになりそうで、設計が難しそうですね
0777NAME IS NULL
2016/11/07(月) 11:58:45.23ID:???0778776
2016/11/07(月) 13:36:21.11ID:???■会員テーブル
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｜支払待ち
0779776
2016/11/07(月) 13:39:49.74ID:???1）会員の名無しが利用できるか否かをどうやって判定するのか？
2）アイテムを使用した後は使用履歴テーブルを作るのか？
それとも購入履歴にカラムを追加するのか？
3）請求履歴は購入履歴の内容を合算した金額なわけですが、
購入に対して支払った・キャンセルしたというのはどう判定するのか？
購入履歴にカラムを追加するのか？支払い、キャンセルテーブルを作るのか？
そもそもこの基本設計が間違っている場合はご指摘ください
0780NAME IS NULL
2016/11/07(月) 13:54:24.61ID:???0781NAME IS NULL
2016/11/07(月) 14:03:30.22ID:???スマホゲームなら、30日利用権とかは基本前払い（購入完了で権利発生）。
0782NAME IS NULL
2016/11/07(月) 14:12:49.26ID:???会員テーブルと商品マスター(実装されている商品の一覧と属性、有効期限、価格)、
購入済商品テーブル(会員が購入された商品、購入日)
購入履歴はいらない気がする
1）会員の名無しが利用できるか否か
購入済み商品テーブルに、会員ID、商品IDのレコードがあれば利用できると思う。
2）アイテムを使用した後は使用履歴テーブルを作るのか？
それとも購入履歴にカラムを追加するのか？
購入したアイテムに有効期限、使用回数制限があるなら、購入済商品テーブルにその項目を追加する。
3）請求履歴は購入履歴の内容を合算した金額
ゲームって購入時に即時支払いしてませんか？
後払いになる場合は、購入済み商品テーブルに決済済かどうかの情報持たせて、
決済日に未決済の商品をユーザーごとに集計すればできそう。
0783NAME IS NULL
2016/11/07(月) 14:23:23.14ID:???期間アイテムは効力が発生してる期間がわかる別データを蓄積すべき
0784776
2016/11/07(月) 14:25:45.55ID:???そうでした。スマホゲームは基本的に前払いなんですね。
>>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回発行してるし、プログラムとかで日数を取得しなきゃいけません。
0785NAME IS NULL
2016/11/07(月) 14:31:11.89ID:???購入済み商品テーブルに商品購入日があれば
その購入済み商品が現在使えるかどうかは
判断できるんじゃないですか？
0786776
2016/11/07(月) 14:32:48.93ID:???SELECT 購入ID FROM 購入履歴テーブル
WHERE 企業ID=1 AND NOW() < DATE_ADD(購入日,INTERVAL 60)
こうかな。
＞購入したアイテムに有効期限、使用回数制限があるなら、購入済商品テーブルにその項目を追加する
購入済みのテーブルにアイテムの情報って持たないほうがいいんじゃないですか？
アイテム（商品）の種類に応じて必要なカラムが変わると思いますし。
0787776
2016/11/07(月) 14:35:01.65ID:???そうなんですが、どう購入日と比較するかが問題です。
商品によって利用期間日数が異なる場合、
まず、購入した商品の利用期間日数を取得して、
その日数の範囲内の購入履歴があるか調べるって流れになると思うんです。
0788776
2016/11/07(月) 14:41:40.27ID:???ググりながらコピペしてたんで間違いました。会員の事だと変換ください。
0789NAME IS NULL
2016/11/07(月) 15:24:00.50ID:???>購入済みのテーブルにアイテムの情報って持たないほうがいいんじゃないですか？
購入した日付はユーザーごとにそれぞれ違うので購入した商品とセットにした方がいいと思います
同様に使用回数制限がある場合は、何回使っているか、商品とセットにした方がいいですね
会員がそのアイテムを使用すれば、購入済商品テーブルの該当商品の使用回数を減算していけばいいと
なります。
>>787
購入済商品テーブルに購入した日付が入って入れば購入履歴はいらないんじゃないですか？
利用期間日数が異なって、その都度計算するのが煩わしいということなら、有効期限日を
テーブルに持たせればいいと思います
会員が現在使用可能な商品は、購入済商品テーブルから、
その会員IDと有効期限日前の、使用回数が0でない商品を検索すれば1回で済みます
0790776
2016/11/07(月) 15:38:14.53ID:???ありがとうございます。
改めて皆さんのアドバイスを元にテーブル設計してみました。
■会員テーブル
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の名無しは現在利用できるのか？」は探しやすいと思います。
0791NAME IS NULL
2016/11/08(火) 11:56:23.81ID:???・課金商品
ゲーム内通貨 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のみ＋冗長性高め」がオススメ
また、現在情報と履歴を分離しておくと
古い履歴をバックアップ＆削除出来るようになる
0792776
2016/11/08(火) 13:08:30.55ID:???課金商品と販売アイテムは分けるんだけど、
履歴として統合させるって考え方はすごく参考になります。
今までの私ならそれぞれの履歴テーブルを作っていました。
また、履歴関係は「基本insertのみ＋冗長性高め」というのも無い視点でした。
deleteやupdateさせてしまいがちですが、insertだけだと確かに管理しやすいです。
スマホゲームに限らず、課金・購入関係の設計というのは難しいので、
色んなパターンを想定しながら勉強します。ありがとうございました。
0793NAME IS NULL
2016/11/08(火) 13:12:36.66ID:???0794NAME IS NULL
2016/11/08(火) 13:37:32.04ID:???というか「現在値」を持つテーブルは壊れても復旧できるように
作っとかないと取り返しつかんくなるぞ
0795NAME IS NULL
2016/11/08(火) 14:01:56.83ID:???> というか「現在値」を持つテーブルは壊れても復旧できるように
> 作っとかないと取り返しつかんくなるぞ
普通は、「現在値」を持つのは、バグによるデータ不整合発生に備えるためじゃないよね。
0796NAME IS NULL
2016/11/08(火) 14:22:57.49ID:???っていう話を誰かしてるか？
0797NAME IS NULL
2016/11/08(火) 14:29:51.37ID:???0798NAME IS NULL
2016/11/08(火) 14:34:27.46ID:???>>791で「バグでデータ異常になった際」
というのが、データ不整合の話だと受け取ったが。
0799NAME IS NULL
2016/11/08(火) 15:05:21.93ID:???0800NAME IS NULL
2016/11/08(火) 17:37:41.75ID:???0801NAME IS NULL
2016/11/08(火) 17:40:51.49ID:???顧客情報および取引履歴などは災害も考慮して
遠隔地バックアップするところもある
操作ミスやデータ連携に起因する場合もあるし
誤請求が起きた際に対象の特定不可なんてことになったら悲惨
幸いにもそういった問題が起きたことは無いが
だからといって考慮しないというのはちょっと
0802NAME IS NULL
2016/11/08(火) 17:47:33.46ID:???完璧を求めて「何もしない」になるパターン？
0803NAME IS NULL
2016/11/08(火) 18:30:32.83ID:???>>791の例だと、「アイテムを販売したのに売上レコードが登録されないバグ」とか、「何かを更新・削除しようとしたら意図しないレコードまでが対象になった」とかいろいろあるじゃん。
そういうのはデータベース設計には含められないよって事。
「誤請求」も、それがデータ内容がおかしい（請求処理コードは正しい）のが原因の場合もあれば、データ内容は正しいが請求処理コードがおかしい場合もある。
いずれにしても、データベース設計では救えない。
0804NAME IS NULL
2016/11/08(火) 18:32:58.32ID:???0805NAME IS NULL
2016/11/08(火) 18:36:39.07ID:???ユニーク制約つけるとか、外部キー設定するとか、check制約付けるとか、計算結果をキャッシュするならトリガーでそれを行って同一トランザクションで正しい値がセットされるのを保証するとか。
0806NAME IS NULL
2016/11/08(火) 18:44:09.21ID:???>「アイテムを販売したのに売上レコードが登録されないバグ」
例：
売上レコードの登録 + 未反映レコードIDの登録
→ 未反映売上レコードを元に現在値を更新
※アーカイブログと同じ考え方
>「何かを更新・削除しようとしたら意図しないレコードまでが対象になった」
例：
insertのみ
0807NAME IS NULL
2016/11/09(水) 10:27:36.72ID:???0808NAME IS NULL
2016/11/09(水) 10:58:07.90ID:???0809NAME IS NULL
2016/11/09(水) 11:06:30.32ID:???なんかまだ信用できないというか使えてない
0810NAME IS NULL
2016/11/09(水) 11:50:19.71ID:???履歴テーブルの情報消失リスクを下げるという話の流れな
現在値は何かあっても履歴から回復出来るから普通に更新する
長期間/小範囲の異常が後から判明するケースは
リストアやリカバリでは基本的に対処出来ない
0811NAME IS NULL
2016/11/09(水) 12:14:48.31ID:???パフォーマンスの都合で中間データを置くのに使う
一時表を使わずともDBMS側で色々キャッシュは掛かるから
使わない方が好ましいが、いざという時のため知っておいて損はないよ
0812NAME IS NULL
2016/11/09(水) 13:11:02.96ID:oH9jZGKW0813NAME IS NULL
2016/11/09(水) 13:14:37.06ID:oH9jZGKW前段と後段で話が矛盾してるだろ
長期間/小範囲の異常が後から判明したときにリストアやリカバリでも対処できなければ、現在値だって回復できないだろ
というか、そういう状態の時は、現在値すら正しいかどうかもわからん
0814NAME IS NULL
2016/11/09(水) 13:17:00.54ID:oH9jZGKWまあ、普通はデータベースの内容には誤りはないという前提でコードを書くんだが
0815NAME IS NULL
2016/11/09(水) 13:33:31.90ID:???テンポラリーじゃなくてテンポラル表ね
テーブルにデータの変更履歴が残って、
ある時間でSELECTするとその時の値が出てくるやつ
http://www.oracle.com/technetwork/jp/database/application-development/total-recall-1667156-ja.html
https://msdn.microsoft.com/ja-jp/library/dn935015.aspx
0816NAME IS NULL
2016/11/09(水) 13:34:20.55ID:???それが>>806で発生した場合どうなるか少しでも考えてみた？
>>813-814
不良セクタ的な話でもしてるのか？話がズレすぎ
0817NAME IS NULL
2016/11/09(水) 19:41:16.27ID:???0818NAME IS NULL
2016/11/12(土) 00:44:54.88ID:???テーブル単体でみてもどのトランザクションか特定するの難しいな
トランザクションIDのカラムがあればまだなんとか
REDOログのバックアップから解析できれば最強だと思うんだけどな
0819NAME IS NULL
2016/11/13(日) 13:05:54.99ID:???取り消しとかキャンセルはどう扱ったら良いの？
状態の変更で済ますの？
それとも「履歴テーブルは事実のみ残す」として、updateやdeleteはせずに、
別テーブル（キャンセルテーブル）とか作るの？
0820NAME IS NULL
2016/11/13(日) 15:16:05.37ID:???たんに取り消しとかキャンセルとか言われても
それが取り消されている事実だけがわかれば良いのなら単なる状態変更で良いかもしれんが
いつ誰がどういう理由で取り消したのか分からないと困るとか
取り消しを取り消したときその事実が分からないと困るとか言われたらどうするよ
0821NAME IS NULL
2016/11/13(日) 18:44:41.07ID:???とすれば、別テーブルか。
それか、課金テーブルの方に状態カラムを追加して、状態変更するけども、
履歴テーブルも使用するパターンか。
汎用性を重視するなら後者か。
0822NAME IS NULL
2016/11/14(月) 10:51:42.25ID:???金が絡むものは全部残すようにしとかないと大事故になりそう
0823NAME IS NULL
2016/11/14(月) 11:41:08.56ID:???どれを選ぶかは要件次第だけど
選択肢としては赤伝方式もある
同じテーブルにマイナス金額で取り消しの行を作る
関連付けのため取り消し対象の一意キーも持つ
0824NAME IS NULL
2016/11/14(月) 12:06:43.24ID:???それのメリットってなんなの？
状態変更→履歴追加と変わらないと思うし、
むしろマイナス値加える方が無駄が多くなると思うんだが
（マイナスじゃない場合は0かNULLだろうし
0825NAME IS NULL
2016/11/14(月) 12:10:15.92ID:???履歴と状態に分けるのが無駄なケースもあるでしょ
うちのペイメントログなんかそんな感じだよ
0826NAME IS NULL
2016/11/14(月) 12:13:45.74ID:???よかったら、どういう要件でそうしてるのか教えてくれない？話せる範囲でいいから。
0827NAME IS NULL
2016/11/14(月) 12:42:44.00ID:???売上金額的にはマイナスしたいが、売り上げた事実そのものはなくさない
たんにマイナスの売り上げだととらえられなくもないから
普通に売り上げテーブルに追加するのは当然
つか普通に業務システムやってれば赤伝が必要な要件なんていくらでもあると思うが
0828NAME IS NULL
2016/11/14(月) 13:07:36.62ID:???0829NAME IS NULL
2016/11/14(月) 13:22:59.91ID:???取消はメンテナンスの一種という要件なら削除フラグでもいいかもしれん
0830NAME IS NULL
2016/11/14(月) 13:26:39.89ID:???確定後だったり顧客都合の場合は赤伝で事由入力が必須
メリット云々でなく単にユーザー企業からの要請
0831NAME IS NULL
2016/11/14(月) 19:31:39.05ID:CaXG621e0832NAME IS NULL
2016/11/14(月) 20:15:25.62ID:???まあ経理関係の業務に関わらないと知らないのも無理はない
締めたデータで税金とか色々計算するから元データをホイホイ変えられると困るからね
0833NAME IS NULL
2016/11/15(火) 00:36:38.67ID:5C6At6yC赤黒はUPDATE日付、UPDATE_PG名、CREATE日付、CREATE_PG名のカラムがあれば追えるんじゃない？
0834NAME IS NULL
2016/11/15(火) 00:44:27.76ID:???絶対に間違えられないとこだからデータの更新自体したくない（処理済みフラグとかは除いて）
0835NAME IS NULL
2016/11/15(火) 01:12:59.53ID:5C6At6yC調査でSQL投げても30分は帰ってこなかったなぁ
ちなにみそのテーブルのカラム数は700近かった・・・
0836NAME IS NULL
2016/11/15(火) 01:27:08.92ID:???0837NAME IS NULL
2016/11/15(火) 06:00:02.78ID:???0838NAME IS NULL
2016/11/15(火) 07:03:26.87ID:???一億件程度のデータは今時ままあるけどカラム数 700 はさすがに何か間違ってる気がする
0839NAME IS NULL
2016/11/15(火) 11:58:37.25ID:???なんだろ、汎用機とか全然違うシステムの資産をそのまま持ってきたとか？
1レコード1ページか、あるいは8KBに納まってなさそうそんなテーブル扱ったことないな
0840NAME IS NULL
2016/11/15(火) 12:00:02.86ID:???8KBのくだりはなしで
0841NAME IS NULL
2016/11/15(火) 12:03:28.69ID:???0842NAME IS NULL
2016/11/15(火) 14:02:48.22ID:???0843フーテンの虎次郎
2016/11/15(火) 17:46:41.40ID:???0844NAME IS NULL
2016/11/15(火) 18:07:59.48ID:???>今後、これがすべてスマートメーターに置き換わると、年間で約1200億レコードものデータが生み出される
そういう規模になってくるとテーブル云々どころか
リレーショナルDBかグラフ型DBかみたいなレベルからの設計になるんだろうな
何かちょっと楽しそう
0845NAME IS NULL
2016/11/16(水) 19:51:08.74ID:BwtU0UQtすぐ隣に防衛省の背広組の官舎があるのですが、
自分の家の窓にUSB接続のwebカムを貼り付けて、そこの動画を撮影し続け、
学会本部に送っていました。
別に大したものは写っていません。ゴミだしとか奥さんが子供を遊ばせている所とか。
官舎が老朽化して使われなくなってから、
今まで法人税(うちは自営業です)をほぼ払わなくても済んでいたのが、
もう守ってやれないのでこれからは満額申告するように言われました。
納得がいかないと言うと、君は自業自得で餓鬼地獄に落ちる、
朝夕南無妙法蓮華経と三千回ずつ唱えて心をきれいにしなさいと言われ
馬鹿らしくなって脱会しました。
それ以来、どこへ行くにもぞろ目ナンバーの車につけまわされたり大変な日々です。
全ては自分の出来心から起きた事で、どこに訴えて出ると言う訳にもいかないのですが、
何とかしてあの人たちと縁を切った上で新しい始まりを迎える方法はないんだろうか。
0846NAME IS NULL
2016/11/16(水) 20:48:12.85ID:???0847NAME IS NULL
2016/11/16(水) 22:32:02.97ID:m5+ecl6T前半300までは全てのデータ区分で使用
300-350まではデータ区分Aで使用
350-400まではデータ区分Bで使用
400-450まではデータ区分Cで使用
・
・
いにしえの資産でOccuresっぽい使い方してた名残かな
あと区分ABCでテーブル分けるよりこの方が表領域が少なくて済むと聞いたけど・・・データが見難い
0848NAME IS NULL
2016/11/16(水) 23:25:35.33ID:???データベースなに使ってるか知らんが、表領域小さいのはわかるけどディスクIOとメモリは無駄に負荷かかってそう
0849NAME IS NULL
2016/11/16(水) 23:43:06.93ID:???0850NAME IS NULL
2016/11/17(木) 01:07:31.07ID:???IO負荷は下がるだろ
区分分けで無駄なデータ読み込むのはOCCURSとはまた別の話だし
0851NAME IS NULL
2016/11/23(水) 21:15:21.75ID:???http://hitomi.2ch.net/test/read.cgi/poverty/1479870617/
0852NAME IS NULL
2016/12/10(土) 17:06:46.96ID:???商品名2
...
商品名50
みたいな文字列型のカラムを持つ単純なテーブルがあり、
そこに商品の数も保持したいのです。
追加で50個のint型のカラム
商品数1
商品数2
...
商品数50
を追加するのが良いかと思うのですが、カラム数が100個にもなります。
そこで例えばCの構造体みたいな
string 商品名
int 数
をペアで一つのカラムに保存するなどは出来ませんか？
それなら50カラムで足りると思います。
0853NAME IS NULL
2016/12/10(土) 18:38:32.36ID:???で50行商品を挿入じゃダメなん？
0854NAME IS NULL
2016/12/10(土) 19:45:26.40ID:???構造がおかしい
商品増えたらどうすんの？
0855NAME IS NULL
2016/12/10(土) 20:59:46.94ID:???「データベース 正規化」で検索
0856NAME IS NULL
2016/12/10(土) 21:35:12.41ID:???レス古事記乙
0857NAME IS NULL
2016/12/10(土) 21:57:46.22ID:???非道な文言
0858NAME IS NULL
2016/12/10(土) 22:14:55.82ID:gS9WP37z0859NAME IS NULL
2016/12/11(日) 14:38:35.55ID:???商品名\t数
これでバッチリ
商品名A\t数A\t商品名B\t数B\…
で1カラムにまとめればスッキリ
0860NAME IS NULL
2016/12/11(日) 15:04:22.89ID:hv2Rs4Dwhttps://youtu.be/PR6r40GbIfk
0861NAME IS NULL
2016/12/11(日) 15:47:43.95ID:???なるほど
そうします
0862NAME IS NULL
2016/12/11(日) 16:57:31.67ID:???0863NAME IS NULL
2016/12/11(日) 18:48:30.79ID:???0864NAME IS NULL
2016/12/12(月) 21:18:43.67ID:eeDavYCtまず単純にやりとりテーブルのカラムを
ID｜送信した会員ID｜受信した会員ID｜メッセージ｜日付｜既読日
と考えたのですが、掲示板なので送受信の投稿を一画面で表示したいので
これだと自分が送信した場合、受信した場合の履歴しか閲覧できません。
なにか良い考え方・設計の仕方はないでしょうか？
0865NAME IS NULL
2016/12/13(火) 00:39:40.35ID:???それ以外に何を表示したいの？
0866NAME IS NULL
2016/12/13(火) 01:14:29.72ID:???ヤフオクの取引ナビって、1画面で送信受信が一緒に表示されるんです。
表示は2ちゃんの掲示板みたいな感じです。
なので、メールみたいに受信BOX・送信BOXみたいに設計すると実現できません。
0867NAME IS NULL
2016/12/13(火) 01:38:52.77ID:???送信と受信を時間でソートして表示すればいいだけだろ
0868NAME IS NULL
2016/12/13(火) 09:36:19.23ID:???case
when 送信した会員ID = (自分) then '送信'
when 受信した会員ID = (自分) then '受信'
end as 送受信,
h.*
from テーブル h where
送信した会員ID = (自分) or 受信した会員ID = (自分)
order by
日付
0869NAME IS NULL
2016/12/13(火) 09:59:57.60ID:???請求書：１０マソ、ただし、コーディング代として
月末締めの翌々月払いにてお願いします
敬白
0870NAME IS NULL
2016/12/13(火) 12:14:50.84ID:???・掲示板テーブル
・掲示板の利用者テーブル
・掲示板のコメントテーブル
ってして、オークションが終わった後に掲示板テーブルにinsertして、
そのIDを利用者テーブルに会員IDを2レコード（出品・落札者分）追加する
そしてコメント投稿する時は利用者テーブルから掲示板IDを取得して投稿する。
これなら868みたいなコストがかかる糞コードを書かなくても良くなる
0871NAME IS NULL
2016/12/13(火) 14:17:54.37ID:???0872NAME IS NULL
2016/12/13(火) 14:24:53.85ID:???0873NAME IS NULL
2016/12/13(火) 20:15:42.74ID:???２レコード追加する辺りかな
0874NAME IS NULL
2016/12/14(水) 00:38:07.55ID:???追加しないとやり取りできねーだろw
0875NAME IS NULL
2016/12/14(水) 00:43:42.06ID:???掲示板テーブルに作成者と対象者の会員IDを保存する形か
0876NAME IS NULL
2016/12/14(水) 01:14:10.94ID:???こういうこと？
やり取りテーブル
やり取りID｜送信者ID｜受信者ID｜メッセージ送信日時｜既読日時
会員別やりとりテーブル（やり取りの最初に送受信者で1
会員ID｜やり取りID｜送受信区分
会員別やり取りテーブルに送受信者の2レコード作っとけば、参照だけなら少ないコストでいけるかな
0877NAME IS NULL
2016/12/14(水) 04:10:03.47ID:NT2Erum8どのような設計が一番効率的でしょうか？
0878NAME IS NULL
2016/12/14(水) 04:33:12.05ID:NT2Erum8・ランキングは日変動
・アプリを指定すると、順位の推移を表示
3日間考えましたがどのような設計をすればいいかわかりませんでした
よろしくお願いします
0879NAME IS NULL
2016/12/14(水) 04:57:53.13ID:???＞iTunesのランキングを
どこで見られる？
0880NAME IS NULL
2016/12/14(水) 08:10:04.53ID:NT2Erum8http://www.apple.com/jp/itunes/charts/paid-apps/
順位推移をうつすためにはどのような設計がベストですか？
例えばアプリ名からそのアプリの順位推移
ランキング1位を指定すると歴代1位のアプリが表示
のようなことをしたいです
0881NAME IS NULL
2016/12/14(水) 09:38:18.30ID:???>iTunesのランキングを日付毎に取得して保存したいです
取得して保存する機能はもう完成しているのか？
0882NAME IS NULL
2016/12/14(水) 11:25:22.52ID:???そのままでいいんじゃないか？
ランキング (日付, 順位, アプリ名)
アプリの順位推移：
select * from ランキング where アプリ名 = 'hoge'
歴代1位：
select * from ランキング where 順位 = 1
毎日100レコード追加だと1年で36,500レコードしか生成されないので、インデックスはつけなくても大丈夫だろう。
0883NAME IS NULL
2016/12/14(水) 16:12:52.89ID:NT2Erum8日付 順位 アプリ
このテーブルを360個つくるということでしょうか？
それとも同じテーブルに3600個保存ですか？
頭悪くて申し訳ないですが、ご鞭撻おねがいします
0884NAME IS NULL
2016/12/14(水) 16:35:32.01ID:???それはそうと、この件が単なるお勉強ではなくある程度の利便性も求めるなら、
保存するのは他の項目も含めてしておいた方がいいと思う。
例えば無料アプリtop10を取得すると、
https://itunes.apple.com/jp/rss/topfreeapplications/limit=10/json
・AppleがつけたアプリID
・カテゴリ
・リリース日
・有料アプリなら価格
・説明
・作者
とかいろいろ取得できるし。
0885NAME IS NULL
2016/12/14(水) 17:14:45.04ID:???テーブルを追加できることが種目的なケースは別だけど
0886NAME IS NULL
2016/12/14(水) 21:56:15.41ID:NT2Erum8たとえば
ID 日付 順位 アプリ
1 14日 1位 パズドラ
2 14日 2位 モンスト
を取得したとして、15日はどう追加すればいいですか？
ID 日付 順位 アプリ
1 14日 1位 パズドラ
2 14日 2位 モンスト
3 15日 2位 パズドラ
4 15日 1位 モンスト
これだとなんか違う気がするんです…
0887NAME IS NULL
2016/12/14(水) 22:35:57.16ID:???ORDER BY 日付, 順位 にすれば
14日 1位 パズドラ
14日 2位 モンスト
:
15日 1位 モンスト
15日 2位 パズドラ
:
って出てきて望み通りだろ
0888NAME IS NULL
2016/12/14(水) 22:37:26.28ID:???その上でなぜ違うと感じるか
言葉で表現してみて。
なぜを重ねて本質的な
部分を追及して
あなたが実現したいことが
あるから感じることがあるはず。
0889NAME IS NULL
2016/12/15(木) 18:55:18.07ID:41h8Tsky不正登録などの通報を受け付ける機能をサイトにつけようと思います。
2ちゃんみたいに複数の掲示板や動画や画像コンテンツなどあるのですが、
コンテンツ分だけテーブルを用意するとテーブルが増えすぎてしまいます。
かといって、1テーブルにURLや通報コメントだけ保存するのも分かりづらいです。
通報機能をサイトに組み込んでいる方、どのように設計しているか教えてください。
0890NAME IS NULL
2016/12/15(木) 19:51:30.66ID:???なぜテーブル数を気にする？
テーブル数から上流の設計する気？
0891NAME IS NULL
2016/12/15(木) 19:56:24.54ID:XdecS2Pq0892NAME IS NULL
2016/12/16(金) 03:10:55.65ID:???コンテンツが増える毎にテーブル増えるって変じゃねーか？
並行してプログラムの工数も増えるだろうし、
同じテーブル・プログラムをコピペしているようなもんじゃん
0893NAME IS NULL
2016/12/16(金) 04:46:55.78ID:???画像1枚を指して言ってるのかもしれんし、htmlの単位かもしれんし、フォルダやサイト単位かもしれん
0894NAME IS NULL
2016/12/16(金) 08:52:56.76ID:???>通報機能をサイトに組み込んでいる方、
例えばどんなサイト？
参考となるサイトを教えてくれ
0895NAME IS NULL
2016/12/16(金) 09:36:40.78ID:???>1テーブルにURLや通報コメントだけ保存するのも分かりづらいです。
分かりづらいという感覚がよく分からない
0896NAME IS NULL
2016/12/16(金) 11:20:28.27ID:EKNyVeG1https://youtu.be/PR6r40GbIfk
0897NAME IS NULL
2016/12/16(金) 17:34:13.51ID:???コストかけてちゃんとした機能作るんじゃなくて、csvにはいて担当者にわたすとかテーブル直で見させるとか考えてそうだが
まともに作るならそのあたりのことは機能設計進めれば見えてくるからな
0898NAME IS NULL
2016/12/16(金) 20:06:38.03ID:???0899NAME IS NULL
2016/12/17(土) 13:56:10.78ID:???0900NAME IS NULL
2016/12/20(火) 20:08:31.01ID:???いや転送の方がシンプルに実装出来る
0901NAME IS NULL
2016/12/20(火) 21:43:05.36ID:???どっちでもいいけど、わざわざDBはさむ意味なくねーか？
0902NAME IS NULL
2016/12/21(水) 00:48:08.92ID:???0903NAME IS NULL
2016/12/21(水) 01:09:47.94ID:zEZY0OoR発行SEQno1 100,102,103,104,….
発行SEQno2 200,205,223,244,….
・
・
・
2カラムしかなくて、２カラム目はデータをカンマ区切りで横持ち。
この持ち方による恩恵って何があるんだろ？
0904NAME IS NULL
2016/12/21(水) 01:55:33.74ID:???0905NAME IS NULL
2016/12/21(水) 07:02:20.37ID:???単純にリレーションを知らんだけかも
まあそのデータをどう使うかがわからんとなんとも言えないわな
0906NAME IS NULL
2016/12/21(水) 11:13:23.56ID:???・データ（ファイル）サイズがコンパクト
・KVSに移行しやすい
0907NAME IS NULL
2016/12/21(水) 18:33:05.10ID:???0908NAME IS NULL
2016/12/21(水) 19:38:36.07ID:rpLdLInk>>903の情報だけで先入観を持ってあれやこれや考えてしまった奴は失格
0909sage
2016/12/21(水) 20:01:21.16ID:C/hwpI+ihttps://www.youtube.com/watch?v=8fPmkq1CkCU
https://www.youtube.com/watch?v=PR6r40GbIfk
0910NAME IS NULL
2016/12/25(日) 08:51:55.70ID:???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%e3%82%a4%e3%83%ad%e3%83%8f%e3%81%aa%e7%9a%86%e6%a7%98%e3%81%b8.php
河野太郎議員が年金事務所の「イロハ順」を問題提起
年金事務所におけるファイルの整理方法について疑問点を指摘。
「アイウエオ順」ではなく「イロハ順」を使用していることについて
今後調査する意向を示しています。
0911NAME IS NULL
2016/12/28(水) 15:10:25.02ID:aQmnKv8v3800分のテーブルを作るのかひとつのテーブルに纏めるのかどちらがいいのでしょうか?
1年で約243日なので243レコードです
内容は前者と後者で
日付, 株価
日付, コード, 株価
になります
データの利用は一社ごとにするので、○日に○○円の会社を検索等はしないです
0912NAME IS NULL
2016/12/28(水) 15:55:46.77ID:???0913NAME IS NULL
2016/12/28(水) 16:36:29.81ID:???仕様と設計がリンクしてるかそれ？
0914NAME IS NULL
2016/12/28(水) 17:23:33.11ID:???0915NAME IS NULL
2016/12/28(水) 17:47:44.52ID:???0916NAME IS NULL
2016/12/28(水) 18:24:15.02ID:???新規上場や上場廃止があればその度にテーブルの数が増減すんのか？
0917NAME IS NULL
2016/12/28(水) 18:59:34.87ID:???0918NAME IS NULL
2016/12/28(水) 19:44:26.10ID:???するわけないだろ
作って放置だ
沸いての？
0919NAME IS NULL
2016/12/28(水) 19:50:41.73ID:???日本人なら表って言え
0920NAME IS NULL
2016/12/28(水) 21:27:59.41ID:???>作って放置だ
作って放置なテーブル、どんな意味があんだ。
頭、糸引いて腐ってんの？
0921NAME IS NULL
2016/12/28(水) 21:32:26.76ID:???0922NAME IS NULL
2016/12/28(水) 21:56:16.43ID:???発酵してるよ。
0923NAME IS NULL
2016/12/29(木) 14:38:10.29ID:j+hAywaThttps://youtu.be/uH-WOOcNZ0s
https://youtu.be/xHx5MbIGEoY
0924NAME IS NULL
2017/01/02(月) 23:36:17.84ID:???0925NAME IS NULL
2017/01/03(火) 07:08:07.98ID:???0926NAME IS NULL
2017/01/03(火) 14:09:57.59ID:???0927NAME IS NULL
2017/01/04(水) 10:50:48.68ID:???運用で同じカラムのテーブルが増減する設計をする人なんて
DB触って3ヶ月以内の人しかいないからだいじょぶ
0928NAME IS NULL
2017/01/04(水) 14:08:26.12ID:???0929NAME IS NULL
2017/01/04(水) 19:04:03.94ID:???複数市場に同時に上場している銘柄はどーすんの？（東証＆名証 etc）
まぁ>>911の例でいうならカラム一つ市場区分設けて同じ銘柄でも別テーブルにするのか。だったらもっと増えるなw
0930NAME IS NULL
2017/01/04(水) 19:07:10.82ID:???カラム一つ市場区分設けて同じテーブルにはせず、別テーブルにするのか。だったらもっと増えるなw
0931NAME IS NULL
2017/01/04(水) 21:06:10.69ID:???そりゃ普通にあるでしょ...
0932NAME IS NULL
2017/01/19(木) 19:05:15.52ID:???テーブルは分けるべきでしょうか？
例えば、Amazon マーケットプレイスのような
販売ユーザーと購入ユーザーの2種類のユーザーが存在する
このような場合のテーブル設計についてご教示いただけると有り難いです。
システムにより違いはあると思いますが
一般的にはどうなってるのかを知りたくて質問しました。
よろしくお願いします。
0933NAME IS NULL
2017/01/19(木) 19:26:38.80ID:???> 例えば、Amazon マーケットプレイスのような
> 販売ユーザーと購入ユーザーの2種類のユーザーが存在する
そのケースなら販売と購入で管理する項目がかなり違うだろうから分けるのが自然な気がする
販売と購入で同じユーザーIDでやりたいとかならログイン管理のためのテーブルを別に持つとかもあるかもね
一般的には要件によるとしか言えんわな
0934NAME IS NULL
2017/01/19(木) 19:31:14.37ID:???やはり分ける方が自然ですよね
ご回答ありがとうございます。
0935NAME IS NULL
2017/01/19(木) 21:56:23.77ID:???一般的はあなたの問題を複雑にするよ
0936NAME IS NULL
2017/01/20(金) 17:29:07.69ID:???なんかを分析するシステムなんだが、やる都度テーブル作って削除する仕組みがない
ディスク増やしましょうバックアップ時間長くなります、なんてお客さんに言いたくないんだが主菅する部署が影響度調査嫌がってどうにもならん
放置はやめてけれ
0937NAME IS NULL
2017/01/21(土) 20:32:17.44ID:???新規にテーブル初くらかったが、
集計し分析する都度テーブルにレコードを追加してた
その時にしか使わないレコードなのに、ずっと放置
だんだん重くなるばかり。こっそり古いレコード削除してた
0938NAME IS NULL
2017/01/21(土) 22:15:42.63ID:???つHadoop
0939NAME IS NULL 転載ダメ©2ch.net
2017/01/25(水) 22:18:08.12ID:???板復帰(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!
0940NAME IS NULL
2017/01/31(火) 10:14:19.92ID:???メタテーブル的にするかKVSみたいにするか悩む
0941NAME IS NULL
2017/02/21(火) 19:47:38.53ID:???0942NAME IS NULL
2017/02/26(日) 23:08:30.08ID:???課金の話とかややこしすぎ。けど、有名スマホアプリだともっと複雑なんだろうなぁ。
結論的には「要件次第」ってなるんだろうけど、
運用してると要件が後から変わってきちゃったりして、
最初にどこまで要件定義するかが後の設計に大きく関わる。
最初から何千・何億のレコードが入ることを想定した設計って
あらかじめ利用者が数万単位で想定できないと無理だし
テストも含めてそこまで考えるべきなのかなって思ったりして難しい
0943NAME IS NULL
2017/03/15(水) 22:05:29.51ID:OuNraHqTうまく伝えにくいのですが、2つのクラス間に線がひいてあり、その線の途中から他のクラスに線が引いてあるのはなんて言うのでしょうか？
◻----------◻
|
◻
0944NAME IS NULL
2017/03/24(金) 13:16:49.57ID:???0945NAME IS NULL
2017/04/13(木) 21:55:50.22ID:???ファイルをデータベース化したいと思い設計しているのですがこういう感じでどうでしょうか？
fileid integer、hash text、name text、length integer、type integer、lastModified textといった表にしたいのですが
主キーはfileidです、正規化がよくわからず、以下のようなテーブルを考えて結合して表示させようと考えているのですがどうでしょうか？
fileid、hash
fileid、name
fileid、length
fileid、type
fileid、lastModified
0946NAME IS NULL
2017/04/13(木) 23:04:13.24ID:???0947NAME IS NULL
2017/04/13(木) 23:54:46.49ID:???正規化を知らない人は答えないで下さい
0948NAME IS NULL
2017/04/13(木) 23:58:33.20ID:???0949NAME IS NULL
2017/04/14(金) 00:00:51.77ID:???0950NAME IS NULL
2017/04/14(金) 00:01:35.89ID:???主キーのfileldが分かればhash, name, length, type, lastModifiledが分かるならわざわざ分ける(正規化する)必要は無い
0951NAME IS NULL
2017/04/14(金) 00:02:51.27ID:???欲しい答えは帰ってこないだろうね
0952NAME IS NULL
2017/04/14(金) 00:06:17.55ID:???0953NAME IS NULL
2017/04/14(金) 00:15:35.44ID:???0954NAME IS NULL
2017/04/14(金) 06:38:02.43ID:???同じテーブルに格納するからtextなんでは
まぁ普通のdbはこんなテーブル作らないね
0955NAME IS NULL
2017/04/14(金) 07:12:52.41ID:???> 同じテーブルに格納するからtextなんでは
意味不明なんだが...
0956NAME IS NULL
2017/04/14(金) 08:40:56.52ID:???？？？
0957NAME IS NULL
2017/04/14(金) 12:18:02.69ID:???話が発散するのでどうでもいいとこに口を出さないで下さい
0958NAME IS NULL
2017/04/14(金) 12:20:04.02ID:???なんやお前
0959NAME IS NULL
2017/04/14(金) 12:41:36.88ID:???もしかしたら既に発酵してるのかも知れんが w
0960945
2017/04/14(金) 20:34:36.27ID:JLgv9GUw>>946
正規化を意識して、列を追加したりする可能性があるのでこういう設計になりました
ご指摘などありましたらお願いします
>>953
書き忘れていました、C#でsqliteを使用してdbを作るつもりです
sqliteでdateTimeって使えますか？仕様見たけどなかったもので・・・
0961NAME IS NULL
2017/04/14(金) 22:29:35.91ID:???0962NAME IS NULL
2017/04/14(金) 23:43:38.66ID:???0963NAME IS NULL
2017/04/15(土) 02:07:53.54ID:???正規化の勉強から始めようやで
0964NAME IS NULL
2017/04/15(土) 08:17:35.80ID:???正規化のメリットは「無駄を排除できる」てのが大きいと思うけど、さすがに本末転倒な気がする。
0965NAME IS NULL
2017/04/20(木) 21:45:00.22ID:???ねっとりしゃぶれよDB
0966ich1
2017/04/21(金) 16:39:00.55ID:R/eXxgbcこれは嘘でしょ？本当だったら落ち込むわ。。
0967NAME IS NULL
2017/05/17(水) 14:29:51.87ID:qq48S/pIメインテーブルの設計は変えたくないので、補助用のテーブルを作って結合します。
補助用のテーブル、「テーブル名_options」というのを作ったとして、どう設計しますか？
A）テーブル名_optionsに、カラムが必要になる度に追加する
B）テーブル名_optionsを単一参照テーブルにする
C）テーブル名_optionsではなく、目的に応じたテーブルを作り、それだけのカラムを用意する
ご意見ください。お願いします。
0968NAME IS NULL
2017/05/17(水) 18:18:45.31ID:???SQL EAV
でググれ
0969NAME IS NULL
2017/05/17(水) 18:20:36.79ID:???「options jsonb」を追加する
0970967
2017/05/17(水) 18:32:14.92ID:???ググったのですが、いわゆるBのことですよね？
>>969
すみません。こちらはググってもよく分かりません。
どいうことでしょうか？もう少し詳細を教えて下さい。
0971NAME IS NULL
2017/05/17(水) 19:00:10.55ID:???> ググったのですが、いわゆるBのことですよね？
俺のレスから12分しかたってないわけだが
ヒットしたページを何ページも読め
可変属性をどう扱うべきかが、EAVに関連して語られてることが多い
0972NAME IS NULL
2017/05/17(水) 19:02:34.75ID:???> どいうことでしょうか？もう少し詳細を教えて下さい。
969じゃないが、jsonb型のoptionsカラムを追加しろということかと
postgres以外にサポートしているDBがあるかどうか知らないが
0973NAME IS NULL
2017/05/17(水) 19:22:58.64ID:???0974NAME IS NULL
2017/05/18(木) 01:00:05.11ID:YTEweaJo1.TweetとReTweetは別テーブルにする
2.同じテーブルにして使わないフィールドはnull埋め
3.その他
class TweetBase{
    id:int;
    user:int;
    date:Date;
}
class Tweet extends TweetBase{
    text:string;
}
class ReTweet extends TweetBase{
    //RTしたツイートのID
    tweet:number;
}
0975NAME IS NULL
2017/05/18(木) 01:00:46.39ID:YTEweaJoclass TweetBase{
id:int;
user:int;
date:Date;
}
class Tweet extends TweetBase{
text:string;
}
class ReTweet extends TweetBase{
//RTしたツイートのID
tweet:number;
}
0976NAME IS NULL
2017/05/18(木) 08:23:24.27ID:???そのままテーブルにしちゃえばいいんじゃね？
-- 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)
);
0977NAME IS NULL
2017/05/18(木) 17:42:36.92ID:YTEweaJo外部キーで親を持つって事か
その発想はなかった
ありがとう
0978NAME IS NULL
2017/05/18(木) 18:10:50.50ID:???そもそも、この設計がダメダメ
共通の親クラスを持つ意味がない
たとえば、
・tweetを削除する
・retweetを削除する
を実装するとき、どこにどう実装するのか想像すればわかるだろう
0979NAME IS NULL
2017/05/18(木) 18:25:40.04ID:YTEweaJo0980NAME IS NULL
2017/05/18(木) 19:09:16.75ID:???ってか w
せめて模範解答でも示してるならまだかっこはつくけどね
0981NAME IS NULL
2017/05/18(木) 22:49:16.66ID:???一般的な解は3種類くらいあるからググってみろす。
0982NAME IS NULL
2017/05/18(木) 22:51:09.70ID:???0983NAME IS NULL
2017/05/19(金) 11:22:53.49ID:???普通に別クラスで実装
継承して良いのは、リスコフの置換原則に沿っている場合に限る
0984NAME IS NULL
2017/05/19(金) 20:14:19.39ID:???一応ケースバイケースだけどそれくらいならnullでいいだろ
0985NAME IS NULL
2017/05/19(金) 21:12:25.86ID:???0986NAME IS NULL
2017/05/19(金) 22:16:24.78ID:???どこが沿ってないのか詳しく書けるよね？
0987NAME IS NULL
2017/05/19(金) 22:39:04.45ID:ES7yFGBt「そのくらい」じゃなくて分かりやすいように例示しただけで実際はもっと複雑
リスコフの置換原則は大丈夫
0988NAME IS NULL
2017/05/19(金) 23:11:32.87ID:???> 実際はもっと複雑
だからケースバイケースって言われてるんだろ
どんだけ複雑かなんてお前にしかわからんのだし
0989NAME IS NULL
2017/05/19(金) 23:47:37.47ID:???私なら再帰構造にしますよ。
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
);
0990NAME IS NULL
2017/05/21(日) 21:50:51.26ID:???この手のやつはORM前提かどうかで変わると思うんだが
ORMごとに継承関係のあるクラスに対するテーブル設計のベストプラクティスとかないのか？
ORMを前提にテーブル設計を変えるのは本末転倒だって話もあるがな
0991NAME IS NULL
2017/05/22(月) 10:38:01.44ID:???> >>975だけからはリスコフの置換原則に適うかそうでないか判断できんだろう。
今回の"Twitter"が実存するTwitterなら、tweet != retweetなのは明らか
tweetに対するメソッドと、retweetに対するメソッドを、>>975のクラス構成でどこに実装すべきかを
考えれば、リスコフの置換原則に沿ってないのは明らか
0992NAME IS NULL
2017/05/22(月) 10:41:17.07ID:???> どこが沿ってないのか詳しく書けるよね？
逆にどこが沿ってるのか書いてみろ
0993NAME IS NULL
2017/05/22(月) 11:22:50.04ID:???ふつうにこれじゃ駄目なん？
table tweet (id, user, tweet_date, tweet_text, ...その他のtweetの属性)
table retweet (user, retweet_date, tweet_id)
0994NAME IS NULL
2017/05/22(月) 12:15:51.61ID:???0995NAME IS NULL
2017/05/22(月) 13:24:07.22ID:???あと、OOのクラスの継承と、データベースのテーブル継承は別だから、ごっちゃにして話すのよくない。
0996NAME IS NULL
2017/05/22(月) 13:34:39.41ID:???これのどこが再帰構造なんだろうか・・・
0997NAME IS NULL
2017/05/22(月) 15:36:17.62ID:???これ以外考えられん
0998NAME IS NULL
2017/05/22(月) 16:16:51.13ID:???0999NAME IS NULL
2017/05/22(月) 16:21:24.73ID:???1000NAME IS NULL
2017/05/22(月) 16:26:22.62ID:???ORM脳
10011001
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
life time: 586日 20時間 40分 11秒
10021002
Over 1000Thread運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。