DB設計を語るスレ 4

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

PRIMARY KEYの指定されているテーブルに、
他のNOT NULL UNIQUE制約を持つカラムを入れるべきではありませんか？

例えばこんなテーブルです。

アルバムテーブル
画像id NOT NULL PRIMARY KEY,
画像名 NOT NULL UNIQUE,
サムネイル名 NOT NULL UNIQUE

これの構成を変えるとどんな感じにすればいいでしょうか？
画像名が決まればサムネイル名も決まるというルールを作ることも可能です。

>>2
その項目がNULLが入って困るならNOT NULL制約をつければシステムが保証してくれる
その項目がユニークであるなら、UNIQUE制約をつければシステムが保証してくれる
すくなくとも本番ＤＢなら付けない理由がないんだが？

>これの構成を変えるとどんな感じにすればいいでしょうか？
なぜ構成を変えるのか、構成を変えてどうしたいのか全く分からんのに
どんな感じも何もないわ。好きにしろとしか

>>3
テーブルにプライマリキーを2つ以上定義してはなりませんが、
NOT NULLでUNIQUEなカラムはプライマリーキーと同義です。
なので、プライマリキーを指定してるテーブルには、
NOT NULLでUNIQUEなカラムは含めるのは設計的に正しくないのかな？と思って質問しました。

それで、もし正しくない場合構成をどうすればいいか教えて欲しかったのです。

回答内容から付けても特に設計に問題はないと判断させていただきます。

テーブルには複数の候補キーが存在し得る。
かなりはじめの方で学ぶはずのことだが。

インデックス張るのは重くなってからのほうがいいんでしょうか？

それはただの対症療法で、
設計なんてできない人間が場当たり的な手段として考えること

やっぱそうですか。
自分は設計できない人間なので何にインデックス張るのかがよくわかりません。
とりあえずソート基準になりそうなものやselectで頻繁に指定するものにはってます。
DB設計は本当に難しいですね。

最近のＤＢＭＳなら、ここにインデックス張ると良いよと教えてくれるものもある
あてになるのかどうかはしらんが

ビューの作成について質問お願いします。
ビューは導出関係で、SELECT文をデータベースに保存したものという説明がなされています。
つまりSELCTで複数項目を選択して取り出すケースではビューを積極的に作ったほうがいいのでしょうか？
SELECT a, b, c FROM tableがSELECT * FROM viewに変わるんですよね？

セキュリティ的な要件でもなければ、俺ならその程度のＳＱＬでビューは作らん

そういうビューがあった方がいいという時点で
テーブルをそうすべきでは。
複数のテーブルを結合したSELECT文こそ
ビューにするものだろう

プロフを参照するとこの方、銀歯を作る仕事をしていたそうで（微笑）
道理で、物作りの厳しさ、商売の難しさどれを取っても何一つ理解しておらず、
突っ込み所満載なわけです
しかも過去形である所を見ると景気に関係なく黙ってても患者が来る、
病気や虫歯を直す商売でさえ勤まらなかったということでは（笑）
銀歯と金型では要求される精度も品質もまるで違います
質問者が何を作りたいのかが明らかにされていないため分かりませんが
趣味のようなもの、とおっしゃるなら趣味の掲示板で相談されたらいかがでしょうか
その分野の同好の士が良い方法を知っているかもしれませんから
もちろん、趣味の世界といえども技術は只で教えてもらえるほど甘くはないという事を肝に銘じておくべきでしょう

外から入力を受け付ける場合%はエスケープしたほうがいいんでしょうか？
LIKE検索ウインドウでワイルドカードとして使用を許可したほうがいいのか悩んでいます。
というより使ってるプログラムのデータベースエスケープ用関数が%をエスケープしないので、
そのままでもセキュリティ的には問題ないのかなぁと思ってるんですが、
色々サイトまわってると%もエスケープするべきだと書いてるところもあるのでどっちなのかなぁと。
使用DBはsqliteです。

>>14
それはホストアプリの問題だから、使ってるホストアプリのスレで聞いてください

使い方の問題もあるがな
入力した人がワイルドカードとして％入力してるならエスケープしちゃだめだろ
逆にパーセント文字を表しているならエスケープが必要になるだろ

判断がつかないならエスケープしとけ

現在のunixタイムを入れるカラムがあるんですが
それを基準に色々したりしますが
idと同じように上から下へだんだん増えていく数字です
こういうのにもインデックスはいるんでしょうか？

つ 2038
たぶん頭で考えてユニークなデータだから大丈夫だろうと思ってても
意外な落とし穴があるといけないからユニークなIDをつけとくクセをつけた方が余計なリスクがないんだということだと思う

いらないレコードをSELECT文のパフォーマンスのためにどんどん削除すると、
データベースに断片化が起きますよね？
それを掃除するのがVACUUMであってますか？
だいたいどのくらいDELETEしたらVACUUMすればいいのでしょうか？
VACUUMや大量のDELETE処理で時間がかかっても、
その間SELECT文はスイスイうけてくれますか？

ぽすぐれスレいけや。

これで独立できる

売るものはスマートフォンアプリ　WEBサイト運営
サーバーはクラウド VPS
電話はスマートフォンSkype
オフィスは地方にプレハブ型の格安高性能オフィスを建て(300万〜500万)
レンタル自習室＆シェアオフィスで収入を得ながらそこで開発する
http://tinyurl.com/43xmk7m
http://tinyurl.com/3mopkfy

テーブル名の付け方でかなり悩みます・・。

会員テーブルがあって、会員の種類に、一般・ビジネス・管理者など
それぞれ用途が異なります。

最初は1つのusersテーブルに区分を付けてまとめようとしたのですが、
各会員のカラム構成が違うので、独立したテーブルにしようと思いました。
その場合、
users → 一般会員、admin_users→ 管理者、biz_users→ビジネス会員

と言うのを考えたのですが、変じゃないか？と悩んでおり、
どうするのが普通（一般的）か気になり、質問しました。

>>21
DB設計を語るスレ 3
> 910 名前：NAME IS NULL[] 投稿日：2011/06/27(月) 12:30:37.62 ID:72GVkR7S
> あるWebシステムで「管理ユーザ」「一般会員」「ビジネス会員」を
> 1つのusersというテーブルでまとめていました。
>
> 私はこれまで、
> 「admin_users」「users」「biz_users」と3つのテーブルを作って
> それぞれの会員用途で分けていたのですが、
> 前者のように、1つのテーブルでアカウント情報を
> まとめるケースって多いのでしょうか？

それちゃんと正規化されてないんじゃね

>>22
前スレ見てテーブル名を拝借したのですが、
結局何も解決されて無さそうで、質問しました。
質問者の人は納得したみたいですが、自分はよくわかりません・・。

テーブルを三つに分けるなんてあほかというのが第一感だけど
セキュリティを考えるとありかなと思って
そうすると3か所でセキュリティを考えないといけなくなるから
とか考えて思考停止中。

管理ユーザーと二つの会員は明らかに別の実体だろ
たまたま似たような属性があるからってまとめればいいってもんじゃないぞ

別の実体かどうかなんて、あれだけの情報で判断できるわけないだろ
テーブルを分ける前提での質問だから、その是非は元の質問とは別の話だ

で、元の質問は、名前どうしよう、ってんだから、好きにしろとしか

相変わらず、テーブル名やフィールド名だけの情報から
予断を持って語るやつの多いこと。

web系での経験則ではだいたい分けてたな。
uiも腐るほど分けるのが普通だし。
人さらって何ぼだし。

>>27
それが結構重要だと思うんですよ。
名前が決まらない事には、DB設計できないと思うんです。

>>21の例で言うと、users以外にadminとbizがありますが、
「そもそもビジネス会員って何なの？その会員は他の会員とどう違うの？」
って他人がテーブルを見た時に理解できないと困ると思うんです。

で、>>25-29の間で
「同じ”ユーザ”なんだから1つのテーブルだろ」とか、
「構造自体が違うんだから分けるべきだろ」
とか意見が多々ある時点で、設計段階で"迷い”が生じてると思うんです。

その迷いがあると、後からテーブルを追加しようにも困ると思うんですよ。
各会員でそれぞれJOINするテーブルが増えてきた時とか。

もちろん、用途に寄って異なるというのは重々承知してるのですが、
会員の種類や分け方、正規化の考え方って、全く情報無いんですよね・・・
ようやく探したのが前スレのログぐらいで・・・
だからもう少し汎用性のある考え方がしたくて、質問しました。

自分としては、1つのテーブルでまとめるのに疑問を感じるんです。
「区分」や「権限」のカラムを追加して分ければいいと思いますが、
そうなると、1つのテーブルに色んな会員情報が入る事になり、
規模が大きくなると対応しにくいんじゃないか？って思うからです。

かといってその前を単純に「（種類名）_users」にするのも良いものか？
と思い、悩みに悩みが重なっている状態で、設計が進みません・・・

そうなると、1つのテーブルに色んな会員情報が入る事になり、

基本情報と個別情報を分ける

>>30
名前なんて定義に付ける記号なんだから、テーブルの物理名なんか最後においといてもＤＢ設計はできる

>「そもそもビジネス会員って何なの？その会員は他の会員とどう違うの？」
まずお前がちゃんとこれを分析（定義）できてるのか？
もしできてるなら、それをここで発表すればこのスレの人がテーブル分けるべきかどうか議論してくれるだろう

>「同じ”ユーザ”なんだから1つのテーブルだろ」とか、
>「構造自体が違うんだから分けるべきだろ」
>とか意見が多々ある時点で、設計段階で"迷い”が生じてると思うんです。
迷ってなんかないぞ。それぞれが思う勝手な要件で言ってるだけで
その要件が違うから答えが違うだけだ

>>28
じゃあどんな情報があれば判断できるの？具体的に挙げてみてよ

>>33
自分が一番悩むのは「後から追加する場合？」を想定するからなんです。
例えば、「プラン」というテーブルを追加したいとします。
一般会員なら、プランは無料・有料を分けるテーブルだと思いますし、
ビジネス会員なら、ベーシックコースとかゴールドコースとかになると思います。
（要はプラン＝料金コースですかね）

その時、>>21の考え方で行くと、同じ「プラン」でも
用途やフィールド構造が全く違うので、結合するテーブル名は分けるわけですが、

users_plan　→　一般会員のプラン
biz_users_plan　→　ビジネス会員のプラン

となって、テーブル名が冗長化していかないか？と思うからです。

テーブル名がこうなると、実行するアプリ側のファイル名や変数名も
biz_users_plan_register.php（ビジネス会員プランに登録）とか
$biz_users_plan_name（ビジネス会員プラン名）とか
名前がどんどん長くなっていく恐れがあります。
そうすると、スパゲティーコードになる元です。

そういうDB設計+アプリ設計まで想定すると、
最初のDB設計を上手くやらないと、後々困る事になるので、悩むわけです。

要件というのは、DBを使用するサイトやアプリの規模が大きくなる事で
変わってくると思うし、大きくなって対応できない設計では困ると思うんです。

すみません。>>35に書いた「冗長化」は違いました・・・。
単に「名前が長くなるとわかりづらくならないか？」と言った
問題定義をしたかったのですが、言葉の選択を間違えました。。、

アプリまで考えるってんならカラム名そのままProperty化想定がそもそも・・・
biz_users_plan_name as planNameとか書けないDBもないだろうし、
O/Rでマッピング弄るとかも余裕で可能

アプリまで考えるにはアプリを知らないと出来ないよ
スパゲッティも意味合い違うし

自分はアプリ開発も5年ほどあるので、そこそこ知ってるつもりです。
あと、自分の場合、カラム名が長くなったり、テーブル構造が増える事で
スパゲティーコード化（他人には分かりづらいごちゃ付いたコード）
する傾向にあるので、そのように書きました。

>>21の例ではビジネス会員としていますが、
「何を持ってビジネスとするのか？」と言うのもあると思います。
単純に有料会員の事なのか、お店のオーナーなのか、
広告出稿などの広告主なのか、BtoBのクライアントの事なのか。

これだけ考えても「ビジネス会員」という名称にはかなり幅広くあります。
ですので、単純にbiz_usersとしても汎用性が利かずに
何に対する会員（ユーザ）かわからなくなってくると思うんです。

ここまで説明すると、私がテーブル名の付け方・考え方について
悩む理由も分かっていただけると思うのですが・・・不足があればご指摘下さい

>>35
だからまず、一般会員とビジネス会員とはなんだという問題があってだな
これが別物なら、それぞれの操作に対して別の名前付けるのは当然だろうが

名前が長くて困ることがあるのか？お前が使うホストアプリはＤＢの項目名がそのまま変数名じゃないとだめなのか？

名前が長いから問題になるなんてことはない
名前が長いってなら、順に連番で振れよ

途中で要件が変わったのなら当然ＤＢ設計も変更するか検討する必要があるが
規模が大きくなって対応できないってのは、事前の要件定義が甘いだけだ

>>38
>「何を持ってビジネスとするのか？」と言うのもあると思います。
>単純に有料会員の事なのか、お店のオーナーなのか、
>広告出稿などの広告主なのか、BtoBのクライアントの事なのか。

つまり、ＤＢに格納すべきデータに対する要件定義もできてないのに
テーブル作って名前も決めろと？

今の段階での要件が、たとえば
・とりあえず何らかの会員管理を行う
・会員にはいくつかの種別がある（種別の詳細は不明）
ぐらいしか決まってないのに、その段階でテーブル分けるとかなんで決めてるかね
じゃあ将来会員種別が増えたらテーブル増やすのか？普通そういうことはやらんが

テーブル名に悩む前に、テーブル作るかどうか、それに何を格納するか考えた方がいいんじゃね

テーブル名の前に会員テーブルを分割する意味が判らないんだけど
一般とかビジネスって会員を形容する、従属する属性じゃないのかな
それとも一般会員とビジネス会員はそれぞれまったく異なった名詞なのかな

>>38-39
>じゃあ将来会員種別が増えたらテーブル増やすのか？普通そういうことはやらんが

自分はまさにそれをやろうとして、「本当にこれで良いのか？」
で悩んでおり、設計できない状態なんです。
だから名前すら決められないんです・・。

それに、会員種別毎にテーブルを”分けない”
という理由に納得行かないんです。

理由は「バックアップしづらい」と「セキュリティ的に不安」だからです。
1つのユーザテーブルにまとめて、カラムで種別を分けるのが
一般的だと思いますが、どう考えても上記2つが引っかかるのです。

それに、会員テーブルなら共通項は、ログインID・パスワード・Emailぐらいです。
それなら種別毎に指定するテーブル（プロフィールとか会社情報とか）
と一緒にして、「○○会員テーブル」というのを作った方が管理しやすいのではないか？
っと思い、そうしようとしたら>>35みたいな悩みが出てくるわけです。

>>39さんが書いてるように、規模が大きくなって対応できないのは
要件定義が悪いと思うので、開発前に定義を詰めたいのですが、
”会員”という定義一つとってもここまで悩むわけです。
（ちなみに、悩むのはあくまで”複数会員”を想定した場合です）

自分はマニュアル思考なため、出来るだけ他者と同じような設計をしたいので、
こうやって自分が納得できる答えを見つけたいと思い、
皆さんのアドバイスをいただいている次第です。

もう少し具体的に書きますと

■会員テーブル（users）
id、loginid、email、password、type

として、typeの種類によって各会員を抽出すると思います。
MySQLでビジネス会員を取得するなら、
SELECT * FROM users WHERE type='biz'

みたいにするのが一般的だと思います。
しかし、繰り返しますがこれをすると、

・テーブルのバックアップが取りづらい
・セキュリティ的に不安（全会員の情報が漏れる可能性がある）
・会員数が増えた場合の使い勝手

こう言うのが気になるため、「テーブルを分けよう」と思った次第です。
そして、分けるとなれば、名前について引っかかり、
アドバイスを求めて、あーでもない・こーでもないと悩んでおります・・。

いまいち>>21の立ち位置がビジネスの方も企画する立場なのか、データベースの担当なのか、アプリのプログラマもやるのか分からんが、
・悩む原因は要件定義が甘いから、つまり聞きとりが不十分だから
・名前は問題になるところじゃない

ER図を2パターン作ってメリデメでどちらかにもう決めたらいいんじゃないか

>>43
バックアップ取りづらいってのは理解できんな
普通ＤＢのバックアップは、そのＤＢを一括でバックアップする
そうしないとテーブル間の整合性がとれなくなるから
そのＤＢにいくつテーブルがあってもあんまり関係ないんだが？

仮にテーブル単位でバックアップするとしても
その場合テーブル数が多い方がバックアップする手間が増えるのは明白だとおもうが？

あと会員数は百でも千でも万でも、使い方は同じだが？
理論上一つのテーブルを、物理的にいくつかに分割して格納することも無いではないが
お前のレベルでは無縁の世界の話だ

結局お前のテーブル分割要因に賛同する点がいくらかでもあるとすれば
セキュリティ的要因でテーブル分割するって言うだけだが
それすらまずお前の要件定義のレベルでは話になってない

他者と同じ設計にしたいって言ってるのに、なぜ一般的と自分で言ってる方法でやらない？
自分で一般的な方法にケチつけといて同じような方法で設計したいって何言ってんだか

若輩者だし何行ってるのかよくわかんねーけど

同じ項目があるならそれは同じテーブルに
区分毎に別項目があるならそれは別テーブルにすればいいんじゃないの？

セキュリティ云々はDB構成よりそれ以外のUIやら管理体制に問題あるんじゃ？

ユーザーテーブルが減ったり増えたりするとして、
例えば全ユーザーのアクセス履歴が欲しい時にどんな設計にするつもりなんだろ
俺ならそんなデータベースに関わりたくない

>>44
全てです。自サイトの今後の発展を考え、リニューアルを検討しているのですが、
どういう仕様にすれば後々安心で、他人が見てもわかるか？
と言うのを重視しており、おっしゃるとおり要件定義が甘いので
皆さまのご指導をいただいております。

>>45
DB一括でバックアップするもんですか？
私はこれまで必要なテーブルのみバックアップしていました。

あと会員数は万単位で、サイトは1000万PV/月なんで、
現状のレベルでは無縁な範囲だと思います。
ですが、今後の発展を考えた時、
どう考えても私一人では運営できませんし、
仕様が自分本位では人に依頼してもトラブルの元です。
ですので、他者と同じ設計にしたいと思いました。

一般的な方法にケチをつけているわけではなく、
私自身がその設計について納得出来ないと設計できません。
ですので、論理的に
「これこれこういう理由があって、こういう設計にするし、
あんたが考えるリスクを避ける事が出来る」

という説明をいただけると私も納得できると思うのですが、
現状では「テーブルを分ければいいじゃん」という結果だけで
その主旨をご説明いただいていないので、混乱している状況です。。

>>47
今は、「ユーザ」は、サイトを利用する会員と、管理ユーザしかいないので、
アクセスログは一般会員のみ取得しています。

今の私の考えで行くと、
「ビジネス会員のアクセス履歴」を取ろうとする設計なら、

user_logs　→　一般会員のアクセス履歴が入るテーブル
biz_user_logs　→　ビジネス会員のアクセス履歴が入るテーブル

にしていると思います。

会員種別が違いますので、
「全アクセス履歴が欲しい」という要件にはなりづらいです。

>「テーブルを分ければいいじゃん」
そんなこと言ってるのはお前だけだ

申し訳ありません。書き間違いでした。
正しくは↓の通りです。

現状では「1つのテーブルで管理すればいい」という結果だけで
その主旨をご説明いただいていないので、混乱している状況です。。

>>51
ビジネス会員や一般会員がユーザーの属性と考えてる人は分けない
あなたの懸念している点は設計の本質ではないの

> ・テーブルのバックアップが取りづらい
バックアップとソースが等価にならないものはバックアップと呼ばない

> ・セキュリティ的に不安（全会員の情報が漏れる可能性がある）
実装の問題であって設計の問題ではない
テーブルを分けた場合の利点とやらも↓で代用できる程度のもの
CREATE VIEW biz_users AS SELECT * FROM users WHERE ビジネス会員のみ;

> ・会員数が増えた場合の使い勝手
DBMSのお仕事ですがな

管理ユーザーと会員ユーザーを
同様にユーザーの属性と考えてるやつの論理が理解できないわけだが、
そこの説明はないのか？

>>53
誰へのレス？
管理ユーザーと会員ユーザーについてなんて論点にしたものは見当たらないんだが
属性と考えてないのなら勝手に分けりゃいいじゃない

全てですって全てでスキルが足りてない
素直に上司に出来ませんって言っておけでFA
ここはDB設計で要件整理代理スレじゃねーしｗ

>>55
上司じゃなくて、自分が運営しているサイトの話しです。
「ユーザ」という考え方のテーブル設計・名称を考察しておりますので、
スレ違いでないと思うのですが・・・・

>>52
その回答に対しては理解できました。
でも、私には「1つのテーブルに複数会員の情報が入る」
と言う設計について、どうしても納得行かないんです。

それがどのように便利でどう当たり前の設計なのか、
その点については誰も回答されていませんよね？
「当然だ」と言うからには、何かしら理由があってそうしてると思うんです。

それが分かれば私が悩んでいた「名前の付け方」についても
答えが導き出せると思いますし、納得して設計出来るようになると思うのですが・・・

>>56
以下のケースで user.role ではなくテーブルで区分けされている時にどう実装するのか考えてみたら
利点が見えてくるんじゃないかなー

CREATE TABLE user (id INT, name TEXT, role TEXT);
INSERT INTO user VALUES (1, 'ちんこ君', '一般会員');
INSERT INTO user VALUES (2, 'まんこさん', 'ビジネス会員');

-- 会員なら誰でも投稿できるブログ
CREATE TABLE blog (editor INT, content TEXT);
INSERT INTO blog VALUES (1, 'chinko');
INSERT INTO blog VALUES (2, 'manko');

-- 投稿者名一覧が欲しい！
SELECT editor.name FROM blog LEFT JOIN user AS editor ON blog.editor = editor.id;

要件上、一般会員とビジネス会員を同じ会員として扱うならまとめたらいいし、
ビジネス会員と一般会員は全然扱いが別なら別テーブルにすればいいと思う

でも全然扱いが別ならそもそもデータベースを一般とビジネスで分けてそれぞれにuserテーブルでも作ったらいいんじゃないかな

みんな言ってるけど要件次第かと

>>57
実際にテーブルを作成して試しました。
このコードで引っかかるのが
「会員なら誰でも投稿できるブログ」という事って
あまりないのではないでしょうか？

同様に、「投稿者名一覧が欲しい」というケースも
”一般会員（ビジネス）としての一覧”が欲しいというケースはあっても、
会員種別無く出力するケースて、ほとんどないと思います。

「それならroleで会員指定すれば良いだけ」なのはわかりますが、
端から別物だという考えがある会員情報を、
どうして一つのテーブルにしているのか？が引っかかるのです。

>>58
他のシステムも色々と見たのですが、
一般会員の場合、ほぼ必ず「プロフィール」という情報があります。
そして、ビジネス系の会員の場合は「会社（契約者）情報」です。

1つのテーブルでまとめる場合、

// 一般会員を表示
SELECT * FROM users INNER JOIN profile ON users.id=profile.users_id
// ビジネス会員を表示
SELECT * FROM users INNER JOIN company ON users.id=company.users_id

として、常に別テーブルと結合しなくてはいけません。
それなら端から別のテーブルにして、
usersなら一般会員情報（アカウント+プロフィール込み）
bizi_usersならビジネス会員情報（アカウント+会社情報込み）
とする方が、編集・削除の面からも便利なのではないか？
と思い、「テーブルを分ける」という考え方でいます。

しかしながら、他の人の意見を聞くと「1つのするのが一般的」と言われます。
だから、私の中で考えが混乱してしまい、要件定義できずにいます。

>>60
そこまで分けた方が良いと思うのならそれでいいでしょ
会員向けメルマガの配信ログを残したりログイン履歴を残したりと思ったときに
テーブルが会員の種類だけ増えていくことに抵抗なさそうだし

自分がわかるように作れよ・・・
webprogにでも行けよしょーもない

会員種別が増えるごとにテーブルが増えていくのか・・・

>>60
ビューってしってるか？
あとお前がどれほどのシステム扱ってるかしらんが
結合せずにＤＢから単一テーブル持ってくる処理なんて実務にほとんどないぞ

>編集・削除の面からも便利なのではないか？
>と思い、「テーブルを分ける」という考え方でいます。
編集・削除といった処理はどうとでもなるから、そんなことではなく
要件（モデル）によってわけるかどうか決めろってみんな言ってるんだが

>他の人の意見を聞くと「1つのするのが一般的」と言われます
少なくともここの意見では、一般的って言えるほど優勢な意見ではないと思うが
みんな要件次第っていってるぞ
お前が別物だって言うならわければ良い。それだけ

>私の中で考えが混乱してしまい、要件定義できずにいます
まさかと思うが、お前、テーブルレイアウト決めてから要件定義しようとか思ってないか？
テーブル分けるかどうか決めてから要件定義するんじないぞ
要件によってわけるかどうか決めるんだぞ

>>61-64
はっきりいって、私の中で要件は「後々変わる」と思ってます。
現在、私が運営しているサイトでは、一般会員と管理ユーザで
問題なかったので、会員種別という概念が無く、単にテーブルを分けていました。

しかし、サイト（システム）をリニューアルさせる段階で、
会員の種別が増える事と、一般的（他人から見て）を考えた時、
たちまち、どうすればいいか？が分からなくなってきてるんです。

私が、phpMyAdminと言うツールでDBを管理しているのもまずいのかもしれません。
これを使ってアプリの動作テストをしていると、いちいちSQLを実行しないと
抽出できないので、使い勝手が悪く、だからテーブルを分けている
と言う要因もあると思います。

しかし、已然として
「会員種別が異なるテーブルに、全ての会員情報を保持しても良いのか？」
と言う疑問を感じてなりません。

せめて、「ここのサイトでは1つの会員テーブルで操作している」
と言う事例があれば、想像も付くと思うのですが・・・

君のやるべきことは要件定義であって、DB設計じゃないよ。

こんな5年経験者が居るのかと驚愕したが・・・
よくよく考えれば夏休みかｗ

>phpMyAdminと言うツールでDBを管理しているのもまずいのかもしれません。

ツールの問題ではないことに1000テラベクレル

では、仮に要件定義として、
今までの「一般会員」と「管理ユーザ」に、「ビジネス会員」を追加する。
と決めたとします。

それでも、私が悩んでいるように、テーブルを分けるか否か、
分けた時のテーブル名をどうするか？
と言う悩みが解決されないのではないでしょうか。

>>67
そう言いますが、今まで私が書いてきたような悩みって全く持ちませんでしたか？
サイトの希望や必要とする要件が増えると、必然的に持つ悩みだと思うのですが・・・

>>68
すみません。その通りでした。phpMyAdminは関係ないですね。

要件定義でやることも理解できてないと・・・。

このレベルで悩んだことはないなぁ。

>>21
良い事を教えてやろう。
1つのテーブルにまとめる理由は

テーブル数が増えないから

だ。これは非常に大きいぞw（いや、冗談抜きで

>>70
君の力量では今悩むことは意味が無い
答えが出ないし、誰かに出してもらっても理解出来ない
君の力量では今思いついてる物を完成させる事が出来るかどうかという感じ
先はその時また悩めばいい

そうそう。とりあえず作ってみれば良いんだよ。
他の人が1つのテーブルでまとめるって書いてるんだから。
素直にその設計でアプリなりサイトなり作ってみて、
それでも気に入らなければ、自分が思うとおりにすれば良いんだよ。

やる前に悩むのは馬鹿だ。机上の空論でしかない

そうそう。分けたいなら分ければいいじゃん。
何が正解だったのかは、そのうち理解できるよ。たぶん。

てか、今のテーブル構成に種類追加するだけで良いんじゃないか？
一般会員と管理ユーザと分けてるんだろ？一般会員に種類つければ。
これが一番近道であり、納得できるだろ。

おまえら偉そうに言ってて、話してるうちに前提を忘れてるのな。
ほんとに要件定義とかできるのかよ。

> 最初は1つのusersテーブルに区分を付けてまとめようとしたのですが、
> 各会員のカラム構成が違うので、独立したテーブルにしようと思いました。

>>78
Q. テーブルを分けるのはおかしくないですか？一般的なのを知りたいです
↓
A. 分けないのが一般的
↓
Q. まとめるとどうたらこうたらで納得できません！迷ってるんです！
↓
A. 迷わず試せよ、試せば判るさ！バカヤロー！ ←今ココ

持つ属性が違う以上は別のテーブルを作る必要はあるだろうけど

1. user
userid,共通属性1,共通属性2...

2.nom_user
userid,属性1,属性2...

3.biz_user
userid,属性1,属性2...

こんな感じでuserテーブルでIDを一意にするようにしておいたほうがいい
userテーブルに会員区分を持つ

その構成ならテーブル分けるのと変わらないじゃんとか言われそうだけど

会員全体という括りで処理をすることが一生ない？

横からすいません。質問です。

２つの条件を満たすユーザのみ指定のデータを閲覧できるようにしたいのですが
どのようにデータを持たせればいいか悩んでいます

わかりづらいですよね。

例えば１と２と３の顧客リストがあって（内容は同じですがリストに名前が付いている）それぞれに閲覧権限があるとします。

それだけならユーザテーブルに権限をいれておけばいいのですが、
今回はさらにユーザ毎に閲覧できる都道府県も限定したいのです。

単純に各都道府県用に閲覧できるかのフラグをユーザテーブルに持たせてもいいのですが
なんかすごい横長のユーザテーブルができてしまうような…

どうしたらスマートな感じになるでしょうか…？

>>81
SQL質疑応答スレ向けな気がする

create table prefecture (prefecture_id int);
create table customer (customer_id int, prefecture_id int);
create table user (user_id int);
create table user_accessible_customer (user_id int, customer_id int);
create table user_accessible_prefecture (user_id int, prefecture_id int);

select * from customer as c where
  exists (select * from user_accessible_customer as ac where ac.user_id = 1)
  and exists (select * from user_accessible_prefecture as ap where ap.prefecture_id = c.prefecture_id and ap.user_id = 1)

whereやorderで使うことのある
0か1のフラグ的なものや、0から9までとか短い範囲の数字しかないものにも
インデックスって効きますか？
つけないほうがいいでしょうか？
一応つけてみましたがレコードが少ないので効果はわかりませんでした

>>83

MySQLでの例（どこでも変わらんとは思うけど
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
http://nippondanji.blogspot.com/2009/04/1.html

、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。
例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を見付け
ようとしても、インデックススキャンが起きるだけなので、オプティマイザはしばしばそのようなスキャンを回避して、テーブルスキャンを選択してしまう。（その方が
インデックスと行の間の行き来がなくなるので、高速になるからだ。）ただし、どちらか一方の値を持つ行だけが圧倒的に少ないというような場合、少ない方の値を
指定すればオプティマイザはインデックスを使用する。例えばYesの行が10万行あって、Noの行が100行のとき、条件でNoを指定すればオプティマイザはインデッ
クスを利用するだろう。しかし、YesとNoの行が半々ぐらいの場合には、インデックスを利用することは殆ど無い。

結構、ユーザデータってテーブル分けて管理してる奴多いんだな
やっぱ、用途毎に分ける方が管理しやすいからか？

どうだろね。
同じ名前のカラムが並ぶようだと変だと思わんのかなあ

単に正規化してるだけでは？
どんなデータか分からないけど
好きな食べ物みたいなのは分けるでしょ

もう分けて union しとけよ

いつまでやるんだよ・・・

wordpressとかxoopsのユーザーテーブルでも参考にしたらどうだ？

このスレの住人的には第1正規形にもしないんだろうか

wordpressは1つのユーザテーブルだな。

SNSのプラグイン入れたけど、
その時はprofileテーブルと結合する形だった。

ただ、同じテーブルを使っているからか、
管理画面も同じだから少し違和感を受けたな。

質問です。次の二つならどちらが自然な設計に感じますか？

１．
顧客（顧客コード）
顧客受注（顧客コード、受注コード）
受注（受注コード、受注総額）
受注明細（受注コード、受注明細コード、明細金額）

２．
顧客（顧客コード）
受注（顧客コード、受注コード、受注総額）
受注明細（受注コード、受注明細コード、明細金額）

２

一つの受注に顧客は一つしかないという暗黙の前提が含まれてるなら２
そうじゃないなら１

ここで何回も言われてるけど、テーブルの項目名だけで設計の是非なんて判断できんぞ

>>94>>95
回答ありがとうございました。
やはりカーディナリティが判断基準なんですね。
スッキリしました。

多対多を表す対照表を、
ER図に書くのと書かないのとは
どちらが分かり易いと感じますか？
理由混みでご意見頂きたいです

文字列型でで保存するか、数値型で保存するか迷う
例えば、ショッピングサイトで、配送希望日時と、配送方法を選ばせる場合、
セレクトボックスで、
-午後 12 時 〜 午後 2 時
-午後 2 時 〜 午後 4 時
-午後 4 時 〜 午後 6 時
-午後 6 時 〜 午後 8 時
-午後 8 時 〜 午後 9 時
こういう選択肢があるとすると、
上から順に1,2,3,4,5として数値で保存（PHPの配列か別テーブルでマッピングさせる）するか、
上記の文字をそのまま文字列型で保存するか悩みます

僕の考えでは、将来上記の時間帯が変更になることも考えられるので、
そのまま文字列として注文と一緒に保存してしまおうと思ったのですが、、、どうすべきでしょうか？

その他、支払い方法として、
・代引き引き替え
・玄関先クレジット払い
というラジオボックスもあります。これはやはり数値でしょうか？？？
でもこれを数値でやるなら、前の例も数値でいいんじゃ？？と混乱してきたので、
アドバイスを求めにやってきました。。。どうかお願いします。

どっちでもいいよ。

そうおっしゃらずに。。。

>将来上記の時間帯が変更になることも考えられる
データベース設計をころころ変えるなよ
それはもう互換性のない違うアプリケーション

設計じゃなくてデータが変わるんだろｗ

>>98
その文字列と数値が1:1対応するならば扱いやすい方にすればいい。
どっちも「時間帯」に対する記号でしかないんだから。
時間帯を開始時刻と終了時刻の組で表現するとかなら設計レベルで
違うと言えるけどね。

>>98
マスタ作ってマスタのIDで管理するか、そのまま開始、終了の時間をもつか
どっちにしても文字型で保存するのはあり得ん

>>101
時間帯が変更されても対応できるような設計をしろってことで
設計を変えるわけじゃないと思うが

あれ？結局、正規化の話になるんじゃないのか、これ？

文字列で保存→ 正規化でテーブル分ける テーブルで変更にも対応？
数字で保存→ アプリケーション アプリケーションで変更に対応

一定の表示以外にも使いまわすなら素のデータでもたしといて
利用する側で加工だろうな。Webでしか使わない、という場合でも
携帯端末向けとかで表記変えることはあるし

>>105
>>98はそういう話に発展させる含みを持っているのかもしれないが、
書かれている内容だけじゃあわからんな。データ型の話だけなら>>99でFA。

PHPで〜とかでてるしこの前のユーザの人でしょ
ならどっちでもいい

文体が違うから別の人でしょ。

てか、正規化の話題多いけど、それだけ難しいとも言える。
DB設計で一番大事な部分だと俺は思うけどな。

え〜？このスレでまともに正規化が議論されることなんて珍しいぞｗ

”まともな”と定義すれば無いかもしれないけど、
少なくとも正規化に関する質問が多いのは事実だよな

>>98をdb関連の話にすると、
配送日時を別テーブルで管理することにしたとする
配送日時の時間割をxデイ以降、新時間割に変更することになったが、xデイ以前の注文は旧時間割に従わなければならない
というケースが予期される場合、どんな設計にしたらよいですか？

こんな感じじゃないのか？

おれの解は、配送日時テーブルに、IDを今度は11から振って、新時間割を入力し、プログラムでxデイ以降の注文には11からの配送日時をインサートする、かな

携帯とかの場合は、別カラムをアルターしてプログラムで携帯用のカラムをセレクトする

ところでお前らDB設計にマインドマップとか使ってる？

マインドマップってかER図でおすすめのソフト教えてください

うん、マインドマップでER図書いてるｗ

>>112
EFFECTIVE_START_DATEとEFFECTIVE_END_DATEが必要だな

>>115
やっぱりDDLとかER図から自動で書いてほしいなあ

>>117
逆に今ER図書けるのでDDL出力ないのって何？

マインドマップを出力してほしいって事だろ

>>119
よほどマインドマップが嫌いみたいだな

削除フラグのはなし
http://www.slideshare.net/syachi/ss-8808413

参照元の複合キーをサロゲートキーにする場合、
参照先で複合キー&外部キーにしていた自然キーは削除するものですか？

例
サロゲートキー追加前(BがAを参照)
A(a,b,c)(主:a,b)
B(a,b,d,e)(主:a,b,d 外部:a,b)

サロゲートキー追加後
-削除する場合
A(s,a,b,c)(主:s ユニーク:a,b)
B(s,d,e)(主:s,d 外部:s)

-削除しない場合
A(s,a,b,c)(主:s ユニーク:a,b)
B(s,a,b,d,e)(主:s,d 外部:s ユニーク:a,b)


削除する場合、Bテーブルを条件更新する時、
AとBをJOINした後に条件指定しないといけません。
(そういうもの？なら、Bを参照するCが出た場合、AとBとCをJOINしてCを取得？)

削除しない場合、サロゲートキーにするメリットが無い気がします。
(JOINはサロゲートキーで、条件は自然キーにできる？)

この場合は削除するのが普通だね。
デメリットについてもその通りなんで得失を踏まえて選択すべし。
どうしても削除しない方にしたい場合は、sと(a,b)両方の外部キーを
設定しておくという手もテクニックとしてなくはない。
サロゲートキーにするメリット？をどう考えているのかはわからんけど。

ってかサロゲートキーと、ナチュラルキーと、それ以外
って感じでエンティティが３区画に分かれるモデリングツールってある？
俺の場合はナチュラルキーをAK1(col2,col3)とかにするんだけど、
そういうのがダイアグラム上で認識できるやつキボンヌ。

つまりサロゲートキーにすると本来の主キーがわからなくなるのをなんとかしたい。

メモリ設計を易しく教えて下さい

たくさん用意しろ

質問でう。

TableAとTableBが1:Nのときに
TableBにこれといって一意になりそうなキーがないとき
TableBには連番とか振るべきですか？

キーがないとして、なにをもって1:Nと判断したの？

>>127
それはTableBの行を一意に特定できないってことなんだが、それで良いのか？

一対一と言ってる訳でもなし困ってもなさそうだし良いんでしょうね

>>128
１つの住所に対してどんな人が住んでいるか
なので１：Ｎかな。と

>>129
TableBは一意に特定することはないので問題ないと思われます


一意に取りに行くことはないので連番などは振る必要はないのでしょうか？

1件削除するのも困りそうだが、、、まあそういうケースが無いならいいんじゃない？

TableBをごっそり削除＆新たに挿入するケースでは要らないな

親のキーと同じNon-Unique Indexぐらいはればいいじゃない。

もっとも連番なりハッシュ値なりでPKにするのがいちばんいいと思うがね。

ハッシュはユニークが保証されないのにＰＫにするとか本気かと

非ユニークになるようなことが殆どないようにすればいいだけ

訂正。
TableBは一意に特定することはない
と言い切っているので
親のPKに連番だのハッシュだのくっつけて複合索引にする必要もないわな。
NonUniqueIndexだけでOK

>>136
ほとんどって．．．それでキー重複のエラーでシステム停止したらどうするんだ？
そんなのあらかじめ予見できるエラーだぞ

なぜハッシュを計算する元の値をキーにしないで、かぶる可能性が高まるハッシュ値をとってキーにするって発想になるのか理解できん

従属するテーブルには一意キーがないと言ってるんだそ。
そもそも元の値をキーにしたらどっちにしてもかぶるだろが。
元の値がなにを想定してるのかわからんが
ハッシュ値のシードとして（何かの列値＋ランダム値もしくはsystimestampが必要なんだよ

ハッシュの意味がないのでどうでもいいことだが
従属先テーブルの主キー＋求めたハッシュで複合索引にするならば
分散度を考慮すればキーが被ることはほとんどありえない。

横からだが、普通に連番にすればいいだけの話

連番＞＞＞＞＞＞＞越えられない壁＞＞＞＞＞＞＞ハッシュ値

> もっとも連番なりハッシュ値なりでPKにするのがいちばんいいと思うがね。

こんな、さもハッシュが連番と同等の提案であるかのように書くからおかしな話になる

::::::::　　　　　　　　┌─────────────── ┐
::::::::　　　　　　　　｜　またハッシュがやられたようだな…│
:::::　　　┌───└───────────ｖ───┬┘
:::::　　　｜フフフ…奴は人工キー四天王の中でも最弱 …│
┌──└────────ｖ─┬────────┘
｜　一意制約ごときに負けるとは│
｜　主キーの面汚しよ 　　　 　　│
└────ｖ────────┘
　 |ﾐ,　 ／　 ｀ヽ　/!　　　　,.──､
　 |彡/二Oニニ|ノ　　　 /三三三!,　　　　　　 |!
　　`,' ＼､､＿,|/-ｬ　　　 ト `=j r=ﾚ　　　　 /ミ !彡 　　　　 ●
T 爪| /　/￣|/´＿_,ｬ　　|`三三‐/　　　　 |`=､|,='| 　　　＿(＿
/人 ヽ ミ='／|`:::::::/ｲ＿_ ト｀ー く＿＿,-,　 ､　_!_ / 　　(　ﾟωﾟ )
/　　`ー─'" |_,.イ､ | |/､　　 Y　 /| | | j　/　ﾐ`┴'彡＼ '　　　　`
　　自動採番　　　　完全ハッシュ関数　　　連番 　　　 >>127

DB設計の一般的解法やトレンドが見られるような本とかサイトってないでしょうか。
例えば会計システムや生産管理システムはこういう風に作るもの、とか
ソーシャルアプリならこんな感じでテーブル分割する、とか。

今日あるところで、
生産管理システムでの製品と部品の関係
（部品が集まると製品となるが、その製品もさらに大きな製品から見ると部品）
を表すテーブル設計のサンプルを見かけましたが、そんな感じで。

オープンソースのWebアプリのテーブル定義などは少し見ているんですが
いろんな分野のが見てみたいです。
出来れば簡単でいいので見所の解説入りで。

聞いたことも見たこともないな。

うーん、ないですかね。

まとまってるサイトなどがなかったら、個々のシステムごとの
「うちはこの問題をこう解決した」
的な話でもいいです。

例えば自分が知ってるのだと、リンクは出来ませんが2006年に発表されてた
mixiのDB分散アーキテクチャ、レベル1・レベル2の話は
テーブル分割が必要なほどの大量データをいかに配置するか、
というのの参考にとても良いと思いました。

KVSとRDBMSは、まったく違うもんだと思ってる。

>>144
生産管理のはあるけど
ソーシャルのはないと思うね

>>145
もし144へのレスでmixiの件だったら、
当時のレベル1、レベル2ってのはKVSじゃないです。
関係なかったらすみません。

>>146
ぜひ生産管理の教えてください。

>>147
ISBN4-534-03473-3とか

設計屋の飯のタネだから、みんな出したがらないんじゃないか

>>148
おお、まさにこんな本があったんですね。ありがとうございます、見てみます。

>>149
ノウハウが案件特有の条件に関係しすぎて
守秘義務で出せないってこともあるかもですね。
でも知りたい。

検索用にタグ機能を作りたいんですけど
どんなテーブル構造にするのが一般的ですか？

｜　記事ID　｜　タグ　｜
で記事IDを重複キーにするか

｜　記事ID　｜　タグ１　｜　タグ２　｜　タグ３　｜　・・・　｜
で記事IDをユニークキーにするか

タグの上限は未定です

上限未設定なら自ずと答えは見えてるじゃん

>>142
> 今日あるところで、
> 生産管理システムでの製品と部品の関係

自分は情報出さないが
情報はくれってか？

>>148
速攻でアマゾン発注した
有益な情報ありがとう

9999-01-01と9999-12-31のどっちが好きですか？

9999-99-99 ははねられるな、、9999-09-09 うーん、9月9日に
バグ出したとこあったよなｗ

たしか99-09-09だったかなー1999年の話だな

>>155
でもnullさんの方がもっと好きです。

昨今は終了日とかってNULLの流れ？

自分は9999-12-31だな。
「終了してるかどうか」を見るのに、
WHERE end_date >= now() OR end_date IS NULL
とか無駄すぎる。

普通終了日だと、終了した日（か終了予定日）が入るもんじゃないか？
「終了してるかどうか」なら、
end_date <= now()だと終了、それ以外なら終了していない、って判定で良いんじゃないかね

>>161
終了予定日が決まってないデータをどうするか、って話の流れだと思うんだが。

それをNULLにしてると、
終了しているものを取得するなら end_date < now() でいいけど
終了日が条件になるのは、終了してないものを取得して表示したい、って時だろうから
end_date >= now() OR end_date IS NULL
になっちゃう。

なっちゃっても別に問題はないけどな。

条件が増えるとそれだけパフォーマンスが落ちると思うが。
しかもOR条件やNULLってインデックスが効かないんじゃなかったか。

インデクスにNULLを含められるDBMSならインデックス一応効くだろ

たとえば9999-12-31が終了してるという意味ですよ、とするなら
終了日が必要な場合、別途項目が必要になる
それなら素直に終了日もってれば良いんじゃないかと

まあ9999-12-31入ってる項目がなんの項目何だよって話はあるが
終了してるかどうかにNULL判断したくないってなら別途フラグ項目持てば良いんじゃね

>>166
> たとえば9999-12-31が終了してるという意味ですよ、とするなら
誰もそんなことはしないと思うが……。

すまん、途中で送ってしまった。続き

>>166
商品の販売終了日とかで、
終了日が決まってないレコードは何を入れる？

だから、NULLでいいんじゃね？

どうしてもnull入れたり、or条件の検索行いたくなければ、元のマスタには開始日だけもち、終了日は取扱い終了マスタのようなので別管理。
検索は、inやexistsを使う感じになるんじゃないの？

ああ、NULLにしてるってことなのか。
今のところ終了期限日に9999-12-31で問題がある理由が見つからないので
170みたいな定義にはしないけど、
NULLが主流だという話は理解した。ありがと。

9999/12/31って直感的じゃないよね
なんとなくセンス悪そう

インデックスにNULLを含められるかどうかにかかわらず
NULLにするほうがDB屋としてセンスないけどな

どんなセンスだｗｗシックスセンスか？

between使う状況を考えてみろ

nullを最小値とみなすか最大値とみなすかはDBMS依存だな

外部結合以外でNULLが出てくるのは三値理論の理解を根本的に間違えてる。

NULLをまともに取り扱えないプログラマは、項目にNULL入れる設計嫌うよね

アホか。そういう問題じゃない

uniqueじゃなきゃ困るだろ

>>177
非キー属性がキーに完全従属するならば、属性ごとに分解したテーブルを
外部結合するのと等価なんだがな。

お前らな〜、null間違った使い方してるとDB神(ゴット)が泣くぞ

神託（,Oracle）ですか？

CHARで0000/00/00と9999/99/99にせよとお告げがあった

文字列の扱いで不用意にnullが混入する下地を作ってしまったオラクルは神を冒涜する邪教だと思う。

オラクルって未だにnullと空文字列を区別できないの？

そこを変えるとえらいことになるからなｗ

>>180
終了日付がuniqueである必要って何よ？

皆さんはコードの持ち方ってどうしてますか？

区分カラム作って１つのテーブル？
コード毎に１つのテーブル？

いくらなんでも質問が端折り過ぎだろ…

>>189
例えば、性別(男、女)や続柄(兄、弟、父)をコード化して管理する時、一つのテーブルに性別列と続柄列を作るか、別々のテーブルにするかってこと？

頑張ってエスパーしてみたが、前者のような設計なんて考えられないので、もっと別のことが聞きたいんだろうな。

>>189
もしくは、コード列と名前列をもつテーブルにすべてのコード体系を詰め込みたいのだろうか？

パラメータを管理するために、年度や税率を一つのテーブルに詰め込んだりはするが、コードの管理ではやらないな。

key-value モデルだとありうるな

例えば、携帯キャリアごとのプランマスタ、というテーブルなら
ドコモプランマスタ、auプランマスタ、というふうに
3キャリアそれぞれに個別のマスタを持ってもいいけど、

|プランID|キャリアID|プラン名|価格|補足情報…|

みたいな構造はありえるかも。
この場合、キャリアIDカラムが、>>189の言う区分カラムになるかな。
同じ意味で括れる情報なら、まとめておいたほうが便利なこともあるので。
システムからみて全く意味の異なるものはまとめないと思う。

>>189
まずコードと区分とは何かをはっきり定義してくれ

>>191
いや、たぶん
区分,コード,名称
1,1,男
1,2,女
2,1,兄
2,2,弟
2,3,父
なテーブルを想定してると思うんだが

RDB設計のセオリーからは外れるけれども
汎用的な設計にするなら十分ありだよ。

実質的に
外部キー制約かけられないだろ
ないな

tes

わお書き込めた。
すいません。書き込んでないと思ってました。。

区分カラム作って１つのテーブルというのは
>>195 さんの感じであってます。

コードの数だけテーブルがあるのでどのコードがどのテーブルなのかとか
管理が大変とか思ったことありませんか？
オブジェクトブラウザなんかでテーブル一覧から必要なテーブル探すのにも
テーブルの数が多いと探すのがめんどくさくて・・・。

それで ID と 名称 だけでいいような単純なコードはひとつのテーブルに
まとめちゃえばいいのでは？と思ったのです。

でもそうすると結合するのがめんどくさかったり遅くなったり
>>197 さんの言うように制約かけれなかったりと問題もでてくるので
どうしようかなーと。

コードだけスキーマ変えるとか・・どうだろ。。

>>197
ERPの設計見たことある？

見たことないんだが、
そのレスは>>195形式のコード値テーブルで
外部キー制約かけれるってことかい？

無理。

リポジトリのようなものならアリなんだろうが

区分付けて一つのテーブルに全部のコードいれたら、今度はその区分の管理に苦労するだけだな

再帰結合用の外部キーの値ってルートはNULLにするのが普通？
今までは自身のレコードのキー入れてたんだけど

NULLにしたほうが見た目判りやすいとおも

DBMSにもよるけど
Oracleだとルートを探すときにインデックスが効かないな
LEVELカラム作って0とか入れればいいんじゃないかな

ツリー構造の親を示すべきカラムに自分自身を指定するのはセンスがおかしい

参照制約かつ非NULL思考だと自身になると思う

>>208
NULLは不定を表すのだから親が居ない事を表すために使うのは妥当でない、
と気にする人なら「親を持っているか？」というカラムを追加したらいい
誰が親かは分からないままだが、親の有無だけははっきりする
NULLを入れたら死んでしまうようなNULLアレルギー患者には悪いがつける薬は無い

>>207
RDBの場合に限れば話は別

キーをDB自動採番の場合めんどくさいことになったんで疑問に思ったんですが
パフォーマンスとか関係ないケースなんでNULLで良さげですかね
意見ありがとうございました

NULLが不定なのではなく、NULLとの比較が不定なのだと思うのだが

>>195は、複合PKだからやめたほうがいいと思う。

uint利用なら何も考えずNOT NULLにして、
NULLの代わりに-1突っ込んでるがダサいのか？

uintって符号なしってことか？
符号なしで定義しといてマイナス突っ込む神経は理解できん
ＤＢＭＳ何かしらんが、そもそもそんな操作は結果保証されないんじゃないか

いやすまん、PG側はマイナス使わない前提で-1を無効値扱いってこと

営業日の計算ってどうやるの？

カレンダーをテーブルで持つと楽。
年次処理で来年度分を作る必要があるけど。

>>216
なんつーか、先祖返りだなｗ
データの定義域には含まれないがそれを格納するデータ型の定義域には含まれる
ある値で無効値を表すという手法は、データ型によって扱いがまちまちになるし、
そもそもデータの定義域=データ型の定義域である場合は使えないから、汎用的に
使えるNULLというものが導入されたのに。

電話番号を１カラムに市外局番から加入者番号までいれるべきか
それぞれ別カラムに市外局番・市内局番・加入者番号を作るべきか

一カラムに決まってるだろ？
システム的に分けるメリットがない。

数値にはNULL入れないな
文字列もオラクル以外ならNOT NULLだ

その電話番号で何をするかだな
だが１カラムにするとカッコやハイフンどうするんだって話になるから
素直に全部わけといたほうがいいんじゃね

カッコとかハイフン位置ぐらい自動で判別しろよ

>>220
全部１カラムでもつと、市内局番が桁数変わったりするときに面倒な気がする
特定市外局番だけ、とか、特定市内局番だけ何かしたいって要件がないなら１カラムで良いんじゃない

>>224
市外局番と市内局番を分離するのは、市外局番のマスタ持たないと無理だったはず

ありがとうございます

カレンダーを作って翌営業日を出すところまでできました
翌々営業日は翌営業日の処理を繰り返すとできるのですが
他にうまい方法ってあります？

>>226
カレンダーの日付を昇順で数えて1個目が最初の営業日、2個目が翌営業日でしょ
その通りクエリを書くだけじゃないかい

カレンダーにあらかじめ営業日の連番を打っておけば簡単。

前スレでJOINすると遅くなるというのは初心者発想って話題になってたけど未だにその意味が分からん・・

そいつは非正規化の意味がわかってないんだろうな。

そいつがSQLを書くのが遅くなるという。

複雑になれば考える時間が多くなるって程度のことなんじゃ？

ああwhereだけで書くと可読性下がるって事か

はあ？

おれもどこかで「正規化しすぎるとJOINでパフォーマンス落ちるからあまりやらないほうがいい」
なんて文を見てだまされていたけど、ばりばり正規化してJOINしまくったほうが
パフォーマンスも汎用性も拡張性も良かったという。

JOINした3テーブル以上の巨大な各テーブルに抽出条件が分散してしまう様なケース、つまりどのテーブルから見ても単独ではデータが絞り込めないような場合、パフォーマンスは悪化しがち。
残念ながらそう言う時に、パフォーマンス出すためには非正規化が必要。

今ならインデックス付きのビューが使えたりして、必ずしもその必要はないかもしれん

データモデルを非正規化するんじゃなくて
あくまでもクラスタ化されたビューを作るイメージだな。
そこを勘違いしちゃいかんな。

クラスタ化前提ならDB設計関係ないやん

正規化が面倒だから、適当に作ってパフォーマンスのために崩したと
言い訳するケースのなんと多いことか。

頻繁に並び替えを行うので、
ソート用の項目を作りました。
数字が小さいほど優先度を高くする方式では大変なため、
cssのz-indexの要領で大きい数字の優先度を高くしたのですが、
並び替えでdesc処理をしなくてはいけないため、
遅くなるので困っています。
うまい解決方法はないでしょうか？

とりあえずその項目にインデックス付けるしかないんじゃね
ＤＢＭＳによってはインデックスに降順指定できたりするかも
ＤＢＭＳによってはデータ配置をその項目順に指定できたりするかも（逆順で指定できるかはしらんが）

降順だと遅いって、ちゃんと昇順と比較した結果か？

>>241
どのDBMSなのかぐらい書くべし。

INSERT後にINSERTしたものをUPDATEするトリガーがあります
INSERT時にはDEFAULT値を入れてるカラムで
このトリガーを使用することで初めてユニークな値になります
このカラムにたいしてUNIQUEキーを指定するのは問題ありますか？
内部でどんな処理が行われてるのかよくわからないのですが

ロック
INSERT
TRIGGER
アンロック

ならよさそうですが

INSERT
INSERT←別の人がINSERTしたがDEFAULT値で入るのでUNIQUEでないと怒られる

だと問題がありそうです

トリガーを使わないでINSERT前にSELECTしてもいけるのですが

トランザクション
SELECT
INSERT
コミット

ユニークキーを指定する場合無難に後者にするべきでしょうか？
それとも前者で問題ないでしょうか？

どんなトリガーなんだ？

INSERT後にUPDATEしてそのユニークカラムの最大値+1を入れてます
自前オートインクリメントみたいなものです

>>244
君も何のDBMSかぐらい書きなさいよ

俺はINSERT文自体にサブクエリ書いてるよ

>>244
ありがとうございます
DBは複数を想定しています
PgSQL MySQL SQLiteあたりのフリーのものです

重要な処理はDB側に持たせると安心なのでトリガーにしましたが
INSERT中にサブクエリ書いたことないので書式がわかりませんが
ちょっとやってみたいと思います

制約がどのタイミングでチェックされるかは、SET CONSTRAINTS で制御可能なはず
実際にやったことはないし、ＤＢＭＳによって実装されてるのかどうかもしらん

http://wikiwiki.jp/hon/?Andromeda
このデータをうまく正規化しようかと思ってるんですが

カテゴリ分けしてみてください

ヒーロー名,ステータス、カテゴリ（メージ、ファイター）

ちょっとやってみてください


テーブルをここに出して見てください

こういう変更の少ないデータはテキスト保存のほうが早い気がする

いいから早く出して見てください

テーブルを

ここはDB初心者スレじゃねえからなあ....

まずは自分で設計してみて、それに対して指導/批評を住人に求む、
という形で再カキコしてみてわいかが？ >>250

253の場合はどうやって設計しますか

スキルレベル１、２、３、４あります

しかもスキルは4つとは限りません
可変長です

どうしますか
教えてください

+---------+----------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------+----------+------+-----+---------+-------+
| stid | int(11) | NO | PRI | NULL | |
| str | float | YES | | NULL | |
| agi | float | YES | | NULL | |
| int | float | YES | | NULL | |
| hp | float | YES | | NULL | |
| mana | float | YES | | NULL | |
| armor | float | YES | | NULL | |
| marmor | float | YES | | NULL | |
| range | float | YES | | NULL | |
| as | float | YES | | NULL | |
| ms | float | YES | | NULL | |
| dmg | char(30) | YES | | NULL | |
| type | char(30) | YES | | NULL | |
| istr | float | YES | | NULL | |
| iagi | float | YES | | NULL | |
| iint | float | YES | | NULL | |
| ihp | float | YES | | NULL | |
| imp | float | YES | | NULL | |
| iarmor | float | YES | | NULL | |
| imarmor | float | YES | | NULL | |
+---------+----------+------+-----+---------+-------+

正規化じゃなくてテーブル作ってください、レベルじゃないかｗ

宿題スレじゃないから。以後スルーで。

>>252
すげーなおい

>>252
わろた

>>252
異次元からの来訪者だなw

下手に答えるよりも>>252を弄るのが面白そうだw

はじめて利用させてもらいます。

MYSQLを利用して、Web販売システムを運用しています。

何を思ったのかクライアントがASPサービスとして現在のシステムを
使いたいと案を出されたのですが、こういった場合
会社ごとに扱う商品のテーブルを作成していく物なのでしょうか。

例、campanyA_product_table campanyB_product_table .....

基盤となる商品については、メインテーブルがありまして
こちらからASPを利用されるお客様が選択していく形となってます。

>>262
顧客と商品の関連を後付けするだけでよくない？
select * from 商品 join 顧客が選んだ商品 using (商品ID) where 顧客ID = 'hoge'

ASPなら別DBだな。

普通会社ごとに別ＤＢにするだろｊｋ

本当にそうだろうか？
ユーザー視点だと、物が買えればいんだから、
販売元がどこの会社だから、とか必ずしも興味がないよね。
むしろ、一度に調べられた方が都合がいい。

そーいった要望に応えるたまには、
会社ごとのDBを別々に検索してくるん？

要は要件しだい。

要件ちゃんと書いてない >>262 にまともな答えは出ないと思う。

すみません。
MacBookAirを鞄に入れて移動中にコーラを買ったのですが
ノンカロリーのブラックが出てきました。

まあ、仕方ないと一口飲んで鞄にしまいました。
気づいたときには、わたしのAirが...

運が良かったことに、ノンカロリーのため
糖分でべと付かなかったことですかね

動くんですが、調子が悪くて落ち込んでいました。
明日、改めて要件を書きたいと思います。

ちなみに今、わたしの机の上にあるAirは
動いていません。　

チラシの裏にでも書いてろﾊｹﾞ

>>266
それってASP？

>>266
この場合の会社ってのは、ＡＳＰサービスを利用する利用者の事だと判断したんだが

ところでお前らチューニングとかしてる？
今のDBはSQLレベルでチェックするだけで十分だよな？

半年に1回くらいインデックスの再構築はする

>>273
ある程度規模が大きくなるとチューニングは不可避

チューニングって、設計段階での考慮じゃなくて、本番開始してからの見直しってことだよな？
>>274 なんかはチューニングってより保守作業って感じなんだが
実際問題チューニングってどんな作業がある？
設計当初のあまさや見込みが外れてそれに対する修正とか？

インフラ側だけでも、パラメータやファイルの配置をいじってみたり、とかいろいろやることあるじゃん。

>>276
設計段階で考える必要があるもの→ソーシャル、DWH
正規化してあれば運用後でもなんとかなるもの→バックオフィス

設計と言ってもこのレベルの話ではないかもしれませんが、
ここ以外にお話をうかがえそうなスレが見当たらなかったので失礼します。

生産管理システムを構築中です。部品の管理単位は設計図上の番号でやっています。
塗装や研磨については設計図上の番号とは無関係になってしまうので、

加工マスタ　（部品ID, 加工コード(0：完成部品、最大：組み立て・未加工品), 加工名, ・・・）

在庫データ　（部品ID, 加工コード, 棚卸日, 棚卸時点在庫数,　・・・）

入出庫データ　（　部品ID, 加工コード, 受払日, 入出庫種別, 数量, ・・・）　’入庫、出庫、不良など。

というような形で作成しようとしています。
まずは、この方向性は正しいでしょうか？もっと優れたモデルがあるのでしょうか？

次に、工程見直しで加工が追加あるいは省略された場合の流れとして、
追加の場合、
・ 追加を指定された加工コード(含む)より大きいものの加工コードを＋1する
・ 新しいレコードを追加する
削除の場合
・ 指定された加工コードより1大きな加工コードを持つレコードに在庫数などを合算する
・ 指定された加工コードのレコードを削除
・ 指定された加工コードより大きいものの加工コードを-1する
という感じで考えています。

この方向性は正しいでしょうか？もっと優れた処理があるでしょうか？
教えてもらえるとすごく助かります。

加工コード、ってのが微妙な感じだな。それって加工状態を示してるんだろうから、
俺なら加工状態マスタを作ると思う。

それもう既にマスタじゃないっしょ

>>281は>>279宛てね。

すみません。加工以外の部分は、

部品マスタ　(部品ID, 部品名,・・・)

構成マスタ　(親部品ID, 子部品ID)

の様に構成してあります。

その部分はすでに動いているシステムを移植中です。
加工関連部分が今回追加になり、Access　VBAで動いているものを可能な範囲でDBMSの関数で書き直して
Accessへの依存度を下げて将来的にはPHPなどでブラウザからも使えるようにしたいです。

>>279で言ってる「加工マスタ」は、
「部品ごとにどんな加工状態があるか」を示すテーブルじゃないの？

>>280
加工状態マスタとはどんなものでしょう？
部品ごとに加工内容、加工時間などが変わってくるので、加工マスタに集約しようとしています。
やりたい事は
・ 「今の部品在庫で期日までにいくつ作れるか」のシミュレート
・ 在庫の管理
・ 部品の手配の支援
等ですので、


>>281
どういう意味でしょう？よくわかりません。

280、281、284 の説明でわからないなら、あきらめた方がいいよ。

285=279です。失礼しました。

>>284
そうです。
「部品ごとにどんな加工状態があるか」マスタです。

ようは、↓みたいのは止めとけって話だろ

・ 追加を指定された加工コード(含む)より大きいものの加工コードを＋1する
・ 新しいレコードを追加する
・ 指定された加工コードより1大きな加工コードを持つレコードに在庫数などを合算する
・ 指定された加工コードのレコードを削除
・ 指定された加工コードより大きいものの加工コードを-1する

>>285
まず感覚的に
工程見直しが主要な関心事として業務フローにあるなら
マスターってよりトランザクションに感じる

あとマスターならコードを滅多やたら弄るもんじゃないっしょ
それを参照するトランザクション系テーブル達が困るから
サロゲートキー使ってるわけでもなさそうだしね

つまり、リナンバーするような行為はヤメトケという事ですね。

加工マスタ(部品ID,加工状態ID,加工順位(0：完成部品,最大：組んだだけの状態),・・・)

のようにして、在庫や入出庫は　部品IDと加工状態IDをキーにした方が良いという事？

全体的に要件がまったく解らんので何とも言えんが

部品を加工するってどういう意味合いだ？
部品（完成品）の製造工程として加工という工程が増えるのか？
部品（材料品、完成品）を加工することによって新たな部品（完成品）が発生するのか？
もしそうなら、加工前の部品（完成品）と加工後の部品（完成品）は同じ部品じゃない（＝同じ部品IDを振ってはいけない）

それを踏まえたうえで在庫管理は何を管理したんだ？
>在庫データ　（部品ID, 加工コード
>入出庫データ　（部品ID, 加工コード
在庫、入出庫で部品IDと加工状況が必要になるなら、加工途中（＝生産途中）の在庫状況が必要だってことか？

工場の生産管理・資材管理システムです。
製品部品展開での部品在庫数の管理システムが存在しています。
それに加工に関する部分が抜けているのでそれを追加しようとしています。
部品自体は設計図上の部品コードを元に管理しています。

例えばの話で、PCを組んでる工場だとして、
マザボにCPUとメモリ組みつけるのは部品の組み立てですよね。
設計図面にもそういう風に表現できると思います。
ヒートシンクにグリースを塗る様な作業は設計図面には注意書きにしかならないので、その辺が今まで実装されていませんでした。

※ 実際の現場ではバリ取りとか塗装とか注油とか焼き入れとかそういう作業を想定しています。

確かに部品自体が塗装などの状態が違えば違うものとしてモデリングするというのもわかりますが、
部品マスタに「部品番号１バリ取り前」「部品番号１塗装前」「部品番号１仕上がり品」みたいにするのは使う側にとって分かりにくいかなと思ってました。

部品を状態毎に1つの部品扱いにして組み立ての構成で子部品が1個の構成で加工を表現すればロジックを単純化できるのは分かってるんですが、
工場の人が構成を入力するので加工と組み立てを別にした方が良いかなと思っていました。

定石としてはやっぱり製品部品展開の中に加工自体を組み込んじゃう方が良いのでしょうか？

つまり今まで製造工程については何も考えてなかったんだろ
部品（製造材料）ごとに加工工程があるって設計はやめた方がいいんじゃね
製品部品展開（構成マスタ）に加工工程組み込むのも俺はお勧めしないが
製品部品展開はあくまで材料を使うものしか入れないようにする
ちゃんと製造工程マスタみたいなのをつくり、そこに組み立て（材料消費あり）、加工（材料消費なし）とかちゃんと区別して入れる
そして製品（部品）製造工程データで生産品ごとの工程と必要な日数とか、使う部品とか作業場所とか使う機械とか入れる

一般的なパッケージだと・・・
加工の特徴はBOMを使わない，一連の加工の途中に中間在庫を持たない
のが違い．

そいう機能のないパッケージの場合はダミーBOMをかませる．
加工前，XX加工後，XXX加工後・・・・てな具合．でもマスタ設定めんどくて嫌がられるよ．

工程の定義だが，もっと細かい「設備」や「運転」の概念がある．
マシンが３台あっても旧型新型があり能力もリードタイムも作れるモノも違うとか．

バッチ運転なんてのは設備で括るからね．バリ取り，メッキ，熱処理なんか
一台のマシンでまとめてやることがある．運転条件として一緒に処理が
できるものとできないものがある．

さらに言えば冶具なんかの「減らないけど必要」で「排他使用」のものもある．
「ベテラン職人」なんてのもココで設定したりする．材料もマシンもOKだが
「その人」がいないと着手できなかったり加工できなかったり．

手間と漏れリスクを考えるとパッケージ買ったほうがいい．

は？ DB設計スレでパッケージ買えって・・・

一昔前じゃ
パッケージ屋はパッケージだけは買うな
構築させられた奴はパッケージ買え
だったのにな、今の若いもんは能力に見合わない自信を持っておる

>>296
ひと昔前の良さが全く伝わらないぞw

既存システムの移植・改修は決定事項なのでパッケに頼る事は出来ないです。orz
元々組み込み屋出身でDB屋ではないのでこんな簡単な事でも分からず恥ずかしい限りです。

さっそく見直しを掛けました。

構成マスタ (親構成ID, 子構成ID, 使用個数,・・・)　キー 親構成ID, 子構成ID

構成マスタサブ(構成ID, 部品ID, 加工ID)　キー 構成ID

加工マスタ(加工ID, 加工名, 加工時間・・・) キー　加工ID

部品マスタ(部品ID, 部品名, ・・・)　キー 部品ID

在庫データ（構成ID, 棚卸日, 棚卸時点在庫数,　・・・）

入出庫データ（構成ID, 受払日, 入出庫種別, 数量, ・・・）　’入庫、出庫、不良など。

この方法ならリナンバー掛けるようなメンドクサイ事態は避けられそうです。
また、組立の時に加工マスタの1レコードにを子部品全部分の加工時間などをまとめられるので良さそうです。

既存の構成編集機能が弱いのでかなり強化しないとマズそうですが、
その辺は手続き言語で何とかしようと思います。

みなさんありがとうございました。

>>298
「加工」は加工だけで組立工程は含まないの？
仕掛とか工程間の在庫とかは必要だし部品表とかけあわせた時に
「工程」のマスタがないとハマる。

構成と加工は独立かい？紐付けて構成・加工マスタにするのか？
（NCとか、複数工程に同じマシンの使いまわしがある事もある）

部品に版数とか複数メーカーとかつけておいたほうがいい。
ライン出庫には入らない、気にしてない場合も多いが発注するとき困るぞ。

入出庫にはfrom-toを入れるようにしといたほうがいい。
入りには「どこから」、出には「どこへ」
こうしておけば保留状態なんかも管理しやすくなる。
カッチリしたシステムにするならキーにするんだが、キーにせずとも
項目だけは入れておくと後々イイことがある。

あと在庫だが・・・在庫に限らず「場所」の定義がないとアカンだろ。
ラインの棚卸もするんなら倉庫だけじゃなく工程も定義すべきだ。

リナンバーについてだが、「もし変更が起きたら」を各現場でシミュレート
してみるといい。しかかってる現物をどうするか？の観点が大事。

まあ、ＤＢ設計以前に要件定義の問題だな

ぶっちゃけ完璧な要件定義ができればＤＢ設計なんて
組み合わせと並べ変えだけといってもいいんじゃね

そこまで行けばデザインツールで自動生成だろ

>>300
でもって大抵のビジネスアプリは画面からDB読んで書くだけ

そもそもある程度以上の規模で、
完璧な要件定義なんてできたことあるか？
要件定義が完璧だと信じてガチガチのテーブル設計にして、仕様変更にうまく対応できないことの方が多くないか？

>>303
仮にその時は完璧でも、そのうち要件が変化していくのが世の常。
だから、「ガチガチのテーブル設計」なんてするのは素人のやることだろ。

要件定義が完璧かはともかく、仕様変更は要件の変更だろ
仕様変更があればテーブルも再設計・変更するのは必然

だが実際それに工数だしてくれないんだよなぁ

>>304
もっともらしい意見にも見えるが、それってユーザー側の要件を設計側で勝手に拡げて
いるわけであって、そこで行っているのは「変化」の予測なんだよな。
だからその予測を外れる「変化」があったら役に立たないし、設計者の予測がユーザーより
正確であるとも限らない。
まぁ、同じようなシステムの構築経験が何度もあるとある程度パターンがわかるし、その
会社でのやり方しか知らないお客さんより大局的に見れたりというのはあるけれど。
ただしそれは、あらかじめ予測できるものであれば事前に要件に折り込むか判断しておく
べきであって、後からの要件の変更とは区別すべきものだとは思うが。

現状でベストと思われる設計をすれば良いんじゃないのか？

何がベストかが問題だ

>>305
> 仕様変更があればテーブルも再設計・変更するのは必然

そんなことはないだろ。できるだけテーブルに影響しないようにするのは常識だと思うが。
もちろん、すべてテーブル変更なしにできるなんていってるわけじゃないよ。

>>306
> あらかじめ予測できるものであれば事前に要件に折り込むか判断しておく

だからそうしろって言ってるんだが...。何が言いたいのかさっぱりわからん。

>>307
このプログラムは、どうせ 2000年まで持たないから年号は二桁でいいよね？ (遠い目

スレ違い。

>>309
ん、違いがわからんか。
つまり、将来の変更への備えが必要だと気づいたなら、要件の方にfeedbackしておけということだ。

>>309
事前に予想できるなら、もちろんそれに対応できるようにテーブル設計するぞ
ただその場合は>>306の言うように要件として織り込んでおく
事前織り込み済みの変更なら仕様変更ではあるが要件変更ではないかもしれん

俺が言ってるのは事前織り込みの要件を超える仕様変更の場合だ
この場合最低限テーブルの見直し（とそれに伴う修正）は必要なんだが
最大の問題はここに工数がでないんだよ
それがためにガチガチの設計するやつは素人とかいう意見がでる
設計論としては間違ってるんだが、実際の商売としてはそうも言ってられん

ソーシャルゲームとかでアイテムボックスのようなものを作りたいのだけど、

・ユーザーID１つにつきアイテムボックスは１つまで(変更の可能性なし)
・アイテムボックスに収納できるアイテム数上限は決まっている(変更の可能性あり)

↑こんな条件の時にはやはり
アイテムボックステーブル　(ID、ユーザーID、アイテムID)　主：ID(一意性を保証するためだけのもの)

のようにして管理するのが普通なのかな？
アイテム上限数が固定で少数ならば
アイテムボックステーブル　(ユーザーID、アイテムID1、アイテムID2、・・アイテムID10)　主：ユーザーID

という構成も考えられるけど
前者はアイテム使用とかで常にレコード数変化するし最大所持数チェックとかINSERT、DELETE、SELECTの回数もバカにならないだろうから何か心配な節がある

好きにしろよ。正規化って意味では前者だけど、いろんな理由で後者が選ばれるケースもある。

>>313
たとえばアイテムボックスに、アイテムスロット１,アイテムスロット２．．．とある場合だと
アイテムの格納されてる位置も必要なわけで、その場合なら後者も無くはない

が、おれなら間違いなく前者でもうちょい項目つける。格納位置（並び順）とか、数量とかはいるんじゃね
アイテムボックステーブルにIDはいらんだろうけど（ユーザID,格納位置でユニーク）

レコード数を変化させる必要も特にない。レコードの中身を消せばいいだけ（レコード消してもいいけど）
INSERT（つかむしろUPDATE）の負荷で考えれば、前者であればアイテム一つ分のデータを挿入するのに対し、
後者であればアイテム１０個分のデータを挿入する。こっちのが負荷高い
selectの回数も同じだぞ。帰ってくる結果の行数は変わるかもしれんが
最大所持数チェックは前者だとcountなりsumなりで済むけど、
後者だとカラムごとに同じアイテムかチェックして足しこむ処理が必要だぞ
何を心配してるのかわからんな

ここは論理設計だけか？物理設計とかも語ってよいのね

twitterのつぶやき検索ってどーやってるんだろ
あれだけ大規模なツイートを検索とかFacebookよりすげぇ

>>317
selectだろ

まあちゃんもヒットしなくても誰にも怒られないシステムだからな。

DB経験3ヶ月の下っ端です。
正規化を勉強するにあたり、サーバ情報の管理を目的としたデータベースで以下の項目があった時、まずどうすれば良いでしょうか？
ぜひヒント貰えれば嬉しいです。

利用者500人/365day/24h
管理ホスト台数1500台

項目

ホスト名(not null)
IPアドレス1(not null)
IPアドレス2
IPアドレス3
OS(複数)
システム名(バラバラ)
アプリケーション名(バラバラ)
物理マシン設置国(4カ国)
データセンタ名(18DC)
サービス停止影響度(5段階)
物理/仮想(どちらか選択)
ハードウェア名(バラバラ)
利用ストレージ名(バラバラ)
アプリケーション責任者(バラバラ)
インフラ責任者(バラバラ)
可動開始日(date)
使用ステータス(二択)
ハードディスクc:(int)

まずは本の一冊でも買って読むのがいいと思うぞ。

>>320
>利用者500人/365day/24h
>管理ホスト台数1500台

なにを管理するのかよくわからんけど、Excel で十分じゃないかと思う。

>>320
まずどうすれば良い・・・？
まずは考えるときに「管理」を自分に対して禁句にすることだ．

「サーバの情報の管理」と言えなくなれば，「サーバの情報」とやらを
使って「何がどうなった」時に「誰が何をどうする」のか真剣に考えるようになる．
これが管理の内容そのものだ．単に管理と言ってると思考がとまってしまう．

次に
「何がどうなった」と「誰が何をどうする」を記述できるようなデータはどういう単位に
なっていなくてはならないか，またそれらの単位の情報はいつどこから入手できる
のか，すべきなのかを考えねばならないことに気づく．

考えてるとスグに，データの粒度精度にも疑問が沸くはずだ．
「アプリケーション」の「責任者」すら単純に定義できないぞ．
カネの出し元，パッケージ提供元，システムとしての開発者，いまの運用担当部門，
受益者部門・・・のうち，どこが責任を持つべきなんだ？そもそも責任者ってナニするの？

こういう事を，ゲッソリするまで考え倒すことだ．そのためにもまず必要なのが，
繰り返しになるが「管理」って極力言わないようにすること．

「管理」だけじゃない．すぐにキーとかインデックスとか言わないのもコツだ．
上に書いたようなことを考える苦労の１％にもならんよ．
でもキーとかインデックスとかが楽なわけじゃない．それだけ考えることが多いってこと．

健闘を祈る．

>>320
まずすべきことは現状分析
なにか改善したいのであれば要求分析
バラバラなものをどう管理すべきかということを考えざるを得なくなるはず。
とにかくヒアリングして分析しる

>>323
プロフェッショナルなアドバイスありがとうございました。
そんな風に考えたことなかったのでとても勉強になりました！

>>324ェ

>>323
管理、Managerここらを使わないようにするだけでだいぶ違うよな

ああ、正規化の勉強したいのか。
エンティティ／リレーションシップについてちゃんとしたメソドロジーの書いてある本を読むべき。まずは基礎理論知らないと話しにならん。
難しいけど頑張って読破しろ。

集合演算とかの概念も必要になってくるからそれもおさえとけ。
でないと正規化できない、というか方法論だけでもできるけど知っといたほうがいいだろう

>>328->>329
理論といっても当たり前のことを言ってるだけだね．
いや，当たり前と思えるようになることが修行なのか．

正規化の説明を最初に読んだとき，第一正規化，第二正規化のあたりは
フムフム学問だなやっぱり，でもめんどくせえな〜などと思ってたが・・・

第三正規化の説明で
「まあ普通にやってれば第一，第二など意識せずに第三くらいまで正規化できるものです」
などと書いてあって一気にスッキリしたよ．

>>328
ちゃんと基礎から勉強しろってのは賛成だが、正規化の前提はリレーショナル
モデルだからERはちょっと違うと思うぞ。

いまどきはk-vだよな

スレ違い

最先端はカラム指向らしい

>>334
kwsk

ttp://lmgtfy.com/?q=%E3%82%AB%E3%83%A9%E3%83%A0%E6%8C%87%E5%90%91

>>335
レコード（行）じゃなくてカラム（縦）ごとにデータをまとめておくこと．

ビッグデータとかmap & reduceとか最近目にするけど，これも流行なのかね．
CALSとかSOAとかWeb2.0とか，色々あったなあ．

スキーマ型DBの欠点を克服できてるけど
何も考えずRDBの代わりに使ったらどえりゃーことになるぞ
気を付けな

最先端って、どこがｗ
Sybase IQなんて相当古いじゃねーか。
特許が切れてオープンソース実装が出てきて流行ってるとか、そういうこと？

これからはNoSQLが来るな

>>340
用途による。課金システムがNoSQLだったらイヤだ。

これからは放射能汚染がくるな

とっくの昔にどっぷりヤラれてるような気がするんですけど

>>339
最新なのは市場のほう．ビッグデータ云々というキーワードだ．
Map & ReduceやるぞのOracle，HPは列指向DBで・・・

発明じゃなくてバトルのあるところが「最新」「最先端」と呼ばれるのよ．

欧州危機が最先端だな

60年前ならとっくに戦争始まってるレベル

皆さんに質問です。

今日会社でこんなことがありました。

私「テーブルの主キーに文字列は使わないほうがいいよ。そんなの見たことがないから」
後輩「どうしてダメなんですか？主キーが文字列のほうが見やすいじゃないですか。だめな理由をいってください！」
私「ぐぬぬ。。」

私はテーブルの主キーは絶対数値型だと思っていたのですが、文字列ではいけない理由をちゃんと説明できません。
実は私が勘違いしているだけで、テーブルの主キーを文字列にすることはよくあるんでしょうか？
文字列ではいけない場合、その理由を知っている方がいましたら、教えてください。

パフォーマンスを優先するか仕様変更可能性を優先するかの違い
PKは文字列より数値のが速い
PKが社員IDのようなもので数値→文字列に変更可能性が考えられるなら数値のみでも文字列使ったりする

商品コードとか普通に文字列使うが

ただ、その場合でも文字に意味をもたせないほうが無難だと思う
意味をもたせると将来桁数が足りなくなったりしやすい

じゃあ可変長にすればいいじゃない
というのは例えば帳票があると通用しない

てか、わかってないことをなんで強弁するのｗ
まぁ、キーはサイズが小さい方がいいから、一般的に文字列より
数値の方が小さいので好まれるとか、可変長のキーは物理
配置が乱れることから好まれないとかあるけど、わかってない人は
「キーは絶対に数値型！」とか言いながらOracleでNUMBERを
使ったりするｗ

オラクルは全てにおいてキャラが基本だよな？

>>347
数字にこだわる理由はない．どっちかというとやめた方がいい．
もしそのこだわりがISAM以来の伝統だったりオブジェクト指向原理主義だったり
するのならなおさらだ．

まず，主キーが番号だと，とくに大きめのプロジェクトが破綻しやすい．
DB設計にヘタクソが入り，そのエンティティを何で識別すべきか？の議論をすっ飛ばして
も設計に入ってしまって，正規化しなくても機能そのものには破綻が出ないもんだから
そのまんま実装に入ってしまｔって・・・

運用テストで「キーが違うけど他がまったく同一な２つのレコード，本当は同じモノだったよ」
みたいなクソ面倒くさい手直しが多発する・・・ような目にあいやすいよ．

それから主キーの数字にユーザーが意味づけしてしまう場合もあり，これまた面倒くさい．
3ケタ目4ケタ目が「20」から「46」までを抜き出してよ！とか言われるよ．
こういうのはプロジェクトもパフォーマンスも保守性も全部影響を受けるからね．
数値型での速度改善効果なんてすぐ吹っ飛ぶ．

あ〜イヤな事をいっぱい思い出した．

>>352
体験談としては聞けるが、理論的な根拠まったくなしだな
単にお前がバカの設計したプロジェクトに入っただけだ。ご愁傷様

その項目が、0-9だけで構成されてて桁数に意味がないなら、数字にする方がいい
文字列だと1と01と001は別物なんだが、そういう要件はあまりない

データ移行が多発するプロジェクトだと、意味のない数字キーだと、変換大変じゃない？

>>352
主キーをそのまま画面に出したのが運の尽きってとこだな。
別途、ユーザーから見える表示用のキーがあれば、小さな影響で改修とかできただろうにね。

>>353
一意になってればイイってだけなら数字でいいし若干数字のほうがいい（かも）程度

しかしプロジェクトは大きさに比例してバカ度も増えるんだよ
>>354のようなリスクをわざわざ積むこともあるまい

レコードの表す情報のをどう識別しどう管理するか？を裏でしっかり把握できてれば
キーとなる要素と属性だけで足りるようになるわけだが・・・

そこまでしっかりやってるならわざわざ裏でやって保守性拡張性を落とすこともない
表に出して(主)キーにしてやればいい

>>355
主キーをそのまま画面に・・・じゃなくてその逆だよ
デカい会社で，かつてメインフレーム使ってたところではよくある話
反対してもいいが人が会社がプロジェクトから切られるだけ

そういうところはユーザーがシステムの仕様に口を出すのもよくある話
その思考がCOBOLっぽいのもよくある話

主キーに自然キーを採用して良かった助かったという経験はないな…

>>352
> 3ケタ目4ケタ目が「20」から「46」までを抜き出してよ！とか言われるよ．
文字列を切り出して比較するのと、数値をモジュロと丸めしてから比較するのと何が違うのかしら

>>357
どっちにしろ、B-Treeのインデックスは効かなくなる。
ファンクションインデックスが使えれば、対処できるけど。

質問です。

よく聞く言葉で「帳票設計」がありますが、
これは「ＤＢ設計」と同じものと考えてよいですか？

駄目です。

俺の理解では、帳票＝出力だから、
ＤＢ設計とか画面設計のことをひっくるめて帳票設計と呼んでいるんだけど、違うのかな？
つまり、外部設計＝帳票設計だと俺は思う。

> ＤＢ設計とか画面設計のことをひっくるめて帳票設計と呼んでいるんだけど、違うのかな？

違います。

外部設計の定義を間違えている気がします

帳票＝紙のことだろ。
コンビニのシステムを例にすると、レシートのことだと思う。
つまり、帳票設計＝レシートの表示の設計じゃないだろうか。
レシートの設計を、画面設計と呼ぶとおかしいので、しょうがないので帳票設計ってよんでるのかなって思った。

>>364
ファイルに吐き出すCSVなりExcelなりのファイルを帳票って言うことがある．
いちばん広い意味だと書き込みのない参照画面をすべて帳票って言うこともある．

>>359
いずれもviewだからDB設計だろとコジツケることもできそうだけど，そうではない．
画面に出す場合は独特の機能を作らなきゃならないしね．

次ページ前ページのボタンをつけようかとか複数のソートキーを持たせようかとか
ある項目をクリックしたらサブ画面を開こうかとか，DB屋にやれと言ったら殺され
そうな機能が山ほど必要な場合もある．

また紙に出す場合もどこどこにどういう端末を置いてどういうプリンタをどこに置こうか
紙はどうしようか（シールなど特殊紙の場合もある）とか，そもそもプリンタは何台必要か
とか・・・こういうのもアプリ屋あるいはSEの仕事でDB屋にはさせられない．

>>356
主キーの話って黙って適当な連番とかでサロゲートキー作ってしまうのが無難な気がするけどねえ。
客見せようのユニークなキーは別途作るような感じで。
そのほうが上に乗っかるアプリケーションも影響受けにくいだろうし。

主キーが数値にしろ文字にしろ
レコードの追加時に組み合わせの最大数を超えたときの処理はどうしてますか？
たとえば32bit数値なら32bitの最大値とか
n文字なら利用可能文字のn乗とかを超えたときの話です

>>367
事前にそこまでのデータ量を扱えることを要求するシステムってそうないような気がするけど
どうなんでしょう
データ量の見積もりをあきらかにミスったとかとなれば別ですが

仮にoracleのシーケンスで採番して上限まで使うとしても
毎秒1000万回採番しても約3兆年かかるらしいとかですよ

それ以前にデータ量多すぎて他の見直しが多そ

Key Value Storeを使い倒してるやついるか？

いつもgoogleにはお世話になっている．

memcachedとcassandraにはお世話になっている

DeNAの球団略称がDBになるそうだ．
ますます住みにくい世の中になるな．

mjd?

>>372
そもそもそんな略称めったに目にしないから、関係ないよ。

DB設計の手順教えて下さい

とりあえず必要なデータを紙に書く
関連のあるデータをくっつけていく
おや？勝手に正規化になってるぞ
完成

>>376
参考になります

>>375
　ビジネス要求をまずはハッキリさせる.
　システム全体のスコープを決める.
　ハードウェアミドルウェア等の既存制約,予算制約を確認する.

　アプリとの棲み分けをきめる.
　3層だか4層だかSOAだかアーキテクチャを決める.
　DBのサポート範囲をきめる.
　運用ルール共通規約など決める.バックアップなんかもここで考える.

　DBの対象とすべきデータの構造を調べる.
　相互の関連性,依存性,寿命(変更・拡張の可能性と頻度)を調べる.

☆データをたばねたりバラしたり,最適配置を考える.
　移行手順はその思考過程からひっぱりだしておく.

☆設計書を書いてDDlをかく (自動化してればDDLを吐かせる).

DB設計というと☆のついてるところだけを考えがちだが,そこだけ
いくら考えても元ネタがなければ動けないよ.
ぜんぶやるつもりで入って,たまたま他人がやってくれてる部分があれば
ラッキー位に思っておいたほうがいい.

>>378
具体的な指摘ありがとうございます。
とてもわかりやすかったです。

販売管理で消費税を商品の1つとするパターンと
スキーマに含めるパターンとどっちが流行り？

消費税をどの単位で計算して丸めるかによってかわるんじゃね

消費税は比率なんだから、商品の一つとみなすのは明らかにおかしいだろ

>>382
商品というよりは、計上科目として分けて保持するか、商品に従属する項目として保持するか、どっちがメジャー聞きたいんじゃないのかな？

経理的なところまで面倒見るなら、わけた方が扱いやすいだろうし、そうでなければ従属させた方がいいんじゃないかな？

消費税率が変わったときにラクなのはどっちだ？
追加でカネをとる口実を作りやすいのはどっちだ？

家電や外食じゃないんだから「いま売れてます」に飛びつくのはやめようよ．

つまり、どうするのがいいんだ？

今後の消費税法しだい

変動要素は税率変更くらいだろう
あと税率の段階，外税化が可能性としてある

いちおう全部を挙げておいて「考えられるのはコレくらいですよね」
⇒設計に生かす

その上で「税率以外は次ステップということにしましょうかXX円かかりますし」
⇒今後の飯の種をのこす

わざわざ内税にさせたぐらいだからいまさら外税化はないだろう。
食品の税率据え置きとかありそうだ。
引き下げならサプライズだが。

>>388
いやいやそういうツッコミを入れてもらうための撒き餌だから．
そういう撒き餌で「そんなのいらないよ」に口を慣らす．

「それいらない」「そっちは今度でもいいか」「これだけは・・・必要・・・かな？」

あとでもめないコツは後から作りこむといくらになるか言っておくこと．
むろんいま追加するといくらかも言っておくこと．

なお避けるべきは「やりすぎ」コレ重要．
要件の見極めができないコイツ業務分かってんのかと思われたらアウトね．

今度うちにいれるシステムは、
3つのパッケージの組み合わせらしいが、
DBがポスグレ、オラクル、SQLサーバとバラバラらしい。
パッケージ間の連携がキーになるシステムなのに、
正気とは思えん…

メンテナンス担当になりませんように！

>>390
共通プラットフォームと称してまたDBを追加だ！
ここまで来たら今度はDB2かSymphowareか・・・

しかしメインフレームが残ってなくてよかったな。

>>390
そんな案件いくらでもある
いちいち気にすんな

KVSでの設計でよく「非正規化」という話を聞くのですが、
例えば、RDB的な「受注（仮に1受注=1商品とすると」テーブルなら受注レコード1件に
「商品ID」、「購入者ID」などの外部キーで持つと思うんですが、
これを
「商品名」、「購入者名」のような形で持ったとして、
商品名がかわったり、購入者名が変わった場合に該当する全ての
受注データを更新することになるとおもうんですが、
そこはKVSなら処理的に問題にならないほど速いということなんでしょうか？

RDBでいう非正規化しないデメリットの部分が、KVSで非正規化した際に
どう解消（または緩和？）されるのかという具体例をあまり見つけられなかったので質問してみました。

考え方が逆。
そういうデメリットのない用途にKVSを使う。

>>393
RDBであえて非正規化するメリットと同じじゃないかな…

じぶんなりの考えだけど
現実のビジネスだと購入者や単価が変わったとき過去のデータまで更新する必要ってあまりなくて、むしろ変えてはいけないケースの方が多い気がする
総売上が変わったり不都合
前に出た消費税でも今年は5%で計算して、8%になったらそれ以降8%にしないと困る
RDBでも消費税変更を見越して設計してれば大丈夫だけど、そうじゃないと大変なことになる
KVSは勉強中だけどKVSのほうがその辺がまだ柔軟に対応できるイメージ

>>394
ではこういうケースは「そういう用途」にはならないということになるんですかね。
普段業務アプリケーションを作っていると、
じゃ、具体的にどういう用途に向くんだろう？と。

>>395
RDBでの非正規化のメリットとして自分が思っているのは、
正規化の基本を第3正規形とすると、それで得られる一番のメリットは
「１事実１箇所」のメリットと思うんですが、そのメリットを超える
データ取得時のパフォーマンス向上を得られる、というメリットなのですが、
そういうことですか？

>>396
受注した瞬間に消費税が確定するのであれば、そうかも知れませんが、
おそらく通常はそうではないですよね？（出荷時になるんじゃないかな？）

「受注」を例にしたのがまずかったのかもしれませんが、
まぁ、そこは大きな問題じゃなくて、
疑問に思ったのは正規化しない場合に後から変更された場合を
・考えないような用途に向いているからそういう場合に使うんだ。
なのか
・考えるが、RDBでの「普通」とは違うなにかKVSならではの対応方法があるのか？
というのを知りたかったんです。

>>396
>>むしろ変えてはいけないケースの方が多い気がする
すいません。
ということは、
>考えないような用途に向いているからそういう場合に使うんだ。
のケースが実は多いんじゃないか、というお考えなわけですね。

>>397
KVSって、第一非正規形を扱えることを除いたらデータモデル的には
キーが1つだけのテーブルと変わりがないでしょ。KVSに何を期待してるのか
いまいちわからんけど、さまざまな用途にオールマイティに対応できるのは
やっぱりRDBだと思うよ。

で、>>393をKVS的に解決するとしたら、商品IDをキーとする商品テーブルに
複数の受注データを持たせるというやり方が考えられるけど。
商品( _商品ID_, 商品名, 受注[] ) こんな感じ。

>>399
>KVSに何を期待してるのか
何かすごいことを期待してるかというより、何に向いていて何に向いていないのかを
自分が普段している業務で具体的にどんなものがあるんだろう？という感じです。

結果、自分の周りにそのような対象は無いとわかればそれでいいですし、
こういう使い方が出来るというのがわかればそれはそれでためになるな、というのを
自分の具体的な仕事を書くわけにも行かないので、例を上げて聞いて見ました。

>商品( _商品ID_, 商品名, 受注[] ) こんな感じ。
KVSはあるkeyから特定のHashへのポインタを持っているイメージなんですが、
商品IDというkeyに対して、受注1、受注2、受注3・・・受注Nというように
属性が増えていく感じになるんですか？

Hashへのポインタ？特定の実装の話か？にしてもいまいち意味不明だが。
いちどちゃんとKVSについて調べてみた方がいいと思う。

>>400
KVSが向いてるのは，ひたすら大量データがたまっていくが更新はそんなにないもの．
正確じゃないが「テーブルじゃなくてインデックスにこそ用がある」時につかうもの．

商品の例だとコンビニやら量販店やらのPOS情報を分析して需要予測たてるような用途．
気温が何度でどの地方（駅前，郊外，住宅街，学生街 etc)でどんなものが売れるか．
コンビニなんかだと日単位時間帯単位でモノを店から店に動かしたりする．

⇒大量データでスピード処理，単一または最小限の応用（この場合は分析）
　全国のPOSの取り方をいっせいに変えるんじゃなければ過去のデータなど付け替えない

会社の業務全体を回すような用途はRDBになるよ．
ちなみに非正規化ってのは，レスポンスとデータ永続性のバランスのための方便．

選択肢はたとえば・・・
実際に使う重複ありデータをメモリ上データをオブジェクトで持つか，それともDB側で持つか．
DB側で持つのもキャッシュで持つかテーブルそのものに持たせたいか．

これはマシンにもよるしDBの選択や設定にもよるしプログラマの質にもよる．
まあ選択肢がある程度ハッキリするだけでも役に立つんじゃないかな．

それだけ読むとDWHの話みたい。

で、いいとおもう

ですな。

付け加えると、KVSの使いどころ。

・分析用としていろいろなデータを突っ込んどきたい。設計段階で確定？無理です。その度にAlterTable?サービス止められません。
・とにかくオンメモリDBとして更新の速さが要求される。（揮発性のデータを永続化DBにストアとかアホのすることだと思っている）
・DWHアプライアンス高くて買えないのでコモディティサーバーでクラスタリングしたい。

といったところじゃね。

結局のとこ、機能をしぼって、大量データをあるていど高速にさばけるようにしただけのものなんじゃないのか

業務アプリ屋からしたらその通りなんだけど．
機能を絞っても，そうそうスケーラビリティもレスポンスも出せるもんじゃないよ．

MapReduceも「別に新しい発想じゃない」って最初から断ってるくらいで，これは
原理が偉いんじゃなくて実装よくやったなあという所が感心するポイントだと思う．

あとGoogleなんかでは一部がコケても処理がコケないことを重視してる．
絶えず更新されてる世界中のサイトの表示順位がおかしいという文句は出ないけど
検索が遅いと不満が出るから．

中身はデタラメでもレスポンスだけはするってタイプか
最悪だな

母数が巨大で計算（点数付け）は統計処理だからデタラメではない。

カッチリやろうとすると東証くらいのデータでもそれはそれは大変なことになる。

>>408
目的に合った設計もできないタイプか
使えないな

すいません、ちょっと質問です。
異なるDB間（例えばオラクルとSQLサーバ）で
データの一貫性を保つにはどうするのが
一般的でしょうか？

ひとつのトランザクションで処理できないですよね？
すると、片方のDBでコミットしてる間に、
もう一方のDBで予期せぬエラーが発生して
ロールバックがかかると整合性が取れなく
なっちゃいませんか？

>>411
SQL Server→Oracleならリンクサーバ
Oracle→SQL ServerならDBリンク
で一本で処理できる

ミドルウェアで２本コネクション持ってるなら
片方こけたらリカバリーできるようにするか
リトライで問題なく処理できるように設計するしかないかな

DBのチンポコは小さい!

さむいな

MySQLが混じった場合も、同じやり方でいいのでしょうか？

>>415
ちょっとは自分で調べたのか？

>>412
レスありがとう。
ヒントはもらったので調べてみます。

ちなみに415は私じゃありません。

MySQLで以下のことで検討してます
データベースを1つ
テーブルを1つ
カラムに次の3つ(id,name,flag)
idは連番
nameはvarchar(100)
flagはintで0か1の値

一日に20万件のflagの書き換えを行うのですが
この場合ってテーブルを分けたほうがよいでしょうか？

>>418
分けたほうが吉

>>418
分けないほうが大吉

なぜ分けた方がいいと思ったのかと、どう分けようとしているのかが
書いていないが、もしパフォーマンスを心配してのことであれば、
実際にそれが無視できないくらい悪いことを確認してから考えろ。

>>420
VIPに帰れ

八つ当たりかこわる

20万件もあるなら分けるだろ普通
書き込むたびに20万件のデータ開くの頭おかしいだろ

テーブルを分けるのは最後の手段だな
たかが20万程度で本当に問題がでるのかやら
パーティショニングやら他に検討すべき事があるんじゃないかな

>>424
>書き込むたびに20万件のデータ開く

正直、なに言ってるのかさっぱりわからん。

いったん結果セットを取ってこないと更新できない、とでも思ってるんじゃない？

俺も1日で20万件程度なら、わざわざテーブル分けなくてもと思うけど。
なぜ分けようと思ったのか？

固定長になるから

バカすぎて何イッてるかさっぱり。
放置でいいよ

>>418
全部で何件中の20万件なのか？20万件中の20万件なのか
１億以上あるデータのうち500分の1程度の書き換えがあるのか。

随時トランザクションが一件ずつ飛び込んでくる合計が一日20万件なのか
数千件ずつなのかそれともバッチ的に全件ガツンと書き換えるのか。

分けたいってのはレコードを分散したいのかIDとフラグだけのテーブルを
設けたいということなのか。

レスポンスの要件、それから整合性の要件は何か。
フラグが書き換えられたレコードは次の瞬間からフラグが書き換わった状態
としてふるまう必要が本当にあるのか、２４時間いつでもそうなっていないと
いけないのか。

・・・と書いてはみたが、言いたいことが伝わったか不安。

>>431
20万件じゃよほどじゃねーと要らねーよ
まで読んだ

煽るような薄いレスじゃないだろｗ

注文明細で、総額＝商品金額＋消費税−使用ポイント−値引き
みたいな場合、使用ポイントと値引きのカラムにはマイナスの値を
入れるようにしたほうがいいものかな？

>>434
って、縦持ちにするんだよね？
注文番号,明細番号,項目名,金額
みたいな構造にするならそれぞれ正負の値を入れておくべきだね。

販売管理だから縦にする必要がないんでしょ。

でも、縦にしてた方が拡張性ありそうだけど。

％引きのポイントがあってだな

割引が複数合ったときの取り扱いとかもあってだな

後出し大杉。でも縦持ち推奨だわ

ただのネットショップのシンプルなシステムだし、
1レコード＝1明細でいいと思ってた（横持ちってこと？）。

値引きはマイナスで格納に一票。

横持ちの方が実装が楽よ
あるかも分からない拡張のために実装してはないと偉い人も言ってた気がする

データモデルはおいそれと変えられないから
データこそが偉い！ってのが
このスレに集うような人たちの主張じゃなかったん？
とりあえず思考でデータモデル作ることの擁護を
プログラム作る時のパラダイムで語られてもなあ

>>441
こんなところで聞かなければ解決できないなら1レコードにすべて格納した方が良い。

直接関係ないが、とあるシステムで端数処理をする関数部分で
絶対値をとるようにしてなかったせいで、マイナスの端数が合わなかったことがあった。
それ以来、数値はマイナスを入れないようにしてる。

>446
床関数と天井関数を、単純に切り捨て切り上げ関数と勘違いしたアホ発見。

>>447
なんでその二つに限定できたの

それしか知らないアホだからでしょう

アホの定義が分からないから議論に参加出来ません

いや俺じゃなくて、分かってないやつが
端数処理の関数を書いたってこと。

そういうやつも要るから、データ側では
なるべくマイナスの値を持たないようにしてる。

そういう現象が発生するのは、集計の前に丸めが行われる勘定とかか？
どちらにしてもそれは単に仕様通りに作っていないだけのように思うが。
マイナスの値を使わないようにしたというのが対策だというなら、もしかすると
仕様自体明確に指示していなかったんじゃないだろうか。

>>452
>仕様自体明確に指示していなかったんじゃないだろうか。

俺もそう思う。

根拠は、

>それ以来、数値はマイナスを入れないようにしてる。

って言うアホな対策しかできないような組織だから。

数値はマイナスを入れないとかいう対策を見ると0のときが心配になるな。
0 Divideを避けるために0は使用しないとかｗ

仕様書に小数点以下は切り上げるとだけ書いてあったら、マイナスの時どうする？

仕様書書いた奴に、「マイナスのケースも明記してね。」と言う。

プログラマ依存ｗ

>>455
丸め方法は明記してくれないと。

もしかして、アカウントを作成するときの
"Sign up for a free 5 user account(五人までの面子で使える無料1アカウント)"
を読んで勘違いしたのだろうか。

果てしなく誤爆した。ごめんなさい。

SNSでユーザがグループAとグループBにわけられていて、
「管理者側からグループAに属するユーザ全員にメッセージを送る」
という機能があるとします。
この前提で、ユーザ一人一人にメッセージへの既読チェック機能を持たせるとしたら
メッセージのテーブルはどうしたらいいでしょうか

id／to_userGroup／to_userId／message／is_read
個別のユーザへのメッセージなら、以上の構成で良いと思うんですが
全員相手のメッセージだと、既読フラグ（is_read）をどう持たせたらいいのかわかりません
どのように作るのが一般的＆効率的ですか？

メッセージと既読フラグを別に持てばいいだけじゃね？

Table: messageTable
　id
　to_userGroup
　message

Table: readStatus
　messageId -- reference to messageTable.id
　to_userId
　is_read

送信する時に、message を messageTable に挿入して、
ユーザーに送信する (もしくは送信先を設定する) 度に
readStatus に messageId と to_userId のセットを挿入
すればいいと思う。

もちろん挿入時は is_read は false にして、読んだよ〜イベントで
true にすればいいだけかと。

個人ごとに読んだかどうかなんだから
グループに送ろうが個人におくろうが、個人に送られてきたメッセージの既読処理をするだけだと思うが

>>462,463
どうもありがとうございます
既読チェック専用のテーブルを別に用意するべきなんですね〜
参考にして作ってみようと思います
ありがとうございました

IDを文字列にするとか数値にするとか議論があったけど、
文字列にする場合もシーケンスでやるのが定石？
それとも別の方法が何かあるのかな？

>>465
お作法の話の元は
「IDに業務の都合を入れるな、話がややこしくなるから」
「どうせならIDはシステムに都合のいい数字がよい」
だよ。

システムにもいくつか都合がある。
ソートしやすいとか容量くわないとかいうキカイの都合
発行順序が分かりやすいというようなシステム屋の都合

これからつくるシステムの固有要件に対して何か思いつけば
キカイに都合のよい「そういう文字列」にしてもいいんじゃない？
思いつかないけど。

いっぽうシステム屋の都合を拡大して文字列にルールを持たせると
「IDに業務の都合を入れるな、話がややこしくなるから」
をシステム屋が自分で踏みにじることになる。

そうなる位なら、数字にすると始めから決めてかかるほうが無難。

文字列派の意見ってどんなだ？

限りなく実装に近いレベルの話でスマソ。でもSQLの話じゃないし。。。

N88からAccess　MDBに移植されたものを、PostgreSQLへ移植中なんだが、

仕入ID　I[年][月][番号] 出荷ID　E[年][月][番号]　みたいになってる。
たとえば、I2012010001 で、2012年1月の仕入1回目。

移植案件でデータ引継ぎもあるから、そのまま移植しようと思うのだが、
元のシステムはナンバリングデータテーブル（プレフィックス　現在値）を持ってて
VBAで作った共通関数でカウントアップしてる。

ナンバリングデータのテーブルなんて他で見た覚えがないので、
シーケンスで作り直そうかと思うんだが、定石なのかどうか知りたい。

他の人が引き継いだ時できるだけ戸惑わないようにしたいんだ。

>>467
オラクルならcharだろ？

>>469
それが理由？速度がどうとか利便性がどうとかじゃなく、オラクルだからchar？

>>468
採番テーブルともいうが、割とよく見る。
シーケンスで作り直せるのならそれでもいいんじゃない

たとえば都道府県名だったらidいらないんじゃないとか

>>472
>>465の
> 文字列にする場合もシーケンスでやるのが定石？
これって、数値文字列にするって話じゃないのね。

>>472
何も考えずに市町村コード使ってるが・・・。

>>474
全然Naturalな設計でしょ

>>470
オラクルは金額や数量以外の項目にCHAR以外を使うとくなことにならん。

全部Varchar2が多数派のような気がするが。

charを使わないって意味ね

日本語に難のあるレスが多いな

>>476
まじで？めんどくさいね

http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917
オラクルだからcharっていうのは、ここに書いてあるようなことが理由なのかな

>>481
？がいっぱい浮かんだけど、Oracleには固定サイズの数値型というものが存在しないことを知って理解した。
普通に32bit整数型とかあるんもんだと思ってた。

PostgreSQLでいう、ストレージがPLAIN以外に設定されたカラムを使うときのペナルティみたいなもんなのね。
勉強になった。

JOIN禁止はすんなり理解した。

アホらしい。Oracleを使う意味が無い。
MySQLで十分だね。

それで要件を満たせるなら俺も十分だと思うよ

んだね。要件次第
まあ一度くらいはこういう案件やっておくといいと思う。エンジニアとして
二度は、オレは御免こうむるがｗ

可変長だと、行移行とそれに伴うデータ領域の断片化を気にしないといけない。
データが大規模で、定期的な保守停止ができない場合致命的。
あと規模に関係なく、半角スペースとnullの扱いに癖があるからね。

>>486
上2行は>>481を薄めたものなのはわかる。
最後の行くわしく

可変長文カラムだと、末尾に空白の有無により、パディングしてやらないと抽出条件としてマッチしないこと。
だからといって半角スペースだけの値をtrimするとnullとしてあつかわれてしまうこと。
この辺りをわざわざ毎回考慮しないといけない。
charでnull禁止にしておけば、この辺り気にする必要がなくなる。

え？

>>488
つまりORACLEは空文字列とNULLの区別がつかないということか

長さゼロの文字列とNULLが同じってのがOracle最大の汚点だよなあ
後方互換のためにもうずっと変えられない仕様なんだろうけど

そしてnullは主キー項目になれないという制約があるから、複合キーの項目なんかに必ずしも埋まらなくても良い可変長文字列なんかがあると非常に扱いに困る。
それなら最初から固定長にしてダミー値をセットするか空白が埋まっている方がマシ。

もっと低レベルの話もある。
ある会社だが取引先コードは数字で１０ケタ固定にしている。
DBMSは標準でOracleを使ってる。
その会社の、とあるシステムでは取引先が8ケタだったり７ケタだったり
なぜか一定ではない。

「何スかコレ？」
「いやあ移行のときにエクセルで設定したら頭のゼロが無くなっちゃってね」

そこを直すと、次の移行でデータの整合性が云々という話になって結局
全社ルールにもキチンとしたDB設計にもあわないマスターになった。

悪いのはビルゲイツかラリーエリソンか情報システム部か？

いやエクセル悪くないだろ
猫に小判、ブタに真珠ってことだろ

情報システム部 に1票

>>490
そうだよ。

というか、char型なら普通スペースが埋められるだろ。
null文字列じゃないだろ。

だから検索条件にtrim()を使うから
Hashインデックスは効かないんじゃねーの？
Btreeだったら効くけど非効率だよね。

変な日本語になっちゃった。

検索条件でいちいちRPAD（だったか忘れたが）する必要がある。
もしくは毎度trimを書く必要がある。
この場合ファンクション索引を使わない限りインデックスは効かない。

よね？

>>496
trim(col)でインデックスはればいいんじゃね？とおもったけど、結局 trim(col) == '' みたいなことができない以上どうにもならんのか。
なんというか、やりにくいねｗ

将来変更されるかもしれないから、 '' がNULLであることを期待したSQLを書くなとマニュアルにはあるけれど
変わらないままずーっときてるのね

そこ変えたらIT業界に好景気がくるぞ

>>492
>そしてnullは主キー項目になれないという制約があるから、複合キーの項目なんかに必ずしも埋まらなくても良い可変長文字列なんかがあると非常に扱いに困る。

それで困るケースが想像つかないわ。
あったとしても
'(NULL)'なり'-'なり適当に入れてやればよいわけで。
どっちみちNull文字列を入れられるDBでも重複はできないわけで。

やはり主キーにヌル文字列が入るケースは想像しにくい。
カバリングインデックスにして性能アップしようとか考えないほうがいいで。

>>500
NULLは複数入れられるよ。

ああ、複合主キーだったら複数入るか。

>>502
単一カラムのUNIQUE制約でさえもNULLを複数入れられるDBMSと
入れられないDBMSがあるよ

可変長の属性でもchar型にしてるとかって、本気でそんなこと言ってるの？

可変長の属性でもなんでもchar型にしちまったら、データ量が増大するじゃねぇか。
バックアップの時間が伸びるとか、
char型のカラムにインデックスを貼ったらインデックスサイズが大きすぎて非効率になるとかいう
考えはなかったの？？

行移行させてしまうようなテーブル設計・DB設計にも問題あるし、
データが大規模であれば当然パーティション設計してるだろ。
断片化解消したいんならパーティション単位に shrink space とか打てば業務中でも可能だろ。
まぁテーブル単位でも大丈夫だろ。
業務アプリがレコードをロックしっぱなしって事が無ければな。

半角スペースとnullの扱いは、困ったもんだねぇ・・・
Oracleがvarchar3とかいうような奴を新規にリリースしたら良いと思うが困難なのかね。

MySQLみたく、エンジンを切り替える方法とか？
でも、格納方法に起因するものだとすると、これだけではダメか。

RTRIM(列) IS NULL
で空白がいくつだろうがNULLだろうが一括で引っ掛けられるのは
便利だったけどな。パフォーマンスもそんなに悪くなかった。
SQL Serverにいったとき面倒だった。GUIの見た目でわからんし。

>>507
char型って、ユーザが意図していれた空白かどうかがわからないところが問題だと思うの。

>>508
そんなものまで区別したいならbinaryにしておけよ

そんなもの、といわれてもなぁ。
可変長ならそれがわかるじゃん。

なんかOracle質問総合スレに神が現れたぞ。

144 名前：NAME IS NULL[] 投稿日：2012/01/20(金) 22:52:50.75 ID:96O4svvI
こんなことありえるか？

朝出社したらインスタンスが落ちててコールの嵐。
なぜ・・・？と思ったらオペレーターがディスク閾値を超えたから以下を実行したらしい。

sudo cp -p /opt/app/oracle/11.2.0.2/product/db1/admin/bdump/* /tmp/log/
sudo rm -Rf /opt

/opt配下のディレクトリ構成

/opt/data
/opt/redo1
/opt/redo2
/opt/arc
/opt/conf
/opt/tmp
/opt/rman

おれはそれを聞いた瞬間、職場を出て未だにファミレスにいる
イロイロ



クソワロタｗｗ
おまえらアドバイスしてやれ

ワロス
逃げちゃダメだ逃げちゃダメだ逃げちゃダメだ？

そういうオペレーターにルート権限を渡してはいけない

ありえねえ・・・
オペレーターも大概だが、こんなのにやらせてる組織の方が
まあネタであることを祈る

・タイトル
・ユーザー名
・パスワード
・メッセージ
上記のような項目をもった投稿テーブルがあって、
そこにログインしているログインユーザーと、
ログインしていない非ログインユーザーどちらからも書き込めるようにしたい
ユーザーテーブルは
・ユーザー名
・パスワード
といった投稿テーブルがもっている項目と同じ項目を保持している
非ログインユーザーからの書き込みはそのまま
投稿テーブルの項目を全て保存すればいいんだけれど、
ログインユーザーからの書き込みは同じ項目があるので、
その扱いをどうするか悩んでます。

今考えている案は、
投稿テーブルに
・ユーザーID
を外部IDとしてもって、そこに値が入っていれば
ユーザー名やパスワードなどはユーザーテーブルを参照する
という方法です。

これ以外に思いつかないんですが、
何かもっとスマートな方法はありますでしょうか

>>515
項が曖昧だ。
まずパスワードという言葉を「ログインパスワード」と「（メッセージごとに異なる）メッセージ削除専用パスワード」の二つの意味で使っている。
他にも全体的にぐだぐだだ。
何をしたい？

>>515
> 今考えている案は、
> 投稿テーブルに
> ・ユーザーID
> を外部IDとしてもって、そこに値が入っていれば
> ユーザー名やパスワードなどはユーザーテーブルを参照する
> という方法です。

奇妙だな。
まず投稿テーブルを見て、複数行の取得さもなくば単数行の取得にて、なにかしらの行を取得する。
その行に含まれるユーザーIDを知る。
そのユーザーIDを使ってユーザーテーブルを参照してパスワードを得る。
こんな手順の処理が有り得るのか？
なんのためにそんな処理が必要？

>>516,517
すいません、確かにパスワードは２つ必要ですね。
まだそこまで考えていなくて曖昧になった部分がありました。

とりあえずとても簡潔に最低限の項目で
▼投稿テーブル
・ID（PK）
・ユーザーID（外部ID）
・ユーザー名
・メッセージ
▼ユーザーテーブル
・ID
・ユーザー名

としておきます。

書き込みは
(1) ユーザーがログインしている状態で投稿される場合
(2) ユーザーがログインしていないときに投稿される場合
の2パターンがあります。
(1)の場合のみ受け付けるならば、投稿テーブルにユーザー名は必要なく、
ユーザーIDだけ保持していれば、ユーザー名などの情報は
ユーザーテーブルから参照すればいいので簡単なのですが、
(2)の場合にも対応したい場合、ユーザーテーブルに情報が無い（非ログイン）ので
投稿テーブル自体にユーザー名を保持しなければいけません。

上記の実装だと、
・ログインしているかどうかによって、フィールドの必須かどうかが変わってくる
　→アプリケーション側の問題がDBの設計に影響してしまっている
のがスマートじゃないなと感じる点です。

(1), (2)の両パターンに対応した投稿テーブルの設計をアドバイスいただきたいです

>>518
匿名投稿の場合、投稿者名の格納は投稿テーブルしかないのかを考える。

匿名投稿をメインにして基本的な構造を設計して、そこにログイン投稿能力を後付けするか、それとも逆か。それぞれの場合での設計をしてみる。

匿名投稿とログイン投稿のどちらが多くなるのか。

たとえ匿名でも、同一人物が何度も無駄な連投をする荒らしになったら、当該人物による投稿をまとめて削除したりフラグ立てたりしなきゃならない。
だから、裏ではこっそり何らかの隠しアカウント処理を入れなきゃならない。

削除専用パスワードは表面的に個々のメッセージが個別に保有していることになるのだから、それはメッセージテーブル。

ログイン者投稿もしくは削除専用パスワードを未入力なら削除専用パスワードのフィールドはnull。

メッセージテーブルのユーザーIDには必ずIDが入る。正確には抽象ユーザーID。
抽象ユーザーIDをpkとする抽象ユーザーテーブルを見れば、それが実アカウントなのか仮アカウントなのかが分かり、実アカウントIDもしくは仮アカウントIDが分かる。
実アカウントテーブルはログインユーザー用。
仮アカウントテーブルは匿名ユーザー用。
匿名といえどもIP-addressやsession-idなどでできるだけ同一人物の集約をしておく。

>>520
> たとえ匿名でも、同一人物が何度も無駄な連投をする荒らしになったら、当該人物による投稿をまとめて削除したりフラグ立てたりしなきゃならない。
> だから、裏ではこっそり何らかの隠しアカウント処理を入れなきゃならない。
確かにそうですね

> メッセージテーブルのユーザーIDには必ずIDが入る。正確には抽象ユーザーID。
> 抽象ユーザーIDをpkとする抽象ユーザーテーブルを見れば、それが実アカウントなのか仮アカウントなのかが分かり、実アカウントIDもしくは仮アカウントIDが分かる。
> 実アカウントテーブルはログインユーザー用。
> 仮アカウントテーブルは匿名ユーザー用。
> 匿名といえどもIP-addressやsession-idなどでできるだけ同一人物の集約をしておく。
おおおおおおお！なるほど！！これはすごい！！
やべえ、これはいい。
抽象ユーザーIDをどう実装するかとかはまだつかめないけど、
かなりもやもやが解消されました。

>>519の指摘も含めまだ詳細が不明なので設計も悩んでしまうのかなぁと思いました
みなさんありがとうございます！

ちょっと似た質問ですけど、
ユーザーに「プロフィール」という情報があった場合、
プロフィールテーブルを作るべきですかね？
それとも、ユーザーテーブルにフィールドを追加する方が良いですかね？

仕様は1ユーザー1プロフィールです。必要フィールドは20ぐらいあります。

どっちでもいい。

特定多数からINSERTがあるテーブルに
IPアドレスとリモートホストどっちを保存したらいいですか？
どっちも？合理的なのはどの方法だろう

>>524
保存して、何に使うの？

>>524
余裕があるなら両方保存しとけば？

>>525
荒らしなどのために保存しておく必要があります
それで抽出して全削除したりします

>>526
そうしようと思ったんですが、
なにかなるほど、といった理由がほしくて質問してみました

>>527
DB設計の話じゃなくなってきてるが・・・。

IP保存→文字数少ない。普通はこれだけで桶。

ホスト名保存→プロバイダなどでIPが変わる時にある程度範囲を絞るのに使いやすい。
　プロバイダ毎に割り当てIPのマップとかを調べてマッチング取ってもいいが、
　規模が大きくなると飛び飛びに拡張されてたりするからﾏﾝﾄﾞｸｻｲ。

漏れがやるとしたら・・・
IPにインデックス張って保存して、自動化部分ではそっちで処理
ホスト名は手動でやる時に like で抽出して使う方向

ってか、荒らしのIPわかってんならINSERT前に拒否すりゃｲﾝｼﾞｬﾈ？

>>528
>IPにインデックス張って保存して、自動化部分ではそっちで処理
>ホスト名は手動でやる時に like で抽出して使う方向
なるほど、こういう考えで行こうと思います
ありがとうございました

あらし対策なら俺なら両方保存しとくが
アドレスだけ保存してても、アドレス変えて接続してきたとき対応できないからな

DBにipv4アドレス保存するときは整数でな。
CIDRマスクも範囲も整数なら簡単。
10進数化文字列で保存したら死蔵だぞ。

そうなん？１６進のほうがわかりやすくね？

>>532
何が分かりやすいんだよ

整数のほうが判りやすいと思うほうがどうかしてる

16進数を文字列として格納すると言っているのか
数値で格納して表示だけ16進数にすることを言っているのか

>>534
整数型と文字列型を比べて、文字列型の方が分かりやすいといっている？

内部表現が整数型をであれ文字配列型であれ、
16進数表記法が分かりやすいというのであれば
IN/OUTを16進数表記にしてしまえばいいんでないの？
そんなことは内部表現を整数にするかそれ以外にするかの判断材料にならないような。

格納する時の構造と表示する時の書式を分けて考えられないだけでしょ

>>532
ごめん。何を言いたいのかマジわかんねえ

カラムの型宣言で16進数の指定できたっけ？

remote_addr INT(8) HEX NOT NULL,

>>534
16進数は整数の表記法の一部だから、整数の方が分かりにくいというなら、必然的に16進数も分かりにくいよな？ww

>>542
整数ってのはINTとかLONGのことな

表記法の問題だけ

>>541
なにがいいたい？

俺もip v4なら、intの値で保持して、必要なら表示用にストアドファンクション用意するかな

>>546
それなら１６進文字列で格納しても変わらなくね？

>>532
16進数で保持するというのが全然分からないので、もう少し詳しく

>>547
unsigned32bit整数値をわざわざhex文字列で格納するって最悪だろ

>>547
16進数文字列だとCIDRマッチがややこしそう

固定長整数値を入れるフィールドを文字列型にする変態はたまにいるね。
perlやphpでしか使わないから全然問題ないと言い張るの。
他の部署、他の会社でやってくれるならご自由に。

>>550
まぁたしかにそれはあるかな

>>551
勉強中の者として初歩的かもしれませんが、教えてください。
その固定長整数値のものが加減乗除する対象ではなければ文字列でも良いのではと思うのですが、ダメですか？

>>553
何か得するの？
だいたいインデックスの順序狂うし

>>554
>インデックスの順序狂うし

そうなんですか。thxです

可変長なら順序狂うの確実だが、固定長なら狂わないかも。
いやどうだろう。大小は文字コード次第か。

>>555
狂わないよ

扱うデータが数なのか文字なのかで決める事でしょ
なぜわざわざ型を捻じ曲げたいのか

たとえば文字列で'002'って格納されてるとする
=2で検索してもマッチしないぞ
格納するときに誰かが'02'や'空白空白2'で格納したらどうする？

加減乗除だけでなく、検索も表示もしないなら好きにすればいいが
そんな項目ほんとにDBに必要か

IPアドレスなら文字でもいいでしょと言ってるんだろ
大規模ならintで保存。
中小規模ならcharでOK．要するにどっちでもいい。

uint32の格納領域をchar配列で定義するようなやつはいつまでもぺーぺーですな。

IPアドレスを入れるのに適した型が提供されているならそれを、そうじゃないなら整数型を。

>>560
大規模でご法度な構造だとわかってるのに、なぜわざわざ中規模で採用するかなあ。

IPAddrにインデックスをはるケースが思い浮かばないな

IPアドレス格納時のデータ型
整数型の利点
・内部表現が一意
・データサイズの平均が最小
・出力時のフォーマッティングコストはそんなに高くない
・サブネットマスクなどの計算もビット演算で可能
整数型の欠点
・内部表現が見慣れない数字

固定長文字列の利点
・登録時に整数への変換不要
・内部表現が見慣れた表示のまま
固定長文字列の欠点
多すぎて書ききれない。

おそらく文字列で問題無しと言ってる連中は、
ネットワーク、とくにIPアドレス体系の知識が無いのだと思われ

あるよ

>>564
思い浮かんだ後で手遅れにならんようにな

>>568
そんな心配は規模が大きくなってからすればいい
スモールスタート時は心配いらん

>>569
スモールスタートは痛いデータ構造を許容する理由にならないので。
むしろ追加予算確保が難しく、また規模増加が起きるとしたら急速で、
なおかつ規模急増中のサービス停止の損害が大きくなりがち。
黒字ラインを突破した途端に破綻して利用者に逃げられる設計なら最初から作らない方が得なんだよ。

>>570
具体的に想定されるケースを挙げてみな？
ログ系ならNoSQLに対比しておけばいいわけだが

>>571
君のところのサイトがどんなに穴だらけになっても他人は困らないし
同業他社はむしろ願ったり叶ったりだから
そのままの気持ちを大切にしていいよ。

>>572
なんだ素人か

用途によるんだろうけど、サブネットが同一か、とかあんまりやらんと思う
実際のところ、IPアドレスを格納してたとして、それを操作する機会ってあんまりないだろうな
たんに記録、表示がメインならドット表示の文字列でも問題はすくないかもしれん

ただ、文字列で格納するとしても、表記を正規化する必要はあると思う
192.168.1.1と192.168.001.001とは、文字列としては別物だからな
で、こんな正規化するぐらいなら俺なら数字で持っとくが

サブネットが同一か、とかチェックするにしてもRDBでやるわけないだろ
仮に文字で格納するなら俺なら１６進表記にするかな。

ドットも保存するの？

数値をわざわざ文字列化してDBに入れる奴もいるんだな。
勉強になった。

>>569
大規模で通用しないDB設計はスモールスタートじゃなくてスモールエンド保証型設計なんだってさ

>>578
この場合の大規模ってのはDWHとかのことね

補足
DWHとODSを同じ設計でするとしたら素人認定だぞ

いや、やっぱり感が直した。
スタースキーマにIPアドレスを保存すること自体が考えにくいな。
おおかた追記型でおｋだな

>>577
つか、>>524はそのアドレスがどういう形で得られるのかも書いてないんだよな。
たとえばこれがApacheのREMOTE_ADDRとかだったら、それでもそれを
わざわざ数値に変換したりするかねぇ。

>>582
ドット付きをDBに入れるくらいなら変換だろう。
どうせ変換するなら
(1) ドット付き→数値
(2) ドット付き→数値→16進数文字列
どちらがいいか

なんのために変換するの？

>>584
むしろ何のために内部表現を文字列にしたいのやら

>>582
特定多数って書いてあるからイントラだと仮定すると、
REMOTE_HOSTのほうがいいんでね？

>>585
必要のない変換ならわざわざやらなくてもいいじゃん。

>>587
わざわざというほどの労力でもあるまいし

LDAP使ってるならREMOTE_HOSTで決まり

parseエラーの対処とか考えたら、変換しなくて済むならそれに越したことはないな。

>>590
お前はパースエラーになりかねないデータを、文字列型だから何でも黙って食ってくれるからといって、
右から左に渡すつもりか？
DBの内部表現が何であれ、アプリがやるべき確認は変わらんだろ。

つかLDAP認証済みならそもそも確認する必要なくね？

>>591
だからそれparseする必要あんの？
それ確認する前に決め付けちゃってない？

>>593
確認するってことは既にparseしてんだろ

だめだこりゃ

変換しない＝チェックもしない＝parseもしない　って事？
HTTPDが返してくるデータだから全面的に信頼してるって事？
ゴミが来てもそのまま入れるって事？

もうプログラミングやめろ。

そう。しなくてOK.
イントラでLDAP認証ずみならな

だから、何を信頼できて何が「ゴミ」なのか、思い込みで設計しないでくれよ。

チェックしなくてokなくらい信頼してるならパースエラーなんか対処しなくていいだろうに

Apacheが渡すREMOTE_ADDRがぶっ壊れてないことをLDAPに頼る設計？
意味わかんね

やはりここはDB板であって、ネットワークやプログラミングに関する
知識の無いヤシが多いなw（もちろん分かってる一部のヤシもいるけど....）
というか、ここは「DB設計を語るスレ」だよな？

>>601
もし君が自分の考えを正しいと思い込んでるなら、ただそれだけで低スキル。

>>600
REMOTE_HOSTだっつてんだろ
DynamicIPだったら信頼できねぇだろうが
頭固いの？

>>603
訂正：信頼できない→クライアントを特定できない

>>602
いや、本当だよ。
自分の領域の外が見えてない石頭のガラパゴス恐竜のスクツだよ。
ちみこそシステムアーキテクチャの勉強でもしたまえ。

>>603
DynamicIPを信用しないのにREMOTE_HOST信用するって…

>>606
だからイントラでLDAPの話だってばｗｗｗ
LDAPでぐぐれ

>>607
LAN内は物理攻撃が容易で、アドレス信用できないときはREMOTE_HOSTはさらに信用できない

なんでipv4アドレス保存を必死に嫌がるのだ？
REMOTE_HOST保存することはipv4アドレス保存しないことの理由になってないぞ？

ならMACアドレス認証とユーザー認証もつけろ
もしくはクライアントにAdmin権限を与えるな。
イントラだから当然FireWallも設置しろ。

>>609
>>604

>>610
訂正　ユーザー認証は要らんな。すまん

LDAPでミスったら被害の範囲を広げるように設計されたwebシステムですかね
REMOTE_HOST原理主義こわい

突然認証の話を創作してる糞電波は誰だよ。
認証関係ないだろうが。

>>613
ミスったら接続できねぇだろうが
そもそもLAN内をどれだけ強固にしたいんだ？

>>614
スレを読めよ

>>615
それ、REMOTE_ADDRをどのような内部表現でDBに保存するかの問題とどんな関係があるんですか？

>>603
>>604

REMOTE_HOSTポイゾニングに弱くね？

MOD_LDAPなりIISなりつかえば桶

>>607
REMOTE_HOSTを作るresolverの仕事をLDAPにやらせるということ？

yes

>>615
> ミスったら接続できねぇだろうが

LDAPミスったら接続できない？
それ質問者の前提を勝手に書き換えて、俺様環境を前提にしてないか？

>>590あたりから異論多発してるっぽいが、それぞれの意見が曖昧で掴みにくい。
ちと整理しとくれよ。

>>623
だーかーらー
固定IPを割り振るとかしてもいいんだよ？
それにレイヤ2で認証してもいいんだよ？
フールプルーフの方法はいくらでもあるだろ

大きく割れ出したのは>>582からだろ

>>582
> たとえばこれがApacheのREMOTE_ADDRとかだったら、それでもそれを
> わざわざ数値に変換したりするかねぇ。

大半はこの数値に変換する是非について語ってるようだが、
そこにLDAPとか認証とかの話が唐突に繋がってくる脈絡が読めん。

>>524

>>628
きっかけはそれっぽいが、それを契機に>>582より新たな議題が提起されて
そこからは変換是非の議論がforkしてるっぽいな。
そこからの流れにLDAPが追加される繋がりがワケワカメ。

変換是非の話の流れ
>>524
>>586
>>587
>>589

そもそも質問者はLDAPとか一切言ってないんだが・・・。
どうしてLDAPとかイントラの話になってるんだ？

>>630
変換という言葉は582までだと>>565と>>582しかなくて、
共にIPv4 addressの数値変換のことを意味している

>>631
仮定だよ仮定。
質問者は
「IPアドレスとホスト名のどっちを格納するのがいいか？」
と質問したのに対して、
きっとアクセスしてきたホストの履歴を残ししたいんじゃね？（それ以外に用途が思い浮かばない。）
（不特定多数ではなく）"特定多数"っていってんだからイントラじゃね？
多数ならLDAPつかってるかもしれないね。
LDAPつかってるなら（使ってなくても）
動的IP使ってる場合もあるから、
REMOTE_HOSTを格納するほうがいいでしょう。

ということでつ。

>>632
ごめん、意味を取り違えた。
変換の話からforkしたくだり。

変換議論まとめてみた。雑に圧縮してごめん。

>>582 REMOTE_ADDRとかだったらわざわざ数値に変換するかね
>>583 ドット付きをDBに入れるくらいなら変換
>>584 何のために変換する？
>>585 何のために内部表現を文字列にしたい？
>>587 必要のない変換ならわざわざやらなくていい
>>588 わざわざというほどの労力でもあるまい
>>590 parseエラー対処を考えたら、変換しなくて済むならそれに越したことはない
>>591 parseエラーになりかねないデータを...渡すつもり？DBの内部表現が何であれアプリがやるべき確認は変わらない
>>593 parseする必要あるのか？確認する前に決めつけていないか？
>>594 確認するということは既にparseしている
>>596 変換しない＝チェックもしない＝parseもしないということ？
>>597 そう。しなくてOK。イントラでLDAP認証済みならば

この瞬間に数値変換議論にLDAPや認証の話が繋がったみたい。

認証があればREMOTE_ADDRのparseエラーは起きないからチェック不要？
apacheの仕組みは良くわからんな

LDAP認証がチェック終わらせてるんだから、後からチェックしなくていい。

IDでないから話がわけわからん

数値保存派と文字列保存派の話だったのにLDAPだったらとかは関係なくね？
intで保存してもipアドレスであることは保証されないから
16進数で桁数指定しても、プログラム上でのチェックは不要ってことにはならんでしょ
だから、逆にLDAPだからって文字列もノーチェックでDBにいれていいかというと大いに疑問がある

そうすると、ipアドレスの型チェックはプログラム上で正規表現でチェックするのが一番融通がきくし分かりやすいし、アドレスは文字列としてプログラム上で使うことが多いから、DBにも文字列で保存した方が自然な気がする
DB設計的なメリデメって数値型でカラム切っておくとgroup byできるくらい？
ドットをDBにいれたくないってどういうデメリットか分からん

> ipアドレスの型チェックはプログラム上で正規表現でチェックするのが一番融通がきくし分かりやすいし
バイナリを取り扱った経験がない人間でも出来るという事か
まともじゃないプログラマが混ざっているアレな現場ならありかもな

バイナリを取り扱った経験がないまともじゃないプログラマが
正規表現の使い方を知ってるとも思えんなぁ

用途がはっきりわからないにあれこれ外野で議論してても意味なくね？

自分の好きに保存すればいいじゃん

v6も数値でいいの？

処理系によるんじゃね

とりあえず、ipもホストもデータで持ってれば後からなんとでもなる。

IPはどっちでもいいんでね？
俺は生でSQL叩く時に楽だし大小比較云々も無いという理由で文字列だけどね(ホストも文字列格納だしその辺と合わせて)
まぁデータ的には数値格納の方がスマートだけどね
ぶっちゃけもうこの辺はポリシー次第

リモホも保存する事には反対してない。
IPは数値に変換して保存には賛成。

数値に変換して格納する場合
・検索対象も数値に変換する（手入力も含めて考えると）
　→　192.168.1.1も、192.168.__1.__1( _ が半角スペース)も、同じ数値に変換される
・変換処理自体をストアードで書けば検索用のSQLも単純で済む
・INSERT時に変換1個1回、検索時に変換1個1回で済む
・データは小さくて済む

文字列で格納する場合
・検索時の入力規則を決めて処理系でチェックするかストアードで同じ表記になるように変換する
・仮に入力、格納データを数値に変換して検索する場合、検索毎に全件件数個＋検索対象1個1回の変換が必要

IPアドレスは元々数値のモノ。
それを人間にわかりやすい表記にしたのが、192.168.x.x形式なんだから、
元々の数値で保存するのが素直なんジャマイカ？

>>646
楽にSQL読み書きしたけりゃ、 INET_ATONとか関数使えばいいじゃん

>>647
文字列で格納する場合だけど、

>・仮に入力、格納データを数値に変換して検索する場合、検索毎に全件件数個＋検索対象1個1回の変換が必要

これはちがうよ。（１個１回という表現の１個が何を指してるのかわからんのだが）
NSERT時に変換1回、検索時に変換1回で済む

おまえらどれだけ巨大なDB作ろうとしているの？

最初の質問者、もう全然出てこねぇし w

そろそろこの話題おわりでいいんじゃね

>>651
いや、いますよ

>>597
LDAPだとどうしてチェックしなくていいんですか？

>>637

>>653
なんだお、いたのかよ

>>655
ちょっと詳しく説明しよか。

組織階層（会社、部門、ユーザー、ホスト等）を一元的に管理できる
Directoryサーバーという物があってだな
そのプロトコルをLDAPという。
一般的にLDAPサーバーといえばDirectroyサーバーのことを差す。
認証方式にはKerberos認証などといったプロコトルを使う。
（他のプロトコルもあると思うがKerberosが多いと思う）

クライアントコンピュータはLDAPプロトコルを喋って、
ディレクトリサーバにログインする。
すると、WEBサーバー等へのアクセスも許可する、ということができる。（シングルサインオン）

LDAPサーバーはネームサーバーも兼ねているので、
マシン名もユーザー名もわかっている。
つまりそのホストは信頼されている、ということ。

そもそも元質問はリモホとアドレスどっち保存しますか？で
IPアドレスの格納形式について聞いてたんじゃないからな

まさに宗教だなｗ
こんなんどっちでもいだろｗ

追記すると、WEBサーバーやアプリサーバーもディレクトリサーバーの管理下に入る。
（入れないことも出来る）
配下にしない場合は、シングルサインオンに制限が加わる。
（３層構造で権限の移譲ができないなど）

>>653
>いや、いますよ


だったら、どういう環境でここはどうこうでって、みんなに説明しろよ
何が
>いや、いますよ
だ w

>>655
LDAPの有無でREMOTE_ADDRのフォーマットの信頼性が上がる？
LDAP詳しくないんでぴんとこないが。

荒らしと言ってる時点でクローズな環境じゃないだろjk

>>662
REMOTE_ADDRフォーマットの信頼性？
フォーマットは崩れるわけねえだろｊｋ

元の要望ではべつにどっちでもいいでしょ。

>>635
> >>596 変換しない＝チェックもしない＝parseもしないということ？
> >>597 そう。しなくてOK。イントラでLDAP認証済みならば

REMOTE_ADDRのparseやチェックの処理がLDAPを使うと不要になる理由は何なの？

>>601
とかなんとか言って全員を低脳扱いしてたお前は
聞き齧ったLDAPという用語を披露してみたかっただけのシッタカだったと？

よくTIMESTAMP型のupdatedなんていうカラムを見かけますが
これって必要なんですか？
更新順にソートしたいケースとかもあるんでしょうけど、
慣習的につけてるような気がする人が多い気がします。

>>668
いつ変更されたかパッと見でわかるじゃん。
むしろシステム運用してると無いと困ると思うけど・・・
DBMSによってはレコード情報でとれるのもあったきがするけども

アプリ側で登録ロジック対応してないと無意味だけど
前触ったシステムでは更新トリガーでセットしてたな．．．

>>667
何を言っているんだ、お前はw
自分はLDAPの知識を自慢げに披露した>>657では無いし、
それどころか今回の話題とLDAPは無関係であり、
却って正しい議論の道筋を混乱させただけ、と断言する

繰り返すけど、ここはDB板にある「DB設計を語るスレ」だよな？
DB設計の本質とは、断片的な顧客の要望(>>524,527)から
適切なデータモデルを導く過程、それを忘れてはいまいか？
まぁ、いつもの業務アプリ/DB系とは異質な領域であり、
皆不慣れであるが故にいくらかの混乱はしかたないと思うがな

>>668
よくWindowsでもLinuxでもファイルには更新時間なんていう属性を見かけますが、
これって必要なんですか？
更新順にソートしたいケースとかもあるんでしょうけど(たとえばmake)、
大半のファイル処理では更新時間なんて必要の無い情報に思えます

>>668
必要があるか無いかはそのテーブルの使われ方によるから何ともいえん
つかお前はよく見るのかもしれんが、俺はめったに見ないぞ、そんなもん

俺はよく見るよ
>>668が思っているように、慣習的につけただろって感じのもよく見るよ
さらに、更新漏れがあるといやだってなって全テーブルに>>669で書いてるようなトリガつけてるのも見たことあるよ
このテーブルにはいらないよねって現場のみんなが認識してるけど、統一感を保つためだけにつけてることも

ちなみにそういうところには、作成日時と更新日時と削除フラグがセットであったりする

>>668
RDBMS以外のキャッシュにデータ丸投げしてるときに、デーモンがupdatedの最大値の変化を検知してキャッシュ更新処理に移るということもあり。
FSのタイムスタンプみたいな存在でもあるけどね。トラブル時にはどんな情報も欲しい。

>>668
同時並行更新処理のときには使ってるよ。
一回SELECTしたデータをUPDATEするときに再度WITH UPDLOCKで取ってきて
こいつが更新されてなければ自分で更新、って感じ。
たぶん赤間本の影響でここ10年来時々見る。

>>670
おい別に自慢してねぇぞ。
効かれたから説明しただけだ
しばらくレスできんぞ

赤間本の影響を受けたならSQLServerの予感がするんだけど、
もしそうならtimestampじゃなくて本名のrowversionに移行してあげてほしいな

>>676
文句があるなら、>>667に言えよ
>>667によれば、お前さん(>>657)は
「聞き齧ったLDAPという用語を披露してみたかっただけのシッタカ」
らしいぞwww

そそっかしい>>667に>>657だと勘違いされるのは、
自分としては、正直言って大迷惑だよ

安価多すぎワロタ

わけわかんねえ。
とりあえずLDAPを言い出したやつが名前にLDAP入れれば？ww

いや、そこは明らかにする必要ないだろ
もうこの話は終わりでいいよ

>>673
甘いな。作成者idと更新者idも付いてるわ。

次の方どうぞ

>>682
ああそうだ、ごめんわすれてた。
都合5カラム強制付加しびれるよねｗ

>>681
せっかく勉強になる話だったからもっと聞きたいんですが。こんなので止まったら残念です。
LDAPとの関連の部分が良くわからなかったので詳しい人の説明を聞きたいよ。

>>666
REMOTE_ADDRはIPプロトコルヘッダの中に入っている送信元アドレスだから。
つまりHTTPとは無関係だから、ホストが信頼されていれば、REMOTE_ADDRも信頼できる。
LDAP環境ならREMOTE_HOSTも一応信頼できるが、完全に信頼するにはIP逆引きが必要かもしれない。（LDAP_DNSで逆引きするよう設定していても）。
まあどこまで信頼するかだが。

Apacheの話なら、REMOTE_HOSTはREMOTE_ADDRをApache自身が
逆引きした結果だろうが。

それはどこから取得していると思う？

すまん誤爆

>>685
ここはおまえの勉強jのためのスレか？

勝手にapacheチューニングしてろよ

>>686
LDAPならREMOTE_HOSTが信用できて、DNSならREMOTE_HOSTが信用できない？
それはなぜ？

DNSのサーバすら信用できない状況ならLDAPのサーバも信用できるわけないWWW

LDAPのDB設計の話でもするんか？

DB設計の際、IPを整数にするか文字列にするかの判断材料に
LDAPが関わってくるという説があるってことだろ

>>524,527が元だよね。

特定多数の(LDAPで信頼されているかもしれない)ホストのうち、
いずれかが荒らし行為をする可能性があるから、IPアドレスなりホストなりを残したいと。

部署ごとにサブネット分けてるかもしれないし、統計出すことも考えれば、
整数で入れておいたほうがいろいろ楽だろ。

で、整数で入れる方が合理的だが、その場合REMOTE_ADDRをparseしなければならず、parseエラーにも対応しなければならない。
一方文字列で入れる場合、parseやチェックを整数と同様にやるべきか、それとも省略できるかについて意見が別れている。
ただし名前解決にLDAPを使っている場合はチェックしなくてもよい。

オチワロタ

>>697
LDAPを使っていようがいまいがREMOTE_HOSTのパースエラーは
対応する必要ないよ。
WEBサーバーのセッション変数REMOTE_HOSTは
[0-9]{1-3}¥.[0-9]{1-3}¥.[0-9]{1-3}¥.[0-9]{1-3}
の形式しかありえない。

>>692
DNSが信頼できないということではない。
HTTPクライアントが渡すHOSTが環境変数REMOTE_HOSTに渡ってきたら、
逆引きしないとまずいかなーと思っただけ。
>>687
ということだから、
REMOTE_HOSTも信頼できるということになるな。

>>697
LDAPを使っていようがいまいがREMOTE_ADDRのパースエラーは
対応する必要ないよ。
WEBサーバーのセッション変数REMOTE_ADDRは
[0-9]{1-3}¥.[0-9]{1-3}¥.[0-9]{1-3}¥.[0-9]{1-3}
の形式しかありえない。

2回も書いたのに、ネットワークアドレスが入ることがありうると曲解されそうですよそれ

>>699
REMOTE_HOSTのパースエラーなんて話は今まで出てきてないずらべよ

だいたいアドレスのパースエラーなんてアプリではじくべき話で
DBに格納するのは正規化されたアドレスだけにしとけって話じゃないのか
DBには正規化された形式で格納するべきで、DB設計の話じゃないだろうと思うんだが

もちろん必要ならIPアドレスとしてパースエラーが起こるようなデータを保持するって設計もありだが
それを勧めてるようなやつはいなさそうだし

それが要件ならそれに従うだけ。
それを確認しないうちから、あるいは勝手に決め付けて、議論してもはじまらない。

>>703
うん。それ誤爆。
あぼんできないのか。

>>705
どちらかというと格納形式への要件を定める立場なんだがな

質問者はここを眺めてるだけで方向性を修正しようともしない

こんなのいくら議論してったって無駄

いやだから、元質問と全然関係ない話題でもりあがってるんだが

>>707
よそさまのシステムの要件定義もできちゃう立場なんですねｗｗｗ

>>704
アドレスのフォーマットに変なのが入ってくる確率なんて
99.99999999999％ないんじゃね。
ただひとつだけあるとしたら、WEBサーバー自身がバグってるとき。

>>711
もしバグってたらもっと高頻度で壊れるのでは？

>>706
ローカルあぼーんだった…
あぼーんしたことねぇからやり方わかんね

>>712
そうだね。
でもそれはアプリのバグじゃなくてサーバーのバグだから、
考慮不要じゃね？

>>711
そういう変な数字をでっち上げる癖は捨てた方がいいのかもしれん

イレブンナイン

しかし
>>711が測定ミスする確率は10%以上あるんだって

今日は静かだな。よし、今日のお題ー

【（バグがあるかないかわからない）サーバープロダクトのパースエラーは考慮する？しない？】

だ。おまいらどうよ

>>718
意味が分からない

それが致命的かどうかによるでしょ

考慮はするでしょ。
対応するコードを書くかどうかは別だけど。

データベースは外部の情報の正確性とかそういうのに依存しない設計が望ましいと思うから、チェックする(・∀・)ｽﾝｽﾝｽｰﾝ♪

チェックするのはDBの仕事じゃないだろう

チェックされた正規の形式でしか格納できないようにするか、
チェックされていない不正な形式のデータでも格納できるようにするか
が、DB設計で考慮するべきことだ
つまり格納するデータの要件としてチェック済み（とみなせる）か否かだけの話

DBMSのチェック制約って使う？使わない？
俺が経験したプロジェクトだと圧倒的にしないとこが多い。

ERPとかだと参照整合性制約すら使ってなくて、
アプリ(ERP)でチェックするしな。

ちなみに俺がスクラッチするなら使える制約は基本的に使う。
RDBに整合性が担保されないデータが入ってきたら後々面倒だから。

>>724
最近はDBでの整合性保障を減らしてる。
KVSとか他のストレージと組み合わせたときの統合的な整合性保障を考えると
ビジネスモデルレイヤーでの抽象的な保障を狙って設計した方が後々の破綻を防げる。

サロゲートキー推進派に質問なのだが、
有効期間を持つマスタにサロゲートキーを付ける場合、
トランザクションを打つ段階で、有効期間が正しくメンテされているとは
限らないとすると対応できる？
たとえば後から単価が決まる（２０日〜月末の単価は１０％オフみたいな）場合、
マスタを修正した時点で、トランに格納されている２０日〜月末のマスタIDを
裏から一括で変更しないといけないんだが…

サロゲートキーを自然キーに置き換えると答えが変わる話には思えないんだが

その日の売上(トラン)と関係ないかも知れないマスタを
トラン(売上)に入れておくこと自体がおかしい。

サロゲートキーはオブジェクト指向みたいなもんだ。オブジェクトは
主キーがあろうがなかろうが、メモリ上の番地が違う以上一意に識別できる。
オブジェクトはどのオブジェクトを呼びに行けばいいのか生成時に知っている。

DBでそれをやろうとするなら、レコード生成時に参照先を固定できないとな。
たとえば単価の有効期間を持つマスタから日別単価マスタを作っておくとか。

サロゲを上手く扱えるモデリングツールがねーよ。
皆の衆はどうしてる？

お前が上手く扱えてないだけだろう・・・

Type A)
論理ERDはNatulalKeyで設計して 、物理ERDでサロゲに落とす。
Type B)
・論理ERDの段階からサロゲ、NK、その他の３区画にできる。

俺はAしか見たこと無いが、本当はBにしたい。
Aも使い物にならん。

Aでもいいけど、NKがそのAKとしてまま残る事が条件だな。

ここってオラクルのスレでいいの？

オラクルのことはオラクルスレに行ってくれよ

はい

モデリングツールって使ったことがないんだが、おまいらオヌヌメのを教えてください。

システム規模が小さい場合、データベース設計を頑張れば頑張るほど後悔する。

後から変更が出るのは規模の大小には関係ない。
最初から完璧なDB設計をする方が無駄だと思う。

>>728
メモリ上の番地が業務的に重要なわけじゃないんだよ。
例えるなら、住んでる場所（アドレス）ではなく住んでる人（コード）が
重要なわけで、住所が変わる前でも人は存在するから、
売り上げは上がるけど、請求するタイミングでは引っ越してるから、
古い住所に請求書送ってもダメってことだよ。

>>739
それもそうだし、売り上げ発生時点の情報がほしいこともあるよねってことじゃ

>>739
売上は売上、請求は請求で日付が違っても別のイベントなんだから
それぞれその時点で追えばいい。遡及するわけではない。
ある時点の住所が後から決まったりしない。

この例は遡及して洗い替えたいっていうもので別物だよ。
小売でセールの期間でどうなったかを後から決めてみたり
アパレルで単価が後付で決まるなんてのは当たり前。
当たり前なのが分かってるならテーブルも分けとけって話。

あなたの隣の集団ストーカー
駅改札や駅周辺で、人の流れを見張っているのが犯人です。
犯人はナマポで税金で食べていけるため通勤、通学者を
馬鹿にしながらターゲットを見張っています。
エア待ち合わせとエア電話が得意です。
エア荷物、エアマスクもいます。鉄道職員にも犯人がいます。

■商品テーブル（item）
■商品のタグ用テーブル（item_tag）

があるとして、1商品につき複数タグを投稿できるとします。
（ニコニコ動画みたいなイメージです）

大体は、タグテーブルに「id、item_id、comment」
というフィールドを作成すると思うのですが、
ニコ動とは違って、登録・編集画面で
いくつかのタグをあらかじめ指定する形を考えています。

1商品に対するタグを変更する場合、
一旦、該当する商品のタグを全削除して
改めて追加する仕様が思いつくのですが、
考え方が間違っている気がしてなりません。。

説明が下手で申し訳ありませんが、分かる方はアドバイスをお願いします。

>>743
タグとコメントの違いはなんですか？

タグテーブルに「便利」とか「面白い」とかのタグコメントが入るという意味です

タグづけは多対多だからテーブルが全部で3つ必要

タグとはコメントのことではないようですね。
ではタグとはなんですか？

商品本体と商品タグの組み合わせか

ニコニコ動画みたいに商品タグを投稿できるというのがよくわからんが
ニコニコ動画には動画投稿以外に投稿あるのか

ニコ動は動画毎にユーザがタグを設定できるよ

>>746
商品とタグテーブルは分かるのですが、それ以外は分からずです
>>747
nameにした方がわかりやすかったですね。すみません。

>>751
nameだと商品名、すなわち商品ごとに１つづつ異なって割り当てられる属性ですよね？
タグというのは商品名のような扱いを受けてもいい？
何をしたいのかを明確に表現できれば、テーブルの形は自然に決まると思いますよ。

>>752
いえ、>>743に書いたタグテーブルの「comment」が気になったんですよね？
だから「タグの名前＝nameにしたらよかったです」と言いました。
商品名だったら、「商品名の名前です」と書きます。

商品名の名前って変な言い方ですね・・・すみません。

とりあえず、現状のテーブル構成を再度書きますと、

■商品テーブル（item）
id、name
■商品タグテーブル（item_tag）
id,item_id,name

と、ここまでの設計は考えつくのですが、
これだと、商品に対するタグを割り当てる（登録）時や
編集する時に、いちいちタグテーブルを削除して再度登録しなければ
行けないのかと思い、設計が間違っているのでは？と感じて質問しました。

>>753
なるほど。ではあなたにとって、タグテーブルで扱われるタグとはなんですか？

商品タグって、値札のことだよな

ニコニコ動画みたいにユーザーが値札を投稿できるようにしたいんだ？

>値札を投稿

オークション？

>>751
アイテムとタグの関連を記録するテーブルをつくるんだよ

つまりこういうことだろ？

タグテーブル
id,name

DBってあんまり使った事なくて、一度使ってみようと
アプリはJavaで作ってて、1秒ごとに数十バイトのデータをUDPでばらまいて
るLANからデータ取ってます。秒単位のデータを60個で分データにして
分データ60個で時データに集計するものです。
とりあえずDB使った事ないからApacheDerbyで組んだら鬼重くて死にそう
なんですがどんなDB使った方がいいんでしょうか？
sec_data (intime datetime, v1 int, v2 int ...10個くらい)
min_data (intime datetime, v1 int, v2 int ...10個くらい)
hour_data (inttime datetime, v1 int, v1_avg int, ... 15個くらい)
データの集計はdatetimeをbetweenしてます。

マシンはatomの2コアで
DBをramディスク（/dev/shm）に作ってますが集計マジ重いです。

そもそもatomというのが…

>>763
ですよね。。
場所の制約で組込み用の86マシンですから。。
ちなみにマシンスペックが普通のsandy3Gくらいの4コアだったとしたら
こんな要件にはどのDBで対応されますか？

>>761
あまりにも固定サイズ過ぎて定型すぎる統計処理を頻繁にやるときって
RDBMSを計算で使わないよな。

分データ、時データはいつ作るんだ？

>>761
1秒ごとに数十バイトのデータをUDPでばらまいて
> るLANからデータ取ってます。秒単位のデータを60個で分データにして
> 分データ60個で時データに集計するものです。

そういうデーモンをC++で作ってしまえば、 毎秒百万回程度の速度で新着データを送られても
リアルタイムに集計を続けられる。
DBはバックアップ程度のつもりで複数行同時書き込みでもするくらい。読むことはない。

>>765
insert into min_data values (select sec_data avg(v1)....)
ってな感じにやってます。
>>766
分データも時データもシステム時間からです。
毎分・毎時にminなりhourに該当時間のデータあるか見てなければ前分データの集計
と前時データの集計です
データに時間の概念が無いので、秒データ受けたらシステム時間で"yyyy-MM-dd HH:mm:ss.SSS"で
insertしてます。
>>767
おっしゃる通りで、今までは普通にCでUDP受け、パイプでインメモリ集計
ただJavaやってみたいのとDB使ってみたかっただけです。

>>765
すいませんミス。。
insert into min_data select sec_data avg(v1)...between '00秒' '59秒'
ってな感じです。

>>768
あなたのやっていることは、たとえ規模や速度に違いがあっても
「全国各地の自動化された震度計から送られ続けるデータを集計して、
必要に応じて緊急地震速報を流すシステム」に似てます。
ログなどを本システムとは異なる処理として非同期でDB保存することはあっても、
一旦DBに書いてそれを読んで集計するという設計はありえません。

>>768
> おっしゃる通りで、今までは普通にCでUDP受け、パイプでインメモリ集計
> ただJavaやってみたいのとDB使ってみたかっただけです。

では同じ設計のままJavaで書く。
DBにはデータ保存だけしておく。
insertは数百件や数千件をまとめて。
毎分の集計ではDBを使わなくていい。
まれに特殊な条件で集計したくなったときだけDBを読む。
どうしても日常的に読みたければ必要最低限かつ十分なindexを用意する。

>>770-771
やはりそうですよね。やってみたかったからやってみたら
すっごい重くてどうにもこうにも。。得手不得手が有るのは承知です。
ただ単にDB触る事あんまり無いだろうからやってみたかったというのが実情です。
やっぱいつも通り正攻法で行きます。 ありがとうございました！

>>769
SQLite3でインメモリDBを使った場合だと数msで終わる処理だね
Derbyの事情はまったく存じないけどインデックスとか効いてなさそう

>>772
あなたがDB得意になったら、そのアイデアでも実用化できなくはない。あまりおすすめできないけど。
しかしDB苦手なうちにチャレンジしない方がいい。
それは教材に向いてない課題だから、今はその問題については諦めていいです。
他のもの作りましょう。

ここって質問スレなの？
話した内容纏めないなら意味なくね？

>>775
>ここって質問スレなの？

スレタイ嫁よ…

>>775
新顔さんかな？
このスレでは以前からずっとDB設計相談室みたいになっていたから、
DB設計に関わる話題なら何でも好きに語ればいいし、
無理に纏める必要も無いと思う

少なくともしばらく前にあったような
DB設計そっちのけでグダグダした雑談をされるよりも、
今のほうがズット正常な流れだ

DBそっちのけでグダグダ雑談してる方が正常に見える。

>>775
君は内容を纏めることに意味を感じるのなら、
君が纏めればいいんじゃないかな。

質問スレ別にあるし、業務毎とかで使いそうなデータ構造をwikiにでも纏められると嬉しいんだがね

>>780
言い出しっぺの法則

>>780
それが望ましいとあなたが思うなら、どうぞご自由におやりください

ネットショップで発送地域を選択する場合があります。

条件として
・複数選択可
・地域ごとに集計したい（例：東京に発送できるお店3件のような表示にしたい）
・エリアで選択出来るようにしたい（例：関東を設定すると、東京も神奈川も発送圏内となる）

こういった仕様の場合、発送地域テーブルに都道府県別で追加するのでしょうか？
それとも1カラムに選択した都道府県をカンマ区切りで入力するのでしょうか？

このような設計を行った経験がある方は教えて下さい。

>>783
カンマ区切りなんてしないよ

>>783
適切に正規化するのであれば、テーブルは４個必要になる
・注文テーブル
・注文-発送都道府県-関連テーブル
・発送都道府県テーブル
・発送地域テーブル

テーブル間の関連を以下に示す
・注文と発送都道府県は関連テーブルを用いてm対n関係
・発送地域と発送都道府県は1対m関係

テーブル数を減らすのであれば、正規化を崩して
発送地域と発送都道府県を一つのテーブルにまとめてしまう方法もある

注文テーブルはどこから出てきたｗ

>>785
そこまで分けると登録時のUIが想像出来ないんですよね・・・

例えば↓こういうフォームをよく見ますが、
□関東
□東京　□神奈川　□埼玉　□千葉　□茨城　□栃木　□群馬

選択した都道府県を「発送都道府県テーブル」に
追加していけばいいと言うのは想像できるのですが、
「関東」にチェックを入れた場合どうなるのでしょうか？

>>785
> ・発送地域と発送都道府県は1対m関係

それでいいの？
ホテル検索とかでは
・東京
・新宿区
・23区以外の東京
・関東
・東京以外の関東
なんてのを区分として列挙するのを普通に見かけるんだけどな。

>>787
UI の問題は他の場所で質問してください

でも、設計が頓挫してるとUIにも影響が及び、運用出来ませんよね?
実用化まで想定するのが設計だと思いますが・・・

>>787
Table: 発送地域テーブル

地域 | 県
----+---
関東 | 東京
関東 | 神奈川
関東 | 埼玉
関東 | 千葉
関東 | 茨城
関東 | 群馬
東京 | 東京
神奈川 | 神奈川
埼玉 | 埼玉
千葉 | 千葉
茨城 | 茨城
群馬 | 群馬

で、いいかと。

>>770
なぜありえないんだ？

>>790
それはお前の都合だろ
UIはスレチだから他所いけ

>>791
これで行きます。ありがとうございます。

>>793
器小さいんですね

>>794
脳にウジがわいてるみたいだな。ウザいから消えろ

>>790
DBとモデル層がちゃんと作られてたら、あとからどんなUIを足してもいいし変えてもいい。
事前に想定されたUIとか必要ないし、そんなものの想定引っ張られて下位レイヤー作ってもろくなことにならんですね。

>>791
リレーションしてない感が漂いまくって面白いな。

リレーションするｗ

>>798
普通に使うだろ

>>797
ちょっとどの辺にリレーションしてない感が漂ってるのか詳しく説明願う。

リレーション「する」って言い方をするのは、リレーショナルデータベースを
理論から学んでない人だろう。

>>800
関東

>>802
なにそれ？
説明できないなら、無理にとは言わないけど。

>>803
理解できないならムリしなくていい

そもそも>>783は貰った回答を理解できなかったから具体例を上げて更に尋ねたんだろ
それを視野狭窄な>>789がフォームという単語に反応して変な事を言い出しただけに読めるな

>>805
みえませんな

レベル低っ

巣に帰ればいいのに

>>800
わかんないやつなんかどうでもいい

>>791
とりあえずダメっぽさがある

>>801
英語では動詞としても使われるし
英文ドキュメントに慣れた人同士だと
DBに限らず色んなところでよく使う

>>811
どうでもいいが動詞ならrerateでは。

typo relate

そういう問題じゃねぇｗｗｗ

このスレ的にいえば
一般にリレーションってといえば列と列との関連だぞ。
リレーションシップはエンティティ間の関連。

お、おう

>>791は
とりあえず
東京｜東京
以下はいらんな

おい、おまいらそれよりもっと頭のよさそうな事言おうぜ！

レス遅れた、スマソ

>>787
基本的に>>796の意見に賛同する
以下、>>796と重複する部分はあるけど、自分なりにコメントする

UI層は(>>796も指摘しているように)頻繁に仕様が追加/変更されるものだし、
(UI無しに)他店APからの一括注文をメッセージとして受信することも考えられる
それに対してDB層は(単純なフィールド追加等を除く)仕様変更には多くのコストが必要なので
DB仕様の安定性が重要になる
だから、DB設計においては極力UI層への依存部分を減らす努力が必要

具体的には、たとえば
・UI層でイベント「関東チェック」が発生すると、
・モデル層の都道府県一括更新手続きが起動され、
・都道府県テーブルへ地域コードを条件とした一括UPDATE文(SQL)を発行する
いう実装が考えられる

追記：>>794の下段はいわゆる「余計な一言」、スルー耐性を習得汁！

大分類、中分類、小分類や、今回の地方、県のように本来階層をもつ分類を
フラットな１個のテーブルに入れてしまう設計はどうだろうか？

コード,親コード,名称
　　01,　　NULL,関東
　　02,　　　01,東京
　　03,　　　01,千葉

みたいな設計
メリットデメリット語ってくれ

メリットになるケースがほとんどない

>>820
配達地域区分とか商圏とかホテル検索で使われるエリアとか、
都道府県市町村などの行政の階層と一致してないので、
行政の階層にだけ合致させた設計は実情にそぐわなくなる。

行政じゃないものを行政の階層にまぜまぜするのが変なだけ
別テーブルにすればいい

日本は長らく都道府県の再編が止まってるから実感しにくいかもしれないが、
都道府県が持つ地理的な範囲と自治体とは異なる情報。
市町村で考えれば分かるかな？
合併ブームだったとき、地理的な範囲を表現するために市町村コードなんか使ってたら合併の前後でデータ不整合が起きたり。

>>788
まず、顧客要望(>>783)からの(身勝手な)推測と
受注業務における発送先区分体系はホテル業務や運送業務ほど複雑にはならないという
常識から、>>785くらいで十分であろうという考え方が一つ

次に>>788の懸念への対応については、
ちょうど>>820から議論が始まったので、そちらを参考にしてください

>>822-823
つまり>>788の例でいけば、必ずしも東京都と新宿区が別階層である必要はない、って解釈でいいのか？

階層をどうとるか、って問題はあると思うが、階層がある、って前提で>>820を考えたらどうだろう

メリットとしては階層の変更しやすいとか、階層が可変な場合に有効とか思いついたんだが

>>804
了解、指摘はするけど説明はできないと言うことね。

ほほえましいねぇ

わかってないのは君だけだよ

一般論として、この手の問題で
分からないと主張する人が分かることの第三者へのメリットは滅多にないが、
当事者はそのことを理解しにくい

>>828-830
理解できてないのは認めるけど、説明できてないのも事実だよね。

>>831
説明する人が説明したくなる理由を作るのは、尋ねる側の説得力だよね。
ストップして誰も損だと思わないならそこで話ストップしても仕方ないし。

いや、スルーしろよｗ

スルーかわいそう

>>832
> リレーションしてない感が漂いまくって面白いな。

の理由を聞いてるだけなんだが、説明できないなら別にストップしてもらっていいよ。
指摘だけしたい奴って、別に珍しくないから。

>>835
お前も含めてみんな分かってるんじゃないか？

スレがリレーションしてない感でヤバイ

つかさ、みんなリレーションしようぜ

リレーションできない制約なんだよ
名前を見るんだ

俺はトゥギャザーしたい

お後がよろしいようで

>>836
結局説明はなしということね。
まあ、想像通りの結末だったな。

UIから入ってもいいけど、考え方は整理しないとな・・・
画面をつかう人の選択範囲として適切なのは何だ？
そこから何を判断基準として何を選ぶのか？
場所でいいのか？まずは商品から入るんじゃないのか？

あとは要件として鵜呑みにしていいか疑問なのが・・・
発送地域ってのはショップの都合で決まるのか？
日本国内ごとき、送ろうと思えばどうとでもなるんじゃないのか？
料金・納期の問題じゃなくて制約なのか？ホントか？

考え方を整理したり要件を分析するのはいいけれど、
ここがDB設計であることを忘れずに議論することを望む

訂正

X: ここがDB設計であることを忘れずに
O: ここがDB設計スレであることを忘れずに

現実を写像するとかいうキレイ事の設計なぞほとんどない。
オッサンのタワゴトやらウソだらけの現行システムドキュメントを紐解くんだ。

心憎いばかりに分析されたシンプルな作りで、少々のこる不可解な部分は
今は分からないが半年後1年後にユーザーが泣いて喜ぶ仕掛けが埋め込まれてる。

・・・てな事をするのが設計だろ？

>今は分からないが半年後1年後にユーザーが泣いて喜ぶ仕掛けが埋め込まれてる。
ここってニュアンスによっては微妙だよね
工数掛けずに出来るならいいけど、無駄に拡張性のために工数を使うのはプロの仕事じゃないと個人的に思う
要件外でって意味でね

>>847
受託のようなプライド不要の世界は捨てておくとして、
多くの設計の世界で、真の要件は与えられるものではないんだがな。

>>847
もちろん時限爆弾だと思う。
逆にとったとしてもイースターエッグは今喜ばれないから、これもアウト

>>846
拡張はリレーションを張っていけばいいのて、エンティティの設計レベルではあまり気にしたことはないな。どこに張ったらいいかで悩むことは多々あるけど。

>>846
>現実を写像するとかいうキレイ事の設計なぞほとんどない。

そういうセリフが吐けるのは「キレイ事の設計」ができるようになってから

そんなDB設計の基礎ができていないヤシラに限って、
>心憎いばかりに分析されたシンプルな作りで、少々のこる.....
などという、独りよがりで過去の経験だけを頼りにした運頼みの設計をやらかす
その結果、そんなシステムの保守を引き継いだ若手からは、
「オッサンのタワゴト」やら「ウソだらけ」と揶揄されることになる

動けばいいんだよ。

done is better than perfect
だっけ？

>>851
正規化するとテーブルが４つだのナンだの言う前に、たった数行の中に
「発送地域」「地域」「エリア」「発送圏内」
とこれだけ用語を乱発してるのを何とかしてやるのが先だろ

表現が安定しないやつもそうだが、そこを正そうとしないで設計にすぐ
入りたがるやつにも碌なのがいなかった

なあなあで握って進めるから、破綻が判明するのはだいぶ後のテスト時

たしかにな
用語の定義をちゃんとしないやつは
相手との認識も合ってない

おっさんがいないとスレが止まるな

誤爆したorz

m対n(=多対多)の関係はRDBで表現できないのはご存知？

は？

交差エンティティ作れば済むじゃん

トランザクションの概念を語るとき、よく銀行のシステムが持ち出されますが、
これら銀行のシステムでも設計の仕方によってはトランザクション不要に出来ますでしょうか？

>>861
トランザクションやRDBMSの概念が生み出されるよりも、
銀行システムの誕生の方が早いので。

>>860
そう。交差エンティティ作って1対多の関係にしなければいけない。

アホか。
まぁ、「交差エンティティを作れば」表現できるという答も100%正解ではないが。

ほら、これがABとabの多対多関係を交差エンティティを使わずに表現したものだ。
(A,a)
(A,b)
(B,a)
(B,b)

まぁ、「交差エンティティを作れば」表現できるという答も100%正解ではないが。

イミフ

>>865
> まぁ、「交差エンティティを作れば」表現できるという答も100%正解ではないが。
> イミフ

何を言ってるのやら

>>866
交差エンティティで表現出来ない多対多の例をあげてみてくれないか

>>867
単に『まぁ、「交差エンティティを作れば」表現できるという答も100%正解ではないが。イミフ』という表現から伝えたいことが伝わってこないというだけ

99%の正解って言うのがあるのか？

>>867
逆だ。
交差エンティティ「でも」多対多を表現できるというだけで、それが
必須というわけじゃないということ。

>>870
多対多は...

・交差エンティティで表現できる ... 正解
・交差エンティティでも表現できる ... 正解

・「交差エンティティを作れば」表現できるという答も100%正解ではない ... 不正解

つまり、>>863 は、馬鹿ということ。

>>864は論理的な考え方ができない子なんだな

>>863
スマン、レス番間違えた。

>>864 だった ... orz

>>863は馬鹿、で合ってると思うぞｗ

＞100%正解ではない ... 不正解
>>871も馬鹿であっているｗ

少なくともレス番間違えて話をgdgdにするのは馬鹿に違いない

>>875
>＞100%正解ではない ... 不正解

また、アホが一匹でてきたぞ。

つまり>>864が変ってことか

>>871
100%正解ではないという表現が悪いのか。じゃあ表現を変えよう。
RDBで多対多関係を表現するのに交差エンティティを用いればいい
ってのは十分条件にはなってるけど必要十分じゃあない。
お互い従属関係を持たない2つの属性からなるリレーションはそれ自体
多対多関係を表現できるんであって、それは交差エンティティに限らない。

・2は偶数だ
・人は哺乳類だ
↑こーいうのまで否定しだしそうだなw
↓こーいうのが否定出来る事と混同してる
・偶数は2だけだ
・哺乳類は人だけだ
論理学やり直してきた方がイイ

>>864が言っている組み合わせを格納できるエンティティがまさに交差エンティティなんだが。なんでみんな突っ込まないの？

話題が基礎的すぎて興味ないんだろ

もう放置でいいんじゃね？

>>881
交差エンティティはエンティティ間の関連を表現するもので、ERモデルで
設計する場合に用いられるもの。>>864でいえばABあるいはabにあたる
エンティティが存在してそのとき>>864を交差エンティティと呼ぶが、
>>864はそうではない。
なんかそのへん混同している人が多いみたいだが、RDBとERは
イコールじゃないぞ。RDBの入門書なんかでいきなりエンティティが
出てくるものもあったりするから仕方ない面もあるが。

お前らの言ってることが全然分からない
おすすめの書籍を教えて

>>880
そういえば最近見たニュースで、「偶数と奇数を足すと必ず奇数になることを
説明せよ」という問題に「思いつく偶数と奇数を足したら全て奇数だった」という
回答を書いた大学生がいたというのがあったな。

掲示板をつくっています。
・親投稿
　└ 子投稿
　└ 子投稿
のように１つだけコメントができるようにしたいのですが、
投稿テーブル、コメントテーブルと分けたほうがいいですか？
同じ情報を保持しているので、なるべく１つのテーブルで簡潔させて、
なおかつJOINで１度に子投稿も一緒に取得したいのですが、
・実装方法・その実装での子投稿を含んだ投稿を取得するSQL
を助言してもらえませんか？

関連付けのためのテーブルができてもかまいません。

>>887
あほか

>>887
投稿テーブルとコメントテーブルで想定するフィールド名を示した上で、
SQL質疑応答スレ 12問目
ttp://toro.2ch.net/test/read.cgi/db/1316769778/
に行くといいよ。

今動いているシステムのER図を作りたいのですが
ダンプしたsql文放り込んだらER図を作ってくれるようなソフトありませんでしょうか？

dbmsは？

MySQLですが、関係あります？

Workbenchで桶

>>887
親投稿(投稿テーブル)と子投稿(コメントテーブル)が「同じ情報を保持している」のだから、
単一テーブルで設計してもかまわないと思う

（本当に「同じ情報」であるという条件付き。後出しで「実は....」なんてのは勘弁してネw）

具体的なテーブル設計としては、たとえば以下のフィールドを持つ
単一の「投稿テーブル」を定義する
・投稿IDフィールド -- PK, シリアル型
・区分フィールド -- 文字列型, 値制約: "親" または "子"
・親IDフィールド -- FK, 整数型, 参照性制約: 投稿テーブル.投稿IDフィールド
・(その他の共通情報を表現する複数のフィールド)
親IDフィールドは、区分フィールド値が "子"の場合にのみ有効であり、
それ以外("親"の場合)はNULL(無効)とする

検索のSQL文については、まずは自分で考えよう(単一テーブルだから初歩レベルの問題)
もし考えても分からなかったら、このカキコを添えて>>889紹介のスレへ逝け

>>894
区分フィールドいらなくね？
親IDがNULLなら親ってことだし
NULLがいやなら0でもいいけど

>>894
子コメントの下にもコメントツリーをぶら下げられるようにしよう！
と、まるで専ブラやメーラーのように。

なんて言い出したとき、そのテーブルで「全然平気、任せとけ」と言えるか？
無駄を増やした挙げ句、能力を低下させてるかのようだ。