DB設計を語るスレ 7

語れ

前スレ
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/

関連スレ

何故データベース設計は軽視されるのか？
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/

>>1乙

>>1乙
Redmineのmembers禁止

数人のわからずやのためにどれだけレスが消費されたか分からんからな。
禁止でいいと思うわ。

Junction Tableって属性や関連もってもいいの？

これがずっと疑問でさ

>>6
それこそ狭義と広義かと

>>6
個人的には属性を持てると思う
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 歪みでしかない

>>8を訂正
X: 属性を持ってはいけない、あるいは持つべきであるとは書かれていない
O: 属性を持ってはいけない、あるいは持つべきではないとは書かれていない

前スレ>>995で以下の質問があったのでレスする
>> たまたまあるエンティティが２つの外部キーを持ち、
>>そのエンティティを介して２つのエンティティがm:n関係
>の具体例があったら上げて欲しい。「出版」みたいなわけわからん奴じゃなくて。

エンティティ顧客(customer)と製品(product)があり、第三の要素として受注(order)がある
order は、ある顧客からある製品を受注したという事象(event)を表現している
また属性として受注日付/受注個数等の受注に付随する属性、主キーとして受注番号、
そして外部キーとして顧客および製品への1:n関係を表現する顧客番号と製品コードを持つ

ここでERモデル設計上では、order は受注という事象を表現するエンティティである
なおかつ、結果としてorder を介し customer と product はm:n関係がある

>>8
だからサロゲートキーはつけてもいいって。
wikipediaに頼るんなら、書いてあることぐらい理解しようよ。

>>10
それはたまたまじゃない。持つべくして持ってるよね。

>>11
Associative Entity以外のどこに書いてある？

>>8
サロゲートキーを持ってはいけない、あるいは持つべきではないとは書かれていない

サロゲートキーを持てるかどうかじゃなくて
そのサロゲートキーが有用な場面は、って話だったはずなんだが
どんだけループしてんの

持ってはいけないから、有用な場面を検討する必要は無い
vs
持っていいけど、その構成だと意味が無いから不要

かなぁ。

・サロゲートキーは便利だから積極的に使おう（推奨派）
　　　　vs.
・サロゲートキーはそれが必要なケースに限って使うべき（制限派）

ではないかと思われ


自分は後者の制限派
たとえば>>10の例だと、企業間取引であれば多くは受注伝票上の受注番号が
自然キーになるからサロゲートキーは使うべきではないけど、
これが(オンラインショッピングのような)個人取引であれば
受注番号は人工キーをサロゲートキーにせざるをえない、と考える

そしてRailsは前者の推奨派であり、
(属性を持たないm:n関係を除く)あらゆるテーブルはサロゲートキー id を持つ

ここいらで、長く続くサロゲートキー論争の発端となった前スレ476のカキコをコピペしておく

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にサロゲートキーを持つ意味って何なんでしょう？
複合キーはバグの温床でそれを排除できる。 将来の変更に柔軟に対応できる。
といわれても意味が分からない。このケースにおいて複合キーにバグの温床となる要素があるんだろうか…？
今後のテーブル構造の変更に柔軟に対応できる要素があるんだろうか…？
いったいどんな変更を想定しているんだろうか…？

>>17
持つ意味は無い。
将来的に必要になったときに持てばいい。

>>16
> 受注番号は人工キーをサロゲートキーにせざるをえない
？？

>>11
>それはたまたまじゃない。持つべくして持ってるよね。

そうだよね

ではここまではいいとして、次に、ある顧客との間で成立した
特定製品の値引きに関する契約が要求仕様に追加されたと仮定する
この場合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 表現できない)ことが分かるのではないだろうか？

>>20
なんかまた話がずれたな。
で、自分でER図は書いてみた？
論理と物理

>>21
概念ERモデル図は>>20で書いてあるだろ
ここまで単純なモデルであれば、
よほどの初学者でも無い限り、誰でも論理ER図は書けるはず
それとも>>21は書けないのかな？
もし書けるというのなら、論理/物理設計を話題にしたい>>21が、
実際に書いてみればいいんジャマイカと思われ

それから、物理ERモデル設計は制約やインデックス等を定義するものだから、
(ER図としてではなく)表形式のテーブル設計書として書いているよ
それとも、普段>>21は物理ER図を書いているの？
わざわざ物理ER図を書くという発想がピンとこないなあ....
ひょっとして>>21は(業務経験の無い)学生さんかな？

何の話してんの？サロゲートキーなんてもうどうでもいいのかな。
連関エンティティはサロゲートキーを持ちうるかどうかから離れてってない？
どうせ長文書くなら結論まで頼む。

>>23
もともとは（概念設計レベルではなく）論理設計レベルの質問(>>17)なんだから、

X: associative entity はサロゲートキーを持ちうるかどうか
O: junction table はサロゲートキーを持ちうるかどうか

じゃねえの？

自演…

>>20
その2個のER図を比べている意味がわからない。内容もおかしいし

第一チェンが使ってたAssociative Entityがなんで別の概念なんだ？

>>10
前スレ>>995では一部省略したけど、

> ・たまたまあるエンティティが２つの外部キーを持ち、
> 　そのエンティティを介して２つのエンティティがm:n関係にあったとしても、
>　設計者がそのエンティティを連関エンティティであると宣言していなければ
>　(=設計者が意図していなければ/見落としていれば)、そのエンティティは連関エンティティではない

を受けて、「たまたまあるエンティティが二つの外部キーを持ち、なおかつ形態としては連関エンティティに
見えるが、設計者が意図していない、または、見落としているようなエンティティの例があったらあげてくれ」
という趣旨の質問。

で、>>10のorderは、連関エンティティと同じ形態であるためには、(customer_id, product_id)がユニークで
ある必要があるけど、そうなの？

うーん、その後の議論は全くもって意味不明だな。
何を主張したいのやら。

WikipediaのAssosiative Entityのページにあった図、あれって連関エンティティがrelationでもありentityでもある
といういみで、長方形と菱形を重ねただけかと思ったんだが違うのか？

連関エンティティも交差テーブルも、使用するFWの都合等でサロゲートキーを持っても良い、って前スレで結論出たんじゃないのか？

>>30
連関エンティティだけ

>>31
は？何で持っちゃ駄目なんだ？

>>7
この人も意味わからんわ

>>22
> わざわざ物理ER図を書くという発想がピンとこないなあ....

え？書くよ？
逆に、物理ER図を書かない現場を知らないわ。

Rails禁止。

>>32
結論出たのが連関エンティティだけ

>>33
Junction Tableで定義されてるのは、FKをまとめたPKのみ
これが狭義だろ
広義はしらね

Associative Entityは狭義も広義もなく
属性や関係を持ったりサロゲートキーを持つ話も定義されてる

たとえば男女関係のように、多対多につながってるものを
表現する手法を教えてください。 ホモとレズはいません。

AさんはB子とC子とつきあっている
DさんはC子とD子とE子とつきあっている
FさんはB子とC子とつきあっている
Gさんは誰ともつきあっていない（自慰だけに）

設計してるうちに似てきちゃったテーブルはひとつにまとめてますか？

>>38
m f
---
A B
A C
D C
D D
D E
F B
F C

>>40
このテーブルって、インデックスはどうやって張ればいい？
mとfでセットで春？

そう。ユニークになるでしょ。

インデックスはどうやって検索するかがメインだからなぁ
まあ、PKには普通インデックス張られるから、この場合ならm,fでPKにするだろうし
mから検索するならそのままでもいいけど、fから検索するんのが多ければ俺ならfか(f,m)のインデックス張るかもしれん

ユニークであると、複数列インデックスの後ろだけって使われないから
(f,m)でインデックス貼るな

ありがとう
mとfにそれぞれインデックス張りました

主キーについて教えて下さい。
ミック氏の書籍に「達人に学ぶDB設計 徹底指南書」には、
主キーに、"可変長文字列"を使用すべきでない。と書かれており、
コードやID（つまるところサロゲートキー？）を使うべきだとあります。

しかし、ネットで色々調べていると、サロゲートキーの使用は避け、
ナチュラルキー（これは可変長含む？）を使うべきだ。と言う解説も多くありました。

実際のところ、どのように両者を使い分ければ良いのでしょうか？
素人ながらに考えたのは、
ナチュラルキーが固定長文字列にできるのであれば、ナチュラルキー
それ以外はID（サロゲートキー）。なのかなと・・・。
経験者の方の意見をお聞きしたいです。

>>46
なぜ可変長文字列を使用すべきではないかの理由はかかれていなかったの？
データ構造の話に言及してそうな気はするんだけど。

後々カラムやテーブルを弄くる可能性があるなら
サロゲートキーで弄らないなら複合キーを使う
俺的にはそんなイメージ

コードやIDが全てサロゲートキーだと思ってるならまずそこが間違ってる

>>47
可変長にすると、"山田太郎"と"山田 太郎"が異なる値となるため、
たとえば外部キーで結合する場合に不一致が起こる・・・
可変長文字列が必要であるのなら変動する可能性が高い・・・
固定長と混合する可能性がある・・・
などと書かれていました。


>>49
現実世界を表す名称がナチュラルキーであるため、
それ単体でも意味を理解できるが、
サロゲートキーは単体では意味をなさない。
と、そのような理解をしています。
そういった意味では、ナンバリングの"1"もIDの"A001"も同じではないのでしょうか？

http://gihyo.jp/dev/serial/01/sql_academy2/000304
ミックって人が書いてる。
2008年時点で可変長の内容は書いてないな

> サロゲートキーは，基本的には不要なものです。〜省略〜
> しかし，以下のような業務要件の場合には，サロゲートキーを使うことを考えます。
> �@ そもそも入力データに主キーにできる項目がなく，データが重複している場合
> �A 主キーの値が使いまわされる場合
> �B 主キーの体系が変化する場合

ミックって人、訳の用語がぐちゃぐちゃで好きになれない
サロゲートキーを代理キーと訳されると、alternate keyはどうしたらいいのだ

>>50
システム側で独自に割り当て
システムでしか利用しない主キーをサロゲートキーと言うので

コードは外部で利用するために作ったものだと思うから
サロゲートキーではないよ

病院の待合室の機械で出てくる受付番号や
注文伝票で利用する商品コードとかな
"A001"はその類でしょ

ちゃんとした日本語しゃべれ。

ここ日本語厨おおいよな。

普通に理解できるやん。

>>51
サロゲートキーの訳語としての「代理キー」はメジャーだと思うけど。

例えばこことか。
ナチュラルキーとサロゲートキーについての議論
http://nippondanji.blogspot.jp/2013/12/blog-post_4.html

この人も嫌いなのか？

>>55
>>51の記事のURL出して話してるから
ミックって人の引用でしょ

>>56
> ミックって人の引用でしょ
わかってますが、それが何か？

>>55
訳語としては「代替キー」のがメジャーだと思う

普段はそのまま「サロゲートキー」を使うから訳語を使わないんだけどさ

>>58
疲れる。
どっちがメジャーかなんて話はしてないんだけど。

マジでどうでもいいわ

>>59
支離滅裂だなぁ

そもそも、サロゲートの日本語訳が代理・代替なんだから、どっちでもいいだろ

>>62
代理キーって別にあるからよくない

>>61
何が言いたいんだか。

「訳の用語がぐちゃぐちゃ」の例として、「サロゲートキーを代理キーと訳される」って言ってるけど、
サロゲートキーを代理キーと訳すのも普通にあるということなんだけど。

どっちがよりメジャーかなんてどうでもいいわ。

>>63
じゃ、>>55のリンク先の人も駄目ってことか？

>>65
引用利用をとやかく言うって
>>55の先の人に恨みでもあるの？

>>66
意味が分からん。

>>55のリンク先の人も、サロゲートキーを代理キーと言ってるけど、それはどうなのって聞いてるんだが。

>>67
他ブログを引用して記事を書くとき
元ブログの文言をそのまま使うことは往々にしてあるので
どうも思わん

>>66
MySQL業界外では結構嫌われてるからね。

>>68
引用とかしてないけど？

>>70
わからないならいいよ
>>55の人、その記事以外では代理キーって書かないんだよ

元の話に戻そうぜ、どうでもいいことを引っ張るなよ

この中に>>8居るだろ

前スレの太郎次郎三郎のあたりからもうずっとおかしい。
俺は全部同一人物じゃないかと睨んでるんだが。

この人も代理キー派？
http://watanabek.cocolog-nifty.com/blog/2013/03/id-8fce.html

>>75
うざい

全部>>51の自演

>>77
うざい

>>46
この辺読むといいかもよ。

リレーショナルモデルのドメイン設計についての議論
http://nippondanji.blogspot.jp/2013/12/blog-post_8.html

IDの設計についてのさらに突っ込んだ議論
http://nippondanji.blogspot.jp/2013/12/id.html

代理キーにしたくてしょうがない人がいる？

代理キーと訳されるのが我慢できない人がいる

>>80 >>81
うざい

wikipedia厨が現れるころかい

>>83
うざい

スレが進んでいると思ったら、またどうでもいいことで伸びていただけだった。

>>50
ありがとう。そっちの理由なのか。なんともいえない気持ちになるなぁ。。

まぁ、ほんとに不変な自然キーってなかなか無いので、
なんだかんだある程度の覚悟はしとかないといけないよね。

ホントに永遠に不変なものなんて世の中には存在しないが
システム開発において、これは不変だとして扱いますよと決めるのが要件定義
ある程度覚悟とか、要件定義の甘さをごまかしてるだけだろ

要件定義でしっかり決めたところで、「ホントに永遠に不変なもの」じゃないんだから変わりうるでしょ。
なぜ話をひっくり返して要件定義が甘いとかずれた話になるんだろ。

いつもの人だから、論理矛盾だらけなんです。

>>85-87
有る程度、「何を」覚悟するんだ
要件変更による設計変更なのか
要件変更の伴わない設計あるいは実装の変更なのか

要件定義を行った段階では、客も不変だと認識していてかつ、それで進めてよいとなったものが
運用中に変更になることなど。
つまり、ベンダもクライアントも不変だとしていたものが、そうではなくなることを覚悟する。

つか、あなたが想定していそうな、ベンダの思い込みで実装するような馬鹿じゃないんですよ。

スレが伸びててビックリっす！

すいません。質問したキッカケは、
可変長文字列（varchar(50)とか）の列を
５列ぐらい主キーに設定していたので、
「これは、まとめてサロゲートキーした方がいいじゃないのかな？
どっちがいいんだろう？」
って事を知りたかっただけなのですが・・・

参考URLなどありがとうございます。勉強します。

荒れたってより食ってかかるやつが現れた印象

>>92
日本語も論理も変な奴が常駐してるせい

>>93
放置すれば良いよ

今まで主キーが不変であったためしが無いので
サロゲーロキー一択だなぁ
ナチュラルキーにしたいけど顧客の無茶な仕変がこわすぐる

>>93
論理が変な奴ってこれか？
>>55 >>57 >>64 >>70

日本語変なのってこれか？
>>51

>>95
結合テーブルはどうしてた？

>>96
>>89とかだろ

>>96
>>8,10,20とか。

>>97
「結合テーブル」って何？
で、どうしてたって何を？

Rails禁止なので。

もうサロゲートキーの話題も禁止でいいんじゃないか？

>>100
「結合テーブル」は「連関エンティティ」の実装のテーブル
どうしてたって、サロゲートキーつけてた？って聞きたかった

>>101
結合テーブルはRails用語ではないよ

>>103
> 「結合テーブル」は「連関エンティティ」の実装のテーブル
> どうしてたって、サロゲートキーつけてた？って聞きたかった

その話題は、前スレからさんざん出てるじゃん。
まだ荒らし足りないの？

>>104
意味わからんぞ。>>95の人がつけたかつけなかったを聞いただけだ

過敏になりすぎ

ﾋﾞｸｯ

>>105
それ聞いてどうすんだよ。
お前には関係無いだろ。

また荒らす

>>105
>>95ではないが、俺はつけるよ

>>107
理由もわからないなら、返信しなくて良いのに

>>110
うざい

>>111
やっぱその人か…
出しゃばらなくていいんだよ

>>112
いや、マジで聞いてどうすんのよ？

>>103
> 結合テーブルはRails用語ではないよ

定義がどっかにある？

JOIN

Rails脳

>>114
定義がどこかにあるかは知らないが
データベース設計を10年以上前からやってるけどそのころから普通に
"Junction Table"を用語として使ってて
それを訳すときは"結合テーブル"にしてた

junction tableなら「交差テーブル」じゃないの？

前スレでRails厨がRails用語を乱発しまくったせいでスレがおかしくなった

>>118
"Cross Reference Table"を訳すときに使ってた
同じ意味って

>>120
頼むからまともな日本語しゃべってくれよ

>>121
なにがわからないの？

ジャパニーズ

cross reference tebleなら「相互参照テーブル」じゃないの？

>>117
> 定義がどこかにあるかは知らないが

見つけてこいや

>>124
DB設計でもその訳のがいいのかな

>>122
> 同じ意味って
これどういう意味？何かの方言？

要するに、Junction Tableを結合テーブルと訳し、Cross Reference Tableを交差テーブルと訳してたってことか？

それは異端だと思うわ。

>>103
最初から、「連関エンティティにもサロゲートキーをつけてるのか？」と質問しておけば、こんなことにはならなかった。

まあ、何の為にそれを知りたいのかは俺もわからないけど。

>>127
結合テーブルと交差テーブルが同じ意味ということ

>>128
そうだね

"Cross Reference Table"はOracleで別の意味でも使われてて
そっちは別の訳にしてた

>>130
> "Cross Reference Table"はOracleで別の意味でも使われてて
> そっちは別の訳にしてた

これのこと？
http://docs.oracle.com/cd/E23549_01/integration.1111/b56238/med_xrefs.htm

>>130
> 結合テーブルと交差テーブルが同じ意味ということ

これは煽りじゃ無くてお願いね。
それならそうと最初から書いてよ。無駄にレスの往復が増えるから。

>>129
> 最初から、「連関エンティティにもサロゲートキーをつけてるのか？」と質問しておけば、こんなことにはならなかった。
すまん。反省してる

> 今まで主キーが不変であったためしが無いので
> サロゲーロキー一択だなぁ
連関エンティティだと主キーが不変にならないのかなと思ったから聞いた
サロゲートキーつけるって言われたら不変でないポイントを聞きたかった

>>131
それだね

>>132
すまん

気が済んだ？

結合テーブル＝関連テーブル≒連関エンティティっていうことでいいじゃない

いっそちゃんとした日本語の定義を、お前らがここで話し合って決めろよ

>>136
>>135

サロゲートキーが代替キーでも代理キーでもいいし、結合テーブルでも関連テーブルでも交差テーブルでもいいじゃん。

お前らの好きな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.

文脈でわかるだろ。

>>133
> 連関エンティティだと主キーが不変にならないのかなと思ったから聞いた
> サロゲートキーつけるって言われたら不変でないポイントを聞きたかった

?

>>139
過去レス嫁よ

>>140
君、>>133なんだろうけど、まだ意味わかんないよ

>>141
>>133ではないんだが･･･荒らすなよ

>>142
どういう意味なのかわかってるのなら、教えてくれます？

もうそのへんにしとけ

あと、>>140もいらんちゃちゃ入れずに完全無視しろ

>>103
サロゲートキーとサロゲートキーをくっつけてるテーブルには
サロゲートキーをつけなかったよ

それが普通

そしてまた何周めかのループに突入すると

ループの前に話をずらすステップが入るよ

楽しそうだな

いつまでサロゲートの話してんだよ

他の話題がないんだ

サロゲート職人の朝は早い

まぁ好きではじめた仕事ですから

id厨が飽きちゃったら、もはや語られる話題が無い件について

KVSで盛り上がって欲しい

KVSは一応スレがある

【KVS】 Key-Value Storeを勉強するスレ
http://toro.2ch.net/test/read.cgi/db/1267115925/

外部キーが書き換えられたときに自動で追従させたいんだけど
トリガー使って一緒に書き換えは可能？

可能だし、DBMSによってはそういう設定ができる

まあ、基本DBMSに依るんで何とも言えんが
外部キーの変更をカスケードして追従する機能があったり
トリガでの更新だと制限があったりすることもある

が、外部キーの値が書き換えられる状況がまず正しいか検討するべきじゃないかと

普段は運用の仕事をしているSEだが、上司にDBの設計をやりたいと話したら
DBはプログラミングと関わっているから〇〇の部署に行けよという
話になったが、DBの設計ってアプリ部分の話を指すのが普通なのか？
俺は、インフラ部分の方式設計や物理設計をやりたいという意味で言ったんだが。

この場合は、上司と俺のどちらの認識が正しいのか教えてください。

>>161
上司

>>162
そうなんですか･･･orz
DBのインフラ部分の方式設計や物理設計、パラメータの設計をやりたいという
希望を伝えたい場合、どういう伝え方がいいんでしょうか。
質問ばかりですいません。

>>163
> DBのインフラ部分の方式設計や物理設計、パラメータの設計をやりたいという

相当でかいシステムでない限りそこだけ単独で担当つけたりしない
(そう言うケースだと、それなりのスペシャリストでないと歯がたたん)
ソフトウェア設計の一部になるから、その手の部署に行くしかないよ

そもそもこんなこと聞いてる時点で、そんな設計できる能力あるのか疑問なんだが...

>>164
素人なんでよく分かってないんですいません。
仕事のイメージとしては、各種サーバの構築(OS、JP1等のソフトのインストール)や
動作確認等のテスト等の作業と併せてDBの方式設計、構築をするという感じです。
上司には、上記のような仕事をしたいという伝え方がいいのでしょうか。

>>165
ねえ、人の話聞いてる？

> ソフトウェア設計の一部になるから、その手の部署に行くしかないよ

って書いてあるんだが...

>>165
DB設計うんぬんの前に、コミュニケーションの原則として、
相手に自分の意志を伝達したいのであれば、それを具体的に説明すべき
（抽象的な表現を都合のいいように解釈してくれると勘違いするな！！）
つまり、>>165で書かれたイメージを上司に話すことが第一歩になる

職場の異動希望、成功を祈るよ

>>166
すいません。気を付けます。

>>167
ご指摘ありがとうざいます。
インフラ設計、構築の仕事を希望していたのは、元々オラクルの
資格勉強をしていてDBのソフトの設定等に興味があったからなんですよね。
異動希望が絶対に叶うように頑張ります！

世の中に「絶対」は無い

>>169
「絶対」は「絶対」にないの？ (w

死に物狂いで勉強して、
障害復旧やらDBのバグ解析や回避方法などの、
実務経験とスキルを積み上げて、
ぎょうかいでなまえをしられた大企業に就職できたら
希望は叶う可能性があるかも知れないな、って思ったよ
頑張れ

>>170
ないよ

てことはあるんじゃんｗ

>>168
チューニングしたいって言えばなんとなく通じてくれるかもしれないけど、まぁ、具体的に話をするのが一番いい。
クエリ改善も含まれるけど、それだって大切な仕事だ。

AとBの依存関係を持つテーブルCがあるとします。
C の構成は idA, idB しかない。

インデックスは idA,idB それぞれに振ってる。
あと、idA,idBでユニークインデックス振ってるんだけど
インデックス振り過ぎ？

>>174
チューニングっていう表現だとアプリ部分も含まれるんですかね？
次の面談では上司にオラクルの資格勉強を通してDBの設定操作に興味を
持ったので各種サーバーの設計、構築、テストをするインフラ部分の仕事をしたい
という感じで伝えてみようと思います。

>>175
基本DBMSによるけど

それ(idA,idB)で主キーになってるんじゃないのか？
ほとんどのDBMSで主キーに勝手にユニークインデックス張ってるんじゃね
それ以外に自分で張ってるなら全く無駄なインデックス張ってるかもしれんぞ

(idA,idB)のインデックスとidAのインデックスが同時に使われることはないだろうし
idAのインデックスからidBを得るにはインデックスから実データの参照が必要
idAに普通にインデックス張るのは無駄かもしれん

>>175
インデックス張りの追加可否については、
そのDBを利用するアプリケーションのアクセスパスを元に判断する

たとえば>>175の例で A と B が(C を介して) m:n 関係であったとする
そしてアプリケーションのDBへのアクセスパスを分析(＊)したところ、
A の行を元に対応する B の行集合を得る操作が大半で、
その逆に B から A を得る操作はごく僅かであったとする
この場合、idA にインデックスを張ることによって、
システム全体の性能改善が期待できると判断できる

(＊)アクセスパスの分析は、以下に示す二段階で実施すべき
・アプリケーション設計時：
　　アクセス頻度を設計値として見積もり、DBの物理設計書(テーブル仕様書)へ明記する
・システム連動テスト時：
　　ログを解析し、実環境でのアクセス頻度が見積もりと一致することを確認する

インデックスは張れば使うってもんでもないんで、そのインデックスが有効かどうか考えんと
パターンとしてはＡからＢを検索、ＢからＡを検索、ＡＢペアで検索の３通り
（実際にその全てのパターンでアプリが検索するとはかぎらないんだが、一応全部想定する）
いま考えるべきは
Ａから検索するときに、Ａ，Ｂの複合インデックスとＡ単独のインデックスではどっちがより有効か？
Ｂから検索するときに、Ｂ，Ａの複合インデックスとＢ単独のインデックスではどっちがより有効か？
ペアで検索するときにＡＢとＢＡでどっちの複合インデックスがより有効か
の三つじゃないかね

俺の考えでは同じ普通のインデックスなら、ＡＢの複合が有ればＡ単独のインデックスに出番はないと思うが
例外があるとすれば、ＡＢの複合よりＡ単独の方がインデックスページのＩＯ量が少なくて済むから、
超巨大なデータでそれなりのカーディナリで実データルックアップ差し引いても速いときぐらい？
実際にそんな状況が起こりえるかな？
Ｂからのパターンも同様
ペアで検索はＡとＢでどっちがカーディナリ高いかで差が出るかもしれん。大差は出ないと思うが、気になるなら
両方作ってオプティマイザに任せるのがいいかも

ということで、俺ならＡＢの複合インデックスとＢＡの複合インデックス二つだけ作っておくかな
あくまで速度メインで考えた場合だけど

>>177-179
みんなー！ ありがとうー！
とりあえず、(idA)単体のインデックスはすてました

スロークエリをログに出力するようにしとけばOK

すいません。圧倒的に場違いなのは理解してるのですが、DBに詳しい方教えてください。

自分はポストグレの入門書をかじり、サーブレットのJDBCを理解できる程度の者です。

この状態で、英語辞書のようなもの（たとえば、alcといったようなサイトのように、単語を打ち込むと日本語訳と例文がでてくるようなもの。）
を作りたいのですが、どのようにすれば効率がよく作れるのでしょうか？

>>182
どっかの業者に金払って作ってもらう

>>183
勉強も兼ねて自分でやりたいのです。

どのDBを使えばやりやすいのでしょうか？もしくはプログラミングなどを書けば利用すれば自動でできるものなのでしょうか？

入門書を物理的にかじりでもしたの？JDBCを理解できる程度ってのも意味がわからないし。
低機能なものなら学生の宿題にでてもおかしくないレベルだし、まずDB使わずに作ってみたらどう。

まず、英単語の日本語訳と例文をどうやって準備するのかが難しいような

>>178
> 　　アクセス頻度を設計値として見積もり、DBの物理設計書(テーブル仕様書)へ明記する
アクセス頻度って何？
単位時間あたりのアクセス数とか？
で、何らかの閾値を超えたりしたら、何か物理設計を変更するとか？

>>187
普通に、必要に応じてインデックスを追加するって話だと思うよ

>>188
あなたには聞いてません

>>186
いや、それは既にできてるんです。

しこしこhsqlに入れて言って、JDBCでブラウザに表示まではできます。

しかし、あまりにも重労働すぎるので、まだここらは初心者なので、ハック的な技術があるか聞きたかったのです。

DB操作なので、そこまでプレミアムなスキルでもないとは思ってるのですが、やはり不可能でしょうか

>>190
今、何を効率が悪いと感じていて、何を重労働と感じているのかを書かないと、アドバイスのしようがない。
そして、多分その回答はスレ違いだと思われる。
このスレは、「データベース設計」のスレなので。

>>190
元ネタからinsert文でも作って流せばいいんじゃないの。

登録が大変ってことなら、一括インポートすればいいじゃない
てか、DB設計となんの関係もないが

スレ違いだとわかってて平気で質問するような奴をまともに相手しちゃイカン

辞書つくりたい。

どのDB使えばいいか教えてください。お願いします。

どの本よめばいいですか？

「ポストグレの入門書をかじり」終えたなら、次はその本をしゃぶりつくすこと。

>>196
そのあとは何をやればいいでしょうか？

問題の切り分け能力をつけるために雪山に登山する。

>>198
そのあとはいかがすればいいでしょうか？

>>199
やってからどうぞ

生徒の出席状況を確認するシステムを作りたいと考えています。
月ごと、年ごとにカレンダーで一覧を表示したいのですが
student_id, year, month, day
を持つテーブルを作って、生徒が一日一回出席をボタンを押すたびに
その日をinsertするという形を考えました。
もっとうまい方法があれば教えて頂けないでしょうか。
よろしくお願いします。

2行目、ユーザーごとに月ごとにカレンダーで一覧を表示したい
の間違いです。すみません。

>>201
> year, month, day

Date 型でいいんじゃね？

>>201
要件がそれだけならそれでいいんじゃね、としか言えないな

うまいって言うのは、何がどうなってればうまいと思うの？
今何がまずいと思うの？

>>203
Date型を初めて知ったのでググってみます。

>>204
これでいいのか自信が無かったのでお聞きしました。
プログラムとか経験ないのに作れと無茶振りされたもので…

同じ年月日で1件しか受け付けないなら、8桁の数値型でいいように思う。

タイムレコーダーみたいなもんだろ
同じidでも時刻入りで入力は全部記録するべきと思う

>>206
なんでそんな面倒な設計にするんだ...

Date型にしない理由が見当たらん

あえて理由をつけるなら、年月で絞る時にインデックスが効きやすいとか
まあ、億オーダーのレコード数でもなければ普通に日付型で良いだろうけど

いまどき日付型のないDBMSとか有るかな？

インデックスの効きやすさに差が出てくるもんなの？

年、月、日で別項目なら、年、月でインデックスはれば密度が違うからなぁ
数字８ケタとかなら大差ない気はするけど
日付型はうっかり変換関数とかにかけて悲惨な事になったりすることも
まあ、最近のDBMSなら関数噛ませてインデックスに出来るやつもあったような

年月日のインデックスのほかに年月のインデックスを貼るん？？

月ごと年毎にカレンダーで一覧表示ってあるけど、
国内だと年毎＝年度毎だったりするから、
年月日別より年月と日の方が扱いやすいかもしれない。
列結合の検索（INDEXききづらい）や複数項目使った範囲検索すればいいって
話だけど、単項目の検索のほうが楽だし、バグも当然少ない。
INDEXも明確にわかりやすい。

初心者みたいだし、日付型の項目を一緒に作っておいて、
登録データを見ながら、やってみてはどうだろうか。

>>212
ああ、ごめん。
数字8桁のほうがインデックス効きやすいと言ってるのかと勘違いしてた。それなら納得。
書いてくれてるように、式インデックス使えるならそれ使ってもいいね。

>>214
＞日付型の項目を一緒に作っておいて、
＞登録データを見ながら、やってみてはどうだろうか。
このやり方でやってみようと思います。
皆さんありがとうございます。

出欠システムなら日付の他に遅刻早退中抜け情報も必要なんじゃねか
要件として不要とわかってるならいいんだが

年月と日とかよっぽど特殊な要件がないと利点が見出せん
日付型と年月日の数字で実データ持つって、１０年前のRDBMSならともかく今時ありえんわ

>>216
> このやり方でやってみようと思います。

なんでそれを選択するかなぁ...

>>219
あまりいいやり方ではないのだろうなというのはわかるのですが
date型のwhere句の書き方がわかっていないからです。
int型で年、月、日を持っていれば
where year = 2013 and month = 12
のように書けばいいのはわかります。
来月4日までに完成させないといけないという時間的な問題もあるので
とりあえず動くように作っておいて後からdate型だけに統一するつもりです。

>>220
大抵の DBMS には Year とか Month とかの関数があるかも、ぐらいは思い付かない？
まあ、期限あるならしょうがないかもな。

式NDEXとか、初心者時代やらないだろ？
カラムに対して、関数つけて検索しないってのはある種のお約束じゃないか？

date型where句の書き方も曖昧みたいだし、
最初は自分のイメージを形にする方優先でいいと思う。

俺は>>220には賛成

年、月、日の数字で持つのはまあそれでもいいけど
同じ情報を二つ持つのはやめなさい
手間とトラブルを増やすだけだから

最初は年月日を数字で持つほうがイメージ湧くから良いと思う
Date型は必要だと思ったときに足せば良いだけだから最初はいらないんじゃないか？

たださ、インデックスの問題で年月のが有利ってのは理解できないぞ

年月のが有利って思ったのは、月別、年別で一覧表示と
あったので、年・月・日と個々に項目を持った場合、
年と月の複合キーか、年のINDEX、月のINDEXを個々に持つ。

仕様が年別と月別の一覧表示なら（集計のみを考えた場合）、
画面上のYYY年MM月をYYYYMMで検索の方がいいかなと。
これならINDEXも１つでいいし。

最近年月単位のパーティションとか作ってたから、頭がかたまってるかもしれん。
有利ってのはちょっと違うな。すまん。

>>220
それが分かりやすいということについては分かる。
ただ、下期の一覧を出したい場合、たとえば、2012/10 〜 2013/3 を抽出したいときが面倒だよってぐらいかな。

来月4日までに作らないといけないって、たぶん、12月サボったツケだろうからがんばれとしか言いようがない。

来月４日か。来年四月かと思ったわｗ
ＤＢ設計うんぬんより、ホストアプリでちゃんとプログラム組めるのかね

1月4日はネタじゃねーの？
マジだったら、まずは Excel でやれって言うわ。
Excel で手に負えないならそもそも 1月4日 なんて無理だろうし。

レストラン、不動産、求人などの検索サイトは、「OR検索」が多発しますが、設計上の配慮はどのようなことがあるのでしょうか。

>>229
まずは、普通に正規化すればいい。
検索に時間がかかるほどのデータ量の場合は、「転置インデックス」とかでググれ。

≫230
＞転地インデックス

そうか。各「OR検索」のフラグは、ユニークな文字列として全文検索用の別テーブルにスペース区切りで入れ、OR検索は全文検索に変えればいいのか！

ttp://dev.mysql.com/doc/refman/5.1/ja/fulltext-search.html

>>230
MySQLの全文検索で検索自体はできることが確認できたのだけれど、任意のカラムで全文検索とは別の索引を使用した高速なソートができないことが判明。

別の索引でソートする機能はTritonnではできていたのに、
ttp://qwik.jp/tritonn/userguide.html#0cb0baa8b27d86e9233f601a9cc9cc4f

mroongaではできないっぽい。
どうしたらいいんだ。

>>232
ttp://mroonga.org/ja/blog/2013/12/29/release.html

できるようになってたっぽい！

顧客に経度カラム、緯度カラム持たすのってダサい？

経度、緯度が必要なら持たさないとどうしようもないだろう
ダサいとかいう考え方がおかしいんだが

住所から導出できるだろうとか言う話なら要件次第
経緯まとめた項目ないかってならDBMS次第

ダサいダサくないじゃなくて、顧客にダイレクトに緯度経度を紐付けたい
要件がパッと思い浮かばないんだけど、何かあるんかね

どういう要件があるのかってところが分からんと良いとも悪いとも言えん

不動産か現在位置か

顧客の現在位置を常に把握しないといけないってどういう業務？

運輸業界かな？w

タクシーの配車システムとか

>>238
どこから「常に」なんて要件持ってきたんだ？

>>241
じゃあときどきでいいよ
顧客の位置をときどき把握しないといけないってどういう業務？

>>242
上でいっぱい言われてるだろ
不動産とか運輸業界とか、位置情報をもってるシステムはけっこうあるぞ
昔は緯度経度だけもっててもあまり役に立たなかったんんだが、最近では地図サービスが充実してるからなぁ

コマツの土木車両にはGPSが標準装備されていて、
国内で稼働する全車両の位置情報が把握できる
詳しくは「コマツ GPS」でググレ

不動産なら物件・運送なら車両・画像共有なら画像と紐付くと思うんだ＜緯度経度
そうでなく顧客に直接紐付けというところに引っかかりを覚える

まあどうせ>>234はもう見てないだろうけど

>>244
海外も把握してなかったっけ？

友達を探す

オブジェクト指向でコンポジットパターンと言われる構造のデータって、
どうやってテーブル化するべきでしょうか？

たとえば、

class 予定
{
　日時;
　場所;
};

class 買い物: 予定
{
　vector<品目> 買い物リスト;
};

class 訪問: 予定
{
　用件;
};

こんな感じのクラス階層のものです。

CREATE TABLE ScheduleHeader
(
　int id;
　datetime 日時;
　text 場所;
　int 予定タイプ; // 0 = 買い物, 1 = 訪問...
);

みたいにして、予定タイプを読んでプログラム側で詳細の取得先を切り替えるようにするのかなと思ったのですが、普通はどうするのでしょうか？

>>248
大きく分類すると３つある
(1) シングルテーブル継承
　３つのクラス 予定/買物/訪問 を単一のテーブルで実装する
(2) クラステーブル継承
　３つのクラス 予定/買物/訪問 を個別のテーブルで(=3つのテーブルで)実装する
(3) 具象テーブル継承
　具象クラス 買物/訪問 だけをテーブルとして(=2つのテーブルで)実装する

それぞれに利点/欠点があってここでは書ききれないけど、
多くのORMは(たとえば Ruby on Rails の ActiveRecord は)
最も単純なシングルテーブル継承を基本としてサポートしている
詳しくは、以下の書籍(通称 EoA本)を読むべし
・エンタープライズ アプリケーションアーキテクチャパターン: マーチン・ファウラー
　http://www.amazon.co.jp/dp/4798105538/

>>248ではシングルテーブル継承が主流のような書き方をしたけど、
個人的な意見ではあるが「DB設計」という視点からすれば、以下の問題がある
（これはEoA本では触れられていない）
(a) 買物インスタンスのテーブルでは用件カラムが、訪問インスタンスでは
　買物リストカラムが nullable になるので、検索時に潜在的なバグを生みやすい
(b) (a) によって参照性制約を設定できなくなるため、
　DBのデータ一貫性が損なわれる可能性がある
(c) 一つのテーブルに複数のエンティティを実装することになるため
　インデックス設計が複雑になり、性能問題を引き起こしやすい

従って、>>248 (2) のクラステーブル継承を推す
この方式については、EoA本では複数テーブルのJOIN操作が性能上で不利と書かれている
しかし、現実的なハード構成、簡潔なエンティティ、適切なインデックス設定、そして
SQLの知識を前提とすれば、経験上、数万件のオーダーで性能問題は起きたことがない

それでも現実にはシングルテーブル継承が主流なのは、ORMの採用による
システム開発の効率化優先(およびDB設計の相対的軽視)が背景にあると考える

>>250のアンカを訂正、>>248は間違いで正しくは>>249

>>249-250
ありがとうございました、キーワードが分かっただけで検索がだいぶ楽になりました。
問題の本は、ちょっと高いので行き詰まったら購入を検討したいと思います。

構造的にはクラステーブル継承が好みですが、シングルテーブルなんてのもあるんですね
これは、真っ先にしかられるタイプの構造だと思ってました

むしろRoRのActiveRecordってそんなの推奨してんの？
そんなところまでしばられちゃ正規化も何もあったもんじゃないんじゃないの。

(2)か(3)のどっちかで済ませるのがいいけど、まぁ、(2)は>>248で思ってたやり方そのままかと。
予定タイプを持つことの是非は状況次第。

あと、そもそも論だけれど、数万件のオーダーでしか話せない人は基本的に信用してはいけない。

ついでに、コンポジットパターンじゃないよね、それ。

>>253
> ついでに、コンポジットパターンじゃないよね、それ。
マジでこれ。

つか、RoR馬鹿は黙ってて欲しい。

買い物・訪問テーブルを個別に作り、両者を一覧で見たい場合はUNIONを使う、
というのが普通な気がするが。

システムの要件がわからないとなんとも言えない

文字コードUTF-8でデータを格納するための列の列長のバイト数って
どうやって設計するのがいいの?

シフトJISの頃だと、漢字や平仮名は1文字2バイトだって前提で
漢字10文字入れたい→20バイト、なんて風に設計してたけど、
UTF-8だとどうなんだろう
エンドユーザ側は、どの文字がUTF-8だと3バイトなのか、
4バイトになるのか、なんて意識してないよね

1文字3バイトが多いから30バイト、でいいのだろうか
でもそれだと、漢字10文字入れたいって場合に、4バイトの漢字だと
10文字入らなくなっちゃうよね

逆に4バイトの文字を考慮して40バイト、とすべきなのだろうか
でもそうすると、3バイト文字を13文字詰められちゃうから
変な不整合を起こしそう

nつきの型はバイトベースじゃなく文字数ベースでの指定だったような
DB全体での容量計算の話なら文字コードUCSにすりゃいいんじゃないですかね(適当

設計つか、容量見積の話じゃないのか
まあ、平均的なパターン見るか最悪のケースで見とくか
俺なら最悪のケースだけ計算しとくけど

>>257
固定長カラムを作らなくなって久しいので、そう悩むことがなかった。

>>258
DB全体の容量見積もりというよりかは、単なる列長の考え方、だと思ってます
Oracleでいう、ncharとかnvarchar2を使ってテーブルを作る、が標準なのでしょうかねぇ
ncharは使わずchar、という案件ばかりだったのですが、UTF-8を採用している案件って
実際のところ、ncharとか使ってるものなのでしょうか

>>259
容量計算する場合は、平均文字数はX文字と想定する、という要件があるので、
それで計算すればいいのかな、と
とはいえ、じゃあ1文字は何バイトなのよ?というのもあるかな、と

>>260
最大を大きめの可変長で作っておけばよかろうとは思っているのですが、
漢字30バイトの列には漢字が何文字入るの?と問われたときに、文字によって8文字〜10文字、
では都合が悪かろうな…とも思ってまして…

うーむ

そもそも漢字30バイトの列とかあるか？
漢字がまともに扱えるDBMSなら指定は文字数なのが一般的なんじゃ？
漢字の想定の無い項目に漢字いれるとか恐ろしすぎる

UTF8で扱えるんだよね？

>>262
すいません、30バイトの列には漢字は何文字入るの?でした

NCHARで文字数指定する、一般的なのでしょうかね

漢字だろうが英数字だろうが、CHAR(n)で入るバイト数を指定、漢字は2バイト、と
これまでやってきたため、その考え方の変更が必要そうですね…

ええと、そもそもなんだけど、
少なくともデータ長に関しては無頓着にクエリを発行して、
データベースエラーを元にvalidateを行おうとしているの？

> 逆に4バイトの文字を考慮して40バイト、とすべきなのだろうか
> でもそうすると、3バイト文字を13文字詰められちゃうから
> 変な不整合を起こしそう

昔から悩んでいるのですが、
・会員情報（アカウント名、パスワード、メールアドレス
・プロフィール（性別、生年月日、写真、コメントなど）

を、1つのテーブルにするべきですかね？分けるべきですかね？
1対1なんで1つの方が良いとは思うのですが、
後々プロフィールのカラムを追加する可能性もあるので、
分けたほうがいいのかなとも思います。

オススメの方法・考え方を教えて下さい。

>>266
参考書レベルの正規化では第2正規形にするあたりで別表にしそうなものだが、
実際問題としては、それ系のテーブルというものは、カラムの追加がないのなら、
無理に分ける必要は無い
性別、生年月日なんかも、分けて書いてる教科書もあるけど、異端をのぞいちゃ
変わるものでもないのだから会員情報テーブルに置いときゃOK

コメント2、コメント3、みたいなカラムの追加が予定されているなら、
プロフィールのその部分だけ別表に分けたほうがよかろうな

テーブルをは、教科書にそれで分けてる事例が書いてあるからって程度の理由で
分けるもんじゃない
運用でおかしくならないかどうかって観点で分けるのだ

>>267
どこの世界の第2正規形の話をしてるの？
なんかカラムの追加が発生しうるテーブルは分割するのが基本だが、実際は〜みたいな言い回しだけど。

> 変わるものでもないのだから会員情報テーブルに置いときゃOK
これも、まるで理解できない。パスワードも異端をのぞいちゃ変わるものでもないってこと？
それとも、俗にいうマスタとトランの分割の話かな。

267と268の間に、パスワードに関する記述があるのだろうか、と俺は
見えないモノを見ようとしてモニタを覗き込んだのであった

> 異端をのぞいちゃ変わるものでもないのだから会員情報テーブルに置いときゃOK
変わるものなら会員情報に置かないほうがいいってことでしょ。
じゃあ、パスワードは変わらないの？ってことだけど。

>>268
お前は今まで性別や生年月日を何回変えた?

>>271
だからおかしいでしょ？
性別や生年月日は変わらないから会員情報に置けばいいよっていうなら、
変わるパスワードは会員情報から追い出さなきゃいけない。

>>272
追い出したけりゃ、追い出せばいいんじゃね?

ところでその唐突に出てきたパスワードって、何の話なのだ

>>268
「変わらないんだから分割する必要ない」
ということは
「変わるものは必ず分割する」
ということと、等価ではないよ

私は>>267が指摘している、性別や生年月日をまで別テーブルに分割する必要はない、
という見解には同意できるけど、でもパスワードは変更するから云々というのは、
飛躍しすぎだと考える

>>273
もともと会員テーブルにあるカラムのことだけど。

>>274
変わろうが変わるまいが分割する必要はないという主張をするのなら、
変更されるのがまれかどうかという話は必要ないでしょ。
だから、まるで理解できないと書いた。

性別、生年月日なんかも、分けて書いてる教科書もあるけど
↑この教科書とやらがどういうポリシーで分けたかを書かないとどうにもならんよ

>>271,272
韓国では自己申告によって誕生日を変更できるらしい
また、日本でも性別に関して一度だけなら現実に変更は起こりうる
まあ、これらはどちらも極端な例かもしれないがね

それはさておき、会員情報には現実に何度も変更される事を想定すべき項目もある
たとえば郵便番号/住所/電話番号/メールアドレスは引っ越し等で変わる
もしも想定しているサービスがSNS等であるなら、
最新の情報さえDB上に記録されていれば十分かもしれない
しかし、仮にサービスがオンラインショップの会員であり、
過去に遡って全会員を対象にした購買傾向を追跡/分析したいのであれば、
ある会員IDに対する変更履歴情報をDB上に格納する方法も選択肢になる

つまり>>266に対して言いたい事とは、会員情報を実装するのにテーブルが１個ですむのか
複数必要になるのかは、提供しようとするサービスの業務分析によって決まる、ってこと
で、もしも業務分析の初期段階にあって決定できないのなら１個にまとめる
何となく必要になりそうだから...という曖昧な理由による複数テーブル化は、
DB設計に無駄を追加するだけの無益な行為である

>>275
つまり、分割する必要なない、と思ってる、ということでよい?

何だかよく分からん

>>275
会員テーブルにあるパスワードはへんだから別テーブルにしろ、といいたいのか?
それなら>>266にそう言ってやればよろしかろう

俺にも、お前が何を言いたいのか分からん

>>277
これに一票

>>277さんの回答を元に質問させていただきますと、
>>266の質問は新規サイトを作る時にいつも悩むのでして、
自分の性格からか、どうしても汎用性の高い仕様にしたく思い、
2つのテーブルに分けています。

しかし、selectする時も面倒くさいし、画面設計も多くなります。
だからと言って、絶対に後からカラムがしないとも言い切れないし、
ECではなく、コミュニティ関係のサイトでも
複数の住所とか画像とか登録したくなるかもしれません。

そんなこんなを考えると、DB設計がなかなかまとまらないんです。

ただ、これまで2つに分けて後からプロフィールを追加する事案って
ほぼ無かったように思います。ECサイトは作っていませんが。

だからやっぱり「迷ったら1つにしろ」っていう
>>277さんの意見が正しいんですかね。私自身が心配し過ぎというか・・・

>>280
画面設計が増えるの？

>>282
はい。会員情報とプロフィールなら画面が2つ分かれます。
有名所だと、ヤフーもそうだと思います。

>>283
テーブルを分けることとは関係なくない？

確かに関係無いですね・・・

そんなことより第二正規形ってそういうもんだっけ？
俺が学んだのと違うな

>>280
迷ったら一つにする、というのは誤りではないが、必ずしも正解でもない
基本通りに分割する、というのも誤りではないが、やはり必ずしも正解でもない

何事にも限度がある
その限度のガイドラインとなるのは、やはり業務と仕様かと

ひとテーブルにまとめるなら、これは分割する必要なさそうだけど、一緒でよい?と、
逆に分割するなら、例えばプロフィールは今後増える?増えるなら分割しないとだぜ?
みたいなことを開発側と練っていって、より正解に近い方を選んでいくもので、
DB担当一人で悩む所ではないかなと

マスターベーション的に分割するという行為には、あまり価値がない

「変更されないから」同じテーブルにおいていいなんて前置きをされたら
変更されるカラムがあるけどそれはいいのか？って思うだけだ。
前置きをするからには何らかの理由があったはずだ。

>>278
分割の必要はないと思ってるよ。
変更されないから同じテーブルに置いていいよという前置きの意味が分からないだけだよ。

>>279
何も変じゃないよ。同じテーブルに置けばよい。
変更されるかどうかなんて気にせず置けばよい。

>>280
クラス分割とテーブル分割を混同してはいけない。
OR/Mによってテーブル設計を縛られてはいけない。
それだけだよ。

>>287
相談できる相手がいればいいんですけどね・・。
あまりDB設計の事例ってネット上に無いですし、
どうすれば良いか悩むんですよね・・・。

>>289
定型的にこうすればよい、という手法が無いからね
ネットなりで示される事例というのも、当該の案件ではそうした、というだけであって
どんな場合にも通用するわけじゃないし

抽象的なDB設計手法の情報を得つつ、具体的な案件で活用し、また別の事例を学び、
前回の案件での反省を踏まえて、みたいな手探りの繰り返しで、センスや勘所を
磨いていく、だろうかねぇ

ただベースとなるところは持つべきで、それはDBの基礎知識だったり、DBはどうあるべきか
みたいな思想だったり、無駄や過剰を判断する自分なりの基準だったりして、さ

それはアーキテクチャやNWも同様なのだけれどね

>>277
>過去に遡って全会員を対象にした購買傾向を追跡/分析したいのであれば、
>ある会員IDに対する変更履歴情報をDB上に格納する方法も選択肢になる
>
>つまり>>266に対して言いたい事とは、会員情報を実装するのにテーブルが１個ですむのか
>複数必要になるのかは、提供しようとするサービスの業務分析によって決まる、ってこと
履歴テーブルを追加するかどうかと、会員情報とプロフィールを分けるかどうかは関係ないよね…？
会員情報テーブルに履歴ももたせるという発想は、SNSではあり得ないし。。

皆さま。アドバイスありがとうございました。
小規模なサイトなら1テーブルに済ませるように考えたいと思います。

セキュリティの一環で会員情報とプロフ情報を分けるのはありだと思うな。
会員情報を独立させて、暗号化させとけば情報漏えいは減ると思うし。
思想っていうか方針の問題だと思う。
正解はないよね。

元の質問にかかれてないけど、プロフィールが必須かどうかで話は変わるよ。

>>293
それ思想でも方針でも無くて、セキュリティ要件

何らかの要件でわける必要があればわければ良いけど
今回の例でわける必要もメリットもあるようには見えんが

ここも強制IDになればいいのにな。自演臭がひどい

ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。

http://iup.2ch-library.com/i/i1163452-1396345725.png
ゲームのデータベース作ってるんですが、うまく正規化ができなくて困ってます。

・プレイヤーは１つのチーム編成を持っている
・プレイヤーは複数のキャラクターを持っている
・チーム編成は同じプレイヤーのキャラクターを最大8つ登録できる
・チーム編成の1番目のキャラクターをリーダーとするため、チーム全体の順番を保存したい
・キャラクターは１つのチーム編成にしか登録できない
・キャラクターは１つのチーム編成に１つしか登録できない

パズドラっていうソーシャルゲームのチーム編成っぽい感じです。
どうしたらいいですか？

>>298
> ・キャラクターは１つのチーム編成にしか登録できない
> ・キャラクターは１つのチーム編成に１つしか登録できない

つまりチーム編成とキャラクターは一対多の関係だと言いたいのかな、これ

キャラクターIDが一意なサロゲートキーなのか重複しうる種別IDなのか
曖昧なのが混乱を誘っているように見える

まずは主キーがどれか整理して考えるとこからじゃないかな

>>298
自分には、文章で書かれた要求に従って、適切に設計されているように見える
少なくとも第１／２正規化は満たしているから、
それ以上の正規化にはこだわらなくてもいいのではないかと思う

>>298
キャラクターが複数のチームに登録されてるように見えるよ。

すいません、チーム編成テーブルの主キーが決まらなくて困ってます

>>302
チーム編成テーブルの主キーは
プレイヤーIDとキャラクターIDでいいんじゃないの？

自分が設計すると、チームを別途に作ってしまうな

> ・キャラクターは１つのチーム編成にしか登録できない
これって必要？結果としては出てくるんだけど、要件なのかなーってね

>>303
>> ・キャラクターは１つのチーム編成にしか登録できない
>これって必要？結果としては出てくるんだけど、要件なのかなーってね
システムの要件としては必要なんだろ
問題はどこまでDB側で保障するかって話
これを保証したいなら、キャラクターテーブルにチーム編成の主キー(ID)持たせろって事になる
同様に
>・プレイヤーは１つのチーム編成を持っている
これも保障したいならプレイヤーテーブルにチーム編成のID持たせる

俺ならこのレイアウトのまま、登録するアプリでチェックするけど
チーム編成の主キーは(プレイヤーID,キャラクターID)か(プレイヤーID,キャラクターID,番号)かだな

チーム編成の主キーは(プレイヤーID,キャラクターID)か(プレイヤーID,番号,キャラクターID)かだな
に訂正しとく

>>302
>>299に答えないと進まないと思う。この部分。
> キャラクターIDが一意なサロゲートキーなのか重複しうる種別IDなのか

見た感じ一意なものだと予想してるんだけど。つまりスライムじゃなくスラりんだと。

>>304
> 俺ならこのレイアウトのまま、登録するアプリでチェックするけど

いやー、データベースで一意性制約つけられるスキーマにしたほうがいいって。

>>303
大体同意見。
>自分が設計すると、チームを別途に作ってしまうな
将来的に複数チームを持たせられるようにすることを考えればそうしたくなるね。
ソシャゲだと複数デッキ登録しておける場合が多いし。

>> ・キャラクターは１つのチーム編成にしか登録できない
>これって必要？結果としては出てくるんだけど、要件なのかなーってね
ね。キャラクターが1ユーザにしか紐づかないのであれば、自然と1つのチームにしか登録できないよね。

>>304
>>> ・キャラクターは１つのチーム編成にしか登録できない
>>これって必要？結果としては出てくるんだけど、要件なのかなーってね
(snip)
> これを保証したいなら、キャラクターテーブルにチーム編成の主キー(ID)持たせろって事になる
そうしてもいいし、そうしなくてもいい。すでに保証されてる。

>>・プレイヤーは１つのチーム編成を持っている
>これも保障したいならプレイヤーテーブルにチーム編成のID持たせる
同様。

よって、その制約を守るためにアプリでチェックする内容に変化はないだろう。
何か勘違いしたまま書いたんじゃないかな。

>>299
そうです。
ひとつのチームにキャラクターが複数存在します
ポケモンみたいなイメージです

>>299
キャラクターテーブルはそのまま、レコード一件につきキャラクター一体を表します。
情報量少なくて申し訳ありません。

チームを将来的に複数もてる事を想定した場合、
チームテーブルは

*チームID
*順番
プレイヤーID
キャラクターID

こんな感じで、何人か仰っているように
「一つのチームに同じキャラクターは登録できない」
という条件に絞った方が綺麗に正規化されているのでしょうか

>>311
すいません、間違えました

*プレイヤーID
*チーム番号
*順番
キャラクターID
という感じです

>>311
それは正規化できてないよ。
チームに8キャラクター登録できるということを踏まえると、
ひとつのチームの情報に、プレイヤーIDが繰り返し8回出てくることになるでしょ。
複数チームを想定しつつ、正規化をするなら、

プレイヤー-チーム
*プレイヤーID
*チームID

チーム
*チームID
*順番
キャラクターID

加えて、チームID、キャラクターIDでユニーク制約をつけておけばいいかと。

ついでに書いておくと、データの無駄(重複)を排除するのが正規化の目的。
無駄がなければすっきりする。

その上で、
・チームに所属できるのは8キャラクターまで
・チーム数はひとつのみ
・プレイヤーが所有権を持つキャラクターのみチームに属することができる
という、制約が必要になってくる。
これは、DBMSがもっている制約で行うこともできるが、アプリでもやることがほとんど。

>>312
それでもいい。

>>313
ユニーク制約ってよく分からないんですが、
一意だけどキーにはしないという感じの制約ですか？

>>313
これだと、別のプレイヤーが同じチームを持ってしまいませんか？

>>314
両方野郎と思います！

>>316
ユニークキーといったりもするよ。一意であることを示すものだね。
プライマリキーはそもそもユニーク制約もかねてる。

>>317
持たせようと思えば持たせられるね。
ところでそれは>>312でも同じですね。

ついでに言えば>>312の設計だと
・複数プレイヤーが同じチームを持てる(当然、他人の所持キャラクターを含む)
・順番さえ違えば同じチームに複数の同キャラクターを持てる
みたいな愉快な事になるねw

>>320
二つ目は>>313でも言及してるけど、ユニーク制約で対応だね。
チーム、順番はユニークであるべきだし、
チーム、キャラクターIDもまた、ユニークであるべきだ。
PKだけでは対応できない。

同じ意味で、>>304がプレイヤーID、キャラクターID、番号の3項目をPKにするというのはおかしな話。

>>308
>キャラクターが1ユーザにしか紐づかないのであれば、自然と1つのチームにしか登録できないよね。
キャラクターは他のユーザーのチームに参加できない、という要件を勝手に想定してないか？

>>320
一つ目ってそうなりますか？
キャラクターが、同じテーブル内のレコードで他に存在してはいけない
という制約があるので
「プレイヤー1の1番目のチームの1番目のキャラクターはこれだけだ！」と、特定できる、かつ他のチームにそのキャラクターはいない

となると思ったんですが

>>322
すいません、書き忘れです・・

あ、よくみたらそう書いてあったわ
無かった事にしてくれ

個人的には有る程度ゆるく作っとかんと、テーブルレイアウト変えるのは大変
アプリ修正の方が工数が軽いから、チェック類はアプリでやる方が良い場合が多い
と思う

>>311,312
まず>>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とは
作図法(=表現方法)が異なるだけで、意味的に同じものになる

>>323
> キャラクターが、同じテーブル内のレコードで他に存在してはいけない
という制約があるので

テーブルにそういう制約があるなら、>>311-312で明記しる
要件とデータ定義をごっちゃにすんな

システムに使われるデータフローというのは全てデータベースのリレーションで管理するものだと思ってたら、
DBを扱うアプリケーション側で制限するのも大丈夫なんですね
業務で使ったことないので勉強になります

>>327
すいません、その後のレスの流れを組んでいただけたのかと思って紛らわしいこと言ってしまいました

>>328
話の発端が分かるよう名前欄に298と入力しとけ
鳥頭の相手をするのも疲れるだろ

>>326
この画像の右下のチーム編成は、
そのチーム内での順番の一意制というのは保証されない？

>>329
すいません

えーと、

プレイヤーテーブル
*プレイヤーID
プレイヤーネーム

チームテーブル
*チームID
プレイヤーID

チーム編成テーブル
*チームID
*順番
キャラクターID(ユニーク)

キャラクターテーブル
*キャラクターID
プレイヤーID

というので第三正規化まで綺麗に出来てるでしょうか？
順番の8つまで、という制限は無理そうですが。

>>330
チーム内での順序の一意性が必要であれば、
(チームID, 番号) というペアに対して一意性制約をかける

>>332
いいんじゃないかな
チームは8人までという制約がどうしても欲しければ
ユーザー定義関数を制約に指定したりトリガーで確認して例外を投げるとかいろいろ考えられるけど、
この辺りはDBMSの実装に依存するんで設計とは別の話になるかな

>>328
いやあ、十分分かるよ。
キャラクターはゲーム中でユニークな存在である、プレイヤーはチームを一つしか持たない、
チームには同一キャラクターを登録できない。
これを総合すれば、チームテーブル全体において、キャラクターがユニークになるのは明白だからね。
これが分からないって言ってる人は少なくとも>>328よりも設計に関する理解度が低いから安心してスルーしていいよ。

>>332
順番の値の範囲が1-8(もしくは0-7)であるような制約を課せばいいよ。
同様に、プレイヤーあたりのチーム数制限もかけられるんだけど、その場合はそのチームテーブルだとちょっと面倒になるね。
*プレイヤーID
*チーム番号
チームID
として、チーム番号に制約をかければ素直にいける。

レイアウトの好みと、制約の容易さは天秤にかけられるもの。

ありがとうございます。
大変勉強になりました！

>>329
俺は要件とデータ定義をごっちゃにすんなっつってんの

>>311-312のデータ定義で要件>>298が満たせるか、って突っ込んでんのに
「要件に書いたから分かるだろ」
じゃいかんだろ、ってこと

>>326
複数チーム構成でチームと言うエンティティが必要なのはわかるんだが
単一チームであってもチームと言うエンティティがある方が自然な気がするんだが
複数か単一かの違いは、チームとプレイヤーのリレーションの基数の問題じゃないか？

俺もそう思うよ。

ゲーム開発者が理解に苦しむような制約のあるゲームを、ゲーム利用者がプレイして素朴に楽しめるのだろうか。

どの制約が理解に苦しむものなの？

>>339
そう、基数が１で固定のケースが単一チームと考えることもできる

ただしその場合には、チームとプレイヤーという対象物(サブジェクト)は
「必ず」１対１に対応するから、概念モデル(ERモデル)として設計する時には、
どちらか一つを選んでエンティティとして具体化するのが普通じゃないかと思う
別の言い方をすれば、はじめから要求仕様で単体チームと明確になっているのなら、
単体チームとして最適な、最も単純な解を選ぶべきだと考える
（Simple is best とか オッカムの剃刀 みたいな言葉があるよね！）

こうした考え方を元に、プレーヤーをエンティティとして選びチームを捨てるという
判断を下した >>298 の論理設計図が、(単体チーム向けとして)最適解であると考えた

>>343
「必ず」1対1の対応をするんだから分ける必要はない、つまり第三正規形なんていらないってことだよね。
わかるわかる。

>>344
そういった推論になってしまうのは、
第三正規形の定義を「正しく」理解していないからだろね

>>343
チームとプレイヤーとは一般的な考えでは異なる概念だから
一つのエンティティとするのはかえってその概念モデルの理解を妨げる気がする

省略できるものすべてを省略するのが必ずしもわかりやすいという事にはならんよ

>>346
わかりやすいとは、一言も言っていないけどな

　与えられた問題に対して必要十分かつ最も簡潔な解を選ぶ

ことが望ましい、という意見だよ

>>345
うん。この場合は問題ないね。
もともと第三正規形になっていた。

ところで、>>300
> 少なくとも第１／２正規化は満たしている
これも、少なくともという言葉で濁すのかな。

>>300って前スレあたりで第二正規形を理解してなかった人じゃないの？
で、勉強が終わったからその発言になったんじゃないかな。

今回突っ込みを入れられて第三正規形を勉強したんでしょう。
知ったかぶりの成長が見て取れる良スレ。

そもそも>>298の問題は正規化できていないことでなく、要件が筋が悪いし整理もできていないことだろう

要件をそのまま定義に落とし込むならチーム編成テーブル自体なくていい
●キャラクタテーブルに順番カラムを追加しnullならチーム未所属扱いにする
●その上で{キャラクターID, 順番}の組でユニーク制約を持たせる
　※nullがユニーク制約の対象になるDBMSもある点には注意
などとすれば>>298に書かれた要件は満たせる

ただ「やっぱりチーム編成は複数持ちたい」的な話が出る可能性は高い
>>298にユニーク制約を加えたりアプリ側でチェックするべきという回答が出たのも、それを見据えたものと思う

★マインドコントロールの手法★

・沢山の人が偏った意見を一貫して支持する
　偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
　誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法


↑マスコミや、カルトのネット工作員がやっていること

TVなどが、偏った思想や考え方に染まっているフリや常識が通じないフリをする人間をよく出演させるのは、
カルトよりキチガイに見える人たちを作ることで批判の矛先をカルトから逸らすことが目的。

リアルでもネットでも、偽装左翼は自分たちの主張に正当性がないことを自覚しているのでまともに議論をしようとしないのが特徴。
.........

>>351
これが貼られるタイミングが前スレあたりから興味深い。
やっぱ強制ID必要だわ。

>>350
あるチームに所属するキャラクターを未所属(どこのチームにも
所属していない状態)へ変更するには、どのように操作するの？

SQLのUPDATE文では、あるカラムが有効値である時に
それをNULL値へ更新できないと思うんだけど....

>>353
update aaa set bbb = null;

>>300
> SQLのUPDATE文では、あるカラムが有効値である時に
> それをNULL値へ更新できないと思うんだけど....

何をどうがんばっても擁護できないんだけど。
update で値をNULLにできないっていってるよね？

あ、まてよ、oracle信者の可能性があるか？

>>354
レスありがと
UPDATE文の右辺式にNULLが書けるとは知らなかった

>>350訂正
> ●その上で{キャラクターID, 順番}の組でユニーク制約を持たせる
{所有プレイヤーID, 順番}の組、と書いたつもりだった、お恥ずかしい

>>357
NULLは式でも値でもない
右辺にかけるのは、（スカラー）式かDEFAULTかNULLって決まってる

つか、今までNULLに更新した事ないのか？
どういう立場でDB使ってるんだ？

>>356
ORACLEはNULLとヌルストリングを区別できないだけで
いくらなんでもUPDATEでNULLにするのは出来るだろ

>>359
ちょっと上のゲーム絡みの書き込み見れば、
このスレのレベルはわかるだろ。

まともな人もいるよ。
一部のレベルの低い人がドヤ顔で語ってるからおかしなことになってるだけ。
さすがにその流れでNULLへ更新できないなんて言いだすとは思わなかったけどな。

ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。
ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。ひんがら目気色悪すぎこっち見んな死ね。

狭い範囲にしか影響が出ない場合や、
または、区分しにくいコードに関しても、ソースコードに
直接書き込むのはNG？うちのシステムコード書きまくってます。

リテラルをプログラム中に書きまくるって話？それはプログラミングの話であって設計の話ではないのでは？

>>364
○○コードみたいなやつを条件文に直接書くってこと。そういうのって全て区分にしてDB化しなきゃいけないの?

変動しない性別テーブルなんて要らん

ある製品を作る
生産システムにおいて
ある工程のみ特殊な処理をしたい。
しかし、pgに行程コードを書くのがngであるなら、
工程マスターに新規区分フィールドを追加することになるが、
その工程を判別するためだけにdb変更がありなのかってこと

その情報をデータとして永続化する必要がないならDBに持たなくて良いんじゃない

画面に表示するメッセージの文面や色、ダイアログのサイズやタイトル、
そういったものまでDBに格納した結果、マスターから1レコード取ってくるだけの処理で
50個とか60個とかSQLが投げられているシステムの事を思い出した

>>367
その条件に別の行程を追加するとき、PGに工程コードを追加するのか、
それともDBに区分フィールドを追加して該当する行程に１を立てるのか？
ポイントは、その条件が、ほかのシステムでも使われうるものなのかどうかということ。
その工程だけ１が立っていてほか全部ゼロのようなものは、
たいてい、狭い範囲でしか使われていない。そんなものは、
PGに持てばいい話。といいたいところだが、ほかの方はどうされているのか知りたい。
どんなケースであれ、直でコードを書くのを避けているのかどうか。

http://blog.livedoor.jp/itsoku/archives/ubuntu-install-virtualbox.html

>>370
生産で行う処理が特殊であれ通常であれ、
生産管理システムから見たら同じ処理でしょう
何を迷う事があるんですか

>>370
将来にわたって参照・変更することがないならプログラムに書くかな

>>370
見解ありがとうございました

>>370
> ポイントは、その条件が、ほかのシステムでも使われうるものなのかどうかということ。
そんなの関係ないよ。

ポイントなのは、
* 対象となる工程が変わりうるのか
* 対象となる工程が多いのか少ないのか

今、工程1〜工程100まで工程マスターに登録されてるとして、
「工程4のみ特別な処理をする」という要件があったとき、コードで
if (record.process_id == 'proc4') {
}
みたいなコードで十分なのか、
if (record.is_special_process) {
}
とした方が良いのかという違い。

対象となる工程が変わりうるのなら、データベースにis_special_processカラムを追加するか、
別テーブルを追加すべき。table special_processes (process_id) みたいな。

また、対象となる工程が多い場合も、同様にするのがいい。

対象となる工程が少なく、また今後変わる予定も無い場合に限って、プログラムに埋め込んでも良い。

>>375
対象の工程にフォーカスした場合はそうなるだろうけど
>>370を否定する理由にはならんな

それとも対象の工程だけで考えるべきであり
その場限りの特殊な処理だろうがDBに入れるべきといってるのだろうか

>>375
そのプログラム（システム）以外のところで、特別な処理をする工程を知りたいとなったらどうする？
たとえどんなに対象が少なくて今後変わる予定がなくても、他のシステムでその工程を知りたいなら
プログラム中に埋め込むべきではないだろ

>>368の、データとして永続化する必要
>>370の、ほかのシステムでも使われうるもの
>>373の、参照
これらはすべてそう言う意味だと思うけど

よくありがちなのは特殊と言いつつ、特殊な処理が実はいくつもあったりして、全然特殊じゃなかったりすること。

> そのプログラム（システム）以外のところで、特別な処理をする工程を知りたいとなったらどうする？

それが同一サーバ内のシステムなら、外部設定ファイルに情報を持たせる手も一応はある
あんまりお勧めはできないけど、DB側に情報を持たせられない・持たせたくない事情があるなら

品質管理上、その特殊な処理が入った成果物のロットを明確にしないといけないとか、特殊な処理がいつから導入されていつ終了になったのかとか、後々に問題にならないようなものならいいが。

特殊な処理を例外扱いしないために、
生産(管理)システムを導入するということもあるかと。

>>377
> そのプログラム（システム）以外のところで、特別な処理をする工程を知りたいとなったらどうする？
そうなったら、そうなったときに考えればいいこと。
無限の拡張性を担保して開発することなんかできない。

あるシステムの外部からそのシステムが知っている情報を取得するとき、普通はAPI経由にすると思うけど。
一つのデータベースインスタンスを複数のシステムが共有するのは、最初からそういう前提になって無い場合はほとんどしないんじゃないかな。

>>380
> 品質管理上、その特殊な処理が入った成果物のロットを明確にしないといけないとか、特殊な処理がいつから導入されていつ終了になったのかとか、後々に問題にならないようなものならいいが。

それと、工程コードをハードコーディングしていいかどうかに、何の関連が？

>>384
ハードコーディングするぐらいだから記録もあんまり考えてないのかなと思って。関係ないならすまん。

まあ、この処理は他と比べて特別であるという判断を、誰がどんな根拠でするのかなあ、とは思う、生産システムの例なのでそこは結構気にした方がいいと思うが。

まずは、その特別な処理をカイゼンすることが先じゃないかな

なんでもかんでもDBの区分化したら、
PGが変更されて使わないフィールドが出てきて
あとからなんだこれ？よくわからんが、とりあえず
とっておくか的なゴミフィールドが出てこないか？

実際のDB構造・ER図を見れて参考に出来るサイトをご存じでしたら、教えて頂けませんでしょうか
例えばeccubeのERは少し参考になりました

>>386
モノの生産となると、どうしても外せない特別な工程が出る事もある

>>387
運用次第、水は低きに流れる

>>363,367はアプリケーションの振る舞いを
データベースで制御したいの？したくないの？
その答えだけで決まる話だと思うんですけど

>>391
したいかしたくないかわからないから、普通はどうやんのってのが知りたいんじゃ？

>>392
普通はしたいかしたくないか(必要があるかないか)決めてそれに合わせて考えます
それが設計ってもんですよ

>>392
何をしたいのか判らないものは答えようがないじゃないすかね
どうでもいいけど日本人は普通という単語が好きだよねって話思い出した

>>393
> 普通はしたいかしたくないか(必要があるかないか)決めてそれに合わせて考えます

必要があるのかないのか自分では判断できないから聞いてるんだろ

設計には要件定義ってフェーズが有ってね
自分で判断できないときは、判断できる人に決めてもらうんですよ

ハードコーディングするかどうかは、実装詳細だろ

ていうか、この質問ってDB設計に関係あるんですかね。

「DB設計とは何か？」や「DB設計におけるよくある勘違い」という意味では、
まったく関連が無いとは言えないこともない

・postgres 1.81

・http://eow.alc.co.jp/search?q=sort&ref=sa

このような辞書を作りたいのですが、カラムはどのようにわければいいでしょうか？
また、例文は例文で別にストックして表示する形がベストでしょうか？

よろしくお願いします

単語、意味
単語、用例
この二つのテーブルがあれば足りるんじゃ？

あとは、実際に使う上で便宜があるように項目を追加・分離

http://f.xup.cc/xup0ouojxbn.jpg
http://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

Tweetを恣意的にまとめて時系列順で読ませるようなものを作りたいのですが

tweetsテーブル
id
tweet_text
tweet_date

tweet_groupテーブル
id

tweet_group_associationテーブル
tweet_id
tweet_group_id


こんなテーブル設計でいいのでしょうか？
tweet_groupテーブルがほぼ空(強いて言えば名前や読まれた回数ぐらいはつけられるようにするかも)なのが気になるのですが
もっとすっきりとした設計は可能ですか？

何をしたいのか全く分からんが、tweet_groupの価値も分からんね

>>403
・tweet_groupというのが「Tweetを恣意的にまとめ」たもの(=エンティティ)であり、
・あるTweetが複数のグループに所属することを(>>403が)想定している
のであれば、DB設計における最初の出発点としては
そんな感じでいいんじゃないかと

Twitterの特定のツィートをまとめたいのですが、
データベース的にどんな風に作ればいいのかってことです。
まとめる方法は完全に手動です。

まとめ(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 |

こんな風にしたほうがいいのでしょうか？

>>405
ありがとうございます。
とりあえずこれで行ってみます

>>406
>Twitterの特定のツィートをまとめたいのですが、
>データベース的にどんな風に作ればいいのかってことです。

アプリケーションの設計は、大きく「何を作るか」という機能設計と
「どうやって作るか」という実装設計の２つに分類され、
一般には定義した機能(の仕様)を元にして実装方法が決まる
言い換えると、「どうまとめるか」という機能が決まらずに実装が決まることはないし、
「どんな風に作れば」という実装を元に「どうまとめるか」という機能を
検討しようとする試みは、本末転倒だよ

で、ツイートのまとめかたという機能(の仕様)は>>403自身しか知らないし、
それは>>403のアイデアで勝負すべき事柄であり、
もし相談するのならここではなくSNS関連の板が該当する

遠回しな言い方になったけど、あるツイートの集合について、互いに交わらない
部分集合へ分割するのであれば、DBの実装設計としては
>>406の「１対n」方式を選択することになるし、
交わりを許すのであれば>>403の「m対n」方式を選択することになる
で、繰り返しになるけど、その判断は>>403が下すしかない
もしも現時点で機能仕様が決められないなら、個人的には単純な「１対n」を勧める

交わる前提で設計したほうがいいと思うけどな。
異なる観点でまとめることができないなんてことになるし。

>>408
> もしも現時点で機能仕様が決められないなら、個人的には単純な「１対n」を勧める

現時点で決められないのであれば、n:mにするでしょ。
別にそれで特別設計が複雑になるわけではないし、1:nも実現できるし。

いつものあの人でしょ。
経験で学んだらしいが、毎度逆を行くのはどういう経験をつんだらそうなるのか不思議でならない

まあ、ある程度経験のある人間ならn:mで設計しとけばいいんだけど
ここに聞きに来てるような段階のひとなら、なるべく単純な形からやっとけってのは一理あるとはおもう

単純にいくならtweetsテーブルにグループの名前なりIDなりの項目作れば良いんだけどね

>>406って>>403からtweet_groupを取り除いただけだよね
なんで1:nだの言い出したのか判らないな

もともと
> まとめ(groupとします)とツィートは*対*の関係です。
って書いてんのに1:n にしろとかいうのは根本から間違えてるもんね。

車が欲しいんですけど、オススメの車はありますか？→お前に車なんていらない。自転車乗ってればいいんだ。
みたいなイカレ具合だよこれは。

ディーラーは務まらんだろうが、そうでなければ然程不思議な意見でもないな。

何のために車が欲しいのか書いて無ければ自転車も車だ

座席（映画館とかの予約）の管理にDBを使いたいのですが、
どのように設計すればよいかアドバイスをお願いしますm(_ _)m
（当方初心者です）

複数の部屋に座席が多数並んでいるとします。
その座席の空き情報を調べたり、誰が予約しているのかの情報を
管理したいです。

予約時に部屋のマップから座席を指定したいのですが、内部で
キーをどのように持つべきかわかりません。

現在は以下のようなレコードになっています。

座席番号(連番)[key],部屋番号,座席の行番号,座席の列番号,予約者ID

予約したり、位置を特定するのに、毎度、座席位置と座席番号を
変換しているので、この変換なしに部屋番号,座席の行番号,座席の列番号
の一組でキーに設定できないでしょうか？

ご助言、よろしくお願いします。

>>417
まず、座席情報と予約情報は別テーブルにした方がいい。
予約業務は、実際は時刻情報等が必要なのでは？

> 変換しているので、この変換なしに部屋番号,座席の行番号,座席の列番号
の一組でキーに設定できないでしょうか？

「キー」が何を指しているのかわからないけど、なぜ「キー」に設定したいと思ってるの？

>>417
座席位置は、マップで表示する際に必要
マップから座席を選んだときは座席番号さえあればデータは登録可能でしょう。

>>417
部屋番号,座席の行番号,座席の列番号
以上3つがナチュラルキーのようだから、それらを複合主キーにして
座席番号(連番)
を削除すれば>>417の希望は満たせるけど…

上映日時的なカラムがないのが気になるし「座席番号(連番)」が他のテーブルに使われてないかも気がかり

座席番号って、そういうことか。>>419は忘れてください。

>>418の時刻情報と、>>420でいいと思う。

「4人並びの席」とかの指定がうまくできるのかな？

>>422
映画館程度の規模でマップから選ぶなら、見た目で判断できるからいいんじゃないかな。
要件的には問題ないというか。

みなさん、アドバイスありがとうございます。m(_ _)m

上映時間ごとにテーブルを作っています・・・。
初設計なので、常識を軽々とスルーしているようですね。orz

これから座席のメンテナンス情報（汚れ、故障、等々）を
追加したいと考えているのですが、

部屋番号,座席の行番号,座席の列番号 →座席番号(連番)取得
座席番号→メンテナンス情報取得

の二段階を

部屋番号,座席の行番号,座席の列番号 →メンテナンス情報

にしたいと考えています。

複合主キーという存在を知らなかったので、こういう場合
みなさんはどのように処理しているのか教えて頂きたかったのです。

> 4人並びの席

そのあたりはプログラム側で処理して、DBには同一の予約者IDを
書き込んでいます・・・。

>>424
俺の質問は無視か・・・

てか、JOINは知ってるのか？

> 上映時間ごとにテーブルを作っています・・・。

それは、ある映画館に3部屋あって、それぞれの部屋で毎日4回上映する場合、
毎日12回のCREATE TABLEをやってるという意味か？

まあ部屋情報の上に館情報もあったほうがいいけどな
座席は行と列、アイルの情報があるし、欠番の席もあるから
固定の座席テーブルから、売り出し用のテーブルにidのみ転記、そっちで
独自にidをつけて予約、発券に使うのがよさそうな。

俺の勘だが、まずこれ読んだほうが話が早いと思うぞ。

『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』
http://www.amazon.co.jp/dp/4798124702

『達人に学ぶ SQL徹底指南書』
http://www.amazon.co.jp/dp/4798115169

>>425
すみません、見落としてしまいました。

> 予約業務は、実際は時刻情報等が必要なのでは？

一日の上映回数は決まっているので、その時刻ごとに
テーブルを作ってました

> なぜ「キー」に設定したいと思ってるの？

座席番号はDB上にのみ存在していて、データを一意に識別するときには
必ず部屋番号、列、行番号を使っているので、それを直接キーにしたいと
思いました。

＊キーによるレコード選択はO(1)で、条件文を使った選択は
O(n) or O(log N) のように処理に時間がかかるのではないかと勝手に
思っています。

> JOINは知ってるのか？

知りません・・・

> 毎日12回のCREATE TABLEをやってるという意味か？

はい・・・

>>426

今は一館だけですが、将来的には必要になるかもしれません。

> 固定の座席テーブルから、売り出し用のテーブルにidのみ転記、そっちで
> 独自にidをつけて予約、発券に使うのがよさそうな。

なるほど。メンテナンス情報はそういう風にできるか検討してみます。

>>427

自分でも現状の知識ではかなり無理があると思っています。 orz
とりあえずご紹介いただいた本を読んでみます。

>> JOINは知ってるのか？
>知りません・・・

おーい w せめてせめて基本的なことぐらい知ってからにしようよ

課題ならいいけど、業務だったら怖え。

会議室予約とか、貸出予約とかのサンプルどっかに転がってないか
それみて応用すればいいんじゃね

多分なまじっかコードが書けるんで、DB設計は壊滅的なのにシステム全体では一応動くものが作れちゃうパターンだな

そもそもDBMSとは何ぞやというレベルから勉強して設計を1からやり直さないと、にっちもさっちも行かなくなりそう

だれもが通る道。早いうちに痛い目あった方が後々よい

て言うか、今はどうやってるのよ？
メンテ情報とか、連座の扱いとか、VIP 席とか身障者の方の席とかの対応とか、まず何をしたいかを決めた方がいいと思うよ。

学校の宿題か情報処理の自習問題だろ

そうであることを切に祈る

JOINってもう使わないな

　 　 ／￣￣ヽ　 ┏┓
　　 / (●) ..(●　┏┛
　　 |　　 'ｰ=‐' i 　・
　 　 > 　　　　く
　＿/　,／⌒)､,ヽ＿
　　 ヽ､_／~ヽ､__）　 ＼

あなたはまだJOINを使っている人？

RDBやめたか

NHK質問操縦状回答問題

NHK質問操縦状回答問題

NHK質問操縦状回答問題

NoSQLの感想をどうぞ

カテゴリなど複数登録があるテーブルで
デフォルト（初期状態）示すカラム名って、何が適切ですかね？
default　で良いですかね？

カテゴリが何も設定されてない状態がデフォルトなんじゃないの？
それとも内容ごとに初期値が存在しうるのかな。

>>444
例えば学校の部活をカテゴリとして、
「野球部、サッカー部、写真部」に所属しているとします。
その場合、メインの部活は野球部であり、他は違うよ
っといった見せ方をしたのです。

要は複数カテゴリからメインのカテゴリ、メインじゃないカテゴリを
指定できて、後に変更できるといった仕様です。

>>445
primaryとかつけたいところ

メインフラグじゃだめかな

そのものズバリで MainCategory じゃダメなのか？

>>448
ユーザーが選択するテーブルを2つに分けろということですか？
確かに正規化されている気はしますが、どうなんですかね・・・

#category
id｜name｜sort

#main_category
id｜category_id｜user_id

#sub_category
id｜category_id｜user_id

ちなみに自分は↓こんな感じのテーブル構成を考えており、
defaultの部分がメインフラグ扱いなのですが、
カラム名は違うほうがいいのではないか？と思い、質問しています。

#user_category
id｜category_id｜user_id｜default

>>450
そのdefaultというカラム名を
primary
main_flag
main_category
とかにしたらって返信だと思うよ

ただ、primaryとdefaultはSQLで利用される言葉だから避けることをオススメするよ
primaryはprimary_flagにするとかな

defaultは意味が違うんじゃないかな？
入力等がないときに使われるあらかじめ用意しておく値って意味だからね

そもそもの設計に疑問があるんだけど

・ユーザテーブル
ユーザID, …

・ユーザ/カテゴリ中間テーブル
ユーザID, カテゴリID, メインカテゴリフラグ, …

みたいにテーブルを分けた方が良くない？

ごめん、リロードしてなかった

>>451
なるほど。分かりやすく説明していただきありがとうございます。
とりあえず、defaultは駄目かな？と疑問に思ってたので、
教えていただき助かりました。main_flagかmain_categoryにします。

簡易的なブログを運営しています
投稿タイトルや日時、本文をpostsテーブルに持たせて
投稿カテゴリーについてはcategoriesテーブルに持たせて外部キーpost_idで結んでいます

質問なのですが、複数のブログを運営する場合にはテーブル設計はどうするのがいいでしょうか
新たにblogsテーブルを作成し、blog_idをpostsテーブル、categoriesテーブルに持たせたらいいんでしょうか
それともブログごとにテーブルを作るのがいいんでしょうか
うまいやり方があれば教えていただきたいです
よろしくお願いします

>>455
wordpressが別テーブルにしてるところから判断すると別テーブルが正解。

別テーブルにしておくと、ブログの追加、削除が簡単。

その複数のブログとやらが、どの程度の関連性をもつのか考えんことには何とも言えん
個人的には別テーブルは無いんじゃないかな
別ＤＢにするか、単一テーブルでブログＩＤとかサイトＩＤとか持つか、どっちかじゃない？

ああ、捕捉しとくけど、別ＤＢって考え方はDBMSによって微妙に変わる
別インスタンスだったり、別スキーマだったり
つまり、同一テーブル名称だけど別のものってことね
少なくとも別テーブル名で同じテーブルデータ持つのはないだろって話

WordPressってサイトテーブルにレコードを追加して
そのサイトIDを含んだテーブル群を別途作成するのか
こんなのメンテナンスしたくないぜ

メンテナンスしたくない気持ち半分、メンテしやすいと思う気持ち半分。
管理ツールがちゃんとしてれば後者。

別スキーマのほうがもっとよかった。

ブログごとにテーブルって事は、データ増えるたびにテーブル作れって意見と同じじゃないか

少なくともプログラムでまずテーブル名取得してからSQL組み立てとかやりたくねぇ

不特定多数にブログを開設させるようなのでない限りは
スキーマ方式が良いと思う
wordpressみたいな方式はパス

テーブルを作るのはよくないようですね
DBを分ける方式を採用することにしました
ありがとうございました

そんでDBリンクとか使い出しちゃうんだろうな

>>463
スキーマ単位だろうがテーブル単位だろうが
やってる事は同じコピペなんだよね
> 新たにblogsテーブルを作成し、blog_idをpostsテーブル、categoriesテーブルに持たせたらいいんでしょうか
工数が取れないとかじゃない限りこっちが無難よ

◎2chスレッド勢いランキングサイトリスト◎

★+ニュース板
・ 2NN (推奨サイト)
・ 2chTimes
★+ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★+ニュース板その他
・ Desktop2ch
・ 記者別一覧
★全板
・ 全板縦断勢いランキング (推奨サイト)
・ スレッドランキング総合ランキング
・ ログ速
★全板実況込み
・ 2勢 (推奨サイト)
・ READ2CH
・ i-ikioi

※ 要タイトル検索
※ 2chブラウザ併用推奨

>>455
複数ブログに共通の記事があるのなら同一テーブル。
そうでないなら別テーブル？

運用中にCREATE TABLEやらDROP TABLEが出てくるのはどーもなー
同じカラムならまとめりゃいいじゃん

>>468
妙なこだわり持ってるね

明らかに設計ミスだからな

運用中にCREATE TABLEなんて普通にやってることだから気にならない

プログラムが自動でテーブル作りまくるのか
管理ツールでもないのに

DB慣れてないとどうしてもそうなるのはしょうがない。

分割とかしてたら普通だろ

その規模までいってないだけか

オレオレ原理主義の人来てるな

要件次第だよ

結論としては、運用を想像できない素人達が無知を晒したでFA？

構成管理とか統計情報取得とかをしないんなら、別にいいんじゃないのかな

モノによっちゃ、しないしな

Ruby on Railとか使ってると、宗教戦争になっちゃうんだけど。

俺は業務にあった、DB設計にすべきだと思うんだけど、
Railsだとこうだからといって、無駄な外部キーを増やしたがる。

業務を遂行するために選んだフレームワークで使いやすい形にするのは、業務にあったDB設計にあらずってこと？

なんかもぞもぞする言い回しなんだけど、単にRoR嫌いって言いたいだけなのかな。

いるんだよね
理想を追い求めてフレームワークから脱線したがる人

俺も反論するレス書こうとして何回も見てたら

他のフレームワークでこういう設計だからと言う理由で
（フレームワーク使いもしないのに）本来の設計を捻じ曲げるやつがいる

という主張じゃないかと思い始めた

> （フレームワーク使いもしないのに）
あぁー。そこまでは気が回らなかったです。それなら納得。

>>478
それは使っている(使えている)とは言えないのでは…

>>476
ないわぁ

要件次第

１時から２時の間に太郎君が学校で死にました
という文があるじゃないですか。
これみたいな沢山の文をデータベースにしたいんですけど
どうゆう構造で保存したらいいとかが分かる本教えてください。
これから太郎君は３時に死んでいるかとか、
太郎くんが１時から２時の間にどこにいるかを
調べられるようにしたいです。

例文が物騒だなw

ミステリーの謎解きか設定考えるのに使うんかねｗ

RDBよりPrologとかの出番かも

ミステリの粗探しなら、Excelに
「いつ」「だれが」「どこで」「何をした」
をダラダラ入力して、並べ替え・オートフィルタでよくね？

まぁ、その項目をカラムにすればいいと思うんだけどね。

自然言語の解析やりたいって話の気もするけど
それに応じたデータベースってのは有るんだろうけど、それ用の所で聞いてくれって感じだな

やりたいことは>>489だと思うしDBに落とし込む価値も有りそうだけど、もう少し要件の説明が欲しいな

参考書に関しては、まず適当な入門書でも買ってRDBMSの基礎を学んでみるところからかな
基礎知識がついたら試しに要件と自分の考えた設計をここに晒してみるといいと思う

住人にRDBMSを扱ってる人間が多いとは思うが、別にRDBMSに閉じたスレでもなかろう

つっても、たとえば全文検索の考え方なら実現できそうかどうか、みたいなのは
俺には分からんが
とはいえプリプロセッシングとしての、自然言語解析がキモっぽい気もする

>>493
そもそもスレタイ的にはまずDB設計ありきだし、>>485のやりたいことも
小説をそのまま読み込ませて話を時系列に並べさせたいとかではなくて
「いつ誰がどこでどうした」
というのを手入力して、人物や場所別に出来事を時系列順に並べたい、とかいうもののような気がする

小説丸々食わす方向も面白そうだけど

id 名前　趣味

上のようなテーブルがあって、趣味の値は複数あります。
こういうときはどんなデータ構造にすればいいのでしょうか？

趣味テーブル作るのはださいと思うので、
他の方法を教えてください

IDテーブル(ID, 名前)
趣味テーブル(ID, 趣味1, 趣味2, &#8226;&#8226;&#8226;)

やっぱ

1 山田　[野球][音楽]
こういうＤＢがスマートそうですね

SQL99で定義されてる配列型でも使えば

でもなんか列数増えるの嫌だわ

>>495
ダサい格好いいといった感覚論でなく、具体的に正規化を崩すメリット・デメリットを自分で挙げてみれ
アプリ側の仕様によってはDB側の正規化を崩すメリットが勝るケースもあるが、そのケースに該当するか？

>>495
趣味の正規化というか分類をどうする？

>>495
そのまま

id 名前　趣味
----------------
1　鈴木　野球
1　鈴木　ホッケー
2　田中　野球
2　田中　剣道

って入れていくのが今時のDBっぽいよ

だったらいっそidもいらんだろ
なんのidかは知らんが

タグ管理とかだと、マスタ化しないこともあるね。
趣味をどういう風に扱いたいか次第だなぁ。

特に理由がないなら、ここにいる人たちは口をそろえて正規化しろって言って終わる話。

ユーザIDにしか見えないけど、なんで名前持ってんだろ
今時は難しいなぁ

サロゲートキーがついてるほうがマシだった

マイナンバー実装はよ

495 です。

ゲームを作っていて、あらゆる属性で効力など絞り込みたいです。


趣味はアイデンティティの一つであり、
名前などと同じように扱うべきです。
そういった観点からいうと、
役割の同じものを別テーブルに書き出すのは間違ってると思いますし、
正規化とは言えないと思います。
規格化と言うべきではないでしょうか。

ということで、タグ管理がイメージに近いと思いました。

こういった感じでしょうか？
id 属性　値
1　名前　鈴木
1　仕事　野球
1　仕事　俳優
1　ポジション ライト
1　打順　１番

更には、野球クラスのサブ属性といったものも同じレベルで扱いたいです。

森羅万象テーブルとかいう話があったの思い出した

>>508
いっそNoSQLの方向に進む方が幸せになれるかもね

そのidってなんなんだろうな。その属性のいずれとも1対1の関係にないものなんだろうし。

1というものがなんなのか判別するために
アイデンティテイがあると思うんだけど

クイズみたいなもんだよ、
人物１を当ててください。
ヒント
打順は１番、ポジションはライト、野球選手

こういうことを言ってるんじゃなくて？？

>>508
主張の内容はよく理解できないけど、確固たるポリシーがあるならそれに従ってやればいいんじゃね？

流石に釣り針が太すぎて、あんまり絡む気が起きんな

>>511
{id,属性}の複合キーといったところだろう
table名を森羅万象とすると、これで鈴木の諸々のデータが取れる寸法

SELECT * FROM 森羅万象 WHERE id IN
(SELECT id FROM 森羅万象 WHERE 属性 = '名前' AND 値 = '鈴木')

森羅万象テーブルのメリットデメリットは各々考えてくれ
ネタでなくこういう設計やる奴もいるのがなんとも…

って同id同属性のレコードもあるのか

あ、欠陥があった
属性オブジェクトを識別するもの入れてなかった。

idとは（これでは属オブジェクトハッシュコード）
select * from 従属オブジェクト = 1　で得られる結果と
同じ属性プロパティを持ったオブジェクトです

属性ハッシュコード　 属性　値 従属オブジェクトハッシュコード
1　名前　鈴木 1
2　仕事　野球 1
3　仕事　俳優 1
4　ポジション ライト 1
5　打順　１番 1

欠陥があるとすれば君の発想の根本に欠陥があるんだよ、というながれ。

値以外は、実態がオブジェクトで格納されているということです。

いや、違かった

属性オブジェクトは
自分自身のハッシュコード、自分自身の属性の名前、自分自身の値、元のオブジェクトを
データベース上では返すということです

格納する属性をユーザーに決めさせるようなシステムならこういう設計もありだわな
例えば Trac (BTS) のカスタムチケットとかで使われてるよ

ありと言ってもらえて自信つきました。
ちょっとこれでやってみます。

でもそうとは思えないんだよね。
実際にどういうデータを入れようとしているのか。
ゲームの属性や効力について、悪く言えばまとまりのない、良く言えば自由度の高い構成にする理由が思いつかん。

RPGツクールみたいなものを作ろうとしてるとしても、属性マスタを作ったほうがいいと思うんだが。
ユニーク属性ばかりにするつもりなんだろうか。

うおー。時間が二進数や。

趣味と名前がホントに（属性という）同一の扱いでいいならアリだろうけど
>野球クラスのサブ属性といったものも同じレベルで扱いたいです
「サブ」属性なのに同じレベルで扱うのはおかしくないか？
サブ属性とメイン属性は何がどう違うのか表現できなければ、サブとメインの区別が無いのと同じだぞ

作るのはカードゲームです。
今回考えたデータベースを扱うのは、エディターでなくゲームで使います。

マスタは作りません。全てオブジェクトで管理します。

サブの利用頻度は少ないと思いますが、
野球選手のモテ度を５アップとか、
打順一番の打者は先頭打者ホームランを打ちますとか
そういった魔法も作るかもしれないので。

もちろん、デッキエディターなんかは
従来の構造で十分なのでそれで作ります。

ソシャゲのカードゲームにおける、アビリティのようなものを想像するのは間違いってことでいいんだよね。

名前とかHPとか基本的な(どのモンスターでも大体持つ)属性は
きちんとカラムに持たせたり、それがジョブみたいに複数あるものなら
関連テーブルを持たせたりと、RDBの王道を行く方がよい

その設計では、HPがなかったり複数あったり「HP:田中」だったり
間違えてHPじゃなくてHDを持ってたりと滅茶苦茶できるから
アプリ側で登録更新削除時の整合性チェック、及び検索時の異常データに
対する例外処理を手厚くする必要が出てきて、面倒なことこの上ない
DB管理上もデータの見通しが悪すぎるし

特定のモンスターしか持たない特殊パラメータだけ例外的に
・モンスターテーブル
・特殊パラメータテーブル
・上2つの関連テーブル
みたいな形で持たせるのはアリだと思うけどね

いっぱい指摘されてるように典型的なEAVパターンじゃないか。
RDBのアンチパターンまっしぐらよりは、
MongoDBとか使った方が幸せになれるんじゃないかね。

>>525
追加要素の多いカードバトル物のパターンだね

例に挙げたような魔法を作るとなると、その打順がどうかといった制御はアプリケーション側で
実装するのだろう
であれば、データベースには必要な情報を積み上げていくに留め、積み上げられたデータから
モテ度なり打順なりの有無を拾っていった方が良い

見返してみると >>502 が正解かな

RDBは継承は得意じゃないし、そもそもRDBを使わないのも一つの手

カードゲームなら用途的に1000も種類があれば相当多い部類だろうけど
それぐらいのオーダのデータ量ならxmlで持っても問題なかろう

>>528
すいません。
何度も言うように、実態はオブジェクトですので
HPに田中が入ることはありません。
レコードの更新はテーブルじゃなく、オブジェクトに行うものなので。
このテーブルはフィルタさえかかればいいのです。
RDBとは違うものだと思います。

また、HPを二つ持つことも全然ありです。
このモンスターにHP10を追加する。
追加したHPは元のHPと別に扱い、
このHPが全部消滅した時にこのモンスターは死ぬとか
プログラムの仕様を説明すればいいです。
構想上はこんな感じの仕様で動きます。

また、許さない場合もデータベースやオブジェクトが判断しなくとも、
私が作らなければいいだけの話です。

プログラムエラーで動かないようなら意味ないので制限しますけども。

構想が原因でプログラムエラーになることはないから、その構想でも動くと思うよ。
ただめんどくさいだけだね。
オブジェクトとしても気持ち悪いものに仕上がる。

全部一人で作るつもりなら、もう好きにしろよって感じだな
ただ、自分がアプリ担当でこんなクソ設計を上げてくる奴がいたらグーで殴るわ

>>532
そういう自由度を求めるなら、>>530のする通りで、>>502のパターンが適している。

>>532
DBを単なるデータストアとしてしか使わないなら、設計に悩む必要はないよ
オブジェクトと相互変換しやすいようにやれば良い

DBMSの基本的な考え方として、データの整合性はDBMSで保障するってのがある
DBMSの設計論はほとんどその考えを踏襲してる
その保障がいらないならほとんどの設計論は意味ないから

>>534
もちろん後者。

> プログラムの仕様を説明すればいいです。
> 構想上はこんな感じの仕様で動きます。

> 私が作らなければいいだけの話です。

>>536
だから保障されてるってオブジェクトしかいじらないんだから。

>>538
だから好きにしろって
もうここに来る必要もないし、レスする必要もないから

まぁ、ひどい失敗をして学ぶのもいい経験だと思う。
問題は、プログラミングに関する素養がなさそうなところ。
失敗していることに気づかない可能性がある。

おまえさ、知識が足りないからって捨て言葉吐くなよ。
勉強しろよ。

他のスレとは違って忍耐強い人多いから、うまく荒れなくても泣かないでね

ごめん。理解してもえなくて腹たった。
とりあえず、シコシコ作ってみるわ。

実行時まで追加するものの種別がわからんなら、この手の設計にするしかないだろ
おかしいと言うなら、まともな設計と言うものを示してよ

やることはいたってシンプルではあるが口で言うと複雑なので、
まぁ実物をみてもらうしかないですわ。
とりあえず、この仕組みでトランプ作ってみますよっと。

煽りとかじゃなくてDBMS使わないってのも一つの手だぜ、本当に
カードの種類は数万にも達しない上に例外的なパラメータも多いと、そもそもDBMSの強みが活かし辛いケースだし

>>546
そういうこともあって、近頃のネトゲでは>>502みたいなのが主流

ああいったネトゲでは、業務ロジックというかゲームのルールというか仕様というかが、
RDBMS的な思想に基づく、例えば制約やキーによる実現がかえって非効率になっており、
その上でこと細かい制御が必要になるのだから、アプリケーション側をスケールアップ/アウト
しやすいアーキテクチャにした上で、DB側には特に工夫せずに格納する、というのが
パターンとして確立している

>>547
NoSQLでいいじゃんとかxmlシリアライズしとけとかって話なら、早々に言及されてた気がする

>>547
あぁー。そういうこともあって、名前や基礎データにいたるまで、工夫せず>>502のように、、、え？

DBMSは使いませんよ。
SQL的なことはしますが、SQLは使いません。
一応NoSQLです。

オブジェクトの情報を集約し、ある範囲の対象を取りたい場合に
データベース的に扱うとどんな情報があればいいのか
どんな設計にすればいいのかがしりたいわけです。
僕的にも今回の場合、502はわりと素敵な設計だと思います。

いやだから、>>502を全否定してる人はいないだろ
これ以上何の論議がしたいわけ？

なんかやけに >>502 推しの奴がいるな

全否定してるやつもいないが、全肯定してるのは質問者だけだが
質問者がそれで納得してるんだから、さっさとそれで作れば良いのに

質問者も全肯定なんてしてないよね。わりと、でしょ。
自分で考えてるやつあるからそれでどうぞと。

都道府県テーブル
id|名前
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の昇順&amp;降順
のような、いろんな項目を検索させたり、並び替えさせたりする場合、どのようなindexを貼るのがいいのでしょうか？

Bツリーインデックスかな

そういや、ビットマップインデックスが使いやすい場面って、あるのだろうか

更新が無けりゃいいのかな

ごく限られた場合にのみ、僅かにメリットが得られるのみ

そのトレードオフとして、何かのインデックスを扱うときに、それがBツリーかビットマップかを
判断しなければならない手間とかといったデメリットを考えると、間尺にあわん

>>556-558
回答ありがとうございます。
となったら、特に貼る必要もないのですね。　更新コストが馬鹿にならないですが、様々なパターンの複合indexでも貼るのかどうか、気になっておりました。

>>559
検索条件に指定されやすいカラムだけ張っとけ

BIツールが発行する動的SQLみたいなののためのインデックスのことかね

BIツール側の自由度を高めるほど、インデックスは効き目が薄くなっていく

一覧が落ちてる 保守

au氷水ディレクター戦争タイステーキ万国ニューヨークブカ牛肉直輸出制限業者議論病院雇用市議しょうゆダシマクッロスさむらい山雪光金ガンダム風ミックドラ社員あかうんとパズ豚骨のり塩肉マンつばめの巣担々麺野菜炒めラーメン

au氷水ディレクター戦争タイステーキ万国ニューヨークブカ牛肉直輸出制限業者議論病院雇用市議しょうゆダシマクッロスさむらい山雪光金ガンダム風ミックドラ社員あかうんとパズ豚骨のり肉マンつばめの巣塩担々麺野菜炒めラーメン

au氷水ディレクター戦争タイステーキ万国ニューヨークブカ牛肉直輸出制限業者議論病院雇用市議しょうゆダシマクッロスさむらい山雪光金ガンダム風ミックドラ社員あかうんとパズ豚骨のり肉マンつばめの巣塩担々麺野菜炒めラーメン

ニンニクヤーフォー低額土地NHK名古屋遅延電池切れ福岡損保新規駐車近代ゲームフジワイプ転職提案ラーメン
abk公式漏洩安保険王なにあげてんだよ？「わー！ふーう？」↓↓★★↓↓宿題通調印鑑カウントダウン息子議員国会大学生

うちの一部門だけ昔からの付き合いで、メインで使ってるとことは異なるベンダーが
Accessで作った業務ソフトを使ってるんだが、そのデータを取り込む必要があって
とりあえずCSVでもいいからよこせつったら、渡されたテーブルの日付フィールドが和暦だった・・・
まあ取り込む時に変換すりゃいいんだろうけど、ちょっとなんだかなーって感じで脱力した。
もしやと思ってMDBのぞいてみたら、日付型はガン無視して文字型で和暦が格納されてる・・・
しかも、西暦に変換するテーブルまであるしw
こんなの初めて見たんだけど、業界的にこういうのもありなの？

>>564
作った時期とか
おまえの所が和暦文化なら
あるんじゃね？
平成になって西暦重視になったところも多いし

そういや西暦和暦変換ってあんまりすることがなくなったな。前はよくやってたのに。

>>564
昭和64年3月31日と
平成元年3月31日を
区別する必要があるなら日付型は使えない。

>>566
元禄とか慶長とか天平勝宝とかの和暦を西暦に直したいんだけど、良い手が見つからない。
趣味のプログラムなんで急いではいないけど。

>>565
平成以降の作。ていうか2000年以降だし。
最近もVerUPしてる。

>>567
たぶんその必要はなさそう。
売上げ入れて請求書を出すだけのもんだし。

>>567
> 昭和64年3月31日と

そんな日付は存在しない
年度処理とかで、仮想的に昭和として扱う場合でも、単に表示するだけとかなら文字列でいいけど、なんかの処理するなら普通に日付型にして出力時点で変換した方がいいと思う

>>569
和暦と2000年は無関係

>>569
全部和暦なんだろ？

>>571
いや、そんだけ新しいって事で、2000年問題を絡めたわけじゃないよ。

>>568
西暦でもグレゴリオ暦に切り替える前か後かで違ってくるしねえ、しかも国によって違う
ユリウス日で統一して取り出すときに変換するしか・・・

>>568
その辺の和暦がよく分からんが対応表作ってれば良いんじゃないの？

>>574
カソリックの方が暦の近代化が早くて、
英米のプロテスタントの切り替えが遅かったというのが興味深いです。

>>575
太陰太陽暦だと閏月があったりして、単純に置き換えられないんです。

>>576
でも一回作ればあと楽だし、ググって見つかりそうな気もするが

>>576
カトリックのトップの教皇が作ったものをプロテスタントの国々が簡単に受け入れるわけないでしょ。

明治改暦以前の暦をグレゴリオ暦やユリウス暦と相互変換するのは基本的にテーブルにするしかない。
そんなサイトがあった気がするが…

天文気象板の暦関係のスレに行けば詳しい人がいると思う。

レプリケーションだが意見くれ！
マスタ側のFK付テーブルは読取専用スナップショット(サブスクライバ)側でもFK付けるべきなのか。
sqlserverでの答えを探してるけど、他のDBでの意見もお願いします

正規化してくと、一つの画面の機能で複数のテーブルにインサートしたりセレクトしたりしてSQL文が多く作られるんだけど、SQL文が増えようが、アプリ開発においては正規化したほうが正しいと考えていいですか？

>>581
まさかとは思うが、JOINは知ってるよね？

それはさておき、深刻なパフォーマンス問題が生じない限り、正規化はしといて損はない。

>>581
はい。

>>582
インサートの話もしてるんだから、join知ってるかどうかによらず、増えることは確かでしょ。

普通に正規化した状態で、「一つの画面の機能」で
複数のテーブルの更新ってそれほど多くない気がするけどな。
可変長の項目が多数あるとかくらいじゃね？

都道府県リスト、区市町村リスト、番地リスト

ちょっと何言ってるかわかんない

３つのリストフィールドから構成される住所画面

その住所を格納するテーブルが複数に分かれてるの？

リストがあってマルチで選択

番地リストに市区町村コードが無いなんてありえないだろ？

>>589
おちつこ？

>>581
要件による
過度の複数テーブル化は検索速度が落ちるから、とことん高速化を目指すシステムなら、少し位の冗長性は許容する
まあ、更新データ多いと判断が難しい

>>581
DBアナリストに取りつかれると、正規化は絶対的な正義になるけど、
ぶっちゃけ面倒くさいから、作り易さから考えた方が良いよ。


ただ、データ件数が数百万、数千万件に行くとかなら別だけどね。

>>583
> インサートの話もしてるんだから、join知ってるかどうかによらず、増えることは確かでしょ。
JOIN知ってるか知らないかでクエリの回数が違うでしょ。
データレコードを取得して、関連するマスタを何回もSELECTして、それをループで回すという極悪コードを見たことあるし。

バカ相手にしても時間の無駄だぞ

581です。
みなさん有難うございます。

私は設計はしたことがないのですが、興味があったので情報処理を受け、正規化は正義と学びました。

>>592>>593
さんがおっしゃるような
判断基準をしりたいなと思っていますが、やはり開発に携わり経験を積むしかなさそうですね。

>>595
>>594のことだよね

あれ。>>593も変なこと言ってるね。

前段では正規形を崩してでも作りやすさを取れと言っていて
後段はデータ件数多いときの話だから、一般的に正規形を崩すきっかけの話だと思うんだが、
「別だけど」と続いている。

>>598
自分は、開発規模が大きければ大きいほど正規化の有効性が出ると思っているので。

開発人数が多人数もしくは長期に渡るのであれば、出来れば正規化されている方が良い。
テーブルが小さければ小さいほどテーブルに対するミスが減るからね。

けれども小規模な開発であれば、正規化なんてあんまり考える必要は無い。
正規化よりもプログラミングのしやすさを優先させた方がずっと効率良く開発できる。

オブジェクト指向での設計・プログラムをどこまでするのかと同じようなものかと。
再利用されない事が決まっているようなものをどこまで正しく作りこむか。
(これも規模が大きければ多きほど正しくオブジェクト指向で作成した方が良い)

あと、正しくインデックスが貼ってあるのであれば、正規化によるコストロスはだいたいが無視できるレベルじゃないかな。
そもそも、速度の為に正規化を崩すってのは間違い(インデックスや正規化が間違っている)だと思っているので。

一番の影響は開発工数だよ。
ちょっとデータを見たり変えたりするのに、いろんなテーブルへ操作しなくてはいけないなんて無駄コスト。
たかだがちょっとした一覧を出すのに、マスタの為にJOINが何十にもなったりとか泣けてくる。

そんなのよりKVSの設計どうしてんのよ
全然イメージ湧かんわ

たとえば小規模な例だけど、CDの一覧表示を行うとする。
order by アーティスト名, アルバム発売日 offset 300 limit 20 というクエリの速度を出す場合、
・アーティストテーブル.アーティスト名
・アルバムテーブル.発売日
というインデックスを作ってもだめだと思うんだけど間違い？

>>601
アーティストとアルバムとの対応関係を表すカラムにもインデックスを張らないと
アーティスト毎にロウをシーケンシャルサーチするから、まともな性能にはならんだろね

つまり>>601ではだめだから、間違いで正しい

・アルバムテーブル.アーティストID
　アルバムテーブル.発売日

というインデックスにすれば性能は出ると？

つまり何がいいたいかというと、
limit offset の最適化を行わせることと、
複数テーブルに散らばっているソート項目は水と油だってことで。

JOINが何十にもなる、そのマスタが本当にJOINであるべきかどうかはさておき、
各マスタが表示順のような項目を持っていた場合に、性能でないでしょと。

>>601
テーブル構成もwhere条件も件数も書かんでエスパーしろってか
どうしてもその条件に速度だしたいなら(アーティスト名, アルバム発売日)でインデックス張れや
最近のDBMSならビューに対してでもインデックス張れるから

>>603
アーティスト名で順序指定(order by)しているから、
そのインデックスだとクエリ実行の度にソート処理が必要になる
結果として、性能は>>601よりも更に劣化すると思われ

あと規模や性能とは関係しないが、そのDB設計だと
コンピレーションを無視しているみたいだけど、それでいいの？

ソートのため（だけ）のインデックスなんて有用性高いか？
インメモリソートならそんなに時間かからんし、
メモリに乗らない量のデータをソートする要件があんまり浮かばん
DWHとかなら結構必要なのか？

>>605
単純な例のつもりだから大丈夫かと思った。エスパーありがとう。
ビューにインデックスがはれるDBMSなら確かに。でも、そうじゃない場合はどうします？

>>606
あら。
・アーティストテーブル：アーティストID, アーティスト名
・アルバムテーブル：アーティストID, 発売日
にすればよろしいでしょうか。
また、コンピレーションというのは何でしょうか。無知ですみません。

あれ、ちがうなぁ。
・アーティストテーブル：アーティスト名, アーティストID
・アルバムテーブル：アーティストID, 発売日
にすれば、複数のインデックスを元に、limit offset の最適化が行われるということでしょうか。

>>608
>そうじゃない場合はどうします？
selectの結果の件数が数万件のオーダーなら別にどうもしない
しいて言うならソートワークのメモリ多めに取るようチューニングするぐらい
数千万とか億とかのオーダーなら、そもそもlimit offset するっていう要件を見直す

>>606
あ、、コンピレーションって複数アーティストが参加しているコンピレーションアルバムのことでしょうか。
てっきり設計手法か何かかと。

例なのでそういうのは無視してもらって、
正規形を満たした状態で、ソート条件が複数テーブルにわたる場合、
インデックスのみでは解決できないように思ってるんですが間違いでしょうか。

> (インデックスや正規化が間違っている)
これに、マテリアライズドビューが含まれているということなのかなぁ。。

>>610
たかが数万件でも、メモリ上でソートを行うのとインデックスが使われるのでは
大きな違いがあると思います。
それがたとえば3ms と 0.02ms で、実際どちらも問題ない速度であったとしても、
query per secでは大きな差になりますよね。

思ったんだが
最近のオプティマイザって、基本的に全体の処理量が最少になるように最適化するよな
その際にlimitとかoffsetとか考慮されてないよな

この例なら最終的には320件の結果セットがあれば良いわけだから
アーティスト名（のインデックス）を順次ループして320件で打ち切れば良いんだが
そう言う実行計画は作らんのだろうか
これならアーティスト名にインデックスがあればそこそこ行けるんじゃ

昔のオラクルとか、ファーストロウに対して最適化されてたような気がするんだが

>>612
確かに、アーティストを320件抽出すれば必要最小限のアーティストに対して
アルバムを結合することはできますね。
でも、limit 20 offset (全アーティスト数よりも大きい数字) になった場合、
その最適化は働かなくなります。

正規形を崩して、アルバムテーブルにアーティスト名を持たせると、
・アルバムテーブル：アーティスト名, 発売日
というインデックスを作ることができ、limit offset が解決できるようになります。

ただ、アルバムテーブル.アーティスト名の同期を取る手間が増えるんですが、
それはDBMSによってはマテリアライズドビューの同期の手間と同じようなものだと思います。

ソート項目が複数テーブルにわたる場合、正規形を保ったまま、上記のようなインデックスを
はったときと遜色のない性能を出せたことがなく、件数が増えると正規形を崩すのはやむなしかと思ってました。

パッと見サブクエリで高速化きそうな？ダメかな？MySQL？書式分からんけどｗ

SELECT * FROM (SELECT ID FROM 〜〜 order by アーティスト名, アルバム発売日) offset 300 limit 20

>>614が何を議論したいのかわからん

>>615
正規化状態でですか？それなら、差はないかと。
正規化を崩していれば、そのサブクエリはインデックスが同等の働きをするのでサブクエリ化しなくてもよいと思います。

>>616
正規化を崩すことでパフォーマンスがあがる場面はあると思っていたけれど
インデックスや正規化を間違えてるだけ(>>599)という話になったので、
どういう正規化およびインデックスにすれば性能がでるのか教えてほしいと思ってます。

>>617
特定の状況やクエリを見れば、正規化を崩すことでパフォーマンスが上がる事はある
以上、この話題終了

荒れる質問してしまいすみませんでした。

データベースを独学で学ぶうえで、以下のような玄人が思想を説明している動画やサイトってあったりしますか？

http://youtu.be/VK4GpC34fBw

>>618 = >>599 なら、それで終了でいいと思うけれど。

別に荒れる質問をしたつもりもないんだけどなぁ。。。

>>614
>正規形を崩して、アルバムテーブルにアーティスト名を持たせると、

リレーションの正規化ってものを一度ちゃんと勉強したほうがいい。

バカ相手にしても時間の無駄だぞ

>>621
おや、、そこに異を唱える人が出てくるとは思ってなかった。
アーティスト名はアーティストテーブルにあるべきだし
アルバム発売日はアルバムテーブルにあるべきじゃないの？

あ。
アーティスト名は主キーになりうるから、
アルバムテーブルにアーティスト名を持つことは必ずしも間違いではないという話かも。

そうなら、アーティストテーブルの活動開始日, アルバム発売日ではどうでしょうか。

>>614,617
まず「正規形を崩す」という言葉をそのまま解釈するのが、ありがちな間違い
今回のケースは非常に単純なデータモデルで検索条件も確定しているから、
最初からその検索条件に特殊化した(= 最適化した or 崩した)テーブル設計ができた

でも現実世界のDB設計は違う
データモデルは複雑だし検索条件も(遠い未来を含めて)確定できない
新規開発時に(正しい論理設計の後で)正規化を崩してテーブルを実装してしまうと、
その時だけは要求性能を満足できても、その後に長く続く保守(= 機能エンハンス)のフェーズで
異なる検索条件を要求された時に対応が極めて困難になる
だから教科書に書いてあるような「正規形の崩し」は、現場だとバッドノウハウになる

ではどうするかというと、正しく論理設計された(=正規化された)データモデルは触らない
代わりに、特定の検索条件に最適化した検索専用テーブル(「ターボテーブル」とも呼ぶ)を追加する

>>625
レスありがとうございます。
まったくもっておっしゃるとおりだと思います。

> 代わりに、特定の検索条件に最適化した検索専用テーブル(「ターボテーブル」とも呼ぶ)を追加する
マテリアライズドビューの使用が可能なDBMSであればそれを使えばよく、
使用できないDBMSであれば、マテリアライズドビューの代わりとなるような
実テーブルを用意するということであっていますか？

>>626
マテリアライズドビューについては理解している自信が無いのでコメントできない

その検索専用テーブルとは、正しく論理設計された(=正規化された)データモデルから
部分的に複写した一時テーブルであり、正規化の原則に従う必要は無い(>>614もO.K)
複写処理はデータモデルの更新処理と完全に同期させる完全な方法もあるけど、
一定期間毎の複写でもかまわないケースは多い（一時的に実データと検索結果にズレが生ずる）

>>626
今のマテビューがどうなってるか知らんが、オラクル以外でこの用語つかってるDBMSあるかな？
マテビューってのはもともとオラクルでレプリケーションのための実データ（のコピー）を持つビューだったはず
検索のためのインデックス付きビューは実データ部分は持つ必要ない
あくまでインデックス項目のデータだけ持てばいい
そういう意味ではインデックス付きビューとマテビューを同一視するのはどうかと思うのだが

あと>>625の言うターボテーブル（この言い方は初めて聞いたが）も
更新のコストの問題があるから、ターボテールブル作成（更新）のタイミング等をコントロールしたりする
これもマテビューとは別ものと考えないとダメじゃないかな

あとそもそも、インデックスは制約じゃないので、本来はＤＢ設計じゃなくてチューニングの話ね
（当然ＤＢ設計時にある程度は見越しておくけど）
性能要件もＤＢ設計だって言うなら話は別だが

一応、今回はシンプルだから崩した形にできたという事実も確かにありますが、
もともとは、正規化されたテーブルとそれぞれのインデックスだけでは、
本来出てしかるべき性能が出ないことがあるというのを説明するための最小構成の例を出すためでした。
お付き合いありがとうございました。

>>627
検索専用テーブルを用意すれば更新コスト、ディスク領域使用量は増えてしまいますが、
汎用的に解決できる方法だと思いました。
それを思いついたことはあっても、不恰好な気がして手を出せずにいましたが、
実際応答速度が上がると思うので使ってみます。

>>628
細かな機能的には差異があるかもしれませんが、PostgreSQLにもマテリアライズドビューがあります。
インデックス付きビューが実装されているDBMSはとても楽に今回の問題が解決できるので、
使える場合は積極的に使うようにします。

>>624
PKは商品コード
アーティスト名は別アルバムで被るからPKにならない

>>601
本来はこうなるはず
PKが商品コード
select アーティスト名、発売日
where 発売日 between a and b
order by 商品コード、発売日

なので、インデックスいらんな

アーティストテーブルは確かに欲しいけども、同じアーティストが
アルバムごとにアーティスト名を変えたりするケースもあるから
アルバムテーブルにもアーティスト名のカラムは入れた方が良いと思う

>>631訂正
商品(アルバム)の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でインデックス効かない

こういう設計だと、買ってきたCDからデータと入れようとしたときに同名のアーティストのどっちなのか
いちいち調べたり、アーティスト名の表記の違いを名寄せする手間が必要になったりする。
正しくアーティストを特定するというのが要件のうちであればそれでいいんだけどね。

買ってきたなら分かるだろ（笑）

マニアなら
trfがTRFに変わったように年代ごとに細かく分けたい気持ちはわかる

話変わっててわろた

まぁ確かに、自分で選んで買ってきたならアーティストは特定できるな。
要は、>>633の設計を成り立たせるには、IDを決定するのにそこに存在しない
情報が必要になるかもしれないという話。

話広げたらなw

CD管理の設計の話に進めるんだったら、
それこそ上でも出ていたようなV.A.であるようなCDを
どう管理するのかのほうを急いだほうがいいんでない？

CD管理ってかアーティスト管理？
興味はあるけど、まず要件がまとまらんだろ

ここ見てていつも思うのが、要件定義をろくにしないで設計始めちゃう奴の多いこと。
ひどいのになるとフィールド名見ただけで「それは正規化されてない」とか言っちゃうしなぁ。

こんな雑談スレに何を期待してるんだ。

みなさんテーブル設計のツールはなに使ってますか？

>>644
ポストイットとホワイトボード

普段は、紙と鉛筆とコーヒーを使っています

>>645
出来上がった物は、スマホで撮影するよな

ER図やテーブル定義書やテーブル作成のSQLはなんのツールで作ってますか？

SQL Developer
SQL Developer Data Modeler
紙、ボールペン、ホワイトボード

ER図…ホワイトボード、ポストイット
テーブル定義書…Excel
テーブル作成のSQL…Excelのマクロ

ありがとうごさいます。

何で設計を学びましたか？

・データベーススペシャリスト試験
・先輩・上司から学ぶ
・データベース設計に関する参考書
・SQLアンチパターンの参考書
・Oracle Database設計の講習

資格はとったのですが、教わる人がいなくて、とりあえず楽々ERDレッスン中です。終わり次第SQLアンチパターン買ってみます。

Oracle=高いというなんとなくイメージがあり敬遠してましたが、講習は無料もあるみたいですねー

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=609&get_params=dc:D17065,clang:JP

会社の金で↑いったずら

ER図とテーブル定義書とDBマイグレーション(flywayとかliquibaseとか）を
うまいこと連携させる回し方みたいなのありませんかね

初めての設計でパニクってます。ワークフロー系のシステムなのですが、参考になる書籍などあれば教えて下さい。。。


いま取り組んでるものは、質問内容に対して回答し、クローズするワークフローシステムです。

大きなフローとしては
「質問部署→回答部署→クローズ部署」
で、その各部署内で「作成→審査→承認」のフローがあります。

お客様からは以下の要望は必ずみたして欲しいと言われています。

要望1.前部署への差し戻し機能、部署内での差し戻しがあります。

要望2.ワークフローを変更した場合の既存プログラム改修を最小限になるデータベースにして欲しい。

要望3.回答部署は複数部署可能とする。その際は各回答部署内で並列に作成審査承認をし、全回答部署が承認された場合に、クローズ部署にいく。

DBの設計で悩む話じゃないと思うが。
今考えてるテーブル書いてみ？

DBと関係ない気がするが・・・

それ作るか？って機能だなｗ
ちゃんと作るなら稟議のミニセットだしそれだけ作るなら機能として片手落ち

ステータスの状態遷移をどうするかとか、あったっけなぁ

出来合いのワークフローのソフトとか使ってみて仕様確認しながら
要件定義ちゃんとした方がいいような気もするなぁ
で、出来合いのやつでいいかもしれないし

最低限で作るとしても、
こんな場合はどうするんだとか、後からいろいろ出てきたり
ちょっと汎用的に作ろうとするとそれなりに
大がかりになりそうだし

まず、権限設定と、ログインして使用してもらう必要があったりとかもあるな

思いついたのはこんな感じですが、
先輩にはデータベース設計を勉強してこいと言われました


質問(質問ID(PK)、内容、作成者、作成日、審査者、審査日、承認者、承認日)

回答(回答ID(PK)、内容、作成者、作成日、審査者、審査日、承認者、承認日)

クローズ(クローズID(PK)、内容、作成者、作成日、審査者、審査日、承認者、承認日)

質問回答連関(質問ID(PKFK)、回答ID(PKFK))
回答クローズ連関(回答ID(PKFK)、クローズID(PKFK))

ユーザ(ユーザID(PK)、名前、部署ID(Fk)、作成権限フラグ、審査権限フラグ、承認権限フラグ、削除フラグ)

部署(部署ID(PK)、部署名、削除フラグ)

そもそもの要件整理不足が否めないが
俺ならheader-detailで遷移はheader.statusで対応

>>656,661
要求事項だけで機能仕様が不明確な段階では、
いきなり論理設計(=デーブル設計)に着手するよりも
概念設計から始めたほうがいいと思う
概念設計を簡単に説明すると：
・要求書に含まれた単語で表される概念を列挙して箱として描き、
・関連する(と思われる)概念の箱の間に線を引き
・概念の役割を以下から割り当て、箱に記入するか楕円や菱形へ書き換える
　　実体(エンティティ)/識別情報(キー)/属性(アトリビュート)/リレーション(関連)
最初はホワイトボードや裏紙にラフスケッチすることから始めよう

今回のケースだと、概念設計のポイントは以下の２点
・ワークフローシステムは、部署をノード(節)、ワークフローを矢印(アーク)とする
　有限グラフとして表現できる
・「作成→審査→承認のフロー」は、質問および回答が持つ「状態の遷移」として表現できる

具体的な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の検討方針(先輩の指導方針？)は妥当だと思うよ
まあ、要求分析や製品企画といった上流工程の実務経験が無い人には難しいかもしれないね

>>663 にミスがあったので訂正

X：・ワークフローシステムは、部署をノード(節)、ワークフローを矢印(アーク)とする
　　　有限グラフとして表現できる

O：・ワークフローシステムは、部署をノード(節)、ワークフローをアーク(矢印)とする
　　　有向グラフとして表現できる

ああ、この人まだいたのか。久しいな。

>>661
いいんじゃねーの。
作成者、審査者、承認者はユーザIDなんでしょ？

先輩の言いたいことはあらかた予想できるけれど、
それをどう結合して、どう操作すれば運用をしていけるか先輩に説明してみたらどうだい。

車輪の再開発はシステム開発とは違うしな
上流経験が本当にあるなら要件整理した段階で開発は止めるレベルの物だよ

開発止めてどうするの？
出来合いのもの金出して買うの？

軽いものでいいから
新人の教育がてらに費用かけずにやろうって計画に見えるな

エンティティおじさんか？

>>663
ありがとうございます。

作成、審査、承認というイベントを分割出来るか考えてみます。

また、履歴について考慮していなかったので、全ての処理履歴を取れるように改善します。

>>658
この手のアプリケーションなら普通に DB 使うだろ。

>>668
お客様って言ってるのがちょっと引っ掛かるが、その先輩が勉強がてらちょっとやらせてみてるって感じなんだろうな
>>661 で、ユーザー/部署テーブルに削除フラグつけてたりするから全くド素人って言うわけでもなさそうだし

現状はどんな仕組みで承認してたりするのか
紙ベースなのか、既存の仕組みがあるのか
どんな紙の書式なのか
どういった点を、改善したいと思ってるのか
実験的なシステムなのか
おそらく関係部署が多いと、調整も必要
誰が誰に承認依頼を出すのかとか、代理承認とかも許すのかとか

>>671
受注が確定してないので教育がてらに私が任命されました。今はお客様のふりをした先輩とやりとりしています。本業務は別なので、進みは非常に悪いです。

>>672
背景は現状メールでやりとりされていて、しっかりと管理されていない情報がある。ISO監査で指摘されたのでシステム化するものです。(詳細不明)

上記の理由により仮定となりますが、>>656に以下を考慮し、もう一度考え直します。

1.部署はたくさんあり。各部には質問、回答、クローズの実施権限を付与する。

2.ユーザーは部署、課に所属する。課を兼任する場合があり。

3.同じ課の同一権限をもつユーザーの代理承認は可能。履歴は代理承認した人とする。

4.各ステップで次ステップのユーザーを指定する。そのユーザにメールがいく。

5.全ての処理は履歴をとる。
検索画面では全て追えるようにする。

6.各処理で添付ファイルをつける。
添付ファイルをつける際にはいくつかの属性を付加する。
ファイルはファイルサーバに格納。

7.ASP.NET+Oracle

>>673
出来合いを検討したけどそれでも開発するって場合は
使い勝手は出来合い並みを求められそうで大変かな

>>674
そうですねー。比べられると辛いです。

ちょっと放置してましたが
「作成→審査→承認」が、
「作成→審査1→審査2→承認1→承認2」など動的に増やせるようにするとこ考えなきゃ。。。

ルートID, 承認順序, 部署ID, イベント名
--------------------------------------
　　　 1, 　　　 1, 　　 2, 作成
　　　 1, 　　　 2, 　　 3, 審査1
　　　 1, 　　　 3, 　　 5, 審査2
　　　 1, 　　　 4, 　　 7, 承認

こんな感じで必要なイベントを管理するテーブルでも作っときゃいいんでない？

その会社に開発導入実績があって追加開発依頼だったら
少しはやりやすいが

フェーズ1で導入に理解のある部署に絞ってパイロット導入して
不足機能を洗い出す
フェーズ2で部署を増やして機能追加パターン網羅に努める
フェーズ3で全面導入とかか

新しい機能を使ってもらうのに
問題を感じていない積極的でない部署を説得させるには
ある程度実績がないと、なにかと難しかったりする
部署間調整に結構時間は割かれる
思いつき仕様をどれだけ抑えつつ便利に使ってもらうか
多分仕様は言い出すと切りがない
メール1回じゃ忘れるので承認要請リマインダーを煩わしくない感じで定期的に出してくれとかね

>>677
> 多分仕様は言い出すと切りがない

稟議システム外販してたけど、マジできりがないよ
稟議のフローに関するところはまだしも、社員情報システムとの連携（承認した奴が辞めちゃった時に差し戻されたらどうするとか
、次の承認者を設定する画面で候補者の並び順が気に入らないとか）が地味に面倒

DB設計だけやればいいなら、多少ややこしい要件が捩じ込まれようと
DB上は格納できるように設計し、あとは全部アプリ側で頑張ってもらえば
良い気がするがどうだろう

どんな要件が出そうかは充分に洗い出す必要があるけど

外販されてるいわゆる「アプリケーション」と呼ばれるものはそんな感じだね。
ユーザー要件に応じて様々にカスタマイズできるよう、テーブルはほとんど
ただの入れ物扱いでエクセル表みたいになってる。
DB設計としては吐き気がするような代物だけど。

>>680
> テーブルはほとんどただの入れ物扱いでエクセル表みたいになってる。

単にお前んところの設計が糞なだけじゃん w

ガチガチの定型業務だけをワークフローで小さく始めてって
思ったりするけど
結局その定型業務用に特化したシステムにしたほうが
いいような気がしたりする

項目をユーザーが登録できるような
汎用的なつくりにしていくと多分>>680のようになる

RDBならEXCEL表とほぼ同じだろう

>>683
DBスレでつり？

EXCEL表って言われてどんなものを想像してるんだろうな
別にDBのテーブルレイアウトそのままEXCELに持っていくこともできるわけだが

>>680>>681
それが本来の正しい姿
テクニカルが凄い！とかただのマスターベーションだよ

>>686
つり？意味不明

>>682-683
このスレ見ない方がいいかと...

>>688
ここRDB専門スレだっけ？

>>689
RDB 専用じゃないけど
> RDBならEXCEL表とほぼ同じだろう
程度の理解力だとねぇ...

みんな短文過ぎて意味ぜんぜんわかんなーい

>>690
あんた、真のEXCEL使いを見たこと無いだろ！

テーブル＝EXCEL表＋インデックス＝EXCELデータベース

Excelは方眼紙切って設計書を書く物だとしか思ってないだろ
印刷ズレまくるのに
普通に集計、分析とかで表として使ってみ

>>680
どんなExcelになっててどんな表が良かったのか
興味出てきた

ほぼ同じとまではいわんが、エクセルのあるべき姿を知らない人が紛れ込むと厄介だね。

[ユーザが項目を追加したり、ワークフローを変更したりとできる汎用的なアプリケーションのDBはExcelの1シートに全ての情報を纏めたような、つまり正規化されていないDBである]てこと？

正規化の限界か

予備1とか作っちゃうんだろう。前時代的にもほどがあるなぁ。

>>696
> エクセルのあるべき姿

Excel スレに行けよ...

予備1とかにせずに
マスターのマスターをつくる感じで
ユーザー管理者が項目を追加できるような仕組みを作ることは
できることだと思うが
実際にユーザーがデータを入力したあとは
項目変更に制限を加えたり
システム連動項目の仕組みを入れたり
マスターのバージョン管理をするようにしたほうが
よかったりというのはあると思う

もっと汎用的にしようと思えばユーザー管理者が
create tableする仕組みも考えられると思うが
ワークフローシステムの場合にそこまでするのかはわからん

Excelに予備１は無いだろ
列追加で終わりだし
正規化も出来るだろう

>>697
1シート1テーブルだろ
否定有りきで無茶論（笑）

>>699
頭悪いなあんた。

>>703
誹謗中傷スレに行けよ
そんなスレがあるかどうかは知らんけど w

Excelついでで全然違うが
Xcuteってツールが面白そうではある
かなり前と思うが日経なんとかに出てたかな
実際に使ったことはないが

今見たらXlsFlowってのもあるみたいだし

>>704
言わんとすることを理解もできずExcelスレに行けというのがまともなレスだと思えるのか
表計算ソフトを使えないことの自己紹介なのかね。

スレ違いだって事、いい加減理解しろ

ODBCのデータソースとしてエクセルブック使えるのに？とまで話を進める必要はないか。

そういう話なら関連はあるんだろうが、
ＤＢ設計と結びつけて語らないとな

> テーブルはほとんど
> ただの入れ物扱いでエクセル表みたいになってる。
> DB設計としては吐き気がするような代物だけど。

んだから、こうやって引き合いに出される「エクセル表」が、どの程度のエクセル表なのかって話になるわけじゃん。
吐き気がするような表を使ってる時点で、エクセルをまともに使うことすらできずに卑下するなんておかしくねってことで。

では
>>680の
>ただの入れ物扱いでエクセル表みたいになってる。
これの解説を誰かよろしく

>>706
はいはい、真の Excel 使いなのはわかったから、いい加減どっか行けよ

で
設計論でテーブルとエクセルの違いって？

マスターのマスターを作るやつってSQLアンチパターンにのってたよね

>>711
数字だろうがなんだろうが、全カラム CHAR(255)。
もちろん外部制約やユニーク指定もない。
そしてインデックスすら張ってない。
そんな糞ミドルをよく見かける。

>>715
ユニークとインデックス以外はエクセルでも出来るし
やっぱエクセル表みたいってのはエクセルにも失礼な状態だな

そんなアプリ使うより
京大式カード使うほうが安上がりな気がする

>>715
それをエクセル表みたいと表現したのがまずいだけだと思うわ
エクセルにも劣るとか、エクセル初心者が作った表とかさ、いろいろあるじゃん

DB使える俺スゲーだろ
excel優秀なのに

外部制約やユニークはない方が好きだな
メンテしにくくなるし

>>720
小規模ならそうなんだけど、大規模システムで制約がないとか怖すぎる

>>720
手でメンテするからじゃないかな

>>714
問診アンケートみたいなやつだと項目がやたら多くて
マスターというかアンケートの雛形を作って
さらにアンケートの種類によって項目が違う
回答欄がテキストか数値かとかの項目の種類もあるし
サブタイプとしてテーブル分けたりしたほうがいいのかもね
それでも記録だけならいいんだけど、回答の値を他で
有効に使うにはさらに仕組みが要る

まあ項目を汎用的な仕組みにするのは
使う場面は限定したいし、やらずに済めばそれがいい
あんまりRDB向きではないということだろう

SQLアンチパターンはいい本だな

>>722
一発物は手作業でしょ

>>724
一発物だからという綻びが被害を拡大する

>>725
何の被害だよ？
私失敗しないので

一発物を何発やるの？

>>726
お前自体が失敗だろ

何発しても毎回違えば一発物

外部キーは履歴のこらないから、付けるなって講習で言われた

>>730 外部キーがなければ残る履歴って何よ？

・販売履歴テーブルの売値
・商品テーブルの売値

みたいな話なんでないの？

>>730
どこの講習だよ w
マジでそんなこと言ってるなら、晒していいレベルだわ

履歴が残る残らないの意味から分からんのだが…。

>>732のやつ
他にもいろいろケースはあると思う。そのイベントが発生した時点の値がわからなくなるからイベントテーブルに外部キーは設定しないほうが安全だと言っていた。
講習代で一日三万もはらったよ

どう見ても、こいつがセミナーの内容を理解できないで、断片的な言葉だけ覚えたとしか思えん w

>>729
内容が違えば何度でも手動でメンテしますよと。なんせ一発ものですからね。
やっぱ被害は拡大する一方。

>>737
内容が毎回変わっても自動化できる方法を示さないとね

>>738
その考え方をする状況に至ってるのがもうだめ。

意味解らん
手作業……被害拡大
自動化……考えが駄目

意味がわからんか。馬鹿の壁とはうまく言ったもんだよね。

なるほど、あっち側の人か w

どうせ説明も出来んのだろう

>>739
> その考え方をする状況に至ってるのがもうだめ。
状況に至ってる、なるほどわかる

そもそも自動化された（できる）作業は今ここで議題になってるメンテに含まれんだろ

正規化すると履歴が残らないとかそういうレベルか

>>746
何それ？どうやったらそうなんの？逆に知りたいわ

履歴が残るように正規化すればいいだけではあるけど、参照用テーブルを作ることはよくあるね

履歴を残す残さないと
外部キーは無関係。

アニメと声優の関係って多対多(アニメは複数キャストを登用し、声優は複数のアニメに出る)だと思うんだけど
これを関係データベースとして使えるようにするにはどうすればいいですか？

アニメマスタ（anime_id,anime_name）
声優マスタ(voice_id,voice_name)
出演データ(anime_id,voice_id)

キャラクターそのものは１つじゃないの？
まあ代替わりとかメディアによっては変わるけど同じ作品内ならほぼ固定でしょ

>>752
同じ作品内という括りでは考えていません
今までの全てのアニメとそれに出演した声優でデータベースを作りたいと考えています

>>751
連関ってやつですか
ありがとうございます！

出演してるアニメがわかればいいのか？
キャラクターの情報は要らない？

>>755
おせっかい

DBの勉強したいです大量のサンプルデータってどこかにないですか？

>>757
ベンチ用のデータ

大量って人によって受け止め方違う気がする
普通はどのくらいから大量って呼ぶんだろうか？

>>757
なんか多そうなのいくつか

郵便番号csv (日本郵便)
ttp://www.post.japanpost.jp/zipcode/download.html

気象データ(気象庁)
ttp://www.data.jma.go.jp/gmd/risk/obsdl/

基盤地図情報(国土地理院)
ttp://fgd.gsi.go.jp/download/

>>757
livedoorのグルメdatasetも割と多いんだっけかな？
ttp://blog.livedoor.jp/techblog/archives/65836960.html

>>758,760-761
ありがとうございます！

>>760
国の集めてるデータ自体は只なのを知らん人多よな（笑）

住基データください

公開データじゃないからそりゃ無理

>>763
突然どうしたの？

データベースを作成する際、予めExcelにまとめたりしますか。
データベースに入力するがまとめる作業なのだから二度手間ですか。

データ入力する人によって合わせる

MYSQL初心者の自分が、数万件の資料から、必要な部分のデータだけ引用し、一覧表にまとめて、
条件検索できる形にします。
資料からデータを引用入力する過程を、データベースに直接打ち込むか、
EXCELで一覧を作ってからデータベースを作るかということなのですが。
Excelで予めまとめたものは、MYSQLに再び手入力しなくても、コピーか自動転送できるものですか。

>>769
vbaで一気に入れてる

他のDBではインポートの機能があるけど

あ、勿論mysqlでもcsvからならvbaでなくても出来るよ。ここではスレチになるから詳細はmysqlのスレで聞いてくれ

>>770、771　早速お返事ありがとう！
web上で検索できるDBにしたかったので、mysqlについて尋ねました。
これが完成したらきっと世のため人のためになると思うのだけど
初心者なので遠い道のりになりそうです。どこかに協力者がいないものか。
知恵を貸して頂いてありがとうございます。

素直にAccessにしろ

accessはローカルで使うものなのではないのですか？

フロントエンドで使えばDBをそのまま操作できるね

データ分離して共有フォルダー配置で3〜4人程度ならAccessでも十分

素人にACCESS勧めるなんて怖い事やめろよ
実際に見た事あるが地獄だぞ

フロントエンドどうするのか知らんが
その代案がMySQLってか？

薦めるなっていうけど、そもそも素人さんの一番近くにあるのがMS-OfficeのAccessだと思うけどなぁ。

職場のOracleはデータ管理をアクセスでしてたな

もはやGoogleスプレッドシートで良くね？

読書メーターみたいなamazonの本と連動しているようなサイトって、
管理者がいちいち本のデータを手入力したんだと思いますか。
それとも自動で吸い出しというかリンクさせるのだと思いますか。
不動産サイトやグルメ情報サイトでも、個々の情報を載せてくれっていう客の送ってきたデーターを
管理側でいちいち手入力しているんですか。それとも

>>782
これで予想がつくかと。
http://bookmeter.com/help/?id=22

共通属性と可変属性の定石のテーブル設計ってありますか？

>>782
世の中にはWeb APIとかいうような類の便利なものがあってだな

>>785
予想つかない。ソースを表示とかしても察しつかなかった。私は素人。バカです。

>>782
そうなんだ。APIっていうのがamazonのデータが流用できるようなパッケージなのかな。

難しいね。プログラマの人はみんなこういうことを当然のように知っているのね。

APIはバックエンドの話だしな。
このスレに来るの早すぎるんじゃね？

>>786
そうだね。
たとえばWindowsで動作するソフトウェアを作ろうとしたらAPIバイブルという本が必須の時代があった。
最低限必要な2冊を買うと2万円ぐらいかかったが。
つまり、APIがなんなのかは当然知っていたよ。

ハードルが低くなるということは、低レベルの知識が欠落したプログラマを生むことに他ならない。

と、えらそうに書いたが、自分もアセンブラに関する知識は大雑把なものでしかないので、
やはり習得時期には既に先人によって甘い皮に包まれてしまっていたレベルの知識は欠落しているのである。

>>784
rdb xml、rdb json、kvsでググれ
間違ってもc1、c2・・・はすんなよｗ

>>790
NoSQLってやつ？
ニュースでは見るけど、実際に触ったことないなあ
ACID特性持たすのが大変ときいたが

>>791
NoSQLに該当するのはkvsだけだな。
てか、しらないなら書かれてるとおりググれよｗ

>>788
ポケベル→ケータイ→スマホ
スマホしか知らない小学生が、ポケベルもケータイも使ってからしか
立派なスマホアプリは作れないってこともないと思うんだけど
そういうこととは違うのか。

ぜんぜん違うｗ

>>794
どう違うの？うまく説明してみて。

ポケベルには何の連続性もないだろ
ケータイも電話する部分を作るなら必要だがでんセに関係ない部分に連続性はない

>>795
スマホにポケベル入ってるの

そっか。
プログラミングは、古いものから進化してきた過程に連続性があるから
最初から全部勉強しなくては新しいのだけ見てもわからないということなんだね。
進化してきたということは、そうなる理由があったと思うから、最新のものを学べば、
一番手っ取り早いだろうと思ってたんだけど。
古参のプログラマーの人は、自分たちが通ってきた苦難の道を、新人が通らずにいきなり同じ到達点に来られるのが
なんか癪だから、わざと遠回りさせたがっているのかと思ったけど、違うんだね。

>>798
頭悪いだろ

ひらがな読み書きできないのに、いきなり漢字使わせられるようなもんだよ

>>800
？

こんなに便利になってんのになんで遺物みたいなのを大事にしてるかね
俺は指導側だがそんな今後使う必要が薄いとこは教えないなぁ
そこで詰まられても本当に時間の無駄だし

> ハードルが低くなるということは、低レベルの知識が欠落したプログラマを生むことに他ならない。
欠落してるからダメだとは言ってない。

SQLそのものはそれほどでもないけど
ホストアプリ側、とくにWindowsに限れば
開発環境と言語の進歩が低レベルなAPIを使う必要性を無くして行ってるからな
それでも変わった事やろうとするとAPI呼び出しに頼らざるを得ない事もあるにはあるが
全てのプログラマがWinAPI呼び出し必須だった時代なんてとっくに終わってる

まるで誰かがWinAPIを含めた低レベルの知識がなければダメだと言ったかのような会話の展開だけど、どうしたの。

>>805
>>788 が...
> ハードルが低くなるということは、低レベルの「知識が欠落したプログラマ」を生むことに他ならない。
って書いたからだろ。

うわ、おもしれ。
「低レベルの知識」が欠落したプログラマ
なのに

>>807
だから、曖昧なこと書くなよってことだよ
マジで説明が要るとは思わなかった

文脈でわかると思うが

言葉通り、低レベルな奴が増えてるのかもな

低水準って言い方は根付かなかったね

結局 >>799 が正解だったと。

798だよ。自分は素人だから、質問も書いてることも頓珍漢で
頭悪く見えると思うけど、わかりたいから質問した。んで、わかった。
>>802のような考え方が自分は合理的だし好き。自分が習うならこの人に教わりたい。
低レベルな奴が増えてるんじゃなくて、このスレでは自分一人だと思います。
習うといっても、基本の本を端から端までとか、自分は待てない。
作りたいものを作りながら、聞きたいことが出たらちょこちょこ教わって早く結果が欲しい。
早くここの住人に追い付きたいよ。

スレ違いどころか板違い。
根本的でかつ単純な判断すらできない素人なのはわかったよ。

>>813
プログラマ板でアホどもとどうでもいい話でもしとけ

>>811
そもそも低レベルと言う奴がおかしい
低レイヤーだろ

low layer ではなく low level の話なのに？

low level 君乙

low-level programmingって言葉も知らない低レベルな奴が混じってるのか

いいなあ、ここの人たちは。みんな自由自在に作りたいものが作れるのか。
グーグル地図に投稿するサイトとかも、簡単に作れるのか？
放射線量を投稿するサイトとか、ポストの位置を投稿するサイトとかあったろ？
ああいうのは、どやって作るん？素人には無理か？君らでも時間かかるのか？
そういうの作れる人と友達になりたかったら、どこにいったら会えるんかな。

まず2chから離れろよ

最低限このスレから離れろよ

>>820
つてがなければクラウドソーシングを利用する
ただで作って欲しいという意味ならあきらメロン

作って欲しいじゃなくて自分で作りたいん。
お金を払っても中身が自分にわかるように教えてくれるなら全然いいよ。
ちな、いくらぐらいでなら>>820みたいなの作って貰えるん？

>>824
いくらぐらいなら出せるの？5万ぐらいとか？

>>820
スレタイを声に出して10回読んでみろ

出せる金額なんて言ったら、そら上限いっぱいまで所望されるでしょうよー。
５万円でちゃんとやってくれるん？

>>827
やっぱり想定してる金額が相当少ないみたいだね。
5万だとどんなに優しく見積もっても1日で出来上がるシステムしか請けられないよ。
上で書いてるようなものなら、10倍用意して足りるなら御の字と思って。

>>820　(^^)　怒られた　
>>828　そっか。50万円ぐらいは欲しいんだね。全然いいよ。

俺だったら青天井で捻くれた根性叩き直せるまで金出させる

なんなのこれ

>>831
これほとんどが自演なんだぜ？

…すごいな

Nosql作ったことある人います？
うちの職場ではRDB以外受け入れてもらえないんだけど

ひょっとしてDBに興味ある人って変な人ばっかりなの？

お前みたいな馬鹿でないことは確かだろうよ

スキル無いのが集まってくるな

「DBに興味ある人」

意味がいまいち分からないな。

/:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ
　　　　/:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::://ヽ:::::::::::::::|
　　　 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

>>834
作るって何？コードから？
使った、のtypoかな？
mysqlとredis併用でがんがん稼働中ですよ

NoSQL系はRDBがマッチしないケースに適用するものであって、受け入れられないってのは単に説明が足りないとかそもそも不要なんじゃない？

うちでの適用例だと、スマホゲーで永続化不要なリアルタイムPVPでredis使ってる
数分の間だけ桁違いなアクセスがあって、結果格納後はゆるゆると破棄される、みたいな奴です

RDBでもインメモリでチューンすりゃやれんことはないのかもしれないすけど、逆に言えば無理してRDBで実装する理由が無かった。正規化もjoinもいらないし、ただ淡々と行動ログを取って状況を配信し続けるだけなんで。
こんなんnodeあたりでアプリ側インメモリでも良いケースでもあるけど

在庫管理って、基本は最後の棚卸から現在までの受払データのsumが現在の在庫になる、って方針だよね。

個々の受払のデータを持ってなくて、その都度商品マスタと1対1のテーブルに在庫数値を更新する、って方針はあまりないよね。

昔のCOBOLのシステムだとそういうパターンもあったなあ
最新在庫問い合わせのレスポンスの問題で
ただ、その場合も受払の明細データはどっかに持ってる

最新の在庫数持つよ
計算面倒くさい

>>842
>>843

レスどもです。

確かに、毎回アクセスするたびにsumするのは負担がかかるから、更新時にsumして保存するのがよさそうですね。

今やってるシステムは、受け払いの履歴をもってないんだよな。。。。

テーブル名付けるときって、何文字以下にするみたいなこと考えてやってる？
内容を正しく表すことと、他のテーブル名との一貫性をきれいに保たせようとすると、どうも長くなってしまいがちなんだが

今だとKVSにSUM入れて推移はRDB管理がよろしいかと

古いDBは6文字短縮名が多いので可能な限り合わせてる
ERDの論理名は冗長やけどね
新しいプロジェクトだと短縮名英字テーブルに全部冗長な日本語名のビュー被せてる形式
その際は文字長の制限無し

>>846
なるほどです。

>>845
文字数制限厳しい糞DBMSならそこに納めないといかんが、
そうじゃないなら好きにしろ。
プログラムコードの識別子と同じで無理に省略はしなくていい。

ただあんまり長いとSQL文読みにくいけどね

エイリアスで解決

そりゃ当然エイリアスは使うさ。
でも一度は記述しないといけないわけで

>>852
読みやすさの話なんだけど...

>>852
単にスコープの問題。業界にいるならそれくらい理解できないとやばくね。

長さの程度問題じゃ？

長いか短いかはともかく、桁数そろえたくならない？

SQL１発で何でも解決したくなる病にかかるやつが多いから
ほっとくとすごいことになるんだぞｗ

>>856
そういう人は芸術家になればいいと思う

>>856
全然ならん
プレフィックス付けたい病だが…

クラ鯖アプリの添付ファイルのExcelをOracle SecureFilesかなんかのBLOBに突っ込むのって最近流行りですかね？

RAC組んでてDBは冗長化されてて、添付ファイル用に冗長化したファイルサーバ立てるのもアホらしいし
どんなに大きくファイルサイズを見積もっても 1年で1GB程度しかファイルが添付されないから無難な方法かなーと思ったり。

>>860
流行りかどうかは知らんけど、普通にやられてるでしょ
バックアップとかもその方が楽だし

>>860
普段から個別に使いたいならやらないが、一元化って意味ではありやろ

就活の資料の一環として大学で実際の仕様に基づくDB設計を作ります。
自分は求人サイト（リクナビとか）向けの設計を作る事になったのですが、
それで気になることがあるので、質問です。

大体どの求人サイトも会員登録→履歴書作成→求人応募
という仕組みだと思うのですが、求人応募の際に履歴書の内容を
応募した求人毎に保存するべきなのか否か悩みます。

考え方として、
必要）その都度、履歴書の内容は変わるので、応募毎に保存するべき。
不要）履歴書として登録してるテーブルを、応募後に参照させればいいだけ。

正規化の考えから、同じ値を何度も登録させるのはおかしいと思いつつ、
応募時期によって履歴書の内容は変わったり職歴が追加されたりするので、
応募時点の情報を閲覧出来た方が企業としては良いのかな？と思ったりします。

なにぶん、自分は就活前なのでそういった求職者・雇用者の利用方法が想定できません。。
なので、どう設計したらいいか悩むところです。
求人サイトを設計した事がある方がいましたら、アドバイスください。お願いします。

固定部分は一つ、履歴書部分は別にナンページも付けられるようにすりゃいいじゃん
一つのテーブルでなんでもやろうとするのが間違いの始まり

>>863
分けた方がいいですね
理由としては常に同じ値になる訳では無いから
※「応募時期の〜」の考え方でOK

ただし、履歴書の変更修正も残したいなら下みたいな感じのが良いかと
※応募の有無に関係無く履歴を残したいとか

会員テーブル(会員ID
求人会社テーブル(会社ID
履歴書テーブル(会員ID,履歴書No
応募履歴テーブル(応募時期,会社ID,会員ID,履歴書No

履歴書の変更修正が不要なら履歴書Noが無くなり
応募の度に応募履歴テーブルへ履歴書の内容を記録

正規化は経験者でも悩ましいところですが、まず細かい仕様(どのデータをどう利用する)を確定していく事ですね

>>865
かなり詳しく教えていただきありがとうございます！

自分の中で
「応募の度に応募履歴テーブルへ履歴書の内容を記録」
というのが凄く違和感を感じていたんです。

求人サイトでは履歴書とか職務経歴書とかスキルシート？とかあるのに、
1企業に応募する度に複数テーブルに追加していくのは冗長すぎないか？と。

でも、おっしゃるように常に同じ値になるわけではないし、
1企業が1応募者の人生（履歴）をずっと見られるのも、おかしいですからね。
応募時期によって履歴書の内容が変わる、
それを保存するという考え方で問題ないのかもしれません。

テーブルや登録値を減らすことばかり考えていましたが、
それが良いとは限らないんですね。大変参考になりました！

>>863
テーブル設計以前の要求定義の話だな

>正規化の考えから、同じ値を何度も登録させるのはおかしいと
たとえば提出先毎に内容を保存できるって要件なら
複数に提出した内容がまったく同じだったら
(内部的に識別できるコード類は違うだろうが)
同じデータが複数あってもそれは正規化されてない事にはならん

会社でサーバーOSのグレードアップに伴ってDB移行しなくちゃいけないんだけど、
DB移行計画書はどんくらいのボリュームが適正かしら？
ちな、250人程度の中小企業で、データ数は20万くらい。
やっぱ端折らずに全部計画書に落とすべきかなぁ・・・

>868だけど、俺の質問はなかったことにしてください。
ごめんなさい。

期間で管理する
履歴付きマスターテーブル群を、
性能を落とさずに扱う方法はないでしょうか？
ある期間断面を切りとって、
トランザクションデータとJOINして、
断面単位で集計できるような構造。

>>870
ほんとに性能落ちてるのか？
落ちてると思い込んでるだけじゃないのか？

何も気にせずトランザクションとマスタを結合して断面としたいgroup by書けば終わる話ではないってことなんだろうなぁ

マスタを検索するときに、some_date between master.available_from and master.available_toってするんじゃないかな

期間でパーティショニングとかそういう話じゃ

どういう理由で性能が落ちると思ってるのか、あるいは現状落ちているのかを説明してくれないと答えようがない。

OLAPの話なのかなぁと思ったりシましたが

User(userid int unsigned not null primary key);
Follow(follower int unsigned references User(userid),
followee int unsigned references User(userid));
って設計ダメなんですか？

なんで？

jpaで関係作れないんですよ

>>870
履歴は量が多いなら別テーブルにすれば？
出なければ日付index

テーブルが恐ろしい量で切るな
官公庁見たく５年で廃棄だと５年分のテーブルがずらりと並ぶ事に鳴る
週単位で作っても３５０テーブルとkｗｗｗ

意識したことなかった
MySQLで週別、日別なログを回してて7万テーブルほどあるけど別に問題ないです
あえて言えばphpMyAdminが挙動おかしくなったので封じたけど

PARTITIONで分けちゃえばいい

日ごとに分けるって、1テーブルどれくらいのレコードになるの？

なんで日付事にテーブル作るって思う（笑）
マスターと履歴マスター
履歴もアクセスする事があるなら、履歴には最新も入れときゃいい。

日付ごとで別テーブルって、過去データの検索とかわざわざunionするのか？
7万テーブルのunionとか想像だにできん

日またがりの検索をしない前提なんじゃないのかなぁ。
日別のテーブルを作らざるを得ないほどのデータ量ってストレージも大変なことになってそう

業務要件が分からんから何とも
普通にindex張ってもダメなら、もうデータ分けちゃえ

そう言うときのためにパーティションングって技術があるわけだが

そもそもマスタかが疑わしい

パーティショニングて実際に使った事無いんだが、それなりに安定するの？

パーティショニングのどこに不安定の要素があるんだ？

使った事無いから不安なの
特にどこがという事は無いけど

初めてだから優しくしてね…ｳﾌｯ　　て言えばぁ？

パーティショニングは実用に耐えんかったby適当にいじって負荷テストでサーバ落として上司に詰められた無能

俺のことだ
パーティショニングさんほんとすまん
なんか1日で成果出せなければ死ねとか言われたんだ
実際には三日かかって成果出せなかった
それでも私は元気です

日跨りの検索案件も、毎日数件程度ながらあります
ダンプしたのをvirtualboxに移してから回してます
今まだ回してます

適切な対応を取れば最悪数秒で結果が出るような酷い状況じゃないことを祈るよ。

>>895
実機で負荷テストはダメやろw
日付跨いでパーティショニングされるとしたら夜中だろうし

>>896
ほとんどはこれだよな

時系列をidとしたレコードにtrue とfalseを登録する。
そして、それらの最大連続true回数を調べたいのですが、sqlで取ってくることは可能ですか？

連続数をデータベースに登録しておくべきでしょうか？

>>899
サブクエリを工夫してもできるし、ストアドファンクションが使えるDBMSならそっちでもできるはず
連続数の登録はレコード更新の競合とか面倒臭そうだから勧めない

>>900
ありがとうございます。
野球の打撃成績の管理を頼まれまして、
クエリでなんとか拾ってみます

nulldataでも作ってるのかな

「1つ先がfalseである、trueのレコード」に対して、
「そのレコードより前かつ1番近いfalseのレコード」
以降からそのレコードまでのレコード数を集計すればいいと思う
最大数を求めたいなら、その結果レコードを更に集計

最初や最後のレコードがtrueの場合も集計できるよう工夫して

自分で適当に書いたらややこしい感じになったのでネットに頼った結果、先人は偉大だと思い知り。
引き出しに入れておこう。
https://yone64.wordpress.com/2013/07/04/

独学でプログラムではじめた頃、インデックスすら知らず、
パフォーマンスが出ないためにテーブル分けまくってたのを思い出したわｗ

管理者と会員のやりとり（メッセージ）を保存して一覧表示させたいと思います。
その場合の設計を考えたのですが、
「管理者ID、会員ID、タイトル、内容、送信日」
というのは変ではないでしょうか？

というのも会員がメッセージを投稿した場合、管理者IDはNULLになります。逆もしかりです。
かと言って管理者・会員のIDが分かれているので、こうするしかない気がします。
どうするのがシンプルでオーソドックスでしょうか？