DB設計を語るスレ 7
レス数が1000を超えています。これ以上書き込みはできません。
0001NAME IS NULL
2013/12/06(金) 15:52:17.46ID:09A/n1Z4前スレ
DB設計を語るスレ 6
http://toro.2ch.net/test/read.cgi/db/1341061787/
DB設計を語るスレ 5
http://toro.2ch.net/test/read.cgi/db/1331558806/
DB設計を語るスレ 4
http://toro.2ch.net/test/read.cgi/db/1309828440/
DB設計を語るスレ 3
http://hibari.2ch.net/test/read.cgi/db/1269585561/
DB設計を語るスレ ２
http://pc11.2ch.net/test/read.cgi/db/1223458453/
DB設計を語るスレ
http://pc11.2ch.net/test/read.cgi/db/1166540159/
0002NAME IS NULL
2013/12/06(金) 15:53:09.09ID:???何故データベース設計は軽視されるのか？
http://toro.2ch.net/test/read.cgi/db/1228061247/
頼むから正規化しろよ 第二正規形
http://toro.2ch.net/test/read.cgi/db/1116097001/
【より良い】データモデリング【モデルを】
http://toro.2ch.net/test/read.cgi/db/1057509675/
T字形ER（TM)ってどうよ？
http://toro.2ch.net/test/read.cgi/db/1156946197/
0003NAME IS NULL
2013/12/06(金) 15:53:10.26ID:???0004NAME IS NULL
2013/12/06(金) 18:51:30.97ID:???Redmineのmembers禁止
0005NAME IS NULL
2013/12/06(金) 19:01:36.51ID:???禁止でいいと思うわ。
0006NAME IS NULL
2013/12/06(金) 19:05:27.11ID:???これがずっと疑問でさ
0007NAME IS NULL
2013/12/06(金) 19:20:50.54ID:???それこそ狭義と広義かと
0008NAME IS NULL
2013/12/06(金) 21:32:49.66ID:???個人的には属性を持てると思う
Wikipediaの解説では、分かりやすい例として最も単純な
外部キーだけの構成で記述してあるだけで、
属性を持ってはいけない、あるいは持つべきであるとは書かれていない
http://en.wikipedia.org/wiki/Junction_table
この解釈により、WikipediaのERモデルの解説中にある
ER図例における relatioship は、すべて junction table として実装できる
http://en.wikipedia.org/wiki/Entity-relationship_model
http://ja.wikipedia.org/wiki/実体関連モデル
判断に迷うのは、サロゲートキーを持てるかどうかという話
そもそも junction table では外部キーのタプルが主キーであるから、
サロゲートキーの追加はDB設計上の重複 or 歪みでしかない
0009NAME IS NULL
2013/12/06(金) 21:41:30.47ID:???X: 属性を持ってはいけない、あるいは持つべきであるとは書かれていない
O: 属性を持ってはいけない、あるいは持つべきではないとは書かれていない
0010NAME IS NULL
2013/12/06(金) 22:16:23.45ID:???>> たまたまあるエンティティが２つの外部キーを持ち、
>>そのエンティティを介して２つのエンティティがm:n関係
>の具体例があったら上げて欲しい。「出版」みたいなわけわからん奴じゃなくて。
エンティティ顧客(customer)と製品(product)があり、第三の要素として受注(order)がある
order は、ある顧客からある製品を受注したという事象(event)を表現している
また属性として受注日付/受注個数等の受注に付随する属性、主キーとして受注番号、
そして外部キーとして顧客および製品への1:n関係を表現する顧客番号と製品コードを持つ
ここでERモデル設計上では、order は受注という事象を表現するエンティティである
なおかつ、結果としてorder を介し customer と product はm:n関係がある
0011NAME IS NULL
2013/12/07(土) 04:15:21.33ID:???だからサロゲートキーはつけてもいいって。
wikipediaに頼るんなら、書いてあることぐらい理解しようよ。
>>10
それはたまたまじゃない。持つべくして持ってるよね。
0012NAME IS NULL
2013/12/07(土) 11:56:34.44ID:???Associative Entity以外のどこに書いてある？
0013NAME IS NULL
2013/12/07(土) 12:01:38.01ID:???サロゲートキーを持ってはいけない、あるいは持つべきではないとは書かれていない
0014NAME IS NULL
2013/12/07(土) 17:49:17.18ID:???そのサロゲートキーが有用な場面は、って話だったはずなんだが
どんだけループしてんの
0015NAME IS NULL
2013/12/07(土) 17:57:22.88ID:???vs
持っていいけど、その構成だと意味が無いから不要
かなぁ。
00168
2013/12/07(土) 18:22:28.70ID:???vs.
・サロゲートキーはそれが必要なケースに限って使うべき（制限派）
ではないかと思われ
自分は後者の制限派
たとえば>>10の例だと、企業間取引であれば多くは受注伝票上の受注番号が
自然キーになるからサロゲートキーは使うべきではないけど、
これが(オンラインショッピングのような)個人取引であれば
受注番号は人工キーをサロゲートキーにせざるをえない、と考える
そしてRailsは前者の推奨派であり、
(属性を持たないm:n関係を除く)あらゆるテーブルはサロゲートキー id を持つ
0017NAME IS NULL
2013/12/07(土) 18:31:02.82ID:???476 名前: NAME IS NULL Mail: sage 投稿日: 2013/11/13(水) 22:40:49.61 ID: ???
すみません、ちょっと相談です。
どこからも参照されないような、意味のないサロゲートキーは張るべきではないって指摘したら
全てのテーブルにサロゲートキー張るのが定石ですよ！って返事が来た。
そんな定石は聞いたことないし、むしろ何でもID(IDリクワイアド)って世間一般的には否定されてなかったっけ？
テーブルA
[ID(サロゲートキー)]
[Part Number]
テーブルB
[ID(サロゲートキー)]
[Product Name]
テーブルC
A.[ID]
B.[ID]
CがA,Bの組み合わせでユニークなとき、Cにサロゲートキーを持つ意味って何なんでしょう？
複合キーはバグの温床でそれを排除できる。 将来の変更に柔軟に対応できる。
といわれても意味が分からない。このケースにおいて複合キーにバグの温床となる要素があるんだろうか…？
今後のテーブル構造の変更に柔軟に対応できる要素があるんだろうか…？
いったいどんな変更を想定しているんだろうか…？
0018NAME IS NULL
2013/12/07(土) 18:50:25.23ID:???持つ意味は無い。
将来的に必要になったときに持てばいい。
0019NAME IS NULL
2013/12/07(土) 18:57:34.02ID:???> 受注番号は人工キーをサロゲートキーにせざるをえない
？？
0020NAME IS NULL
2013/12/07(土) 21:29:40.21ID:???>それはたまたまじゃない。持つべくして持ってるよね。
そうだよね
ではここまではいいとして、次に、ある顧客との間で成立した
特定製品の値引きに関する契約が要求仕様に追加されたと仮定する
この場合ERモデルに対して、、たとえばエンティティ：顧客と製品との間に
リレーションシップ：取引条件(customer_product)を追加するという設計変更を行う
customer_product は、属性として値引率を持つ
そして、これまで設計してきたこのERモデルについて：
・チェンの記法(>>8 のWikipedia解説)によるER図と
・associative entity 用いたER図と
を見比べてみよう
http://www.h6.dion.ne.jp/~machan/misc/associative-entity.png
この質問(>>10 の前スレ995)は、assocative entity に関する議論のなかで起きた
チェン記法ではエンティティ/リレーションシップがERモデル設計の意図に沿って
正確に作図できているのに対して、associative entity を用いた作図では
それらの分類を表現しない(or 表現できない)ことが分かるのではないだろうか？
0021NAME IS NULL
2013/12/07(土) 22:57:13.39ID:???なんかまた話がずれたな。
で、自分でER図は書いてみた？
論理と物理
0022NAME IS NULL
2013/12/08(日) 00:08:29.06ID:???概念ERモデル図は>>20で書いてあるだろ
ここまで単純なモデルであれば、
よほどの初学者でも無い限り、誰でも論理ER図は書けるはず
それとも>>21は書けないのかな？
もし書けるというのなら、論理/物理設計を話題にしたい>>21が、
実際に書いてみればいいんジャマイカと思われ
それから、物理ERモデル設計は制約やインデックス等を定義するものだから、
(ER図としてではなく)表形式のテーブル設計書として書いているよ
それとも、普段>>21は物理ER図を書いているの？
わざわざ物理ER図を書くという発想がピンとこないなあ....
ひょっとして>>21は(業務経験の無い)学生さんかな？
0023NAME IS NULL
2013/12/08(日) 00:40:49.31ID:???連関エンティティはサロゲートキーを持ちうるかどうかから離れてってない？
どうせ長文書くなら結論まで頼む。
0024NAME IS NULL
2013/12/08(日) 01:15:19.92ID:???もともとは（概念設計レベルではなく）論理設計レベルの質問(>>17)なんだから、
X: associative entity はサロゲートキーを持ちうるかどうか
O: junction table はサロゲートキーを持ちうるかどうか
じゃねえの？
0025NAME IS NULL
2013/12/08(日) 01:23:32.88ID:???0026NAME IS NULL
2013/12/09(月) 13:28:31.71ID:???その2個のER図を比べている意味がわからない。内容もおかしいし
第一チェンが使ってたAssociative Entityがなんで別の概念なんだ？
0027NAME IS NULL
2013/12/09(月) 13:35:28.68ID:???前スレ>>995では一部省略したけど、
> ・たまたまあるエンティティが２つの外部キーを持ち、
> そのエンティティを介して２つのエンティティがm:n関係にあったとしても、
> 設計者がそのエンティティを連関エンティティであると宣言していなければ
> (=設計者が意図していなければ/見落としていれば)、そのエンティティは連関エンティティではない
を受けて、「たまたまあるエンティティが二つの外部キーを持ち、なおかつ形態としては連関エンティティに
見えるが、設計者が意図していない、または、見落としているようなエンティティの例があったらあげてくれ」
という趣旨の質問。
で、>>10のorderは、連関エンティティと同じ形態であるためには、(customer_id, product_id)がユニークで
ある必要があるけど、そうなの？
0028NAME IS NULL
2013/12/09(月) 13:47:37.45ID:???何を主張したいのやら。
0029NAME IS NULL
2013/12/09(月) 13:50:36.03ID:???といういみで、長方形と菱形を重ねただけかと思ったんだが違うのか？
0030NAME IS NULL
2013/12/09(月) 14:54:37.72ID:???0031NAME IS NULL
2013/12/09(月) 15:11:19.15ID:???連関エンティティだけ
0032NAME IS NULL
2013/12/09(月) 15:14:58.73ID:???は？何で持っちゃ駄目なんだ？
0033NAME IS NULL
2013/12/09(月) 15:18:02.14ID:???この人も意味わからんわ
0034NAME IS NULL
2013/12/09(月) 15:47:07.60ID:???> わざわざ物理ER図を書くという発想がピンとこないなあ....
え？書くよ？
逆に、物理ER図を書かない現場を知らないわ。
0035NAME IS NULL
2013/12/09(月) 16:04:31.85ID:???0036NAME IS NULL
2013/12/09(月) 16:24:11.82ID:???結論出たのが連関エンティティだけ
0037NAME IS NULL
2013/12/09(月) 16:27:23.99ID:???Junction Tableで定義されてるのは、FKをまとめたPKのみ
これが狭義だろ
広義はしらね
Associative Entityは狭義も広義もなく
属性や関係を持ったりサロゲートキーを持つ話も定義されてる
0038NAME IS NULL
2013/12/09(月) 19:12:38.98ID:KDrt2ZmL表現する手法を教えてください。 ホモとレズはいません。
AさんはB子とC子とつきあっている
DさんはC子とD子とE子とつきあっている
FさんはB子とC子とつきあっている
Gさんは誰ともつきあっていない（自慰だけに）
0039NAME IS NULL
2013/12/09(月) 19:43:33.66ID:???0040NAME IS NULL
2013/12/09(月) 20:29:20.47ID:???m f
---
A B
A C
D C
D D
D E
F B
F C
0041NAME IS NULL
2013/12/09(月) 22:13:08.75ID:???このテーブルって、インデックスはどうやって張ればいい？
mとfでセットで春？
0042NAME IS NULL
2013/12/09(月) 23:53:25.58ID:???0043NAME IS NULL
2013/12/10(火) 01:11:01.08ID:???まあ、PKには普通インデックス張られるから、この場合ならm,fでPKにするだろうし
mから検索するならそのままでもいいけど、fから検索するんのが多ければ俺ならfか(f,m)のインデックス張るかもしれん
0044NAME IS NULL
2013/12/10(火) 11:38:43.16ID:???(f,m)でインデックス貼るな
0045NAME IS NULL
2013/12/10(火) 19:31:01.18ID:???mとfにそれぞれインデックス張りました
0046NAME IS NULL
2013/12/10(火) 19:48:08.80ID:0Naa032yミック氏の書籍に「達人に学ぶDB設計 徹底指南書」には、
主キーに、"可変長文字列"を使用すべきでない。と書かれており、
コードやID（つまるところサロゲートキー？）を使うべきだとあります。
しかし、ネットで色々調べていると、サロゲートキーの使用は避け、
ナチュラルキー（これは可変長含む？）を使うべきだ。と言う解説も多くありました。
実際のところ、どのように両者を使い分ければ良いのでしょうか？
素人ながらに考えたのは、
ナチュラルキーが固定長文字列にできるのであれば、ナチュラルキー
それ以外はID（サロゲートキー）。なのかなと・・・。
経験者の方の意見をお聞きしたいです。
0047NAME IS NULL
2013/12/10(火) 20:00:13.76ID:???なぜ可変長文字列を使用すべきではないかの理由はかかれていなかったの？
データ構造の話に言及してそうな気はするんだけど。
0048NAME IS NULL
2013/12/10(火) 22:12:28.07ID:4E3YwY8Zサロゲートキーで弄らないなら複合キーを使う
俺的にはそんなイメージ
0049NAME IS NULL
2013/12/11(水) 02:08:25.89ID:???0050NAME IS NULL
2013/12/11(水) 05:34:25.98ID:???可変長にすると、"山田太郎"と"山田 太郎"が異なる値となるため、
たとえば外部キーで結合する場合に不一致が起こる・・・
可変長文字列が必要であるのなら変動する可能性が高い・・・
固定長と混合する可能性がある・・・
などと書かれていました。
>>49
現実世界を表す名称がナチュラルキーであるため、
それ単体でも意味を理解できるが、
サロゲートキーは単体では意味をなさない。
と、そのような理解をしています。
そういった意味では、ナンバリングの"1"もIDの"A001"も同じではないのでしょうか？
0051NAME IS NULL
2013/12/11(水) 09:35:04.16ID:???ミックって人が書いてる。
2008年時点で可変長の内容は書いてないな
> サロゲートキーは，基本的には不要なものです。～省略～
> しかし，以下のような業務要件の場合には，サロゲートキーを使うことを考えます。
> ① そもそも入力データに主キーにできる項目がなく，データが重複している場合
> ② 主キーの値が使いまわされる場合
> ③ 主キーの体系が変化する場合
ミックって人、訳の用語がぐちゃぐちゃで好きになれない
サロゲートキーを代理キーと訳されると、alternate keyはどうしたらいいのだ
>>50
システム側で独自に割り当て
システムでしか利用しない主キーをサロゲートキーと言うので
コードは外部で利用するために作ったものだと思うから
サロゲートキーではないよ
病院の待合室の機械で出てくる受付番号や
注文伝票で利用する商品コードとかな
"A001"はその類でしょ
0052NAME IS NULL
2013/12/11(水) 11:03:31.56ID:???0053NAME IS NULL
2013/12/11(水) 11:09:32.42ID:???0054NAME IS NULL
2013/12/11(水) 11:11:20.60ID:???0055NAME IS NULL
2013/12/11(水) 11:13:41.45ID:???サロゲートキーの訳語としての「代理キー」はメジャーだと思うけど。
例えばこことか。
ナチュラルキーとサロゲートキーについての議論
http://nippondanji.blogspot.jp/2013/12/blog-post_4.html
この人も嫌いなのか？
0056NAME IS NULL
2013/12/11(水) 11:32:39.97ID:???>>51の記事のURL出して話してるから
ミックって人の引用でしょ
0057NAME IS NULL
2013/12/11(水) 11:38:35.70ID:???> ミックって人の引用でしょ
わかってますが、それが何か？
0058NAME IS NULL
2013/12/11(水) 12:29:55.48ID:???訳語としては「代替キー」のがメジャーだと思う
普段はそのまま「サロゲートキー」を使うから訳語を使わないんだけどさ
0059NAME IS NULL
2013/12/11(水) 12:46:03.62ID:???疲れる。
どっちがメジャーかなんて話はしてないんだけど。
0060NAME IS NULL
2013/12/11(水) 12:51:58.74ID:???0061NAME IS NULL
2013/12/11(水) 12:56:18.44ID:???支離滅裂だなぁ
0062NAME IS NULL
2013/12/11(水) 13:08:52.98ID:???0063NAME IS NULL
2013/12/11(水) 13:10:23.88ID:???代理キーって別にあるからよくない
0064NAME IS NULL
2013/12/11(水) 13:11:28.04ID:???何が言いたいんだか。
「訳の用語がぐちゃぐちゃ」の例として、「サロゲートキーを代理キーと訳される」って言ってるけど、
サロゲートキーを代理キーと訳すのも普通にあるということなんだけど。
どっちがよりメジャーかなんてどうでもいいわ。
0065NAME IS NULL
2013/12/11(水) 13:12:29.54ID:???じゃ、>>55のリンク先の人も駄目ってことか？
0066NAME IS NULL
2013/12/11(水) 13:15:16.66ID:???引用利用をとやかく言うって
>>55の先の人に恨みでもあるの？
0067NAME IS NULL
2013/12/11(水) 13:17:38.32ID:???意味が分からん。
>>55のリンク先の人も、サロゲートキーを代理キーと言ってるけど、それはどうなのって聞いてるんだが。
0068NAME IS NULL
2013/12/11(水) 13:19:51.13ID:???他ブログを引用して記事を書くとき
元ブログの文言をそのまま使うことは往々にしてあるので
どうも思わん
0069NAME IS NULL
2013/12/11(水) 13:20:55.70ID:???MySQL業界外では結構嫌われてるからね。
0070NAME IS NULL
2013/12/11(水) 13:22:26.59ID:???引用とかしてないけど？
0071NAME IS NULL
2013/12/11(水) 13:26:38.16ID:???わからないならいいよ
>>55の人、その記事以外では代理キーって書かないんだよ
0072NAME IS NULL
2013/12/11(水) 13:29:27.62ID:???0073NAME IS NULL
2013/12/11(水) 13:35:34.16ID:???0074NAME IS NULL
2013/12/11(水) 13:40:56.20ID:???俺は全部同一人物じゃないかと睨んでるんだが。
0075NAME IS NULL
2013/12/11(水) 13:55:53.11ID:???http://watanabek.cocolog-nifty.com/blog/2013/03/id-8fce.html
0076NAME IS NULL
2013/12/11(水) 13:58:44.38ID:???うざい
0077NAME IS NULL
2013/12/11(水) 14:02:57.32ID:???0078NAME IS NULL
2013/12/11(水) 14:04:55.95ID:???うざい
0079NAME IS NULL
2013/12/11(水) 14:09:59.77ID:???この辺読むといいかもよ。
リレーショナルモデルのドメイン設計についての議論
http://nippondanji.blogspot.jp/2013/12/blog-post_8.html
IDの設計についてのさらに突っ込んだ議論
http://nippondanji.blogspot.jp/2013/12/id.html
0080NAME IS NULL
2013/12/11(水) 14:10:29.36ID:???0081NAME IS NULL
2013/12/11(水) 14:11:34.34ID:???0082NAME IS NULL
2013/12/11(水) 14:17:36.99ID:???うざい
0083NAME IS NULL
2013/12/11(水) 14:23:57.11ID:???0084NAME IS NULL
2013/12/11(水) 14:32:54.43ID:???うざい
008547
2013/12/11(水) 15:27:09.13ID:???>>50
ありがとう。そっちの理由なのか。なんともいえない気持ちになるなぁ。。
まぁ、ほんとに不変な自然キーってなかなか無いので、
なんだかんだある程度の覚悟はしとかないといけないよね。
0086NAME IS NULL
2013/12/11(水) 16:31:28.80ID:???システム開発において、これは不変だとして扱いますよと決めるのが要件定義
ある程度覚悟とか、要件定義の甘さをごまかしてるだけだろ
0087NAME IS NULL
2013/12/11(水) 16:58:31.51ID:???なぜ話をひっくり返して要件定義が甘いとかずれた話になるんだろ。
0088NAME IS NULL
2013/12/11(水) 18:25:22.27ID:???0089NAME IS NULL
2013/12/11(水) 18:32:29.28ID:???有る程度、「何を」覚悟するんだ
要件変更による設計変更なのか
要件変更の伴わない設計あるいは実装の変更なのか
0090NAME IS NULL
2013/12/12(木) 01:20:20.96ID:???運用中に変更になることなど。
つまり、ベンダもクライアントも不変だとしていたものが、そうではなくなることを覚悟する。
つか、あなたが想定していそうな、ベンダの思い込みで実装するような馬鹿じゃないんですよ。
009146
2013/12/12(木) 05:54:48.85ID:???すいません。質問したキッカケは、
可変長文字列（varchar(50)とか）の列を
５列ぐらい主キーに設定していたので、
「これは、まとめてサロゲートキーした方がいいじゃないのかな？
どっちがいいんだろう？」
って事を知りたかっただけなのですが・・・
参考URLなどありがとうございます。勉強します。
0092NAME IS NULL
2013/12/12(木) 09:21:37.75ID:???0093NAME IS NULL
2013/12/12(木) 11:43:50.96ID:???日本語も論理も変な奴が常駐してるせい
0094NAME IS NULL
2013/12/12(木) 13:01:42.82ID:???放置すれば良いよ
0095NAME IS NULL
2013/12/12(木) 13:09:54.66ID:???サロゲーロキー一択だなぁ
ナチュラルキーにしたいけど顧客の無茶な仕変がこわすぐる
0096NAME IS NULL
2013/12/12(木) 13:11:15.57ID:???論理が変な奴ってこれか？
>>55 >>57 >>64 >>70
日本語変なのってこれか？
>>51
0097NAME IS NULL
2013/12/12(木) 13:15:04.08ID:???結合テーブルはどうしてた？
0098NAME IS NULL
2013/12/12(木) 13:42:19.40ID:???>>89とかだろ
0099NAME IS NULL
2013/12/12(木) 13:45:21.77ID:???>>8,10,20とか。
0100NAME IS NULL
2013/12/12(木) 13:48:32.10ID:???「結合テーブル」って何？
で、どうしてたって何を？
0101NAME IS NULL
2013/12/12(木) 13:51:43.07ID:???0102NAME IS NULL
2013/12/12(木) 14:08:28.03ID:???0103NAME IS NULL
2013/12/12(木) 14:10:07.37ID:???「結合テーブル」は「連関エンティティ」の実装のテーブル
どうしてたって、サロゲートキーつけてた？って聞きたかった
>>101
結合テーブルはRails用語ではないよ
0104NAME IS NULL
2013/12/12(木) 14:12:19.33ID:???> 「結合テーブル」は「連関エンティティ」の実装のテーブル
> どうしてたって、サロゲートキーつけてた？って聞きたかった
その話題は、前スレからさんざん出てるじゃん。
まだ荒らし足りないの？
0105NAME IS NULL
2013/12/12(木) 14:16:29.77ID:???意味わからんぞ。>>95の人がつけたかつけなかったを聞いただけだ
過敏になりすぎ
0106NAME IS NULL
2013/12/12(木) 14:18:54.66ID:???0107NAME IS NULL
2013/12/12(木) 14:20:04.80ID:???それ聞いてどうすんだよ。
お前には関係無いだろ。
0108NAME IS NULL
2013/12/12(木) 14:22:34.52ID:+HgL5VL30109NAME IS NULL
2013/12/12(木) 14:22:34.51ID:???>>95ではないが、俺はつけるよ
0110NAME IS NULL
2013/12/12(木) 14:27:13.33ID:???理由もわからないなら、返信しなくて良いのに
0111NAME IS NULL
2013/12/12(木) 14:28:56.24ID:???うざい
0112NAME IS NULL
2013/12/12(木) 14:30:37.75ID:+HgL5VL3やっぱその人か…
出しゃばらなくていいんだよ
0113NAME IS NULL
2013/12/12(木) 14:32:21.95ID:???いや、マジで聞いてどうすんのよ？
0114NAME IS NULL
2013/12/12(木) 14:33:59.24ID:???> 結合テーブルはRails用語ではないよ
定義がどっかにある？
0115NAME IS NULL
2013/12/12(木) 14:36:19.25ID:???0116NAME IS NULL
2013/12/12(木) 14:38:44.85ID:???0117NAME IS NULL
2013/12/12(木) 14:51:34.47ID:???定義がどこかにあるかは知らないが
データベース設計を10年以上前からやってるけどそのころから普通に
"Junction Table"を用語として使ってて
それを訳すときは"結合テーブル"にしてた
0118NAME IS NULL
2013/12/12(木) 14:53:59.03ID:???0119NAME IS NULL
2013/12/12(木) 14:56:55.38ID:???0120NAME IS NULL
2013/12/12(木) 14:59:19.00ID:???"Cross Reference Table"を訳すときに使ってた
同じ意味って
0121NAME IS NULL
2013/12/12(木) 15:06:55.65ID:???頼むからまともな日本語しゃべってくれよ
0122NAME IS NULL
2013/12/12(木) 15:08:23.13ID:???なにがわからないの？
0123NAME IS NULL
2013/12/12(木) 15:09:40.18ID:???0124NAME IS NULL
2013/12/12(木) 15:10:11.11ID:???0125NAME IS NULL
2013/12/12(木) 15:11:07.44ID:???> 定義がどこかにあるかは知らないが
見つけてこいや
0126NAME IS NULL
2013/12/12(木) 15:16:00.56ID:???DB設計でもその訳のがいいのかな
0127NAME IS NULL
2013/12/12(木) 15:16:07.22ID:???> 同じ意味って
これどういう意味？何かの方言？
0128NAME IS NULL
2013/12/12(木) 15:18:25.98ID:???それは異端だと思うわ。
0129NAME IS NULL
2013/12/12(木) 15:24:49.36ID:???最初から、「連関エンティティにもサロゲートキーをつけてるのか？」と質問しておけば、こんなことにはならなかった。
まあ、何の為にそれを知りたいのかは俺もわからないけど。
0130NAME IS NULL
2013/12/12(木) 15:26:52.00ID:???結合テーブルと交差テーブルが同じ意味ということ
>>128
そうだね
"Cross Reference Table"はOracleで別の意味でも使われてて
そっちは別の訳にしてた
0131NAME IS NULL
2013/12/12(木) 15:30:05.19ID:???> "Cross Reference Table"はOracleで別の意味でも使われてて
> そっちは別の訳にしてた
これのこと？
http://docs.oracle.com/cd/E23549_01/integration.1111/b56238/med_xrefs.htm
0132NAME IS NULL
2013/12/12(木) 15:32:18.70ID:???> 結合テーブルと交差テーブルが同じ意味ということ
これは煽りじゃ無くてお願いね。
それならそうと最初から書いてよ。無駄にレスの往復が増えるから。
0133NAME IS NULL
2013/12/12(木) 15:39:17.13ID:???> 最初から、「連関エンティティにもサロゲートキーをつけてるのか？」と質問しておけば、こんなことにはならなかった。
すまん。反省してる
> 今まで主キーが不変であったためしが無いので
> サロゲーロキー一択だなぁ
連関エンティティだと主キーが不変にならないのかなと思ったから聞いた
サロゲートキーつけるって言われたら不変でないポイントを聞きたかった
>>131
それだね
>>132
すまん
0134NAME IS NULL
2013/12/12(木) 16:37:01.89ID:???0135NAME IS NULL
2013/12/12(木) 16:47:06.76ID:???0136NAME IS NULL
2013/12/12(木) 17:30:33.89ID:???0137NAME IS NULL
2013/12/12(木) 17:50:04.94ID:???>>135
0138NAME IS NULL
2013/12/12(木) 17:55:55.22ID:???お前らの好きなWikipediaもこう書いてる。
> Junction tables are known under many names, among them cross-reference table,
> bridge table, join table, map table, intersection table, linking table, many-to-many resolver,
> link table, pairing table, pivot table, transition table, or association table.
文脈でわかるだろ。
0139NAME IS NULL
2013/12/13(金) 15:20:17.30ID:???> 連関エンティティだと主キーが不変にならないのかなと思ったから聞いた
> サロゲートキーつけるって言われたら不変でないポイントを聞きたかった
?
0140NAME IS NULL
2013/12/13(金) 15:36:03.87ID:???過去レス嫁よ
0141NAME IS NULL
2013/12/13(金) 15:44:56.27ID:???君、>>133なんだろうけど、まだ意味わかんないよ
0142NAME IS NULL
2013/12/13(金) 15:50:06.90ID:???>>133ではないんだが･･･荒らすなよ
0143NAME IS NULL
2013/12/13(金) 16:00:58.23ID:???どういう意味なのかわかってるのなら、教えてくれます？
0144NAME IS NULL
2013/12/13(金) 16:15:14.33ID:???0145NAME IS NULL
2013/12/13(金) 16:15:56.64ID:???0146NAME IS NULL
2013/12/13(金) 16:33:03.72ID:???サロゲートキーとサロゲートキーをくっつけてるテーブルには
サロゲートキーをつけなかったよ
0147NAME IS NULL
2013/12/13(金) 17:39:37.14ID:???0148NAME IS NULL
2013/12/13(金) 19:10:52.65ID:???0149NAME IS NULL
2013/12/13(金) 20:08:01.77ID:???0150NAME IS NULL
2013/12/13(金) 20:09:53.98ID:???0151NAME IS NULL
2013/12/14(土) 00:55:25.42ID:???0152NAME IS NULL
2013/12/14(土) 01:35:43.22ID:???0153NAME IS NULL
2013/12/14(土) 11:35:08.43ID:???0154NAME IS NULL
2013/12/15(日) 09:50:26.06ID:???0155NAME IS NULL
2013/12/20(金) 11:39:32.84ID:???0156NAME IS NULL
2013/12/20(金) 11:41:58.41ID:???0157NAME IS NULL
2013/12/20(金) 14:51:54.09ID:???【KVS】 Key-Value Storeを勉強するスレ
http://toro.2ch.net/test/read.cgi/db/1267115925/
0158NAME IS NULL
2013/12/20(金) 19:32:20.25ID:???トリガー使って一緒に書き換えは可能？
0159NAME IS NULL
2013/12/22(日) 00:28:50.75ID:???0160NAME IS NULL
2013/12/22(日) 05:23:06.61ID:???外部キーの変更をカスケードして追従する機能があったり
トリガでの更新だと制限があったりすることもある
が、外部キーの値が書き換えられる状況がまず正しいか検討するべきじゃないかと
0161NAME IS NULL
2013/12/23(月) 09:50:29.46ID:ffNWKxBTDBはプログラミングと関わっているから〇〇の部署に行けよという
話になったが、DBの設計ってアプリ部分の話を指すのが普通なのか？
俺は、インフラ部分の方式設計や物理設計をやりたいという意味で言ったんだが。
この場合は、上司と俺のどちらの認識が正しいのか教えてください。
0162NAME IS NULL
2013/12/23(月) 09:56:10.08ID:???上司
0163161
2013/12/23(月) 10:03:54.64ID:???そうなんですか･･･orz
DBのインフラ部分の方式設計や物理設計、パラメータの設計をやりたいという
希望を伝えたい場合、どういう伝え方がいいんでしょうか。
質問ばかりですいません。
0164NAME IS NULL
2013/12/23(月) 10:30:37.62ID:???> DBのインフラ部分の方式設計や物理設計、パラメータの設計をやりたいという
相当でかいシステムでない限りそこだけ単独で担当つけたりしない
(そう言うケースだと、それなりのスペシャリストでないと歯がたたん)
ソフトウェア設計の一部になるから、その手の部署に行くしかないよ
そもそもこんなこと聞いてる時点で、そんな設計できる能力あるのか疑問なんだが...
0165NAME IS NULL
2013/12/23(月) 11:18:37.37ID:Qc7rtsKy素人なんでよく分かってないんですいません。
仕事のイメージとしては、各種サーバの構築(OS、JP1等のソフトのインストール)や
動作確認等のテスト等の作業と併せてDBの方式設計、構築をするという感じです。
上司には、上記のような仕事をしたいという伝え方がいいのでしょうか。
0166NAME IS NULL
2013/12/23(月) 11:35:46.73ID:???ねえ、人の話聞いてる？
> ソフトウェア設計の一部になるから、その手の部署に行くしかないよ
って書いてあるんだが...
0167NAME IS NULL
2013/12/23(月) 11:38:08.21ID:???DB設計うんぬんの前に、コミュニケーションの原則として、
相手に自分の意志を伝達したいのであれば、それを具体的に説明すべき
（抽象的な表現を都合のいいように解釈してくれると勘違いするな！！）
つまり、>>165で書かれたイメージを上司に話すことが第一歩になる
職場の異動希望、成功を祈るよ
0168161=164
2013/12/23(月) 11:58:17.32ID:???すいません。気を付けます。
>>167
ご指摘ありがとうざいます。
インフラ設計、構築の仕事を希望していたのは、元々オラクルの
資格勉強をしていてDBのソフトの設定等に興味があったからなんですよね。
異動希望が絶対に叶うように頑張ります！
0169NAME IS NULL
2013/12/23(月) 13:12:23.81ID:Sfh6mz3Q0170NAME IS NULL
2013/12/23(月) 13:22:59.12ID:???「絶対」は「絶対」にないの？ (w
0171NAME IS NULL
2013/12/23(月) 13:38:34.43ID:hLwsZxNF障害復旧やらDBのバグ解析や回避方法などの、
実務経験とスキルを積み上げて、
ぎょうかいでなまえをしられた大企業に就職できたら
希望は叶う可能性があるかも知れないな、って思ったよ
頑張れ
0172NAME IS NULL
2013/12/23(月) 14:44:41.76ID:???ないよ
0173NAME IS NULL
2013/12/23(月) 15:49:38.08ID:???0174NAME IS NULL
2013/12/23(月) 17:58:05.61ID:???チューニングしたいって言えばなんとなく通じてくれるかもしれないけど、まぁ、具体的に話をするのが一番いい。
クエリ改善も含まれるけど、それだって大切な仕事だ。
0175NAME IS NULL
2013/12/23(月) 18:43:42.31ID:???C の構成は idA, idB しかない。
インデックスは idA,idB それぞれに振ってる。
あと、idA,idBでユニークインデックス振ってるんだけど
インデックス振り過ぎ？
0176168
2013/12/23(月) 20:38:47.00ID:???チューニングっていう表現だとアプリ部分も含まれるんですかね？
次の面談では上司にオラクルの資格勉強を通してDBの設定操作に興味を
持ったので各種サーバーの設計、構築、テストをするインフラ部分の仕事をしたい
という感じで伝えてみようと思います。
0177NAME IS NULL
2013/12/23(月) 20:51:07.99ID:???基本DBMSによるけど
それ(idA,idB)で主キーになってるんじゃないのか？
ほとんどのDBMSで主キーに勝手にユニークインデックス張ってるんじゃね
それ以外に自分で張ってるなら全く無駄なインデックス張ってるかもしれんぞ
(idA,idB)のインデックスとidAのインデックスが同時に使われることはないだろうし
idAのインデックスからidBを得るにはインデックスから実データの参照が必要
idAに普通にインデックス張るのは無駄かもしれん
0178NAME IS NULL
2013/12/23(月) 23:14:15.58ID:???インデックス張りの追加可否については、
そのDBを利用するアプリケーションのアクセスパスを元に判断する
たとえば>>175の例で A と B が(C を介して) m:n 関係であったとする
そしてアプリケーションのDBへのアクセスパスを分析(＊)したところ、
A の行を元に対応する B の行集合を得る操作が大半で、
その逆に B から A を得る操作はごく僅かであったとする
この場合、idA にインデックスを張ることによって、
システム全体の性能改善が期待できると判断できる
(＊)アクセスパスの分析は、以下に示す二段階で実施すべき
・アプリケーション設計時：
アクセス頻度を設計値として見積もり、DBの物理設計書(テーブル仕様書)へ明記する
・システム連動テスト時：
ログを解析し、実環境でのアクセス頻度が見積もりと一致することを確認する
0179NAME IS NULL
2013/12/24(火) 04:27:06.39ID:???パターンとしてはＡからＢを検索、ＢからＡを検索、ＡＢペアで検索の３通り
（実際にその全てのパターンでアプリが検索するとはかぎらないんだが、一応全部想定する）
いま考えるべきは
Ａから検索するときに、Ａ，Ｂの複合インデックスとＡ単独のインデックスではどっちがより有効か？
Ｂから検索するときに、Ｂ，Ａの複合インデックスとＢ単独のインデックスではどっちがより有効か？
ペアで検索するときにＡＢとＢＡでどっちの複合インデックスがより有効か
の三つじゃないかね
俺の考えでは同じ普通のインデックスなら、ＡＢの複合が有ればＡ単独のインデックスに出番はないと思うが
例外があるとすれば、ＡＢの複合よりＡ単独の方がインデックスページのＩＯ量が少なくて済むから、
超巨大なデータでそれなりのカーディナリで実データルックアップ差し引いても速いときぐらい？
実際にそんな状況が起こりえるかな？
Ｂからのパターンも同様
ペアで検索はＡとＢでどっちがカーディナリ高いかで差が出るかもしれん。大差は出ないと思うが、気になるなら
両方作ってオプティマイザに任せるのがいいかも
ということで、俺ならＡＢの複合インデックスとＢＡの複合インデックス二つだけ作っておくかな
あくまで速度メインで考えた場合だけど
0180NAME IS NULL
2013/12/24(火) 10:53:27.13ID:???みんなー！ ありがとうー！
とりあえず、(idA)単体のインデックスはすてました
0181NAME IS NULL
2013/12/24(火) 13:50:48.07ID:???0182NAME IS NULL
2013/12/25(水) 03:13:21.40ID:???自分はポストグレの入門書をかじり、サーブレットのJDBCを理解できる程度の者です。
この状態で、英語辞書のようなもの（たとえば、alcといったようなサイトのように、単語を打ち込むと日本語訳と例文がでてくるようなもの。）
を作りたいのですが、どのようにすれば効率がよく作れるのでしょうか？
0183NAME IS NULL
2013/12/25(水) 04:28:35.99ID:???どっかの業者に金払って作ってもらう
0184NAME IS NULL
2013/12/25(水) 04:57:16.91ID:???勉強も兼ねて自分でやりたいのです。
どのDBを使えばやりやすいのでしょうか？もしくはプログラミングなどを書けば利用すれば自動でできるものなのでしょうか？
0185NAME IS NULL
2013/12/25(水) 06:56:48.06ID:???低機能なものなら学生の宿題にでてもおかしくないレベルだし、まずDB使わずに作ってみたらどう。
0186NAME IS NULL
2013/12/25(水) 10:48:09.00ID:???0187NAME IS NULL
2013/12/25(水) 11:22:11.63ID:???> アクセス頻度を設計値として見積もり、DBの物理設計書(テーブル仕様書)へ明記する
アクセス頻度って何？
単位時間あたりのアクセス数とか？
で、何らかの閾値を超えたりしたら、何か物理設計を変更するとか？
0188NAME IS NULL
2013/12/25(水) 13:42:27.13ID:???普通に、必要に応じてインデックスを追加するって話だと思うよ
0189NAME IS NULL
2013/12/25(水) 13:56:26.58ID:???あなたには聞いてません
0190NAME IS NULL
2013/12/25(水) 15:17:58.00ID:???いや、それは既にできてるんです。
しこしこhsqlに入れて言って、JDBCでブラウザに表示まではできます。
しかし、あまりにも重労働すぎるので、まだここらは初心者なので、ハック的な技術があるか聞きたかったのです。
DB操作なので、そこまでプレミアムなスキルでもないとは思ってるのですが、やはり不可能でしょうか
0191NAME IS NULL
2013/12/25(水) 15:24:35.48ID:???今、何を効率が悪いと感じていて、何を重労働と感じているのかを書かないと、アドバイスのしようがない。
そして、多分その回答はスレ違いだと思われる。
このスレは、「データベース設計」のスレなので。
0192NAME IS NULL
2013/12/25(水) 16:35:30.38ID:???元ネタからinsert文でも作って流せばいいんじゃないの。
0193NAME IS NULL
2013/12/25(水) 17:10:49.53ID:???てか、DB設計となんの関係もないが
0194NAME IS NULL
2013/12/25(水) 17:28:36.48ID:???0195NAME IS NULL
2013/12/27(金) 00:27:47.60ID:???どのDB使えばいいか教えてください。お願いします。
どの本よめばいいですか？
0196NAME IS NULL
2013/12/27(金) 05:19:59.69ID:???0197NAME IS NULL
2013/12/28(土) 13:57:10.40ID:???そのあとは何をやればいいでしょうか？
0198NAME IS NULL
2013/12/28(土) 19:44:11.56ID:???0199NAME IS NULL
2013/12/28(土) 21:49:55.11ID:???そのあとはいかがすればいいでしょうか？
0200NAME IS NULL
2013/12/29(日) 00:13:12.63ID:???やってからどうぞ
0201NAME IS NULL
2013/12/29(日) 09:58:05.95ID:???月ごと、年ごとにカレンダーで一覧を表示したいのですが
student_id, year, month, day
を持つテーブルを作って、生徒が一日一回出席をボタンを押すたびに
その日をinsertするという形を考えました。
もっとうまい方法があれば教えて頂けないでしょうか。
よろしくお願いします。
0202NAME IS NULL
2013/12/29(日) 10:13:47.42ID:???の間違いです。すみません。
0203NAME IS NULL
2013/12/29(日) 13:52:18.62ID:???> year, month, day
Date 型でいいんじゃね？
0204NAME IS NULL
2013/12/29(日) 16:47:09.07ID:???要件がそれだけならそれでいいんじゃね、としか言えないな
うまいって言うのは、何がどうなってればうまいと思うの？
今何がまずいと思うの？
0205NAME IS NULL
2013/12/29(日) 17:31:09.27ID:P0pfEg/ADate型を初めて知ったのでググってみます。
>>204
これでいいのか自信が無かったのでお聞きしました。
プログラムとか経験ないのに作れと無茶振りされたもので…
0206NAME IS NULL
2013/12/29(日) 18:15:46.26ID:OD3whmkM0207NAME IS NULL
2013/12/29(日) 19:34:23.48ID:???同じidでも時刻入りで入力は全部記録するべきと思う
0208NAME IS NULL
2013/12/29(日) 20:03:04.43ID:???なんでそんな面倒な設計にするんだ...
0209NAME IS NULL
2013/12/29(日) 20:37:58.37ID:???0210NAME IS NULL
2013/12/29(日) 22:51:20.12ID:???まあ、億オーダーのレコード数でもなければ普通に日付型で良いだろうけど
いまどき日付型のないDBMSとか有るかな？
0211NAME IS NULL
2013/12/29(日) 23:55:12.54ID:???0212NAME IS NULL
2013/12/30(月) 00:11:28.56ID:???数字８ケタとかなら大差ない気はするけど
日付型はうっかり変換関数とかにかけて悲惨な事になったりすることも
まあ、最近のDBMSなら関数噛ませてインデックスに出来るやつもあったような
0213NAME IS NULL
2013/12/30(月) 00:21:17.18ID:???0214NAME IS NULL
2013/12/30(月) 00:32:23.64ID:???国内だと年毎＝年度毎だったりするから、
年月日別より年月と日の方が扱いやすいかもしれない。
列結合の検索（INDEXききづらい）や複数項目使った範囲検索すればいいって
話だけど、単項目の検索のほうが楽だし、バグも当然少ない。
INDEXも明確にわかりやすい。
初心者みたいだし、日付型の項目を一緒に作っておいて、
登録データを見ながら、やってみてはどうだろうか。
0215211
2013/12/30(月) 00:58:10.60ID:???ああ、ごめん。
数字8桁のほうがインデックス効きやすいと言ってるのかと勘違いしてた。それなら納得。
書いてくれてるように、式インデックス使えるならそれ使ってもいいね。
0216205
2013/12/30(月) 03:13:16.40ID:???＞日付型の項目を一緒に作っておいて、
＞登録データを見ながら、やってみてはどうだろうか。
このやり方でやってみようと思います。
皆さんありがとうございます。
0217NAME IS NULL
2013/12/30(月) 03:41:44.12ID:???要件として不要とわかってるならいいんだが
0218NAME IS NULL
2013/12/30(月) 04:09:56.25ID:???日付型と年月日の数字で実データ持つって、１０年前のRDBMSならともかく今時ありえんわ
0219NAME IS NULL
2013/12/30(月) 09:35:37.71ID:???> このやり方でやってみようと思います。
なんでそれを選択するかなぁ...
0220205
2013/12/30(月) 09:56:38.07ID:???あまりいいやり方ではないのだろうなというのはわかるのですが
date型のwhere句の書き方がわかっていないからです。
int型で年、月、日を持っていれば
where year = 2013 and month = 12
のように書けばいいのはわかります。
来月4日までに完成させないといけないという時間的な問題もあるので
とりあえず動くように作っておいて後からdate型だけに統一するつもりです。
0221NAME IS NULL
2013/12/30(月) 12:45:50.34ID:???大抵の DBMS には Year とか Month とかの関数があるかも、ぐらいは思い付かない？
まあ、期限あるならしょうがないかもな。
0222NAME IS NULL
2013/12/30(月) 13:02:36.69ID:???カラムに対して、関数つけて検索しないってのはある種のお約束じゃないか？
date型where句の書き方も曖昧みたいだし、
最初は自分のイメージを形にする方優先でいいと思う。
俺は>>220には賛成
0223NAME IS NULL
2013/12/30(月) 13:09:39.20ID:???同じ情報を二つ持つのはやめなさい
手間とトラブルを増やすだけだから
0224NAME IS NULL
2013/12/30(月) 13:44:47.82ID:???Date型は必要だと思ったときに足せば良いだけだから最初はいらないんじゃないか？
たださ、インデックスの問題で年月のが有利ってのは理解できないぞ
0225NAME IS NULL
2013/12/30(月) 14:25:39.38ID:???あったので、年・月・日と個々に項目を持った場合、
年と月の複合キーか、年のINDEX、月のINDEXを個々に持つ。
仕様が年別と月別の一覧表示なら（集計のみを考えた場合）、
画面上のYYY年MM月をYYYYMMで検索の方がいいかなと。
これならINDEXも１つでいいし。
最近年月単位のパーティションとか作ってたから、頭がかたまってるかもしれん。
有利ってのはちょっと違うな。すまん。
0226NAME IS NULL
2013/12/30(月) 14:29:10.94ID:???それが分かりやすいということについては分かる。
ただ、下期の一覧を出したい場合、たとえば、2012/10 ～ 2013/3 を抽出したいときが面倒だよってぐらいかな。
来月4日までに作らないといけないって、たぶん、12月サボったツケだろうからがんばれとしか言いようがない。
0227NAME IS NULL
2013/12/30(月) 21:56:26.34ID:???ＤＢ設計うんぬんより、ホストアプリでちゃんとプログラム組めるのかね
0228NAME IS NULL
2013/12/30(月) 22:15:20.28ID:???マジだったら、まずは Excel でやれって言うわ。
Excel で手に負えないならそもそも 1月4日 なんて無理だろうし。
0229NAME IS NULL
2014/01/14(火) 13:38:32.08ID:oHMfQEMd0230NAME IS NULL
2014/01/14(火) 14:07:05.29ID:???まずは、普通に正規化すればいい。
検索に時間がかかるほどのデータ量の場合は、「転置インデックス」とかでググれ。
0231NAME IS NULL
2014/01/14(火) 15:59:56.77ID:???＞転地インデックス
そうか。各「OR検索」のフラグは、ユニークな文字列として全文検索用の別テーブルにスペース区切りで入れ、OR検索は全文検索に変えればいいのか！
ttp://dev.mysql.com/doc/refman/5.1/ja/fulltext-search.html
0232NAME IS NULL
2014/01/23(木) 00:18:44.56ID:???MySQLの全文検索で検索自体はできることが確認できたのだけれど、任意のカラムで全文検索とは別の索引を使用した高速なソートができないことが判明。
別の索引でソートする機能はTritonnではできていたのに、
ttp://qwik.jp/tritonn/userguide.html#0cb0baa8b27d86e9233f601a9cc9cc4f
mroongaではできないっぽい。
どうしたらいいんだ。
0233NAME IS NULL
2014/01/23(木) 22:53:35.79ID:???ttp://mroonga.org/ja/blog/2013/12/29/release.html
できるようになってたっぽい！
0234NAME IS NULL
2014/02/01(土) 12:29:02.11ID:???0235NAME IS NULL
2014/02/02(日) 16:02:38.86ID:???ダサいとかいう考え方がおかしいんだが
住所から導出できるだろうとか言う話なら要件次第
経緯まとめた項目ないかってならDBMS次第
0236NAME IS NULL
2014/02/02(日) 16:59:37.09ID:???要件がパッと思い浮かばないんだけど、何かあるんかね
どういう要件があるのかってところが分からんと良いとも悪いとも言えん
0237NAME IS NULL
2014/02/02(日) 17:36:05.55ID:???0238NAME IS NULL
2014/02/02(日) 21:56:03.62ID:???0239NAME IS NULL
2014/02/02(日) 22:26:05.91ID:???0240NAME IS NULL
2014/02/02(日) 22:41:59.84ID:???0241NAME IS NULL
2014/02/02(日) 22:43:07.74ID:???どこから「常に」なんて要件持ってきたんだ？
0242NAME IS NULL
2014/02/03(月) 12:35:21.28ID:???じゃあときどきでいいよ
顧客の位置をときどき把握しないといけないってどういう業務？
0243NAME IS NULL
2014/02/03(月) 13:41:30.16ID:???上でいっぱい言われてるだろ
不動産とか運輸業界とか、位置情報をもってるシステムはけっこうあるぞ
昔は緯度経度だけもっててもあまり役に立たなかったんんだが、最近では地図サービスが充実してるからなぁ
0244NAME IS NULL
2014/02/03(月) 14:37:34.37ID:???国内で稼働する全車両の位置情報が把握できる
詳しくは「コマツ GPS」でググレ
0245NAME IS NULL
2014/02/04(火) 07:04:37.83ID:???そうでなく顧客に直接紐付けというところに引っかかりを覚える
まあどうせ>>234はもう見てないだろうけど
0246NAME IS NULL
2014/02/04(火) 07:52:16.70ID:???海外も把握してなかったっけ？
0247NAME IS NULL
2014/02/04(火) 11:49:31.30ID:???0248NAME IS NULL
2014/02/16(日) 09:53:05.01ID:???どうやってテーブル化するべきでしょうか？
たとえば、
class 予定
{
日時;
場所;
};
class 買い物: 予定
{
vector<品目> 買い物リスト;
};
class 訪問: 予定
{
用件;
};
こんな感じのクラス階層のものです。
CREATE TABLE ScheduleHeader
(
int id;
datetime 日時;
text 場所;
int 予定タイプ; // 0 = 買い物, 1 = 訪問...
);
みたいにして、予定タイプを読んでプログラム側で詳細の取得先を切り替えるようにするのかなと思ったのですが、普通はどうするのでしょうか？
0249NAME IS NULL
2014/02/16(日) 15:53:10.15ID:???大きく分類すると３つある
(1) シングルテーブル継承
３つのクラス 予定/買物/訪問 を単一のテーブルで実装する
(2) クラステーブル継承
３つのクラス 予定/買物/訪問 を個別のテーブルで(=3つのテーブルで)実装する
(3) 具象テーブル継承
具象クラス 買物/訪問 だけをテーブルとして(=2つのテーブルで)実装する
それぞれに利点/欠点があってここでは書ききれないけど、
多くのORMは(たとえば Ruby on Rails の ActiveRecord は)
最も単純なシングルテーブル継承を基本としてサポートしている
詳しくは、以下の書籍(通称 EoA本)を読むべし
・エンタープライズ アプリケーションアーキテクチャパターン: マーチン・ファウラー
http://www.amazon.co.jp/dp/4798105538/
0250NAME IS NULL
2014/02/16(日) 16:54:02.82ID:???個人的な意見ではあるが「DB設計」という視点からすれば、以下の問題がある
（これはEoA本では触れられていない）
(a) 買物インスタンスのテーブルでは用件カラムが、訪問インスタンスでは
買物リストカラムが nullable になるので、検索時に潜在的なバグを生みやすい
(b) (a) によって参照性制約を設定できなくなるため、
DBのデータ一貫性が損なわれる可能性がある
(c) 一つのテーブルに複数のエンティティを実装することになるため
インデックス設計が複雑になり、性能問題を引き起こしやすい
従って、>>248 (2) のクラステーブル継承を推す
この方式については、EoA本では複数テーブルのJOIN操作が性能上で不利と書かれている
しかし、現実的なハード構成、簡潔なエンティティ、適切なインデックス設定、そして
SQLの知識を前提とすれば、経験上、数万件のオーダーで性能問題は起きたことがない
それでも現実にはシングルテーブル継承が主流なのは、ORMの採用による
システム開発の効率化優先(およびDB設計の相対的軽視)が背景にあると考える
0252NAME IS NULL
2014/02/16(日) 18:25:03.41ID:???ありがとうございました、キーワードが分かっただけで検索がだいぶ楽になりました。
問題の本は、ちょっと高いので行き詰まったら購入を検討したいと思います。
構造的にはクラステーブル継承が好みですが、シングルテーブルなんてのもあるんですね
これは、真っ先にしかられるタイプの構造だと思ってました
0253NAME IS NULL
2014/02/17(月) 03:14:40.87ID:???そんなところまでしばられちゃ正規化も何もあったもんじゃないんじゃないの。
(2)か(3)のどっちかで済ませるのがいいけど、まぁ、(2)は>>248で思ってたやり方そのままかと。
予定タイプを持つことの是非は状況次第。
あと、そもそも論だけれど、数万件のオーダーでしか話せない人は基本的に信用してはいけない。
ついでに、コンポジットパターンじゃないよね、それ。
0254NAME IS NULL
2014/02/17(月) 15:46:39.31ID:???> ついでに、コンポジットパターンじゃないよね、それ。
マジでこれ。
つか、RoR馬鹿は黙ってて欲しい。
0255NAME IS NULL
2014/02/17(月) 16:12:59.95ID:???というのが普通な気がするが。
0256NAME IS NULL
2014/02/17(月) 18:21:51.34ID:???0257NAME IS NULL
2014/02/20(木) 02:43:39.28ID:???どうやって設計するのがいいの?
シフトJISの頃だと、漢字や平仮名は1文字2バイトだって前提で
漢字10文字入れたい→20バイト、なんて風に設計してたけど、
UTF-8だとどうなんだろう
エンドユーザ側は、どの文字がUTF-8だと3バイトなのか、
4バイトになるのか、なんて意識してないよね
1文字3バイトが多いから30バイト、でいいのだろうか
でもそれだと、漢字10文字入れたいって場合に、4バイトの漢字だと
10文字入らなくなっちゃうよね
逆に4バイトの文字を考慮して40バイト、とすべきなのだろうか
でもそうすると、3バイト文字を13文字詰められちゃうから
変な不整合を起こしそう
0258NAME IS NULL
2014/02/20(木) 12:49:30.10ID:???DB全体での容量計算の話なら文字コードUCSにすりゃいいんじゃないですかね(適当
0259NAME IS NULL
2014/02/20(木) 17:21:34.45ID:???まあ、平均的なパターン見るか最悪のケースで見とくか
俺なら最悪のケースだけ計算しとくけど
0260NAME IS NULL
2014/02/20(木) 19:20:16.03ID:???固定長カラムを作らなくなって久しいので、そう悩むことがなかった。
0261NAME IS NULL
2014/02/20(木) 22:07:05.92ID:???DB全体の容量見積もりというよりかは、単なる列長の考え方、だと思ってます
Oracleでいう、ncharとかnvarchar2を使ってテーブルを作る、が標準なのでしょうかねぇ
ncharは使わずchar、という案件ばかりだったのですが、UTF-8を採用している案件って
実際のところ、ncharとか使ってるものなのでしょうか
>>259
容量計算する場合は、平均文字数はX文字と想定する、という要件があるので、
それで計算すればいいのかな、と
とはいえ、じゃあ1文字は何バイトなのよ?というのもあるかな、と
>>260
最大を大きめの可変長で作っておけばよかろうとは思っているのですが、
漢字30バイトの列には漢字が何文字入るの?と問われたときに、文字によって8文字～10文字、
では都合が悪かろうな…とも思ってまして…
うーむ
0262NAME IS NULL
2014/02/20(木) 22:20:27.32ID:???漢字がまともに扱えるDBMSなら指定は文字数なのが一般的なんじゃ？
漢字の想定の無い項目に漢字いれるとか恐ろしすぎる
0263NAME IS NULL
2014/02/20(木) 22:28:19.51ID:???0264NAME IS NULL
2014/02/20(木) 22:59:24.51ID:???すいません、30バイトの列には漢字は何文字入るの?でした
NCHARで文字数指定する、一般的なのでしょうかね
漢字だろうが英数字だろうが、CHAR(n)で入るバイト数を指定、漢字は2バイト、と
これまでやってきたため、その考え方の変更が必要そうですね…
0265NAME IS NULL
2014/02/21(金) 00:24:39.50ID:???少なくともデータ長に関しては無頓着にクエリを発行して、
データベースエラーを元にvalidateを行おうとしているの？
> 逆に4バイトの文字を考慮して40バイト、とすべきなのだろうか
> でもそうすると、3バイト文字を13文字詰められちゃうから
> 変な不整合を起こしそう
0266NAME IS NULL
2014/03/13(木) 16:48:47.68ID:iuRydHHe・会員情報（アカウント名、パスワード、メールアドレス
・プロフィール（性別、生年月日、写真、コメントなど）
を、1つのテーブルにするべきですかね？分けるべきですかね？
1対1なんで1つの方が良いとは思うのですが、
後々プロフィールのカラムを追加する可能性もあるので、
分けたほうがいいのかなとも思います。
オススメの方法・考え方を教えて下さい。
0267NAME IS NULL
2014/03/13(木) 20:14:22.01ID:???参考書レベルの正規化では第2正規形にするあたりで別表にしそうなものだが、
実際問題としては、それ系のテーブルというものは、カラムの追加がないのなら、
無理に分ける必要は無い
性別、生年月日なんかも、分けて書いてる教科書もあるけど、異端をのぞいちゃ
変わるものでもないのだから会員情報テーブルに置いときゃOK
コメント2、コメント3、みたいなカラムの追加が予定されているなら、
プロフィールのその部分だけ別表に分けたほうがよかろうな
テーブルをは、教科書にそれで分けてる事例が書いてあるからって程度の理由で
分けるもんじゃない
運用でおかしくならないかどうかって観点で分けるのだ
0268NAME IS NULL
2014/03/13(木) 20:47:38.42ID:???どこの世界の第2正規形の話をしてるの？
なんかカラムの追加が発生しうるテーブルは分割するのが基本だが、実際は～みたいな言い回しだけど。
> 変わるものでもないのだから会員情報テーブルに置いときゃOK
これも、まるで理解できない。パスワードも異端をのぞいちゃ変わるものでもないってこと？
それとも、俗にいうマスタとトランの分割の話かな。
0269NAME IS NULL
2014/03/13(木) 20:55:57.98ID:???見えないモノを見ようとしてモニタを覗き込んだのであった
0270NAME IS NULL
2014/03/13(木) 21:00:59.77ID:???変わるものなら会員情報に置かないほうがいいってことでしょ。
じゃあ、パスワードは変わらないの？ってことだけど。
0271NAME IS NULL
2014/03/13(木) 21:03:08.62ID:???お前は今まで性別や生年月日を何回変えた?
0272NAME IS NULL
2014/03/13(木) 21:04:55.34ID:???だからおかしいでしょ？
性別や生年月日は変わらないから会員情報に置けばいいよっていうなら、
変わるパスワードは会員情報から追い出さなきゃいけない。
0273NAME IS NULL
2014/03/13(木) 21:10:20.38ID:???追い出したけりゃ、追い出せばいいんじゃね?
ところでその唐突に出てきたパスワードって、何の話なのだ
0274NAME IS NULL
2014/03/13(木) 21:17:30.23ID:???「変わらないんだから分割する必要ない」
ということは
「変わるものは必ず分割する」
ということと、等価ではないよ
私は>>267が指摘している、性別や生年月日をまで別テーブルに分割する必要はない、
という見解には同意できるけど、でもパスワードは変更するから云々というのは、
飛躍しすぎだと考える
0275NAME IS NULL
2014/03/13(木) 21:25:43.82ID:???もともと会員テーブルにあるカラムのことだけど。
>>274
変わろうが変わるまいが分割する必要はないという主張をするのなら、
変更されるのがまれかどうかという話は必要ないでしょ。
だから、まるで理解できないと書いた。
0276NAME IS NULL
2014/03/13(木) 21:33:46.78ID:???↑この教科書とやらがどういうポリシーで分けたかを書かないとどうにもならんよ
0277NAME IS NULL
2014/03/13(木) 21:36:48.99ID:???韓国では自己申告によって誕生日を変更できるらしい
また、日本でも性別に関して一度だけなら現実に変更は起こりうる
まあ、これらはどちらも極端な例かもしれないがね
それはさておき、会員情報には現実に何度も変更される事を想定すべき項目もある
たとえば郵便番号/住所/電話番号/メールアドレスは引っ越し等で変わる
もしも想定しているサービスがSNS等であるなら、
最新の情報さえDB上に記録されていれば十分かもしれない
しかし、仮にサービスがオンラインショップの会員であり、
過去に遡って全会員を対象にした購買傾向を追跡/分析したいのであれば、
ある会員IDに対する変更履歴情報をDB上に格納する方法も選択肢になる
つまり>>266に対して言いたい事とは、会員情報を実装するのにテーブルが１個ですむのか
複数必要になるのかは、提供しようとするサービスの業務分析によって決まる、ってこと
で、もしも業務分析の初期段階にあって決定できないのなら１個にまとめる
何となく必要になりそうだから...という曖昧な理由による複数テーブル化は、
DB設計に無駄を追加するだけの無益な行為である
0278NAME IS NULL
2014/03/13(木) 21:38:05.27ID:???つまり、分割する必要なない、と思ってる、ということでよい?
何だかよく分からん
0279NAME IS NULL
2014/03/13(木) 21:42:52.06ID:???会員テーブルにあるパスワードはへんだから別テーブルにしろ、といいたいのか?
それなら>>266にそう言ってやればよろしかろう
俺にも、お前が何を言いたいのか分からん
>>277
これに一票
0280266
2014/03/13(木) 21:52:34.35ID:iuRydHHe>>266の質問は新規サイトを作る時にいつも悩むのでして、
自分の性格からか、どうしても汎用性の高い仕様にしたく思い、
2つのテーブルに分けています。
しかし、selectする時も面倒くさいし、画面設計も多くなります。
だからと言って、絶対に後からカラムがしないとも言い切れないし、
ECではなく、コミュニティ関係のサイトでも
複数の住所とか画像とか登録したくなるかもしれません。
そんなこんなを考えると、DB設計がなかなかまとまらないんです。
0281266
2014/03/13(木) 21:56:14.20ID:iuRydHHeほぼ無かったように思います。ECサイトは作っていませんが。
だからやっぱり「迷ったら1つにしろ」っていう
>>277さんの意見が正しいんですかね。私自身が心配し過ぎというか・・・
0282NAME IS NULL
2014/03/13(木) 22:07:27.12ID:???画面設計が増えるの？
0283266
2014/03/13(木) 22:09:51.65ID:iuRydHHeはい。会員情報とプロフィールなら画面が2つ分かれます。
有名所だと、ヤフーもそうだと思います。
0284NAME IS NULL
2014/03/13(木) 22:11:07.41ID:???テーブルを分けることとは関係なくない？
0285266
2014/03/13(木) 22:12:13.75ID:iuRydHHe0286NAME IS NULL
2014/03/13(木) 22:18:38.92ID:???俺が学んだのと違うな
0287NAME IS NULL
2014/03/13(木) 22:29:45.44ID:???迷ったら一つにする、というのは誤りではないが、必ずしも正解でもない
基本通りに分割する、というのも誤りではないが、やはり必ずしも正解でもない
何事にも限度がある
その限度のガイドラインとなるのは、やはり業務と仕様かと
ひとテーブルにまとめるなら、これは分割する必要なさそうだけど、一緒でよい?と、
逆に分割するなら、例えばプロフィールは今後増える?増えるなら分割しないとだぜ?
みたいなことを開発側と練っていって、より正解に近い方を選んでいくもので、
DB担当一人で悩む所ではないかなと
マスターベーション的に分割するという行為には、あまり価値がない
0288NAME IS NULL
2014/03/13(木) 22:47:16.13ID:???変更されるカラムがあるけどそれはいいのか？って思うだけだ。
前置きをするからには何らかの理由があったはずだ。
>>278
分割の必要はないと思ってるよ。
変更されないから同じテーブルに置いていいよという前置きの意味が分からないだけだよ。
>>279
何も変じゃないよ。同じテーブルに置けばよい。
変更されるかどうかなんて気にせず置けばよい。
>>280
クラス分割とテーブル分割を混同してはいけない。
OR/Mによってテーブル設計を縛られてはいけない。
それだけだよ。
0289266
2014/03/13(木) 22:50:05.61ID:iuRydHHe相談できる相手がいればいいんですけどね・・。
あまりDB設計の事例ってネット上に無いですし、
どうすれば良いか悩むんですよね・・・。
0290NAME IS NULL
2014/03/13(木) 23:22:34.49ID:???定型的にこうすればよい、という手法が無いからね
ネットなりで示される事例というのも、当該の案件ではそうした、というだけであって
どんな場合にも通用するわけじゃないし
抽象的なDB設計手法の情報を得つつ、具体的な案件で活用し、また別の事例を学び、
前回の案件での反省を踏まえて、みたいな手探りの繰り返しで、センスや勘所を
磨いていく、だろうかねぇ
ただベースとなるところは持つべきで、それはDBの基礎知識だったり、DBはどうあるべきか
みたいな思想だったり、無駄や過剰を判断する自分なりの基準だったりして、さ
それはアーキテクチャやNWも同様なのだけれどね
0291NAME IS NULL
2014/03/13(木) 23:39:05.90ID:???>過去に遡って全会員を対象にした購買傾向を追跡/分析したいのであれば、
>ある会員IDに対する変更履歴情報をDB上に格納する方法も選択肢になる
>
>つまり>>266に対して言いたい事とは、会員情報を実装するのにテーブルが１個ですむのか
>複数必要になるのかは、提供しようとするサービスの業務分析によって決まる、ってこと
履歴テーブルを追加するかどうかと、会員情報とプロフィールを分けるかどうかは関係ないよね…？
会員情報テーブルに履歴ももたせるという発想は、SNSではあり得ないし。。
0292266
2014/03/13(木) 23:59:55.50ID:iuRydHHe小規模なサイトなら1テーブルに済ませるように考えたいと思います。
0293NAME IS NULL
2014/03/14(金) 00:00:47.83ID:???会員情報を独立させて、暗号化させとけば情報漏えいは減ると思うし。
思想っていうか方針の問題だと思う。
正解はないよね。
0294NAME IS NULL
2014/03/14(金) 00:30:43.94ID:???0295NAME IS NULL
2014/03/14(金) 03:02:55.53ID:???それ思想でも方針でも無くて、セキュリティ要件
何らかの要件でわける必要があればわければ良いけど
今回の例でわける必要もメリットもあるようには見えんが
0296NAME IS NULL
2014/03/14(金) 15:45:55.14ID:???0297NAME IS NULL
2014/03/16(日) 05:05:46.88ID:JOrCCh2Qひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
0298NAME IS NULL
2014/04/01(火) 18:57:09.58ID:uRrxpLcGゲームのデータベース作ってるんですが、うまく正規化ができなくて困ってます。
・プレイヤーは１つのチーム編成を持っている
・プレイヤーは複数のキャラクターを持っている
・チーム編成は同じプレイヤーのキャラクターを最大8つ登録できる
・チーム編成の1番目のキャラクターをリーダーとするため、チーム全体の順番を保存したい
・キャラクターは１つのチーム編成にしか登録できない
・キャラクターは１つのチーム編成に１つしか登録できない
パズドラっていうソーシャルゲームのチーム編成っぽい感じです。
どうしたらいいですか？
0299NAME IS NULL
2014/04/01(火) 21:45:48.50ID:???> ・キャラクターは１つのチーム編成にしか登録できない
> ・キャラクターは１つのチーム編成に１つしか登録できない
つまりチーム編成とキャラクターは一対多の関係だと言いたいのかな、これ
キャラクターIDが一意なサロゲートキーなのか重複しうる種別IDなのか
曖昧なのが混乱を誘っているように見える
まずは主キーがどれか整理して考えるとこからじゃないかな
0300NAME IS NULL
2014/04/01(火) 22:32:06.40ID:???自分には、文章で書かれた要求に従って、適切に設計されているように見える
少なくとも第１／２正規化は満たしているから、
それ以上の正規化にはこだわらなくてもいいのではないかと思う
0301NAME IS NULL
2014/04/02(水) 00:43:45.08ID:???キャラクターが複数のチームに登録されてるように見えるよ。
0302NAME IS NULL
2014/04/02(水) 11:43:52.19ID:nZFSMvfa0303NAME IS NULL
2014/04/02(水) 12:03:59.63ID:???チーム編成テーブルの主キーは
プレイヤーIDとキャラクターIDでいいんじゃないの？
自分が設計すると、チームを別途に作ってしまうな
> ・キャラクターは１つのチーム編成にしか登録できない
これって必要？結果としては出てくるんだけど、要件なのかなーってね
0304NAME IS NULL
2014/04/02(水) 13:07:55.98ID:???>> ・キャラクターは１つのチーム編成にしか登録できない
>これって必要？結果としては出てくるんだけど、要件なのかなーってね
システムの要件としては必要なんだろ
問題はどこまでDB側で保障するかって話
これを保証したいなら、キャラクターテーブルにチーム編成の主キー(ID)持たせろって事になる
同様に
>・プレイヤーは１つのチーム編成を持っている
これも保障したいならプレイヤーテーブルにチーム編成のID持たせる
俺ならこのレイアウトのまま、登録するアプリでチェックするけど
チーム編成の主キーは(プレイヤーID,キャラクターID)か(プレイヤーID,キャラクターID,番号)かだな
0305304
2014/04/02(水) 13:14:40.81ID:???に訂正しとく
0306NAME IS NULL
2014/04/02(水) 13:57:02.95ID:???>>299に答えないと進まないと思う。この部分。
> キャラクターIDが一意なサロゲートキーなのか重複しうる種別IDなのか
見た感じ一意なものだと予想してるんだけど。つまりスライムじゃなくスラりんだと。
0307NAME IS NULL
2014/04/02(水) 16:03:44.52ID:???> 俺ならこのレイアウトのまま、登録するアプリでチェックするけど
いやー、データベースで一意性制約つけられるスキーマにしたほうがいいって。
0308NAME IS NULL
2014/04/02(水) 16:24:39.19ID:???大体同意見。
>自分が設計すると、チームを別途に作ってしまうな
将来的に複数チームを持たせられるようにすることを考えればそうしたくなるね。
ソシャゲだと複数デッキ登録しておける場合が多いし。
>> ・キャラクターは１つのチーム編成にしか登録できない
>これって必要？結果としては出てくるんだけど、要件なのかなーってね
ね。キャラクターが1ユーザにしか紐づかないのであれば、自然と1つのチームにしか登録できないよね。
>>304
>>> ・キャラクターは１つのチーム編成にしか登録できない
>>これって必要？結果としては出てくるんだけど、要件なのかなーってね
(snip)
> これを保証したいなら、キャラクターテーブルにチーム編成の主キー(ID)持たせろって事になる
そうしてもいいし、そうしなくてもいい。すでに保証されてる。
>>・プレイヤーは１つのチーム編成を持っている
>これも保障したいならプレイヤーテーブルにチーム編成のID持たせる
同様。
よって、その制約を守るためにアプリでチェックする内容に変化はないだろう。
何か勘違いしたまま書いたんじゃないかな。
0309NAME IS NULL
2014/04/02(水) 16:32:34.21ID:???そうです。
ひとつのチームにキャラクターが複数存在します
ポケモンみたいなイメージです
0310NAME IS NULL
2014/04/02(水) 16:35:19.06ID:???キャラクターテーブルはそのまま、レコード一件につきキャラクター一体を表します。
情報量少なくて申し訳ありません。
0311NAME IS NULL
2014/04/02(水) 16:42:43.89ID:???チームテーブルは
*チームID
*順番
プレイヤーID
キャラクターID
こんな感じで、何人か仰っているように
「一つのチームに同じキャラクターは登録できない」
という条件に絞った方が綺麗に正規化されているのでしょうか
0312NAME IS NULL
2014/04/02(水) 16:44:58.34ID:???すいません、間違えました
*プレイヤーID
*チーム番号
*順番
キャラクターID
という感じです
0313NAME IS NULL
2014/04/02(水) 16:47:10.43ID:???それは正規化できてないよ。
チームに8キャラクター登録できるということを踏まえると、
ひとつのチームの情報に、プレイヤーIDが繰り返し8回出てくることになるでしょ。
複数チームを想定しつつ、正規化をするなら、
プレイヤー-チーム
*プレイヤーID
*チームID
チーム
*チームID
*順番
キャラクターID
加えて、チームID、キャラクターIDでユニーク制約をつけておけばいいかと。
0314NAME IS NULL
2014/04/02(水) 16:53:15.69ID:???無駄がなければすっきりする。
その上で、
・チームに所属できるのは8キャラクターまで
・チーム数はひとつのみ
・プレイヤーが所有権を持つキャラクターのみチームに属することができる
という、制約が必要になってくる。
これは、DBMSがもっている制約で行うこともできるが、アプリでもやることがほとんど。
0315NAME IS NULL
2014/04/02(水) 17:02:10.65ID:???それでもいい。
0316NAME IS NULL
2014/04/02(水) 17:36:20.74ID:???ユニーク制約ってよく分からないんですが、
一意だけどキーにはしないという感じの制約ですか？
0317NAME IS NULL
2014/04/02(水) 17:37:20.91ID:???これだと、別のプレイヤーが同じチームを持ってしまいませんか？
0318NAME IS NULL
2014/04/02(水) 17:38:12.74ID:???両方野郎と思います！
0319NAME IS NULL
2014/04/02(水) 17:49:21.65ID:???ユニークキーといったりもするよ。一意であることを示すものだね。
プライマリキーはそもそもユニーク制約もかねてる。
>>317
持たせようと思えば持たせられるね。
ところでそれは>>312でも同じですね。
0320NAME IS NULL
2014/04/02(水) 17:55:00.02ID:???・複数プレイヤーが同じチームを持てる(当然、他人の所持キャラクターを含む)
・順番さえ違えば同じチームに複数の同キャラクターを持てる
みたいな愉快な事になるねw
0321NAME IS NULL
2014/04/02(水) 18:01:47.35ID:???二つ目は>>313でも言及してるけど、ユニーク制約で対応だね。
チーム、順番はユニークであるべきだし、
チーム、キャラクターIDもまた、ユニークであるべきだ。
PKだけでは対応できない。
同じ意味で、>>304がプレイヤーID、キャラクターID、番号の3項目をPKにするというのはおかしな話。
0322NAME IS NULL
2014/04/02(水) 20:53:31.23ID:???>キャラクターが1ユーザにしか紐づかないのであれば、自然と1つのチームにしか登録できないよね。
キャラクターは他のユーザーのチームに参加できない、という要件を勝手に想定してないか？
0323NAME IS NULL
2014/04/02(水) 20:53:34.87ID:???一つ目ってそうなりますか？
キャラクターが、同じテーブル内のレコードで他に存在してはいけない
という制約があるので
「プレイヤー1の1番目のチームの1番目のキャラクターはこれだけだ！」と、特定できる、かつ他のチームにそのキャラクターはいない
となると思ったんですが
0324NAME IS NULL
2014/04/02(水) 20:54:39.01ID:???すいません、書き忘れです・・
0325322
2014/04/02(水) 20:59:31.50ID:???無かった事にしてくれ
個人的には有る程度ゆるく作っとかんと、テーブルレイアウト変えるのは大変
アプリ修正の方が工数が軽いから、チェック類はアプリでやる方が良い場合が多い
と思う
0326300
2014/04/02(水) 22:51:12.12ID:???まず>>298の単一チーム要求仕様について、
>>300で述べたように、実装設計(論理モデル)としてよく考えてあると思う
ここで、>>298のチーム編成テーブルとは概念モデル(ERモデル)上のリレーションを実装した
いわゆる Junction Table (訳語は結合テーブル、交差テーブル...等々、>>8を参照)であり、
プレイヤーテーブルやキャラクターテーブルのように単独の主キー(PK)を持たず、
代わりにFKの複合キーを主キーとして用いる
また、その具体的な主キーの論理設計については、>>304,305に賛同する
次に複数チーム要求仕様について、
個々のチームを識別できるようにするため単独の主キー(PK)が必要になることから、
概念モデル上では(リレーションではなく)エンティティとして設計しなければならない
この変更に伴い、チーム編成テーブルは(プレイヤーとキャラクターとの間の関係ではなく)
チームとキャラクターとの間の１対n関係へと変更する
これらをまとめたものを以下にアップした
http://www.h6.dion.ne.jp/~machan/misc/role-playting-game.png
この図の左側にある単一チーム版の設計図については、先に述べたように>>298とは
作図法(=表現方法)が異なるだけで、意味的に同じものになる
0327NAME IS NULL
2014/04/02(水) 22:53:02.63ID:???> キャラクターが、同じテーブル内のレコードで他に存在してはいけない
という制約があるので
テーブルにそういう制約があるなら、>>311-312で明記しる
要件とデータ定義をごっちゃにすんな
0328NAME IS NULL
2014/04/02(水) 23:18:24.65ID:???DBを扱うアプリケーション側で制限するのも大丈夫なんですね
業務で使ったことないので勉強になります
>>327
すいません、その後のレスの流れを組んでいただけたのかと思って紛らわしいこと言ってしまいました
0329NAME IS NULL
2014/04/02(水) 23:48:12.46ID:???話の発端が分かるよう名前欄に298と入力しとけ
鳥頭の相手をするのも疲れるだろ
0330NAME IS NULL
2014/04/02(水) 23:53:15.82ID:???この画像の右下のチーム編成は、
そのチーム内での順番の一意制というのは保証されない？
0332298
2014/04/03(木) 00:03:19.54ID:???プレイヤーテーブル
*プレイヤーID
プレイヤーネーム
チームテーブル
*チームID
プレイヤーID
チーム編成テーブル
*チームID
*順番
キャラクターID(ユニーク)
キャラクターテーブル
*キャラクターID
プレイヤーID
というので第三正規化まで綺麗に出来てるでしょうか？
順番の8つまで、という制限は無理そうですが。
0334NAME IS NULL
2014/04/03(木) 00:26:58.57ID:???いいんじゃないかな
チームは8人までという制約がどうしても欲しければ
ユーザー定義関数を制約に指定したりトリガーで確認して例外を投げるとかいろいろ考えられるけど、
この辺りはDBMSの実装に依存するんで設計とは別の話になるかな
0335NAME IS NULL
2014/04/03(木) 00:48:00.02ID:???いやあ、十分分かるよ。
キャラクターはゲーム中でユニークな存在である、プレイヤーはチームを一つしか持たない、
チームには同一キャラクターを登録できない。
これを総合すれば、チームテーブル全体において、キャラクターがユニークになるのは明白だからね。
これが分からないって言ってる人は少なくとも>>328よりも設計に関する理解度が低いから安心してスルーしていいよ。
0336NAME IS NULL
2014/04/03(木) 00:53:25.65ID:???順番の値の範囲が1-8(もしくは0-7)であるような制約を課せばいいよ。
同様に、プレイヤーあたりのチーム数制限もかけられるんだけど、その場合はそのチームテーブルだとちょっと面倒になるね。
*プレイヤーID
*チーム番号
チームID
として、チーム番号に制約をかければ素直にいける。
レイアウトの好みと、制約の容易さは天秤にかけられるもの。
0337298
2014/04/03(木) 01:01:15.85ID:???大変勉強になりました！
0338NAME IS NULL
2014/04/03(木) 01:25:36.44ID:???俺は要件とデータ定義をごっちゃにすんなっつってんの
>>311-312のデータ定義で要件>>298が満たせるか、って突っ込んでんのに
「要件に書いたから分かるだろ」
じゃいかんだろ、ってこと
0339NAME IS NULL
2014/04/03(木) 03:39:14.85ID:???複数チーム構成でチームと言うエンティティが必要なのはわかるんだが
単一チームであってもチームと言うエンティティがある方が自然な気がするんだが
複数か単一かの違いは、チームとプレイヤーのリレーションの基数の問題じゃないか？
0340NAME IS NULL
2014/04/03(木) 03:57:54.64ID:???0341NAME IS NULL
2014/04/03(木) 04:34:20.68ID:???0342NAME IS NULL
2014/04/03(木) 04:42:16.58ID:???0343300
2014/04/03(木) 23:30:20.92ID:???そう、基数が１で固定のケースが単一チームと考えることもできる
ただしその場合には、チームとプレイヤーという対象物(サブジェクト)は
「必ず」１対１に対応するから、概念モデル(ERモデル)として設計する時には、
どちらか一つを選んでエンティティとして具体化するのが普通じゃないかと思う
別の言い方をすれば、はじめから要求仕様で単体チームと明確になっているのなら、
単体チームとして最適な、最も単純な解を選ぶべきだと考える
（Simple is best とか オッカムの剃刀 みたいな言葉があるよね！）
こうした考え方を元に、プレーヤーをエンティティとして選びチームを捨てるという
判断を下した >>298 の論理設計図が、(単体チーム向けとして)最適解であると考えた
0344NAME IS NULL
2014/04/04(金) 00:24:09.39ID:???「必ず」1対1の対応をするんだから分ける必要はない、つまり第三正規形なんていらないってことだよね。
わかるわかる。
0346NAME IS NULL
2014/04/04(金) 00:51:42.00ID:???チームとプレイヤーとは一般的な考えでは異なる概念だから
一つのエンティティとするのはかえってその概念モデルの理解を妨げる気がする
省略できるものすべてを省略するのが必ずしもわかりやすいという事にはならんよ
0347300
2014/04/04(金) 01:16:47.18ID:???わかりやすいとは、一言も言っていないけどな
与えられた問題に対して必要十分かつ最も簡潔な解を選ぶ
ことが望ましい、という意見だよ
0348NAME IS NULL
2014/04/04(金) 02:22:50.75ID:???うん。この場合は問題ないね。
もともと第三正規形になっていた。
ところで、>>300
> 少なくとも第１／２正規化は満たしている
これも、少なくともという言葉で濁すのかな。
0349NAME IS NULL
2014/04/04(金) 03:05:51.77ID:???で、勉強が終わったからその発言になったんじゃないかな。
今回突っ込みを入れられて第三正規形を勉強したんでしょう。
知ったかぶりの成長が見て取れる良スレ。
0350NAME IS NULL
2014/04/04(金) 07:42:09.63ID:???要件をそのまま定義に落とし込むならチーム編成テーブル自体なくていい
●キャラクタテーブルに順番カラムを追加しnullならチーム未所属扱いにする
●その上で{キャラクターID, 順番}の組でユニーク制約を持たせる
※nullがユニーク制約の対象になるDBMSもある点には注意
などとすれば>>298に書かれた要件は満たせる
ただ「やっぱりチーム編成は複数持ちたい」的な話が出る可能性は高い
>>298にユニーク制約を加えたりアプリ側でチェックするべきという回答が出たのも、それを見据えたものと思う
0351「ガスライティング 集団ストーカー カルト」で検索を！
2014/04/04(金) 14:59:22.62ID:XdgNP63l・沢山の人が偏った意見を一貫して支持する
偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法
・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法
↑マスコミや、カルトのネット工作員がやっていること
TVなどが、偏った思想や考え方に染まっているフリや常識が通じないフリをする人間をよく出演させるのは、
カルトよりキチガイに見える人たちを作ることで批判の矛先をカルトから逸らすことが目的。
リアルでもネットでも、偽装左翼は自分たちの主張に正当性がないことを自覚しているのでまともに議論をしようとしないのが特徴。
.........
0352NAME IS NULL
2014/04/04(金) 17:59:09.87ID:???これが貼られるタイミングが前スレあたりから興味深い。
やっぱ強制ID必要だわ。
0353300
2014/04/04(金) 20:48:09.77ID:???あるチームに所属するキャラクターを未所属(どこのチームにも
所属していない状態)へ変更するには、どのように操作するの？
SQLのUPDATE文では、あるカラムが有効値である時に
それをNULL値へ更新できないと思うんだけど....
0354NAME IS NULL
2014/04/04(金) 21:25:33.58ID:???update aaa set bbb = null;
0355NAME IS NULL
2014/04/04(金) 22:37:06.16ID:???> SQLのUPDATE文では、あるカラムが有効値である時に
> それをNULL値へ更新できないと思うんだけど....
何をどうがんばっても擁護できないんだけど。
update で値をNULLにできないっていってるよね？
0356NAME IS NULL
2014/04/04(金) 22:39:14.09ID:???0358NAME IS NULL
2014/04/05(土) 06:51:15.09ID:???> ●その上で{キャラクターID, 順番}の組でユニーク制約を持たせる
{所有プレイヤーID, 順番}の組、と書いたつもりだった、お恥ずかしい
0359NAME IS NULL
2014/04/06(日) 18:31:05.21ID:???NULLは式でも値でもない
右辺にかけるのは、（スカラー）式かDEFAULTかNULLって決まってる
つか、今までNULLに更新した事ないのか？
どういう立場でDB使ってるんだ？
>>356
ORACLEはNULLとヌルストリングを区別できないだけで
いくらなんでもUPDATEでNULLにするのは出来るだろ
0360NAME IS NULL
2014/04/06(日) 19:51:05.96ID:???ちょっと上のゲーム絡みの書き込み見れば、
このスレのレベルはわかるだろ。
0361NAME IS NULL
2014/04/06(日) 19:56:37.84ID:???一部のレベルの低い人がドヤ顔で語ってるからおかしなことになってるだけ。
さすがにその流れでNULLへ更新できないなんて言いだすとは思わなかったけどな。
0362NAME IS NULL
2014/04/07(月) 08:14:34.93ID:rbRzBkbjひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
0363NAME IS NULL
2014/04/20(日) 10:48:47.69ID:a30yxTYOまたは、区分しにくいコードに関しても、ソースコードに
直接書き込むのはNG？うちのシステムコード書きまくってます。
0364NAME IS NULL
2014/04/20(日) 11:51:05.33ID:???0365NAME IS NULL
2014/04/20(日) 12:06:45.70ID:???○○コードみたいなやつを条件文に直接書くってこと。そういうのって全て区分にしてDB化しなきゃいけないの?
0366NAME IS NULL
2014/04/20(日) 14:12:30.30ID:???0367NAME IS NULL
2014/04/20(日) 15:28:22.36ID:B7j12JHQ生産システムにおいて
ある工程のみ特殊な処理をしたい。
しかし、pgに行程コードを書くのがngであるなら、
工程マスターに新規区分フィールドを追加することになるが、
その工程を判別するためだけにdb変更がありなのかってこと
0368NAME IS NULL
2014/04/20(日) 17:17:35.34ID:???0369NAME IS NULL
2014/04/20(日) 17:30:14.83ID:???そういったものまでDBに格納した結果、マスターから1レコード取ってくるだけの処理で
50個とか60個とかSQLが投げられているシステムの事を思い出した
0370NAME IS NULL
2014/04/20(日) 18:53:11.19ID:???その条件に別の行程を追加するとき、PGに工程コードを追加するのか、
それともDBに区分フィールドを追加して該当する行程に１を立てるのか？
ポイントは、その条件が、ほかのシステムでも使われうるものなのかどうかということ。
その工程だけ１が立っていてほか全部ゼロのようなものは、
たいてい、狭い範囲でしか使われていない。そんなものは、
PGに持てばいい話。といいたいところだが、ほかの方はどうされているのか知りたい。
どんなケースであれ、直でコードを書くのを避けているのかどうか。
0371NAME IS NULL
2014/04/20(日) 20:49:32.05ID:???0372NAME IS NULL
2014/04/21(月) 04:55:39.17ID:???生産で行う処理が特殊であれ通常であれ、
生産管理システムから見たら同じ処理でしょう
何を迷う事があるんですか
0373NAME IS NULL
2014/04/21(月) 12:21:53.45ID:???将来にわたって参照・変更することがないならプログラムに書くかな
0374NAME IS NULL
2014/04/22(火) 00:05:13.58ID:???見解ありがとうございました
0375NAME IS NULL
2014/04/22(火) 18:26:28.72ID:???> ポイントは、その条件が、ほかのシステムでも使われうるものなのかどうかということ。
そんなの関係ないよ。
ポイントなのは、
* 対象となる工程が変わりうるのか
* 対象となる工程が多いのか少ないのか
今、工程1～工程100まで工程マスターに登録されてるとして、
「工程4のみ特別な処理をする」という要件があったとき、コードで
if (record.process_id == 'proc4') {
}
みたいなコードで十分なのか、
if (record.is_special_process) {
}
とした方が良いのかという違い。
対象となる工程が変わりうるのなら、データベースにis_special_processカラムを追加するか、
別テーブルを追加すべき。table special_processes (process_id) みたいな。
また、対象となる工程が多い場合も、同様にするのがいい。
対象となる工程が少なく、また今後変わる予定も無い場合に限って、プログラムに埋め込んでも良い。
0376NAME IS NULL
2014/04/22(火) 18:44:57.89ID:???対象の工程にフォーカスした場合はそうなるだろうけど
>>370を否定する理由にはならんな
それとも対象の工程だけで考えるべきであり
その場限りの特殊な処理だろうがDBに入れるべきといってるのだろうか
0377NAME IS NULL
2014/04/23(水) 03:39:05.33ID:???そのプログラム（システム）以外のところで、特別な処理をする工程を知りたいとなったらどうする？
たとえどんなに対象が少なくて今後変わる予定がなくても、他のシステムでその工程を知りたいなら
プログラム中に埋め込むべきではないだろ
>>368の、データとして永続化する必要
>>370の、ほかのシステムでも使われうるもの
>>373の、参照
これらはすべてそう言う意味だと思うけど
0378NAME IS NULL
2014/04/23(水) 06:39:39.46ID:???0379NAME IS NULL
2014/04/23(水) 07:34:05.46ID:???それが同一サーバ内のシステムなら、外部設定ファイルに情報を持たせる手も一応はある
あんまりお勧めはできないけど、DB側に情報を持たせられない・持たせたくない事情があるなら
0380NAME IS NULL
2014/04/23(水) 09:10:15.12ID:???0381NAME IS NULL
2014/04/23(水) 09:22:02.84ID:???生産(管理)システムを導入するということもあるかと。
0382NAME IS NULL
2014/04/23(水) 10:51:43.60ID:???> そのプログラム（システム）以外のところで、特別な処理をする工程を知りたいとなったらどうする？
そうなったら、そうなったときに考えればいいこと。
無限の拡張性を担保して開発することなんかできない。
0383NAME IS NULL
2014/04/23(水) 11:30:12.87ID:???一つのデータベースインスタンスを複数のシステムが共有するのは、最初からそういう前提になって無い場合はほとんどしないんじゃないかな。
0384NAME IS NULL
2014/04/23(水) 16:16:13.60ID:???> 品質管理上、その特殊な処理が入った成果物のロットを明確にしないといけないとか、特殊な処理がいつから導入されていつ終了になったのかとか、後々に問題にならないようなものならいいが。
それと、工程コードをハードコーディングしていいかどうかに、何の関連が？
0385NAME IS NULL
2014/04/23(水) 19:08:52.29ID:???ハードコーディングするぐらいだから記録もあんまり考えてないのかなと思って。関係ないならすまん。
まあ、この処理は他と比べて特別であるという判断を、誰がどんな根拠でするのかなあ、とは思う、生産システムの例なのでそこは結構気にした方がいいと思うが。
0386NAME IS NULL
2014/04/23(水) 21:01:24.29ID:???0387NAME IS NULL
2014/04/23(水) 22:34:16.62ID:???PGが変更されて使わないフィールドが出てきて
あとからなんだこれ？よくわからんが、とりあえず
とっておくか的なゴミフィールドが出てこないか？
0388NAME IS NULL
2014/04/24(木) 03:04:14.01ID:???例えばeccubeのERは少し参考になりました
0389NAME IS NULL
2014/04/24(木) 08:45:03.20ID:???モノの生産となると、どうしても外せない特別な工程が出る事もある
0390NAME IS NULL
2014/04/24(木) 09:25:23.56ID:???運用次第、水は低きに流れる
0391NAME IS NULL
2014/04/24(木) 09:45:45.94ID:???データベースで制御したいの？したくないの？
その答えだけで決まる話だと思うんですけど
0392NAME IS NULL
2014/04/24(木) 16:55:01.43ID:???したいかしたくないかわからないから、普通はどうやんのってのが知りたいんじゃ？
0393NAME IS NULL
2014/04/24(木) 17:40:06.15ID:???普通はしたいかしたくないか(必要があるかないか)決めてそれに合わせて考えます
それが設計ってもんですよ
0394NAME IS NULL
2014/04/24(木) 18:18:32.20ID:???何をしたいのか判らないものは答えようがないじゃないすかね
どうでもいいけど日本人は普通という単語が好きだよねって話思い出した
0395NAME IS NULL
2014/04/25(金) 11:07:43.69ID:???> 普通はしたいかしたくないか(必要があるかないか)決めてそれに合わせて考えます
必要があるのかないのか自分では判断できないから聞いてるんだろ
0396NAME IS NULL
2014/04/25(金) 12:44:00.39ID:???自分で判断できないときは、判断できる人に決めてもらうんですよ
0397NAME IS NULL
2014/04/25(金) 13:09:43.48ID:???0398NAME IS NULL
2014/04/25(金) 16:11:41.57ID:???0399NAME IS NULL
2014/04/25(金) 21:09:49.76ID:???まったく関連が無いとは言えないこともない
0400NAME IS NULL
2014/04/26(土) 16:02:14.63ID:???・http://eow.alc.co.jp/search?q=sort&;ref=sa
このような辞書を作りたいのですが、カラムはどのようにわければいいでしょうか？
また、例文は例文で別にストックして表示する形がベストでしょうか？
よろしくお願いします
0401NAME IS NULL
2014/04/27(日) 12:58:00.88ID:???単語、用例
この二つのテーブルがあれば足りるんじゃ？
あとは、実際に使う上で便宜があるように項目を追加・分離
0402NAME IS NULL
2014/04/29(火) 02:49:34.42ID:ZtWZlvdehttp://f.xup.cc/xup0hqxhyjg.jpg
http://f.xup.cc/xup9bhtcaam.jpg
http://f.xup.cc/xup9baxbbdr.jpg
http://f.xup.cc/xup9llhswj.jpg
http://f.xup.cc/xup0oxgfbsh.jpg
0403NAME IS NULL
2014/04/29(火) 15:24:48.79ID:o8Wl779otweetsテーブル
id
tweet_text
tweet_date
tweet_groupテーブル
id
tweet_group_associationテーブル
tweet_id
tweet_group_id
こんなテーブル設計でいいのでしょうか？
tweet_groupテーブルがほぼ空(強いて言えば名前や読まれた回数ぐらいはつけられるようにするかも)なのが気になるのですが
もっとすっきりとした設計は可能ですか？
0404NAME IS NULL
2014/04/29(火) 16:24:47.32ID:???0405NAME IS NULL
2014/04/29(火) 16:41:40.85ID:???・tweet_groupというのが「Tweetを恣意的にまとめ」たもの(=エンティティ)であり、
・あるTweetが複数のグループに所属することを(>>403が)想定している
のであれば、DB設計における最初の出発点としては
そんな感じでいいんじゃないかと
0406403
2014/04/29(火) 16:47:04.03ID:o8Wl779oデータベース的にどんな風に作ればいいのかってことです。
まとめる方法は完全に手動です。
まとめ(groupとします)とツィートは*対*の関係です。
tweets
id
tweet_text
tweet_date
tweets_group
group_id
tweet_id (tweetsテーブルのidが外部キー)
※group_idとtweet_idで主キー
tweets
| 1 | テストなう |
| 2 | hogeなう |
| 3 | fugaなう |
| 4 | piyoなう |
| 5 | barなう |
tweets_group
| 1| 2 |
| 1| 3 |
| 1| 4 |
こんな風にしたほうがいいのでしょうか？
0407NAME IS NULL
2014/04/29(火) 16:47:50.28ID:???ありがとうございます。
とりあえずこれで行ってみます
0408NAME IS NULL
2014/04/29(火) 18:07:39.52ID:???>Twitterの特定のツィートをまとめたいのですが、
>データベース的にどんな風に作ればいいのかってことです。
アプリケーションの設計は、大きく「何を作るか」という機能設計と
「どうやって作るか」という実装設計の２つに分類され、
一般には定義した機能(の仕様)を元にして実装方法が決まる
言い換えると、「どうまとめるか」という機能が決まらずに実装が決まることはないし、
「どんな風に作れば」という実装を元に「どうまとめるか」という機能を
検討しようとする試みは、本末転倒だよ
で、ツイートのまとめかたという機能(の仕様)は>>403自身しか知らないし、
それは>>403のアイデアで勝負すべき事柄であり、
もし相談するのならここではなくSNS関連の板が該当する
遠回しな言い方になったけど、あるツイートの集合について、互いに交わらない
部分集合へ分割するのであれば、DBの実装設計としては
>>406の「１対n」方式を選択することになるし、
交わりを許すのであれば>>403の「m対n」方式を選択することになる
で、繰り返しになるけど、その判断は>>403が下すしかない
もしも現時点で機能仕様が決められないなら、個人的には単純な「１対n」を勧める
0409NAME IS NULL
2014/05/01(木) 00:54:34.97ID:???異なる観点でまとめることができないなんてことになるし。
0410NAME IS NULL
2014/05/01(木) 15:53:40.57ID:???> もしも現時点で機能仕様が決められないなら、個人的には単純な「１対n」を勧める
現時点で決められないのであれば、n:mにするでしょ。
別にそれで特別設計が複雑になるわけではないし、1:nも実現できるし。
0411NAME IS NULL
2014/05/01(木) 17:48:24.30ID:???経験で学んだらしいが、毎度逆を行くのはどういう経験をつんだらそうなるのか不思議でならない
0412NAME IS NULL
2014/05/01(木) 18:22:12.17ID:???ここに聞きに来てるような段階のひとなら、なるべく単純な形からやっとけってのは一理あるとはおもう
単純にいくならtweetsテーブルにグループの名前なりIDなりの項目作れば良いんだけどね
0413NAME IS NULL
2014/05/02(金) 01:08:39.86ID:???なんで1:nだの言い出したのか判らないな
0414NAME IS NULL
2014/05/02(金) 06:00:18.79ID:???> まとめ(groupとします)とツィートは*対*の関係です。
って書いてんのに1:n にしろとかいうのは根本から間違えてるもんね。
車が欲しいんですけど、オススメの車はありますか？→お前に車なんていらない。自転車乗ってればいいんだ。
みたいなイカレ具合だよこれは。
0415NAME IS NULL
2014/05/02(金) 07:28:30.51ID:???0416NAME IS NULL
2014/05/02(金) 10:03:25.97ID:???0417NAME IS NULL
2014/05/12(月) 16:50:32.32ID:iczyP8Poどのように設計すればよいかアドバイスをお願いしますm(_ _)m
（当方初心者です）
複数の部屋に座席が多数並んでいるとします。
その座席の空き情報を調べたり、誰が予約しているのかの情報を
管理したいです。
予約時に部屋のマップから座席を指定したいのですが、内部で
キーをどのように持つべきかわかりません。
現在は以下のようなレコードになっています。
座席番号(連番)[key],部屋番号,座席の行番号,座席の列番号,予約者ID
予約したり、位置を特定するのに、毎度、座席位置と座席番号を
変換しているので、この変換なしに部屋番号,座席の行番号,座席の列番号
の一組でキーに設定できないでしょうか？
ご助言、よろしくお願いします。
0418NAME IS NULL
2014/05/12(月) 17:08:07.34ID:???まず、座席情報と予約情報は別テーブルにした方がいい。
予約業務は、実際は時刻情報等が必要なのでは？
> 変換しているので、この変換なしに部屋番号,座席の行番号,座席の列番号
の一組でキーに設定できないでしょうか？
「キー」が何を指しているのかわからないけど、なぜ「キー」に設定したいと思ってるの？
0419NAME IS NULL
2014/05/12(月) 17:24:38.80ID:???座席位置は、マップで表示する際に必要
マップから座席を選んだときは座席番号さえあればデータは登録可能でしょう。
0420NAME IS NULL
2014/05/12(月) 17:26:03.55ID:???部屋番号,座席の行番号,座席の列番号
以上3つがナチュラルキーのようだから、それらを複合主キーにして
座席番号(連番)
を削除すれば>>417の希望は満たせるけど…
上映日時的なカラムがないのが気になるし「座席番号(連番)」が他のテーブルに使われてないかも気がかり
0422NAME IS NULL
2014/05/12(月) 17:37:23.99ID:???0423NAME IS NULL
2014/05/12(月) 17:50:38.10ID:???映画館程度の規模でマップから選ぶなら、見た目で判断できるからいいんじゃないかな。
要件的には問題ないというか。
0424417
2014/05/12(月) 17:53:57.82ID:???上映時間ごとにテーブルを作っています・・・。
初設計なので、常識を軽々とスルーしているようですね。orz
これから座席のメンテナンス情報（汚れ、故障、等々）を
追加したいと考えているのですが、
部屋番号,座席の行番号,座席の列番号 →座席番号(連番)取得
座席番号→メンテナンス情報取得
の二段階を
部屋番号,座席の行番号,座席の列番号 →メンテナンス情報
にしたいと考えています。
複合主キーという存在を知らなかったので、こういう場合
みなさんはどのように処理しているのか教えて頂きたかったのです。
> 4人並びの席
そのあたりはプログラム側で処理して、DBには同一の予約者IDを
書き込んでいます・・・。
0425418
2014/05/12(月) 18:06:17.68ID:???俺の質問は無視か・・・
てか、JOINは知ってるのか？
> 上映時間ごとにテーブルを作っています・・・。
それは、ある映画館に3部屋あって、それぞれの部屋で毎日4回上映する場合、
毎日12回のCREATE TABLEをやってるという意味か？
0426NAME IS NULL
2014/05/12(月) 18:07:40.05ID:???座席は行と列、アイルの情報があるし、欠番の席もあるから
固定の座席テーブルから、売り出し用のテーブルにidのみ転記、そっちで
独自にidをつけて予約、発券に使うのがよさそうな。
0427418
2014/05/12(月) 18:10:54.72ID:???『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』
http://www.amazon.co.jp/dp/4798124702
『達人に学ぶ SQL徹底指南書』
http://www.amazon.co.jp/dp/4798115169
0428417
2014/05/12(月) 19:09:52.33ID:???すみません、見落としてしまいました。
> 予約業務は、実際は時刻情報等が必要なのでは？
一日の上映回数は決まっているので、その時刻ごとに
テーブルを作ってました
> なぜ「キー」に設定したいと思ってるの？
座席番号はDB上にのみ存在していて、データを一意に識別するときには
必ず部屋番号、列、行番号を使っているので、それを直接キーにしたいと
思いました。
＊キーによるレコード選択はO(1)で、条件文を使った選択は
O(n) or O(log N) のように処理に時間がかかるのではないかと勝手に
思っています。
> JOINは知ってるのか？
知りません・・・
> 毎日12回のCREATE TABLEをやってるという意味か？
はい・・・
>>426
今は一館だけですが、将来的には必要になるかもしれません。
> 固定の座席テーブルから、売り出し用のテーブルにidのみ転記、そっちで
> 独自にidをつけて予約、発券に使うのがよさそうな。
なるほど。メンテナンス情報はそういう風にできるか検討してみます。
>>427
自分でも現状の知識ではかなり無理があると思っています。 orz
とりあえずご紹介いただいた本を読んでみます。
0429NAME IS NULL
2014/05/12(月) 19:46:07.47ID:???>知りません・・・
おーい w せめてせめて基本的なことぐらい知ってからにしようよ
0430NAME IS NULL
2014/05/12(月) 20:56:06.04ID:???0431NAME IS NULL
2014/05/12(月) 21:01:22.09ID:???それみて応用すればいいんじゃね
0432NAME IS NULL
2014/05/12(月) 21:14:21.50ID:???そもそもDBMSとは何ぞやというレベルから勉強して設計を1からやり直さないと、にっちもさっちも行かなくなりそう
0433NAME IS NULL
2014/05/12(月) 22:03:14.57ID:???0434NAME IS NULL
2014/05/12(月) 23:36:49.77ID:???メンテ情報とか、連座の扱いとか、VIP 席とか身障者の方の席とかの対応とか、まず何をしたいかを決めた方がいいと思うよ。
0435NAME IS NULL
2014/05/13(火) 09:34:29.15ID:???0436NAME IS NULL
2014/05/13(火) 10:04:13.79ID:???0437NAME IS NULL
2014/05/15(木) 14:45:01.25ID:???0438NAME IS NULL
2014/05/15(木) 14:52:54.37ID:???/ (●) ..(● ┏┛
| 'ｰ=‐' i ・
> く
＿/ ,／⌒)､,ヽ＿
ヽ､_／~ヽ､__） ＼
0439NAME IS NULL
2014/05/15(木) 19:04:14.49ID:???0440NAME IS NULL
2014/05/15(木) 19:06:49.11ID:???0441NAME IS NULL
2014/05/15(木) 20:26:10.54ID:ofSwoAjeNHK質問操縦状回答問題
NHK質問操縦状回答問題
0442NAME IS NULL
2014/05/15(木) 21:53:18.82ID:???0443NAME IS NULL
2014/05/20(火) 15:21:27.68ID:9GXuUkHfデフォルト（初期状態）示すカラム名って、何が適切ですかね？
default で良いですかね？
0444NAME IS NULL
2014/05/20(火) 18:22:42.07ID:???それとも内容ごとに初期値が存在しうるのかな。
0445443
2014/05/20(火) 19:35:22.53ID:???例えば学校の部活をカテゴリとして、
「野球部、サッカー部、写真部」に所属しているとします。
その場合、メインの部活は野球部であり、他は違うよ
っといった見せ方をしたのです。
要は複数カテゴリからメインのカテゴリ、メインじゃないカテゴリを
指定できて、後に変更できるといった仕様です。
0446NAME IS NULL
2014/05/20(火) 19:36:58.57ID:???primaryとかつけたいところ
0447NAME IS NULL
2014/05/20(火) 21:53:08.07ID:???0448NAME IS NULL
2014/05/21(水) 00:52:33.64ID:???0449443
2014/05/21(水) 09:51:23.94ID:???ユーザーが選択するテーブルを2つに分けろということですか？
確かに正規化されている気はしますが、どうなんですかね・・・
#category
id｜name｜sort
#main_category
id｜category_id｜user_id
#sub_category
id｜category_id｜user_id
0450443
2014/05/21(水) 09:54:55.07ID:???defaultの部分がメインフラグ扱いなのですが、
カラム名は違うほうがいいのではないか？と思い、質問しています。
#user_category
id｜category_id｜user_id｜default
0451NAME IS NULL
2014/05/21(水) 10:53:09.47ID:???そのdefaultというカラム名を
primary
main_flag
main_category
とかにしたらって返信だと思うよ
ただ、primaryとdefaultはSQLで利用される言葉だから避けることをオススメするよ
primaryはprimary_flagにするとかな
defaultは意味が違うんじゃないかな？
入力等がないときに使われるあらかじめ用意しておく値って意味だからね
0452NAME IS NULL
2014/05/21(水) 12:12:49.78ID:???・ユーザテーブル
ユーザID, …
・ユーザ/カテゴリ中間テーブル
ユーザID, カテゴリID, メインカテゴリフラグ, …
みたいにテーブルを分けた方が良くない？
0453NAME IS NULL
2014/05/21(水) 12:15:58.31ID:???0454443
2014/05/21(水) 12:18:29.63ID:???なるほど。分かりやすく説明していただきありがとうございます。
とりあえず、defaultは駄目かな？と疑問に思ってたので、
教えていただき助かりました。main_flagかmain_categoryにします。
0455NAME IS NULL
2014/06/20(金) 01:21:01.61ID:???投稿タイトルや日時、本文をpostsテーブルに持たせて
投稿カテゴリーについてはcategoriesテーブルに持たせて外部キーpost_idで結んでいます
質問なのですが、複数のブログを運営する場合にはテーブル設計はどうするのがいいでしょうか
新たにblogsテーブルを作成し、blog_idをpostsテーブル、categoriesテーブルに持たせたらいいんでしょうか
それともブログごとにテーブルを作るのがいいんでしょうか
うまいやり方があれば教えていただきたいです
よろしくお願いします
0456NAME IS NULL
2014/06/20(金) 04:37:15.15ID:???wordpressが別テーブルにしてるところから判断すると別テーブルが正解。
別テーブルにしておくと、ブログの追加、削除が簡単。
0457NAME IS NULL
2014/06/20(金) 09:12:54.86ID:???個人的には別テーブルは無いんじゃないかな
別ＤＢにするか、単一テーブルでブログＩＤとかサイトＩＤとか持つか、どっちかじゃない？
0458NAME IS NULL
2014/06/20(金) 09:18:47.55ID:???別インスタンスだったり、別スキーマだったり
つまり、同一テーブル名称だけど別のものってことね
少なくとも別テーブル名で同じテーブルデータ持つのはないだろって話
0459NAME IS NULL
2014/06/20(金) 09:53:44.10ID:???そのサイトIDを含んだテーブル群を別途作成するのか
こんなのメンテナンスしたくないぜ
0460NAME IS NULL
2014/06/21(土) 00:03:23.07ID:4Orq4nTs管理ツールがちゃんとしてれば後者。
別スキーマのほうがもっとよかった。
0461NAME IS NULL
2014/06/21(土) 03:04:17.33ID:???少なくともプログラムでまずテーブル名取得してからSQL組み立てとかやりたくねぇ
0462NAME IS NULL
2014/06/21(土) 08:10:49.62ID:???スキーマ方式が良いと思う
wordpressみたいな方式はパス
0463455
2014/06/21(土) 15:47:17.22ID:KVSVdrTZDBを分ける方式を採用することにしました
ありがとうございました
0464NAME IS NULL
2014/06/21(土) 22:46:30.00ID:???0465NAME IS NULL
2014/06/22(日) 00:26:57.60ID:???スキーマ単位だろうがテーブル単位だろうが
やってる事は同じコピペなんだよね
> 新たにblogsテーブルを作成し、blog_idをpostsテーブル、categoriesテーブルに持たせたらいいんでしょうか
工数が取れないとかじゃない限りこっちが無難よ
0466NAME IS NULL
2014/06/22(日) 06:49:37.84ID:9FaJOsP1★+ニュース板
・ 2NN (推奨サイト)
・ 2chTimes
★+ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★+ニュース板その他
・ Desktop2ch
・ 記者別一覧
★全板
・ 全板縦断勢いランキング (推奨サイト)
・ スレッドランキング総合ランキング
・ ログ速
★全板実況込み
・ 2勢 (推奨サイト)
・ READ2CH
・ i-ikioi
※ 要タイトル検索
※ 2chブラウザ併用推奨
0467NAME IS NULL
2014/06/23(月) 01:59:43.21ID:???複数ブログに共通の記事があるのなら同一テーブル。
そうでないなら別テーブル？
0468NAME IS NULL
2014/06/23(月) 10:23:15.43ID:???同じカラムならまとめりゃいいじゃん
0469NAME IS NULL
2014/06/23(月) 10:28:15.72ID:???妙なこだわり持ってるね
0470NAME IS NULL
2014/06/23(月) 10:40:36.51ID:???0471NAME IS NULL
2014/06/23(月) 10:50:50.35ID:???0472NAME IS NULL
2014/06/23(月) 14:22:37.88ID:???管理ツールでもないのに
0473NAME IS NULL
2014/06/23(月) 14:23:48.39ID:???0474NAME IS NULL
2014/06/23(月) 14:45:53.57ID:???その規模までいってないだけか
0475NAME IS NULL
2014/06/23(月) 16:13:14.15ID:???要件次第だよ
0476NAME IS NULL
2014/06/23(月) 21:45:48.58ID:???0477NAME IS NULL
2014/06/23(月) 21:58:57.55ID:???モノによっちゃ、しないしな
0478NAME IS NULL
2014/06/24(火) 01:06:01.11ID:???俺は業務にあった、DB設計にすべきだと思うんだけど、
Railsだとこうだからといって、無駄な外部キーを増やしたがる。
0479NAME IS NULL
2014/06/24(火) 03:45:04.62ID:tUTXA4Xlなんかもぞもぞする言い回しなんだけど、単にRoR嫌いって言いたいだけなのかな。
0480NAME IS NULL
2014/06/24(火) 04:13:12.20ID:???理想を追い求めてフレームワークから脱線したがる人
0481NAME IS NULL
2014/06/24(火) 04:16:32.55ID:???他のフレームワークでこういう設計だからと言う理由で
（フレームワーク使いもしないのに）本来の設計を捻じ曲げるやつがいる
という主張じゃないかと思い始めた
0482NAME IS NULL
2014/06/24(火) 04:22:12.86ID:tUTXA4Xlあぁー。そこまでは気が回らなかったです。それなら納得。
0483NAME IS NULL
2014/06/24(火) 07:17:17.12ID:???それは使っている(使えている)とは言えないのでは…
0484NAME IS NULL
2014/06/24(火) 11:51:01.06ID:???ないわぁ
要件次第
0485NAME IS NULL
2014/07/11(金) 09:21:57.34ID:???という文があるじゃないですか。
これみたいな沢山の文をデータベースにしたいんですけど
どうゆう構造で保存したらいいとかが分かる本教えてください。
これから太郎君は３時に死んでいるかとか、
太郎くんが１時から２時の間にどこにいるかを
調べられるようにしたいです。
0486NAME IS NULL
2014/07/11(金) 14:11:16.23ID:???0487NAME IS NULL
2014/07/11(金) 14:15:17.26ID:???0488NAME IS NULL
2014/07/11(金) 17:52:09.72ID:???0489NAME IS NULL
2014/07/11(金) 20:52:09.55ID:???「いつ」「だれが」「どこで」「何をした」
をダラダラ入力して、並べ替え・オートフィルタでよくね？
0490NAME IS NULL
2014/07/11(金) 20:53:59.03ID:SfLsxBaO0491NAME IS NULL
2014/07/12(土) 08:59:55.84ID:???それに応じたデータベースってのは有るんだろうけど、それ用の所で聞いてくれって感じだな
0492NAME IS NULL
2014/07/12(土) 09:29:18.08ID:???参考書に関しては、まず適当な入門書でも買ってRDBMSの基礎を学んでみるところからかな
基礎知識がついたら試しに要件と自分の考えた設計をここに晒してみるといいと思う
0493NAME IS NULL
2014/07/12(土) 10:18:13.14ID:???つっても、たとえば全文検索の考え方なら実現できそうかどうか、みたいなのは
俺には分からんが
とはいえプリプロセッシングとしての、自然言語解析がキモっぽい気もする
0494NAME IS NULL
2014/07/12(土) 17:45:18.39ID:???そもそもスレタイ的にはまずDB設計ありきだし、>>485のやりたいことも
小説をそのまま読み込ませて話を時系列に並べさせたいとかではなくて
「いつ誰がどこでどうした」
というのを手入力して、人物や場所別に出来事を時系列順に並べたい、とかいうもののような気がする
小説丸々食わす方向も面白そうだけど
0495NAME IS NULL
2014/07/15(火) 22:34:20.78ID:E2UqVvuO上のようなテーブルがあって、趣味の値は複数あります。
こういうときはどんなデータ構造にすればいいのでしょうか？
趣味テーブル作るのはださいと思うので、
他の方法を教えてください
0496NAME IS NULL
2014/07/15(火) 22:46:01.11ID:???趣味テーブル(ID, 趣味1, 趣味2, •••)
0497NAME IS NULL
2014/07/15(火) 23:00:37.00ID:E2UqVvuO1 山田 [野球][音楽]
こういうＤＢがスマートそうですね
0498NAME IS NULL
2014/07/15(火) 23:23:59.24ID:???0499NAME IS NULL
2014/07/15(火) 23:48:36.53ID:???0500NAME IS NULL
2014/07/16(水) 01:30:25.91ID:???ダサい格好いいといった感覚論でなく、具体的に正規化を崩すメリット・デメリットを自分で挙げてみれ
アプリ側の仕様によってはDB側の正規化を崩すメリットが勝るケースもあるが、そのケースに該当するか？
0501NAME IS NULL
2014/07/16(水) 01:45:35.25ID:???趣味の正規化というか分類をどうする？
0502NAME IS NULL
2014/07/16(水) 01:54:37.84ID:???そのまま
id 名前 趣味
----------------
1 鈴木 野球
1 鈴木 ホッケー
2 田中 野球
2 田中 剣道
って入れていくのが今時のDBっぽいよ
0503NAME IS NULL
2014/07/16(水) 03:45:24.46ID:???なんのidかは知らんが
0504NAME IS NULL
2014/07/16(水) 03:46:29.94ID:???趣味をどういう風に扱いたいか次第だなぁ。
特に理由がないなら、ここにいる人たちは口をそろえて正規化しろって言って終わる話。
0505NAME IS NULL
2014/07/16(水) 03:48:07.94ID:???今時は難しいなぁ
0506NAME IS NULL
2014/07/16(水) 10:49:20.98ID:???0507NAME IS NULL
2014/07/16(水) 16:53:31.67ID:???0508NAME IS NULL
2014/07/16(水) 20:58:42.08ID:tc/eB9a4ゲームを作っていて、あらゆる属性で効力など絞り込みたいです。
趣味はアイデンティティの一つであり、
名前などと同じように扱うべきです。
そういった観点からいうと、
役割の同じものを別テーブルに書き出すのは間違ってると思いますし、
正規化とは言えないと思います。
規格化と言うべきではないでしょうか。
ということで、タグ管理がイメージに近いと思いました。
こういった感じでしょうか？
id 属性 値
1 名前 鈴木
1 仕事 野球
1 仕事 俳優
1 ポジション ライト
1 打順 １番
更には、野球クラスのサブ属性といったものも同じレベルで扱いたいです。
0509NAME IS NULL
2014/07/16(水) 22:21:16.67ID:???0510NAME IS NULL
2014/07/16(水) 22:39:11.59ID:???いっそNoSQLの方向に進む方が幸せになれるかもね
0511NAME IS NULL
2014/07/16(水) 22:47:23.13ID:???0512NAME IS NULL
2014/07/16(水) 22:59:46.22ID:tc/eB9a4アイデンティテイがあると思うんだけど
クイズみたいなもんだよ、
人物１を当ててください。
ヒント
打順は１番、ポジションはライト、野球選手
こういうことを言ってるんじゃなくて？？
0513NAME IS NULL
2014/07/16(水) 23:08:28.40ID:???主張の内容はよく理解できないけど、確固たるポリシーがあるならそれに従ってやればいいんじゃね？
0514NAME IS NULL
2014/07/16(水) 23:20:46.66ID:???>>511
{id,属性}の複合キーといったところだろう
table名を森羅万象とすると、これで鈴木の諸々のデータが取れる寸法
SELECT * FROM 森羅万象 WHERE id IN
(SELECT id FROM 森羅万象 WHERE 属性 = '名前' AND 値 = '鈴木')
森羅万象テーブルのメリットデメリットは各々考えてくれ
ネタでなくこういう設計やる奴もいるのがなんとも…
0515NAME IS NULL
2014/07/16(水) 23:23:52.20ID:???0516NAME IS NULL
2014/07/16(水) 23:51:18.63ID:tc/eB9a4属性オブジェクトを識別するもの入れてなかった。
idとは（これでは属オブジェクトハッシュコード）
select * from 従属オブジェクト = 1 で得られる結果と
同じ属性プロパティを持ったオブジェクトです
属性ハッシュコード 属性 値 従属オブジェクトハッシュコード
1 名前 鈴木 1
2 仕事 野球 1
3 仕事 俳優 1
4 ポジション ライト 1
5 打順 １番 1
0517NAME IS NULL
2014/07/16(水) 23:53:36.03ID:???0518NAME IS NULL
2014/07/16(水) 23:57:15.11ID:tc/eB9a40519NAME IS NULL
2014/07/17(木) 00:00:46.22ID:r/KRisL/属性オブジェクトは
自分自身のハッシュコード、自分自身の属性の名前、自分自身の値、元のオブジェクトを
データベース上では返すということです
0520NAME IS NULL
2014/07/17(木) 00:07:04.16ID:???例えば Trac (BTS) のカスタムチケットとかで使われてるよ
0521NAME IS NULL
2014/07/17(木) 00:38:06.10ID:r/KRisL/ちょっとこれでやってみます。
0522NAME IS NULL
2014/07/17(木) 01:01:10.00ID:???実際にどういうデータを入れようとしているのか。
ゲームの属性や効力について、悪く言えばまとまりのない、良く言えば自由度の高い構成にする理由が思いつかん。
RPGツクールみたいなものを作ろうとしてるとしても、属性マスタを作ったほうがいいと思うんだが。
ユニーク属性ばかりにするつもりなんだろうか。
0523NAME IS NULL
2014/07/17(木) 01:01:36.51ID:???0524NAME IS NULL
2014/07/17(木) 01:17:20.87ID:???>野球クラスのサブ属性といったものも同じレベルで扱いたいです
「サブ」属性なのに同じレベルで扱うのはおかしくないか？
サブ属性とメイン属性は何がどう違うのか表現できなければ、サブとメインの区別が無いのと同じだぞ
0525NAME IS NULL
2014/07/17(木) 01:46:21.34ID:r/KRisL/今回考えたデータベースを扱うのは、エディターでなくゲームで使います。
マスタは作りません。全てオブジェクトで管理します。
サブの利用頻度は少ないと思いますが、
野球選手のモテ度を５アップとか、
打順一番の打者は先頭打者ホームランを打ちますとか
そういった魔法も作るかもしれないので。
0526NAME IS NULL
2014/07/17(木) 01:49:49.37ID:r/KRisL/従来の構造で十分なのでそれで作ります。
0527NAME IS NULL
2014/07/17(木) 03:24:11.30ID:???0528NAME IS NULL
2014/07/17(木) 08:44:05.46ID:???きちんとカラムに持たせたり、それがジョブみたいに複数あるものなら
関連テーブルを持たせたりと、RDBの王道を行く方がよい
その設計では、HPがなかったり複数あったり「HP:田中」だったり
間違えてHPじゃなくてHDを持ってたりと滅茶苦茶できるから
アプリ側で登録更新削除時の整合性チェック、及び検索時の異常データに
対する例外処理を手厚くする必要が出てきて、面倒なことこの上ない
DB管理上もデータの見通しが悪すぎるし
特定のモンスターしか持たない特殊パラメータだけ例外的に
・モンスターテーブル
・特殊パラメータテーブル
・上2つの関連テーブル
みたいな形で持たせるのはアリだと思うけどね
0529NAME IS NULL
2014/07/17(木) 11:49:48.12ID:???RDBのアンチパターンまっしぐらよりは、
MongoDBとか使った方が幸せになれるんじゃないかね。
0530NAME IS NULL
2014/07/17(木) 14:03:26.43ID:???追加要素の多いカードバトル物のパターンだね
例に挙げたような魔法を作るとなると、その打順がどうかといった制御はアプリケーション側で
実装するのだろう
であれば、データベースには必要な情報を積み上げていくに留め、積み上げられたデータから
モテ度なり打順なりの有無を拾っていった方が良い
見返してみると >>502 が正解かな
0531NAME IS NULL
2014/07/17(木) 18:02:02.16ID:???カードゲームなら用途的に1000も種類があれば相当多い部類だろうけど
それぐらいのオーダのデータ量ならxmlで持っても問題なかろう
0532NAME IS NULL
2014/07/17(木) 21:01:38.12ID:r/KRisL/すいません。
何度も言うように、実態はオブジェクトですので
HPに田中が入ることはありません。
レコードの更新はテーブルじゃなく、オブジェクトに行うものなので。
このテーブルはフィルタさえかかればいいのです。
RDBとは違うものだと思います。
また、HPを二つ持つことも全然ありです。
このモンスターにHP10を追加する。
追加したHPは元のHPと別に扱い、
このHPが全部消滅した時にこのモンスターは死ぬとか
プログラムの仕様を説明すればいいです。
構想上はこんな感じの仕様で動きます。
また、許さない場合もデータベースやオブジェクトが判断しなくとも、
私が作らなければいいだけの話です。
プログラムエラーで動かないようなら意味ないので制限しますけども。
0533NAME IS NULL
2014/07/17(木) 21:32:04.62ID:???ただめんどくさいだけだね。
オブジェクトとしても気持ち悪いものに仕上がる。
0534NAME IS NULL
2014/07/17(木) 22:31:17.97ID:???ただ、自分がアプリ担当でこんなクソ設計を上げてくる奴がいたらグーで殴るわ
0535NAME IS NULL
2014/07/17(木) 22:33:05.75ID:???そういう自由度を求めるなら、>>530のする通りで、>>502のパターンが適している。
0536NAME IS NULL
2014/07/17(木) 22:38:08.02ID:???DBを単なるデータストアとしてしか使わないなら、設計に悩む必要はないよ
オブジェクトと相互変換しやすいようにやれば良い
DBMSの基本的な考え方として、データの整合性はDBMSで保障するってのがある
DBMSの設計論はほとんどその考えを踏襲してる
その保障がいらないならほとんどの設計論は意味ないから
0537NAME IS NULL
2014/07/17(木) 22:52:11.55ID:???もちろん後者。
> プログラムの仕様を説明すればいいです。
> 構想上はこんな感じの仕様で動きます。
> 私が作らなければいいだけの話です。
0538NAME IS NULL
2014/07/17(木) 23:01:57.62ID:r/KRisL/だから保障されてるってオブジェクトしかいじらないんだから。
0539NAME IS NULL
2014/07/17(木) 23:21:03.50ID:???だから好きにしろって
もうここに来る必要もないし、レスする必要もないから
0540NAME IS NULL
2014/07/17(木) 23:35:54.05ID:???問題は、プログラミングに関する素養がなさそうなところ。
失敗していることに気づかない可能性がある。
0541NAME IS NULL
2014/07/17(木) 23:37:21.73ID:r/KRisL/勉強しろよ。
0542NAME IS NULL
2014/07/17(木) 23:38:29.41ID:???0543NAME IS NULL
2014/07/17(木) 23:46:24.45ID:r/KRisL/とりあえず、シコシコ作ってみるわ。
0544NAME IS NULL
2014/07/17(木) 23:51:11.04ID:???おかしいと言うなら、まともな設計と言うものを示してよ
0545NAME IS NULL
2014/07/17(木) 23:56:47.30ID:r/KRisL/まぁ実物をみてもらうしかないですわ。
とりあえず、この仕組みでトランプ作ってみますよっと。
0546NAME IS NULL
2014/07/18(金) 01:09:07.72ID:???カードの種類は数万にも達しない上に例外的なパラメータも多いと、そもそもDBMSの強みが活かし辛いケースだし
0547NAME IS NULL
2014/07/18(金) 01:27:07.68ID:???そういうこともあって、近頃のネトゲでは>>502みたいなのが主流
ああいったネトゲでは、業務ロジックというかゲームのルールというか仕様というかが、
RDBMS的な思想に基づく、例えば制約やキーによる実現がかえって非効率になっており、
その上でこと細かい制御が必要になるのだから、アプリケーション側をスケールアップ/アウト
しやすいアーキテクチャにした上で、DB側には特に工夫せずに格納する、というのが
パターンとして確立している
0548NAME IS NULL
2014/07/18(金) 01:31:23.61ID:???NoSQLでいいじゃんとかxmlシリアライズしとけとかって話なら、早々に言及されてた気がする
0549NAME IS NULL
2014/07/18(金) 03:38:55.48ID:???あぁー。そういうこともあって、名前や基礎データにいたるまで、工夫せず>>502のように、、、え？
0550NAME IS NULL
2014/07/18(金) 05:19:40.78ID:50IdpTKoSQL的なことはしますが、SQLは使いません。
一応NoSQLです。
オブジェクトの情報を集約し、ある範囲の対象を取りたい場合に
データベース的に扱うとどんな情報があればいいのか
どんな設計にすればいいのかがしりたいわけです。
僕的にも今回の場合、502はわりと素敵な設計だと思います。
0551NAME IS NULL
2014/07/18(金) 06:48:23.14ID:???これ以上何の論議がしたいわけ？
0552NAME IS NULL
2014/07/18(金) 07:23:52.21ID:???0553NAME IS NULL
2014/07/18(金) 13:24:58.77ID:???質問者がそれで納得してるんだから、さっさとそれで作れば良いのに
0554NAME IS NULL
2014/07/18(金) 13:37:39.70ID:???自分で考えてるやつあるからそれでどうぞと。
0555NAME IS NULL
2014/07/23(水) 22:42:02.92ID:ueXS7cQrid|名前
1|北海道
2|青森
チームテーブル
id|名前|都道府県|並び順
1|札幌AAA|1|10
2|東京BBB|8|20
3|浜松CCC|15|30
選手テーブル
id|名前|生年月日|チーム|身長|体重|血液型|足のサイズ|100m走
1|田中|1990/01/10|2|180.0|75.0|A|28.0|11.5
2|佐藤|1989/12/31|1|175.5|80.5|B|26.0|10.8
3|鈴木|1991/01/01|1|177.7|60.0|A|27.5|14.0
身長、体重、足のサイズ、100m走の範囲検索、所属チームの都道府県の検索、並び順は名前、身長、体重、足、100mの昇順&降順
のような、いろんな項目を検索させたり、並び替えさせたりする場合、どのようなindexを貼るのがいいのでしょうか？
0556NAME IS NULL
2014/07/23(水) 22:49:02.61ID:???0557NAME IS NULL
2014/07/23(水) 23:11:15.86ID:???更新が無けりゃいいのかな
0558NAME IS NULL
2014/07/23(水) 23:56:17.21ID:???そのトレードオフとして、何かのインデックスを扱うときに、それがBツリーかビットマップかを
判断しなければならない手間とかといったデメリットを考えると、間尺にあわん
0559555
2014/07/24(木) 08:11:00.86ID:RfQppZp+回答ありがとうございます。
となったら、特に貼る必要もないのですね。 更新コストが馬鹿にならないですが、様々なパターンの複合indexでも貼るのかどうか、気になっておりました。
0560NAME IS NULL
2014/07/24(木) 08:50:17.01ID:???検索条件に指定されやすいカラムだけ張っとけ
0561NAME IS NULL
2014/07/25(金) 00:09:34.62ID:???BIツール側の自由度を高めるほど、インデックスは効き目が薄くなっていく
0562NAME IS NULL
2014/08/20(水) 10:30:40.54ID:4cvw8JQq0563NAME IS NULL
2014/08/23(土) 08:22:56.98ID:???au氷水ディレクター戦争タイステーキ万国ニューヨークブカ牛肉直輸出制限業者議論病院雇用市議しょうゆダシマクッロスさむらい山雪光金ガンダム風ミックドラ社員あかうんとパズ豚骨のり肉マンつばめの巣塩担々麺野菜炒めラーメン
au氷水ディレクター戦争タイステーキ万国ニューヨークブカ牛肉直輸出制限業者議論病院雇用市議しょうゆダシマクッロスさむらい山雪光金ガンダム風ミックドラ社員あかうんとパズ豚骨のり肉マンつばめの巣塩担々麺野菜炒めラーメン
ニンニクヤーフォー低額土地NHK名古屋遅延電池切れ福岡損保新規駐車近代ゲームフジワイプ転職提案ラーメン
abk公式漏洩安保険王なにあげてんだよ？「わー！ふーう？」↓↓★★↓↓宿題通調印鑑カウントダウン息子議員国会大学生
0564NAME IS NULL
2014/08/25(月) 15:21:29.17ID:6xD79/JdAccessで作った業務ソフトを使ってるんだが、そのデータを取り込む必要があって
とりあえずCSVでもいいからよこせつったら、渡されたテーブルの日付フィールドが和暦だった・・・
まあ取り込む時に変換すりゃいいんだろうけど、ちょっとなんだかなーって感じで脱力した。
もしやと思ってMDBのぞいてみたら、日付型はガン無視して文字型で和暦が格納されてる・・・
しかも、西暦に変換するテーブルまであるしw
こんなの初めて見たんだけど、業界的にこういうのもありなの？
0565NAME IS NULL
2014/08/25(月) 15:36:25.25ID:???作った時期とか
おまえの所が和暦文化なら
あるんじゃね？
平成になって西暦重視になったところも多いし
0566NAME IS NULL
2014/08/25(月) 17:45:25.82ID:???0567NAME IS NULL
2014/08/26(火) 03:31:50.46ID:???昭和64年3月31日と
平成元年3月31日を
区別する必要があるなら日付型は使えない。
0568NAME IS NULL
2014/08/26(火) 03:35:12.39ID:???元禄とか慶長とか天平勝宝とかの和暦を西暦に直したいんだけど、良い手が見つからない。
趣味のプログラムなんで急いではいないけど。
0569564
2014/08/26(火) 08:40:30.50ID:???平成以降の作。ていうか2000年以降だし。
最近もVerUPしてる。
>>567
たぶんその必要はなさそう。
売上げ入れて請求書を出すだけのもんだし。
0570NAME IS NULL
2014/08/26(火) 08:45:18.20ID:???> 昭和64年3月31日と
そんな日付は存在しない
年度処理とかで、仮想的に昭和として扱う場合でも、単に表示するだけとかなら文字列でいいけど、なんかの処理するなら普通に日付型にして出力時点で変換した方がいいと思う
0571NAME IS NULL
2014/08/26(火) 09:04:38.34ID:???和暦と2000年は無関係
0572NAME IS NULL
2014/08/26(火) 09:09:08.14ID:???全部和暦なんだろ？
0573NAME IS NULL
2014/08/26(火) 12:27:47.85ID:???いや、そんだけ新しいって事で、2000年問題を絡めたわけじゃないよ。
0574NAME IS NULL
2014/08/26(火) 12:49:37.23ID:???西暦でもグレゴリオ暦に切り替える前か後かで違ってくるしねえ、しかも国によって違う
ユリウス日で統一して取り出すときに変換するしか・・・
0575NAME IS NULL
2014/08/30(土) 18:39:44.88ID:???その辺の和暦がよく分からんが対応表作ってれば良いんじゃないの？
0576NAME IS NULL
2014/08/30(土) 19:25:57.08ID:???カソリックの方が暦の近代化が早くて、
英米のプロテスタントの切り替えが遅かったというのが興味深いです。
>>575
太陰太陽暦だと閏月があったりして、単純に置き換えられないんです。
0577NAME IS NULL
2014/08/30(土) 19:51:02.34ID:???でも一回作ればあと楽だし、ググって見つかりそうな気もするが
0578NAME IS NULL
2014/08/31(日) 03:27:14.69ID:???カトリックのトップの教皇が作ったものをプロテスタントの国々が簡単に受け入れるわけないでしょ。
明治改暦以前の暦をグレゴリオ暦やユリウス暦と相互変換するのは基本的にテーブルにするしかない。
そんなサイトがあった気がするが…
0579NAME IS NULL
2014/08/31(日) 03:28:35.72ID:???0580NAME IS NULL
2014/10/18(土) 11:04:21.84ID:???マスタ側のFK付テーブルは読取専用スナップショット(サブスクライバ)側でもFK付けるべきなのか。
sqlserverでの答えを探してるけど、他のDBでの意見もお願いします
0581NAME IS NULL
2014/10/23(木) 07:58:26.04ID:???0582NAME IS NULL
2014/10/23(木) 14:06:35.44ID:???まさかとは思うが、JOINは知ってるよね？
それはさておき、深刻なパフォーマンス問題が生じない限り、正規化はしといて損はない。
0583NAME IS NULL
2014/10/23(木) 16:21:06.94ID:???はい。
>>582
インサートの話もしてるんだから、join知ってるかどうかによらず、増えることは確かでしょ。
0584NAME IS NULL
2014/10/23(木) 16:29:01.78ID:???複数のテーブルの更新ってそれほど多くない気がするけどな。
可変長の項目が多数あるとかくらいじゃね？
0585NAME IS NULL
2014/10/23(木) 23:27:17.15ID:???0586NAME IS NULL
2014/10/23(木) 23:49:27.24ID:???0587NAME IS NULL
2014/10/24(金) 00:00:45.93ID:???0588NAME IS NULL
2014/10/24(金) 00:04:06.73ID:???0589NAME IS NULL
2014/10/24(金) 02:49:09.07ID:???0590NAME IS NULL
2014/10/24(金) 03:59:11.37ID:???0591NAME IS NULL
2014/10/24(金) 04:57:58.03ID:???おちつこ？
0592NAME IS NULL
2014/10/24(金) 09:01:43.84ID:???要件による
過度の複数テーブル化は検索速度が落ちるから、とことん高速化を目指すシステムなら、少し位の冗長性は許容する
まあ、更新データ多いと判断が難しい
0593NAME IS NULL
2014/10/24(金) 11:12:19.77ID:???DBアナリストに取りつかれると、正規化は絶対的な正義になるけど、
ぶっちゃけ面倒くさいから、作り易さから考えた方が良いよ。
ただ、データ件数が数百万、数千万件に行くとかなら別だけどね。
0594NAME IS NULL
2014/10/24(金) 11:55:15.34ID:???> インサートの話もしてるんだから、join知ってるかどうかによらず、増えることは確かでしょ。
JOIN知ってるか知らないかでクエリの回数が違うでしょ。
データレコードを取得して、関連するマスタを何回もSELECTして、それをループで回すという極悪コードを見たことあるし。
0595NAME IS NULL
2014/10/24(金) 18:19:10.71ID:R3rzZn6a0596NAME IS NULL
2014/10/24(金) 18:30:42.23ID:???みなさん有難うございます。
私は設計はしたことがないのですが、興味があったので情報処理を受け、正規化は正義と学びました。
>>592>>593
さんがおっしゃるような
判断基準をしりたいなと思っていますが、やはり開発に携わり経験を積むしかなさそうですね。
0597NAME IS NULL
2014/10/24(金) 18:31:53.57ID:???>>594のことだよね
0598NAME IS NULL
2014/10/24(金) 18:39:13.53ID:???前段では正規形を崩してでも作りやすさを取れと言っていて
後段はデータ件数多いときの話だから、一般的に正規形を崩すきっかけの話だと思うんだが、
「別だけど」と続いている。
0599593
2014/10/24(金) 19:31:30.78ID:???自分は、開発規模が大きければ大きいほど正規化の有効性が出ると思っているので。
開発人数が多人数もしくは長期に渡るのであれば、出来れば正規化されている方が良い。
テーブルが小さければ小さいほどテーブルに対するミスが減るからね。
けれども小規模な開発であれば、正規化なんてあんまり考える必要は無い。
正規化よりもプログラミングのしやすさを優先させた方がずっと効率良く開発できる。
オブジェクト指向での設計・プログラムをどこまでするのかと同じようなものかと。
再利用されない事が決まっているようなものをどこまで正しく作りこむか。
(これも規模が大きければ多きほど正しくオブジェクト指向で作成した方が良い)
あと、正しくインデックスが貼ってあるのであれば、正規化によるコストロスはだいたいが無視できるレベルじゃないかな。
そもそも、速度の為に正規化を崩すってのは間違い(インデックスや正規化が間違っている)だと思っているので。
一番の影響は開発工数だよ。
ちょっとデータを見たり変えたりするのに、いろんなテーブルへ操作しなくてはいけないなんて無駄コスト。
たかだがちょっとした一覧を出すのに、マスタの為にJOINが何十にもなったりとか泣けてくる。
0600NAME IS NULL
2014/10/24(金) 19:32:54.84ID:bd39MiQK全然イメージ湧かんわ
0601NAME IS NULL
2014/10/24(金) 19:45:07.11ID:???order by アーティスト名, アルバム発売日 offset 300 limit 20 というクエリの速度を出す場合、
・アーティストテーブル.アーティスト名
・アルバムテーブル.発売日
というインデックスを作ってもだめだと思うんだけど間違い？
0602NAME IS NULL
2014/10/24(金) 20:07:27.33ID:???アーティストとアルバムとの対応関係を表すカラムにもインデックスを張らないと
アーティスト毎にロウをシーケンシャルサーチするから、まともな性能にはならんだろね
つまり>>601ではだめだから、間違いで正しい
0603NAME IS NULL
2014/10/24(金) 20:09:00.94ID:???アルバムテーブル.発売日
というインデックスにすれば性能は出ると？
0604NAME IS NULL
2014/10/24(金) 20:12:50.43ID:???limit offset の最適化を行わせることと、
複数テーブルに散らばっているソート項目は水と油だってことで。
JOINが何十にもなる、そのマスタが本当にJOINであるべきかどうかはさておき、
各マスタが表示順のような項目を持っていた場合に、性能でないでしょと。
0605NAME IS NULL
2014/10/24(金) 20:23:50.64ID:???テーブル構成もwhere条件も件数も書かんでエスパーしろってか
どうしてもその条件に速度だしたいなら(アーティスト名, アルバム発売日)でインデックス張れや
最近のDBMSならビューに対してでもインデックス張れるから
0606NAME IS NULL
2014/10/24(金) 20:24:48.30ID:???アーティスト名で順序指定(order by)しているから、
そのインデックスだとクエリ実行の度にソート処理が必要になる
結果として、性能は>>601よりも更に劣化すると思われ
あと規模や性能とは関係しないが、そのDB設計だと
コンピレーションを無視しているみたいだけど、それでいいの？
0607NAME IS NULL
2014/10/24(金) 20:29:12.45ID:???インメモリソートならそんなに時間かからんし、
メモリに乗らない量のデータをソートする要件があんまり浮かばん
DWHとかなら結構必要なのか？
0608NAME IS NULL
2014/10/24(金) 20:32:36.90ID:???単純な例のつもりだから大丈夫かと思った。エスパーありがとう。
ビューにインデックスがはれるDBMSなら確かに。でも、そうじゃない場合はどうします？
>>606
あら。
・アーティストテーブル：アーティストID, アーティスト名
・アルバムテーブル：アーティストID, 発売日
にすればよろしいでしょうか。
また、コンピレーションというのは何でしょうか。無知ですみません。
0609NAME IS NULL
2014/10/24(金) 20:36:04.62ID:???・アーティストテーブル：アーティスト名, アーティストID
・アルバムテーブル：アーティストID, 発売日
にすれば、複数のインデックスを元に、limit offset の最適化が行われるということでしょうか。
0610NAME IS NULL
2014/10/24(金) 20:54:16.18ID:???>そうじゃない場合はどうします？
selectの結果の件数が数万件のオーダーなら別にどうもしない
しいて言うならソートワークのメモリ多めに取るようチューニングするぐらい
数千万とか億とかのオーダーなら、そもそもlimit offset するっていう要件を見直す
0611NAME IS NULL
2014/10/24(金) 21:06:31.45ID:???あ、、コンピレーションって複数アーティストが参加しているコンピレーションアルバムのことでしょうか。
てっきり設計手法か何かかと。
例なのでそういうのは無視してもらって、
正規形を満たした状態で、ソート条件が複数テーブルにわたる場合、
インデックスのみでは解決できないように思ってるんですが間違いでしょうか。
> (インデックスや正規化が間違っている)
これに、マテリアライズドビューが含まれているということなのかなぁ。。
>>610
たかが数万件でも、メモリ上でソートを行うのとインデックスが使われるのでは
大きな違いがあると思います。
それがたとえば3ms と 0.02ms で、実際どちらも問題ない速度であったとしても、
query per secでは大きな差になりますよね。
0612NAME IS NULL
2014/10/24(金) 21:07:23.62ID:???最近のオプティマイザって、基本的に全体の処理量が最少になるように最適化するよな
その際にlimitとかoffsetとか考慮されてないよな
この例なら最終的には320件の結果セットがあれば良いわけだから
アーティスト名（のインデックス）を順次ループして320件で打ち切れば良いんだが
そう言う実行計画は作らんのだろうか
これならアーティスト名にインデックスがあればそこそこ行けるんじゃ
昔のオラクルとか、ファーストロウに対して最適化されてたような気がするんだが
0613NAME IS NULL
2014/10/24(金) 21:12:11.88ID:???確かに、アーティストを320件抽出すれば必要最小限のアーティストに対して
アルバムを結合することはできますね。
でも、limit 20 offset (全アーティスト数よりも大きい数字) になった場合、
その最適化は働かなくなります。
0614NAME IS NULL
2014/10/24(金) 21:28:09.14ID:???・アルバムテーブル：アーティスト名, 発売日
というインデックスを作ることができ、limit offset が解決できるようになります。
ただ、アルバムテーブル.アーティスト名の同期を取る手間が増えるんですが、
それはDBMSによってはマテリアライズドビューの同期の手間と同じようなものだと思います。
ソート項目が複数テーブルにわたる場合、正規形を保ったまま、上記のようなインデックスを
はったときと遜色のない性能を出せたことがなく、件数が増えると正規形を崩すのはやむなしかと思ってました。
0615583
2014/10/24(金) 22:03:08.90ID:???SELECT * FROM (SELECT ID FROM ～～ order by アーティスト名, アルバム発売日) offset 300 limit 20
0616NAME IS NULL
2014/10/24(金) 22:21:36.92ID:???0617NAME IS NULL
2014/10/24(金) 22:37:54.57ID:???正規化状態でですか？それなら、差はないかと。
正規化を崩していれば、そのサブクエリはインデックスが同等の働きをするのでサブクエリ化しなくてもよいと思います。
>>616
正規化を崩すことでパフォーマンスがあがる場面はあると思っていたけれど
インデックスや正規化を間違えてるだけ(>>599)という話になったので、
どういう正規化およびインデックスにすれば性能がでるのか教えてほしいと思ってます。
0618NAME IS NULL
2014/10/24(金) 22:57:11.05ID:???特定の状況やクエリを見れば、正規化を崩すことでパフォーマンスが上がる事はある
以上、この話題終了
0619NAME IS NULL
2014/10/24(金) 23:12:11.38ID:???データベースを独学で学ぶうえで、以下のような玄人が思想を説明している動画やサイトってあったりしますか？
http://youtu.be/VK4GpC34fBw
0620NAME IS NULL
2014/10/24(金) 23:38:45.27ID:???別に荒れる質問をしたつもりもないんだけどなぁ。。。
0621NAME IS NULL
2014/10/24(金) 23:53:26.01ID:???>正規形を崩して、アルバムテーブルにアーティスト名を持たせると、
リレーションの正規化ってものを一度ちゃんと勉強したほうがいい。
0622NAME IS NULL
2014/10/24(金) 23:54:45.91ID:R3rzZn6a0623NAME IS NULL
2014/10/24(金) 23:58:50.96ID:???おや、、そこに異を唱える人が出てくるとは思ってなかった。
アーティスト名はアーティストテーブルにあるべきだし
アルバム発売日はアルバムテーブルにあるべきじゃないの？
0624NAME IS NULL
2014/10/25(土) 00:07:39.66ID:???アーティスト名は主キーになりうるから、
アルバムテーブルにアーティスト名を持つことは必ずしも間違いではないという話かも。
そうなら、アーティストテーブルの活動開始日, アルバム発売日ではどうでしょうか。
0625NAME IS NULL
2014/10/25(土) 00:48:10.26ID:???まず「正規形を崩す」という言葉をそのまま解釈するのが、ありがちな間違い
今回のケースは非常に単純なデータモデルで検索条件も確定しているから、
最初からその検索条件に特殊化した(= 最適化した or 崩した)テーブル設計ができた
でも現実世界のDB設計は違う
データモデルは複雑だし検索条件も(遠い未来を含めて)確定できない
新規開発時に(正しい論理設計の後で)正規化を崩してテーブルを実装してしまうと、
その時だけは要求性能を満足できても、その後に長く続く保守(= 機能エンハンス)のフェーズで
異なる検索条件を要求された時に対応が極めて困難になる
だから教科書に書いてあるような「正規形の崩し」は、現場だとバッドノウハウになる
ではどうするかというと、正しく論理設計された(=正規化された)データモデルは触らない
代わりに、特定の検索条件に最適化した検索専用テーブル(「ターボテーブル」とも呼ぶ)を追加する
0626NAME IS NULL
2014/10/25(土) 00:56:17.86ID:???レスありがとうございます。
まったくもっておっしゃるとおりだと思います。
> 代わりに、特定の検索条件に最適化した検索専用テーブル(「ターボテーブル」とも呼ぶ)を追加する
マテリアライズドビューの使用が可能なDBMSであればそれを使えばよく、
使用できないDBMSであれば、マテリアライズドビューの代わりとなるような
実テーブルを用意するということであっていますか？
0627NAME IS NULL
2014/10/25(土) 01:16:38.45ID:???マテリアライズドビューについては理解している自信が無いのでコメントできない
その検索専用テーブルとは、正しく論理設計された(=正規化された)データモデルから
部分的に複写した一時テーブルであり、正規化の原則に従う必要は無い(>>614もO.K)
複写処理はデータモデルの更新処理と完全に同期させる完全な方法もあるけど、
一定期間毎の複写でもかまわないケースは多い（一時的に実データと検索結果にズレが生ずる）
0628NAME IS NULL
2014/10/25(土) 02:31:23.66ID:???今のマテビューがどうなってるか知らんが、オラクル以外でこの用語つかってるDBMSあるかな？
マテビューってのはもともとオラクルでレプリケーションのための実データ（のコピー）を持つビューだったはず
検索のためのインデックス付きビューは実データ部分は持つ必要ない
あくまでインデックス項目のデータだけ持てばいい
そういう意味ではインデックス付きビューとマテビューを同一視するのはどうかと思うのだが
あと>>625の言うターボテーブル（この言い方は初めて聞いたが）も
更新のコストの問題があるから、ターボテールブル作成（更新）のタイミング等をコントロールしたりする
これもマテビューとは別ものと考えないとダメじゃないかな
あとそもそも、インデックスは制約じゃないので、本来はＤＢ設計じゃなくてチューニングの話ね
（当然ＤＢ設計時にある程度は見越しておくけど）
性能要件もＤＢ設計だって言うなら話は別だが
0629NAME IS NULL
2014/10/25(土) 05:36:58.95ID:???もともとは、正規化されたテーブルとそれぞれのインデックスだけでは、
本来出てしかるべき性能が出ないことがあるというのを説明するための最小構成の例を出すためでした。
お付き合いありがとうございました。
>>627
検索専用テーブルを用意すれば更新コスト、ディスク領域使用量は増えてしまいますが、
汎用的に解決できる方法だと思いました。
それを思いついたことはあっても、不恰好な気がして手を出せずにいましたが、
実際応答速度が上がると思うので使ってみます。
>>628
細かな機能的には差異があるかもしれませんが、PostgreSQLにもマテリアライズドビューがあります。
インデックス付きビューが実装されているDBMSはとても楽に今回の問題が解決できるので、
使える場合は積極的に使うようにします。
0630NAME IS NULL
2014/10/25(土) 08:43:46.25ID:???PKは商品コード
アーティスト名は別アルバムで被るからPKにならない
0631NAME IS NULL
2014/10/25(土) 09:01:16.28ID:???本来はこうなるはず
PKが商品コード
select アーティスト名、発売日
where 発売日 between a and b
order by 商品コード、発売日
なので、インデックスいらんな
0632NAME IS NULL
2014/10/25(土) 10:28:50.77ID:???アルバムごとにアーティスト名を変えたりするケースもあるから
アルバムテーブルにもアーティスト名のカラムは入れた方が良いと思う
0633NAME IS NULL
2014/10/25(土) 12:55:24.16ID:???商品(アルバム)のPKは商品コード
アーティストのPKはアーティストID
select b.アーティスト名、a.発売日
from 商品 a inner join アーティスト b
where a.アーティストID = b.アーティストID
a.発売日 between a and b
order by b.アーティスト名、a.発売日
駆動表が商品だから、order byでインデックス効かない
0634NAME IS NULL
2014/10/25(土) 14:31:04.25ID:???いちいち調べたり、アーティスト名の表記の違いを名寄せする手間が必要になったりする。
正しくアーティストを特定するというのが要件のうちであればそれでいいんだけどね。
0635NAME IS NULL
2014/10/25(土) 21:04:38.81ID:???0636NAME IS NULL
2014/10/25(土) 21:32:09.35ID:???trfがTRFに変わったように年代ごとに細かく分けたい気持ちはわかる
0637NAME IS NULL
2014/10/25(土) 21:49:08.16ID:???0638NAME IS NULL
2014/10/25(土) 22:20:59.07ID:???要は、>>633の設計を成り立たせるには、IDを決定するのにそこに存在しない
情報が必要になるかもしれないという話。
0639NAME IS NULL
2014/10/26(日) 02:44:25.73ID:???0640NAME IS NULL
2014/10/26(日) 02:47:04.27ID:???それこそ上でも出ていたようなV.A.であるようなCDを
どう管理するのかのほうを急いだほうがいいんでない？
0641NAME IS NULL
2014/10/26(日) 03:43:08.83ID:???興味はあるけど、まず要件がまとまらんだろ
0642NAME IS NULL
2014/10/26(日) 08:04:21.98ID:???ひどいのになるとフィールド名見ただけで「それは正規化されてない」とか言っちゃうしなぁ。
0643NAME IS NULL
2014/10/26(日) 09:20:20.48ID:???0644NAME IS NULL
2014/10/26(日) 09:35:39.26ID:???0645NAME IS NULL
2014/10/26(日) 09:52:06.49ID:???ポストイットとホワイトボード
0646NAME IS NULL
2014/10/26(日) 09:59:21.71ID:???0647NAME IS NULL
2014/10/26(日) 10:11:34.91ID:???出来上がった物は、スマホで撮影するよな
0648NAME IS NULL
2014/10/26(日) 18:47:31.66ID:???0649NAME IS NULL
2014/10/26(日) 20:04:36.68ID:???SQL Developer Data Modeler
紙、ボールペン、ホワイトボード
0650NAME IS NULL
2014/10/26(日) 20:33:09.53ID:???テーブル定義書…Excel
テーブル作成のSQL…Excelのマクロ
0651NAME IS NULL
2014/10/26(日) 22:41:58.36ID:???何で設計を学びましたか？
0652NAME IS NULL
2014/10/26(日) 23:26:28.22ID:???・先輩・上司から学ぶ
・データベース設計に関する参考書
・SQLアンチパターンの参考書
・Oracle Database設計の講習
0653NAME IS NULL
2014/10/26(日) 23:46:29.61ID:???Oracle=高いというなんとなくイメージがあり敬遠してましたが、講習は無料もあるみたいですねー
0654NAME IS NULL
2014/10/26(日) 23:54:32.92ID:???会社の金で↑いったずら
0655NAME IS NULL
2014/10/27(月) 14:50:00.90ID:???うまいこと連携させる回し方みたいなのありませんかね
0656NAME IS NULL
2014/10/29(水) 12:50:37.43ID:???いま取り組んでるものは、質問内容に対して回答し、クローズするワークフローシステムです。
大きなフローとしては
「質問部署→回答部署→クローズ部署」
で、その各部署内で「作成→審査→承認」のフローがあります。
お客様からは以下の要望は必ずみたして欲しいと言われています。
要望1.前部署への差し戻し機能、部署内での差し戻しがあります。
要望2.ワークフローを変更した場合の既存プログラム改修を最小限になるデータベースにして欲しい。
要望3.回答部署は複数部署可能とする。その際は各回答部署内で並列に作成審査承認をし、全回答部署が承認された場合に、クローズ部署にいく。
0657NAME IS NULL
2014/10/29(水) 12:52:58.07ID:???今考えてるテーブル書いてみ？
0658NAME IS NULL
2014/10/29(水) 13:01:57.23ID:???0659NAME IS NULL
2014/10/29(水) 14:31:06.36ID:???ちゃんと作るなら稟議のミニセットだしそれだけ作るなら機能として片手落ち
0660NAME IS NULL
2014/10/29(水) 21:31:50.41ID:???出来合いのワークフローのソフトとか使ってみて仕様確認しながら
要件定義ちゃんとした方がいいような気もするなぁ
で、出来合いのやつでいいかもしれないし
最低限で作るとしても、
こんな場合はどうするんだとか、後からいろいろ出てきたり
ちょっと汎用的に作ろうとするとそれなりに
大がかりになりそうだし
まず、権限設定と、ログインして使用してもらう必要があったりとかもあるな
0661NAME IS NULL
2014/10/29(水) 21:34:59.02ID:???先輩にはデータベース設計を勉強してこいと言われました
質問(質問ID(PK)、内容、作成者、作成日、審査者、審査日、承認者、承認日)
回答(回答ID(PK)、内容、作成者、作成日、審査者、審査日、承認者、承認日)
クローズ(クローズID(PK)、内容、作成者、作成日、審査者、審査日、承認者、承認日)
質問回答連関(質問ID(PKFK)、回答ID(PKFK))
回答クローズ連関(回答ID(PKFK)、クローズID(PKFK))
ユーザ(ユーザID(PK)、名前、部署ID(Fk)、作成権限フラグ、審査権限フラグ、承認権限フラグ、削除フラグ)
部署(部署ID(PK)、部署名、削除フラグ)
0662NAME IS NULL
2014/10/29(水) 22:29:10.51ID:???俺ならheader-detailで遷移はheader.statusで対応
0663NAME IS NULL
2014/10/29(水) 23:48:38.92ID:???要求事項だけで機能仕様が不明確な段階では、
いきなり論理設計(=デーブル設計)に着手するよりも
概念設計から始めたほうがいいと思う
概念設計を簡単に説明すると：
・要求書に含まれた単語で表される概念を列挙して箱として描き、
・関連する(と思われる)概念の箱の間に線を引き
・概念の役割を以下から割り当て、箱に記入するか楕円や菱形へ書き換える
実体(エンティティ)/識別情報(キー)/属性(アトリビュート)/リレーション(関連)
最初はホワイトボードや裏紙にラフスケッチすることから始めよう
今回のケースだと、概念設計のポイントは以下の２点
・ワークフローシステムは、部署をノード(節)、ワークフローを矢印(アーク)とする
有限グラフとして表現できる
・「作成→審査→承認のフロー」は、質問および回答が持つ「状態の遷移」として表現できる
具体的なE-R図(データモデル)と状態遷移図(状態モデル)を以下にアップしておいた
http://www.h6.dion.ne.jp/~machan/misc/workflow-data.png
http://www.h6.dion.ne.jp/~machan/misc/workflow-state.png
これを「叩き台」にして、シナリオとの整合性を検査したり、論理ER図、状態遷移表、
そして手続き(=遷移)等の詳細化を試みるのがいいのではないかと思う
>>657,658,659
システム開発において、DB設計(データモデルの設計)から着手するという
>>656の検討方針(先輩の指導方針？)は妥当だと思うよ
まあ、要求分析や製品企画といった上流工程の実務経験が無い人には難しいかもしれないね
0664NAME IS NULL
2014/10/29(水) 23:58:54.80ID:???X：・ワークフローシステムは、部署をノード(節)、ワークフローを矢印(アーク)とする
有限グラフとして表現できる
O：・ワークフローシステムは、部署をノード(節)、ワークフローをアーク(矢印)とする
有向グラフとして表現できる
0665NAME IS NULL
2014/10/30(木) 00:05:07.54ID:???0666NAME IS NULL
2014/10/30(木) 00:11:11.38ID:???いいんじゃねーの。
作成者、審査者、承認者はユーザIDなんでしょ？
先輩の言いたいことはあらかた予想できるけれど、
それをどう結合して、どう操作すれば運用をしていけるか先輩に説明してみたらどうだい。
0667NAME IS NULL
2014/10/30(木) 00:12:08.11ID:???上流経験が本当にあるなら要件整理した段階で開発は止めるレベルの物だよ
0668NAME IS NULL
2014/10/30(木) 01:28:17.03ID:???出来合いのもの金出して買うの？
軽いものでいいから
新人の教育がてらに費用かけずにやろうって計画に見えるな
0669NAME IS NULL
2014/10/30(木) 03:17:20.16ID:???0670NAME IS NULL
2014/10/30(木) 07:49:25.93ID:???ありがとうございます。
作成、審査、承認というイベントを分割出来るか考えてみます。
また、履歴について考慮していなかったので、全ての処理履歴を取れるように改善します。
0671NAME IS NULL
2014/10/30(木) 07:58:37.72ID:???この手のアプリケーションなら普通に DB 使うだろ。
>>668
お客様って言ってるのがちょっと引っ掛かるが、その先輩が勉強がてらちょっとやらせてみてるって感じなんだろうな
>>661 で、ユーザー/部署テーブルに削除フラグつけてたりするから全くド素人って言うわけでもなさそうだし
0672NAME IS NULL
2014/10/30(木) 11:21:36.22ID:???紙ベースなのか、既存の仕組みがあるのか
どんな紙の書式なのか
どういった点を、改善したいと思ってるのか
実験的なシステムなのか
おそらく関係部署が多いと、調整も必要
誰が誰に承認依頼を出すのかとか、代理承認とかも許すのかとか
0673NAME IS NULL
2014/10/30(木) 12:54:04.15ID:???受注が確定してないので教育がてらに私が任命されました。今はお客様のふりをした先輩とやりとりしています。本業務は別なので、進みは非常に悪いです。
>>672
背景は現状メールでやりとりされていて、しっかりと管理されていない情報がある。ISO監査で指摘されたのでシステム化するものです。(詳細不明)
上記の理由により仮定となりますが、>>656に以下を考慮し、もう一度考え直します。
1.部署はたくさんあり。各部には質問、回答、クローズの実施権限を付与する。
2.ユーザーは部署、課に所属する。課を兼任する場合があり。
3.同じ課の同一権限をもつユーザーの代理承認は可能。履歴は代理承認した人とする。
4.各ステップで次ステップのユーザーを指定する。そのユーザにメールがいく。
5.全ての処理は履歴をとる。
検索画面では全て追えるようにする。
6.各処理で添付ファイルをつける。
添付ファイルをつける際にはいくつかの属性を付加する。
ファイルはファイルサーバに格納。
7.ASP.NET+Oracle
0674NAME IS NULL
2014/10/31(金) 14:31:13.09ID:???出来合いを検討したけどそれでも開発するって場合は
使い勝手は出来合い並みを求められそうで大変かな
0675NAME IS NULL
2014/11/01(土) 21:33:03.97ID:???そうですねー。比べられると辛いです。
ちょっと放置してましたが
「作成→審査→承認」が、
「作成→審査1→審査2→承認1→承認2」など動的に増やせるようにするとこ考えなきゃ。。。
0676NAME IS NULL
2014/11/02(日) 00:41:03.67ID:???--------------------------------------
1, 1, 2, 作成
1, 2, 3, 審査1
1, 3, 5, 審査2
1, 4, 7, 承認
こんな感じで必要なイベントを管理するテーブルでも作っときゃいいんでない？
0677NAME IS NULL
2014/11/02(日) 12:58:21.61ID:???少しはやりやすいが
フェーズ1で導入に理解のある部署に絞ってパイロット導入して
不足機能を洗い出す
フェーズ2で部署を増やして機能追加パターン網羅に努める
フェーズ3で全面導入とかか
新しい機能を使ってもらうのに
問題を感じていない積極的でない部署を説得させるには
ある程度実績がないと、なにかと難しかったりする
部署間調整に結構時間は割かれる
思いつき仕様をどれだけ抑えつつ便利に使ってもらうか
多分仕様は言い出すと切りがない
メール1回じゃ忘れるので承認要請リマインダーを煩わしくない感じで定期的に出してくれとかね
0678NAME IS NULL
2014/11/02(日) 13:56:02.19ID:???> 多分仕様は言い出すと切りがない
稟議システム外販してたけど、マジできりがないよ
稟議のフローに関するところはまだしも、社員情報システムとの連携（承認した奴が辞めちゃった時に差し戻されたらどうするとか
、次の承認者を設定する画面で候補者の並び順が気に入らないとか）が地味に面倒
0679NAME IS NULL
2014/11/02(日) 18:56:13.75ID:???DB上は格納できるように設計し、あとは全部アプリ側で頑張ってもらえば
良い気がするがどうだろう
どんな要件が出そうかは充分に洗い出す必要があるけど
0680NAME IS NULL
2014/11/02(日) 19:23:35.85ID:???ユーザー要件に応じて様々にカスタマイズできるよう、テーブルはほとんど
ただの入れ物扱いでエクセル表みたいになってる。
DB設計としては吐き気がするような代物だけど。
0681NAME IS NULL
2014/11/02(日) 19:45:36.78ID:???> テーブルはほとんどただの入れ物扱いでエクセル表みたいになってる。
単にお前んところの設計が糞なだけじゃん w
0682NAME IS NULL
2014/11/02(日) 20:29:32.36ID:???思ったりするけど
結局その定型業務用に特化したシステムにしたほうが
いいような気がしたりする
項目をユーザーが登録できるような
汎用的なつくりにしていくと多分>>680のようになる
0683NAME IS NULL
2014/11/02(日) 20:40:55.55ID:???0684NAME IS NULL
2014/11/02(日) 21:04:39.13ID:???DBスレでつり？
0685NAME IS NULL
2014/11/02(日) 21:18:23.36ID:MzPGu/L1別にDBのテーブルレイアウトそのままEXCELに持っていくこともできるわけだが
0686NAME IS NULL
2014/11/02(日) 21:27:11.80ID:???それが本来の正しい姿
テクニカルが凄い！とかただのマスターベーションだよ
0687NAME IS NULL
2014/11/02(日) 21:42:49.74ID:???つり？意味不明
0688NAME IS NULL
2014/11/02(日) 21:44:12.44ID:???このスレ見ない方がいいかと...
0689NAME IS NULL
2014/11/02(日) 21:59:50.00ID:???ここRDB専門スレだっけ？
0690NAME IS NULL
2014/11/02(日) 22:12:08.30ID:???RDB 専用じゃないけど
> RDBならEXCEL表とほぼ同じだろう
程度の理解力だとねぇ...
0691NAME IS NULL
2014/11/02(日) 22:14:47.26ID:???0692NAME IS NULL
2014/11/02(日) 22:17:07.51ID:???あんた、真のEXCEL使いを見たこと無いだろ！
0693NAME IS NULL
2014/11/02(日) 22:22:27.74ID:???0694NAME IS NULL
2014/11/02(日) 22:41:01.42ID:???印刷ズレまくるのに
普通に集計、分析とかで表として使ってみ
0695NAME IS NULL
2014/11/02(日) 22:48:51.49ID:???どんなExcelになっててどんな表が良かったのか
興味出てきた
0696NAME IS NULL
2014/11/03(月) 00:43:12.29ID:???0697NAME IS NULL
2014/11/03(月) 03:52:20.53ID:???正規化の限界か
0698NAME IS NULL
2014/11/03(月) 04:51:14.63ID:???0699NAME IS NULL
2014/11/03(月) 09:25:54.64ID:???> エクセルのあるべき姿
Excel スレに行けよ...
0700NAME IS NULL
2014/11/03(月) 09:54:27.76ID:???マスターのマスターをつくる感じで
ユーザー管理者が項目を追加できるような仕組みを作ることは
できることだと思うが
実際にユーザーがデータを入力したあとは
項目変更に制限を加えたり
システム連動項目の仕組みを入れたり
マスターのバージョン管理をするようにしたほうが
よかったりというのはあると思う
もっと汎用的にしようと思えばユーザー管理者が
create tableする仕組みも考えられると思うが
ワークフローシステムの場合にそこまでするのかはわからん
0701NAME IS NULL
2014/11/03(月) 10:11:23.36ID:???列追加で終わりだし
正規化も出来るだろう
0702NAME IS NULL
2014/11/03(月) 10:57:28.91ID:???1シート1テーブルだろ
否定有りきで無茶論（笑）
0703NAME IS NULL
2014/11/03(月) 11:08:57.34ID:???頭悪いなあんた。
0704NAME IS NULL
2014/11/03(月) 11:47:11.80ID:???誹謗中傷スレに行けよ
そんなスレがあるかどうかは知らんけど w
0705NAME IS NULL
2014/11/03(月) 11:49:03.35ID:???Xcuteってツールが面白そうではある
かなり前と思うが日経なんとかに出てたかな
実際に使ったことはないが
今見たらXlsFlowってのもあるみたいだし
0706NAME IS NULL
2014/11/03(月) 11:49:27.98ID:???言わんとすることを理解もできずExcelスレに行けというのがまともなレスだと思えるのか
表計算ソフトを使えないことの自己紹介なのかね。
0707NAME IS NULL
2014/11/03(月) 11:53:54.72ID:???0708NAME IS NULL
2014/11/03(月) 11:58:11.00ID:???0709NAME IS NULL
2014/11/03(月) 12:10:01.68ID:???ＤＢ設計と結びつけて語らないとな
0710NAME IS NULL
2014/11/03(月) 12:14:12.73ID:???> ただの入れ物扱いでエクセル表みたいになってる。
> DB設計としては吐き気がするような代物だけど。
んだから、こうやって引き合いに出される「エクセル表」が、どの程度のエクセル表なのかって話になるわけじゃん。
吐き気がするような表を使ってる時点で、エクセルをまともに使うことすらできずに卑下するなんておかしくねってことで。
0711NAME IS NULL
2014/11/03(月) 12:21:04.58ID:???>>680の
>ただの入れ物扱いでエクセル表みたいになってる。
これの解説を誰かよろしく
0712NAME IS NULL
2014/11/03(月) 12:24:57.77ID:???はいはい、真の Excel 使いなのはわかったから、いい加減どっか行けよ
0713NAME IS NULL
2014/11/03(月) 12:29:41.15ID:???設計論でテーブルとエクセルの違いって？
0714NAME IS NULL
2014/11/03(月) 13:05:11.22ID:???0715NAME IS NULL
2014/11/03(月) 14:08:45.36ID:???数字だろうがなんだろうが、全カラム CHAR(255)。
もちろん外部制約やユニーク指定もない。
そしてインデックスすら張ってない。
そんな糞ミドルをよく見かける。
0716NAME IS NULL
2014/11/03(月) 14:20:09.97ID:???ユニークとインデックス以外はエクセルでも出来るし
やっぱエクセル表みたいってのはエクセルにも失礼な状態だな
0717NAME IS NULL
2014/11/03(月) 14:49:30.25ID:???京大式カード使うほうが安上がりな気がする
0718NAME IS NULL
2014/11/03(月) 19:55:16.35ID:???それをエクセル表みたいと表現したのがまずいだけだと思うわ
エクセルにも劣るとか、エクセル初心者が作った表とかさ、いろいろあるじゃん
0719NAME IS NULL
2014/11/04(火) 06:46:58.09ID:???excel優秀なのに
0720NAME IS NULL
2014/11/04(火) 07:49:22.29ID:???メンテしにくくなるし
0721NAME IS NULL
2014/11/04(火) 08:16:11.67ID:???小規模ならそうなんだけど、大規模システムで制約がないとか怖すぎる
0722NAME IS NULL
2014/11/04(火) 14:05:21.25ID:???手でメンテするからじゃないかな
0723NAME IS NULL
2014/11/05(水) 19:41:04.40ID:???問診アンケートみたいなやつだと項目がやたら多くて
マスターというかアンケートの雛形を作って
さらにアンケートの種類によって項目が違う
回答欄がテキストか数値かとかの項目の種類もあるし
サブタイプとしてテーブル分けたりしたほうがいいのかもね
それでも記録だけならいいんだけど、回答の値を他で
有効に使うにはさらに仕組みが要る
まあ項目を汎用的な仕組みにするのは
使う場面は限定したいし、やらずに済めばそれがいい
あんまりRDB向きではないということだろう
SQLアンチパターンはいい本だな
0724NAME IS NULL
2014/11/05(水) 20:13:17.38ID:???一発物は手作業でしょ
0725NAME IS NULL
2014/11/05(水) 20:55:57.21ID:???一発物だからという綻びが被害を拡大する
0726NAME IS NULL
2014/11/05(水) 21:04:27.39ID:???何の被害だよ？
私失敗しないので
0727NAME IS NULL
2014/11/05(水) 22:39:19.72ID:???0728NAME IS NULL
2014/11/05(水) 22:43:05.33ID:???お前自体が失敗だろ
0729NAME IS NULL
2014/11/06(木) 00:42:18.75ID:???0730NAME IS NULL
2014/11/07(金) 00:12:57.39ID:???0731NAME IS NULL
2014/11/07(金) 08:01:51.77ID:???0732NAME IS NULL
2014/11/07(金) 12:07:45.59ID:???・商品テーブルの売値
みたいな話なんでないの？
0733NAME IS NULL
2014/11/07(金) 12:45:02.55ID:???どこの講習だよ w
マジでそんなこと言ってるなら、晒していいレベルだわ
0734NAME IS NULL
2014/11/07(金) 12:52:48.36ID:???0735NAME IS NULL
2014/11/07(金) 13:50:33.98ID:???他にもいろいろケースはあると思う。そのイベントが発生した時点の値がわからなくなるからイベントテーブルに外部キーは設定しないほうが安全だと言っていた。
講習代で一日三万もはらったよ
0736NAME IS NULL
2014/11/07(金) 14:02:53.74ID:???0737NAME IS NULL
2014/11/07(金) 15:31:11.29ID:???内容が違えば何度でも手動でメンテしますよと。なんせ一発ものですからね。
やっぱ被害は拡大する一方。
0738NAME IS NULL
2014/11/07(金) 20:09:38.63ID:???内容が毎回変わっても自動化できる方法を示さないとね
0739NAME IS NULL
2014/11/07(金) 20:12:16.46ID:???その考え方をする状況に至ってるのがもうだめ。
0740NAME IS NULL
2014/11/07(金) 20:25:18.85ID:???手作業……被害拡大
自動化……考えが駄目
0741NAME IS NULL
2014/11/07(金) 20:27:32.10ID:???0742NAME IS NULL
2014/11/07(金) 20:54:22.72ID:???0743NAME IS NULL
2014/11/08(土) 00:06:17.00ID:???0744NAME IS NULL
2014/11/08(土) 00:07:33.77ID:???> その考え方をする状況に至ってるのがもうだめ。
状況に至ってる、なるほどわかる
0745NAME IS NULL
2014/11/08(土) 03:33:23.00ID:???0746NAME IS NULL
2014/11/11(火) 12:27:19.65ID:???0747NAME IS NULL
2014/11/11(火) 23:21:37.69ID:???何それ？どうやったらそうなんの？逆に知りたいわ
0748NAME IS NULL
2014/11/11(火) 23:50:22.49ID:???0749NAME IS NULL
2014/11/15(土) 21:58:25.51ID:???外部キーは無関係。
0750NAME IS NULL
2014/11/19(水) 10:34:29.41ID:???これを関係データベースとして使えるようにするにはどうすればいいですか？
0751NAME IS NULL
2014/11/19(水) 10:47:32.77ID:???声優マスタ(voice_id,voice_name)
出演データ(anime_id,voice_id)
0752NAME IS NULL
2014/11/19(水) 10:48:12.52ID:???まあ代替わりとかメディアによっては変わるけど同じ作品内ならほぼ固定でしょ
0753NAME IS NULL
2014/11/19(水) 11:32:03.92ID:???同じ作品内という括りでは考えていません
今までの全てのアニメとそれに出演した声優でデータベースを作りたいと考えています
0754NAME IS NULL
2014/11/19(水) 11:39:45.60ID:???連関ってやつですか
ありがとうございます！
0755NAME IS NULL
2014/11/19(水) 19:40:58.07ID:???キャラクターの情報は要らない？
0756NAME IS NULL
2014/11/19(水) 20:30:13.45ID:???おせっかい
0757NAME IS NULL
2014/11/21(金) 23:08:46.40ID:???0758NAME IS NULL
2014/11/21(金) 23:45:27.87ID:???ベンチ用のデータ
0759NAME IS NULL
2014/11/22(土) 01:00:30.78ID:???普通はどのくらいから大量って呼ぶんだろうか？
0760NAME IS NULL
2014/11/22(土) 03:45:59.58ID:???なんか多そうなのいくつか
郵便番号csv (日本郵便)
ttp://www.post.japanpost.jp/zipcode/download.html
気象データ(気象庁)
ttp://www.data.jma.go.jp/gmd/risk/obsdl/
基盤地図情報(国土地理院)
ttp://fgd.gsi.go.jp/download/
0761NAME IS NULL
2014/11/22(土) 03:49:14.53ID:???livedoorのグルメdatasetも割と多いんだっけかな？
ttp://blog.livedoor.jp/techblog/archives/65836960.html
0762NAME IS NULL
2014/11/22(土) 05:53:15.05ID:???ありがとうございます！
0763NAME IS NULL
2014/11/22(土) 13:16:56.44ID:???国の集めてるデータ自体は只なのを知らん人多よな（笑）
0764NAME IS NULL
2014/11/22(土) 13:32:55.26ID:???0765NAME IS NULL
2014/11/22(土) 13:53:43.48ID:???0766NAME IS NULL
2014/11/22(土) 20:18:46.29ID:???突然どうしたの？
0767NAME IS NULL
2014/11/26(水) 14:08:21.22ID:???データベースに入力するがまとめる作業なのだから二度手間ですか。
0768NAME IS NULL
2014/11/26(水) 14:31:41.38ID:???0769NAME IS NULL
2014/11/26(水) 14:59:25.15ID:???条件検索できる形にします。
資料からデータを引用入力する過程を、データベースに直接打ち込むか、
EXCELで一覧を作ってからデータベースを作るかということなのですが。
Excelで予めまとめたものは、MYSQLに再び手入力しなくても、コピーか自動転送できるものですか。
0770NAME IS NULL
2014/11/26(水) 15:07:04.63ID:VxueBJXevbaで一気に入れてる
他のDBではインポートの機能があるけど
0771770
2014/11/26(水) 15:08:57.08ID:???0772NAME IS NULL
2014/11/26(水) 15:23:40.97ID:???web上で検索できるDBにしたかったので、mysqlについて尋ねました。
これが完成したらきっと世のため人のためになると思うのだけど
初心者なので遠い道のりになりそうです。どこかに協力者がいないものか。
知恵を貸して頂いてありがとうございます。
0773NAME IS NULL
2014/11/27(木) 02:33:23.80ID:???0774NAME IS NULL
2014/11/27(木) 13:02:24.07ID:/d36AIiz0775NAME IS NULL
2014/11/27(木) 16:22:27.75ID:yC4odKj70776NAME IS NULL
2014/11/27(木) 17:11:28.17ID:???0777NAME IS NULL
2014/11/28(金) 00:09:35.10ID:???実際に見た事あるが地獄だぞ
0778NAME IS NULL
2014/11/28(金) 00:52:57.64ID:???その代案がMySQLってか？
0779NAME IS NULL
2014/11/28(金) 00:56:23.09ID:???0780NAME IS NULL
2014/11/28(金) 13:37:17.80ID:tkpwrtJQ0781NAME IS NULL
2014/11/29(土) 01:32:58.03ID:???0782NAME IS NULL
2014/12/01(月) 19:20:30.62ID:TYW4z9TX管理者がいちいち本のデータを手入力したんだと思いますか。
それとも自動で吸い出しというかリンクさせるのだと思いますか。
不動産サイトやグルメ情報サイトでも、個々の情報を載せてくれっていう客の送ってきたデーターを
管理側でいちいち手入力しているんですか。それとも
0783NAME IS NULL
2014/12/01(月) 19:32:47.23ID:???これで予想がつくかと。
http://bookmeter.com/help/?id=22
0784NAME IS NULL
2014/12/01(月) 22:48:42.01ID:???0785NAME IS NULL
2014/12/01(月) 23:22:46.79ID:???世の中にはWeb APIとかいうような類の便利なものがあってだな
0786NAME IS NULL
2014/12/02(火) 00:27:28.83ID:???予想つかない。ソースを表示とかしても察しつかなかった。私は素人。バカです。
>>782
そうなんだ。APIっていうのがamazonのデータが流用できるようなパッケージなのかな。
難しいね。プログラマの人はみんなこういうことを当然のように知っているのね。
0787NAME IS NULL
2014/12/02(火) 02:38:05.73ID:???このスレに来るの早すぎるんじゃね？
0788NAME IS NULL
2014/12/02(火) 03:10:55.97ID:???そうだね。
たとえばWindowsで動作するソフトウェアを作ろうとしたらAPIバイブルという本が必須の時代があった。
最低限必要な2冊を買うと2万円ぐらいかかったが。
つまり、APIがなんなのかは当然知っていたよ。
ハードルが低くなるということは、低レベルの知識が欠落したプログラマを生むことに他ならない。
0789NAME IS NULL
2014/12/02(火) 03:17:03.18ID:???やはり習得時期には既に先人によって甘い皮に包まれてしまっていたレベルの知識は欠落しているのである。
0790NAME IS NULL
2014/12/02(火) 10:39:24.02ID:???rdb xml、rdb json、kvsでググれ
間違ってもc1、c2・・・はすんなよｗ
0791NAME IS NULL
2014/12/02(火) 20:20:40.59ID:???NoSQLってやつ？
ニュースでは見るけど、実際に触ったことないなあ
ACID特性持たすのが大変ときいたが
0792NAME IS NULL
2014/12/02(火) 21:34:48.11ID:???NoSQLに該当するのはkvsだけだな。
てか、しらないなら書かれてるとおりググれよｗ
0793NAME IS NULL
2014/12/03(水) 12:55:40.79ID:???ポケベル→ケータイ→スマホ
スマホしか知らない小学生が、ポケベルもケータイも使ってからしか
立派なスマホアプリは作れないってこともないと思うんだけど
そういうこととは違うのか。
0794NAME IS NULL
2014/12/03(水) 14:00:27.54ID:???0795NAME IS NULL
2014/12/03(水) 17:17:22.58ID:???どう違うの？うまく説明してみて。
0796NAME IS NULL
2014/12/03(水) 17:50:35.83ID:???ケータイも電話する部分を作るなら必要だがでんセに関係ない部分に連続性はない
0797NAME IS NULL
2014/12/03(水) 18:14:15.72ID:???スマホにポケベル入ってるの
0798NAME IS NULL
2014/12/03(水) 19:51:28.03ID:???プログラミングは、古いものから進化してきた過程に連続性があるから
最初から全部勉強しなくては新しいのだけ見てもわからないということなんだね。
進化してきたということは、そうなる理由があったと思うから、最新のものを学べば、
一番手っ取り早いだろうと思ってたんだけど。
古参のプログラマーの人は、自分たちが通ってきた苦難の道を、新人が通らずにいきなり同じ到達点に来られるのが
なんか癪だから、わざと遠回りさせたがっているのかと思ったけど、違うんだね。
0799NAME IS NULL
2014/12/03(水) 20:28:55.47ID:???頭悪いだろ
0800NAME IS NULL
2014/12/03(水) 20:43:55.10ID:???0801NAME IS NULL
2014/12/03(水) 23:47:45.24ID:???？
0802NAME IS NULL
2014/12/03(水) 23:57:41.16ID:???俺は指導側だがそんな今後使う必要が薄いとこは教えないなぁ
そこで詰まられても本当に時間の無駄だし
0803NAME IS NULL
2014/12/04(木) 00:03:39.77ID:???欠落してるからダメだとは言ってない。
0804NAME IS NULL
2014/12/04(木) 03:32:55.29ID:???ホストアプリ側、とくにWindowsに限れば
開発環境と言語の進歩が低レベルなAPIを使う必要性を無くして行ってるからな
それでも変わった事やろうとするとAPI呼び出しに頼らざるを得ない事もあるにはあるが
全てのプログラマがWinAPI呼び出し必須だった時代なんてとっくに終わってる
0805NAME IS NULL
2014/12/04(木) 05:08:52.97ID:???0806NAME IS NULL
2014/12/04(木) 07:01:33.78ID:???>>788 が...
> ハードルが低くなるということは、低レベルの「知識が欠落したプログラマ」を生むことに他ならない。
って書いたからだろ。
0807NAME IS NULL
2014/12/04(木) 12:35:54.37ID:???「低レベルの知識」が欠落したプログラマ
なのに
0808NAME IS NULL
2014/12/04(木) 12:58:02.91ID:???だから、曖昧なこと書くなよってことだよ
マジで説明が要るとは思わなかった
0809NAME IS NULL
2014/12/04(木) 16:37:10.19ID:???0810NAME IS NULL
2014/12/04(木) 16:54:09.18ID:???0811NAME IS NULL
2014/12/04(木) 17:17:36.79ID:???0812NAME IS NULL
2014/12/04(木) 17:25:20.57ID:???0813NAME IS NULL
2014/12/04(木) 17:36:04.01ID:???頭悪く見えると思うけど、わかりたいから質問した。んで、わかった。
>>802のような考え方が自分は合理的だし好き。自分が習うならこの人に教わりたい。
低レベルな奴が増えてるんじゃなくて、このスレでは自分一人だと思います。
習うといっても、基本の本を端から端までとか、自分は待てない。
作りたいものを作りながら、聞きたいことが出たらちょこちょこ教わって早く結果が欲しい。
早くここの住人に追い付きたいよ。
0814NAME IS NULL
2014/12/04(木) 17:41:32.81ID:???根本的でかつ単純な判断すらできない素人なのはわかったよ。
0815NAME IS NULL
2014/12/04(木) 17:57:52.43ID:???プログラマ板でアホどもとどうでもいい話でもしとけ
0816NAME IS NULL
2014/12/04(木) 19:18:47.47ID:???そもそも低レベルと言う奴がおかしい
低レイヤーだろ
0817NAME IS NULL
2014/12/04(木) 19:32:06.74ID:???0818NAME IS NULL
2014/12/04(木) 19:43:25.53ID:???0819NAME IS NULL
2014/12/04(木) 20:13:32.60ID:???0820NAME IS NULL
2014/12/04(木) 21:10:47.56ID:???グーグル地図に投稿するサイトとかも、簡単に作れるのか？
放射線量を投稿するサイトとか、ポストの位置を投稿するサイトとかあったろ？
ああいうのは、どやって作るん？素人には無理か？君らでも時間かかるのか？
そういうの作れる人と友達になりたかったら、どこにいったら会えるんかな。
0821NAME IS NULL
2014/12/04(木) 21:14:11.64ID:???0822NAME IS NULL
2014/12/04(木) 21:41:00.62ID:???0823NAME IS NULL
2014/12/04(木) 21:49:19.56ID:???つてがなければクラウドソーシングを利用する
ただで作って欲しいという意味ならあきらメロン
0824NAME IS NULL
2014/12/04(木) 22:50:12.20ID:???お金を払っても中身が自分にわかるように教えてくれるなら全然いいよ。
ちな、いくらぐらいでなら>>820みたいなの作って貰えるん？
0825NAME IS NULL
2014/12/04(木) 22:52:29.10ID:???いくらぐらいなら出せるの？5万ぐらいとか？
0826NAME IS NULL
2014/12/04(木) 23:26:02.41ID:???スレタイを声に出して10回読んでみろ
0827NAME IS NULL
2014/12/04(木) 23:29:41.15ID:???５万円でちゃんとやってくれるん？
0828NAME IS NULL
2014/12/04(木) 23:35:11.75ID:???やっぱり想定してる金額が相当少ないみたいだね。
5万だとどんなに優しく見積もっても1日で出来上がるシステムしか請けられないよ。
上で書いてるようなものなら、10倍用意して足りるなら御の字と思って。
0829NAME IS NULL
2014/12/05(金) 00:16:55.98ID:???>>828 そっか。50万円ぐらいは欲しいんだね。全然いいよ。
0830NAME IS NULL
2014/12/05(金) 00:25:52.49ID:???0831NAME IS NULL
2014/12/05(金) 00:36:29.01ID:???0832NAME IS NULL
2014/12/05(金) 22:09:27.55ID:???これほとんどが自演なんだぜ？
0833NAME IS NULL
2014/12/05(金) 22:55:49.46ID:???0834NAME IS NULL
2014/12/22(月) 21:22:44.32ID:???うちの職場ではRDB以外受け入れてもらえないんだけど
0835NAME IS NULL
2014/12/23(火) 23:04:24.71ID:???0836NAME IS NULL
2014/12/23(火) 23:13:01.96ID:wIV9jy1z0837NAME IS NULL
2014/12/23(火) 23:17:15.11ID:???0838NAME IS NULL
2014/12/23(火) 23:18:23.47ID:???意味がいまいち分からないな。
0839あ
2014/12/25(木) 19:35:28.04ID:???/:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::://ヽ:::::::::::::::|
l:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::// ヽ::::::::::::::l
l:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::/:::「'ヽ:::::::::::// ヽ:::::::::::|
|::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ﾉl:::ﾉ l:::::::／ ヽ::::::::|
ﾉ:::::::::::::::::::::::::::::::::::::::::::::::::::::／ ﾞﾞ ﾉ:::/ ,,;;;;;;,, ,,,,ヽ:::::l
）:::::::::::::::::::::::::::::::::::::::::::::::／ ノ／ ＿＿,'''i: ('''＿_）:::l
）::::::::::::::::::::::::::::::::::::::::::::::::::/ ￣￣ン:. :「￣`ヾ
1:::::::::::::::::::::::「 ｀┤l:::::::::::::::::l ￣ , ヽ￣ l
｀l:::::::::::::::::::::ヽ :l li:::::::::::::/ ヽ /´ ｀l |
ヽ::::::::::::::::::::::＼_」 lヽ::::／ .l !:-●,__ ノ /
ノ:::::::::::::::::::::::::::ﾉ | l ｀ﾞﾞ i ,,;;;;;;;;;;;;;;;;;;;;, /ヽ
,／ ヽ::::::::::::::::::::::（ l l::::::::.. /.:''／´￣＿ｿ / ｀ヽ
ヽ:::::::::::::::ヽ | l:::::::::::... /::/／￣￣_ソ / ＼ ヴッ！！
ヽ:::::::＼| l::::::::::::::::... / :::.ゝ｀￣￣／ ／ ヽ
ヽ:::l l:::::::::::::::::::.. ￣￣;;'' ／ ヽ
l l;;;;;;:::::::::::::::.....;;;;............;;;;;;''ノ l
l l ''''''''''''''''''''''''''''''''''''''￣l | |
http://www.youtube.com/watch?v=z2qK2lhk9O0
0840NAME IS NULL
2014/12/26(金) 01:11:09.38ID:???作るって何？コードから？
使った、のtypoかな？
mysqlとredis併用でがんがん稼働中ですよ
NoSQL系はRDBがマッチしないケースに適用するものであって、受け入れられないってのは単に説明が足りないとかそもそも不要なんじゃない？
うちでの適用例だと、スマホゲーで永続化不要なリアルタイムPVPでredis使ってる
数分の間だけ桁違いなアクセスがあって、結果格納後はゆるゆると破棄される、みたいな奴です
RDBでもインメモリでチューンすりゃやれんことはないのかもしれないすけど、逆に言えば無理してRDBで実装する理由が無かった。正規化もjoinもいらないし、ただ淡々と行動ログを取って状況を配信し続けるだけなんで。
こんなんnodeあたりでアプリ側インメモリでも良いケースでもあるけど
0841NAME IS NULL
2014/12/31(水) 14:13:36.57ID:0K4PB+LJ個々の受払のデータを持ってなくて、その都度商品マスタと1対1のテーブルに在庫数値を更新する、って方針はあまりないよね。
0842NAME IS NULL
2014/12/31(水) 17:22:31.20ID:???最新在庫問い合わせのレスポンスの問題で
ただ、その場合も受払の明細データはどっかに持ってる
0843NAME IS NULL
2014/12/31(水) 19:48:16.77ID:???計算面倒くさい
0844NAME IS NULL
2015/01/01(木) 00:44:16.68ID:???>>843
レスどもです。
確かに、毎回アクセスするたびにsumするのは負担がかかるから、更新時にsumして保存するのがよさそうですね。
今やってるシステムは、受け払いの履歴をもってないんだよな。。。。
0845NAME IS NULL
2015/01/01(木) 00:45:59.06ID:???内容を正しく表すことと、他のテーブル名との一貫性をきれいに保たせようとすると、どうも長くなってしまいがちなんだが
0846NAME IS NULL
2015/01/01(木) 03:05:53.17ID:rJHa5+se0847NAME IS NULL
2015/01/01(木) 12:03:49.22ID:???ERDの論理名は冗長やけどね
新しいプロジェクトだと短縮名英字テーブルに全部冗長な日本語名のビュー被せてる形式
その際は文字長の制限無し
0848NAME IS NULL
2015/01/01(木) 12:37:40.19ID:MgTOS1zHなるほどです。
0849NAME IS NULL
2015/01/01(木) 12:49:25.02ID:???文字数制限厳しい糞DBMSならそこに納めないといかんが、
そうじゃないなら好きにしろ。
プログラムコードの識別子と同じで無理に省略はしなくていい。
0850NAME IS NULL
2015/01/04(日) 09:27:34.18ID:???0851NAME IS NULL
2015/01/04(日) 13:44:21.19ID:???0852NAME IS NULL
2015/01/05(月) 00:54:38.64ID:mqBMdeHjでも一度は記述しないといけないわけで
0853NAME IS NULL
2015/01/05(月) 07:33:16.86ID:???読みやすさの話なんだけど...
0854NAME IS NULL
2015/01/05(月) 14:07:10.94ID:???単にスコープの問題。業界にいるならそれくらい理解できないとやばくね。
0855NAME IS NULL
2015/01/05(月) 14:23:48.27ID:???0856NAME IS NULL
2015/01/05(月) 14:55:22.09ID:???0857NAME IS NULL
2015/01/05(月) 15:14:25.22ID:???ほっとくとすごいことになるんだぞｗ
0858NAME IS NULL
2015/01/05(月) 15:37:23.57ID:???そういう人は芸術家になればいいと思う
0859NAME IS NULL
2015/01/05(月) 23:35:32.74ID:???全然ならん
プレフィックス付けたい病だが…
0860NAME IS NULL
2015/01/09(金) 00:04:59.68ID:???RAC組んでてDBは冗長化されてて、添付ファイル用に冗長化したファイルサーバ立てるのもアホらしいし
どんなに大きくファイルサイズを見積もっても 1年で1GB程度しかファイルが添付されないから無難な方法かなーと思ったり。
0861NAME IS NULL
2015/01/09(金) 08:06:54.40ID:???流行りかどうかは知らんけど、普通にやられてるでしょ
バックアップとかもその方が楽だし
0862NAME IS NULL
2015/01/09(金) 10:57:55.61ID:???普段から個別に使いたいならやらないが、一元化って意味ではありやろ
0863NAME IS NULL
2015/01/25(日) 10:15:05.33ID:CkJSYlpG自分は求人サイト（リクナビとか）向けの設計を作る事になったのですが、
それで気になることがあるので、質問です。
大体どの求人サイトも会員登録→履歴書作成→求人応募
という仕組みだと思うのですが、求人応募の際に履歴書の内容を
応募した求人毎に保存するべきなのか否か悩みます。
考え方として、
必要）その都度、履歴書の内容は変わるので、応募毎に保存するべき。
不要）履歴書として登録してるテーブルを、応募後に参照させればいいだけ。
正規化の考えから、同じ値を何度も登録させるのはおかしいと思いつつ、
応募時期によって履歴書の内容は変わったり職歴が追加されたりするので、
応募時点の情報を閲覧出来た方が企業としては良いのかな？と思ったりします。
なにぶん、自分は就活前なのでそういった求職者・雇用者の利用方法が想定できません。。
なので、どう設計したらいいか悩むところです。
求人サイトを設計した事がある方がいましたら、アドバイスください。お願いします。
0864NAME IS NULL
2015/01/25(日) 10:55:14.86ID:???一つのテーブルでなんでもやろうとするのが間違いの始まり
0865NAME IS NULL
2015/01/25(日) 12:31:40.86ID:???分けた方がいいですね
理由としては常に同じ値になる訳では無いから
※「応募時期の～」の考え方でOK
ただし、履歴書の変更修正も残したいなら下みたいな感じのが良いかと
※応募の有無に関係無く履歴を残したいとか
会員テーブル(会員ID
求人会社テーブル(会社ID
履歴書テーブル(会員ID,履歴書No
応募履歴テーブル(応募時期,会社ID,会員ID,履歴書No
履歴書の変更修正が不要なら履歴書Noが無くなり
応募の度に応募履歴テーブルへ履歴書の内容を記録
正規化は経験者でも悩ましいところですが、まず細かい仕様(どのデータをどう利用する)を確定していく事ですね
0866863
2015/01/25(日) 17:06:48.43ID:CkJSYlpGかなり詳しく教えていただきありがとうございます！
自分の中で
「応募の度に応募履歴テーブルへ履歴書の内容を記録」
というのが凄く違和感を感じていたんです。
求人サイトでは履歴書とか職務経歴書とかスキルシート？とかあるのに、
1企業に応募する度に複数テーブルに追加していくのは冗長すぎないか？と。
でも、おっしゃるように常に同じ値になるわけではないし、
1企業が1応募者の人生（履歴）をずっと見られるのも、おかしいですからね。
応募時期によって履歴書の内容が変わる、
それを保存するという考え方で問題ないのかもしれません。
テーブルや登録値を減らすことばかり考えていましたが、
それが良いとは限らないんですね。大変参考になりました！
0867NAME IS NULL
2015/01/25(日) 20:43:07.22ID:???テーブル設計以前の要求定義の話だな
>正規化の考えから、同じ値を何度も登録させるのはおかしいと
たとえば提出先毎に内容を保存できるって要件なら
複数に提出した内容がまったく同じだったら
(内部的に識別できるコード類は違うだろうが)
同じデータが複数あってもそれは正規化されてない事にはならん
0868NAME IS NULL
2015/01/25(日) 21:36:08.57ID:???DB移行計画書はどんくらいのボリュームが適正かしら？
ちな、250人程度の中小企業で、データ数は20万くらい。
やっぱ端折らずに全部計画書に落とすべきかなぁ・・・
0869NAME IS NULL
2015/01/25(日) 23:23:10.77ID:???ごめんなさい。
0870NAME IS NULL
2015/02/05(木) 15:45:04.43ID:???履歴付きマスターテーブル群を、
性能を落とさずに扱う方法はないでしょうか？
ある期間断面を切りとって、
トランザクションデータとJOINして、
断面単位で集計できるような構造。
0871NAME IS NULL
2015/02/05(木) 18:04:25.11ID:???ほんとに性能落ちてるのか？
落ちてると思い込んでるだけじゃないのか？
0872NAME IS NULL
2015/02/05(木) 18:30:34.45ID:???0873NAME IS NULL
2015/02/05(木) 18:43:31.22ID:???0874NAME IS NULL
2015/02/05(木) 19:36:31.64ID:???0875NAME IS NULL
2015/02/06(金) 10:25:52.87ID:???0876NAME IS NULL
2015/02/06(金) 10:36:30.05ID:???0877NAME IS NULL
2015/02/06(金) 21:57:54.20ID:???Follow(follower int unsigned references User(userid),
followee int unsigned references User(userid));
って設計ダメなんですか？
0878NAME IS NULL
2015/02/07(土) 00:15:25.79ID:???0879NAME IS NULL
2015/02/07(土) 00:45:48.73ID:???0880NAME IS NULL
2015/02/07(土) 11:26:46.85ID:???履歴は量が多いなら別テーブルにすれば？
出なければ日付index
0881NAME IS NULL
2015/02/07(土) 18:46:41.23ID:???官公庁見たく５年で廃棄だと５年分のテーブルがずらりと並ぶ事に鳴る
週単位で作っても３５０テーブルとkｗｗｗ
0882NAME IS NULL
2015/02/08(日) 00:41:13.61ID:???MySQLで週別、日別なログを回してて7万テーブルほどあるけど別に問題ないです
あえて言えばphpMyAdminが挙動おかしくなったので封じたけど
0883NAME IS NULL
2015/02/08(日) 01:38:22.61ID:???0884NAME IS NULL
2015/02/08(日) 02:44:08.15ID:???0885NAME IS NULL
2015/02/08(日) 12:21:58.11ID:???マスターと履歴マスター
履歴もアクセスする事があるなら、履歴には最新も入れときゃいい。
0886NAME IS NULL
2015/02/08(日) 15:00:50.25ID:???7万テーブルのunionとか想像だにできん
0887NAME IS NULL
2015/02/08(日) 16:24:21.22ID:???日別のテーブルを作らざるを得ないほどのデータ量ってストレージも大変なことになってそう
0888NAME IS NULL
2015/02/08(日) 16:26:37.66ID:???普通にindex張ってもダメなら、もうデータ分けちゃえ
0889NAME IS NULL
2015/02/08(日) 19:35:47.21ID:???0890NAME IS NULL
2015/02/08(日) 21:58:31.67ID:???0891NAME IS NULL
2015/02/09(月) 15:27:52.70ID:???0892NAME IS NULL
2015/02/09(月) 16:02:03.09ID:???0893NAME IS NULL
2015/02/09(月) 20:02:55.48ID:???特にどこがという事は無いけど
0894NAME IS NULL
2015/02/09(月) 21:05:23.78ID:???0895NAME IS NULL
2015/02/10(火) 02:58:10.51ID:???俺のことだ
パーティショニングさんほんとすまん
なんか1日で成果出せなければ死ねとか言われたんだ
実際には三日かかって成果出せなかった
それでも私は元気です
日跨りの検索案件も、毎日数件程度ながらあります
ダンプしたのをvirtualboxに移してから回してます
今まだ回してます
0896NAME IS NULL
2015/02/10(火) 03:45:01.36ID:???0897NAME IS NULL
2015/02/10(火) 06:02:53.64ID:???実機で負荷テストはダメやろw
日付跨いでパーティショニングされるとしたら夜中だろうし
0898NAME IS NULL
2015/02/10(火) 10:33:13.03ID:???ほとんどはこれだよな
0899NAME IS NULL
2015/02/10(火) 13:01:58.60ID:???そして、それらの最大連続true回数を調べたいのですが、sqlで取ってくることは可能ですか？
連続数をデータベースに登録しておくべきでしょうか？
0900NAME IS NULL
2015/02/10(火) 16:11:29.46ID:???サブクエリを工夫してもできるし、ストアドファンクションが使えるDBMSならそっちでもできるはず
連続数の登録はレコード更新の競合とか面倒臭そうだから勧めない
0901NAME IS NULL
2015/02/10(火) 18:38:50.77ID:???ありがとうございます。
野球の打撃成績の管理を頼まれまして、
クエリでなんとか拾ってみます
0902NAME IS NULL
2015/02/10(火) 19:02:59.15ID:???0903NAME IS NULL
2015/02/10(火) 19:07:57.03ID:???「そのレコードより前かつ1番近いfalseのレコード」
以降からそのレコードまでのレコード数を集計すればいいと思う
最大数を求めたいなら、その結果レコードを更に集計
最初や最後のレコードがtrueの場合も集計できるよう工夫して
0904NAME IS NULL
2015/02/10(火) 19:56:15.24ID:???引き出しに入れておこう。
https://yone64.wordpress.com/2013/07/04/
0905NAME IS NULL
2015/02/13(金) 02:25:06.50ID:???パフォーマンスが出ないためにテーブル分けまくってたのを思い出したわｗ
0906NAME IS NULL
2015/02/13(金) 23:43:22.23ID:iHKHG1ypその場合の設計を考えたのですが、
「管理者ID、会員ID、タイトル、内容、送信日」
というのは変ではないでしょうか？
というのも会員がメッセージを投稿した場合、管理者IDはNULLになります。逆もしかりです。
かと言って管理者・会員のIDが分かれているので、こうするしかない気がします。
どうするのがシンプルでオーソドックスでしょうか？
0907NAME IS NULL
2015/02/14(土) 00:46:17.44ID:???0908NAME IS NULL
2015/02/14(土) 01:56:45.93ID:???管理者＝会員ID０とかにすれば要らないような
0909NAME IS NULL
2015/02/14(土) 02:29:27.88ID:???0910NAME IS NULL
2015/02/14(土) 02:35:48.88ID:???普通はこうやる
メッセージテーブル
送信日、メッセージNo、送信者ID、受信者ID、タイトル、内容
利用者テーブル
利用者ID、利用者情報…
0911NAME IS NULL
2015/02/14(土) 03:21:24.37ID:???メッセージID、親メッセージID、利用者ID、タイトル、内容、送信日
1 null user_1 質問です 困ってます 2015/2/1
2 1 admin_1 そうですか 大変ですね 2015/2/1
3 2 user_1 うわあん もうこねえよ 2015/2/2
という感じでツリー表示したいわけではないのかな。
0912NAME IS NULL
2015/02/14(土) 07:04:15.19ID:???まず関係するテーブルの定義は簡単にでも一通り挙げるべき
具体的には管理者テーブル・利用者テーブルの定義が足りない
あと、DBMSとバージョンも書けば各DBMS固有の解決法もあるかもしれない
今回は管理者/利用者テーブルの定義に関してはこっちで予想した上で、特にDBMSに依存しない回答を書くと
メッセージテーブルと管理者/利用者テーブルの間に、メッセージ投稿者テーブルを噛ませたら良さそう
メッセージテーブル
{投稿番号(PK),投稿者ID(FK),タイトル,その他メッセージ情報…}
メッセージ投稿者テーブル
{投稿者ID(PK),ハンドル(ネーム),その他投稿設定…}
管理者テーブル
{管理者ID(PK),投稿者ID(FK),その他管理者情報…}
利用者テーブル
{利用者ID(PK),投稿者ID(FK),その他利用者情報…}
0913NAME IS NULL
2015/02/14(土) 09:36:32.23ID:???0914NAME IS NULL
2015/02/14(土) 09:50:17.00ID:???> 管理者・会員のIDが分かれている
これが必須要件ならそのままが一番シンプルだと思う
ここを変えていいなら他の人が言ってるように管理者と会員を一つのテーブルにして、フィールドに管理者か会員の区別をつければいい
ちょっと気になったのは
> 管理者と会員のやりとり
って一つでいいの？
2ちゃんのスレッドみたいな概念は要らないの？
0915NAME IS NULL
2015/02/14(土) 09:59:40.79ID:???ただもし、管理者テーブルや会員テーブルが既に別システムで定義されている場合、
投稿者テーブルで集約することはできなくなる。
その場合、投稿者ビューとして集約し、管理者ID＋α、会員ID＋αで一意化する必要がある
αの部分として、
投稿者として別の情報を付与するなら投稿者テーブルを作り投稿者IDを使う。
管理者、会員と投稿者の関係はそれぞれ交差テーブルを作る。
もしくは単純に区分値を与える。
0916NAME IS NULL
2015/02/14(土) 10:10:35.21ID:???「既に管理者テーブルと会員テーブルがあるのなら、そこに投稿者IDつければいいじゃん」という考える人がいるかもしれない。
コンテキストの規模によるため一概に言えないが、「One fact in one place」の原則から、会員管理と投稿管理は別コンテキストとかんがえ別テーブルとした方が、後々の機能拡張にも手を出しやすくなると思う。
0917906
2015/02/14(土) 10:46:33.77ID:K+3vnnrF理解できそうな部分だけ掻い摘んで返信します。
＞管理者と会員の区別って必要なのか
必要です。設計が違います。
管理者テーブルは単純に「管理者ID、表示名、ログイン名、パスワード、権限」ぐらいですが、
会員テーブルは「名前、性別、生年月日、住所」などのプロフィールが入っています。
なぜプロフィールと会員情報を1本化したかというと、1対1の関係であり、
正規化するほどでもないので、1つのテーブルにまとめてます。
（これは過去にこのスレでアドバイス頂いた設計でもあります）
>>911
基本的にはそのような単純な表示を想定しています。
>>912
かなり詳しくありがとうございます。ただ、PKとかFKとかの意味が理解できないので、この後勉強します。
>>914
スレッドみたいな概念は考えていません。単純な連絡用ですので。
レス頂いた分を見ると、皆さんが引っかかっているのは
「会員テーブルと管理者テーブルが別の意味がわからない」だと思います。
上記の通り、別のテーブルとして定義しているため、「投稿者ID」とするのではなく、
別カラムとして用意する案を考え、>>906となりました。説明不足ですみません。
0918906
2015/02/14(土) 11:04:16.03ID:K+3vnnrF「管理者と会員でテーブルが分かれてるから、新たに投稿用の会員テーブル？を作る」
として、”投稿者テーブル”とする意図も分かりました。
そういう考えをした事がなかったので、新たな発見です。
ただ、>>916さんが言うように既存のテーブルに新たに投稿者IDを追加するというのは
どうなのか？と思うので、それなら単純に管理者ID・会員IDを使った方が良い気もします。
色んなやり方・考え方があり難しいですが、もう少し勉強します。
0919NAME IS NULL
2015/02/14(土) 14:22:07.79ID:???0920NAME IS NULL
2015/02/14(土) 15:23:59.21ID:???まあまあ、最初はみんな初心者ですから
0922NAME IS NULL
2015/02/15(日) 21:28:37.18ID:RML1uFu9イメージとしてはヤオフクです。出品とか落札手数料とかオプション使用で課金されて、月末に支払うみたいな。
その場合のテーブル設計として
◯課金テーブル
課金ID｜請求ID｜ユーザーID｜内容｜金額｜課金日
◯請求テーブル
請求ID｜ユーザーID｜金額｜請求日
◯支払いテーブル
支払いID｜ユーザーID｜請求ID｜支払い方法｜支払日
といった設計でおかしくないですかね？支払いテーブルと請求テーブルを一緒でも良い気はしますが。
0923NAME IS NULL
2015/02/15(日) 23:20:38.55ID:???請求と支払いの関係が1対1なら1テーブルに纏めるのがいいね
で、課金テーブルを分けないとダメな気がするが
オプションA、B、C等の課金料設定テーブルとユーザーが実際に利用したオプションの課金利用テーブル
課金設定テーブルのPKは課金ID
課金ID、オプション名、金額、備考
課金サービス利用テーブルのPKは請求ID
請求ID、課金ID、金額(金額変わる可能性があるからここでも持つ)
0924922
2015/02/16(月) 00:27:09.16ID:???返信ありがとうございます。
「課金サービス利用テーブル」が中間テーブルのようなイメージですが、
一度課金したのに金額が変わる可能性って無いと思います。
んでも、請求IDがPKってのはどうなんでしょ？違うような気も・・。
とりあえず、まとめると以下の感じだと収まりが良いですかね？
◯サービステーブル
サービスID｜サービス名｜金額
◯課金テーブル
課金ID｜サービスID｜ユーザーID｜金額｜課金日
◯請求テーブル
請求ID｜ユーザーID｜金額｜請求日｜支払い方法｜支払日
◯課金サービス利用テーブル
請求ID｜課金ID
Aさん（ID5）が「サービス名：出品（ID3｜500円）」を利用したら、
課金テーブルに「1｜3｜5｜500｜2015/02/16」が入って、翌月の請求時に
課金サービス利用テーブルには「1｜1」が入り、
請求テーブルには「1｜5｜500｜2015/03/01｜銀行振込｜NULL」が入ると。
うーん、この考え方で良いのかなぁ
0925NAME IS NULL
2015/02/16(月) 05:03:23.35ID:???請求と課金が1:nなら、課金テーブルに請求ID持ったほうが
請求締め処理やるときに楽だぞ
請求テーブルにユーザーIDと金額が必要かどうかは良く検討した方がいいぞ
複数のテーブルに「金額」っていう同一の項目名つけるのもやめた方が良い
0926922
2015/02/16(月) 09:16:11.73ID:???ありがとうございます。中間テーブルも必要ない気がしますので、
以下のようにまとめることにしました。
◯サービステーブル
サービスID｜サービス名｜料金
◯課金テーブル
課金ID｜請求ID｜サービスID｜ユーザーID｜金額｜課金日
◯請求テーブル
請求ID｜ユーザーID｜小計｜消費税｜請求日｜支払い方法｜支払日
0927NAME IS NULL
2015/02/16(月) 10:17:37.96ID:???0928NAME IS NULL
2015/02/16(月) 12:07:55.28ID:???だから、その課金と請求って 1:1 なの？
1:1 なら課金と請求を一つにまとめるべきで、テーブル名も 利用テーブル とか、取引テーブル とかにした方がいいと思う
俺なら
◯取引テーブル
取引ID｜サービスID｜ユーザーID｜課金金額｜課金日 | 請求金額 | 請求日 | 支払い方法 | 支払日 |
にするかな
常にサービステーブルの金額が課金金額と請求金額になるなら、課金金額と請求金額は不要
（変わる例としては、特定ユーザーのみ割り引くとか、キャンペーン中なので請求金額のみ割り引くとか
あと途中で値上げ/値下げした時に、その切り替わりの処理を考慮する必要がある（サービステーブルそのまま書き換えると、課金した時と請求する時で金額が違うとかなるから））
> Aさん（ID5）が「サービス名：出品（ID3｜500円）」を利用したら、
1｜3｜5｜500｜2015/02/16 | 500 | Null | Null | Null |
> 翌月の請求時に
1｜3｜5｜500｜2015/02/16 | 500 | 2015/03/01 | 銀行振込 | Null |
0929NAME IS NULL
2015/02/16(月) 13:09:37.15ID:???複数の課金をまとめて請求って形。
0930NAME IS NULL
2015/02/16(月) 13:31:29.39ID:???>イメージとしてはヤオフクです。出品とか落札手数料とかオプション使用で課金されて、月末に支払うみたいな。
と書かれてるな。
0931NAME IS NULL
2015/02/16(月) 16:17:14.99ID:???> 請求と支払いの関係が1対1なら1テーブルに纏めるのがいいね
というレスした人ががんばってるのが現状だよね。
0932NAME IS NULL
2015/02/16(月) 17:00:58.29ID:???> 1:1 なら課金と請求を一つにまとめるべきで、
たとえ1:1でも、そうすべきなんてちっとも思わないけど。
0933NAME IS NULL
2015/02/16(月) 18:09:50.26ID:???理由は？
0934NAME IS NULL
2015/02/16(月) 18:43:44.78ID:???> 理由は？
自分は一つにまとめるべき理由は語らないのに、人には聞くの？
逆に聞くけど、これコード書くとき、課金クラスとか請求クラスとか支払いクラスとか一切無しに、
全部入りの取引クラスとか作っちゃうの？
0935NAME IS NULL
2015/02/16(月) 19:24:05.28ID:???普通に分ける選択肢と分けない選択しがあって理由がないのに分けるの？
あと、レコードのフィールドと操作クラスになんの関係があるんだ？
0936NAME IS NULL
2015/02/16(月) 19:58:25.61ID:???0937NAME IS NULL
2015/02/16(月) 20:24:19.45ID:???別の話に切り替えたいならそれでもいいけど
0938NAME IS NULL
2015/02/16(月) 20:25:55.92ID:???クラスがどうのこうのの事を言ってるの？
全然理由になってないと思うけど
0939NAME IS NULL
2015/02/16(月) 21:07:53.45ID:???0940NAME IS NULL
2015/02/16(月) 22:18:10.95ID:???なっちゃうんだよな。トリガなんかで保証しない限り。
0941NAME IS NULL
2015/02/16(月) 22:24:59.89ID:???ひょっとしてビューも知りませんとか？
0942NAME IS NULL
2015/02/17(火) 00:41:14.37ID:???今帰宅…違う人っす(^◇^;)
他の人が書いてるけど理由無くどんどん分けるのは良くないでしょ
あと、>>934の人はちょっと意味不明ですね
0943NAME IS NULL
2015/02/17(火) 01:22:05.72ID:???どうして1対1を検証しようとするのかが分からん。
0944NAME IS NULL
2015/02/17(火) 01:24:12.19ID:???0945NAME IS NULL
2015/02/17(火) 02:33:50.71ID:???先にドリンクばーだけ頼んどいて後から料理で注文取り消しの処理が入る事に鳴るけどな
もちろん取り消し確認しなきゃ成らないから速度がた落ちｗ
最後はオンメモリオラクルで力技で逃げ切ったけど後シラネｗ
0946NAME IS NULL
2015/02/17(火) 03:43:33.04ID:???安価ミスだと信じてるんだけど、大真面目な可能性を捨てきれないこのスレがちょっといやだ
0947NAME IS NULL
2015/02/17(火) 05:00:50.34ID:???なにか言いたいことがあるならちゃんと書けばいいのでは？
0948NAME IS NULL
2015/02/17(火) 05:17:02.86ID:???請求と課金は1対多だけど、請求と支払いは質問者も言ってる様に1対1だろ
0949NAME IS NULL
2015/02/17(火) 05:38:14.66ID:???技術板ってどこもそんなもんだろ
覚えたてで口出したいだけ
0950NAME IS NULL
2015/02/17(火) 06:34:46.46ID:???請求をした時点では支払いがないから、もちろん1:0..1だなぁ。
0951NAME IS NULL
2015/02/17(火) 06:38:43.83ID:???>>939は>>938あてだよ
0952NAME IS NULL
2015/02/17(火) 07:05:03.53ID:???請求と支払いは俺にとっては別の概念だから
俺なら1:1だろうが別テーブルにするがな
システム的な理由なら
更新時のロック範囲とか検索時のパフォーマンスとか
請求と支払いが同一の概念だと思うなら一つにすれば良いんじゃない
請求〆処理や入金処理でロック待ち多発する可能性はあるけど
0953NAME IS NULL
2015/02/17(火) 10:04:12.24ID:???それを1つのテーブルでやってたら無駄だわ。
だから請求は請求テーブル、支払いは支払いテーブルにまとめるという概念で
あとはサイトの規模・更新頻度や要件などを考えみて、どう設計するかだろ。
0954934
2015/02/17(火) 10:14:17.52ID:???> あと、>>934の人はちょっと意味不明ですね
>>934の後半は、アプリケーション側のドメインモデルを抽出するとき、あるいは、ビジネスロジックモデルを
抽出するときに、課金・請求・支払いを分けたいと思う動機があるとすれば、それはリレーションモデルの
エンティティ抽出にも言えませんか、っていう流れにしたかったのね。
>>940
> データモデルの観点から言えば、1:1の関係を別テーブルに分けたら1:0..1か0..1:0..1に
> なっちゃうんだよな。
俺がまとめるべきとは思わない理由の一つもそれ。
先にまとめるべきだと思う理由を聞きたかったから、それは言わなかった。話がまぎれる可能性があるし。
課金・請求・支払いに限らず、時系列で発生するものは、1:1ではなくて1:0..1になる。
そのとき、テーブルが一つだとNULLの嵐になるというのがどうかという問題だね。
NULL撲滅委員会みたいな原理主義者なら、それは絶対にNoだと言うかも。
0955934
2015/02/17(火) 10:18:44.37ID:???> 請求と支払いは俺にとっては別の概念だから
それが分ける派の素朴な理由だと思う。
そう思う派にとっては、今回のケースは「分割する話」ではなくて「合成する話」となる。
合成すべき派がいるなら、なぜそう思うのか理由が知りたいんだよなぁ。
0956NAME IS NULL
2015/02/17(火) 10:42:54.63ID:???使用するDBは、SQL Serverです。
とある機器から1分毎にデータを収集しています。
フィールドは次のようになっています。
-----
日時
メーター1
メーター2
・
・
・
メーター100
-----
これを日毎に集計し、1つのメータに対して
平均値、最大値、最小値を求め、1レコードにし別テーブルに格納したいです。
このとき、
・300フィールドを用意したテーブルに格納するか
・メータ別にテーブルを作成するか
どちらのほうが良いのでしょうか？
0957NAME IS NULL
2015/02/17(火) 10:47:01.71ID:???メーター数に増減があった時に、どうなるかを考えてみよう
0958NAME IS NULL
2015/02/17(火) 10:56:12.94ID:???そこまで考えが及びませんでした、
フィールドを増減させるのは大変ですね。
メータ別にテーブルを用意します。
ありがとうございます。
0959NAME IS NULL
2015/02/17(火) 11:16:36.90ID:???増減の都度、その後のSQLソースを修正するつもりなのか？
0960NAME IS NULL
2015/02/17(火) 11:24:54.67ID:???集計データ: {日時, 平均値, 最大値, 最小値}
がいいんじゃないかな。
0961956
2015/02/17(火) 11:54:12.84ID:???どちらにしても、フィールド数もテーブル数も多くなるなとは思いました。
集計テーブルに、メータを10個ｘ10テーブル分とも考えましたが
中途半端になるような気がしたので、どちらかにする。と決定し、
質問させてもらいました。
メータが増減するとなった場合、機器の取り外しや据え付けも必要だし
頻繁には行わないので、その都度SQLを修正します。
>>960
測定データは、どうしても[日時、メータ1～」のテーブルに格納します。
というか、収集ソフトの仕様でされてしまいます。
0962NAME IS NULL
2015/02/17(火) 11:56:27.17ID:???それはViewで対応したら？
0963NAME IS NULL
2015/02/17(火) 19:14:05.67ID:???データの横持ちは、破滅を招くよ。なるべく避けるのが吉。
横持ちが何かわからなかったらググるべし。
> というか、収集ソフトの仕様でされてしまいます。
データ収集ソフトがデータベースに登録するってこと？
0964NAME IS NULL
2015/02/17(火) 19:22:45.64ID:???それくらい読み取ろうよ
0965NAME IS NULL
2015/02/17(火) 19:26:15.62ID:???縦持ちにしておけば他の何かしたいときにも便利でよい。
0966NAME IS NULL
2015/02/17(火) 20:13:50.24ID:???> 請求と支払いは俺にとっては別の概念だから
> 俺なら1:1だろうが別テーブルにするがな
まじでこんな考えの奴がいるのか
スゲーな
> 請求〆処理や入金処理でロック待ち多発する可能性はあるけど
どんだけ大規模なシステム想定してるんだよ
> 952が正しいわ。請求がキャンセルされる可能性もあるし、支払予定が変わる可能性もある。
そういう履歴も持ちたいと言うなら既に要件が変わってる
普通はキャンセルフラグ、予定日の更新等で対応
0967NAME IS NULL
2015/02/17(火) 20:17:09.62ID:???規模によるけどビューの方がいい
0968NAME IS NULL
2015/02/17(火) 20:18:35.66ID:???で？
いちいち面倒だから言いたいことあるなら書けよ
0969NAME IS NULL
2015/02/17(火) 21:41:50.68ID:???それはインデックス付きビューが実装されているRDBMS限定の話？それとも全般で？
0970NAME IS NULL
2015/02/17(火) 21:49:59.55ID:???0971NAME IS NULL
2015/02/17(火) 21:57:22.24ID:???0972NAME IS NULL
2015/02/17(火) 23:01:20.33ID:???0973NAME IS NULL
2015/02/17(火) 23:19:24.98ID:???アホなこという奴いて困る
0974NAME IS NULL
2015/02/17(火) 23:25:12.03ID:???0975NAME IS NULL
2015/02/17(火) 23:38:42.60ID:???もうね、あんたみたいなのは宇宙的バカwww
0976NAME IS NULL
2015/02/17(火) 23:58:45.01ID:???否定された理由がわからないレスを挙げてくれ
0977NAME IS NULL
2015/02/18(水) 00:00:36.21ID:???板違い
0978NAME IS NULL
2015/02/18(水) 05:06:20.99ID:???⇒ 性能ガー
今時は六層ぐらいでも大丈夫
⇒ >>974 メンテナンスが大変そうだね
そりゃその頭なら、大変だと思うよ w
0979NAME IS NULL
2015/02/18(水) 09:29:32.17ID:???0980NAME IS NULL
2015/02/18(水) 10:06:50.92ID:???COBOLerなの？
0981NAME IS NULL
2015/02/18(水) 11:10:33.62ID:???なんでそんなこと思ったの？
0982NAME IS NULL
2015/02/18(水) 11:44:35.74ID:???0983NAME IS NULL
2015/02/18(水) 12:01:06.69ID:???0984NAME IS NULL
2015/02/18(水) 12:05:00.47ID:???普通の頭の人でも楽にメンテができるような設計を心がけてくださいね。
みんなが君のように頭が良いわけじゃないから。
引退できなくなるよ。
0985NAME IS NULL
2015/02/18(水) 12:28:28.64ID:???なんでこう言う奴っていちいち書かないと気がすまないんだろう？
ここが変だろボケ、ですむレスになんレス費やしてるんだよ
0986NAME IS NULL
2015/02/18(水) 12:30:05.30ID:???まさかと思うか六層のビューを使いまくってるとか思ってないよな？
>>973 見てそう思ってたら、単なるアホだぞ
0987NAME IS NULL
2015/02/18(水) 12:52:31.70ID:???なんでこう言う奴って、他人が無料で自分に駄目だししてくれるべきって考えてるんだろう
0988NAME IS NULL
2015/02/18(水) 12:55:35.25ID:???別に議論するつもりもないし、変なとこ指摘するつもりもないよ
ただ、そういう発想をする君はCOBOLerなの？って疑問がわいただけで
0989NAME IS NULL
2015/02/18(水) 13:16:29.66ID:???ちょっと確認したいんだけど、君>>928なの？
もしそうだとしたら、>922で
> サービスを利用したら課金が発生して、月末（または指定日）にまとめて請求するような仕様を考えています。
と言ってるのに、>>928で
> だから、その課金と請求って 1:1 なの？
と勘違い質問をし（明らかに多:1の話）、さらには
> 1:1 なら課金と請求を一つにまとめるべき
という主張をしてるよね。
勘違い質問をしたのはいいとしても、一つにまとめるべき理由があるなら教えてくれないかな。
普通は一つにまとめるべきだと思ってるから
>>966
> > 請求と支払いは俺にとっては別の概念だから
> > 俺なら1:1だろうが別テーブルにするがな
>
> まじでこんな考えの奴がいるのか
> スゲーな
みたいなこと言ってるんだよね？
0990NAME IS NULL
2015/02/18(水) 13:19:41.16ID:???>>923は別の人ですよね。
> 請求と支払いの関係が1対1なら1テーブルに纏めるのがいいね
「請求と支払いが1対1なら1テーブルに纏めるのがいい」という話と、
「課金と請求が1:1 なら課金と請求を一つにまとめるべき」という話が錯綜しててわかりづらい。
0991NAME IS NULL
2015/02/18(水) 13:21:46.72ID:???全部を一つにまとめるべきって考えてる人がいるってことでいいのかな？
0992NAME IS NULL
2015/02/18(水) 14:19:57.38ID:???課金と請求が1:0..1ってマジでいってんですか
0993NAME IS NULL
2015/02/18(水) 14:23:38.08ID:???ああなるほど、理由も説明できないのに他人にラベル貼りたがる人って事ですか
まあ、そういう人もいるんだろうな
0994NAME IS NULL
2015/02/18(水) 15:11:43.31ID:???0995NAME IS NULL
2015/02/18(水) 15:21:08.99ID:???慣用句としてはどうなんかね。
0996NAME IS NULL
2015/02/18(水) 17:55:59.85ID:???を支持する人っているの？
俺は多分支持しないかな。
0997NAME IS NULL
2015/02/18(水) 18:02:06.14ID:???0998NAME IS NULL
2015/02/18(水) 18:09:51.32ID:???http://peace.2ch.net/test/read.cgi/db/1424250550/
ごめーん、別板に誤爆してあせってsageteoff入れ忘れた
0999NAME IS NULL
2015/02/18(水) 18:30:29.76ID:???マジだけど、なんか間違ってる？
1000NAME IS NULL
2015/02/18(水) 18:32:35.98ID:???1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。