5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

DB設計を語るスレ 4

1 :NAME IS NULL:2011/07/05(火) 10:14:00.14 ID:???
前スレ
DB設計を語るスレ 3
http://hibari.2ch.net/test/read.cgi/db/1269585561/

DB設計を語るスレ 2
http://pc11.2ch.net/test/read.cgi/db/1223458453/

DB設計を語るスレ
http://pc11.2ch.net/test/read.cgi/db/1166540159/

2 :NAME IS NULL:2011/07/05(火) 17:18:59.72 ID:???
PRIMARY KEYの指定されているテーブルに、
他のNOT NULL UNIQUE制約を持つカラムを入れるべきではありませんか?

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

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

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

3 :NAME IS NULL:2011/07/05(火) 19:58:50.74 ID:???
>>2
その項目がNULLが入って困るならNOT NULL制約をつければシステムが保証してくれる
その項目がユニークであるなら、UNIQUE制約をつければシステムが保証してくれる
すくなくとも本番DBなら付けない理由がないんだが?

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

4 :2:2011/07/05(火) 20:14:52.26 ID:???
>>3
テーブルにプライマリキーを2つ以上定義してはなりませんが、
NOT NULLでUNIQUEなカラムはプライマリーキーと同義です。
なので、プライマリキーを指定してるテーブルには、
NOT NULLでUNIQUEなカラムは含めるのは設計的に正しくないのかな?と思って質問しました。

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

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

5 :NAME IS NULL:2011/07/05(火) 23:43:07.77 ID:???
テーブルには複数の候補キーが存在し得る。
かなりはじめの方で学ぶはずのことだが。

6 :NAME IS NULL:2011/07/06(水) 00:53:51.25 ID:???
インデックス張るのは重くなってからのほうがいいんでしょうか?

7 :NAME IS NULL:2011/07/06(水) 01:51:12.39 ID:???
それはただの対症療法で、
設計なんてできない人間が場当たり的な手段として考えること

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

9 :NAME IS NULL:2011/07/06(水) 15:00:28.23 ID:???
最近のDBMSなら、ここにインデックス張ると良いよと教えてくれるものもある
あてになるのかどうかはしらんが

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

11 :NAME IS NULL:2011/07/10(日) 12:00:40.88 ID:???
セキュリティ的な要件でもなければ、俺ならその程度のSQLでビューは作らん

12 :NAME IS NULL:2011/07/10(日) 12:23:38.94 ID:???
そういうビューがあった方がいいという時点で
テーブルをそうすべきでは。
複数のテーブルを結合したSELECT文こそ
ビューにするものだろう

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

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

15 :NAME IS NULL:2011/07/14(木) 00:58:09.73 ID:???
>>14
それはホストアプリの問題だから、使ってるホストアプリのスレで聞いてください

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

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

16 :NAME IS NULL:2011/07/16(土) 05:09:19.36 ID:zVyql7Ng
現在のunixタイムを入れるカラムがあるんですが
それを基準に色々したりしますが
idと同じように上から下へだんだん増えていく数字です
こういうのにもインデックスはいるんでしょうか?

17 :NAME IS NULL:2011/07/16(土) 08:49:20.27 ID:???
つ 2038
たぶん頭で考えてユニークなデータだから大丈夫だろうと思ってても
意外な落とし穴があるといけないからユニークなIDをつけとくクセをつけた方が余計なリスクがないんだということだと思う

18 :NAME IS NULL:2011/07/17(日) 03:49:45.65 ID:???
いらないレコードをSELECT文のパフォーマンスのためにどんどん削除すると、
データベースに断片化が起きますよね?
それを掃除するのがVACUUMであってますか?
だいたいどのくらいDELETEしたらVACUUMすればいいのでしょうか?
VACUUMや大量のDELETE処理で時間がかかっても、
その間SELECT文はスイスイうけてくれますか?

19 :NAME IS NULL:2011/07/17(日) 11:20:44.05 ID:???
ぽすぐれスレいけや。

20 :NAME IS NULL:2011/07/19(火) 21:51:10.43 ID:???
これで独立できる

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

21 :NAME IS NULL:2011/07/23(土) 13:13:55.40 ID:dlvFoJHC
テーブル名の付け方でかなり悩みます・・。

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

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

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

22 :NAME IS NULL:2011/07/23(土) 14:04:05.84 ID:???
>>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つのテーブルでアカウント情報を
> まとめるケースって多いのでしょうか?

23 :NAME IS NULL:2011/07/23(土) 17:55:36.26 ID:???
それちゃんと正規化されてないんじゃね

24 :NAME IS NULL:2011/07/23(土) 22:40:33.66 ID:???
>>22
前スレ見てテーブル名を拝借したのですが、
結局何も解決されて無さそうで、質問しました。
質問者の人は納得したみたいですが、自分はよくわかりません・・。

25 :NAME IS NULL:2011/07/23(土) 22:52:37.20 ID:???
テーブルを三つに分けるなんてあほかというのが第一感だけど
セキュリティを考えるとありかなと思って
そうすると3か所でセキュリティを考えないといけなくなるから
とか考えて思考停止中。

26 :NAME IS NULL:2011/07/23(土) 23:51:24.02 ID:???
管理ユーザーと二つの会員は明らかに別の実体だろ
たまたま似たような属性があるからってまとめればいいってもんじゃないぞ

27 :NAME IS NULL:2011/07/24(日) 00:09:31.34 ID:???
別の実体かどうかなんて、あれだけの情報で判断できるわけないだろ
テーブルを分ける前提での質問だから、その是非は元の質問とは別の話だ

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


28 :NAME IS NULL:2011/07/24(日) 00:15:36.19 ID:???
相変わらず、テーブル名やフィールド名だけの情報から
予断を持って語るやつの多いこと。

29 :NAME IS NULL:2011/07/24(日) 08:46:27.33 ID:???
web系での経験則ではだいたい分けてたな。
uiも腐るほど分けるのが普通だし。
人さらって何ぼだし。

30 :21:2011/07/24(日) 23:01:03.86 ID:???
>>27
それが結構重要だと思うんですよ。
名前が決まらない事には、DB設計できないと思うんです。

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

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

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

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


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

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


32 :NAME IS NULL:2011/07/24(日) 23:53:10.94 ID:???
そうなると、1つのテーブルに色んな会員情報が入る事になり、

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

33 :NAME IS NULL:2011/07/25(月) 00:20:48.34 ID:???
>>30
名前なんて定義に付ける記号なんだから、テーブルの物理名なんか最後においといてもDB設計はできる

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

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


34 :NAME IS NULL:2011/07/25(月) 00:21:20.23 ID:???
>>28
じゃあどんな情報があれば判断できるの?具体的に挙げてみてよ

35 :21:2011/07/25(月) 00:33:04.57 ID:???
>>33
自分が一番悩むのは「後から追加する場合?」を想定するからなんです。
例えば、「プラン」というテーブルを追加したいとします。
一般会員なら、プランは無料・有料を分けるテーブルだと思いますし、
ビジネス会員なら、ベーシックコースとかゴールドコースとかになると思います。
(要はプラン=料金コースですかね)

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

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

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

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

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

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

36 :21:2011/07/25(月) 00:36:17.28 ID:???
すみません。>>35に書いた「冗長化」は違いました・・・。
単に「名前が長くなるとわかりづらくならないか?」と言った
問題定義をしたかったのですが、言葉の選択を間違えました。。、

37 :NAME IS NULL:2011/07/25(月) 01:37:21.54 ID:???
アプリまで考えるってんならカラム名そのままProperty化想定がそもそも・・・
biz_users_plan_name as planNameとか書けないDBもないだろうし、
O/Rでマッピング弄るとかも余裕で可能

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

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

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

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

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

39 :NAME IS NULL:2011/07/25(月) 02:12:50.52 ID:???
>>35
だからまず、一般会員とビジネス会員とはなんだという問題があってだな
これが別物なら、それぞれの操作に対して別の名前付けるのは当然だろうが

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

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

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


40 :NAME IS NULL:2011/07/25(月) 02:25:35.08 ID:???
>>38
>「何を持ってビジネスとするのか?」と言うのもあると思います。
>単純に有料会員の事なのか、お店のオーナーなのか、
>広告出稿などの広告主なのか、BtoBのクライアントの事なのか。

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

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

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

41 :NAME IS NULL:2011/07/25(月) 02:51:11.59 ID:???
テーブル名の前に会員テーブルを分割する意味が判らないんだけど
一般とかビジネスって会員を形容する、従属する属性じゃないのかな
それとも一般会員とビジネス会員はそれぞれまったく異なった名詞なのかな

42 :21:2011/07/25(月) 02:54:34.74 ID:???
>>38-39
>じゃあ将来会員種別が増えたらテーブル増やすのか?普通そういうことはやらんが

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

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

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

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

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

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



43 :21:2011/07/25(月) 03:00:43.73 ID:???
もう少し具体的に書きますと

■会員テーブル(users)
id、loginid、email、password、type

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

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

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

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

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

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

45 :NAME IS NULL:2011/07/25(月) 08:14:17.20 ID:???
>>43
バックアップ取りづらいってのは理解できんな
普通DBのバックアップは、そのDBを一括でバックアップする
そうしないとテーブル間の整合性がとれなくなるから
そのDBにいくつテーブルがあってもあんまり関係ないんだが?

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

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

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

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

46 :NAME IS NULL:2011/07/25(月) 08:52:51.85 ID:???
若輩者だし何行ってるのかよくわかんねーけど

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

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

47 :NAME IS NULL:2011/07/25(月) 13:29:31.16 ID:???
ユーザーテーブルが減ったり増えたりするとして、
例えば全ユーザーのアクセス履歴が欲しい時にどんな設計にするつもりなんだろ
俺ならそんなデータベースに関わりたくない

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

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

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

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

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

49 :21:2011/07/25(月) 15:12:42.26 ID:???
>>47
今は、「ユーザ」は、サイトを利用する会員と、管理ユーザしかいないので、
アクセスログは一般会員のみ取得しています。

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

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

にしていると思います。

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

50 :NAME IS NULL:2011/07/25(月) 15:18:29.41 ID:???
>「テーブルを分ければいいじゃん」
そんなこと言ってるのはお前だけだ

51 :21:2011/07/25(月) 15:42:43.78 ID:???
申し訳ありません。書き間違いでした。
正しくは↓の通りです。

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

52 :NAME IS NULL:2011/07/25(月) 16:27:08.54 ID:???
>>51
ビジネス会員や一般会員がユーザーの属性と考えてる人は分けない
あなたの懸念している点は設計の本質ではないの

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

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

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

53 :NAME IS NULL:2011/07/25(月) 16:39:40.07 ID:???
管理ユーザーと会員ユーザーを
同様にユーザーの属性と考えてるやつの論理が理解できないわけだが、
そこの説明はないのか?

54 :52:2011/07/25(月) 17:42:32.92 ID:???
>>53
誰へのレス?
管理ユーザーと会員ユーザーについてなんて論点にしたものは見当たらないんだが
属性と考えてないのなら勝手に分けりゃいいじゃない

55 :NAME IS NULL:2011/07/25(月) 17:50:42.68 ID:???
全てですって全てでスキルが足りてない
素直に上司に出来ませんって言っておけでFA
ここはDB設計で要件整理代理スレじゃねーしw

56 :21:2011/07/25(月) 18:05:24.93 ID:???
>>55
上司じゃなくて、自分が運営しているサイトの話しです。
「ユーザ」という考え方のテーブル設計・名称を考察しておりますので、
スレ違いでないと思うのですが・・・・

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

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

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

57 :52:2011/07/25(月) 19:12:29.82 ID:???
>>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;

58 :NAME IS NULL:2011/07/25(月) 19:48:20.67 ID:???
要件上、一般会員とビジネス会員を同じ会員として扱うならまとめたらいいし、
ビジネス会員と一般会員は全然扱いが別なら別テーブルにすればいいと思う

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

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

59 :21:2011/07/25(月) 19:58:58.55 ID:???
>>57
実際にテーブルを作成して試しました。
このコードで引っかかるのが
「会員なら誰でも投稿できるブログ」という事って
あまりないのではないでしょうか?

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

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

60 :21:2011/07/25(月) 20:03:29.90 ID:???
>>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つのするのが一般的」と言われます。
だから、私の中で考えが混乱してしまい、要件定義できずにいます。

61 :NAME IS NULL:2011/07/25(月) 20:33:19.64 ID:???
>>60
そこまで分けた方が良いと思うのならそれでいいでしょ
会員向けメルマガの配信ログを残したりログイン履歴を残したりと思ったときに
テーブルが会員の種類だけ増えていくことに抵抗なさそうだし

62 :NAME IS NULL:2011/07/25(月) 20:51:44.49 ID:???
自分がわかるように作れよ・・・
webprogにでも行けよしょーもない

63 :NAME IS NULL:2011/07/25(月) 20:57:24.86 ID:???
会員種別が増えるごとにテーブルが増えていくのか・・・

64 :NAME IS NULL:2011/07/25(月) 21:12:12.12 ID:???
>>60
ビューってしってるか?
あとお前がどれほどのシステム扱ってるかしらんが
結合せずにDBから単一テーブル持ってくる処理なんて実務にほとんどないぞ

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

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

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

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

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

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

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

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

66 :NAME IS NULL:2011/07/25(月) 22:01:11.50 ID:???
君のやるべきことは要件定義であって、DB設計じゃないよ。

67 :NAME IS NULL:2011/07/25(月) 22:04:09.67 ID:???
こんな5年経験者が居るのかと驚愕したが・・・
よくよく考えれば夏休みかw

68 :NAME IS NULL:2011/07/25(月) 22:04:35.18 ID:???
>phpMyAdminと言うツールでDBを管理しているのもまずいのかもしれません。

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

69 :21:2011/07/25(月) 22:05:32.91 ID:???
では、仮に要件定義として、
今までの「一般会員」と「管理ユーザ」に、「ビジネス会員」を追加する。
と決めたとします。

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

70 :21:2011/07/25(月) 22:07:40.83 ID:???
>>67
そう言いますが、今まで私が書いてきたような悩みって全く持ちませんでしたか?
サイトの希望や必要とする要件が増えると、必然的に持つ悩みだと思うのですが・・・

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

71 :NAME IS NULL:2011/07/25(月) 22:07:42.36 ID:???
要件定義でやることも理解できてないと・・・。

72 :NAME IS NULL:2011/07/25(月) 22:08:57.81 ID:???
このレベルで悩んだことはないなぁ。

73 :NAME IS NULL:2011/07/25(月) 22:21:45.64 ID:???
>>21
良い事を教えてやろう。
1つのテーブルにまとめる理由は

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

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

74 :NAME IS NULL:2011/07/25(月) 22:25:27.85 ID:???
>>70
君の力量では今悩むことは意味が無い
答えが出ないし、誰かに出してもらっても理解出来ない
君の力量では今思いついてる物を完成させる事が出来るかどうかという感じ
先はその時また悩めばいい

75 :NAME IS NULL:2011/07/25(月) 22:28:23.77 ID:???
そうそう。とりあえず作ってみれば良いんだよ。
他の人が1つのテーブルでまとめるって書いてるんだから。
素直にその設計でアプリなりサイトなり作ってみて、
それでも気に入らなければ、自分が思うとおりにすれば良いんだよ。

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

76 :NAME IS NULL:2011/07/25(月) 22:28:57.89 ID:???
そうそう。分けたいなら分ければいいじゃん。
何が正解だったのかは、そのうち理解できるよ。たぶん。

77 :NAME IS NULL:2011/07/25(月) 22:49:51.21 ID:???
てか、今のテーブル構成に種類追加するだけで良いんじゃないか?
一般会員と管理ユーザと分けてるんだろ?一般会員に種類つければ。
これが一番近道であり、納得できるだろ。

78 :NAME IS NULL:2011/07/25(月) 23:33:07.61 ID:???
おまえら偉そうに言ってて、話してるうちに前提を忘れてるのな。
ほんとに要件定義とかできるのかよ。

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


79 :NAME IS NULL:2011/07/25(月) 23:46:12.30 ID:???
>>78
Q. テーブルを分けるのはおかしくないですか?一般的なのを知りたいです

A. 分けないのが一般的

Q. まとめるとどうたらこうたらで納得できません!迷ってるんです!

A. 迷わず試せよ、試せば判るさ!バカヤロー! ←今ココ

80 :NAME IS NULL:2011/07/26(火) 09:31:38.33 ID:???
持つ属性が違う以上は別のテーブルを作る必要はあるだろうけど

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

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

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

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

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

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

81 :NAME IS NULL:2011/07/26(火) 11:09:57.12 ID:???
横からすいません。質問です。

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

わかりづらいですよね。

例えば1と2と3の顧客リストがあって(内容は同じですがリストに名前が付いている)それぞれに閲覧権限があるとします。

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

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

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

82 :NAME IS NULL:2011/07/26(火) 14:04:23.40 ID:???
>>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)

83 :NAME IS NULL:2011/07/26(火) 15:18:14.25 ID:???
whereやorderで使うことのある
0か1のフラグ的なものや、0から9までとか短い範囲の数字しかないものにも
インデックスって効きますか?
つけないほうがいいでしょうか?
一応つけてみましたがレコードが少ないので効果はわかりませんでした

84 :NAME IS NULL:2011/07/26(火) 17:03:09.39 ID:???
>>83

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

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



85 :NAME IS NULL:2011/07/26(火) 18:13:47.03 ID:???
結構、ユーザデータってテーブル分けて管理してる奴多いんだな
やっぱ、用途毎に分ける方が管理しやすいからか?

86 :NAME IS NULL:2011/07/26(火) 18:55:12.77 ID:???
どうだろね。
同じ名前のカラムが並ぶようだと変だと思わんのかなあ

87 :NAME IS NULL:2011/07/26(火) 19:47:37.40 ID:???
単に正規化してるだけでは?
どんなデータか分からないけど
好きな食べ物みたいなのは分けるでしょ

88 :NAME IS NULL:2011/07/27(水) 00:39:54.06 ID:???
もう分けて union しとけよ

89 :NAME IS NULL:2011/07/27(水) 00:47:12.71 ID:???
いつまでやるんだよ・・・

90 :NAME IS NULL:2011/07/28(木) 00:47:32.08 ID:???
wordpressとかxoopsのユーザーテーブルでも参考にしたらどうだ?

91 :NAME IS NULL:2011/07/28(木) 07:21:09.49 ID:???
このスレの住人的には第1正規形にもしないんだろうか

92 :NAME IS NULL:2011/07/28(木) 09:33:04.52 ID:???
wordpressは1つのユーザテーブルだな。

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

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

93 :NAME IS NULL:2011/07/30(土) 19:02:53.80 ID:???
質問です。次の二つならどちらが自然な設計に感じますか?

1.
顧客(顧客コード)
顧客受注(顧客コード、受注コード)
受注(受注コード、受注総額)
受注明細(受注コード、受注明細コード、明細金額)

2.
顧客(顧客コード)
受注(顧客コード、受注コード、受注総額)
受注明細(受注コード、受注明細コード、明細金額)

94 :NAME IS NULL:2011/07/30(土) 19:04:15.73 ID:???


95 :NAME IS NULL:2011/07/30(土) 23:49:48.55 ID:???
一つの受注に顧客は一つしかないという暗黙の前提が含まれてるなら2
そうじゃないなら1

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

96 :93:2011/07/31(日) 00:04:43.25 ID:???
>>94>>95
回答ありがとうございました。
やはりカーディナリティが判断基準なんですね。
スッキリしました。

97 :NAME IS NULL:2011/07/31(日) 03:18:12.53 ID:???
多対多を表す対照表を、
ER図に書くのと書かないのとは
どちらが分かり易いと感じますか?
理由混みでご意見頂きたいです

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

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

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

99 :NAME IS NULL:2011/07/31(日) 13:39:17.84 ID:???
どっちでもいいよ。

100 :NAME IS NULL:2011/07/31(日) 13:40:51.94 ID:u5tg0kuA
そうおっしゃらずに。。。

101 :NAME IS NULL:2011/07/31(日) 14:05:06.25 ID:???
>将来上記の時間帯が変更になることも考えられる
データベース設計をころころ変えるなよ
それはもう互換性のない違うアプリケーション

102 :NAME IS NULL:2011/07/31(日) 14:21:17.12 ID:???
設計じゃなくてデータが変わるんだろw

103 :NAME IS NULL:2011/07/31(日) 14:24:04.74 ID:???
>>98
その文字列と数値が1:1対応するならば扱いやすい方にすればいい。
どっちも「時間帯」に対する記号でしかないんだから。
時間帯を開始時刻と終了時刻の組で表現するとかなら設計レベルで
違うと言えるけどね。

104 :NAME IS NULL:2011/07/31(日) 14:26:35.17 ID:???
>>98
マスタ作ってマスタのIDで管理するか、そのまま開始、終了の時間をもつか
どっちにしても文字型で保存するのはあり得ん

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

105 :NAME IS NULL:2011/07/31(日) 18:21:30.17 ID:???
あれ?結局、正規化の話になるんじゃないのか、これ?

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

106 :NAME IS NULL:2011/07/31(日) 18:27:23.99 ID:???
一定の表示以外にも使いまわすなら素のデータでもたしといて
利用する側で加工だろうな。Webでしか使わない、という場合でも
携帯端末向けとかで表記変えることはあるし

107 :NAME IS NULL:2011/07/31(日) 18:57:36.72 ID:???
>>105
>>98はそういう話に発展させる含みを持っているのかもしれないが、
書かれている内容だけじゃあわからんな。データ型の話だけなら>>99でFA。

108 :NAME IS NULL:2011/07/31(日) 20:32:52.54 ID:???
PHPで〜とかでてるしこの前のユーザの人でしょ
ならどっちでもいい

109 :NAME IS NULL:2011/07/31(日) 22:39:45.91 ID:???
文体が違うから別の人でしょ。

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

110 :NAME IS NULL:2011/07/31(日) 23:23:22.81 ID:???
え〜?このスレでまともに正規化が議論されることなんて珍しいぞw

111 :NAME IS NULL:2011/08/01(月) 00:24:17.48 ID:???
”まともな”と定義すれば無いかもしれないけど、
少なくとも正規化に関する質問が多いのは事実だよな

112 :NAME IS NULL:2011/08/01(月) 09:09:01.47 ID:???
>>98をdb関連の話にすると、
配送日時を別テーブルで管理することにしたとする
配送日時の時間割をxデイ以降、新時間割に変更することになったが、xデイ以前の注文は旧時間割に従わなければならない
というケースが予期される場合、どんな設計にしたらよいですか?

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

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

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

113 :NAME IS NULL:2011/08/03(水) 00:40:01.92 ID:???
ところでお前らDB設計にマインドマップとか使ってる?

114 :NAME IS NULL:2011/08/04(木) 22:42:14.36 ID:???
マインドマップってかER図でおすすめのソフト教えてください

115 :NAME IS NULL:2011/08/05(金) 23:56:33.10 ID:???
うん、マインドマップでER図書いてるw

116 :NAME IS NULL:2011/08/06(土) 00:01:17.75 ID:???
>>112
EFFECTIVE_START_DATEとEFFECTIVE_END_DATEが必要だな

117 :NAME IS NULL:2011/08/06(土) 10:39:26.39 ID:???
>>115
やっぱりDDLとかER図から自動で書いてほしいなあ

118 :NAME IS NULL:2011/08/09(火) 00:20:01.44 ID:???
>>117
逆に今ER図書けるのでDDL出力ないのって何?

119 :NAME IS NULL:2011/08/09(火) 01:33:19.96 ID:???
マインドマップを出力してほしいって事だろ

120 :NAME IS NULL:2011/08/09(火) 02:29:45.71 ID:???
>>119
よほどマインドマップが嫌いみたいだな

121 :NAME IS NULL:2011/08/11(木) 18:55:32.11 ID:???
削除フラグのはなし
http://www.slideshare.net/syachi/ss-8808413

122 :NAME IS NULL:2011/08/17(水) 23:04:36.76 ID:???
参照元の複合キーをサロゲートキーにする場合、
参照先で複合キー&外部キーにしていた自然キーは削除するものですか?


サロゲートキー追加前(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はサロゲートキーで、条件は自然キーにできる?)

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

124 :NAME IS NULL:2011/08/19(金) 00:41:02.17 ID:???
ってかサロゲートキーと、ナチュラルキーと、それ以外
って感じでエンティティが3区画に分かれるモデリングツールってある?
俺の場合はナチュラルキーをAK1(col2,col3)とかにするんだけど、
そういうのがダイアグラム上で認識できるやつキボンヌ。

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


125 :NAME IS NULL:2011/08/19(金) 21:39:08.94 ID:???
メモリ設計を易しく教えて下さい

126 :NAME IS NULL:2011/08/20(土) 02:11:11.85 ID:???
たくさん用意しろ

127 :NAME IS NULL:2011/08/21(日) 19:59:31.21 ID:???
質問でう。

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

128 :NAME IS NULL:2011/08/21(日) 20:15:09.35 ID:???
キーがないとして、なにをもって1:Nと判断したの?

129 :NAME IS NULL:2011/08/21(日) 21:47:15.00 ID:???
>>127
それはTableBの行を一意に特定できないってことなんだが、それで良いのか?

130 :NAME IS NULL:2011/08/21(日) 23:13:57.29 ID:???
一対一と言ってる訳でもなし困ってもなさそうだし良いんでしょうね

131 :>>127:2011/08/21(日) 23:28:22.94 ID:???
>>128
1つの住所に対してどんな人が住んでいるか
なので1:Nかな。と

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


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


132 :NAME IS NULL:2011/08/22(月) 11:42:41.29 ID:???
1件削除するのも困りそうだが、、、まあそういうケースが無いならいいんじゃない?

133 :NAME IS NULL:2011/08/22(月) 12:45:42.13 ID:???
TableBをごっそり削除&新たに挿入するケースでは要らないな

134 :NAME IS NULL:2011/08/22(月) 23:31:37.15 ID:???
親のキーと同じNon-Unique Indexぐらいはればいいじゃない。

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


135 :NAME IS NULL:2011/08/22(月) 23:34:58.10 ID:???
ハッシュはユニークが保証されないのにPKにするとか本気かと

136 :NAME IS NULL:2011/08/23(火) 00:38:38.09 ID:???
非ユニークになるようなことが殆どないようにすればいいだけ

137 :NAME IS NULL:2011/08/23(火) 01:00:10.15 ID:???
訂正。
TableBは一意に特定することはない
と言い切っているので
親のPKに連番だのハッシュだのくっつけて複合索引にする必要もないわな。
NonUniqueIndexだけでOK



138 :NAME IS NULL:2011/08/24(水) 10:56:03.76 ID:???
>>136
ほとんどって...それでキー重複のエラーでシステム停止したらどうするんだ?
そんなのあらかじめ予見できるエラーだぞ

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


139 :NAME IS NULL:2011/08/24(水) 13:44:44.81 ID:???
従属するテーブルには一意キーがないと言ってるんだそ。
そもそも元の値をキーにしたらどっちにしてもかぶるだろが。
元の値がなにを想定してるのかわからんが
ハッシュ値のシードとして(何かの列値+ランダム値もしくはsystimestampが必要なんだよ

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


140 :NAME IS NULL:2011/08/24(水) 13:52:41.02 ID:???
横からだが、普通に連番にすればいいだけの話

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

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

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

141 :NAME IS NULL:2011/08/24(水) 16:17:24.27 ID:???
::::::::        ┌─────────────── ┐
::::::::        | またハッシュがやられたようだな…│
:::::   ┌───└───────────v───┬┘
:::::   |フフフ…奴は人工キー四天王の中でも最弱 …│
┌──└────────v─┬────────┘
| 一意制約ごときに負けるとは│
| 主キーの面汚しよ       │
└────v────────┘
  |ミ,  /  `ヽ /!    ,.──、
  |彡/二Oニニ|ノ    /三三三!,       |!
  `,' \、、_,|/-ャ    ト `=j r=レ     /ミ !彡      ●
T 爪| / / ̄|/´__,ャ  |`三三‐/     |`=、|,='|    _(_
/人 ヽ ミ='/|`:::::::/イ__ ト`ー く__,-,  、 _!_ /   ( ゚ω゚ )
/  `ー─'" |_,.イ、 | |/、   Y  /| | | j / ミ`┴'彡\ '    `
  自動採番    完全ハッシュ関数   連番     >>127

142 :NAME IS NULL:2011/08/30(火) 00:18:55.71 ID:???
DB設計の一般的解法やトレンドが見られるような本とかサイトってないでしょうか。
例えば会計システムや生産管理システムはこういう風に作るもの、とか
ソーシャルアプリならこんな感じでテーブル分割する、とか。

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

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

143 :NAME IS NULL:2011/08/30(火) 00:21:25.92 ID:???
聞いたことも見たこともないな。

144 :NAME IS NULL:2011/08/30(火) 00:47:34.33 ID:???
うーん、ないですかね。

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

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

145 :NAME IS NULL:2011/08/30(火) 00:54:43.05 ID:???
KVSとRDBMSは、まったく違うもんだと思ってる。

146 :NAME IS NULL:2011/08/30(火) 15:30:17.69 ID:???
>>144
生産管理のはあるけど
ソーシャルのはないと思うね

147 :NAME IS NULL:2011/08/30(火) 20:51:48.13 ID:???
>>145
もし144へのレスでmixiの件だったら、
当時のレベル1、レベル2ってのはKVSじゃないです。
関係なかったらすみません。

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

148 :NAME IS NULL:2011/08/31(水) 00:03:25.50 ID:EB4rX3D7
>>147
ISBN4-534-03473-3とか

149 :NAME IS NULL:2011/08/31(水) 05:47:24.12 ID:???
設計屋の飯のタネだから、みんな出したがらないんじゃないか

150 :NAME IS NULL:2011/08/31(水) 20:58:09.25 ID:???
>>148
おお、まさにこんな本があったんですね。ありがとうございます、見てみます。

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

151 :NAME IS NULL:2011/09/03(土) 11:29:02.59 ID:???
検索用にタグ機能を作りたいんですけど
どんなテーブル構造にするのが一般的ですか?

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

| 記事ID | タグ1 | タグ2 | タグ3 | ・・・ |
で記事IDをユニークキーにするか

タグの上限は未定です



152 :NAME IS NULL:2011/09/03(土) 11:31:07.06 ID:???
上限未設定なら自ずと答えは見えてるじゃん

153 :93:2011/09/04(日) 01:22:16.60 ID:???
>>142
> 今日あるところで、
> 生産管理システムでの製品と部品の関係

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

154 :NAME IS NULL:2011/09/04(日) 01:23:57.97 ID:???
>>148
速攻でアマゾン発注した
有益な情報ありがとう

155 :NAME IS NULL:2011/09/06(火) 10:23:27.40 ID:???
9999-01-01と9999-12-31のどっちが好きですか?

156 :NAME IS NULL:2011/09/06(火) 13:56:22.84 ID:???
9999-99-99 ははねられるな、、9999-09-09 うーん、9月9日に
バグ出したとこあったよなw

157 :NAME IS NULL:2011/09/06(火) 13:57:11.76 ID:???
たしか99-09-09だったかなー1999年の話だな

158 :NAME IS NULL:2011/09/08(木) 12:18:39.29 ID:???
>>155
でもnullさんの方がもっと好きです。

159 :NAME IS NULL:2011/09/08(木) 18:16:39.19 ID:???
昨今は終了日とかってNULLの流れ?

160 :NAME IS NULL:2011/09/08(木) 20:39:31.57 ID:???
自分は9999-12-31だな。
「終了してるかどうか」を見るのに、
WHERE end_date >= now() OR end_date IS NULL
とか無駄すぎる。

161 :NAME IS NULL:2011/09/09(金) 01:56:51.14 ID:???
普通終了日だと、終了した日(か終了予定日)が入るもんじゃないか?
「終了してるかどうか」なら、
end_date <= now()だと終了、それ以外なら終了していない、って判定で良いんじゃないかね

162 :NAME IS NULL:2011/09/09(金) 06:49:25.17 ID:???
>>161
終了予定日が決まってないデータをどうするか、って話の流れだと思うんだが。

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



163 :NAME IS NULL:2011/09/10(土) 03:07:57.50 ID:???
なっちゃっても別に問題はないけどな。

164 :NAME IS NULL:2011/09/10(土) 07:19:45.64 ID:???
条件が増えるとそれだけパフォーマンスが落ちると思うが。
しかもOR条件やNULLってインデックスが効かないんじゃなかったか。

165 :NAME IS NULL:2011/09/10(土) 11:43:46.63 ID:???
インデクスにNULLを含められるDBMSならインデックス一応効くだろ


166 :NAME IS NULL:2011/09/10(土) 22:07:54.00 ID:???
たとえば9999-12-31が終了してるという意味ですよ、とするなら
終了日が必要な場合、別途項目が必要になる
それなら素直に終了日もってれば良いんじゃないかと

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

167 :NAME IS NULL:2011/09/11(日) 07:13:44.83 ID:???
>>166
> たとえば9999-12-31が終了してるという意味ですよ、とするなら
誰もそんなことはしないと思うが……。

168 :167:2011/09/11(日) 07:21:39.48 ID:???
すまん、途中で送ってしまった。続き

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


169 :NAME IS NULL:2011/09/11(日) 08:09:56.53 ID:???
だから、NULLでいいんじゃね?

170 :187:2011/09/11(日) 09:40:06.34 ID:???
どうしてもnull入れたり、or条件の検索行いたくなければ、元のマスタには開始日だけもち、終了日は取扱い終了マスタのようなので別管理。
検索は、inやexistsを使う感じになるんじゃないの?

171 :NAME IS NULL:2011/09/11(日) 22:07:47.86 ID:???
ああ、NULLにしてるってことなのか。
今のところ終了期限日に9999-12-31で問題がある理由が見つからないので
170みたいな定義にはしないけど、
NULLが主流だという話は理解した。ありがと。

172 :93:2011/09/11(日) 22:11:08.26 ID:???
9999/12/31って直感的じゃないよね
なんとなくセンス悪そう

173 :NAME IS NULL:2011/09/11(日) 22:22:37.09 ID:???
インデックスにNULLを含められるかどうかにかかわらず
NULLにするほうがDB屋としてセンスないけどな

174 :NAME IS NULL:2011/09/11(日) 22:40:21.97 ID:???
どんなセンスだwwシックスセンスか?

175 :NAME IS NULL:2011/09/11(日) 23:28:03.27 ID:???
between使う状況を考えてみろ

176 :NAME IS NULL:2011/09/11(日) 23:36:19.38 ID:???
nullを最小値とみなすか最大値とみなすかはDBMS依存だな

177 :NAME IS NULL:2011/09/11(日) 23:43:18.82 ID:???
外部結合以外でNULLが出てくるのは三値理論の理解を根本的に間違えてる。


178 :NAME IS NULL:2011/09/12(月) 01:58:26.21 ID:???
NULLをまともに取り扱えないプログラマは、項目にNULL入れる設計嫌うよね

179 :NAME IS NULL:2011/09/12(月) 03:15:05.66 ID:???
アホか。そういう問題じゃない

180 :NAME IS NULL:2011/09/12(月) 06:32:53.74 ID:???
uniqueじゃなきゃ困るだろ

181 :NAME IS NULL:2011/09/12(月) 06:43:17.31 ID:???
>>177
非キー属性がキーに完全従属するならば、属性ごとに分解したテーブルを
外部結合するのと等価なんだがな。

182 :NAME IS NULL:2011/09/12(月) 08:29:39.05 ID:???
お前らな〜、null間違った使い方してるとDB神(ゴット)が泣くぞ

183 :NAME IS NULL:2011/09/12(月) 08:58:25.67 ID:???
神託(,Oracle)ですか?

184 :NAME IS NULL:2011/09/12(月) 09:59:22.66 ID:???
CHARで0000/00/00と9999/99/99にせよとお告げがあった

185 :NAME IS NULL:2011/09/12(月) 11:31:33.03 ID:???
文字列の扱いで不用意にnullが混入する下地を作ってしまったオラクルは神を冒涜する邪教だと思う。

186 :NAME IS NULL:2011/09/12(月) 16:41:44.01 ID:???
オラクルって未だにnullと空文字列を区別できないの?

187 :NAME IS NULL:2011/09/13(火) 13:15:54.73 ID:???
そこを変えるとえらいことになるからなw

188 :93:2011/09/14(水) 02:40:00.83 ID:???
>>180
終了日付がuniqueである必要って何よ?

189 :NAME IS NULL:2011/09/21(水) 17:39:51.41 ID:???
皆さんはコードの持ち方ってどうしてますか?

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

190 :NAME IS NULL:2011/09/21(水) 18:41:26.17 ID:???
いくらなんでも質問が端折り過ぎだろ…

191 :187:2011/09/21(水) 21:47:38.69 ID:???
>>189
例えば、性別(男、女)や続柄(兄、弟、父)をコード化して管理する時、一つのテーブルに性別列と続柄列を作るか、別々のテーブルにするかってこと?

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

192 :187:2011/09/21(水) 21:53:02.16 ID:???
>>189
もしくは、コード列と名前列をもつテーブルにすべてのコード体系を詰め込みたいのだろうか?

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

193 :NAME IS NULL:2011/09/21(水) 22:02:36.59 ID:???
key-value モデルだとありうるな

194 :NAME IS NULL:2011/09/22(木) 00:48:40.43 ID:???
例えば、携帯キャリアごとのプランマスタ、というテーブルなら
ドコモプランマスタ、auプランマスタ、というふうに
3キャリアそれぞれに個別のマスタを持ってもいいけど、

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

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

195 :NAME IS NULL:2011/09/22(木) 01:02:00.89 ID:???
>>189
まずコードと区分とは何かをはっきり定義してくれ

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

196 :NAME IS NULL:2011/09/22(木) 01:25:36.08 ID:???
RDB設計のセオリーからは外れるけれども
汎用的な設計にするなら十分ありだよ。


197 :NAME IS NULL:2011/09/22(木) 01:45:15.61 ID:???
実質的に
外部キー制約かけられないだろ
ないな

198 :NAME IS NULL:2011/09/22(木) 01:50:19.23 ID:???
tes

199 :>>189:2011/09/22(木) 02:02:14.02 ID:???
わお書き込めた。
すいません。書き込んでないと思ってました。。

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

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

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

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

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

200 :NAME IS NULL:2011/09/22(木) 02:02:50.78 ID:???
>>197
ERPの設計見たことある?

201 :197:2011/09/22(木) 02:24:54.92 ID:???
見たことないんだが、
そのレスは>>195形式のコード値テーブルで
外部キー制約かけれるってことかい?

202 :NAME IS NULL:2011/09/22(木) 02:27:41.58 ID:???
無理。

203 :NAME IS NULL:2011/09/22(木) 03:27:17.83 ID:???
リポジトリのようなものならアリなんだろうが

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

204 :NAME IS NULL:2011/09/22(木) 11:03:11.72 ID:???
再帰結合用の外部キーの値ってルートはNULLにするのが普通?
今までは自身のレコードのキー入れてたんだけど

205 :NAME IS NULL:2011/09/22(木) 15:35:13.92 ID:???
NULLにしたほうが見た目判りやすいとおも

206 :NAME IS NULL:2011/09/22(木) 15:44:46.15 ID:???
DBMSにもよるけど
Oracleだとルートを探すときにインデックスが効かないな
LEVELカラム作って0とか入れればいいんじゃないかな

207 :NAME IS NULL:2011/09/22(木) 15:55:42.61 ID:???
ツリー構造の親を示すべきカラムに自分自身を指定するのはセンスがおかしい

208 :NAME IS NULL:2011/09/22(木) 16:05:58.57 ID:???
参照制約かつ非NULL思考だと自身になると思う

209 :NAME IS NULL:2011/09/22(木) 16:25:00.28 ID:???
>>208
NULLは不定を表すのだから親が居ない事を表すために使うのは妥当でない、
と気にする人なら「親を持っているか?」というカラムを追加したらいい
誰が親かは分からないままだが、親の有無だけははっきりする
NULLを入れたら死んでしまうようなNULLアレルギー患者には悪いがつける薬は無い

210 :NAME IS NULL:2011/09/22(木) 16:44:55.42 ID:???
>>207
RDBの場合に限れば話は別

211 :204:2011/09/22(木) 17:18:22.25 ID:???
キーをDB自動採番の場合めんどくさいことになったんで疑問に思ったんですが
パフォーマンスとか関係ないケースなんでNULLで良さげですかね
意見ありがとうございました

212 :NAME IS NULL:2011/09/22(木) 19:37:25.36 ID:???
NULLが不定なのではなく、NULLとの比較が不定なのだと思うのだが

213 :NAME IS NULL:2011/09/22(木) 22:18:35.36 ID:???
>>195は、複合PKだからやめたほうがいいと思う。

214 :NAME IS NULL:2011/09/26(月) 15:08:42.44 ID:???
uint利用なら何も考えずNOT NULLにして、
NULLの代わりに-1突っ込んでるがダサいのか?

215 :NAME IS NULL:2011/09/26(月) 16:48:33.73 ID:???
uintって符号なしってことか?
符号なしで定義しといてマイナス突っ込む神経は理解できん
DBMS何かしらんが、そもそもそんな操作は結果保証されないんじゃないか

216 :NAME IS NULL:2011/09/26(月) 17:22:08.27 ID:???
いやすまん、PG側はマイナス使わない前提で-1を無効値扱いってこと

217 :NAME IS NULL:2011/09/26(月) 21:57:00.40 ID:???
営業日の計算ってどうやるの?

218 :NAME IS NULL:2011/09/26(月) 22:02:28.35 ID:???
カレンダーをテーブルで持つと楽。
年次処理で来年度分を作る必要があるけど。

219 :NAME IS NULL:2011/09/26(月) 22:55:38.42 ID:???
>>216
なんつーか、先祖返りだなw
データの定義域には含まれないがそれを格納するデータ型の定義域には含まれる
ある値で無効値を表すという手法は、データ型によって扱いがまちまちになるし、
そもそもデータの定義域=データ型の定義域である場合は使えないから、汎用的に
使えるNULLというものが導入されたのに。

220 :NAME IS NULL:2011/09/26(月) 23:03:42.90 ID:???
電話番号を1カラムに市外局番から加入者番号までいれるべきか
それぞれ別カラムに市外局番・市内局番・加入者番号を作るべきか

221 :NAME IS NULL:2011/09/26(月) 23:52:24.61 ID:???
一カラムに決まってるだろ?
システム的に分けるメリットがない。

222 :NAME IS NULL:2011/09/27(火) 03:07:03.09 ID:???
数値にはNULL入れないな
文字列もオラクル以外ならNOT NULLだ

223 :NAME IS NULL:2011/09/27(火) 04:09:38.96 ID:???
その電話番号で何をするかだな
だが1カラムにするとカッコやハイフンどうするんだって話になるから
素直に全部わけといたほうがいいんじゃね

224 :NAME IS NULL:2011/09/27(火) 08:16:50.02 ID:???
カッコとかハイフン位置ぐらい自動で判別しろよ

225 :NAME IS NULL:2011/09/27(火) 19:33:59.79 ID:???
>>220
全部1カラムでもつと、市内局番が桁数変わったりするときに面倒な気がする
特定市外局番だけ、とか、特定市内局番だけ何かしたいって要件がないなら1カラムで良いんじゃない

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

226 :217:2011/09/28(水) 00:22:09.32 ID:???
ありがとうございます

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

227 :NAME IS NULL:2011/09/28(水) 14:17:57.93 ID:???
>>226
カレンダーの日付を昇順で数えて1個目が最初の営業日、2個目が翌営業日でしょ
その通りクエリを書くだけじゃないかい

228 :NAME IS NULL:2011/09/28(水) 16:04:04.89 ID:???
カレンダーにあらかじめ営業日の連番を打っておけば簡単。

229 :NAME IS NULL:2011/10/15(土) 23:15:52.96 ID:???
前スレでJOINすると遅くなるというのは初心者発想って話題になってたけど未だにその意味が分からん・・


230 :NAME IS NULL:2011/10/15(土) 23:35:27.68 ID:???
そいつは非正規化の意味がわかってないんだろうな。

231 :NAME IS NOT NULL:2011/10/15(土) 23:44:46.97 ID:???
そいつがSQLを書くのが遅くなるという。

232 :NAME IS NULL:2011/10/16(日) 11:48:35.84 ID:???
複雑になれば考える時間が多くなるって程度のことなんじゃ?

233 :NAME IS NULL:2011/10/16(日) 15:35:47.45 ID:???
ああwhereだけで書くと可読性下がるって事か

234 :NAME IS NULL:2011/10/16(日) 20:47:05.95 ID:???
はあ?

235 :NAME IS NULL:2011/10/19(水) 15:34:36.46 ID:???
おれもどこかで「正規化しすぎるとJOINでパフォーマンス落ちるからあまりやらないほうがいい」
なんて文を見てだまされていたけど、ばりばり正規化してJOINしまくったほうが
パフォーマンスも汎用性も拡張性も良かったという。

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

237 :NAME IS NULL:2011/10/19(水) 23:20:32.44 ID:???
今ならインデックス付きのビューが使えたりして、必ずしもその必要はないかもしれん

238 :NAME IS NULL:2011/10/19(水) 23:26:03.88 ID:???
データモデルを非正規化するんじゃなくて
あくまでもクラスタ化されたビューを作るイメージだな。
そこを勘違いしちゃいかんな。

239 :NAME IS NULL:2011/10/20(木) 01:51:29.12 ID:???
クラスタ化前提ならDB設計関係ないやん

240 :NAME IS NULL:2011/10/20(木) 14:59:51.21 ID:???
正規化が面倒だから、適当に作ってパフォーマンスのために崩したと
言い訳するケースのなんと多いことか。

241 :NAME IS NULL:2011/10/29(土) 03:44:00.08 ID:???
頻繁に並び替えを行うので、
ソート用の項目を作りました。
数字が小さいほど優先度を高くする方式では大変なため、
cssのz-indexの要領で大きい数字の優先度を高くしたのですが、
並び替えでdesc処理をしなくてはいけないため、
遅くなるので困っています。
うまい解決方法はないでしょうか?

242 :NAME IS NULL:2011/10/29(土) 06:57:04.99 ID:???
とりあえずその項目にインデックス付けるしかないんじゃね
DBMSによってはインデックスに降順指定できたりするかも
DBMSによってはデータ配置をその項目順に指定できたりするかも(逆順で指定できるかはしらんが)

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

243 :NAME IS NULL:2011/10/29(土) 07:52:26.17 ID:mhxhY6HH
>>241
どのDBMSなのかぐらい書くべし。

244 :NAME IS NULL:2011/10/29(土) 20:01:25.92 ID:???
INSERT後にINSERTしたものをUPDATEするトリガーがあります
INSERT時にはDEFAULT値を入れてるカラムで
このトリガーを使用することで初めてユニークな値になります
このカラムにたいしてUNIQUEキーを指定するのは問題ありますか?
内部でどんな処理が行われてるのかよくわからないのですが

ロック
INSERT
TRIGGER
アンロック

ならよさそうですが

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

だと問題がありそうです

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

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

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

245 :NAME IS NOT NULL:2011/10/29(土) 23:47:31.68 ID:???
どんなトリガーなんだ?

246 :NAME IS NULL:2011/10/30(日) 03:32:29.68 ID:???
INSERT後にUPDATEしてそのユニークカラムの最大値+1を入れてます
自前オートインクリメントみたいなものです

247 :NAME IS NULL:2011/10/30(日) 04:09:28.27 ID:???
>>244
君も何のDBMSかぐらい書きなさいよ

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

248 :244:2011/10/30(日) 04:33:50.81 ID:???
>>244
ありがとうございます
DBは複数を想定しています
PgSQL MySQL SQLiteあたりのフリーのものです

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

249 :NAME IS NULL:2011/10/30(日) 16:38:14.92 ID:???
制約がどのタイミングでチェックされるかは、SET CONSTRAINTS で制御可能なはず
実際にやったことはないし、DBMSによって実装されてるのかどうかもしらん

250 :NAME IS NULL:2011/10/31(月) 12:38:53.50 ID:???
http://wikiwiki.jp/hon/?Andromeda
このデータをうまく正規化しようかと思ってるんですが

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

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

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


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

251 :NAME IS NULL:2011/10/31(月) 12:50:39.79 ID:???
こういう変更の少ないデータはテキスト保存のほうが早い気がする

252 :250:2011/10/31(月) 12:51:20.95 ID:???
いいから早く出して見てください

テーブルを

253 :NAME IS NULL:2011/10/31(月) 13:53:44.59 ID:???
ここはDB初心者スレじゃねえからなあ....

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

254 :250:2011/10/31(月) 14:04:10.25 ID:???
253の場合はどうやって設計しますか

スキルレベル1、2、3、4あります

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

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

255 :250:2011/10/31(月) 14:55:15.65 ID:???
+---------+----------+------+-----+---------+-------+
| 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 | |
+---------+----------+------+-----+---------+-------+


256 :NAME IS NULL:2011/10/31(月) 17:37:19.81 ID:???
正規化じゃなくてテーブル作ってください、レベルじゃないかw

257 :NAME IS NULL:2011/10/31(月) 20:30:02.45 ID:???
宿題スレじゃないから。以後スルーで。

258 :NAME IS NULL:2011/10/31(月) 21:40:29.79 ID:???
>>252
すげーなおい

259 :NAME IS NULL:2011/10/31(月) 21:52:36.99 ID:???
>>252
わろた

260 :NAME IS NULL:2011/11/01(火) 01:54:16.90 ID:???
>>252
異次元からの来訪者だなw

261 :NAME IS NULL:2011/11/01(火) 19:29:16.45 ID:???
下手に答えるよりも>>252を弄るのが面白そうだw

262 :NAME IS NULL:2011/11/06(日) 10:48:33.38 ID:0iaACRLf
はじめて利用させてもらいます。

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

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

例、campanyA_product_table campanyB_product_table .....

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

263 :NAME IS NULL:2011/11/06(日) 12:56:06.88 ID:???
>>262
顧客と商品の関連を後付けするだけでよくない?
select * from 商品 join 顧客が選んだ商品 using (商品ID) where 顧客ID = 'hoge'

264 :NAME IS NULL:2011/11/06(日) 12:59:03.95 ID:???
ASPなら別DBだな。

265 :NAME IS NULL:2011/11/06(日) 18:16:20.59 ID:???
普通会社ごとに別DBにするだろjk


266 :NAME IS NULL:2011/11/06(日) 18:23:13.59 ID:???
本当にそうだろうか?
ユーザー視点だと、物が買えればいんだから、
販売元がどこの会社だから、とか必ずしも興味がないよね。
むしろ、一度に調べられた方が都合がいい。

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

267 :NAME IS NULL:2011/11/06(日) 18:40:51.53 ID:???
要は要件しだい。

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

268 :NAME IS NULL:2011/11/07(月) 00:20:14.41 ID:fTuhKwsU
すみません。
MacBookAirを鞄に入れて移動中にコーラを買ったのですが
ノンカロリーのブラックが出てきました。

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

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

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



269 :NAME IS NULL:2011/11/07(月) 00:23:14.31 ID:fTuhKwsU
ちなみに今、わたしの机の上にあるAirは
動いていません。 



270 :NAME IS NULL:2011/11/07(月) 00:27:23.98 ID:???
チラシの裏にでも書いてろハゲ

271 :NAME IS NULL:2011/11/07(月) 08:17:41.21 ID:???
>>266
それってASP?

272 :NAME IS NULL:2011/11/07(月) 17:47:24.30 ID:???
>>266
この場合の会社ってのは、ASPサービスを利用する利用者の事だと判断したんだが


273 :NAME IS NULL:2011/11/08(火) 01:26:00.02 ID:???
ところでお前らチューニングとかしてる?
今のDBはSQLレベルでチェックするだけで十分だよな?

274 :NAME IS NULL:2011/11/08(火) 10:07:28.66 ID:???
半年に1回くらいインデックスの再構築はする

275 :NAME IS NULL:2011/11/09(水) 02:39:57.99 ID:???
>>273
ある程度規模が大きくなるとチューニングは不可避

276 :NAME IS NULL:2011/11/09(水) 17:12:31.51 ID:???
チューニングって、設計段階での考慮じゃなくて、本番開始してからの見直しってことだよな?
>>274 なんかはチューニングってより保守作業って感じなんだが
実際問題チューニングってどんな作業がある?
設計当初のあまさや見込みが外れてそれに対する修正とか?

277 :NAME IS NULL:2011/11/09(水) 18:17:26.39 ID:???
インフラ側だけでも、パラメータやファイルの配置をいじってみたり、とかいろいろやることあるじゃん。

278 :NAME IS NULL:2011/11/10(木) 16:34:51.33 ID:???
>>276
設計段階で考える必要があるもの→ソーシャル、DWH
正規化してあれば運用後でもなんとかなるもの→バックオフィス

279 :NAME IS NULL:2011/11/13(日) 00:53:53.04 ID:???
設計と言ってもこのレベルの話ではないかもしれませんが、
ここ以外にお話をうかがえそうなスレが見当たらなかったので失礼します。

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

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

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

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

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

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

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

280 :NAME IS NULL:2011/11/13(日) 00:57:57.02 ID:???
加工コード、ってのが微妙な感じだな。それって加工状態を示してるんだろうから、
俺なら加工状態マスタを作ると思う。

281 :NAME IS NULL:2011/11/13(日) 00:58:07.86 ID:???
それもう既にマスタじゃないっしょ

282 :NAME IS NULL:2011/11/13(日) 00:59:54.91 ID:???
>>281>>279宛てね。

283 :279:2011/11/13(日) 01:01:32.47 ID:???
すみません。加工以外の部分は、

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

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

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

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


284 :NAME IS NULL:2011/11/13(日) 01:04:50.59 ID:???
>>279で言ってる「加工マスタ」は、
「部品ごとにどんな加工状態があるか」を示すテーブルじゃないの?

285 :NAME IS NULL:2011/11/13(日) 01:05:45.79 ID:b+TGUhtw
>>280
加工状態マスタとはどんなものでしょう?
部品ごとに加工内容、加工時間などが変わってくるので、加工マスタに集約しようとしています。
やりたい事は
・ 「今の部品在庫で期日までにいくつ作れるか」のシミュレート
・ 在庫の管理
・ 部品の手配の支援
等ですので、


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

286 :NAME IS NULL:2011/11/13(日) 01:07:37.12 ID:???
280、281、284 の説明でわからないなら、あきらめた方がいいよ。

287 :279:2011/11/13(日) 01:08:33.77 ID:b+TGUhtw
285=279です。失礼しました。

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


288 :NAME IS NULL:2011/11/13(日) 01:14:23.61 ID:???
ようは、↓みたいのは止めとけって話だろ

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

289 :NAME IS NULL:2011/11/13(日) 01:14:50.56 ID:???
>>285
まず感覚的に
工程見直しが主要な関心事として業務フローにあるなら
マスターってよりトランザクションに感じる

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

290 :279:2011/11/13(日) 01:19:10.46 ID:???
つまり、リナンバーするような行為はヤメトケという事ですね。

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

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

291 :NAME IS NULL:2011/11/13(日) 03:17:04.32 ID:???
全体的に要件がまったく解らんので何とも言えんが

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

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

292 :279:2011/11/13(日) 03:56:16.73 ID:???
工場の生産管理・資材管理システムです。
製品部品展開での部品在庫数の管理システムが存在しています。
それに加工に関する部分が抜けているのでそれを追加しようとしています。
部品自体は設計図上の部品コードを元に管理しています。

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

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

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

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

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

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

294 :パッケージ屋:2011/11/13(日) 14:42:00.65 ID:???
一般的なパッケージだと・・・
加工の特徴はBOMを使わない,一連の加工の途中に中間在庫を持たない
のが違い.

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

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

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

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

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

295 :NAME IS NULL:2011/11/13(日) 15:00:46.94 ID:???
は? DB設計スレでパッケージ買えって・・・

296 :NAME IS NULL:2011/11/13(日) 15:53:04.30 ID:???
一昔前じゃ
パッケージ屋はパッケージだけは買うな
構築させられた奴はパッケージ買え
だったのにな、今の若いもんは能力に見合わない自信を持っておる

297 :NAME IS NULL:2011/11/13(日) 20:52:05.17 ID:???
>>296
ひと昔前の良さが全く伝わらないぞw

298 :279:2011/11/14(月) 02:08:51.32 ID:???
既存システムの移植・改修は決定事項なのでパッケに頼る事は出来ないです。orz
元々組み込み屋出身でDB屋ではないのでこんな簡単な事でも分からず恥ずかしい限りです。

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

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

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

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

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

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

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

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

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

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

299 :NAME IS NULL:2011/11/15(火) 01:23:10.86 ID:???
>>298
「加工」は加工だけで組立工程は含まないの?
仕掛とか工程間の在庫とかは必要だし部品表とかけあわせた時に
「工程」のマスタがないとハマる。

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

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

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

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

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

300 :NAME IS NULL:2011/11/15(火) 19:58:50.28 ID:???
まあ、DB設計以前に要件定義の問題だな

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

301 :NAME IS NULL:2011/11/17(木) 22:08:07.85 ID:???
そこまで行けばデザインツールで自動生成だろ

302 :NAME IS NULL:2011/11/19(土) 14:34:35.73 ID:???
>>300
でもって大抵のビジネスアプリは画面からDB読んで書くだけ

303 :NAME IS NULL:2011/11/20(日) 09:57:41.09 ID:???
そもそもある程度以上の規模で、
完璧な要件定義なんてできたことあるか?
要件定義が完璧だと信じてガチガチのテーブル設計にして、仕様変更にうまく対応できないことの方が多くないか?


304 :NAME IS NULL:2011/11/20(日) 15:11:16.69 ID:???
>>303
仮にその時は完璧でも、そのうち要件が変化していくのが世の常。
だから、「ガチガチのテーブル設計」なんてするのは素人のやることだろ。

305 :NAME IS NULL:2011/11/20(日) 15:13:18.97 ID:???
要件定義が完璧かはともかく、仕様変更は要件の変更だろ
仕様変更があればテーブルも再設計・変更するのは必然

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

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

307 :NAME IS NULL:2011/11/20(日) 16:12:38.14 ID:???
現状でベストと思われる設計をすれば良いんじゃないのか?

308 :NAME IS NULL:2011/11/20(日) 16:31:23.98 ID:NgM7YNQ/
何がベストかが問題だ

309 :304:2011/11/20(日) 17:13:42.74 ID:???
>>305
> 仕様変更があればテーブルも再設計・変更するのは必然

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

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

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

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

310 :NAME IS NULL:2011/11/20(日) 17:17:43.11 ID:???
スレ違い。

311 :NAME IS NULL:2011/11/20(日) 19:47:37.15 ID:???
>>309
ん、違いがわからんか。
つまり、将来の変更への備えが必要だと気づいたなら、要件の方にfeedbackしておけということだ。

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

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

313 :NAME IS NULL:2011/11/20(日) 21:28:48.97 ID:???
ソーシャルゲームとかでアイテムボックスのようなものを作りたいのだけど、

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

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

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

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

314 :NAME IS NULL:2011/11/20(日) 21:33:33.73 ID:???
好きにしろよ。正規化って意味では前者だけど、いろんな理由で後者が選ばれるケースもある。

315 :NAME IS NULL:2011/11/20(日) 22:09:25.88 ID:???
>>313
たとえばアイテムボックスに、アイテムスロット1,アイテムスロット2...とある場合だと
アイテムの格納されてる位置も必要なわけで、その場合なら後者も無くはない

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

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

316 :NAME IS NULL:2011/11/22(火) 10:17:53.70 ID:???
ここは論理設計だけか?物理設計とかも語ってよいのね

317 :NAME IS NULL:2011/11/25(金) 11:53:51.38 ID:???
twitterのつぶやき検索ってどーやってるんだろ
あれだけ大規模なツイートを検索とかFacebookよりすげぇ

318 :NAME IS NULL:2011/11/25(金) 13:06:46.81 ID:???
>>317
selectだろ

319 :名無しさん:2011/11/25(金) 19:51:43.71 ID:???
まあちゃんもヒットしなくても誰にも怒られないシステムだからな。


320 :NAME IS NULL:2011/11/26(土) 20:51:07.63 ID:???
DB経験3ヶ月の下っ端です。
正規化を勉強するにあたり、サーバ情報の管理を目的としたデータベースで以下の項目があった時、まずどうすれば良いでしょうか?
ぜひヒント貰えれば嬉しいです。

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

項目

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


321 :NAME IS NULL:2011/11/26(土) 21:18:25.69 ID:???
まずは本の一冊でも買って読むのがいいと思うぞ。

322 :NAME IS NULL:2011/11/26(土) 23:03:21.38 ID:???
>>320
>利用者500人/365day/24h
>管理ホスト台数1500台

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

323 :NAME IS NULL:2011/11/27(日) 00:50:28.36 ID:???
>>320
まずどうすれば良い・・・?
まずは考えるときに「管理」を自分に対して禁句にすることだ.

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

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

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

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

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

健闘を祈る.

324 :NAME IS NULL:2011/11/27(日) 01:13:14.66 ID:???
>>320
まずすべきことは現状分析
なにか改善したいのであれば要求分析
バラバラなものをどう管理すべきかということを考えざるを得なくなるはず。
とにかくヒアリングして分析しる

325 :NAME IS NULL:2011/11/27(日) 09:05:12.66 ID:???
>>323
プロフェッショナルなアドバイスありがとうございました。
そんな風に考えたことなかったのでとても勉強になりました!

326 :NAME IS NULL:2011/11/27(日) 09:54:46.54 ID:???
>>324

327 :NAME IS NULL:2011/11/27(日) 13:49:13.74 ID:???
>>323
管理、Managerここらを使わないようにするだけでだいぶ違うよな

328 :NAME IS NULL:2011/11/28(月) 15:00:19.70 ID:???
ああ、正規化の勉強したいのか。
エンティティ/リレーションシップについてちゃんとしたメソドロジーの書いてある本を読むべき。まずは基礎理論知らないと話しにならん。
難しいけど頑張って読破しろ。

329 :NAME IS NULL:2011/11/28(月) 15:02:47.01 ID:???
集合演算とかの概念も必要になってくるからそれもおさえとけ。
でないと正規化できない、というか方法論だけでもできるけど知っといたほうがいいだろう

330 :NAME IS NULL:2011/11/28(月) 19:32:15.04 ID:???
>>328->>329
理論といっても当たり前のことを言ってるだけだね.
いや,当たり前と思えるようになることが修行なのか.

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

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

331 :NAME IS NULL:2011/11/28(月) 21:23:11.66 ID:???
>>328
ちゃんと基礎から勉強しろってのは賛成だが、正規化の前提はリレーショナル
モデルだからERはちょっと違うと思うぞ。

332 :NAME IS NULL:2011/11/30(水) 15:57:00.45 ID:???
いまどきはk-vだよな

333 :NAME IS NULL:2011/11/30(水) 18:32:58.86 ID:???
スレ違い

334 :NAME IS NULL:2011/11/30(水) 19:56:58.07 ID:???
最先端はカラム指向らしい

335 :NAME IS NULL:2011/11/30(水) 23:49:21.39 ID:???
>>334
kwsk

336 :NAME IS NULL:2011/12/01(木) 05:29:36.12 ID:???
ttp://lmgtfy.com/?q=%E3%82%AB%E3%83%A9%E3%83%A0%E6%8C%87%E5%90%91


337 :NAME IS NULL:2011/12/02(金) 01:52:23.37 ID:???
>>335
レコード(行)じゃなくてカラム(縦)ごとにデータをまとめておくこと.

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

338 :NAME IS NULL:2011/12/02(金) 04:28:45.71 ID:???
スキーマ型DBの欠点を克服できてるけど
何も考えずRDBの代わりに使ったらどえりゃーことになるぞ
気を付けな

339 :NAME IS NULL:2011/12/03(土) 18:33:27.23 ID:???
最先端って、どこがw
Sybase IQなんて相当古いじゃねーか。
特許が切れてオープンソース実装が出てきて流行ってるとか、そういうこと?

340 :NAME IS NULL:2011/12/03(土) 21:38:49.81 ID:???
これからはNoSQLが来るな

341 :NAME IS NULL:2011/12/03(土) 21:58:47.06 ID:???
>>340
用途による。課金システムがNoSQLだったらイヤだ。

342 :NAME IS NULL:2011/12/04(日) 00:32:15.40 ID:???
これからは放射能汚染がくるな

343 :NAME IS NULL:2011/12/04(日) 07:46:54.81 ID:???
とっくの昔にどっぷりヤラれてるような気がするんですけど

344 :NAME IS NULL:2011/12/05(月) 00:41:00.78 ID:???
>>339
最新なのは市場のほう.ビッグデータ云々というキーワードだ.
Map & ReduceやるぞのOracle,HPは列指向DBで・・・

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

345 :NAME IS NULL:2011/12/05(月) 02:06:00.66 ID:???
欧州危機が最先端だな

346 :NAME IS NULL:2011/12/05(月) 04:16:44.47 ID:???
60年前ならとっくに戦争始まってるレベル

347 :NAME IS NULL:2011/12/05(月) 21:05:39.39 ID:0x+CibA0
皆さんに質問です。

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

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

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


348 :NAME IS NULL:2011/12/05(月) 21:19:26.57 ID:???
パフォーマンスを優先するか仕様変更可能性を優先するかの違い
PKは文字列より数値のが速い
PKが社員IDのようなもので数値→文字列に変更可能性が考えられるなら数値のみでも文字列使ったりする

349 :NAME IS NULL:2011/12/05(月) 21:37:49.24 ID:???
商品コードとか普通に文字列使うが

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

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

350 :NAME IS NULL:2011/12/05(月) 21:39:03.68 ID:???
てか、わかってないことをなんで強弁するのw
まぁ、キーはサイズが小さい方がいいから、一般的に文字列より
数値の方が小さいので好まれるとか、可変長のキーは物理
配置が乱れることから好まれないとかあるけど、わかってない人は
「キーは絶対に数値型!」とか言いながらOracleでNUMBERを
使ったりするw

351 :NAME IS NULL:2011/12/05(月) 21:52:37.03 ID:???
オラクルは全てにおいてキャラが基本だよな?


352 :NAME IS NULL:2011/12/06(火) 01:24:31.02 ID:???
>>347
数字にこだわる理由はない.どっちかというとやめた方がいい.
もしそのこだわりがISAM以来の伝統だったりオブジェクト指向原理主義だったり
するのならなおさらだ.

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

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

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

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

353 :NAME IS NULL:2011/12/06(火) 02:23:30.84 ID:???
>>352
体験談としては聞けるが、理論的な根拠まったくなしだな
単にお前がバカの設計したプロジェクトに入っただけだ。ご愁傷様

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

354 :NAME IS NULL:2011/12/06(火) 07:25:11.40 ID:???
データ移行が多発するプロジェクトだと、意味のない数字キーだと、変換大変じゃない?

355 :187:2011/12/06(火) 08:29:17.43 ID:???
>>352
主キーをそのまま画面に出したのが運の尽きってとこだな。
別途、ユーザーから見える表示用のキーがあれば、小さな影響で改修とかできただろうにね。

356 :352:2011/12/06(火) 10:17:19.72 ID:???
>>353
一意になってればイイってだけなら数字でいいし若干数字のほうがいい(かも)程度

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

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

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

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

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

357 :NAME IS NULL:2011/12/06(火) 13:20:01.30 ID:???
主キーに自然キーを採用して良かった助かったという経験はないな…

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

358 :NAME IS NULL:2011/12/06(火) 18:50:19.12 ID:???
>>357
どっちにしろ、B-Treeのインデックスは効かなくなる。
ファンクションインデックスが使えれば、対処できるけど。

359 :NAME IS NULL:2011/12/06(火) 21:12:35.27 ID:???
質問です。

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


360 :NAME IS NULL:2011/12/06(火) 21:21:21.66 ID:???
駄目です。

361 :NAME IS NULL:2011/12/06(火) 21:50:44.59 ID:mrGnDsEe
俺の理解では、帳票=出力だから、
DB設計とか画面設計のことをひっくるめて帳票設計と呼んでいるんだけど、違うのかな?
つまり、外部設計=帳票設計だと俺は思う。


362 :NAME IS NULL:2011/12/06(火) 22:02:40.02 ID:???
> DB設計とか画面設計のことをひっくるめて帳票設計と呼んでいるんだけど、違うのかな?

違います。

363 :NAME IS NULL:2011/12/06(火) 22:03:47.67 ID:???
外部設計の定義を間違えている気がします

364 :NAME IS NULL:2011/12/06(火) 23:48:13.48 ID:???
帳票=紙のことだろ。
コンビニのシステムを例にすると、レシートのことだと思う。
つまり、帳票設計=レシートの表示の設計じゃないだろうか。
レシートの設計を、画面設計と呼ぶとおかしいので、しょうがないので帳票設計ってよんでるのかなって思った。


365 :NAME IS NULL:2011/12/07(水) 02:46:51.57 ID:???
>>364
ファイルに吐き出すCSVなりExcelなりのファイルを帳票って言うことがある.
いちばん広い意味だと書き込みのない参照画面をすべて帳票って言うこともある.

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

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

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

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

367 :NAME IS NULL:2011/12/07(水) 22:39:07.98 ID:???
主キーが数値にしろ文字にしろ
レコードの追加時に組み合わせの最大数を超えたときの処理はどうしてますか?
たとえば32bit数値なら32bitの最大値とか
n文字なら利用可能文字のn乗とかを超えたときの話です

368 :NAME IS NULL:2011/12/07(水) 23:28:06.48 ID:???
>>367
事前にそこまでのデータ量を扱えることを要求するシステムってそうないような気がするけど
どうなんでしょう
データ量の見積もりをあきらかにミスったとかとなれば別ですが

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

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

369 :NAME IS NULL:2011/12/08(木) 00:06:04.05 ID:???
Key Value Storeを使い倒してるやついるか?

370 :NAME IS NULL:2011/12/08(木) 00:56:07.12 ID:???
いつもgoogleにはお世話になっている.

371 :NAME IS NULL:2011/12/08(木) 01:01:14.77 ID:???
memcachedとcassandraにはお世話になっている

372 :NAME IS NULL:2011/12/10(土) 23:54:11.05 ID:???
DeNAの球団略称がDBになるそうだ.
ますます住みにくい世の中になるな.

373 :NAME IS NULL:2011/12/11(日) 02:43:05.63 ID:???
mjd?


374 :NAME IS NULL:2011/12/11(日) 09:58:59.14 ID:???
>>372
そもそもそんな略称めったに目にしないから、関係ないよ。

375 :NAME IS NULL:2011/12/12(月) 03:03:30.28 ID:???
DB設計の手順教えて下さい

376 :NAME IS NULL:2011/12/12(月) 03:13:01.72 ID:???
とりあえず必要なデータを紙に書く
関連のあるデータをくっつけていく
おや?勝手に正規化になってるぞ
完成

377 :NAME IS NULL:2011/12/12(月) 08:14:08.59 ID:???
>>376
参考になります

378 :NAME IS NULL:2011/12/12(月) 09:27:49.02 ID:???
>>375
 ビジネス要求をまずはハッキリさせる.
 システム全体のスコープを決める.
 ハードウェアミドルウェア等の既存制約,予算制約を確認する.

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

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

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

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

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

379 :NAME IS NULL:2011/12/12(月) 22:26:44.20 ID:???
>>378
具体的な指摘ありがとうございます。
とてもわかりやすかったです。

115 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)