DB設計を語るスレ 4

1 ：11/07/05 〜 最終レス ：11/12/08

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

2 ：

PRIMARY KEYの指定されているテーブルに、
他のNOT NULL UNIQUE制約を持つカラムを入れるべきではありませんか？
例えばこんなテーブルです。
アルバムテーブル
画像id NOT NULL PRIMARY KEY,
画像名 NOT NULL UNIQUE,
サムネイル名 NOT NULL UNIQUE
これの構成を変えるとどんな感じにすればいいでしょうか？
画像名が決まればサムネイル名も決まるというルールを作ることも可能です。

3 ：

>>2
その項目がNULLが入って困るならNOT NULL制約をつければシステムが保証してくれる
その項目がユニークであるなら、UNIQUE制約をつければシステムが保証してくれる
すくなくとも本番ＤＢなら付けない理由がないんだが？
>これの構成を変えるとどんな感じにすればいいでしょうか？
なぜ構成を変えるのか、構成を変えてどうしたいのか全く分からんのに
どんな感じも何もないわ。好きにしろとしか

4 ：

>>3
テーブルにプライマリキーを2つ以上定義してはなりませんが、
NOT NULLでUNIQUEなカラムはプライマリーキーと同義です。
なので、プライマリキーを指定してるテーブルには、
NOT NULLでUNIQUEなカラムは含めるのは設計的に正しくないのかな？と思って質問しました。
それで、もし正しくない場合構成をどうすればいいか教えて欲しかったのです。
回答内容から付けても特に設計に問題はないと判断させていただきます。

5 ：

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

6 ：

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

7 ：

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

8 ：

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

9 ：

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

10 ：

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

11 ：

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

12 ：

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

13 ：

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

14 ：

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

15 ：

>>14
それはホストアプリの問題だから、使ってるホストアプリのスレで聞いてください
使い方の問題もあるがな
入力した人がワイルドカードとして％入力してるならエスケープしちゃだめだろ
逆にパーセント文字を表しているならエスケープが必要になるだろ
判断がつかないならエスケープしとけ

16 ：

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

17 ：

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

18 ：

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

19 ：

ぽすぐれスレいけや。

20 ：

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

21 ：

テーブル名の付け方でかなり悩みます・・。
会員テーブルがあって、会員の種類に、一般・ビジネス・管理者など
それぞれ用途が異なります。
最初は1つのusersテーブルに区分を付けてまとめようとしたのですが、
各会員のカラム構成が違うので、独立したテーブルにしようと思いました。
その場合、
users → 一般会員、admin_users→ 管理者、biz_users→ビジネス会員
と言うのを考えたのですが、変じゃないか？と悩んでおり、
どうするのが普通（一般的）か気になり、質問しました。

22 ：

>>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 ：

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

24 ：

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

25 ：

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

26 ：

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

27 ：

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

28 ：

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

29 ：

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

30 ：

>>27
それが結構重要だと思うんですよ。
名前が決まらない事には、DB設計できないと思うんです。
>>21の例で言うと、users以外にadminとbizがありますが、
「そもそもビジネス会員って何なの？その会員は他の会員とどう違うの？」
って他人がテーブルを見た時に理解できないと困ると思うんです。
で、>>25-29の間で
「同じ”ユーザ”なんだから1つのテーブルだろ」とか、
「構造自体が違うんだから分けるべきだろ」
とか意見が多々ある時点で、設計段階で"迷い”が生じてると思うんです。
その迷いがあると、後からテーブルを追加しようにも困ると思うんですよ。
各会員でそれぞれJOINするテーブルが増えてきた時とか。
もちろん、用途に寄って異なるというのは重々承知してるのですが、
会員の種類や分け方、正規化の考え方って、全く情報無いんですよね・・・
ようやく探したのが前スレのログぐらいで・・・
だからもう少し汎用性のある考え方がしたくて、質問しました。

31 ：

自分としては、1つのテーブルでまとめるのに疑問を感じるんです。
「区分」や「権限」のカラムを追加して分ければいいと思いますが、
そうなると、1つのテーブルに色んな会員情報が入る事になり、
規模が大きくなると対応しにくいんじゃないか？って思うからです。
かといってその前を単純に「（種類名）_users」にするのも良いものか？
と思い、悩みに悩みが重なっている状態で、設計が進みません・・・

32 ：

そうなると、1つのテーブルに色んな会員情報が入る事になり、
基本情報と個別情報を分ける

33 ：

>>30
名前なんて定義に付ける記号なんだから、テーブルの物理名なんか最後においといてもＤＢ設計はできる
>「そもそもビジネス会員って何なの？その会員は他の会員とどう違うの？」
まずお前がちゃんとこれを分析（定義）できてるのか？
もしできてるなら、それをここで発表すればこのスレの人がテーブル分けるべきかどうか議論してくれるだろう
>「同じ”ユーザ”なんだから1つのテーブルだろ」とか、
>「構造自体が違うんだから分けるべきだろ」
>とか意見が多々ある時点で、設計段階で"迷い”が生じてると思うんです。
迷ってなんかないぞ。それぞれが思う勝手な要件で言ってるだけで
その要件が違うから答えが違うだけだ

34 ：

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

35 ：

>>33
自分が一番悩むのは「後から追加する場合？」を想定するからなんです。
例えば、「プラン」というテーブルを追加したいとします。
一般会員なら、プランは無料・有料を分けるテーブルだと思いますし、
ビジネス会員なら、ベーシックコースとかゴールドコースとかになると思います。
（要はプラン＝料金コースですかね）
その時、>>21の考え方で行くと、同じ「プラン」でも
用途やフィールド構造が全く違うので、結合するテーブル名は分けるわけですが、
users_plan　→　一般会員のプラン
biz_users_plan　→　ビジネス会員のプラン
となって、テーブル名が冗長化していかないか？と思うからです。
テーブル名がこうなると、実行するアプリ側のファイル名や変数名も
biz_users_plan_register.php（ビジネス会員プランに登録）とか
$biz_users_plan_name（ビジネス会員プラン名）とか
名前がどんどん長くなっていく恐れがあります。
そうすると、スパゲティーコードになる元です。
そういうDB設計+アプリ設計まで想定すると、
最初のDB設計を上手くやらないと、後々困る事になるので、悩むわけです。
要件というのは、DBを使用するサイトやアプリの規模が大きくなる事で
変わってくると思うし、大きくなって対応できない設計では困ると思うんです。

36 ：

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

37 ：

アプリまで考えるってんならカラム名そのままProperty化想定がそもそも・・・
biz_users_plan_name as planNameとか書けないDBもないだろうし、
O/Rでマッピング弄るとかも余裕で可能
アプリまで考えるにはアプリを知らないと出来ないよ
スパゲッティも意味合い違うし

38 ：

自分はアプリ開発も5年ほどあるので、そこそこ知ってるつもりです。
あと、自分の場合、カラム名が長くなったり、テーブル構造が増える事で
スパゲティーコード化（他人には分かりづらいごちゃ付いたコード）
する傾向にあるので、そのように書きました。
>>21の例ではビジネス会員としていますが、
「何を持ってビジネスとするのか？」と言うのもあると思います。
単純に有料会員の事なのか、お店のオーナーなのか、
広告出稿などの広告主なのか、BtoBのクライアントの事なのか。
これだけ考えても「ビジネス会員」という名称にはかなり幅広くあります。
ですので、単純にbiz_usersとしても汎用性が利かずに
何に対する会員（ユーザ）かわからなくなってくると思うんです。
ここまで説明すると、私がテーブル名の付け方・考え方について
悩む理由も分かっていただけると思うのですが・・・不足があればご指摘下さい

39 ：

>>35
だからまず、一般会員とビジネス会員とはなんだという問題があってだな
これが別物なら、それぞれの操作に対して別の名前付けるのは当然だろうが
名前が長くて困ることがあるのか？お前が使うホストアプリはＤＢの項目名がそのまま変数名じゃないとだめなのか？
名前が長いから問題になるなんてことはない
名前が長いってなら、順に連番で振れよ
途中で要件が変わったのなら当然ＤＢ設計も変更するか検討する必要があるが
規模が大きくなって対応できないってのは、事前の要件定義が甘いだけだ

40 ：

>>38
>「何を持ってビジネスとするのか？」と言うのもあると思います。
>単純に有料会員の事なのか、お店のオーナーなのか、
>広告出稿などの広告主なのか、BtoBのクライアントの事なのか。
つまり、ＤＢに格納すべきデータに対する要件定義もできてないのに
テーブル作って名前も決めろと？
今の段階での要件が、たとえば
・とりあえず何らかの会員管理を行う
・会員にはいくつかの種別がある（種別の詳細は不明）
ぐらいしか決まってないのに、その段階でテーブル分けるとかなんで決めてるかね
じゃあ将来会員種別が増えたらテーブル増やすのか？普通そういうことはやらんが
テーブル名に悩む前に、テーブル作るかどうか、それに何を格納するか考えた方がいいんじゃね

41 ：

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

42 ：

>>38-39
>じゃあ将来会員種別が増えたらテーブル増やすのか？普通そういうことはやらんが
自分はまさにそれをやろうとして、「本当にこれで良いのか？」
で悩んでおり、設計できない状態なんです。
だから名前すら決められないんです・・。
それに、会員種別毎にテーブルを”分けない”
という理由に納得行かないんです。
理由は「バックアップしづらい」と「セキュリティ的に不安」だからです。
1つのユーザテーブルにまとめて、カラムで種別を分けるのが
一般的だと思いますが、どう考えても上記2つが引っかかるのです。
それに、会員テーブルなら共通項は、ログインID・パスワード・Emailぐらいです。
それなら種別毎に指定するテーブル（プロフィールとか会社情報とか）
と一緒にして、「○○会員テーブル」というのを作った方が管理しやすいのではないか？
っと思い、そうしようとしたら>>35みたいな悩みが出てくるわけです。
>>39さんが書いてるように、規模が大きくなって対応できないのは
要件定義が悪いと思うので、開発前に定義を詰めたいのですが、
”会員”という定義一つとってもここまで悩むわけです。
（ちなみに、悩むのはあくまで”複数会員”を想定した場合です）
自分はマニュアル思考なため、出来るだけ他者と同じような設計をしたいので、
こうやって自分が納得できる答えを見つけたいと思い、
皆さんのアドバイスをいただいている次第です。

43 ：

もう少し具体的に書きますと
■会員テーブル（users）
id、loginid、email、password、type
として、typeの種類によって各会員を抽出すると思います。
MySQLでビジネス会員を取得するなら、
SELECT * FROM users WHERE type='biz'
みたいにするのが一般的だと思います。
しかし、繰り返しますがこれをすると、
・テーブルのバックアップが取りづらい
・セキュリティ的に不安（全会員の情報が漏れる可能性がある）
・会員数が増えた場合の使い勝手
こう言うのが気になるため、「テーブルを分けよう」と思った次第です。
そして、分けるとなれば、名前について引っかかり、
アドバイスを求めて、あーでもない・こーでもないと悩んでおります・・。

44 ：

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

45 ：

>>43
バックアップ取りづらいってのは理解できんな
普通ＤＢのバックアップは、そのＤＢを一括でバックアップする
そうしないとテーブル間の整合性がとれなくなるから
そのＤＢにいくつテーブルがあってもあんまり関係ないんだが？
仮にテーブル単位でバックアップするとしても
その場合テーブル数が多い方がバックアップする手間が増えるのは明白だとおもうが？
あと会員数は百でも千でも万でも、使い方は同じだが？
理論上一つのテーブルを、物理的にいくつかに分割して格納することも無いではないが
お前のレベルでは無縁の世界の話だ
結局お前のテーブル分割要因に賛同する点がいくらかでもあるとすれば
セキュリティ的要因でテーブル分割するって言うだけだが
それすらまずお前の要件定義のレベルでは話になってない
他者と同じ設計にしたいって言ってるのに、なぜ一般的と自分で言ってる方法でやらない？
自分で一般的な方法にケチつけといて同じような方法で設計したいって何言ってんだか

46 ：

若輩者だし何行ってるのかよくわかんねーけど
同じ項目があるならそれは同じテーブルに
区分毎に別項目があるならそれは別テーブルにすればいいんじゃないの？
セキュリティ云々はDB構成よりそれ以外のUIやら管理体制に問題あるんじゃ？

47 ：

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

48 ：

>>44
全てです。自サイトの今後の発展を考え、リニューアルを検討しているのですが、
どういう仕様にすれば後々安心で、他人が見てもわかるか？
と言うのを重視しており、おっしゃるとおり要件定義が甘いので
皆さまのご指導をいただいております。
>>45
DB一括でバックアップするもんですか？
私はこれまで必要なテーブルのみバックアップしていました。
あと会員数は万単位で、サイトは1000万PV/月なんで、
現状のレベルでは無縁な範囲だと思います。
ですが、今後の発展を考えた時、
どう考えても私一人では運営できませんし、
仕様が自分本位では人に依頼してもトラブルの元です。
ですので、他者と同じ設計にしたいと思いました。
一般的な方法にケチをつけているわけではなく、
私自身がその設計について納得出来ないと設計できません。
ですので、論理的に
「これこれこういう理由があって、こういう設計にするし、
あんたが考えるリスクを避ける事が出来る」
という説明をいただけると私も納得できると思うのですが、
現状では「テーブルを分ければいいじゃん」という結果だけで
その主旨をご説明いただいていないので、混乱している状況です。。

49 ：

>>47
今は、「ユーザ」は、サイトを利用する会員と、管理ユーザしかいないので、
アクセスログは一般会員のみ取得しています。
今の私の考えで行くと、
「ビジネス会員のアクセス履歴」を取ろうとする設計なら、
user_logs　→　一般会員のアクセス履歴が入るテーブル
biz_user_logs　→　ビジネス会員のアクセス履歴が入るテーブル
にしていると思います。
会員種別が違いますので、
「全アクセス履歴が欲しい」という要件にはなりづらいです。

50 ：

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

51 ：

申し訳ありません。書き間違いでした。
正しくは↓の通りです。
現状では「1つのテーブルで管理すればいい」という結果だけで
その主旨をご説明いただいていないので、混乱している状況です。。

52 ：

>>51
ビジネス会員や一般会員がユーザーの属性と考えてる人は分けない
あなたの懸念している点は設計の本質ではないの
> ・テーブルのバックアップが取りづらい
バックアップとソースが等価にならないものはバックアップと呼ばない
> ・セキュリティ的に不安（全会員の情報が漏れる可能性がある）
実装の問題であって設計の問題ではない
テーブルを分けた場合の利点とやらも↓で代用できる程度のもの
CREATE VIEW biz_users AS SELECT * FROM users WHERE ビジネス会員のみ;
> ・会員数が増えた場合の使い勝手
DBMSのお仕事ですがな

53 ：

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

54 ：

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

55 ：

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

56 ：

>>55
上司じゃなくて、自分が運営しているサイトの話しです。
「ユーザ」という考え方のテーブル設計・名称を考察しておりますので、
スレ違いでないと思うのですが・・・・
>>52
その回答に対しては理解できました。
でも、私には「1つのテーブルに複数会員の情報が入る」
と言う設計について、どうしても納得行かないんです。
それがどのように便利でどう当たり前の設計なのか、
その点については誰も回答されていませんよね？
「当然だ」と言うからには、何かしら理由があってそうしてると思うんです。
それが分かれば私が悩んでいた「名前の付け方」についても
答えが導き出せると思いますし、納得して設計出来るようになると思うのですが・・・

57 ：

>>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 ：

要件上、一般会員とビジネス会員を同じ会員として扱うならまとめたらいいし、
ビジネス会員と一般会員は全然扱いが別なら別テーブルにすればいいと思う
でも全然扱いが別ならそもそもデータベースを一般とビジネスで分けてそれぞれにuserテーブルでも作ったらいいんじゃないかな
みんな言ってるけど要件次第かと

59 ：

>>57
実際にテーブルを作成して試しました。
このコードで引っかかるのが
「会員なら誰でも投稿できるブログ」という事って
あまりないのではないでしょうか？
同様に、「投稿者名一覧が欲しい」というケースも
”一般会員（ビジネス）としての一覧”が欲しいというケースはあっても、
会員種別無く出力するケースて、ほとんどないと思います。
「それならroleで会員指定すれば良いだけ」なのはわかりますが、
端から別物だという考えがある会員情報を、
どうして一つのテーブルにしているのか？が引っかかるのです。

60 ：

>>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 ：

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

62 ：

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

63 ：

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

64 ：

>>60
ビューってしってるか？
あとお前がどれほどのシステム扱ってるかしらんが
結合せずにＤＢから単一テーブル持ってくる処理なんて実務にほとんどないぞ
>編集・削除の面からも便利なのではないか？
>と思い、「テーブルを分ける」という考え方でいます。
編集・削除といった処理はどうとでもなるから、そんなことではなく
要件（モデル）によってわけるかどうか決めろってみんな言ってるんだが
>他の人の意見を聞くと「1つのするのが一般的」と言われます
少なくともここの意見では、一般的って言えるほど優勢な意見ではないと思うが
みんな要件次第っていってるぞ
お前が別物だって言うならわければ良い。それだけ
>私の中で考えが混乱してしまい、要件定義できずにいます
まさかと思うが、お前、テーブルレイアウト決めてから要件定義しようとか思ってないか？
テーブル分けるかどうか決めてから要件定義するんじないぞ
要件によってわけるかどうか決めるんだぞ

65 ：

>>61-64
はっきりいって、私の中で要件は「後々変わる」と思ってます。
現在、私が運営しているサイトでは、一般会員と管理ユーザで
問題なかったので、会員種別という概念が無く、単にテーブルを分けていました。
しかし、サイト（システム）をリニューアルさせる段階で、
会員の種別が増える事と、一般的（他人から見て）を考えた時、
たちまち、どうすればいいか？が分からなくなってきてるんです。
私が、phpMyAdminと言うツールでDBを管理しているのもまずいのかもしれません。
これを使ってアプリの動作テストをしていると、いちいちSQLを実行しないと
抽出できないので、使い勝手が悪く、だからテーブルを分けている
と言う要因もあると思います。
しかし、已然として
「会員種別が異なるテーブルに、全ての会員情報を保持しても良いのか？」
と言う疑問を感じてなりません。
せめて、「ここのサイトでは1つの会員テーブルで操作している」
と言う事例があれば、想像も付くと思うのですが・・・

66 ：

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

67 ：

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

68 ：

>phpMyAdminと言うツールでDBを管理しているのもまずいのかもしれません。
ツールの問題ではないことに1000テラベクレル

69 ：

では、仮に要件定義として、
今までの「一般会員」と「管理ユーザ」に、「ビジネス会員」を追加する。
と決めたとします。
それでも、私が悩んでいるように、テーブルを分けるか否か、
分けた時のテーブル名をどうするか？
と言う悩みが解決されないのではないでしょうか。

70 ：

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

71 ：

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

72 ：

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

73 ：

>>21
良い事を教えてやろう。
1つのテーブルにまとめる理由は
テーブル数が増えないから
だ。これは非常に大きいぞw（いや、冗談抜きで

74 ：

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

75 ：

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

76 ：

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

77 ：

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

78 ：

おまえら偉そうに言ってて、話してるうちに前提を忘れてるのな。
ほんとに要件定義とかできるのかよ。
> 最初は1つのusersテーブルに区分を付けてまとめようとしたのですが、
> 各会員のカラム構成が違うので、独立したテーブルにしようと思いました。

79 ：

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

80 ：

持つ属性が違う以上は別のテーブルを作る必要はあるだろうけど
1. user
userid,共通属性1,共通属性2...
2.nom_user
userid,属性1,属性2...
3.biz_user
userid,属性1,属性2...
こんな感じでuserテーブルでIDを一意にするようにしておいたほうがいい
userテーブルに会員区分を持つ
その構成ならテーブル分けるのと変わらないじゃんとか言われそうだけど
会員全体という括りで処理をすることが一生ない？

81 ：

横からすいません。質問です。
２つの条件を満たすユーザのみ指定のデータを閲覧できるようにしたいのですが
どのようにデータを持たせればいいか悩んでいます
わかりづらいですよね。
例えば１と２と３の顧客リストがあって（内容は同じですがリストに名前が付いている）それぞれに閲覧権限があるとします。
それだけならユーザテーブルに権限をいれておけばいいのですが、
今回はさらにユーザ毎に閲覧できる都道府県も限定したいのです。
単純に各都道府県用に閲覧できるかのフラグをユーザテーブルに持たせてもいいのですが
なんかすごい横長のユーザテーブルができてしまうような…
どうしたらスマートな感じになるでしょうか…？

82 ：

>>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 ：

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

84 ：

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

85 ：

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

86 ：

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

87 ：

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

88 ：

もう分けて union しとけよ

89 ：

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

90 ：

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

91 ：

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

92 ：

wordpressは1つのユーザテーブルだな。
SNSのプラグイン入れたけど、
その時はprofileテーブルと結合する形だった。
ただ、同じテーブルを使っているからか、
管理画面も同じだから少し違和感を受けたな。

93 ：

質問です。次の二つならどちらが自然な設計に感じますか？
１．
顧客（顧客コード）
顧客受注（顧客コード、受注コード）
受注（受注コード、受注総額）
受注明細（受注コード、受注明細コード、明細金額）
２．
顧客（顧客コード）
受注（顧客コード、受注コード、受注総額）
受注明細（受注コード、受注明細コード、明細金額）

94 ：

２

95 ：

一つの受注に顧客は一つしかないという暗黙の前提が含まれてるなら２
そうじゃないなら１
ここで何回も言われてるけど、テーブルの項目名だけで設計の是非なんて判断できんぞ

96 ：

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

97 ：

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

98 ：

文字列型でで保存するか、数値型で保存するか迷う
例えば、ショッピングサイトで、配送希望日時と、配送方法を選ばせる場合、
セレクトボックスで、
-午後 12 時 〜 午後 2 時
-午後 2 時 〜 午後 4 時
-午後 4 時 〜 午後 6 時
-午後 6 時 〜 午後 8 時
-午後 8 時 〜 午後 9 時
こういう選択肢があるとすると、
上から順に1,2,3,4,5として数値で保存（PHPの配列か別テーブルでマッピングさせる）するか、
上記の文字をそのまま文字列型で保存するか悩みます
僕の考えでは、将来上記の時間帯が変更になることも考えられるので、
そのまま文字列として注文と一緒に保存してしまおうと思ったのですが、、、どうすべきでしょうか？
その他、支払い方法として、
・代引き引き替え
・玄関先クレジット払い
というラジオボックスもあります。これはやはり数値でしょうか？？？
でもこれを数値でやるなら、前の例も数値でいいんじゃ？？と混乱してきたので、
アドバイスを求めにやってきました。。。どうかお願いします。

99 ：

どっちでもいいよ。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
11: システム構築ベンダの実力 (937)
12: Microsoft SQL Server 総合スレ 9 (187)
13: 【MySQL】下らねぇ質問はID出して書き込みやがれ 2 (12)
14: no sql 総合 (4)