DB設計を語るスレ 8 [転載禁止]©5ch.io
レス数が1000を超えています。これ以上書き込みはできません。
0001NAME IS NULL
2015/02/18(水) 18:09:10.83ID:cm3dXkF1前スレ
DB設計を語るスレ 7
http://peace.2ch.net/test/read.cgi/db/1386312737/
0002NAME IS NULL
2015/02/18(水) 18:40:45.29ID:???DB設計を語るスレ 6
http://toro.2ch.net/test/read.cgi/db/1341061787/
DB設計を語るスレ 5
http://toro.2ch.net/test/read.cgi/db/1331558806/
DB設計を語るスレ 4
http://toro.2ch.net/test/read.cgi/db/1309828440/
DB設計を語るスレ 3
http://hibari.2ch.net/test/read.cgi/db/1269585561/
DB設計を語るスレ ２
http://pc11.2ch.net/test/read.cgi/db/1223458453/
DB設計を語るスレ
http://pc11.2ch.net/test/read.cgi/db/1166540159/
0003NAME IS NULL
2015/02/18(水) 18:41:48.58ID:???何故データベース設計は軽視されるのか？
http://toro.2ch.net/test/read.cgi/db/1228061247/
頼むから正規化しろよ 第二正規形
http://toro.2ch.net/test/read.cgi/db/1116097001/
【より良い】データモデリング【モデルを】
http://toro.2ch.net/test/read.cgi/db/1057509675/
T字形ER（TM)ってどうよ？
http://toro.2ch.net/test/read.cgi/db/1156946197/
0004NAME IS NULL
2015/02/18(水) 18:42:43.90ID:???複数の課金情報を一括で請求するという話らしいよ
0005NAME IS NULL
2015/02/18(水) 18:47:56.97ID:???悪いんだけど、もう一回前スレ989-991を読み返して。
あと>>1乙
0006NAME IS NULL
2015/02/18(水) 19:05:24.42ID:???そうだね。
http://peace.2ch.net/test/read.cgi/db/1386312737/928
は、そういう主張をしている人だよ。
0007NAME IS NULL
2015/02/18(水) 20:09:41.39ID:???0008NAME IS NULL
2015/02/18(水) 21:28:48.64ID:???そんなレス書くやつのほうが、よっぽど…
0009NAME IS NULL
2015/02/18(水) 22:56:42.75ID:???> （変わる例としては、特定ユーザーのみ割り引くとか、キャンペーン中なので請求金額のみ割り引くとか
> あと途中で値上げ/値下げした時に、その切り替わりの処理を考慮する必要がある（サービステーブルそのまま書き換えると、課金した時と請求する時で金額が違うとかなるから））
これ、俺ならそういう課金レコードを別に作ると思うんだけど、それって変な発想なのかな
0010NAME IS NULL
2015/02/19(木) 00:01:09.32ID:???が正解
0011NAME IS NULL
2015/02/19(木) 01:48:21.53ID:???俺は>>952を不支持
統一するか分けるかは仕様によるとしか言えん
特に分ける理由が無ければ統一でいいでしょ
0012NAME IS NULL
2015/02/19(木) 11:01:20.92ID:???> 特に分ける理由が無ければ統一でいいでしょ
ひとつにまとめるのが普通な人は、そう思うんでしょう。
分けるのが自然と考える人は、特に結合する必要がなければ結合しない、ということになる。
> 統一するか分けるかは仕様によるとしか言えん
何をエンティティにするかということに関して、仕様が影響するのは事実だけど、
社会通念上別物なら別エンティティだと考えるのも自然だと思う。そして、俺はそっち派。
さらに今回はイベント発生トリガーに時間的差異がある、1:1ではなくて1:0..1の場合の話だから、
それが結合しない方が良い理由の一つにもなる。NULL撲滅委員会的に。
0013NAME IS NULL
2015/02/19(木) 14:19:49.82ID:???> これ、俺ならそういう課金レコードを別に作ると思うんだけど、それって変な発想なのかな
課金テーブルがあるという前提で、請求金額の帳尻を合わせるために課金が発生していないにも
かかわらず課金レコードを追加すると、後々禍根が残りかねない。
俺なら、請求明細テーブルを作って、対象となる課金レコードに対応するレコードと、割引など
レコードを作って、SUM(請求明細.請求金額)が請求合計金額になるようにするな。
0014NAME IS NULL
2015/02/19(木) 15:13:36.48ID:???普通そうだわなぁ
0015NAME IS NULL
2015/02/19(木) 16:11:55.94ID:???ごめん、サービスレコードと書くところを課金レコードと書いていたようです。
課金サービスはそのままにして割引サービスレコードを追加するというのはなるほどでした。
どもです。
0016NAME IS NULL
2015/02/19(木) 16:58:01.05ID:???・会員が利用したサービスに対して月額料金を請求する
・会員が利用したオプションサービスに対して料金を請求する
・オプションは何度も追加される可能性あり
・月末締め、翌月指定日に請求メールを送信する
・会員は振込方法を選べる
・管理者が確認したら利用継続。未払いなら停止
こういうのはWebサービスでよくあるよな？レン鯖とか携帯の契約もそうだ。
今や机上の空論的な論争になってるが、こういう想定で設計を考えたらどうだ？
0017NAME IS NULL
2015/02/19(木) 17:04:08.73ID:???そんなの誰が設計したって似た感じになるだろ、
って思ってたんだが、ひとつにまとめるべき派が出てきて驚愕した。
0018NAME IS NULL
2015/02/19(木) 17:42:50.86ID:???0019NAME IS NULL
2015/02/19(木) 17:50:53.88ID:???思ってるんだろうってことがわかった。
0020NAME IS NULL
2015/02/19(木) 20:28:30.21ID:???エンティティ数やテーブル数は出来るだけ減らすのが正義だとする人に合った事はある
仕様書のページ数やプログラムのステップ数で値段決まってた時代の人かと思ったぜ
0021NAME IS NULL
2015/02/19(木) 23:42:08.07ID:???0022NAME IS NULL
2015/02/20(金) 00:30:48.55ID:???0023NAME IS NULL
2015/02/20(金) 00:43:06.87ID:???0024NAME IS NULL
2015/02/20(金) 01:09:41.62ID:???性能落ちるやん
昔ステータスが変わるごとにテーブル項目全コピー
マスタの内容は時点の内容を横持ちってシステムを担当して驚いたけど
データ量は増えるけど処理は簡単だし１手前に戻れるとかいろいろ勉強になった
0025NAME IS NULL
2015/02/20(金) 01:38:35.39ID:???0026NAME IS NULL
2015/02/20(金) 02:45:43.25ID:???1で済む物をわざわざ分ける理由は？
社会通念上？
正規化と全然関係無い（笑）
0027NAME IS NULL
2015/02/20(金) 08:38:33.86ID:???0028NAME IS NULL
2015/02/20(金) 10:16:14.93ID:???論理設計におけるエンティティ抽出の話だよ。
一般的に考えて、別々の業務で発生する事象を、論理設計段階で別物として扱うということ。
ところで、申請と承認を扱うシステムがあったら、それも一つにまとめるのか？
0029NAME IS NULL
2015/02/20(金) 10:33:24.42ID:QgK6W0g0・1ユーザーがメインカテゴリ、サブカテゴリの2階層まで登録できる
・階層が増えるケース（3階層になるとか）は無い
・データ表示画面でサブカテゴリ名を常に表示したい（食べログとかのポータルサイトのイメージ）
■共通テーブル
□ユーザーテーブル
ID｜ユーザー名
□カテゴリテーブル
ID｜親ID｜カテゴリ名｜順番
■考え中のAパターン（中間テーブルをもちいて、2レコード登録）
□ユーザーカテゴリテーブル
ID｜ユーザーID｜カテゴリID
■考え中のBパターン（ユーザーテーブルを変更してカテゴリIDを追加）
□ユーザーテーブル
ID｜メインカテゴリID｜サブカテゴリID｜ユーザー名
A・Bどちらにすれば良いか悩んでいます。
正規化や汎用性の高さからはAでしょうが、出力時にSQLコストがかかります。
プログラムで再帰しながら何とかする方法もあるのでしょうが・・。
かといってBだと汎用性がなさすぎるので、仮に「1ユーザー2カテゴリ登録させたい」だと詰みます。
皆様のご意見をお願いします。
0030NAME IS NULL
2015/02/20(金) 11:18:08.17ID:???食べログとかのポータルサイトを全然知らないからイメージがわかない。
> □カテゴリテーブル
> ID｜親ID｜カテゴリ名｜順番
は決定項目なのが前提みたいだけど、この構造を変えるっていう案もあるのでは。
0031NAME IS NULL
2015/02/20(金) 13:32:54.98ID:???0032NAME IS NULL
2015/02/20(金) 13:44:46.51ID:???カテゴリのメインとサブの区別がよくわからん
>・1ユーザーがメインカテゴリ、サブカテゴリの2階層まで登録できる
この言い方だと、メインかサブかはユーザーの指定によって決まるように見える
メインに出来るカテゴリ、サブに出来るカテゴリ、メインとサブにできる関係
このあたりの条件をはっきりさせた上で
ユーザが登録できるメインカテゴリ数とサブカテゴリ数の上限（と下限）
をはっきりさせんと何も決まらん
003329
2015/02/20(金) 14:08:55.50ID:???分かりづらくてすみません。
□カテゴリーテーブル
ID｜親ID｜カテゴリ名｜順番
1 ｜NULL｜和食｜1
2 ｜NULL｜中華｜2
3 ｜1 ｜寿司｜1
4 ｜2 ｜ラーメン｜1
こういうカテゴリが入ってるとします。
1ユーザーは「和食＞寿司」という選択が出来るイメージです。
1人1カテゴリ（メイン内のサブカテゴリ1つを選択）という意味です。
0034NAME IS NULL
2015/02/20(金) 14:45:35.93ID:1Av/MwJL2階層がそのうち3階層以上に拡張したくなるかもしれない。
ユーザーが複数のカテゴリを使いたくなるかもしれない。
対応しやすさから言うと、上の方かな。
0035NAME IS NULL
2015/02/20(金) 14:50:37.44ID:???□親カテゴリーテーブル
ID｜カテゴリ名｜順番
1 ｜和食｜1
2 ｜中華｜2
□サブカテゴリーテーブル
ID｜親ID｜カテゴリ名｜順番
1 ｜1 ｜寿司｜1
2 ｜2 ｜ラーメン｜1
□ユーザーカテゴリテーブル
ID｜ユーザーID｜サブカテゴリID
という構造にすることもできるのだが。
0036NAME IS NULL
2015/02/20(金) 14:53:18.91ID:???そして、その選択されたカテゴリはどこに使われるんだ？
0037NAME IS NULL
2015/02/20(金) 15:10:52.05ID:???> 出力時にSQLコストがかかります。
AとBで一体どれくらいコストの違いがあると思ってる？
> プログラムで再帰しながら何とかする方法もあるのでしょうが・・。
どこに再帰の必要があるんだ・・・。
> かといってBだと汎用性がなさすぎるので、仮に「1ユーザー2カテゴリ登録させたい」だと詰みます。
ん？
□ユーザーテーブル
ID, メインカテゴリID, サブカテゴリID, ユーザー名
1, 1, 1, user name1
2, 1, 2, user name1
3, 1, 1, user name2
登録できるけど？
0038NAME IS NULL
2015/02/20(金) 15:12:30.76ID:???氏名とかメールアドレスとかパスワードとかが登録されてる奴か？
だったら、Bパターンはないわー。
0039NAME IS NULL
2015/02/20(金) 15:18:44.83ID:???悩むのもわかるが、2階層までしかないなら
> □カテゴリテーブル
> ID｜親ID｜カテゴリ名｜順番
>
> □ユーザーカテゴリテーブル
> ID｜ユーザーID｜カテゴリID
でいいでしょ。
それともあれか？
たかだか1:1にしかすぎないから、全部まとめるのはどうかとか、そういう話か？
004029
2015/02/20(金) 17:37:47.54ID:???今、Aパターンでパフォーマンステストしていますが、
おっしゃるように再帰問い合わせできずにサブクエリだらけになるので、重くならないかと・・。
もちろん要件次第なのはその通りなのですが、見極めが難しいところです
004129
2015/02/20(金) 17:42:39.67ID:???目的はユーザーのグループ（所属）分けです。
ID｜名前｜メインカテゴリ名｜サブカテゴリ名
みたいな感じで一覧表示が目的です。
この形のSELECTを実行するにはAパターンだとサブクエリしまくりが発生します。
どの程度パフォーマンスに影響が出るかは調査中ですが。
0042NAME IS NULL
2015/02/20(金) 17:43:33.80ID:???> サブクエリだらけ
って、カテゴリの部分はカテゴリテーブルをJOINするだけでしょ？
0043NAME IS NULL
2015/02/20(金) 17:45:16.07ID:???0044NAME IS NULL
2015/02/20(金) 17:50:35.91ID:???メインカテゴリでグルーピングするのか、サブカテゴリでグルーピングするのか。
0045NAME IS NULL
2015/02/20(金) 17:55:48.84ID:???カテゴリという言葉が、メインカテゴリ、サブカテゴリ、メインサブの系統
あたりの区別が出来ずに使われてるのが問題
>メインに出来るカテゴリ、サブに出来るカテゴリ、メインとサブにできる関係
何一つとしてはっきりしてないのだが
本人もなんとなくでしか理解してないんだろうけど、一度条件をはっきり書きだしてみたら
ユーザーが指定するのはサブカテゴリを一つだけで良いのか？
その場合
サブカテゴリは必ず親カテゴリをもってるのか？
それは（ユーザーに無関係に）一意にきまるのか？
そのカテゴリマスタの構成で考えられるのは、メインとサブに厳密な区分はない場合だ
（機械構成部品のように、見方によっては親だが違う見方では子になるような）
その場合はサブを指定するって考え方はおかしい
0046NAME IS NULL
2015/02/20(金) 18:20:09.10ID:???プログラマはね、記述された仕様をきっちり読むものなんだよ。
だから、
> ・1ユーザーがメインカテゴリ、サブカテゴリの2階層まで登録できる
「2階層まで」とあったら、
・カテゴリ未登録
・メインカテゴリのみ登録
・メインカテゴリ・サブカテゴリの両方を登録
って読む。（読まない人もいるだろうが）
まず、この理解は正しいかどうかだけでも教えてくれ。
で、もし正しいなら、グルーピングは何を対象に行うのか教えてくれ。
0047NAME IS NULL
2015/02/20(金) 18:36:32.80ID:???これでいいのかどうか教えてくれ。
table users: {id, name}
1;"user1"
2;"user2"
table categories: {id, parent_id, name, seq}
1;;"和食";1
2;;"中華";2
3;1;"寿司";1
4;2;"ラーメン";1
table user_category {user_id, category_id}
1;3
2;4
select u.id as user_id,
u.name as user_name,
c1.name as main_category,
c.name as sub_category_name
from user_category uc
join users u on u.id = uc.user_id
join categories c on c.id = uc.category_id
join categories c1 on c1.id = c.parent_id;
1;"user1";"和食";"寿司"
2;"user2";"中華";"ラーメン"
004829
2015/02/20(金) 19:32:43.06ID:???1度の登録でメインカテゴリ、サブカテゴリを必ず登録します。
例）
Aさんは「和食（メイン）」の「寿司（サブ）」を選択した。
Bさんは「中華（メイン）」の「ラーメン（サブ）」を選択した。
というイメージですので、>>47さんの場合は
table user_category {user_id, category_id}
1;1
1:3
2;2
2:4
になります。
メインカテゴリだけ検索して、絞り込み検索でサブカテゴリまで抽出したいので、
上記のような入力方法になると思っています。
ただ、>>47さんのSQL文を見ると、自分の考えが間違っている気がしてなりません・・。
自分ではこれほど短いコードは書けません。サブクエリだらけだったので。
もう少し勉強してみます。皆さん、説明不足なのにアドバイス頂き、ありがとうございました。
0049NAME IS NULL
2015/02/20(金) 19:40:09.96ID:???シンプルに考えればええんよ。
サブがわかればメインは引っ張ってこれるよね。という話。
005029
2015/02/20(金) 20:44:35.37ID:???改めて感謝させてください。>>48のSQL文、凄いですね！
単純結合でここまでスマートに、シンプルに出来ると思いませんでした。
そして、メインカテゴリ・サブカテゴリと2つ登録しなくても
メインだけ、サブだけで絞り込み検索できますし、完璧だと思います。
パフォーマンス的にも全く問題無いです。かなり速いです。
自分が勉強した範囲では、>>48のように2つ登録する方法が中間テーブルとして正しいと学んだので、
本当に目から鱗というか、驚きでした。自分の中でDBに対する世界観が変わったような衝撃です。
自分の足りない情報でここまで丁寧に・確実にご回答いただけ、申し訳ない限りです。。
本当に本当に勉強になりました。貴重なアドバイスをありがとうございました。
005229
2015/02/20(金) 21:12:37.03ID:???これは凄すぎます。自分のSQL史を塗り替える衝撃です。
本当にありがとうございました。
0053NAME IS NULL
2015/02/21(土) 02:05:42.60ID:???むしろもともとどんなクエリを書いていたのか見てみたい
0054NAME IS NULL
2015/02/21(土) 02:23:11.15ID:???論理設計？実装の話だよ
>>ところで、申請と承認を扱うシステムがあったら、それも一つにまとめるのか？
要件次第だろ（笑）
0055NAME IS NULL
2015/02/22(日) 09:41:18.84ID:+W519OeWjoin使うなと言うアホが未だにいるしな
で、ぼこぼこ同じ値保持しまくるテーブルが出来てどこが正しいの〜？ってなる
0056NAME IS NULL
2015/02/22(日) 10:06:55.97ID:???＼エーーーーーーーッ！？／ ,,､,､,,,
∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
（ ） （ ） （ ） ）
0057NAME IS NULL
2015/02/22(日) 10:24:23.91ID:???そういうバカのせいで使用が制限されてるようなもんだしな
0058NAME IS NULL
2015/02/22(日) 10:31:43.44ID:???0059NAME IS NULL
2015/02/22(日) 11:13:08.38ID:???結合順ならわかるが書き方で重くなる？
今ちょっとはまってるので、教えろください
0060NAME IS NULL
2015/02/22(日) 17:47:17.60ID:9nhB2Xgl月額料金はプラン毎に金額や使用範囲・条件が変わって、
オプションはドメイン追加とかメールアカウント追加とかそういうのです。
（ちなみにレン鯖を運営しているわけでも運営するつもりでもありません）
当初は、料金プランテーブルとオプションテーブルの2つを作ればいいと思ったのですが、
「プランによって使用範囲が変わる」「オプションによっても使用範囲が変わりそう」との想定から、
基本的なのは1つのテーブルにまとめて、以下のように正規化することを考えました。
◯料金テーブル（ID、プラン名、価格、識別コード）
1｜格安プラン｜500｜plan
2｜独自ドメイン｜3000｜option
◯料金設定テーブル（料金ID、設定名、設定値）
1｜initial_cost｜3000
1｜capacity｜10737418240
※格安プランの初期費用は3000円、使用可能容量は10GBという意味
この設計についてどう思いますか？足りない情報があればツッコミお願いします。
0061NAME IS NULL
2015/02/22(日) 18:36:13.85ID:+W519OeWjoin使うと遅いから使うなと言ったアホはインデックスを知らなかった
0062NAME IS NULL
2015/02/22(日) 18:50:52.72ID:???そんな情報はどうでもよくて、joinの書き方が変なことでクソ重くなる例がほしいんだと思う
0063NAME IS NULL
2015/02/22(日) 20:01:49.52ID:???インデックスの無い列でjoinしたら遅かったとか
そういう、書き方と関係ないレベルの話だったオチなんじゃないかと思うんだが
結合順とか今時のオプティマイザなら入れ替えるぞ
0064NAME IS NULL
2015/02/23(月) 00:25:06.04ID:???知らないトラップが潜んでるかもしれないという不安感
0065NAME IS NULL
2015/02/23(月) 04:40:25.42ID:???まあ一般的にそんな話があるなら俺も聞いてみたいが
特定のRDBMSで特定のバージョンで書き方によって
オプティマイザが変な判断するって話は聞いたことあるけど
詳しい中身は忘れたわ。バグとしてさっさと修正されたし
006647
2015/02/23(月) 14:28:43.85ID:???やっぱ、日本語であれこれ質問するより、コード(SQL)書いた方が速いのかな。
面倒なんで、いつもは書かないんだけど。
0067NAME IS NULL
2015/02/23(月) 22:22:49.03ID:???ここの住民的言語難易度
日本語＞＞＞＞SQL
日本語がいいのはそもそもSQL知らない奴
0068NAME IS NULL
2015/02/23(月) 23:15:56.66ID:???0069NAME IS NULL
2015/02/24(火) 06:19:21.74ID:???0070NAME IS NULL
2015/02/24(火) 13:49:29.51ID:???0071NAME IS NULL
2015/02/24(火) 15:40:45.79ID:???0072NAME IS NULL
2015/02/24(火) 16:27:16.40ID:???通常分割するものをあえてひとつにまとめることで生まれるメリットがあることもわかるので、
そのあたりを主張してほしかったなと思う。
普通まとめるでしょというスタンスだったので話はうまく進まなかったね。
0073NAME IS NULL
2015/02/24(火) 19:14:12.04ID:???0074NAME IS NULL
2015/02/24(火) 20:46:17.93ID:???0075NAME IS NULL
2015/02/24(火) 23:23:42.50ID:???普通は纏めるでしょになったのな（笑）
0076NAME IS NULL
2015/02/25(水) 10:11:36.33ID:???特に理由がなければ纏めずにそのままにしておく、というのが自然だと思うんだが。
0077NAME IS NULL
2015/02/25(水) 12:48:56.88ID:???0078NAME IS NULL
2015/02/25(水) 13:20:09.67ID:???0079NAME IS NULL
2015/02/25(水) 13:20:43.03ID:???これ以上言っても無駄だろ
次の話題どうぞ
0081NAME IS NULL
2015/02/25(水) 17:03:39.07ID:???悪いけど、駄目すぎて説明するのがだるい
0082NAME IS NULL
2015/02/25(水) 17:14:37.31ID:???>足りない情報があればツッコミお願いします
情報足りなさすぎてツッコミすらできない
料金設定テーブルが何を持ってるテーブルなのかわからんから
どういう要件でそのテーブル構成になったのかすら読み取れんわ
008381
2015/02/25(水) 17:20:43.41ID:???> レン鯖によくある「月額利用でいくら」「オプション追加したらいくら」というDB設計を勉強しています。
とかしてるのか知らないけど、データベースのモデリングを勉強したことないでしょ。
その手の書籍を先に読むべき。
> ◯料金設定テーブル（料金ID、設定名、設定値）
> 1｜initial_cost｜3000
> 1｜capacity｜10737418240
> ※格安プランの初期費用は3000円、使用可能容量は10GBという意味
とかありえない。
008481
2015/02/25(水) 17:22:54.01ID:???誰にも迷惑かからないし。
0085NAME IS NULL
2015/02/25(水) 17:28:47.69ID:???008681
2015/02/25(水) 17:50:02.51ID:???0087NAME IS NULL
2015/02/25(水) 17:51:18.70ID:???0088NAME IS NULL
2015/02/25(水) 17:59:22.40ID:???以降、自重するので許してくれ。
008960
2015/02/25(水) 18:10:44.53ID:u2pW+KJN>>60に書いた情報で足りると思ったのですが、説明不足ですみません・・。
サービスによって設定項目が変わる場合、その都度テーブルを作るのはどうか？と思い、
料金設定テーブルを構想しました。
>>83-84
WordPressを参考にしてコードで識別する方法を考えたのですが、
ありえないとの事で、勉強不足で申し訳ありません。
みなさん、スレ汚し申し訳ありませんでした。もう少し勉強してから質問します。
回答してくれた方々、ありがとうございました。
0090NAME IS NULL
2015/02/25(水) 18:29:59.03ID:???横から補足すると、料金設定テーブルが何故駄目なのかというと、設定名によって設定名の意味が変わってくるため。
例えば、料金設定テーブルに
1｜domain_cost｜5000
というレコードがあって、「格安プラン、ドメイン追加」の初期費用を計算しようとしたら、capacityの行が邪魔になって簡単なクエリでは金額が計算できない。
これは、超有名なアンチパターン。
同じテーブルに複数の意味の別の情報を登録してはならない。
0091NAME IS NULL
2015/02/25(水) 21:17:56.28ID:???コードで識別するのはいいけど、設定名って何？2レコードにするまでもないだろこんなの
まず最低限第三正規形まで勉強してこい
0092NAME IS NULL
2015/02/25(水) 21:40:20.38ID:???0093NAME IS NULL
2015/02/25(水) 21:48:02.94ID:???何がしたくてこうなってるのか分かんねーから、疑問に思ったこと全部聞いていくしかない
0094NAME IS NULL
2015/02/25(水) 22:14:23.52ID:???非キー属性が存在するということなんだが。(第一正規形はこの際置いておくとして)
>>60のテーブルのどこのことを言っている？
0095NAME IS NULL
2015/02/25(水) 23:42:03.94ID:???0096NAME IS NULL
2015/02/26(木) 08:39:59.52ID:???見える人はこの板にもよくいるね。
0097NAME IS NULL
2015/02/26(木) 13:14:11.12ID:???0098NAME IS NULL
2015/02/26(木) 16:01:43.59ID:???> 何がしたくてこうなってるのか分かんねーから、疑問に思ったこと全部聞いていくしかない
このスレは、ド素人を育ててあげるスレではありません。
0099NAME IS NULL
2015/02/26(木) 17:33:17.98ID:???こういう「俺は素人じゃない！」と思ってる子が一番かわいい
0100NAME IS NULL
2015/02/26(木) 18:22:29.14ID:???0101NAME IS NULL
2015/02/26(木) 23:51:17.20ID:???まず基本的なところから指摘すると、正規化という技法は
DB設計における論理設計フェーズで「最適化」を目的として用いられるもの
だから正規化うんぬんを検討するには、概念モデルから正しく導出した
初版の論理モデルが必要になる
残念ながら >>60 の設計内容を見るに、
「概念モデルから初版の論理モデルを正しく導出する」
というDB設計の初歩が身に付いていないと思われる
以下、具体的にざっと見て気が付いた問題点を挙げてみる
(1) 料金テーブルの一意性(identity)が曖昧
あるロウ(行)の一意性を保証するカラムはキーと呼ばれるけど、
このテーブルには「ID」と「識別コード」という２つのキー候補がある
現実世界のモデリングであれば、複数のキー候補が重複したり
それを許容せざるをえないといった難しい局面も想定できるけど、
今回の単純なDB設計演習課題であれば、１つに絞れるはず
(2) 料金テーブルの一意性(identity)が複雑
このテーブルで一意性を保証するには、２つのカラム「料金ID」と「設定名」を
組み合わせなければならない
こうしたキー構成は複合キーと呼ばれ、現実世界のモデリングでは
積極的に使う/使わざるをえないといった難しい局面も想定できるけど、
今回の単純なDB設計演習課題であれば、１つキーだけで保証できるはず
(3) 複数の料金プラン間で共通するオプションが想定されていない
たとえばウィルス検査サービス/自動メール転送サービスといった、
各プランで共通するオプションが表現できていない
まず正規化という言葉を忘れ、「与えられた要求仕様をモデルで正確に表現する」という
視点でDB設計の考え方を見直してから、検討(勉強)を再開したほうがいいと思う
0102NAME IS NULL
2015/02/27(金) 00:08:56.15ID:???0103NAME IS NULL
2015/02/27(金) 00:34:11.77ID:???>なんでその段階で複合キーやめろって話が出てくるんだ。
複合キーを使ったDB設計法そのものは否定していないよ
それが必要になる/必要か否かを検討しなければならない局面はあるから
ただし、この程度の単純なお題で、なおかつ「ロウの一意性」というDB設計における
初歩の初歩を正しく理解していれば、単純に一つのカラムだけでキーを構成できるはず
今回のケースは腕自慢大会じゃないんだから、より単純な概念モデルのほうが
お題への解答として望ましいのは、しごく当たり前の話じゃないかな
>そのキーはどっから現れるんだよ。
もし >>102 が「ロウの一意性」を理解しているのなら、意味不明な質問だね
0104NAME IS NULL
2015/02/27(金) 02:46:37.22ID:???最終的にほしいと思っている表をつくってもらうところから始めればいいかな。
日本人は表題好き民族といわれているから、最終的に欲している表はすぐかけると思う。
そっから手順に従って正規化を行えばよかろ。
まとめれば>>101の最後2行だけでいい
0105NAME IS NULL
2015/02/27(金) 04:57:33.27ID:???どう見ても要求仕様なんて固まってない
0106NAME IS NULL
2015/02/27(金) 08:13:34.85ID:???料金IDと設定名と設定値があり、料金IDと設定名に対して設定値が一意に定まる(関数従属する)
という関係があるならば、(料金ID,設定名)が料金設定テーブルの候補キーとなるというのが
関係モデルで考えた場合の基本だが、別にそこに曖昧さも複雑さもないぞ。
一つのカラムだけでキーを構成できるというが、この「一つのカラム」って何を指してるのかね？
0107NAME IS NULL
2015/02/27(金) 12:59:06.05ID:???要件がはっきりしないからモデリングとか無理みたいな話はもういいから
0108NAME IS NULL
2015/02/27(金) 14:57:58.17ID:???とか出題されても誰も正答できんだろ？
出題の前にもっと問題をしっかり作れってなるよな？
0109NAME IS NULL
2015/02/27(金) 15:05:40.32ID:???静かにしてもらえませんか。
0110NAME IS NULL
2015/02/27(金) 17:30:17.77ID:???演算を求めてるわけじゃなく、設計の話だろ？
商品テーブルがあって、購入テーブルがあって、購入商品テーブルがあって〜
って、EC開発経験者なら大体想像できるわな。
その中で、「商品テーブルだけじゃ、”北海道産”の人参と”徳島県産”の人参が分からん」
とかツッコミ入れていき、それなら1つのテーブルに産地カラムを付けるべきだ、いや産地を別テーブルにするべきだ
とかなんとか指摘できるじゃん。
お前みたいな1から10まで正確な要件定義を求める奴って、想像性が足りないからだろ
0111NAME IS NULL
2015/02/27(金) 17:58:59.71ID:???要件定義を語るスレでも立てて要件定義はそっちで固めるとかしてほしいわ
完璧な要件定義だせとは言わんが、ＤＢ設計の話するならＤＢ設計出来る程度の要件は提示してもらわんとな
0112NAME IS NULL
2015/02/27(金) 21:16:11.85ID:???何をもめているんだ？
設計できない言い訳か？
0113NAME IS NULL
2015/02/27(金) 21:20:19.16ID:???x = ジャガイモの価格
y = 人参の価格
3x+2y
できるじゃん
0114NAME IS NULL
2015/02/27(金) 21:22:46.16ID:???お釣りを出すのなら、
答え = 客が出した金額 - ( 3x + 2y )
だね
0115NAME IS NULL
2015/02/27(金) 21:23:25.87ID:???0116NAME IS NULL
2015/02/27(金) 22:29:20.09ID:???投稿にはコメントがついてリビジョンには影響されない
リビジョンはgitのブランチみたいに好きな位置に戻れてそこから枝分かれする感じ
post
post_id
post_revision
revision_id
post_id
parent_revision_id 編集元のリビジョン
is_active 現在有効なリビジョン
comment
comment_id
post_id
一応こんな感じのを考えたんだけど、もっと一般的な方法あるかな？
0117NAME IS NULL
2015/02/27(金) 22:45:08.91ID:???0118NAME IS NULL
2015/02/28(土) 07:32:31.34ID:???0119NAME IS NULL
2015/02/28(土) 08:27:24.51ID:???配列型が使えるDBMSなら、経路列挙モデルでも良いと思う
他にも色々方法があるから"DB 階層構造"で検索すべし
0120116
2015/02/28(土) 12:56:16.79ID:???post_id
parent_id
root_id
is_active
post_data...
こうかな？
コメントやその他テーブルのFKと投稿ページのURLに使うpost_id等は変わらないから
初期投稿のpost_idから現在有効なリビジョンを取得するのにroot_idを追加してみた
どっちみち1回はjoinが必要だからこれがシンプルで無難かなー
0121NAME IS NULL
2015/02/28(土) 15:12:08.20ID:???>投稿にはコメントがついてリビジョンには影響されない
この仕様だとリビジョンを特定したコメントを付けられないけど、
それでいいのかな？
たとえば、ある改訂履歴を伴った記事に対して「今回の改訂内容は間違いじゃね？」と
コメントしたい時、この仕様だとリビジョンを明示的に指定する機能が無いから
コメントの本文中にコメント対象とするリビジョンIDを書かなければならない
この制限は、2ch掲示板だと(カキコ時に対象レス番号を指定する機能が無いから)
カキコ本文中にアンカとして対象レス番号を書くのと類似している
普通は、(投稿ではなく)リビジョンに対してコメントをつける仕様にすると思う
これをあえて逆にした利点や >>60 の意図/設計方針が分からない
0122NAME IS NULL
2015/02/28(土) 16:51:54.33ID:???複数のモデル（A,B）からCを参照したいです。
（早い話、アップロードされた重いファイルを再利用したい）
参照するモデルは増えていく可能性あり。
・D（A_id,B_idを持つ）を定義し、CにD_idを持たせる。
・CにA_id,B_idを持たせる。
・AにC_id、BにC_idを持たせる（コンテントがモデルを保有するのは関係上おかしい気がする）
・A、Bそれぞれにバイナリ情報テーブルAC、BCを定義すべき。
どれがいいですか？
0123NAME IS NULL
2015/02/28(土) 16:55:32.92ID:???> ・AにC_id、BにC_idを持たせる（コンテントがモデルを保有するのは関係上おかしい気がする）
モデルがコンテントを保有しているように見えるけど、詳しく。
0124NAME IS NULL
2015/02/28(土) 16:57:40.09ID:???>なにもおかしな状態のものを是正するアプローチをしなくても
この意見はごもっともで、たしかに正規化という言葉へ過敏に反応してしまった感があります
でも、ただ単に「DB設計の基礎ができていない」と指摘するだけでは、
指摘された >>60 本人が(どこが良くないのか分からないから)途方にくれてしまうと考えました
だから辛口かもしれないけど、あえて具体的に問題点を指摘しています
>最終的にほしいと思っている表をつくってもらうところから始めればいいかな。
この発想は、このスレでたびたび議論になる「テーブルは分けるべき or 纏めるべき」の言葉で
言い換えれば：
「(最終的に欲しいとおもっている要求仕様を)一つのテーブル(=表)へまとめてみよう」
という纏めるべき派に沿った提案であり、
>日本人は表題好き民族といわれているから、最終的に欲している表はすぐかけると思う。
>そっから手順に従って正規化を行えばよかろ。
纏める派の根拠が「日本人は表題好き民族といわれている」であるから、
「日本では纏めるのが普通」という発想になると思います（この推測、間違っていますか？）
>まとめれば>>101の最後2行だけでいい
>>101 の最後2行で示した方向性が重要なのはそのとおりですけど、
自分は分けるべき派だから、「(表に纏めてから)手順に従って正規化を行う」とは設計論が異なります
正規化は論理設計を一通り終えてから、最後の仕上げとして検証(正しく設計されているか確認)および
最適化(性能チューニング)を目的に行うものです
「正規化は検証/最適化の技法であって、要求分析や論理設計の技法ではない」と考えます
0125122
2015/02/28(土) 17:02:51.97ID:???DBの知識は乏しいのですが、具象でいうと、
記事(A)が画像(C)を保有する事と、画像(C)が記事(A)を保有する事では
前者が自然という意味です。
idについて言うと、A has Cの関係だと、CがAのidを持つ事が良いという事です。
0126122
2015/02/28(土) 17:30:40.22ID:???0127122
2015/02/28(土) 17:43:37.04ID:???同一テーブルの異なるレコードから同一のCを参照することができない。でした。
日本語不自由ですみません。
何言ってんだこいつ、みたいな空気？
0128NAME IS NULL
2015/02/28(土) 18:44:02.45ID:???AがCを保有するほうが自然だといいながら、CがAのidを持つ事がよいという結論に至る理由が分からないので詳しく。
0129122
2015/02/28(土) 18:44:16.00ID:???>・AにC_id、BにC_idを持たせる（コンテントがモデルを保有するのは関係上おかしい気がする）
AとCを1対多にしないのであれば、これが一番かもしれません。
ソースコード上ではマッピングでAがCを保有しているようにすればいいのかも。
AとCのオブジェクト指向的な親子関係はDB設計では問題がないのかな、
1対1においてもオブジェクト的に子要素となりうる方にidを定義しなければならないかなと思っていました。
そもそもモデルとコンテントが1対1という前提条件を記入していませんでした。以上です。
スレ汚しすみません。
0130NAME IS NULL
2015/02/28(土) 18:45:38.11ID:???まとめるべきといっているわけじゃない。
正規化を始めるにあたり、最終的に欲しているビューを開始点にすべきだといっている。
0131122
2015/02/28(土) 18:52:45.07ID:???1(A)対多(C)の関係を作るとして、CがAのidを保有しなければ
1つのAレコードは複数のCレコードを保有することができないと思ったからです。
0132NAME IS NULL
2015/02/28(土) 18:53:37.02ID:???そういうことなら連関エンティティを作るといいよ。
記事とコンテンツのマッピングをしているテーブルといったほうが通じやすいかな
0133122
2015/02/28(土) 19:33:08.78ID:???記事A
連関エンティティ・テーブルB（A_id、C_idを持つ）
コンテントC
新規テーブルDが増えた場合、
連関エンティティ・テーブルE（D_id、C_idを持つ）を追加
これなら、記事とコンテントの関係が1対多、多対多の場合でも対応できる。
という事ですか？
0134122
2015/02/28(土) 19:45:41.20ID:???連想エンティティ・テーブルB
コンテントC（B_idを持つ）
新規テーブルD（B_idを持つ）
でもいいのか。
0135122
2015/02/28(土) 19:57:33.09ID:???ありがとうございました。m(_ _)m
後は何とかします。
0136NAME IS NULL
2015/02/28(土) 19:57:35.60ID:???0137NAME IS NULL
2015/03/01(日) 00:20:25.08ID:???その「最終的に欲しているビュー」とは具体的にはどのような構造の情報ですか？
私はそれを「一つに纏めた表」だと推測しています（間違っていますか？）
そして正規化の始まりである「第一正規化された表」とは「一つに纏まった表」であり、
「正規化を始めるにあたり .... ビューを開始点にすべき」という主張は、
「まとめるべき」という主張を別の言葉で言い換えただけのものにすぎず、本質は同じです
0138NAME IS NULL
2015/03/01(日) 00:43:26.81ID:???もうコテつけるかまとめるスレ作ってそっちでやれよ
0139NAME IS NULL
2015/03/01(日) 01:31:36.41ID:???だからそっから正規化されてテーブルが分割されるんじゃん。
日本語不自由なのか？
0140NAME IS NULL
2015/03/01(日) 07:24:12.14ID:???日本語勉強しろ
0141NAME IS NULL
2015/03/01(日) 07:55:00.37ID:???関係データベースの理論を学んでいればわかること。
出発点はすべての属性の直積であって、これに選択、射影といった演算を行って
目的のデータを得るというのが本来の関係データベース。
ただしそのままでは更新異常等の問題があるので、関数従属性などをもとに
リレーションを分割するというのがリレーションの正規化。
で、ここまではあくまでも関係モデルの考え方。
上のレスを見ると関係モデルの言葉と実体関連モデルの考え方がごっちゃに
なっているように見える。独学者にありがちだけど。
0142NAME IS NULL
2015/03/01(日) 08:51:14.09ID:???モデリングスレならDB板できた直後からずっとあるよ
0143NAME IS NULL
2015/03/01(日) 10:25:58.99ID:???nullが不要なカラムなら非null制約つけとけ、必要なら使え
nullを-1とか999999とかで代用するのだけは止めれ
0144NAME IS NULL
2015/03/01(日) 11:36:32.33ID:???ばか
0145NAME IS NULL
2015/03/02(月) 01:05:52.43ID:???0146NAME IS NULL
2015/03/02(月) 16:14:41.36ID:???実体(entity)という言葉を知らずに、DB設計を語ってる（つもりの）奴が多そう。
0147NAME IS NULL
2015/03/02(月) 16:57:30.61ID:???> 普通は、(投稿ではなく)リビジョンに対してコメントをつける仕様にすると思う
そうかな？
普通は、今現在アクティブな投稿内容に対してコメントを付けるのでは？
で、post_idがPKなら、
post
post_id
contents(内容)
の内容が更新されていって、コメントは常にpost_idに対して行われる。
0148116
2015/03/02(月) 23:40:08.52ID:???>>147
提案を参考に以下のようにしてみました。
これで1回実装してみようかな
post
post_id
post_revision
revision_id
post_id
parent_revision_id 編集元のリビジョン
is_active 現在有効なリビジョン
data...
comment
comment_id
post_id
post_revision_id
0149NAME IS NULL
2015/03/03(火) 10:31:16.38ID:???post_revision.dataってブログの内容？
その構造だと、post一覧を持ってくるの厳しくない？
0150NAME IS NULL
2015/03/03(火) 10:32:17.19ID:???なんか、やだなぁ、それ。
0151NAME IS NULL
2015/03/03(火) 13:17:26.10ID:???> リビジョンはgitのブランチみたいに好きな位置に戻れてそこから枝分かれする感じ
ができちゃまずいんじゃないかと思ったりしたが。
1.1 -> 1.2 -> 1.3で1.3にコメントつけられたが、やっぱ1.2から分岐した1.2.1がcurrentねとかやられると、
1.3のコメントの立場は？って思う。
0152NAME IS NULL
2015/03/03(火) 13:30:13.88ID:???ブログというよりwikiに近いものにも思える。
0153NAME IS NULL
2015/03/03(火) 15:47:07.69ID:???本来の目的があって、その実現手段としてある実装方法を思いつき、「ある実現手段の実装方法は？」と
質問してしまうパターンじゃないの？
本当の目的が「gitみたいなリビジョン管理」じゃないのなら、真の目的の実現手段は別にあるかもよ。
0154NAME IS NULL
2015/03/03(火) 17:28:58.33ID:???0155NAME IS NULL
2015/03/10(火) 02:37:01.16ID:???ページの文字数はユーザーが変更できます
0156NAME IS NULL
2015/03/10(火) 10:08:26.10ID:???その場合本はどのくらい想定しているのか
各本に対してページはどのくらい想定しているのか
ページの文字数はどのくらいを想定しているのか
ページをどうやって取ってくるのか（頁番号、文字列検索）
ページの文字数をユーザーが変更できるというのは具体的にどういうことか
ページの内容をユーザーが変更できるということか
0157NAME IS NULL
2015/03/10(火) 10:27:41.09ID:???0158NAME IS NULL
2015/03/10(火) 11:27:01.22ID:???スマホの読書アプリ使ったことないの？
0159NAME IS NULL
2015/03/10(火) 11:31:27.81ID:???0160NAME IS NULL
2015/03/10(火) 11:55:07.67ID:???0161NAME IS NULL
2015/03/10(火) 14:17:40.39ID:???本の数はわかりません
ページ数もわかりません
ページ番号は文字の大きさで変わるのですが、文字の大きさとユーザのページ番号は記録します。文字列検索はデータベースの昨日ではなく、別に対応します
ユーザーは本の内容を変更できません
ローカルファイルは使えませんが、AmazonS3のようなデータベースは使えます
0162NAME IS NULL
2015/03/10(火) 16:11:22.59ID:???>>156は無視していいんじゃないかなぁさすがに。
0163NAME IS NULL
2015/03/10(火) 16:51:31.52ID:???大きさで変わると言ってるだけだ
0164NAME IS NULL
2015/03/10(火) 16:59:22.21ID:???0165NAME IS NULL
2015/03/10(火) 17:24:35.11ID:???文字列検索エンジンから渡されるのが本IDと頁IDとして
本ID,頁ID,頁内容
頁内容の型はsqlserverだとvarcahr(max)
0166NAME IS NULL
2015/03/10(火) 17:51:43.68ID:???>>165
> 本ID,頁ID,頁内容
だから、文字の大きさを変えたらページ番号が振り直されるんだってば。
>>155
> 本のように膨大な文字列があって、それを一頁だけとってくるようなテーブルってどう作ればよいですか？
> ページの文字数はユーザーが変更できます
これ、サーバアプリなの？
つか、サーバでやりたいの？
どうしてもサーバでやりたいなら、ページ数が変わる要因ごとに、サーバでプリレンダしてページ単位で保存するしかないのでは？
サーバへのリクエストでその処理をトリガーするのでもいいけど。
行間3パターンで文字の大きさが5種類あるなら、MAX15パターン。
英文フォントとかだと、文字の大きさを変えなくても、行間が調整されてページ内文字数が変わったりするかもだけど。
0167NAME IS NULL
2015/03/10(火) 17:53:02.30ID:???サーバでやるの無理じゃね？
0168NAME IS NULL
2015/03/10(火) 18:11:06.56ID:???静かにしてもらえませんか
0169NAME IS NULL
2015/03/10(火) 18:11:43.07ID:???ありがとうございます
それが一番良さそうです
0170NAME IS NULL
2015/03/10(火) 18:12:17.45ID:???0171NAME IS NULL
2015/03/10(火) 18:14:09.81ID:???0172NAME IS NULL
2015/03/10(火) 18:15:13.96ID:???0173NAME IS NULL
2015/03/10(火) 18:15:56.81ID:???未来に生きてんな
0174NAME IS NULL
2015/03/10(火) 18:23:18.63ID:???0175NAME IS NULL
2015/03/10(火) 18:59:00.76ID:???0176NAME IS NULL
2015/03/10(火) 19:24:06.81ID:???本ID,フォントID,頁ID,頁内容？
つか、文字列検索は別エンジンて事だが、それは何を返すのよ
0177NAME IS NULL
2015/03/10(火) 19:34:52.28ID:???0178NAME IS NULL
2015/03/10(火) 20:02:33.29ID:???0179NAME IS NULL
2015/03/10(火) 20:05:11.38ID:???なので>>164
0180NAME IS NULL
2015/03/10(火) 20:20:17.63ID:???すみません
0181NAME IS NULL
2015/03/10(火) 21:28:09.34ID:???0182NAME IS NULL
2015/03/24(火) 16:59:37.39ID:???http://getpocket.com/redirect?url=http%3A%2F%2Fqiita.com%2FJxck_%2Fitems%2F156d0a231c6968f2a474
0183NAME IS NULL
2015/03/24(火) 17:00:05.16ID:???こっち
http://qiita.com/Jxck_/items/156d0a231c6968f2a474
0184NAME IS NULL
2015/03/24(火) 18:02:49.51ID:???0185NAME IS NULL
2015/03/24(火) 19:15:18.00ID:???0186NAME IS NULL
2015/03/25(水) 00:45:43.05ID:???正解かもしれんね。
0187NAME IS NULL
2015/03/25(水) 10:25:15.39ID:???0188NAME IS NULL
2015/03/25(水) 12:20:35.36ID:???0189NAME IS NULL
2015/03/25(水) 13:25:49.75ID:???0190NAME IS NULL
2015/03/25(水) 13:40:17.65ID:???削除フラグ立てるより別テーブルに移動しろ？
JOINが超めんどくさいじゃん
0191NAME IS NULL
2015/03/25(水) 18:10:11.75ID:???今まで作ったDB、最初は何も考えずに
消すようにしてると、大抵のケースで問題になるから
削除はフラグになってたな
0192NAME IS NULL
2015/03/25(水) 18:55:12.89ID:???ビュー作っとけば？
めんどくさいことには変わりないけどさ。
0193NAME IS NULL
2015/03/25(水) 19:28:07.65ID:???マスタ系のテーブルは、トランザクション系のデータ一覧なんかを取得するときにJOINしまくると思うけど、
そのJOIN先を全部UNIONしたViewにしろと？
そんなことやったことないからわからんけど、パフォーマンス的にどうなのよ？
0194NAME IS NULL
2015/03/25(水) 20:57:04.36ID:???「それは削除じゃなくて状態です」とか「他に状態はありませんか？」が出てきた辺りで混乱したな
論理削除自体が状態管理だろと
削除されているかどうかの答えだってtrue/false/unknown以外が入ってたら地雷設計やろ
0195NAME IS NULL
2015/03/25(水) 22:41:39.75ID:???0196NAME IS NULL
2015/03/25(水) 23:19:34.02ID:insjhg41後の拡張を予測して、正規化しようか悩んでいます。
作っているプロジェクト自体が小規模を対象としており、
拡張する可能性が無いと思うのですが、
先々の事まで考えて設計するべきか悩み、停滞しております。。。
こういうとき、みなさんならどう設計しますか？
要件通り、1つのテーブルでまとめますか？
それとも万が一の事を考えてテーブルを分けますか？
0197NAME IS NULL
2015/03/26(木) 01:53:44.16ID:???要件をみたすのは当たり前で、それを正規化しない理由がわからん
正規化のためにテーブル分ける必要があるなら分ける
将来的に変更（拡張）しないことなんて、正規化しないことの理由にならん
0198NAME IS NULL
2015/03/26(木) 03:17:23.44ID:???>>195
まったくで。
>>196
現状の要件では、1つのテーブルで十分正規化されてるってことでいいよね。
そうなら1つのテーブルのままでいいよ。
0199NAME IS NULL
2015/03/26(木) 06:54:03.76ID:???> 1つのテーブルで十分正規化されてるってことでいいよね。
どうやったらこんな解釈ができるんだ？
安定した低能君恐るべしｗ
0200196
2015/03/26(木) 12:10:09.03ID:???正規化すると開発の手間や難易度が増えるので（あくまでも自分たちの中では）
1テーブルで収まるなら正規化せずに行こうと考えがちです。
>>198
十分はされていないと思います。
例えば商品テーブルがあって、商品をカテゴリ毎に分けるという仕様があるとします。
商品テーブルにカテゴリIDを追加するだけでいいやってのが今の設計段階なのですが、
「もしかしたら、複数カテゴリに所属する可能性はないか？」って考えが浮かび、
そうなると別テーブル（中間テーブル）を作って正規化した方が良いとなります。
ですが、要件的には「1つの商品にカテゴリは1つ」であり、現実的に考えても
複数カテゴリを指定できるなんて、かなり規模のでかいECサイトぐらいです。
Amazonや楽天レベルならまだしも、自分が関わるプロジェクトや顧客に
それほどまでのサイトになる案件はありません。
ですので、「開発しやすい1テーブルにまとめればいいんじゃね？」
って考えが浮かび、正規化しないパターンも考えているのです。
でも、昨日こちらに書き込んでから「正規化しても大した手間ではない」
と思い、分ける方向で行こうとしていますが・・。
0201NAME IS NULL
2015/03/26(木) 13:18:57.85ID:???削除フラグが嫌いな人が多いようで。
俺は好きだが。
0202NAME IS NULL
2015/03/26(木) 13:40:37.24ID:???> ですが、要件的には「1つの商品にカテゴリは1つ」であり、
だとすれば、複数テーブルに分割するのは正規化じゃないね。
顧客テーブルに性別があり、その性別を別のテーブルに分割することは可能だけど、それは正規化じゃない。
0203NAME IS NULL
2015/03/26(木) 14:31:45.45ID:???やりもしないで採用するかしないかを考えるのは
正規化のやり方わかりませんと言いたくないだけかと
0204NAME IS NULL
2015/03/26(木) 15:14:40.01ID:???immutableであるべき派だからこそ、削除フラグやNULLが許せなくてブログ書くから目立つのかもしれないが。
0205NAME IS NULL
2015/03/26(木) 15:38:03.79ID:???現時点の要件に対して十分に正規化されているかどうかだよ。
「もしこうなった場合に対応できないからこれは十分とはいえない」という考えを捨てるべき。
0206196
2015/03/26(木) 18:52:07.00ID:???そう思えるかどうかですね。どうしても良い設計を探求したくなるので・・・。
とりあえず>>203さんの言うように、一度正規化してから
「それでもやっぱり複数登録する必要はないか？」を考えて
最終的にどうするか考えます。みなさんアドバイスありがとうございました。
0207NAME IS NULL
2015/03/26(木) 19:01:56.56ID:???0208NAME IS NULL
2015/03/26(木) 21:09:25.29ID:???0209NAME IS NULL
2015/03/26(木) 23:11:56.48ID:???0210NAME IS NULL
2015/03/27(金) 03:19:23.75ID:???現在のテーブルレイアウトでは正規化が保てなくなる仕様変更が
あるかもしれませんがないかもしれません。どうしましょう？
こういう事だろ
好きにしろとしか言えんわ
0211NAME IS NULL
2015/03/27(金) 04:20:46.16ID:???俺もそう思うんだけど、>>199によると違うらしい。
>>199がそれ以降レスをしているかどうかは不明。
0212NAME IS NULL
2015/03/27(金) 06:56:20.34ID:???正規化がなんなのかわかってない可能性が大だけど。
0213NAME IS NULL
2015/03/27(金) 08:26:32.30ID:???日本語の勉強からやり直せよ
>>196
> 後の拡張を予測して、正規化しようか悩んでいます。
>>198
> 現状の要件では、1つのテーブルで十分正規化されてるってことでいいよね。
>>200
> >>198
> 十分はされていないと思います。
0214NAME IS NULL
2015/03/27(金) 09:30:12.46ID:???「現在の要件では正規化できているけど、要件が追加された場合を考えるべきでしょうか」
としか読めない気がするがね
「本人が十分ではないと思うとレスしたから正規化が不十分なんだ！」
と思ったのなら、煽りでなく真面目にアスペルガー症候群の疑いがある
現実でも人と揉めて苦しい思いをしているなら、一度心療内科に行った方がいい
0215NAME IS NULL
2015/03/27(金) 13:09:44.48ID:???対する実装はコストがかかるケースが多いし、その柔軟な設計に対する実装にバグがあったら、
その修正コストは誰が払うべきなんだという問題もある。
今回のケースでは、一つの商品に対して複数の商品カテゴリを登録できるようにしておく、というのが
仕様の変化を見越したモデリングだが、そうすると、JOIN結果が「常に1レコード」から「複数レコードも
ありうる」ということになり、それに対応したコードを書かなければならない。
一つの商品に対して複数のカテゴリを登録できるようにするという仕様に将来なったとき、結局
UI部分もビジネスロジック部分も変更しなければならないのだから、今そうしておく必要性は薄いと思う。
0216NAME IS NULL
2015/03/27(金) 13:57:32.04ID:???これが一番納得行く回答だね
0217NAME IS NULL
2015/03/27(金) 16:59:23.42ID:???本人がそう言ってるのはその通りだけど
その本人のレベルを推し量ると、ほんとにちゃんと正規化出来てるとは思えないフシはあるがな
だからって
>1つのテーブルで十分正規化されてるってことでいいよね。
という前提で回答したものに
>どうやったらこんな解釈ができるんだ？
というのも安定した低能君の反応だわなｗ
0218NAME IS NULL
2015/03/27(金) 23:40:13.30ID:???テンパってないか？
0219NAME IS NULL
2015/03/28(土) 08:30:17.45ID:???0220NAME IS NULL
2015/03/28(土) 08:33:02.47ID:???本人が正規化できてないと思ってるって言ってるけど「なんの根拠もないけどぼくは正規化されてると感じるんだ」ってか？ｗ
病院行ってもダメなレベルだから、そのまま引き籠っとけよ
0221NAME IS NULL
2015/03/28(土) 08:45:49.62ID:???設計側の視点だけで見てると、実装側の労力を見落とすことって多いよな
仕様変更を余儀なくされる可能性が高い訳でもないのに、勝手に先回りして
余計な事をしない方が良いと俺も思うわ
0222NAME IS NULL
2015/03/28(土) 10:49:35.55ID:???こえｒ名言だと思う
0223NAME IS NULL
2015/03/28(土) 14:18:27.04ID:???落ち着いてもう一回最初からレスを読み直してみたらどう。
0224NAME IS NULL
2015/03/28(土) 15:39:41.38ID:???それは君の方だろ...
>>196
> 後の拡張を予測して、正規化しようか悩んでいます。
現状正規化されてるなら、悩んだりしてないと思うぞ
0225NAME IS NULL
2015/03/28(土) 17:06:21.66ID:???既に書かれているように正規化をなにか勘違いしているんだろう。
0226NAME IS NULL
2015/03/28(土) 17:40:48.89ID:???0227NAME IS NULL
2015/03/28(土) 17:47:25.16ID:???その言い方だと、いま正規化されてなくても問題はないみたいだ
将来の仕様変更があろうが無かろうが、正規化はしておくのが普通だろう
0228NAME IS NULL
2015/03/28(土) 17:59:04.88ID:???> その言い方だと、いま正規化されてなくても問題はないみたいだ
ひとつのテーブルで足りるとか書いてるから、少なくとも >>196 は問題ないと考えてるんだろ
0229NAME IS NULL
2015/03/28(土) 18:36:53.09ID:???そこを引用した上で理解できないって末期だよ
0230NAME IS NULL
2015/03/28(土) 18:43:25.75ID:???満足してないから質問してくるわけで。
0231NAME IS NULL
2015/03/28(土) 18:46:38.21ID:???適性無い新人さんでも紛れ込んでんのか？
0232NAME IS NULL
2015/03/28(土) 18:54:55.90ID:???はいはい、ぼくちゃんなら（こんきょはないけど）こうかんがえるんだ
ってか？ｗ
0233NAME IS NULL
2015/03/28(土) 19:03:09.45ID:???>>225 は単なる憶測だし、意味のないレスにしか見えんが
0234NAME IS NULL
2015/03/28(土) 19:55:37.18ID:???0235NAME IS NULL
2015/03/30(月) 18:02:13.31ID:???> 今のテーブルを正規化して将来につなげるっておかしな考えなの？
主キーと1:1な関係の属性が、将来1:nになるかもしれないのを見越した設計を正規化とは言わないよ。
0236NAME IS NULL
2015/03/31(火) 11:18:45.16ID:???具体的に言えば、会員テーブルをログイン情報とプロフィールに分けるのと同じだよ。
0237NAME IS NULL
2015/03/31(火) 11:45:13.64ID:???0238NAME IS NULL
2015/03/31(火) 13:14:16.10ID:???「現状の要求仕様で、主キーと1:1な関係の属性を、将来1:nになるかもしれないのを見越して
別テーブルに分割する」ということを正規化とは言わないという趣旨。
つまり、元発言者は、正規化するかしないかの決断をしているわけではなくて、要求仕様の
弾力化をするかしないかの判断をしているということ。
ちなみに、俺はしない方が良いと思う。
1:nにも対応することに決めたときに、主キーと1:nな関係の属性のテーブルを分割することは
正規化だけれども。
0239NAME IS NULL
2015/03/31(火) 15:09:33.18ID:???じゃ、正規化してテーブル分けて1:1にしておき、後から複数登録が必要になった時、
それが出来るようにすればいいだけ。テーブル構成を変える必要もないし、
拡張コストもあまりかからない（ビュー側の変更だけ
0240NAME IS NULL
2015/03/31(火) 16:24:22.42ID:???> じゃ、正規化してテーブル分けて1:1にしておき、後から複数登録が必要になった時、
> それが出来るようにすればいいだけ。
だけじゃないから、余計なことはしない方が良いと言ってます。
items: {item_id, description, category_name}
あるいは、
items: {item_id, descritpion, category_id}
categories: (category_id, description}
とするのを
items: {item_id, description}
categories: {category_id, description}
item_category: {item_id, category_id}
と分割したとき、
あるitemのcategoryの内容を変更したり、itemを削除するときに、余計なコードが必要です。
また1:1であることを保証するのを、アプリケーション側、あるいはデータベース側の制約で実装する必要があります。
「1:1であることを保証する」コードは、1:nになったときには削除する必要があります。
さらに、コードで保証する場合、バグやマニュアルでitem_categoryデータを登録するとデータ全体に不整合が
起こり、1:1が前提のコードの部分で、最悪アプリが落ちる原因になるかもしれません。
0241NAME IS NULL
2015/03/31(火) 18:36:32.27ID:???素人もしくはエンタープライズかぶれのどちらかじゃないだろうかと思うことがある。
「かもしれない」と「これはありえない」の境界線をどこで引くのか見てみたいものだけれど。
0242NAME IS NULL
2015/03/31(火) 19:25:28.17ID:???0243NAME IS NULL
2015/03/31(火) 21:26:28.46ID:???ただ、その用語が正しくないって言うだけで
個人的には「1つしか登録しない」という顧客の発言を
「1つしか登録できない」と読み替えるかどうかは微妙なラインだと思うが
0244NAME IS NULL
2015/03/31(火) 23:40:53.52ID:???いなくなってしまったのがちょっぴりさみしい
0245NAME IS NULL
2015/03/31(火) 23:56:16.26ID:???0246NAME IS NULL
2015/04/01(水) 00:03:12.26ID:???0247NAME IS NULL
2015/04/01(水) 02:38:39.80ID:???A）メインテーブルに関連項目（カテゴリIDとか）を入れる
B）関連項目は別のテーブルに分ける
として、スタート時の要件は1対1とする。
この場合、Bで設計していたら1対多にするのは簡単だけど、Aにしてたら無理じゃないか？
メインテーブルのカラムを変えないといけないし、既に稼働してたら停止しなくちゃいけないぞ。
でも、BならUIやプログラム（SQL含む）の変更だけで済むから、テーブル設計を変えなくてもいい。
1対多であっても1つしか登録しないケースも有るわけで、
バグやデータ全体の不都合なんて起こらないと思うんだが。
0248NAME IS NULL
2015/04/01(水) 04:15:43.63ID:???>>240の構成を元にして話を進めるけど、
descriptionを複数持たせたいって要件が発生した時のことは気にしなくていいの？
0249NAME IS NULL
2015/04/01(水) 09:31:27.57ID:???それなら尚更分けるべきじゃね？
0250NAME IS NULL
2015/04/01(水) 09:36:44.48ID:???items: {item_id}
categories: {category_id, description}
item_category: {item_id, category_id,description}
itemのcategory毎にdescriptionを持たせたいならこうするべきだろ。
description以外のカラムを追加したい時もitem_categoryに追加すればいいし、
メインのitems・categoriesをいじる必要もない。
0251NAME IS NULL
2015/04/01(水) 10:49:49.21ID:???> >>240の構成を元にして話を進めるけど、
> descriptionを複数持たせたいって要件が発生した時のことは気にしなくていいの？
いやだから、そういう要件が発生したときに変更を行えって話で。
ノーコスト（に近いコスト）で、柔軟な設計にできるのならば、それでいいが。
あるいは、要件が変更になったときに、ノーコスト（に近いコスト）で対応できるなら、それをする価値があるかもしれない。
今回の話は、1:1が1:nになったとき、結局あちこち変更する必要があるんだから、そうなったときにデータモデルも
変えればいいでしょってこと。
>>250
items.descriptionは、item自身のdescription。
要するに、PK以外になにかの属性があるってことを示しているだけ。
0252NAME IS NULL
2015/04/01(水) 10:54:35.66ID:???最初から1:nにも対応できるモデルにしておくのもありかもしれない。
(*1) 多段階のレビューや承認が必要な場合や、データベースのマイグレーション
コストが高くて、簡単には変更できない場合など。
0253NAME IS NULL
2015/04/01(水) 11:10:15.96ID:???>items.descriptionは、item自身のdescription。
>要するに、PK以外になにかの属性があるってことを示しているだけ。
でもさ、実際に「登録したカテゴリに説明を加えたい」という要件が出るかもしれない。
その場合も中間テーブルがある事で柔軟な拡張が可能になるよ。
0254NAME IS NULL
2015/04/01(水) 13:09:28.74ID:???>>253
って事についても、要件が「複数カテゴリを登録させたい」になった時に
中間テーブルを作成すればいいだけだよ。
そしてitemsのカラムも削除しなくていい。そのまま使えば。
items内のitem_id、category_idをitem_categoryにコピーするのは簡単だし。
itemsのcategory_idは表示用のカテゴリにして
item_categoryのcategory_idは検索用とか複数選択用のカテゴリにすればいい。
正規化の概念からしたらitemsにcategory_idが残るのは気持ち悪く感じるかもしれないけど、
上記のように「表示用・検索用」と分けて考えるなら、有りだと思う。
0256NAME IS NULL
2015/04/01(水) 13:33:57.61ID:???ごめん、なんか勘違いしてた。
0257NAME IS NULL
2015/04/01(水) 19:22:34.91ID:???脳内変換君チース w
0258NAME IS NULL
2015/04/24(金) 16:14:48.74ID:???具体的には、日本酒なら「原料米」、「精米歩合」などの情報が必要で、
ワインならその情報は必要なく、代わりに「原料葡萄」、「パーカーポイント」などが必要。
それを、ひとつのテーブルにごちゃごちゃ入れるなら分ける必要ないけど、
日本酒、ワインに共通する「名称」や「メーカー」などは共通の1テーブルとし、「日本酒」、「ワイン」をそれぞれ別テーブルとした方がすっきりするかなぁ？
0259NAME IS NULL
2015/04/24(金) 20:46:26.40ID:???普通にお酒テーブル、日本酒属性テーブル、ワイン属性テーブル、... でいいかと
0260NAME IS NULL
2015/04/24(金) 21:11:55.72ID:???世界中で販売されてるアルコール類の総数なんて知れてるんだからアルコール類テーブルで良いかと
それにメーカーテーブル、製法テーブル、原料テーブル
どう分けるかは、結局のところ表示(データをどう扱うか)に依存すると思う
0261NAME IS NULL
2015/04/24(金) 21:15:09.31ID:???絞るならJSONとかでもいい
分ける必要は感じないかなぁ
0262NAME IS NULL
2015/04/25(土) 00:04:17.87ID:???それぞれメリット/デメリットあるので要件に応じて判断する。
0263NAME IS NULL
2015/04/28(火) 16:10:12.02ID:???みなさま、ありがとう！
0264NAME IS NULL
2015/05/09(土) 17:48:10.03ID:gMN7AwQoそれぞれ商品テーブルを扱う場合、どういう設計が適切ですか？
問屋が登録した商品を販売店に納品し、
販売店から消費者が商品を購入するイメージです。
悩んでいる部分を書くと、
1：問屋、販売店、消費者テーブルは3つに分けるのか1つのユーザテーブルにするか？
2：問屋と販売店は会社情報テーブルと結合させたい。
消費者は商品のレビューを投稿したいので、プロフィールテーブルと結合したい。
（それぞれ関係は1：1）
3：商品テーブルに問屋ID、販売店IDなどのカラムが必要か？
この3点が気になり、どんなテーブル設計にするか悩んでいます。
良いアイディアがあれば助言おねがいします。
0265NAME IS NULL
2015/05/09(土) 19:07:06.77ID:???何のためのＤＢなんだ？
>問屋、販売店、消費者テーブルは3つに分けるのか1つのユーザテーブルにするか？
その三つが、同一として扱わなければならない理由があるなら一つのテーブルもありかもしれん
>問屋と販売店は会社情報テーブルと結合させたい
すればいいんじゃね。何が疑問かわからん
問屋とか販売店とかの定義が固まってないのに会社情報テーブルとか
プロフィールテーブルとか出来上がってるのが謎だが
>商品テーブルに問屋ID、販売店IDなどのカラムが必要か？
商品が特定されたときに、自動的に問屋や販売店が特定されるなら必要かもしれんな
それ以外に必要な理由が浮かばん
なぜそのカラムが必要だと思ったんだ？何の情報を格納する気だ？
0266NAME IS NULL
2015/05/09(土) 20:17:47.90ID:gMN7AwQo>何のためのＤＢなんだ？
商品を販売管理するためのDBです。
分かりやすいように一般的な名称にしましたが、
具体的には以下のような意味合いです。
問屋＝メーカー
販売店＝メーカーが作った物を販売するお店、人
消費者＝それを購入する人
商品＝メーカーが作った商品
>>問屋、販売店、消費者テーブルは3つに分けるのか1つのユーザテーブルにするか？
>その三つが、同一として扱わなければならない理由があるなら一つのテーブルもありかもしれん
問屋、販売店、消費者ともに自分達の専用ページ（管理画面）があります。
その管理画面にて商品を登録したり、消費者なら購入履歴を閲覧できるイメージです。
つまり、ログインやら会員に関する部分は共通テーブルにした方が良いのかな？
と言った悩みです。
>>問屋と販売店は会社情報テーブルと結合させたい
>すればいいんじゃね。何が疑問かわからん
1のユーザーテーブルを3つにするか1つにするかで結合方法や設計が変わります。
だからどうすればいいか悩んでおります。
会社情報やらプロフィールやらのテーブルが必要だというのは決まっています。
>>>商品テーブルに問屋ID、販売店IDなどのカラムが必要か？
>なぜそのカラムが必要だと思ったんだ？何の情報を格納する気だ？
メーカーや販売店は自分の商品がいくつ売れたのか？を知りたいです。
商品の販売状況が分かれば、仕入れを変更できます。
そして商品に販売店IDがあれば、「どこの店のどの商品が売れてるのか？」
というのを消費者にアピールする事が出来ます。
0267NAME IS NULL
2015/05/09(土) 22:11:43.81ID:???【小規模】
問屋＋販売店＋消費者テーブル：ユーザID
商品テーブル：商品ID、ユーザID
流通テーブル：商品ID、販売元ID（ユーザID）、販売先ID（ユーザID）、注文日、料金、出荷日、到着日、等々
履歴テーブル：商品ID、販売元ID（ユーザID）、販売先ID（ユーザID）、注文日、料金、出荷日、到着日、等々
【中大規模】
問屋テーブル：問屋ID
販売店テーブル：販売店ID
消費者テーブル：消費者ID
商品テーブル：商品ID、問屋ID
流通＿仕入れテーブル：商品ID、販売店ID、注文日、料金、出荷日、到着日、等々
流通＿販売テーブル：商品ID、販売店ID、消費者ID、注文日、料金、出荷日、到着日、等々
仕入れ履歴テーブル：商品ID、販売店ID、注文日、料金、出荷日、到着日、等々
販売履歴テーブル：商品ID、販売店ID、問屋ID、注文日、料金、出荷日、到着日、等々
予算・規模・画面・速度を加味して上から選ぶ感じで
何かの手違いで消費者情報が洩れるとまずいので、できれば分ける方が良い
0268NAME IS NULL
2015/05/09(土) 22:55:03.47ID:???>ログインやら会員に関する部分は共通テーブルにした方が良いのかな？
会員って何かしらんが、それが販売店と消費者を同一に扱う理由になるのか？
ログインを共通にしたければすれば良いけど、それと販売店と消費者が同一かどうかとは別の話
>会社情報やらプロフィールやらのテーブルが必要
情報が必要なのが決まってるってならわかるが
>1のユーザーテーブルを3つにするか1つにするかで結合方法や設計が変わります
のに、テーブルが決まってるのはおかしくないの？
まあ、決まってるなら別に悩む必要もないだろ。分けたら分けた各テーブルに
わけなかったらその一つのテーブルに結合すれば良いだけだし
>メーカーや販売店は自分の商品がいくつ売れたのか？
自分の商品って何だ？
商品によってメーカーが決まるなら、商品にメーカー情報を持つのはありだけど
商品を売った所がどこかと言うのは、商品を売ったと言う情報に持たせる必要があるんだが
商品に販売店IDがあるということは、商品が決まれば販売店が決まると言う事だぞ
つまり一つの商品はかならず一つの販売店でしか取り扱わないと言う事だぞ
0269NAME IS NULL
2015/05/09(土) 23:37:17.85ID:gMN7AwQo詳しく想定していただきありがとうございます。
小規模だと1つのユーザテーブルにして、
中大規模だと分けるというのは考えていませんでした。
次のレスにも記載しますが、
ユーザテーブルを分けると、関連するテーブルもその数分、必要になる気がして
一緒にした方が良いのかな？と悩んだりしております。
0270NAME IS NULL
2015/05/09(土) 23:41:43.79ID:gMN7AwQo>会員って何かしらんが、それが販売店と消費者を同一に扱う理由になるのか？
誰でも問屋や販売店になれるシステムではなく、
商品購入などの履歴を見たりしたいので、会員機能が必要です。
それを勝手に分かってもらえると思い込んでいました。すみません。
ログインID（またはメールアドレス）、パスワードにて専用画面にログインし、
問屋は問屋用のメニューを、販売店は販売店用のメニューを、
消費者は消費者用のメニューを利用します。
ということは、「メールアドレス認証テーブル」「パスワード再発行テーブル」
などの会員制サービスによくあるテーブルが、ログイン対象分必要になってしまいます。
3つのユーザ×関連テーブルとなるため、テーブル数が増えすぎます。
もちろん、「テーブル数が増えることなんて気にしなくていい」
という事ならそうなのでしょうが、それで良いのかと思い、質問した次第です。
>自分の商品って何だ？
>>264に書きましたが、問屋は自分が商品データを登録するわけです。
販売店は問屋から商品を仕入れます。
自分（問屋や販売店）が扱う商品がどの程度売れるのか見たい、という意味です。
>商品に販売店IDがあるということは、商品が決まれば販売店が決まると言う事だぞ
それは問題無いです。例えばシャープのテレビがあったとして、
それをヨドバシカメラに納品し、山田太郎さんが買ったとします。
その段階で、問屋（メーカー）であるシャープはどこの販売店が
テレビの売上がいいか調べる事が出来ます。
販売店もどこの問屋のテレビが売れるか調べる事が出来ます。
それが分かれば、今度からはその問屋から多く仕入れよう、となるわけです。
>つまり一つの商品はかならず一つの販売店でしか取り扱わないと言う事だぞ
問屋が別の販売店に同じ商品を納品する時は、
商品データを複製追加するのはおかしいですかね？おかしいですね。。
上記で記載したように、「商品がどの販売店で売れて、それはどこから納品されたのか？」
を知る設計が必要なのですが、具体的に分かりません。
0271264
2015/05/10(日) 00:11:50.57ID:???もしかして以下のような設計が良いんですかね？
これなら過度にテーブルは増えないし、
他のテーブルを作って結合する必要がない気もします。
問屋テーブル：ID、メールアドレス、パスワード、会社名、担当者名、住所・・・etc
販売店テーブル：ID、メールアドレス、パスワード、会社名、担当者名、住所・・・etc
消費者テーブル：ID、メールアドレス、パスワード、ニックネーム、名前、住所・・・etc
パスワード再発行テーブル：問屋ID、販売店ID、消費者ID、識別コード、日付
メールアドレスの認証テーブル：問屋ID、販売店ID、消費者ID、識別コード、日付
消費者（ID：1）がパスワード再発行の申請をした時に追加されるレコード
NULL｜NULL｜1｜Adu1e5sQ｜2015-05-10
0272NAME IS NULL
2015/05/10(日) 05:38:13.34ID:???小規模低予算なら作り手がサクッと作る
大規模なら高額プロにお任せ
ここに書き込んでいる時点で経験が浅いよね。
だから上に書いたのをヒントに自分がやり易いようにやるのが最適解だよ。
データ不備が見つかったら修正で良いじゃない
0273NAME IS NULL
2015/05/11(月) 00:12:04.01ID:???■認証関係
ログインテーブル（メールアドレスとかパスワードとか有効フラグとか）
パスワード再発行テーブル
メールアドレスの確認テーブル
■利用者
問屋テーブル：問屋ID、ログインID
販売店テーブル：販売店ID、ログインID
消費者テーブル：消費者ID、ログインID
みたいな感じでデータを保持すれば何も問題ないでしょ。
仮に代理店とか修理屋とか利用者が増えても過度にテーブルが増えない
0274NAME IS NULL
2015/05/11(月) 00:15:38.75ID:???メールアドレスの確認テーブル
これ用意する意味わからん
0275NAME IS NULL
2015/05/11(月) 00:23:26.13ID:???販売情報：販売店ID、商品ID、販売先ユーザID、販売日
とか
購入情報：ユーザID、購入日、販売店ID、商品ID
のようなテーブルを作ればいいよ。
> それはどこから納品されたのか？
これについては、問屋(メーカー)という表記がとても気持ち悪いので、真意が読めないけれど
メーカーであるとするならば、商品情報にメーカーは含まれるはずだから問題ない。
本来の意味である問屋だとするならば、ある商品について
仕入れ情報：どの問屋から何個仕入れたか
という情報は必要だろうけれど、どの問屋から仕入れたものを誰に売ったかというのは意識しないでしょ。
トレーサビリティを持たせるなら話は変わるけれど、それなら商品各個にシリアルを持たせなければならない。
0276NAME IS NULL
2015/05/13(水) 11:54:15.05ID:???正規化にこだわって1対1なのに2つのテーブルに分けたら、
参照する時は（ほぼ）必ず2つのテーブルにアクセスする事になったから、
やっぱり1つのテーブルにまとめた方が良い、とかよくある。
0277NAME IS NULL
2015/05/13(水) 11:58:03.94ID:???0278NAME IS NULL
2015/05/13(水) 12:29:03.69ID:???> 正規化にこだわって1対1なのに2つのテーブルに分けたら
意味がわからん
0279NAME IS NULL
2015/05/13(水) 14:38:29.42ID:???0280NAME IS NULL
2015/05/13(水) 15:09:17.66ID:???0281NAME IS NULL
2015/05/13(水) 15:44:59.49ID:???> よくある。
ざっくりでいいので、母数と割合がどれくらいか教えてもらえる？
あと、よくあるにも関わらず何度も同じ轍を踏むのはなんで？
0282NAME IS NULL
2015/05/13(水) 16:33:09.77ID:???0283NAME IS NULL
2015/05/13(水) 16:51:46.65ID:???横だけど、そんなもん個人の範疇以外で答えられんだろw
0284NAME IS NULL
2015/05/13(水) 17:41:33.72ID:???> 正規化にこだわって1対1なのに2つのテーブルに分けたら、
それは、何正規形にしようとして分割したんだ？
0285NAME IS NULL
2015/05/13(水) 18:22:14.36ID:???0286NAME IS NULL
2015/05/13(水) 18:48:54.50ID:???俺なんて10年MySQL使った実務してるけど、今でも悩みまくるもん。
1つの案件で3ヶ月は悩む。悩みすぎて仕事干されるレベル。
0287NAME IS NULL
2015/05/13(水) 19:32:51.19ID:???世の中広いとおもた w
0288NAME IS NULL
2015/05/13(水) 20:28:23.42ID:???0289NAME IS NULL
2015/05/13(水) 20:50:32.73ID:???0290NAME IS NULL
2015/05/13(水) 22:23:28.15ID:P11X/PnAよかったら、見てみて。
https://blngs.com
0291NAME IS NULL
2015/05/14(木) 03:55:30.94ID:???そうだよ。
「よくある」って体感してる人は、どのくらいの割合で遭遇するのか知りたいんだよ。
個人の範疇として聞きたいんだけど>>283は学習中を除いて>>276の状況に一度でもなったことがある？
0292隼人新聞社
2015/05/14(木) 12:23:52.49ID:NhtWk18J●宅間守（在日部落）→大阪 附属池田小学校児童殺傷 。大量殺人犯 創価学会員の犯行 両親も創価学会員
８人殺害 １５人を殺傷。 朝鮮人部落出身。
●斉藤勇太→ＪＲ取手駅前バス無差別殺傷通り魔事件（取手バスジャック） 創価学会員の犯行
「通勤、通学客で混雑するバスの中で手加減せず無差別に襲っており、社会に大きな不安や衝撃を与えた結果は重大だ」
●酒鬼薔薇聖斗→ 東慎一郎（在日）神戸の首切り魔で酒鬼薔薇聖斗 神戸の首切り魔。生首を校門に飾る。２人殺害。創価学会員の犯行 大量殺人犯
●福田孝行（在日）→山口県母子強姦殺害 殺害後屍姦、乳児も殺害 大量殺人犯 創価学会員の犯行。裁判では屍姦は
生き返らせるための（創価流の）儀式だと供述 死刑判決
● 大芦明 →2011年 11月5日 大阪府堺市中区 隣人二名殺害事件。創価学会員の犯行 無期懲役
●八木茂 →埼玉・保険金殺人事件犯人 ２名殺害（平成12年）死刑判決 創価学会員の犯行
●武まゆみ→、埼玉・保険金殺人事件犯人 ２名殺害（平成12年）無期懲役 創価学会員の犯行
●森田考子→埼玉・保険金殺人事件犯人 ２名殺害（平成12年）共犯者で懲役13〜15年の判決 創価学会員の犯行
●柏市連続通り魔殺傷事件X強盗殺人 創価学会員の犯行の犯行
●引寺利明 →マツダ宇品工場ファミリア暴走連続殺傷事件 引き殺しで1人死亡、11人を殺傷 創価学会員の犯行
●織原城二(金聖鐘) → ルーシー・ブラックマンさん事件 創価学会員の犯行 10人の女性に強姦又は強制わいせつ 内2人の女性が死亡
●山口芳寛 →熊本3才女児遺棄事件。レイプ 創価学会員の犯行。幼女に熱い視線、女児が大好き 強姦殺人無期懲役
●内柴正人→柔道金メダリスト（連続）強姦事件 （2009.5.15付 聖教新聞） 創価学会員の犯行
●アクリフーズ毒入り大量殺人事件 創価学会員の犯行
●リサイクルショップエース大量殺人事件 連続殺人！５人以上を殺して埋める 創価学会員の犯行
0293NAME IS NULL
2015/05/14(木) 14:52:03.10ID:???maji uzai
0294NAME IS NULL
2015/05/14(木) 18:47:29.97ID:???そんな反応を示すってことは、通常の設計から道を外れているからじゃないのかなぁ。
普通に設計してる人は、そんな状況にならんで終わる話だもの。
0295NAME IS NULL
2015/05/14(木) 21:34:28.09ID:???俺は知りたいとは思わないが？
0296NAME IS NULL
2015/05/14(木) 22:05:02.81ID:???横だけど、通常の設計から道外れてるから質問するんじゃないのか？
設計に自信持ってたら端から質問しないだろw
0297NAME IS NULL
2015/05/14(木) 22:20:44.83ID:???0298NAME IS NULL
2015/05/14(木) 23:41:00.41ID:???横だが
よくあるがどれくらいの頻度か分からんが、母数と割合がどれ位とか聴くのはアホかとは思うけどな
ちな、俺も珍しくはない頻度で見かけるわ
将来の拡張性を謳うもそもそも使わない、予算つかないがゆえ1対1の2テーブル等々（笑）
0299NAME IS NULL
2015/05/15(金) 00:09:14.83ID:???何であなたも知りたいでしょって言われたかのような反応をしてるんだろう。
そんなところに同意は求めていないよ。
>>296
>>276経験を語っているだけで質問をしているようには見えないよ。
>>298
そういう理由なら納得するよ。
その必要のない拡張性を事前に実装し、メンテし続けることで発生するコストを考えれば損だろうけれど。
0300NAME IS NULL
2015/05/15(金) 01:15:31.50ID:???って理由で分けたくなる時がある。
この”なんとなく”って個人の主観でしか無いけど、割と重要な気がする。
んで、メンテし続けることで
「毎回JOINしてて面倒くさいよな」とか
「1つのテーブルでもそんなに使い勝手変わらないよな」
って気づいて一緒にしちゃうことも。
0301NAME IS NULL
2015/05/15(金) 11:06:40.94ID:???0302NAME IS NULL
2015/05/15(金) 11:14:39.67ID:???> 普通に設計してる人は、そんな状況にならんで終わる話だもの。
いやだから、普通に設計できないアホのこと知ってどうすんだよ？
そのアホの勘違いした俺理論でも聞いて、んでどうすんのさ？
0303NAME IS NULL
2015/05/15(金) 14:42:12.10ID:???↑
馬鹿
0304NAME IS NULL
2015/05/15(金) 14:57:02.21ID:???0305NAME IS NULL
2015/05/15(金) 15:09:08.74ID:???0306NAME IS NULL
2015/05/15(金) 15:10:44.12ID:???学んでても案件や要件によって難しくなると思うけど
0307NAME IS NULL
2015/05/15(金) 15:57:39.51ID:???別に学ばずともリレーショナルモデルを構築できたり、正規化理論と同等のものを編み出せるならいいよ。
普通は学ぶ方が速いが。
0308NAME IS NULL
2015/05/15(金) 16:12:37.02ID:???人間性をまず正規化してほしいね。
0309NAME IS NULL
2015/05/15(金) 16:32:27.17ID:???0310NAME IS NULL
2015/05/15(金) 16:42:46.56ID:???0311NAME IS NULL
2015/05/15(金) 16:44:02.25ID:???0312NAME IS NULL
2015/05/15(金) 17:00:39.30ID:???0313NAME IS NULL
2015/05/15(金) 17:15:44.24ID:???0314NAME IS NULL
2015/05/15(金) 17:54:03.81ID:???> 単純に「1つのテーブルにカラムが20も30もあるとなんとなく嫌」
> って理由で分けたくなる時がある。
> この”なんとなく”って個人の主観でしか無いけど、割と重要な気がする。
そのなんとなくは、異なる二つのエンティティじゃないかと思うってことじゃないか？
だとしたら、正規化は関係ない。
一部のカラムの更新が激烈で性能要件が厳しい場合、正規化以外の理由で分割することもあるかもしれん。
俺はそういうのにはあたったことないから想像だが。
0315NAME IS NULL
2015/05/16(土) 00:10:11.61ID:???＞そういう理由なら納得するよ。
何でお前みたいな知恵遅れを納得させないといけないんだよバーカ（笑）
0316NAME IS NULL
2015/05/16(土) 02:34:31.57ID:???0317NAME IS NULL
2015/05/16(土) 03:31:25.38ID:???他の人がわざわざ煽る理由はないもんね
0318NAME IS NULL
2015/05/16(土) 11:51:57.29ID:???>>315と>>298は俺で、>>276は他人な
なぜ一緒にしたがるのか…>>299が知恵遅れの馬鹿だからw
0319NAME IS NULL
2015/05/16(土) 14:58:17.38ID:???論理的に考えられるなら、どういうレスすればいいか分かるだろうに
0320NAME IS NULL
2015/05/16(土) 18:24:36.50ID:???0321NAME IS NULL
2015/05/16(土) 18:42:17.07ID:???0322NAME IS NULL
2015/05/21(木) 18:13:39.48ID:pzhWHvsu生徒の親御さんとやりとりするシステムを作ろうと思います。
要件は
・管理者（私とバイト仲間のAさん）と会員（親御さん）がログイン出来る会員制サイト
・1スレッド（質問）に対して、管理者と会員が投稿していく
・質問が解決すると、「済」になる（フラグ指定）
・投稿があるとメールが管理者と会員に送信される
・会員のプロフィール（傾向とか重視している科目とか）を設定したい
というのを構想しているのですが、テーブル設計で悩みます。
そんなに大きくするつもりはないのですが、以下のもので大丈夫でしょうか？
似たようなシステムを設計した事がある方がいましたら、アドバイス下さい。お願いします。
管理者テーブル、会員テーブル、会員プロフィール、
掲示板マスタ、掲示板メッセージ、メール送信テーブル
0323NAME IS NULL
2015/05/21(木) 18:25:16.95ID:???テーブル名だけじゃなくて、せめて主な項目ぐらい書けよ
>会員テーブル、会員プロフィール
とか、それぞれ何のテーブル何だ
>掲示板マスタ、掲示板メッセージ
もそれぞれ何持ってるテーブルかわからん
0324NAME IS NULL
2015/05/21(木) 18:36:57.02ID:???0325NAME IS NULL
2015/05/21(木) 18:42:02.79ID:???ご自身で開発する理由はおありでしょうか？
もしなければ無料のサービスをお探しになられた方がよろしいと思いますよ
0326322
2015/05/21(木) 18:42:22.20ID:pzhWHvsuすみません。以下の想定でいます。（書き方は過去レスを参考にしました）
掲示板マスタとメッセージのところは自信ないです。おかしくならないか心配です。
■管理者テーブル（質問を受ける講師）
ID｜ログイン名｜パスワード｜権限｜名前｜自己紹介｜登録日
■会員テーブル（質問をする人。主にログイン部分）
ID｜メールアドレス｜パスワード｜登録日｜削除フラグ
■会員プロフィール（質問をする人の詳細な情報。後から増やす予定）
会員ID｜名前｜性別｜生年月日｜住所｜得意科目｜苦手科目｜管理者メモ
■掲示板マスタ（会員が管理者に質問する）
ID｜会員ID｜管理者ID｜タイトル｜内容｜登録日｜解決日
■掲示板メッセージ（会員が管理者に質問する内容）
掲示板マスタID｜会員ID｜管理者ID｜内容｜登録日｜確認日
■メール送信テーブル（メッセージ投稿があるとメール送信）
ID｜会員ID｜管理者ID｜送信日
0327322
2015/05/21(木) 18:45:16.50ID:???結構親御さんから電話で質問されるのですが、
電話だけなので「言った・言わない」が発生して怒られる事があります。
ですので、簡単に投稿を管理できるものが欲しくて探していました。
無料サービスでは家庭教師向けの物がありません。
Web制作会社に依頼すると100万以上と言われたので、お金がないです。
仲間内と理解のある親御さんの間で使う予定なので、
簡易的でいいのですが、後からバージョンアップ出来るようなのを想定しています。
0328NAME IS NULL
2015/05/21(木) 18:46:36.96ID:???まぁ、一番気をつけるべきはセキュリティ。
個人情報満載のものを、全世界から参照可能なインターネットという場所に配置することのリスクはしっかり考えようね。
0329322
2015/05/21(木) 18:52:33.21ID:???クローズドのサイトなので、知らない人がアクセスはないと思いますが、
SQLインジェクションやクロスサイトスクリプティングなど必要な対策はします。
それ以外で、DB設計について「セキュリティ的にこうすればいいよ」があれば教えて下さい。
0330NAME IS NULL
2015/05/21(木) 18:55:10.05ID:???どういうこと？会員のみが利用できるVPNでも作るのかな
0331322
2015/05/21(木) 19:06:41.80ID:???>>322にも書きましたが、会員のみがアクセスできる会員制サイトです。
アクセス方法はPC・スマホからを予定しています。
ですので、設計の相談をお願いしたいのですが・・・
0332NAME IS NULL
2015/05/21(木) 19:14:05.86ID:???そういうところを踏まえて100万は盛りすぎだけど、ある程度のお金がかかるもんなんですよ。
テーブル設計でいえば別にそれでいいんじゃないの。
メール送信テーブルはメール送信フラグとして会員テーブルか会員プロフィールに持たせてもいいかもね。
管理者IDがあちこちについてる理由がわからないけれど、何か意図があるんだろうから深追いしない。
0333NAME IS NULL
2015/05/21(木) 20:29:47.93ID:rmOhpwWV設計はとりあえずどうでもいい部類
0334NAME IS NULL
2015/05/21(木) 21:44:59.05ID:???それよりWEB知識が豊富過ぎてヤバイ
0335NAME IS NULL
2015/05/21(木) 23:27:19.03ID:???ログインは管理者と会員でわけるのか？
管理者と会員と一つにのテーブルで良いんじゃないのか
掲示板マスタと掲示板メッセージも良くわからんな
両方に管理者IDとかあるけど、それ本当に両方に必要か？
１スレッドで複数の管理者向けの内容を混在させるのか？
メール送信テーブルも、その項目だけなら存在理由がわからん
メッセージを識別できるようにしないとダメなんじゃないのか
0336NAME IS NULL
2015/05/22(金) 01:47:35.63ID:???「本当にそれで良いのか？」って聞いても本人は答えられないと思うぞw
0337NAME IS NULL
2015/05/22(金) 08:56:53.90ID:???投稿者IDみたいなの作ればいいだけだろ
0338NAME IS NULL
2015/05/22(金) 13:39:11.84ID:???ユーザの一人が管理者になるのにね
0339NAME IS NULL
2015/05/22(金) 14:41:58.54ID:???いや、こんな感じじゃないか？
・佐藤さん(会員)がログインする
・掲示板で高橋講師に質問する
・鈴木さん(会員)がログインする
・掲示板で斉藤講師に質問する
・高橋講師がログインする
・自分宛の質問を確認する
・斉藤講師がログインする
・自分宛の質問を確認する
※講師と会員はログイン経路が違うんじゃないか。
※講師は掲示板で質問はしない（回答者する）
0340NAME IS NULL
2015/05/22(金) 14:43:18.94ID:???(正) ※講師は掲示板で質問はしない（回答はする）
0341NAME IS NULL
2015/05/22(金) 14:44:35.06ID:???>>335 宛てのコメント。
0342NAME IS NULL
2015/05/22(金) 15:00:24.49ID:???管理者はログイン名とパスワードだけど、会員はメールアドレスとパスワードだ。
つまり会員種別で講師と生徒が分けるのではなく、テーブル要件そのものが違う。
これを1つにして、会員IDでメッセージ管理しろって無茶苦茶すぎる
0343NAME IS NULL
2015/05/22(金) 20:47:30.78ID:???> ・投稿があるとメールが管理者と会員に送信される
管理者もメールアドレス必要なんだから合わせればいいじゃん
0344NAME IS NULL
2015/05/22(金) 22:26:54.71ID:???合わせろって、>>326を引用するとこうしろってことか？
■利用者テーブル
ID｜ログイン名｜メールアドレス｜パスワード｜登録日
■管理者テーブル
ID｜利用者ID｜権限｜名前｜自己紹介
■会員プロフィール
ID｜利用者ID｜名前｜性別｜生年月日｜住所｜得意科目｜苦手科目｜管理者メモ
どうなんだこれ？逆にややこしくなってねーか？
会員が利用者テーブルに登録するとき、ログインIDがNULLになるんだぞ
0345NAME IS NULL
2015/05/22(金) 22:28:14.30ID:???0346NAME IS NULL
2015/05/22(金) 23:35:24.51ID:???0347NAME IS NULL
2015/05/23(土) 00:05:08.46ID:???0348NAME IS NULL
2015/05/23(土) 00:21:12.95ID:???0349NAME IS NULL
2015/05/23(土) 03:20:03.20ID:???0350NAME IS NULL
2015/05/23(土) 03:40:40.41ID:???> 逆にややこしくなってねーか？
ややこしくしたのは誰なのやら
0351NAME IS NULL
2015/05/23(土) 08:51:11.95ID:???スレ{ID, 講師垢ID, 質問者垢ID, タイトル, 解決フラグ}
レス{スレID, 質問・回答内容}
0352NAME IS NULL
2015/05/23(土) 10:06:12.46ID:???レスの順序は重要だし、昔の話は意味がないとかもあるから、日時を入れた方がいい
0353NAME IS NULL
2015/05/23(土) 11:29:13.36ID:???誰がレスしたのか分からなくね？
0354NAME IS NULL
2015/05/23(土) 11:33:44.21ID:???でも、編集とか削除はレスIDが無いと出来ないと思う。
日付はいらなくてもIDで昇順・降順出来るし。
0355NAME IS NULL
2015/05/28(木) 00:45:10.42ID:f3gKlyUBなんか1つのプロジェクトに100以上のテーブルがあると
それだけで駄目な設計にされそうで、減らそうとしてしまいがちです。
typeとかstatusのカラムを作って同じテーブルで管理したり。
0356NAME IS NULL
2015/05/28(木) 03:43:35.29ID:???100以上の異なる要素って何なのかが気になる
0357NAME IS NULL
2015/05/28(木) 11:34:09.03ID:???マスタテーブルをDBに入れてると100以上は行きます。
郵便番号、都道府県、職業、連絡方法、支払い方法、配送方法、ステータス
などはよく使うのではないでしょうか。
0358NAME IS NULL
2015/05/28(木) 11:38:51.83ID:???0359NAME IS NULL
2015/05/28(木) 11:40:53.77ID:???全部書き出せというのですか？
0360NAME IS NULL
2015/05/28(木) 11:57:27.40ID:???0361NAME IS NULL
2015/05/28(木) 12:48:35.94ID:???「テーブルを減らすとダメな設計ではなくなる」と、
どうして思ったのかをまずは説明してみよう
0362NAME IS NULL
2015/05/28(木) 13:00:49.82ID:???でも、それは私が教えて欲しいこととは違いますよ？
>>361
単純に視認性が良くなる、テーブル構成が把握しやすく、
開発時のバグや不具合のリスクを減らせると思ったからです。
0363NAME IS NULL
2015/05/28(木) 13:26:48.28ID:???0364NAME IS NULL
2015/05/28(木) 14:00:08.44ID:???> 開発時のバグや不具合のリスクを減らせると思ったからです。
ひとつ言えることは、typeとかstatusとかflagとか入りのテーブルが多くなればなるほど、
開発時のバグや不具合のリスクは高くなるよ。
0365NAME IS NULL
2015/05/28(木) 14:35:13.59ID:???『SQLアンチパターン』読むのがお薦め。
0366NAME IS NULL
2015/05/28(木) 14:50:19.56ID:???別に君への説明のためじゃなくて疑問に思ったから聞いてみただけだろ。
100以上が嘘だと思ってるから疑問に思っただけで、答えたくなけりゃ答えなくていいんだよ。
0367NAME IS NULL
2015/05/28(木) 15:04:24.42ID:???そんなシステムのDB設計にかかわるような奴が
こんなとこでそんな質問するとも思えんしな
0368NAME IS NULL
2015/05/28(木) 15:10:43.56ID:???0369NAME IS NULL
2015/05/28(木) 15:12:48.05ID:???大変ためになるご意見ありがとうございます。
statusやflagは主に有効・無効で使うのですが、
typeはそのデータの種類を現すときに使う場合が多く、
そうなるとおっしゃるように開発時のバグや不具合のリスクは高くなりますね。
というわけでやはりテーブルを分けます。
あと、>>365も見てみます。ご意見ありがとうございました。
0370NAME IS NULL
2015/05/28(木) 15:42:12.67ID:???> statusやflagは主に有効・無効で使うのですが、
その有効・無効にstatusやflagを使うのが良くない場合がある。
ちょっと前にWebで論争になったりした。（「削除フラグ」でググる）
また、この話は『理論から学ぶデータベース実践入門』でも詳しく解説されている。
http://gihyo.jp/book/2015/978-4-7741-7197-5
の目次参照。
> 第9章 履歴データとうまく付き合う
0371NAME IS NULL
2015/05/29(金) 18:39:41.87ID:???id:option_name:option_value:sort
1｜pref｜北海道｜1
2｜pref｜青森県｜2
・・・
50｜payment｜銀行振込｜1
51｜payment｜郵便振替｜2
みたいな。wordpressがこんな事してる。
0372NAME IS NULL
2015/05/30(土) 02:23:42.08ID:???あり得ない例えだと説得力ない（笑）
0373NAME IS NULL
2015/05/30(土) 11:42:13.78ID:???「wordpressがこんな事してる」ってあり得る話してるのに、あり得ない例え？？？？
0374NAME IS NULL
2015/05/30(土) 13:30:37.27ID:???質問です。
その例ではprefがoptionカラムにありますよね。その例ではそうそう増えることは確かにないでしょうけど、
1から49までの間に収まっている保証がないものだったらどうするんです？
続いているやつを後ろにずらす？
当然プログラム側でも対応が必要になりますよね
0375NAME IS NULL
2015/05/30(土) 14:10:48.10ID:???ID番号が1〜49に納まってるかどうかなんて関係ないよ。
マスタデータとして、1つのテーブルで共通となる値を管理するって仕様だから。
疑問に思うならwordpress見ればいいだけじゃん。
0376NAME IS NULL
2015/05/30(土) 14:20:27.30ID:???# 都道府県を選択させるデータがほしい
SELECT optin_name,option_value FROM options WHERE option_name='pref' ORDER BY sort
このSQL文から「都道府県だけのデータ」を抽出できるよね？
後はPHPを使ってHTMLの選択リストを作成するときは
echo '<select name="pref">';
while($row = mysql_fetch_array($result)) {
echo '<option value="' . $row['id'] . '">' . $row['option_value'] . '</option>';
}
echo '</select>';
こうやればいいだけじゃないの。
都道府県を後から追加しようがIDが変わるだけだし、何が問題かわからん。
0377NAME IS NULL
2015/05/30(土) 14:52:46.58ID:???0378NAME IS NULL
2015/05/30(土) 14:59:39.81ID:???0379NAME IS NULL
2015/05/31(日) 01:56:58.12ID:???限定的な用法だけどありだよね。
10レコードにも満たないテーブルを選択肢ごとにたくさん作るよりいい。
0380NAME IS NULL
2015/05/31(日) 09:55:36.88ID:???キーワードや各種設定値ならありだけど、完全な固定の都道府県を混ぜ混ぜするのはどうかと思うわ
0381NAME IS NULL
2015/05/31(日) 13:59:03.47ID:???それはそれで意味のわからん設計思想だな
0382NAME IS NULL
2015/05/31(日) 16:39:24.43ID:???一度入れればまず更新が無いだろ
上のマスターは色々ありそうだし
0383NAME IS NULL
2015/05/31(日) 17:05:41.82ID:???いや、だから更新するものと更新しないものを別々にしたい意図がわからん
超でかいテーブルでインデックスの更新したくないとかならまだわからんでもないが...
0384NAME IS NULL
2015/05/31(日) 18:10:39.40ID:???でも、都道府県やら性別やら元号やらは同じテーブルで管理すればいいよ。
それに都道府県の場合、変わる可能性ないって言うけど、
英語サイト用に「東京都→TOKYO」にしたい場合、更新する可能性もあるじゃん。
0385NAME IS NULL
2015/06/01(月) 00:46:50.40ID:???0386NAME IS NULL
2015/06/01(月) 09:32:16.82ID:???で爆速読み書きしようという崇高な思想があるんですね、わかります。
0387NAME IS NULL
2015/06/01(月) 10:19:11.45ID:???0388NAME IS NULL
2015/06/01(月) 13:51:19.72ID:???0389NAME IS NULL
2015/06/01(月) 15:48:34.63ID:???性別は増えることはないだろうけど、元号は確実に増えていくので、プログラム埋め込みだと元号が変わったら、プログラム変更必須になりますよね。
0390NAME IS NULL
2015/06/01(月) 16:33:12.31ID:???元号が変わることを予測したシステムを作るなんてとんでもない。
という考えの時代に生きている人かもしれない。
0391NAME IS NULL
2015/06/01(月) 16:42:37.97ID:???って考え方もあるにはある
0392NAME IS NULL
2015/06/01(月) 16:54:14.97ID:???> プログラム埋め込みだと元号が変わったら、プログラム変更必須になりますよね。
変更すればええやん
0393NAME IS NULL
2015/06/01(月) 16:55:00.20ID:???> 性別は増えることはないだろうけど、
性別も男/女固定とは限らない
0394NAME IS NULL
2015/06/01(月) 17:00:45.25ID:???0395NAME IS NULL
2015/06/01(月) 17:40:17.89ID:???0396NAME IS NULL
2015/06/01(月) 18:38:23.19ID:???男→Man、男の子、ボーイ
女→Woman、女の子、ガール
とかさ。プログラムだと毎回設定ファイルいじる気か？
0397NAME IS NULL
2015/06/01(月) 18:51:16.57ID:???少し考えればよく問題になるいわゆる汎用テーブルではないことに気づけそうなもんだが。
0398NAME IS NULL
2015/06/01(月) 23:40:16.35ID:???先輩から「お前、会員が増える事にテーブルを増やす気か？」って言われて
1つのテーブルにまとめ直した事がある。>>371みたいな設計ではないけど。
0399NAME IS NULL
2015/06/02(火) 00:03:07.09ID:???論理的に使うのと表示じゃ違うから、原則性別（男1,女2,無0）フラグと表示（男、Man）は分ける
0400NAME IS NULL
2015/06/02(火) 01:16:44.84ID:???そしたら汎用テーブルの必要ないな
0401NAME IS NULL
2015/06/02(火) 03:01:44.50ID:???共通項をくくりだしただけではなくて？
0402NAME IS NULL
2015/06/02(火) 05:15:15.83ID:???会員の種類が増えたら、テーブル増やすとかはありだと思う
まさか、利用者が10人から11人になったらテーブル増やすとか言うわけじゃあるまい
ただし、それと全会員共通でログインを管理するテーブルを持つかどうかは別の話
0403NAME IS NULL
2015/06/02(火) 05:36:17.68ID:???性別フラグや各種フラグ、表示文字の設定用で使うのはありかと
個人的には国内限定仕様だと都道府県は専用テーブルにするが
0404NAME IS NULL
2015/06/02(火) 08:55:10.78ID:???増えないとは、言ったけど、それが男/女だけとは言ってない件
0405NAME IS NULL
2015/06/02(火) 10:15:59.42ID:???いや、俺も2個固定じゃなくて増え得るって言ったつもりなんだが
0406NAME IS NULL
2015/06/02(火) 11:17:52.57ID:???言いたいことがよくわからないのだが、
会員＝ログイン情報持ってるわけだろ？
なのに、「全会員共通でログインを管理するテーブルを持つかどうかは別問題」ってどういう意味？
いつログイン/ログアウトしたとかの記録をとるログテーブルを持つかどうかってこと？
0407NAME IS NULL
2015/06/02(火) 11:54:03.62ID:???会員の種類が異なると、その属性集合が異なる場合があって、それを別テーブルにするとかいうことでしょ。
0408NAME IS NULL
2015/06/02(火) 12:24:57.25ID:???ごめん。理解できない。
有料会員/無料会員とあって、それを別テーブルにする
って事でもないよな？こういう場合は1テーブルにしてるはず。
0409NAME IS NULL
2015/06/02(火) 12:43:55.18ID:???> 有料会員/無料会員とあって、それを別テーブルにする
そういうことだが。
> 1テーブルにしてるはず
なんで「はず」なんだ。
0410NAME IS NULL
2015/06/02(火) 12:56:54.80ID:???有料会員にしか属さない情報をどう管理するかって話だよ。
0411NAME IS NULL
2015/06/02(火) 13:08:08.12ID:???0412NAME IS NULL
2015/06/02(火) 13:11:50.97ID:???男/女/不明/その他
くらいじゃないの？増えるというのは？
0413NAME IS NULL
2015/06/02(火) 13:12:26.99ID:???無料→有料（またはその逆）になる場合、いちいちテーブル移動するのか？
0414NAME IS NULL
2015/06/02(火) 13:20:43.08ID:???会員属性テーブル：ID、属性名
会員テーブル：ID、会員属性ID、ログイン名、パスワード
この会員属性テーブルに、無料と有料を用意して
会員テーブルで結合するって話なだけだろ。さすがに。
0415NAME IS NULL
2015/06/02(火) 13:27:56.49ID:???こう言うことだろ
ログイン情報テーブル（Id, ログインId, パスワード情報, ...）
有料会員情報テーブル（Id, 有効期限, 支払方法, ...）
無料会員情報テーブル（Id, ...）
0416NAME IS NULL
2015/06/02(火) 13:39:11.11ID:???いや、だからその場合は無料から有料会員になったらどうするのよ？
無料会員情報テーブルのレコード消して、有料会員情報テーブルの方に追加して・・・
って処理が発生していいのか？
あと、有料会員が投稿したデータとかはどうなるんだよ？
投稿じゃなくても何か購入とかでもいい。
「5月は無料会員でした。6月は有料会員になりました。7月は無料会員に戻りました」
ってケースの場合、その設計だと破綻するだろ。
0417NAME IS NULL
2015/06/02(火) 13:42:21.44ID:???どういうパターンもあり得るだろ。
対象ドメインなしに、「こういうことだろ」みたいな話をしても意味ない。
> 無料→有料（またはその逆）になる場合、いちいちテーブル移動するのか？
無料会員と有料会員を別テーブルにするという選択をしたなら、そうするだろ。
0418NAME IS NULL
2015/06/02(火) 13:44:16.96ID:???> 「5月は無料会員でした。6月は有料会員になりました。7月は無料会員に戻りました」
> ってケースの場合
正気か？
その場合は、これまでのどの設計でもダメだろ。
0419NAME IS NULL
2015/06/02(火) 13:50:56.73ID:???正気か？ってこういう事が起きないとでも？
起きる可能性があるから、>>415の設計だと破綻するだろって言ってるんだが。
0420NAME IS NULL
2015/06/02(火) 13:52:19.57ID:???member_grades: {member_id, from_date, to_date, grade}
とかも考えられる。
（to_dateがあるのは良くない派もいる）
0421NAME IS NULL
2015/06/02(火) 13:55:55.59ID:???> 正気か？ってこういう事が起きないとでも？
起きる場合もあるだろうな。
> >>415の設計だと破綻するだろって言ってるんだが。
>>415の設計も破綻するが、これまでのどの設計も破綻する。
その意味で、
> 「5月は無料会員でした。6月は有料会員になりました。7月は無料会員に戻りました」
> ってケース
みたいな話を持ち出すのは正気かって言ってるんだが。
頭悪すぎだろ。
0422NAME IS NULL
2015/06/02(火) 14:05:18.95ID:???>>416
> いや、だからその場合は無料から有料会員になったらどうするのよ？
そういう要件があるなら、最初からそれ込みで設計するだろ。
要するに、要件なしであれこれ言っても意味ない。
「有料/無料会員のモデリングの一般解」なんか存在しない。
0423NAME IS NULL
2015/06/02(火) 14:16:12.51ID:???> って処理が発生していいのか？
いいだろ？
なにか問題なのか？
> ってケースの場合、その設計だと破綻するだろ。
購入履歴テーブルとか作ればいいだけだろ
0424NAME IS NULL
2015/06/02(火) 14:41:16.15ID:???0425NAME IS NULL
2015/06/02(火) 14:42:49.90ID:???喧嘩するつもりがないならまじめに自分のレスを見返せ。
>起きる場合もあるだろうな。
って可能性を認めてるのに
>みたいな話を持ち出すのは正気かって言ってるんだが。
って無茶苦茶だろ。自分が何言ってるかわかってるのかよ。
0426NAME IS NULL
2015/06/02(火) 14:46:48.25ID:???じゃあ聞くが、>>415の設計に購入履歴テーブル追加出来る？
机上の空論じゃなくて、出来るなら見本見せてよ。
0427NAME IS NULL
2015/06/02(火) 15:07:34.97ID:???横だけども。
購入履歴はユーザにひもづくよね。
ユーザが有料会員無料会員になろうが、ユーザIDは変わらないよ。
> 有料会員情報テーブル（Id, 有効期限, 支払方法, ...）
> 無料会員情報テーブル（Id, ...）
これのIdは個別のサロゲートキーではなく、ログイン情報テーブル.Id。
>>415がそうじゃないって言ったら俺にはどうしようもないけど。
0428NAME IS NULL
2015/06/02(火) 15:11:50.02ID:???> って無茶苦茶だろ。自分が何言ってるかわかってるのかよ。
設計Aと設計Bに対して、設計Aなら実現できる事象Xを持ち出すのならともかく、
設計Aでも実現できない（というか、それまで話題にすらなっていない）事象Xに
設計Bは対応できないじゃないか、というロジックは頭悪いって言ってるんだが。
>>426
> >>415の設計に購入履歴テーブル追加出来る？
だーかーらー、購入履歴を管理するという要件があるなら、最初からそういう設計にするんだって。
> 要するに、要件なしであれこれ言っても意味ない。
ということだ。
0429NAME IS NULL
2015/06/02(火) 15:23:58.70ID:???「種類の違う会員」の例としては、「個人会員/法人会員」みたいな違いがある場合もある。
そういう場合は、別テーブルにするのもありじゃないか？
0430NAME IS NULL
2015/06/02(火) 15:27:15.61ID:???頭固いんだな。ここは設計を相談するスレだろ？
じゃ、AだろうとBだろうと起こりうる問題に対して
「こういう場合は無理がある」って指摘する事の何がおかしいだよ。
自分の枠に当てはまらなければ、他人の意見は受け付けないのかよ。
>> 要するに、要件なしであれこれ言っても意味ない。
>ということだ。
言いたい事はわかる。でも、俺含め他のやつも「無いことに対する想定」
を話してるんじゃないのかよ。誰かが要件をだしてるわけじゃないんだから。
じゃ、誰かが「俺はこう思う」って出して案に対して、誰かが「それはおかしくね？」
って指摘する事の何がおかしいか分からん。それがおかしいなら話にならないだろ。
0431NAME IS NULL
2015/06/02(火) 15:31:50.11ID:???会員に関連するテーブル（問い合わせ、退会申込、パスワード再請求など）
のテーブルも会員の数だけ作るのか？
0432NAME IS NULL
2015/06/02(火) 15:33:54.22ID:???> >>426
> > >>415の設計に購入履歴テーブル追加出来る？
> だーかーらー、購入履歴を管理するという要件があるなら、最初からそういう設計にするんだって。
>>427じゃだめなん？設計変えないとまずいん？
0433NAME IS NULL
2015/06/02(火) 15:35:12.98ID:???> 会員に関連するテーブル（問い合わせ、退会申込、パスワード再請求など）
> のテーブルも会員の数だけ作るのか？
君の考える
* 問い合わせ
* 退会申込
* パスワード再請求
のテーブル定義を書いてくれ。
一体何を質問されているのかわからない。
0434NAME IS NULL
2015/06/02(火) 15:37:03.10ID:???テーブルの実装としてはおよそ3パターンに分かれるかと。
・別テーブルにする
・共通項をくくりだして、個々に属性情報テーブルを用意する
・1テーブルでNULL使う
これっていつも問題になりがちで、常に正解といえるパターンはないものの典型じゃないかな。
0435NAME IS NULL
2015/06/02(火) 15:39:39.58ID:???> 誰かが要件をだしてるわけじゃないんだから。
そう。
だから、「それはこういう要件に対応できない」の「こういう要件」を後出して次から次に出していくと際限が無いのでは？
この一連の話は、
>>402
> 会員の種類ってのがどの程度の違いがあるかによるけど
> 会員の種類が増えたら、テーブル増やすとかはありだと思う
から始まっていて、その結論は、そういう場合もあるよね、で終わりだと思うんだが。
0436NAME IS NULL
2015/06/02(火) 15:42:00.78ID:???> テーブルの実装としてはおよそ3パターンに分かれるかと。
うん、どれもありえる。
で、「別テーブルにする場合もあるよね」と言ったら、>>431のような返しをされて困惑している。
0437NAME IS NULL
2015/06/02(火) 15:43:09.74ID:???君は、>>429で「個人会員/法人会員みたいな違いがあるから、別テーブルにするのもありじゃないか？」っと提言してるよね？
で、俺は「会員として使うテーブルも分ける事になるけど良いのかな？」と思ったわけだ。
* 問い合わせ
個人だろうと法人だろうと「管理者に質問」するケースは多々あるよね？
カラムは「件名・内容」とか「用件（カテゴリ選択）・内容」が多いと思う。
もちろん、個人と法人で全くフォームの内容が異なるなら2つに分けるべきだろうけど、
そうでない場合は、1つでも良いんじゃないかな？とは思う。
* 退会申込
これは単純だね。退会した日と理由を保管するテーブルだね。
* パスワード再請求
これもよくあるね。ワンタイムパスワードみたいな仮パスワードを送信するとか、
新しいパスワードを設定するためのトークン発行するとか。
会員の種類毎にテーブルを分けるということは、
これらよく使用するテーブルも分けるって事になってもいいの？って指摘だよ。
もちろん、要件によるのは確かだけど。
0438NAME IS NULL
2015/06/02(火) 15:44:50.36ID:???困る必要ないと思うんだよ。
3パターンに分かれるということは、それだけ考える余地があるということ。
「こういうメリット/デメリットが有るよ」って指摘に対して
そこで困って思考停止するなら、設計の話なんて出来ないよ。
0439NAME IS NULL
2015/06/02(火) 15:49:07.15ID:???もういいだろ
0440NAME IS NULL
2015/06/02(火) 16:04:55.70ID:???そういう内容だったら、分ける必要ないと思うけど。
どうして
> 会員として使うテーブルも分ける事になる
と思うんだろう？
0441434
2015/06/02(火) 16:07:05.83ID:???>>436
>>431に対しては、まさかｗと返事するのが妥当。
てか、>>437で引き継いでるのか。
> 会員として使うテーブルも分ける事になる
それは法人会員、個人会員でIDが重複するような設計の場合でしょ。
そのパターンはさすがに考えてなかったな。
0442NAME IS NULL
2015/06/02(火) 16:07:32.32ID:???> 「こういうメリット/デメリットが有るよ」って指摘に対して
それが本当に「デメリット」なら議論する意味もあるんだが、誰も想定していない要件に対応できて
いないというのは「デメリット」ではないのでは？
0443NAME IS NULL
2015/06/02(火) 16:11:02.09ID:???0444NAME IS NULL
2015/06/02(火) 16:12:56.20ID:???個人会員テーブル
法人会員テーブル
の場合で、お問い合せテーブルを分けない場合、
お問い合せテーブル内のカラムは、個人会員IDと法人会員IDが存在して、
どちらかがNULLになるんだけど、そういう想像もつかない？
それとも俺が知らない別の設計があるというなら教えてくれ。
>>442
確かにそう。言葉が悪かった、すまん。
ただ、提案者がいて、第三者（俺）が「こういう場合はどうするの？」
って指摘したことに対して、煽り扱いするのは変じゃね？とは言いたい。
その時点で考える事を放棄してるじゃん。話し合いにならない。
誰かと話したくないなら自分のブログに書けばいいんだよ。
掲示板で意見を述べてる以上は、他人から指摘があっても受け入れろよ。
俺は別に自分が正しい・正しくないを主張してるわけじゃない。
0446NAME IS NULL
2015/06/02(火) 16:17:06.65ID:???だろ？おかしいよな。
だから俺は会員毎にテーブルを分けるのは「おかしい」って言ってるんだよ。
0447NAME IS NULL
2015/06/02(火) 16:20:06.99ID:???> お問い合せテーブル内のカラムは、個人会員IDと法人会員IDが存在して、
法人会員ID=ログインユーザID
個人会員ID=ログインユーザID
と考えてるんだね。
法人会員IDとログインユーザIDは別にすればいいんじゃないかな。
0448434
2015/06/02(火) 16:23:17.82ID:???おかしくない場合もあると俺は思うので、ありがちなパターンとして3つ上げた。
そしてそのどれも駄目だとは言っていない。
0449NAME IS NULL
2015/06/02(火) 16:24:46.74ID:???個人会員テーブル（個人会員ID、個人固有の属性）
認証情報テーブル（ログインユーザID、パスワード等）
法人会員-認証情報の連関テーブル（法人会員IDとログインユーザID）
みたいな感じかな。
0450NAME IS NULL
2015/06/02(火) 16:25:23.50ID:???ということはだよ、
ログインテーブル＝＞個人会員テーブル
ログインテーブル＝＞法人会員テーブル
みたいな感じだ。（文字でER図は書けないけど・・・）
んで、お問い合わせテーブルにはログインIDが存在すると。
（お問い合わせテーブルを1つでまとめる場合ね）
で、この時にも疑問が生じる。
「テーブル見ただけでは、どの会員がお問い合わせしたか分からないのでは？」
もちろん、
お問い合わせテーブル＝＞ログインテーブル＝＞個人会員（法人会員）
と、結合していけばどの会員のお問い合わせかは判別できるけどね。
0451NAME IS NULL
2015/06/02(火) 16:26:57.85ID:???君が出した>>434の3パターン自体はおかしくないよ。誰もが思うこと。
俺は>>429も>>431と突っ込んだだけだから。
0452NAME IS NULL
2015/06/02(火) 16:32:57.55ID:???> と、結合していけばどの会員のお問い合わせかは判別できるけどね。
問い合わせに対応するときに、会員の属性が必要なら、そうすればいいんじゃないかな。
逆に聞くけど、一つにまとめると
会員テーブル（会員ID、法人/個人に共通な属性・・・、法人のみの属性・・・、個人のみの属性・・・）
となるけどそうするの？
0453NAME IS NULL
2015/06/02(火) 16:40:17.99ID:???>>450にも書いたけど、テーブルやカラムを過度に増やさないなら、
ログイン認証テーブル
└個人会員テーブル（性別とか年齢とか）
└法人会員テーブル（会社名とか担当者名とか）
とするだろうね。仮に別の会員が増えても属性テーブルを増やせばいいだけだし。
ただ、その場合は>>450の後半に書いたような疑問は生じるけど。
0454NAME IS NULL
2015/06/02(火) 16:44:51.52ID:???え、それを「個人会員テーブルと法人会員テーブルは別にする」と言ってたんだけど・・・
今まで使った時間は・・・
0455NAME IS NULL
2015/06/02(火) 16:49:07.28ID:???でも、>>453やら>>449みたいな情報を>>431で突っ込んだ後に出せてないよね？
>>429の情報だけじゃ、>>431みたいな疑問が生まれても仕方ないと思うんだけど。
そこからここまで話し合ったから、
「こういう設計のやり方を導き出せる」ってなったわけじゃん。何も時間を無駄にしてないよ。
「いや、俺はこういうつもりだった」っていうなら最初からちゃんと書こうよ。
0456NAME IS NULL
2015/06/02(火) 16:49:12.55ID:???「会員種類が増える」ことを、設計時想定済みの通常運用内とみなすか
仕様変更だとみなすかによって話は全く違う
>>450
>テーブル見ただけでは、どの会員がお問い合わせしたか分からないのでは？
>お問い合わせテーブル＝＞ログインテーブル＝＞個人会員（法人会員）
>と、結合していけばどの会員のお問い合わせかは判別できる
自分自身で疑問は解決してるように見えるが？
すくなくともRDB前提なら単一テーブルでデータが完結してる必要なんてないわけだが
なんならテーブル＝＞ログインテーブル＝＞個人会員（法人会員）でビュー作っとけよ
0457NAME IS NULL
2015/06/02(火) 16:51:08.17ID:???いや、>>429=>>449なんですが・・・
もういいです・・・
0458NAME IS NULL
2015/06/02(火) 16:52:31.46ID:???だから、それを最初に書けって話なの。
後から突っ込まれたから後出して「俺はこういうつもりだった」ってのは卑怯だろ。
0459NAME IS NULL
2015/06/02(火) 16:54:19.98ID:???いや、さすがにみんな>>449くらいのことは前提としてると思ってたんで・・・
念のため書いただけだし・・・
0460NAME IS NULL
2015/06/02(火) 16:57:52.37ID:???お前以外、全員わかってたぞ。
>>402
> 会員の種類ってのがどの程度の違いがあるかによるけど
> 会員の種類が増えたら、テーブル増やすとかはありだと思う
>
> ただし、それと全会員共通でログインを管理するテーブルを持つかどうかは別の話
>>406
> 言いたいことがよくわからないのだが、
> 会員＝ログイン情報持ってるわけだろ？
0461NAME IS NULL
2015/06/02(火) 16:59:15.01ID:???じゃあさ、>>431で突っ込んだ後に、>>433でほじくり返したんだ？
「一体何を質問されているかわからない」って書いてるじゃん。
>>431みたいなケースも考えられるから、
>>449みたいな設計が前提としてあるのは当然って反論はおかしいだろ。
>>431やら>>437やら>>444なら（全部俺が投稿した）の考えが及ぶから、
>>449みたいな設計が思いついたんだろ。
それを最初から前提とするべきってのは少々横暴だわ
0462NAME IS NULL
2015/06/02(火) 17:01:54.91ID:???待て待て。
お前以外全員わかってた＝全員>>449やら>>453に書いたような
会員テーブルとは別に共通のテーブル（ログインテーブル）を持つやり方を知っていた。
というなら、>>453を書いた俺はどうなんだよw知らないと書けないだろうが。
0463NAME IS NULL
2015/06/02(火) 17:02:25.51ID:???> >>449みたいな設計が思いついたんだろ。
お前以外は全員思いついてたわ
つか、常套手段
0464NAME IS NULL
2015/06/02(火) 17:03:36.32ID:???じゃお前は一体なんに反論してたんだよ？
別テーブルにする場合もある論にいちいち反論してんじゃねーよ
0465NAME IS NULL
2015/06/02(火) 17:03:46.85ID:???>>462を見ろ。
0466NAME IS NULL
2015/06/02(火) 17:04:30.48ID:???反論するなって言うなら会話にならないって何度も投稿してるだろうが。
お前は自分の考えのみ認めてもらえないなら、他人の意見は一切受け付けない人間か？
0467NAME IS NULL
2015/06/02(火) 17:09:50.49ID:???べつにお前を貶めようとか思ってるわけじゃないんだが
ほとんどの人は>>402の段階で>>449程度までは考えが及んでると思うんだ
だからお前の質問はかなり無碍な回答をされてるわけだが
それを横暴だっていうならまあそうかもしれん。ただ傲慢なだけだけど
0468NAME IS NULL
2015/06/02(火) 17:12:11.94ID:???> 「種類の違う会員」の例としては、「個人会員/法人会員」みたいな違いがある場合もある。
> そういう場合は、別テーブルにするのもありじゃないか？
>>431
> 会員に関連するテーブル（問い合わせ、退会申込、パスワード再請求など）
> のテーブルも会員の数だけ作るのか？
どうみても「別テーブルにするのもあり」の反論だと思うんだが。
で、最終的にお前はどうするんだと聞かれて、
>>453
> ログイン認証テーブル
> └個人会員テーブル（性別とか年齢とか）
> └法人会員テーブル（会社名とか担当者名とか）
どういうこと？
一貫性がないんだが。
0469NAME IS NULL
2015/06/02(火) 17:14:29.65ID:???まず2つ言いたい事がある。
「ほとんどの人は」と決めつけるな。知らない人もいるし、疑問を持つ人もいる。
みんな同じ、みんな知ってて当たり前の価値観は危険だぞ。
もう一つ。このスレは「DB設計を語るスレ」だ。
「ぼくのかんがえたせっけいをみんなだまってうけいれてくれるすれ」じゃないだよ。
他人から何かしらツッコミやら反論があって当然なんだよ。
そいつが知ってるかどうかは別で。
だから自分が書いたレスには責任を持って答えろよ。
どうせ2ちゃんだしどうでもいいやと責任放棄したいなら無視しろ。
わざわざ反論に反論重ねるからボロが出る。
0470NAME IS NULL
2015/06/02(火) 17:15:38.75ID:???いーや、このスレの流れ的に「お前以外は全員わかってた」と断言するね
0471NAME IS NULL
2015/06/02(火) 17:15:54.46ID:???反論なんじゃなくて、純粋な素朴な疑問なんだととらえようぜ
まあ、ここは語るスレだから好きに語ればいんだけど
みんなもうちょっと初心者に優しくしようぜ
0472NAME IS NULL
2015/06/02(火) 17:19:09.02ID:???431と437と444と446と450を見てから>>453を見てくれ。
自分で疑問投げかけてほぼ自分で答えを導き出したようなもんだw
でも、本来は>>429が>>431への回答として出すべきだとは思うがな。
0473NAME IS NULL
2015/06/02(火) 17:20:16.28ID:???> 自分で疑問投げかけてほぼ自分で答えを導き出したようなもんだw
やっと白状したか
お前以外は最初から全員わかってたんだ、バーーカ
0474467
2015/06/02(火) 17:22:22.83ID:???お前が俺を誰と勘違いしてるか知らんが
>自分が書いたレスには責任を持って答えろよ
責任もって答えるわ
>>467のほとんどの人ってのは>>461に無碍な回答をしてた人のことな
俺は反論やツッコミがある事に何も言ってないよ
むしろお前と同じであって当然だとおもってる
ただ、知らない人間の発言に、知ってる人間がきつい言葉で対応してるって言ってるだけ
0475NAME IS NULL
2015/06/02(火) 17:23:09.57ID:???白状？おかしな奴だな。
最初から>>429へツッコミしてるって書いてるのに。
お前みたいな人格攻撃しか出来ない幼稚な奴は
自分の意見も出せずに子供みたいにピーピー喚くだけだな。ダセェ。
0476NAME IS NULL
2015/06/02(火) 17:26:07.26ID:???そうか。俺も馬鹿みたいに煽ってる来る”だけ”の奴がいるから混乱してるんだよ。
変な言い方してたらすまん。
ただ、何度も書くが、俺自身がどう思おうが、どんな知識があろうが、
>>429に対して>>431の質問して、いろいろこうじゃないの？ああじゃないの？
って意見を出すことに四の五の言われる意味が分からん。
473みたいなアホまるだしの奴にも相手してるから、それは俺の落ち度だが。
0477NAME IS NULL
2015/06/02(火) 17:29:38.99ID:???最初から、そういうこともあるでFAなのに。
0478467
2015/06/02(火) 17:30:40.82ID:???で、お前は俺に突っ込みを入れてるわけだが
>>459や>>463にはなんで突っ込まないの？
言い方としてはよっぽどそっちの方が悪いと思うけど
まさかそれらもが俺の発言だと思ってるの？
0479NAME IS NULL
2015/06/02(火) 17:34:52.71ID:???0481NAME IS NULL
2015/06/02(火) 17:36:32.47ID:???>>93
> 何がしたくてこうなってるのか分かんねーから、疑問に思ったこと全部聞いていくしかない
マジ迷惑
0482NAME IS NULL
2015/06/02(火) 17:38:04.49ID:???残念ながら違うな。
でもさ、お前「迷惑」って言うけど、じゃこのスレで何を語るの？設計じゃねーの？
面倒臭いなら無視すればいい。疑問に思ったことを聞くなって横暴すぎるだろ。
0483NAME IS NULL
2015/06/02(火) 17:40:04.75ID:???いや、俺に教えるべきとか思ってるなら、それは大間違い
0484NAME IS NULL
2015/06/02(火) 17:40:51.20ID:???つい他人を下にして語りたくなるんだろ
なんだお前そんなことも言わないとわからないのかよ という俺カッケー的なあれ
0485434
2015/06/02(火) 17:43:14.22ID:???>>469
> まず2つ言いたい事がある。
俺からも一つ言わせてくれ。名前付けて。
0486NAME IS NULL
2015/06/02(火) 17:44:16.57ID:???何度も何度も書いてるが、俺はまず最初に「ツッコミ」をしたんだよ。
「429さん、あなたの設計だと431みたいな場合どうしますか？」って。
それに対して429が自分の考えを書けばいいだけだろ。
事の発端は429で、俺の質問に429が答えたのではない。
>>484
2ちゃんで反論するなって初めて言われたわw
反論したら駄目なローカルルールなんて知らねーよ。
（もし、このスレにあるならもう黙るわ
0487NAME IS NULL
2015/06/02(火) 17:45:04.10ID:???> だから、それを最初に書けって話なの。
> 後から突っ込まれたから後出して「俺はこういうつもりだった」ってのは卑怯だろ。
0488NAME IS NULL
2015/06/02(火) 17:52:12.30ID:???0489NAME IS NULL
2015/06/02(火) 18:22:35.71ID:???反論するなとか言ううんじゃなくて、なんて言うか
素人が偉そうに語ってるんじゃねぇ という俺カッケー的なあれ
0490NAME IS NULL
2015/06/02(火) 18:40:32.53ID:???0491415
2015/06/02(火) 20:14:35.32ID:???> >>415がそうじゃないって言ったら俺にはどうしようもないけど。
合ってるよー w
>>449
関連テーブルの必要性がわからん
0492NAME IS NULL
2015/06/02(火) 20:19:32.91ID:???どうして無料会員と有料会員2つあるの？
・ログインに関するテーブル
・会員属性に関するテーブル
・有料、サービスに関するテーブル
の3つを基準にすると良いと思うんだけど
0493415
2015/06/02(火) 20:41:19.20ID:???会員属性が有料と無料で違うから
微妙な差ならテーブル一つにして要らない所に Null でも入れとくって言うのもあり
0494NAME IS NULL
2015/06/02(火) 21:31:49.85ID:???なるほど。そういう考えもあるんだね。
0495NAME IS NULL
2015/06/02(火) 22:58:52.53ID:???DB試験の過去問チェックしたことあるならパターンがいくつかあるってことわかるだろうに。
0496NAME IS NULL
2015/06/02(火) 23:13:34.26ID:???0497NAME IS NULL
2015/06/02(火) 23:14:21.26ID:???0498NAME IS NULL
2015/06/03(水) 00:01:39.85ID:???自分は別テーブルにするのが当たり前だと思ってたし、
教本でもエンジニアブログなんかでも別テーブルにするやり方しか書いてない。
共通項括りだして属性だけ別にする、なぜなら〜っての気付かなかった。
DB試験に出るぐらい有名なことなんですね。勉強になります
0499NAME IS NULL
2015/06/03(水) 10:15:01.21ID:???うーむ、この程度は常識だと思ってたが、以外とそうでもないのかな
0500NAME IS NULL
2015/06/03(水) 11:48:14.97ID:???0501NAME IS NULL
2015/06/03(水) 13:47:51.44ID:???0502NAME IS NULL
2015/06/03(水) 14:11:33.94ID:???>>498
0503NAME IS NULL
2015/06/03(水) 14:16:41.55ID:???> 教本でもエンジニアブログなんかでも別テーブルにするやり方しか書いてない。
>>501も言ってるけど、いろいろ本読んだ方がいいよ。
例えば、今回の話題（共通項が多いが、異なる属性がある場合）なら、直近の書籍だと
『SQLアンチパターン』に説明がある。
Webにも解説あり。
『SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました』
http://makopi23.blog.fc2.com/blog-entry-90.html
『5章 EAV (エンティティ・アトリビュート・バリュー)』
http://qiita.com/deme0607/items/a89319014bc007f09f5c
ありがちな話なので、「SQLアンチパターン」以外にも、この手の話に言及してるものがあると思う。
0504NAME IS NULL
2015/06/03(水) 14:20:17.99ID:???『Catalog of Patterns of Enterprise Application Architecture』
http://martinfowler.com/eaaCatalog/index.html
まあ、このサイトはデータベースに特化したものじゃないけど。
データベースに特化したPatternを集めたサイトがあった気がするが、忘れた・・・。
0505NAME IS NULL
2015/06/03(水) 14:37:02.14ID:???0506NAME IS NULL
2015/06/03(水) 15:33:56.08ID:???横だけど凄い丁寧で誠実な人だな。感心するわ。
あなたみたいな回答者がいれば、スレが荒れることもないのにね。
0507NAME IS NULL
2015/06/03(水) 18:21:44.76ID:???いつでも無料で情報くれると思うなよ
0508NAME IS NULL
2015/06/03(水) 20:03:54.99ID:???褒められてる人見て嫉妬しない
0509NAME IS NULL
2015/06/03(水) 20:32:06.40ID:???勉強してないとそのキーワードが出てこないよな。
0510NAME IS NULL
2015/06/03(水) 21:05:05.44ID:???0511NAME IS NULL
2015/06/04(木) 11:51:16.32ID:???本読めば一気に脱出できるがな
本読めアホども
0512NAME IS NULL
2015/06/04(木) 11:56:20.60ID:???そんなんじゃ誰もお前の話なんて聞かねーよ
0513NAME IS NULL
2015/06/04(木) 12:48:40.71ID:???0514NAME IS NULL
2015/06/04(木) 13:12:01.08ID:???0515NAME IS NULL
2015/06/05(金) 00:08:40.38ID:???0516NAME IS NULL
2015/06/05(金) 20:54:48.24ID:SMCH9gEQテーブルpiyo (カラムはa,c)
とあって、
hoge がまず存在して、piyo はhogeがあるときだけ存在する
（hoge.a と piyo.a は同じ）
でもたまに piyoだけ存在することもある
(そのときpiyo.a はnullになってる）
という関係をデータベース用語でなんと呼ぶの？
0517NAME IS NULL
2015/06/05(金) 21:56:39.52ID:???0518NAME IS NULL
2015/06/05(金) 23:17:08.11ID:???よくわからないテーブルだけ出されても答えようがない。
関係を考えるならhoge/piyoは一旦忘れて、aとbとcで考えろ。
aとcが無関係なことだけはわかるが、あとはこれだけじゃわからん。
0519NAME IS NULL
2015/06/08(月) 13:25:30.20ID:???> という関係をデータベース用語でなんと呼ぶの？
呼び名は無い
0520NAME IS NULL
2015/06/08(月) 18:16:36.91ID:???という関係
0521NAME IS NULL
2015/06/08(月) 18:31:32.07ID:???0522NAME IS NULL
2015/06/08(月) 19:35:27.61ID:???>>521
これでいいじゃん
0523NAME IS NULL
2015/06/12(金) 01:13:07.20ID:???0524NAME IS NULL
2015/06/12(金) 04:55:27.11ID:???0525NAME IS NULL
2015/06/12(金) 08:53:29.76ID:KUxeCqtqwhere句で絞ってからjoinしてくれてるのかな？ちなみにOracle
0526NAME IS NULL
2015/06/12(金) 19:47:06.13ID:???実行計画やオートトレース確認してみたらいいんでね？
0527NAME IS NULL
2015/06/13(土) 06:12:24.57ID:???1対多を1対1的にしたいならexists
0528NAME IS NULL
2015/06/16(火) 21:11:52.40ID:taWzsqn+テーブルを作成しようと
id,code1,code2,soukankeisu
のようなテーブル定義を考えています。
これだと相関関係を更新する際に何度もselectしなければならず、時間がかかりすぎるのでは？と考えています。
何か方法はありませんか？
0529NAME IS NULL
2015/06/17(水) 10:08:37.06ID:???その相関関係を、アプリ側でどのように使用するかによる。
0530NAME IS NULL
2015/06/17(水) 10:43:01.52ID:UrK3owRT今は
select * from table
where code1=c1 or code2=c2
order by soukankeisuu desc
limit 20
;
を発行し、プログラム側でこれらのレコードからc1でないものを選んでいます。
0531NAME IS NULL
2015/06/17(水) 10:46:48.53ID:UrK3owRTすみません。
select * from table
where code1=c1 or code2=c1
order by soukankeisuu desc
limit 20
;
でした
0532NAME IS NULL
2015/06/17(水) 10:47:40.93ID:???ごめん、言葉が足りなかった。
* その相関関係を利用するのは、一つのプロセスなのか、複数なのか
* その相関関係を利用するのは、一つのサーバ上のプロセスなのか、複数なのか
あとは、
* OSは何を想定しているのか
くらいかな。
まぁ、何が言いたいかと言うと、RDBじゃなくて、mmapとかNoSQLのがいいんじゃなかろうかということ。
0533NAME IS NULL
2015/06/17(水) 11:01:40.63ID:???ちょっと質問
たとえば、code1=2,code2=3 と code1=3,code2=2 では
soukankeisuu は異なるのかな、同じになるのかな？
0534NAME IS NULL
2015/06/17(水) 11:17:06.31ID:UrK3owRT相関関係を求める処理はwindowsで行っています。
windowsでの作業はバッチ処理のようなイメージで
相関関係を実際に求め
code1,code2,soukankeisuu
というCSVファイルにまとめて(サイズは73Mぐらい)、
更新用SQLファイルを作成し、サーバーにアップする。
0535NAME IS NULL
2015/06/17(水) 11:19:28.24ID:UrK3owRT同じになります。
idに主キーを設定しており、
二つのコードは C0001、C0002だとしたら、これらをソートし
C0001-C0002という値をidに設定しています。
0536NAME IS NULL
2015/06/17(水) 11:19:44.99ID:???0537NAME IS NULL
2015/06/17(水) 11:24:18.03ID:UrK3owRT情報が後だしになって申し訳ありません。
今は430万レコードぐらいです。
0538NAME IS NULL
2015/06/17(水) 11:28:52.64ID:???今までの話聞いてて推測するんだけど、
その数はIDが2000件くらいあって、そのかけ算の結果430万ってことかな？
0539NAME IS NULL
2015/06/17(水) 11:31:53.13ID:UrK3owRTすみません。
まだLinuxでの操作経験、知識欠けていること
相関関係を求めるための元データ(xmlとexcel)が不安定?というか信頼性にかけるところがあり
それをチェックするにはwindows環境のほうが作業がしやすいこと
からサーバーで実行するのは不安なんです。
0540NAME IS NULL
2015/06/17(水) 11:38:00.70ID:UrK3owRTcode1(やcode2)は5000ほどあり、
5000＊5000の行列の上三角の対角なしで、
相関係数の絶対値が一定の値以上のものを選定しています。
0541NAME IS NULL
2015/06/17(水) 11:44:06.77ID:???> 何か方法はありませんか？
まず、相関関係を更新するのに、truncate tableしてから全レコードimportでいいなら、そうすれば
処理時間は大幅に短縮できる。
相関関係を更新するのが差分適用の場合、mysqlならINSERT ... ON DUPLIATE KEY UPDATEが
使える。
相関関係の更新が大量かつ頻繁に行われるということであれば、使ったことはないが、
InnoDB memcached pluginも考慮に値すると思う。
http://thinkit.co.jp/story/2014/01/08/4716
さらに、相関関係テーブルを他のテーブルとJOINする必要がないのなら、MySQLではなくて、
NoSQLオンリーの運用も考えられる。
0542NAME IS NULL
2015/06/17(水) 11:53:27.94ID:UrK3owRTさまざまな案を考えていただきありがとうございます。
INSERT ... ON DUPLIATE KEY UPDATE
InnoDB memcached plugin
NoSQLオンリーの運用
を調べてみてみます。
0543NAME IS NULL
2015/07/09(木) 17:48:26.06ID:T1cEsjFS皆さんは住所関連のカラム名ってどうしてますか？
郵便番号はzip？postcode？
後者が正しいようですが、郵政のサイトではzipになっています。
都道府県はpref？prefecture？
市区町村〜番地、マンション・建物名は
address1、address2、address3 などの簡易表示？
city、town、street などの英名？
カラム名を迷って設計できないことが多々あるので、
皆さんはどうしているか教えて下さい
0544NAME IS NULL
2015/07/09(木) 17:59:43.77ID:???こういうとこ参考にしてみるのもいいよ。
http://www.databaseanswers.org/data_models/index.htm
ちなみに、http://www.databaseanswers.org/data_models/customers_and_addresses/index.htm 見たら、
郵便番号はzip_or_postcodeってなってて、zipがアメリカ英語、postcodeがイギリス英語らしいね。
0545NAME IS NULL
2015/07/13(月) 07:00:56.07ID:JM7F60EO日本語でやれば解決
悩まなくてすむ
住所以外でも諸々
0546NAME IS NULL
2015/07/13(月) 10:27:28.33ID:???> 日本語でやれば解決
俺もつい最近までそう思ってました。MSSQLだしWindowsだしって理由で。
だが、Sync Frameworkが使えない場合があるというのでドはまりした。
今でもこんなこと良くあることなんですかね。
0547NAME IS NULL
2015/07/13(月) 23:15:33.74ID:???返事遅くなってすみません。
このサイトっていわゆるER図のサンプルサイトですかね。
ただ、例のは「line_1、line_2」とか曖昧な名付けであんまり参考にはなりませんが・・・
0548NAME IS NULL
2015/07/13(月) 23:19:43.96ID:???やっぱり英語の方が良いと思うんですよね。確かに分かりやすいとは思いますが。
ただ、有名ところのフォームのソースなんかみても、
みんな適当なんですよね。記号的に名前つけてる感じで。
そんなんで後から困らないか？って思うんですけど、気にしてないんですかね。
0549NAME IS NULL
2015/07/14(火) 03:48:22.33ID:???なぜline_1 line_2に至ったのかを考える脳がないならすべて役に立たないから見ないほうがいい
0550NAME IS NULL
2015/07/15(水) 10:24:55.73ID:???うーん、それを超えてるんですよ。
「なぜそこに至った経緯は分かるけど、それは果たして使えるのか？」って。
そもそも質問している事と違うことに対してレスされることに対して
「すべて役に立たない」って断定して批判するのはいかがなもんでしょう？
0551NAME IS NULL
2015/07/15(水) 10:29:29.77ID:???って質問してるのに、「カタカナでタマゴにするべき」って言うのと一緒だと思うんです。
カタカナにした意図は分かるものの、こっちの質問とは違うじゃないですか。
「卵と玉子の本来の意味や使用用途、使用範囲を考えたらこうするべき」
って意見がほしいのに、全く違う意見を出されて
「タマゴにする意図がわからないなら質問するな（他人に聞くな）」
ってのは、ちょっと横暴すぎると思うんですよ。言い方をもっと変えないと。
0552NAME IS NULL
2015/07/15(水) 10:47:43.98ID:???質問する→回答される→それは超えてるんですよ
命名レベルで足止まるドシロウトに越えられるって笑う
使えるか使えないか判断する立場はまだまだ早い感じ
0553NAME IS NULL
2015/07/15(水) 11:37:23.74ID:???0554NAME IS NULL
2015/07/15(水) 12:19:27.92ID:???お前以下の奴はそうそう居ないと思うぞｗ
0555NAME IS NULL
2015/07/15(水) 13:38:50.68ID:???0556NAME IS NULL
2015/07/15(水) 13:55:16.85ID:???> このサイトっていわゆるER図のサンプルサイトですかね。
ER図のサンプルじゃなくて、Data Modelのサンプル（または実例）。
> ただ、例のは「line_1、line_2」とか曖昧な名付けであんまり参考にはなりませんが・・・
そうかな。このページだけでもいろいろと示唆に富んでると思うんだが。
俺は、このモデルにマッチする要件のシステムは作ったことないけど、なるほど、
こんな感じにモデリングする要件もあるのかと感心したが。
0557NAME IS NULL
2015/07/15(水) 15:10:30.68ID:???日本語でよくある住所１住所２かｗ
住所って、表示／印刷すること考えると、改行個所どうすかって問題が出るんだよ
だからデータ上、行ごとに分けて持つのはよくあるパターンだぞ
0558NAME IS NULL
2015/07/15(水) 17:27:21.30ID:???> カタカナにした意図は分かるものの、こっちの質問とは違うじゃないですか。
> 「卵と玉子の本来の意味や使用用途、使用範囲を考えたらこうするべき」
> って意見がほしいのに、全く違う意見を出されて
> 「タマゴにする意図がわからないなら質問するな（他人に聞くな）」
> ってのは、ちょっと横暴すぎると思うんですよ。
それは意図が分かっていないからじゃないか？line_1 line_2にしている意図を書いてみ。
意図が分かっているのなら、こうするべきって意見が出てこないことにひとつの着地点を見出せてるはずだが。
それでもこうするべきという意見がほしいというなら、勝手にすればいいじゃんっていうしかない。
0559NAME IS NULL
2015/07/17(金) 00:35:32.77ID:???http://komattarasoudan.seesaa.net/article/422452476.html
最近髪でお悩みの方悩まずはこちらをご参考だて下さい。
http://kaminokehahaeru.seesaa.net/article/422482791.html
0561NAME IS NULL
2015/07/19(日) 21:25:29.25ID:???0562NAME IS NULL
2015/07/22(水) 20:53:37.13ID:???address line 1 →住所1
address line 2 →住所2行目
って出てきた。でも、住所2行目ってなんの事か分からなくね？
address cityとかaddress townの方がよくね？
0563NAME IS NULL
2015/07/22(水) 22:41:43.33ID:???0564NAME IS NULL
2015/07/22(水) 22:54:19.26ID:???0565NAME IS NULL
2015/07/23(木) 00:25:45.19ID:???よくないからline1 line2にしてるんだ。
0566NAME IS NULL
2015/07/23(木) 00:43:53.28ID:???それも手ではあるけど
行数限定が難しかったり
改行コードが何かとかでトラブったりするんだよなぁ
経験上、住所に限れば固定行数として持たすほうが色々楽な事が多いんじゃね
0567NAME IS NULL
2015/07/30(木) 21:04:00.60ID:???なぜよくないの？
0568NAME IS NULL
2015/08/04(火) 20:06:09.37ID:???調べても出てこないので困っています
助けてください
0569NAME IS NULL
2015/08/04(火) 20:55:19.15ID:???0570NAME IS NULL
2015/08/04(火) 21:02:09.67ID:???ありがとうございます
そうすればうまくいきますね
0571NAME IS NULL
2015/08/07(金) 19:35:44.75ID:+bbUwYmnhttp://live.fc2.com/79752690/
0572NAME IS NULL
2015/08/26(水) 09:44:57.47ID:???主キーは銘柄コード（銘柄ごとに割り当てられている4桁の数字）にしようと思うんですが問題ありますか？
オートインクリメントのidじゃないといけないんでしょうか
0573NAME IS NULL
2015/08/26(水) 10:33:47.39ID:???銘柄コードは再上場の時くらいしか再利用されないからキーにいいんじゃないかなあ
0574NAME IS NULL
2015/08/26(水) 11:40:20.04ID:???ありがとうございます
銘柄コードをキーにすることにしました
0575NAME IS NULL
2015/08/26(水) 16:33:38.47ID:???重複上場（東証と名証 etc）などは考慮せずだよな？
俺はそうしてるけど
後、優先株式は5桁なのは知ってるか？ 伊藤園 優先は5桁になってるぞ
ついでに言うなら先物や指数はどうすんの？
桁数を固定にする必要はないと思うけど
0576NAME IS NULL
2015/08/26(水) 17:35:44.81ID:???0577NAME IS NULL
2015/08/26(水) 18:28:06.46ID:???0578NAME IS NULL
2015/08/26(水) 20:45:29.91ID:???そうでした^^;
0579NAME IS NULL
2015/08/26(水) 23:48:42.33ID:???後々何か問題が起こるのも嫌なのでとりあえずサロゲートキーにしてみます
0580NAME IS NULL
2015/08/29(土) 00:02:49.38ID:RF4wAyRYよかったら、「blngs」で検索してみて！
0581NAME IS NULL
2015/08/29(土) 00:09:04.60ID:???0582NAME IS NULL
2015/08/29(土) 01:20:53.25ID:???0583NAME IS NULL
2015/08/29(土) 09:58:03.48ID:???長期利用だと銘柄が被るから
厳密にやるなら適用開始終了日で複合キーになるはずだよ
0584NAME IS NULL
2015/08/29(土) 11:18:28.57ID:???良い参考書をご存じないですかね？
0585NAME IS NULL
2015/09/01(火) 18:33:31.19ID:???0586NAME IS NULL
2015/09/01(火) 20:56:02.34ID:???0587NAME IS NULL
2015/09/01(火) 23:15:04.96ID:???0588NAME IS NULL
2015/09/02(水) 02:47:05.19ID:???その槍玉に挙げやすかったし、共感もよびやすかったのだろう。
0589NAME IS NULL
2015/09/02(水) 13:34:38.42ID:???削除フラグにしようが削除日にしようが削除履歴にしようが
どんなパターンでも「有り」なんだから、まずはやってみて決めればいいんだよ。
やる前に四の五の考えるからやれなくなるわけで。
0590NAME IS NULL
2015/09/02(水) 14:42:13.06ID:???いや、なぜだか削除フラグだけは無しだってことになってる
0591NAME IS NULL
2015/09/02(水) 15:38:06.33ID:???0592NAME IS NULL
2015/09/02(水) 15:54:24.28ID:???そう？俺の場合結構あるけど。
例えば、
users: {user_id(PK), user_name}
blog_posts: {id(PK), user_id(FK), post_at, contents}
みたいな関係の場合、ユーザが「削除状態」になったらそのユーザに関連するデータは生成されなくなる。
一方、blog_postsの内容を表示するときは、「削除状態」に関わらず単純にusersをjoinすればいい。
で、何かの要件でユーザが「削除状態」であることを区別する必要がでてきたら、最も簡単なのは
users: {user_id(PK), user_name, delete_flag}
日付が必要なら
users: {user_id(PK), user_name, delete_at}
とかでもいいけど。
これ俺的には良くあるケースなんだが。
0593NAME IS NULL
2015/09/02(水) 16:13:37.27ID:???見たけど、>>592の例で言えば「ブログを削除する」のを
blog_posts: {id(PK), user_id(FK), post_at, contents, delete_flag}
にするのがアンチパターンっていってるのか。
そりゃそうだ。
0594NAME IS NULL
2015/09/02(水) 17:14:55.28ID:???そんなこと書いてないよな。
0595NAME IS NULL
2015/09/02(水) 17:41:17.21ID:???んーと、「時系列に生み出されるデータ」を「削除状態」にするときに、そのテーブルに削除フラグを
追加するのがアンチパターン。
>>593の例だとBugsテーブルで、>>592だとblog_postsテーブル。
それは良くない。
俺が結構あるっていってるのは、>>592のusersのような立場のテーブルを「削除状態」にするケース。
0596NAME IS NULL
2015/09/02(水) 18:02:10.67ID:???CREATE TABLE Accounts (
account_id SERIAL PRIMARY KEY,
account_name VARCHAR(20)
);
CREATE TABLE Bugs (
bug_id SERIAL PRIMARY KEY,
date_reported DATE NOT NULL,
description VARCHAR(1000),
reported_by BIGINT UNSIGNED NOT NULL,
assigned_to BIGINT UNSIGNED,
FOREIGN KEY (reported_by) REFERENCES Accounts(account_id),
FOREIGN KEY (assigned_to) REFERENCES Accounts(account_id)
);
「アカウント削除」はどう実装すれば良いかって言う問題。
Accounts.delete_flagが増えても、別にバグ一覧表示とかバグ新規登録には影響しない。
AccountsがBTSへのログインに使われる場合と、assignするときに「現行ユーザ」を取得
するために、WHERE Accounts.delete_flag = falseとかが必要になるだけ。
いやいや、「だけ」じゃなくてそれが問題だっていうのかもしれないが、俺は別にアンチパターン
だとは思わないんだよね。
0597NAME IS NULL
2015/09/02(水) 18:25:55.50ID:???この構造でbugsを削除するのに、削除フラグ使う奴なんているのか？
それとも俺が想像できないだけで、そういう奴が多数いるのか？
0598NAME IS NULL
2015/09/02(水) 18:56:11.52ID:???俺が言ってるわけじゃない。というのはさておき、
状態が欲しけりゃ以下略。
少なくともスライド主は妥当なケースではないと論じてるね。
0599NAME IS NULL
2015/09/02(水) 19:04:33.06ID:???BTSの場合はチケットが主で、それにユーザがアサインされる関係で、
ブログの場合は、ユーザが複数の記事を所有してる関係だよね。
なぜ混同するの？
0600NAME IS NULL
2015/09/02(水) 22:08:37.73ID:???基準がよく分からんなぁ…
bool deletedはNG、int statusはOK
なんて言ってたのもこの人なんでしょ
0601NAME IS NULL
2015/09/02(水) 22:11:28.93ID:???出来る人が使ったらそうでもないんだろうなぁ
0602NAME IS NULL
2015/09/03(木) 01:29:20.07ID:???それDB設計となんの関係もない話。
0603NAME IS NULL
2015/09/03(木) 01:41:20.67ID:???削除っていうのが嫌なのかも
実際に削除しないのなら削除言うな。と
あなたが(あるいは顧客が)本当にやりたい事は削除じゃないんでしょ。と
0604NAME IS NULL
2015/09/03(木) 03:58:56.69ID:???なるほど
設計に入る前にヒアリングをしっかりしとけ、で終わる話か
この話題には削除フラグを立てておこう
0605NAME IS NULL
2015/09/03(木) 06:44:23.78ID:???無効フラグでいいかと
0606NAME IS NULL
2015/09/03(木) 11:15:49.31ID:???> BTSの場合はチケットが主で、それにユーザがアサインされる関係で、
> ブログの場合は、ユーザが複数の記事を所有してる関係だよね。
> なぜ混同するの？
BTSの場合：
現在有効なユーザがログインする(Accounts参照) → そのユーザがチケットを作成
そのユーザを「削除状態」にする
そのユーザはログインしない（できない）ので、そのユーザは以降チケットを作成しない
ブログの場合：
現在有効なユーザがログインする → そのユーザがブログを作成
そのユーザを「削除状態」にする
そのユーザはログインしない（できない）ので、そのユーザは以降ブログを作成しない
同じだよね？
BTSの場合はブログと違って「アサインする」というアクションの時に「現在有効なユーザ」を
検索する必要があるというだけ。
0607NAME IS NULL
2015/09/03(木) 11:19:16.18ID:???>>592のblog_postsに削除フラグを追加するのと同じってことで、それは俺も筋が悪いと思う。
俺が「結構ある」っていってるのは、users(SQLアンチパターンで言えばAccounts)を
「削除状態」にするとき、delete_flagで十分な場合が結構あるってこと。
0608NAME IS NULL
2015/09/03(木) 11:38:12.57ID:???> 削除っていうのが嫌なのかも
この話題に関して、「削除フラグは思考停止である」って思考停止してる人結構居るよ。
0609NAME IS NULL
2015/09/03(木) 11:40:45.88ID:???0610NAME IS NULL
2015/09/03(木) 12:41:49.63ID:???ユーザが削除されたときにチケットなりブログなりを表示すべきかって話かと思ってたわ
0611NAME IS NULL
2015/09/03(木) 13:08:16.85ID:???表示する必要ないなら、物理削除でええやん
0612NAME IS NULL
2015/09/03(木) 14:06:34.72ID:???商品の取り扱いが終了したから商品マスターから物理削除とかしてたら、
それに紐付くデータの取り扱いがすごく面倒な気がするんだが。
物理削除するために、いわゆるトランザクションデータには、いわゆるマスターデータの
項目（社員名とか商品名とか）を全てコピーするという設計も見たことあるが、
それもどうなのと思う。
0613NAME IS NULL
2015/09/03(木) 14:16:51.25ID:???0614NAME IS NULL
2015/09/03(木) 16:01:57.15ID:???俺だったら、有効期間をもたせるが。
0615NAME IS NULL
2015/09/03(木) 16:03:31.90ID:???かといってdatetimeも嫌だし。
とすると、データコピーもありなのか・・・。うーむ。
0616NAME IS NULL
2015/09/03(木) 16:54:18.15ID:???そうだな。ユーザも物理削除でいいよな。
0617NAME IS NULL
2015/09/03(木) 17:37:45.97ID:???0618NAME IS NULL
2015/09/04(金) 13:39:30.97ID:???「退会理由（削除理由）」が必要な場合はどうしてる？
>>596の例ならAccountsテーブルにカラム追加するパターンだと思うけど、
これも削除フラグの一種だと思ったり。
（退会理由が入力されていたら、その会員は退会済みとか。
0619NAME IS NULL
2015/09/04(金) 13:53:44.95ID:???同じテーブルに追加するのは愚の骨頂
0620NAME IS NULL
2015/09/04(金) 17:05:32.06ID:???> >>596の例ならAccountsテーブルにカラム追加するパターンだと思うけど、
NULL撲滅委員会は駄目だって言うだろうね
0621NAME IS NULL
2015/09/04(金) 18:43:38.61ID:???じゃ、別テーブルを用意するのか？それも無駄にならね？
0622NAME IS NULL
2015/09/04(金) 18:47:58.36ID:???Webでよくある、「会員登録したら確認メールが届いて、URLクリックすると本登録」
これもAccountsテーブルにカラム追加して、確認時に識別コードを照会して
本人か否か確認するってパターンがあるけど、これも別テーブルにするのか？
それともこれは「必ず最初に必要」な処理だから、NULL扱いにはならないか？
0623NAME IS NULL
2015/09/04(金) 18:55:05.97ID:???0624NAME IS NULL
2015/09/04(金) 19:22:45.87ID:???それ、ユーザの状態が仮登録から登録になったらそれ以降ずっと使わないカラムだろうなぁ
0625NAME IS NULL
2015/09/04(金) 19:32:08.31ID:???例えば本登録の場合、「パスワード再発行」とかの認証用コードに流用出来ないかな？
そうすれば使わないって事もないと思うんだが。
0626NAME IS NULL
2015/09/04(金) 19:42:33.26ID:???何でひとつのカラムに複数の意味を持たせてしまうんだろうなぁ
0627NAME IS NULL
2015/09/04(金) 19:42:36.06ID:???0628NAME IS NULL
2015/09/04(金) 20:05:19.12ID:???でもさ、そうすると俺（618以降）が出した要件分のテーブルが必要になるよ？
・Accounts（アカウント管理）*これは>>596
・Reason（退会理由）
・Activation（アカウントのアクチベーション）
・Reminder（アカウントのパスワードの再発行）
これに主題となっている、
「削除フラグやめて履歴テーブル追加」をするとまたテーブルが増える。
それが正しい（アンチパターンじゃない）って事かもしれないけど、
随分、利便性が悪くなるなって感じるんだけど。
0629NAME IS NULL
2015/09/04(金) 20:28:58.78ID:???非正規化は正規化を済ませたあとにやむを得ず行うことだって勉強しなかったの？
ちなみにそれらについて利便性が悪いと感じる部分は見当たらないけれど。
0630NAME IS NULL
2015/09/04(金) 20:30:19.41ID:???> 「削除フラグやめて履歴テーブル追加」をする
のであれば、退会理由はそのテーブルに持たせられるよね。
0631NAME IS NULL
2015/09/04(金) 20:34:20.93ID:???俺自体は>628な感じで設計してるけど、「これで良いのかな？」とずっと悩んではいる。
要件追加される毎にテーブルも追加ってのがどうもね
>>630
退会理由って必ず入力されるものでもないから、
>>620がいうNULL撲滅委員会は駄目だっていうんじゃないかな。
0632NAME IS NULL
2015/09/04(金) 20:45:34.00ID:???「テーブルを追加すべき要件」が追加されるごとにテーブルが追加されるだけだと思う。
退会理由として「なし」をユーザが「選択」したのなら、それはNULL以外の値を割り当てるべきじゃないでしょか。
俺も別にNULL撲滅委員会を信奉しているわけではないので、
退会理由「その他」+退会理由フリーテキストのカラムを用意するなら、それがNULLであることは問題視しない
0633NAME IS NULL
2015/09/04(金) 20:49:30.34ID:???なるほど。「選択したかしないか」を理由にしているわけですね。
NULLが入るのではなく、空白が入ると。
では、顧客情報テーブルとかプロフィールテーブルとかの
「必須項目じゃないカラム」も、”選択してない”として、
同じテーブル内にあっても問題ないわけですかね？
0634NAME IS NULL
2015/09/04(金) 20:50:29.75ID:???普通なら、退会と同時（多少時間的な猶予は取るかもしれないけど）に
個人情報の抹消はしないといけなくなる。
だから、退会理由のような、運営上必要なデータを取るとしても、
個人に紐付ける必要は無いんじゃない？統計として取れば十分だと思うよ。
0635NAME IS NULL
2015/09/04(金) 20:54:27.30ID:???なぜ「なし」の値が空白になると思ったんだろ。
webシステムでドロップダウンを作る際、「なし」のvalueに空白を設定するの？
後段については、俺はNULLで入れていいと思うよ。
プロフィールという一まとまりの情報の一部において、何も選択しなかった場合だよね。
0636NAME IS NULL
2015/09/04(金) 20:55:55.24ID:???ユーザ情報と認証情報が別だからだよと一応。
0637NAME IS NULL
2015/09/04(金) 21:01:18.18ID:???お客は本当に削除を求めているのか？と自らに問うている
禅問答スライドショーの真意はここにあるのではなかろうか
0638NAME IS NULL
2015/09/04(金) 21:01:18.85ID:???いやいや、「なしを選択したら」って条件を出されたら、空白だって思うでしょw
NULL以外の値を割り当てるべきだって追記してるんだから。
NULLと同等としたら、空白だって思うのが自然では？
0639NAME IS NULL
2015/09/04(金) 21:02:51.72ID:???そこに発展させようと思ったのですが、
>ユーザ情報と認証情報が別だからだよと一応。
なぜユーザー情報と認証情報が別なら「良いこと」にされるかわからないんですよね。
一貫性がないじゃないですか。それだと。
0640NAME IS NULL
2015/09/04(金) 21:02:56.69ID:???NULLと同等じゃないから別の値を割り当てるって言ったんだよ。
そうしないとオラクル信者が殴りこんでくる
0641NAME IS NULL
2015/09/04(金) 21:03:45.61ID:???「良いこと」ってなんだろ。別テーブルにするんだよ。
0642NAME IS NULL
2015/09/04(金) 21:06:06.19ID:???あれ？そういう意味（別テーブルにする）なんですか？
それなら、>>633にも書きましたけど、
「必須項目じゃないカラム」は全部別テーブルにするのですか？
0643NAME IS NULL
2015/09/04(金) 21:07:51.58ID:???プロフィールという一まとまりの情報の一部において、必須ではない情報があるときは同一テーブル
ユーザ情報と認証情報(アクティベーションのやつね)は別情報だから別テーブル
と書いてるつもりだけど、そこは伝わってますかね。
0644NAME IS NULL
2015/09/04(金) 21:09:53.45ID:???つまり、設計ではなくて「用途」によって、考え方（アンチパターンか否か）を変えても良い
って解釈をしてもいいですか？
0645NAME IS NULL
2015/09/04(金) 21:10:43.85ID:???そこで出てきているアンチパターンって何？NULL撲滅？
0646NAME IS NULL
2015/09/04(金) 21:11:14.48ID:???NULL撲滅とか、削除フラグをどうするか、とか今のテーマとなっていることですね
0647NAME IS NULL
2015/09/04(金) 21:18:17.67ID:???NULL撲滅については上で書いたとおり信奉してない。
あと、削除フラグについての話はしてないよね。
強いて書くなら、アクティベーションが必要な場合、ユーザの状態管理は削除フラグでは完結できないよね。
↑この場面を想定してあのスライド(の元になった記事)は書かれていると記憶している。
で、ユーザの状態をどう管理するかとして提示されているのが、
状態フラグを持たせるかテーブル分割をするか。
めんどくさくなってきた。
0648NAME IS NULL
2015/09/04(金) 21:21:33.19ID:???確かに面倒臭いですねw
アンチパターンを気にしすぎてテーブル数が増え、設計がややこしくなるなら、
アンチパターンでも分かりやすい設計の方が良いんじゃないか？って思うんですよね。
自分は正規化やらアンチパターンやら気にしすぎて、何も作れなくなってるんで。
0649NAME IS NULL
2015/09/04(金) 21:26:00.22ID:???特定のセパレータで複数の情報を書いたらいいのか？
どうせ、必須項目の値は入るから、全レコードNullじゃなくなる。
無駄はないような気がする。
0650NAME IS NULL
2015/09/04(金) 21:27:39.91ID:???テーブル数が増えたから設計がややこしくなるなんてことはないと思うけど。
JOINが増えて面倒ってなら分からなくもないけど、必要ならビュー作ればいいわけで。
どういうときに分かりやすい設計とかややこしい設計って思っているのか、一度考え直してみたらどう。
>>649
JSON型万能説の話か
0651NAME IS NULL
2015/09/04(金) 21:30:08.15ID:???ビューも良いんですが、単純にSQLのコードが長く異なる事態が、
ミスやバグに繋がると思うんですよね。
やっぱりJOINは出来るだけ少なくしたほうが、それらのリスクは減るじゃないですか。
テーブルに関しても、多いより少ないほうが把握しやすいのでは？
脳内でER図を描くにしても、少ない方がテーブル名だけ見て把握できるし。
0652NAME IS NULL
2015/09/04(金) 21:31:51.72ID:???俺は正規化は決してしないっていうのなら無理には止めないけど、するんでしょ。
どこまでやって、どこからやらないのかは線引きできる？
0653NAME IS NULL
2015/09/04(金) 21:34:59.57ID:???第三正規化までは積極的にやるべきだと思いますが、
それ以降はしなくて良いと思う時は有りますね。
あと、「削除フラグ」や「退会理由」なんかも別に1つのテーブルで良いとは思います。
0654NAME IS NULL
2015/09/04(金) 21:38:38.18ID:???case 削除フラグ when true then 削除 else
case when 認証コード is null then 認証済み else 未認証 end
end as 状態
ってすんの？
0655NAME IS NULL
2015/09/04(金) 21:42:09.53ID:???そのやり方とは違うけど、自分ならこうするかな
#認証済みのレコード取得
SELECT * FROM アカウントテーブル WHRE 状態=認証済み
#退会済みのレコード取得
SELECT * FROM アカウントテーブル WHRE 状態=退会済み
0656NAME IS NULL
2015/09/04(金) 21:42:37.86ID:???状態に削除を含めずに削除フラグを持たせるのはなぜ？
0657NAME IS NULL
2015/09/04(金) 21:46:25.48ID:???実際に正規化て何？レベルのDB見たらそんなの言えなくなる
作るタイミングでわかるバグやミスなんかより正規化してないDBの運用のが数十倍リスク高い
0658NAME IS NULL
2015/09/04(金) 21:49:28.84ID:???正規化なんて何？レベルなら確かにそうですけど、
私があなたと話しているレベル（退会理由や認証のカラムを1つにまとめるか分けるか）
程度なら、そう問題ないんじゃないですかね？
ちょっと例が極端すぎると思うんです。どこかで落とし所をつけないと
0659NAME IS NULL
2015/09/04(金) 21:51:08.83ID:???削除と退会は違うからじゃないかな
退会しても削除したい/したくないってケースはあるだろうし。
0660NAME IS NULL
2015/09/04(金) 21:58:55.49ID:???長らくほぼマンツーで話してた俺と>>657は違うよ。
>>657の話も分かるけど、>>658は第三正規形までは持っていくとのことなのでスジが違うね。
>>659
じゃあ、その「削除」ってつまるところ何？ってところが削除フラグの話の根底にあるんじゃないかな。
たとえば非表示にしたいだけなのか、運用上はもういない扱いにしたいのか。
前者ならふさわしいフラグなり状態なりがあるだろうし、後者なら履歴テーブルに移動してしまえばいいのでは、と。
0661NAME IS NULL
2015/09/04(金) 22:01:10.70ID:???よく続くなこの話
0662NAME IS NULL
2015/09/04(金) 22:23:03.08ID:???0663NAME IS NULL
2015/09/04(金) 22:26:37.63ID:???ユーザーに何て言い訳したら良いんだろうか？
そういう話題はこのスレのテーマとは違うのかな？
0664NAME IS NULL
2015/09/04(金) 22:31:23.60ID:???0665NAME IS NULL
2015/09/04(金) 22:47:34.19ID:???退会した顧客のデータは速やかに削除します、みたいな規約にしているところが多いから、
住所や電話番号みたいな個人データを残しておくのは問題。
そういう点でも、退会履歴テーブルを用意してユーザID、退会日、備考くらいの
最低限の情報を書き込む運用がいいんじゃないかなーと。
0666NAME IS NULL
2015/09/04(金) 22:59:41.04ID:???ユーザーIDを残す意味は何なの？残すなら名前じゃないの？
リレーションしているテーブルも削除するんだろうし。
0667NAME IS NULL
2015/09/04(金) 23:01:49.80ID:???> 新たな話題
ループしまくりですけど...
0668NAME IS NULL
2015/09/04(金) 23:04:12.04ID:???そら知ってる人からしたら「ループした話題」だろうよ。
でも、元ネタのスライドショーしかりで、疑問に思う人がいるから話題人なるんだろ
全部自分中心で考えていたら世話ないよ
0669NAME IS NULL
2015/09/04(金) 23:14:06.57ID:???なに突っかかってるのか知らんけど、定期的にわく話題だから「新たな」じゃねーだろって話
0670NAME IS NULL
2015/09/04(金) 23:16:19.48ID:???0671NAME IS NULL
2015/09/04(金) 23:22:39.27ID:???突っかかってるのはむしろお前じゃね？
俺の主張は
・話題にしている奴が居る
・それに対して意見を言う奴が居る
この事に対して第三者が「過去に話したことだから話すな」ってのは
自分勝手すぎるだろって言いたいだけだが。
過去スレ追えって言うわりに、どのスレ・レスの事か出さないしな。
（過去スレを誰でも参照できると思っているのかもしれないが
0672NAME IS NULL
2015/09/04(金) 23:25:04.84ID:???何が気に入らないのかわからないけど
0673NAME IS NULL
2015/09/04(金) 23:25:26.73ID:???クソガキが来るスレじゃねぇだろ
0674NAME IS NULL
2015/09/04(金) 23:26:41.52ID:???0675NAME IS NULL
2015/09/04(金) 23:46:04.22ID:???> 話すな
> 過去スレ追え
いったい誰がそんなことを言ってるんだ？
妄想激しすぎ w
新たな話題じゃないって書いてるだけだろ
0676NAME IS NULL
2015/09/04(金) 23:48:35.39ID:???どうせ1年持たないでITから居なくなる奴だ
0677NAME IS NULL
2015/09/05(土) 00:01:18.89ID:???よし、今から別の新たな話をしよう。
トピックはこれにしよう。
ユーザに複数の電話番号を持たせるとして、
ユーザ情報テーブルと、ユーザ電話番号テーブルに分割するか、
ユーザ情報テーブルに配列型で電話番号を複数持たせるか。
0678NAME IS NULL
2015/09/05(土) 00:02:25.77ID:???お前らって寂しいおっさんなんだな
今まで何年もITにいてその地位なんだから、たかが知れてるかw
0679NAME IS NULL
2015/09/05(土) 00:03:40.25ID:???ある会社において、社員番号は再利用されることがなく、ユニークなものである。
ここで、社員テーブルを作るにあたり、サロゲートキーを追加すべきか否か。
これなんて新しい話題じゃないかな？
0680NAME IS NULL
2015/09/05(土) 00:06:38.90ID:???喧嘩腰に話すと議論になりませんよ。それこそ「突っかかってる」では？
自分の主張は「知らない人にとっては”新しい”」なんですけど。
あなたは詳しいかもしれない。でもそうじゃない人はいる。
このスレは詳しい人専門のスレじゃない。誰も書いていい。
現に>>585のこの一言で、削除フラグがそれに波及する議論がされている。
あなたみたいに詳しい人にとっては「面白く無い」でしょうけど、
そうじゃない人はあなた以外に複数居てやりとりしてる。
それを横から茶々入れるのは止めません？何も得しないでしょ。
0681NAME IS NULL
2015/09/05(土) 00:09:00.81ID:???大人なら素直に静観しましょうや。ループしたと思っても、復習するつもりでさ。
0682NAME IS NULL
2015/09/05(土) 00:18:57.60ID:???またこの話かよ程度に静観していたようにも見える。
なんで>>668は喧嘩腰なんだろうな。
0683NAME IS NULL
2015/09/05(土) 00:29:11.50ID:???> そうじゃない人はあなた以外に複数居てやりとりしてる。
そうじゃない人って、詳しくない人ってことだろうと思うけれど、具体的に安価をつけてもらえないだろうか。
0684NAME IS NULL
2015/09/05(土) 00:47:03.55ID:???要件とそのDBMSでの配列型の機能次第
>>679
サロゲートキー論争は定期的に話題になって、大概荒れてうやむやになる
つか分かってててわざと言ってるだろ、お前
0685NAME IS NULL
2015/09/05(土) 00:54:24.10ID:???> つか分かってててわざと言ってるだろ、お前
そりゃあもう。
>>668がどう思ってくれるか知りたくてな。
0686NAME IS NULL
2015/09/05(土) 01:22:24.37ID:???それは悪かった。誤解してた。謝罪する。
てっきり、自分の意図しない流れを受け入れられない人だと思ってたよ。
>>683
それこそ「過去スレ見ろ」って事にならないかな？
なんで俺にだけそこまで粘着して嫌がらせのごとく突っかかるのか知らないけど。
>>685
君みたいな人がいるから、同じ話題を嫌がる人がいるというのはよくわかりました。
でも、それを実際にやって証明しようとするのは、凄く性根が腐ってるんですね。
0687NAME IS NULL
2015/09/05(土) 01:25:30.78ID:???ま、こうやって横から意見出してる人間を無理から叩こうとしたり
”わざと”自分が知ってる事をやる人間がいるんだもん。
せっかく盛り上がってた話も台無しだね。俺にもその責任があるわ。
まさかここまで粘着されると思ってなかった。
削除フラグやその関連の話したかった人、ホントすまん。
0688NAME IS NULL
2015/09/05(土) 01:45:19.25ID:???個人情報を管理するテーブルで削除フラグはやめて欲しい、マジで
0689NAME IS NULL
2015/09/05(土) 02:48:29.57ID:???>>686の安価先および削除フラグの話をしていたのは全部俺でして。
話してた相手の方ですか？
0690NAME IS NULL
2015/09/05(土) 03:00:59.35ID:???>>686
> 君みたいな人がいるから、同じ話題を嫌がる人がいるというのはよくわかりました。
なぜそんな勘違いをするのか検討がつかない。
DB設計の経験があるなら、あなたも一度は話題にしたことがあるであろう
ありがちなものを「新たな話題」として提示されたときにどう思うかだよ。
あなたが同じ話題を嫌がる人だと証明しようとなんてしていない。
それとも、過去にしたことのある話題を振られたら嫌だったの？
0691NAME IS NULL
2015/09/05(土) 05:27:51.29ID:???> 喧嘩腰に話すと議論になりませんよ。
お前が言うなよ...w
>>668
> そら知ってる人からしたら「ループした話題」だろうよ。
0692NAME IS NULL
2015/09/07(月) 02:19:00.21ID:???テーブルって同じ実体でも読み込みや更新頻度が全然違うときは分けるべきですか？
0693NAME IS NULL
2015/09/07(月) 02:39:52.05ID:???まずは分けずに作ってみたら。
0694NAME IS NULL
2015/09/07(月) 06:17:21.74ID:???> 分けるべきですか？
なんでそう思ってるのか知らんけど性能とかを気にしてるなら、少なくともこんなスレに質問してる間はデータベースに任せて普通に組んだ方がいい
0695NAME IS NULL
2015/09/07(月) 10:19:27.91ID:???> 退会しちゃう（しちゃった）人の履歴をどこまで残すかって事でしょ。
> 普通なら、退会と同時（多少時間的な猶予は取るかもしれないけど）に
> 個人情報の抹消はしないといけなくなる。
みたいなこと以外を「例外」だと思う人と、そうは思わない人で意見が違うのかもね。
退職した人の前月の勤怠情報は見ることができないといけないし、
今現在はラインナップから外れた商品の処理も行う必要があるし、
アカウント削除された人が起こしたチケットも処理しなければならない。
0696NAME IS NULL
2015/09/07(月) 10:30:06.58ID:???退職者の場合は、税務上の記録保存の義務やら、
年金支払いの業務やらで、その後も情報が必要だからじゃないかな。
商品の場合は、販売終了しても保守義務が残ってますし。
それなりの期間情報を持ってないといけないでしょうね。
アカウント削除された人への対応と言うことで､
猶予期間を持たないといけないかもって思いました。
実際サイトによっては、退会後一ヶ月間は取り消し可能です
って言っているところもあります。
0697NAME IS NULL
2015/09/07(月) 11:31:05.85ID:???>>693
ありがとうございます
まず、普通にやります
0698NAME IS NULL
2015/09/07(月) 12:38:35.30ID:???アカウントが削除された人が起こしたチケットも表示すればいいのでは。
というか、そういう話が出ていたような気がする
0699NAME IS NULL
2015/09/07(月) 12:51:59.57ID:???> アカウントが削除された人が起こしたチケットも表示すればいいのでは。
その実装方法として削除フラグで十分な場合もあるのに、なんだか最近バズってる削除フラグ
関連の人たちは、「後から参照することなんてまれだろ」とか「思考停止」とか言ってるのに
違和感を感じてた。
0700NAME IS NULL
2015/09/07(月) 14:06:54.57ID:???http://qiita.com/Jxck_/items/156d0a231c6968f2a474
0701NAME IS NULL
2015/09/07(月) 14:55:29.08ID:???すくなくとも、そこの内容(コメントでのやりとりまで含めて)を
ちゃんと理解した上での議論とは思えんレベルの話しかされてないけど
0702NAME IS NULL
2015/09/07(月) 15:13:28.30ID:???0703NAME IS NULL
2015/09/07(月) 15:14:29.22ID:???このスレの話じゃないよ。
>>700の記事以降、散発的に削除フラグの話がブログに投稿されたりして、
最終的に「論理削除 Casual Talks #1」というイベントで完結した。
あのスライドもt-wada作成だから話題になってるんじゃないかな。
実際のトーク内容はわからないが。
0704NAME IS NULL
2015/09/07(月) 15:18:17.49ID:???> 普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を
> 話してきました。
http://moro.hatenablog.com/entry/2015/08/31/212013
とかいう話なんで、推して知るべし。
0705NAME IS NULL
2015/09/07(月) 15:19:00.04ID:???0706NAME IS NULL
2015/09/07(月) 15:32:02.57ID:???http://ohbarye.hatenablog.jp/entry/2015/09/01/172400
俺的には、どっちが思考停止やねんって感じなんですが。
0707NAME IS NULL
2015/09/07(月) 15:46:10.29ID:???消すにしても転記できるならそっちのがよさげ
何年も経つとえらいことになるけどもうどうしようもないしなあ
0708NAME IS NULL
2015/09/07(月) 15:55:27.05ID:???0709NAME IS NULL
2015/09/07(月) 16:28:57.05ID:???これが実装コストが一番低いんだよな
保険的な意味合いで要件的に不要でもそうする事は多い
これを思考停止ととるか（バッド）ノウハウと考えるか
0710NAME IS NULL
2015/09/07(月) 17:01:33.00ID:???0711NAME IS NULL
2015/09/07(月) 17:47:26.85ID:???バックアップもあるしログに気を使わないとならんこともあるからな
0712NAME IS NULL
2015/09/07(月) 18:09:39.89ID:???0713NAME IS NULL
2015/09/07(月) 18:28:24.46ID:???極論にしか辿り着けない人もそりゃ出るわね
客の要件を聞かない、聞いても考えない、
そんな一歩目から足踏み外してる人向けのスライドなんだし
0714NAME IS NULL
2015/09/07(月) 20:51:11.67ID:???実装コストが低いってかなり大事だよな。
なんかやたらと正規化・論理的な設計を好む流れあるけど。
同様に「仮登録」も、同じテーブルに入れて状態フラグで判定してもいいと思うんだよな。
0715NAME IS NULL
2015/09/07(月) 20:57:29.92ID:???そうならないときに、ゴミが残るっていやがるお客がいたっけ。
しかも、シリアルが飛ぶのも駄目だとか言い出したな。
0716NAME IS NULL
2015/09/07(月) 21:00:04.68ID:???その気持ちは分かるけど、俺は逆に仮登録と本登録の違いぐらいで
全く同一のテーブルを複数用意する事に違和感感じるんだよな
0717NAME IS NULL
2015/09/07(月) 21:23:24.18ID:???メールアドレスのベリファイ目的なら、仮登録待ちメールアドレスと認証コードだけのテーブルでいいだろうし。
0718NAME IS NULL
2015/09/07(月) 21:46:35.19ID:???顧客情報のみならまだしも、ECなら購入履歴とかお届け先とか
そういった関連テーブルも物理削除して履歴テーブルに残すべきなのだろうか
0719NAME IS NULL
2015/09/07(月) 22:13:20.15ID:???それなら消せないんじゃないですか。
お届け先も、同様に、どこに届けたかなので、消せないと思います。
今後のサポートで必要でしょうし、税務上も消すとまずいと思います。
0720NAME IS NULL
2015/09/07(月) 22:36:01.10ID:???ということはだよ、顧客テーブルも削除フラグで良くないか？ってなるんだよな。
顧客テーブルだけ履歴に移して、関連テーブルは削除フラグで見えなくする。
これこそおかしくないか？って俺は感じるんだよ。
0721NAME IS NULL
2015/09/07(月) 22:40:15.16ID:???残さなくてはいけないのは販売の記録でしょう。
商品に対する将来のサポートで必要な販売情報と、
顧客テーブルにある情報は違うと思うんです。
間違っているのかなあ。
0722NAME IS NULL
2015/09/07(月) 23:21:57.25ID:???顧客テーブルがないとサポートするのに”誰に”売ったか分からないのでは？
0723NAME IS NULL
2015/09/07(月) 23:31:38.34ID:???0724NAME IS NULL
2015/09/07(月) 23:45:41.28ID:???テストでデータ蓄積されてくると、たんなる削除だと
>>722みたいなことになるので削除フラグに行き着く
でもそもそも削除するようなレコードは履歴に残しちゃいけないわけで
テーブル増やして適切に対応するべきだけど
カラムが増えるのは躊躇しないくせにテーブルが増えるのは嫌がる人が多い
0725NAME IS NULL
2015/09/07(月) 23:54:42.04ID:???俺もテーブル増えるのは嫌がる方なんだが、
履歴とはいえ、似たようなテーブルが増える事ってアンチパターンにならないの？
0726NAME IS NULL
2015/09/07(月) 23:56:06.77ID:???配達先の住所、電話番号を記録しておけば良いんじゃないかな。
これは、いわゆる販売伝票と同じですよね。
顧客テーブルは、客から申し出があれば物理削除しないといけないでしょうｊが、
こちらは消すわけにはいかないでしょう。
0727NAME IS NULL
2015/09/08(火) 00:01:05.15ID:???電子マネーの番号と紐付けられるのすら嫌がる人も多いから、個人を特定できない状態で保存しているというのに。
0728NAME IS NULL
2015/09/08(火) 00:18:02.16ID:???配達先が購入者でない場合は？贈答品とかだとそういうケースも有るよね。
ということはやはり、元となる購入者の情報（顧客テーブル）も
削除できないってことになると思う。
0729NAME IS NULL
2015/09/08(火) 00:28:00.26ID:???その商品の販売に当たり、何を記録として残さないといけないか？と言うことじゃないですかね。
顧客テーブルとして残すというより、その販売レコードに、支払いをした人（購入者）の情報を
入れるだけだと思うんですが。お金の動きの記録と、販売物の動きの記録とが残る感じです。
0730NAME IS NULL
2015/09/08(火) 02:04:24.98ID:???その設計を頭の中で描けてる？
顧客テーブル→注文履歴→注文商品→商品情報
→お届け先
ってのが一般的な繋がりだと思うけど、
注文履歴（販売レコード）に購入者の情報まで入れちゃうと、
それこそ正規化出来てないんじゃないか？
0731730
2015/09/08(火) 02:11:07.35ID:???注文履歴に顧客情報必要だわ。顧客情報編集されたら情報が変わる。
0732NAME IS NULL
2015/09/08(火) 08:29:49.75ID:???0733NAME IS NULL
2015/09/08(火) 08:47:17.59ID:???客に見せるためのシリアルと別に内部処理用の代理キーをわざわざ用意せにゃならん流れだなそれ、面倒くさ
0734NAME IS NULL
2015/09/08(火) 10:09:03.44ID:???> 顧客の要請に応じて個人情報は消さにゃならんのに、注文履歴は残さにゃならんとは。
まぁ、売上分析とかありますし……。
0735NAME IS NULL
2015/09/08(火) 10:29:23.59ID:???注文履歴に残る顧客IDはどうするの？って聞かれたんですよ
同じ事態になるヌルオブジェクトパターンは採用できない
だからNULLにする、NOT NULL制約なしですよ、背筋がゾゾゾー！って
でも外さないといけない
やだなーこわいなーやだなー
って運用してたら、出たんです
誰も知らない注文履歴が…
0736NAME IS NULL
2015/09/08(火) 11:17:08.95ID:???するのが当たり前というか適切な対処法のように感じる。
どうせアプリ側でも削除する時に「元に戻せませんよ？」メッセージ出すだろうし。
で、退会した奴が犯罪者とか曰くつきの奴で情報開示を求められた時は、
DBバックアップしていたデータを復元して提示すると。
Web系で利用者数も少ないなら、こんな管理方法でもおｋな気がする。
0737NAME IS NULL
2015/09/08(火) 11:43:16.92ID:???> 個人情報保護法的には、会員辞める＝会員が登録したレコードを削除
> するのが当たり前
という要件が世界の全てなのかな？
0738NAME IS NULL
2015/09/08(火) 12:00:24.72ID:???さすがにそこまで極論を述べる気はないです
0739NAME IS NULL
2015/09/08(火) 12:14:31.79ID:???個人情報保護法的には、レコード(行)を削除する必要なんてないんじゃね
ただそのレコードに記録された特定個人情報が無くなれば良いだけだろ
たとえば名前を空白とか「名無し」とか「削除」とかにすればいい
情報開示をもとめられても、削除した情報は削除したと開示するだけ
保存義務がある情報を削除してたらどうなるか知らんが
0740NAME IS NULL
2015/09/08(火) 12:34:08.76ID:???>たとえば名前を空白とか「名無し」とか「削除」とかにすればいい
本当にそんなことしてるのか？
0741NAME IS NULL
2015/09/08(火) 12:50:39.26ID:???0742NAME IS NULL
2015/09/08(火) 13:06:07.17ID:???0743NAME IS NULL
2015/09/08(火) 13:28:52.12ID:???こういう奴が、削除フラグとか論理削除とかの単語を見ると発狂するのかも
0744NAME IS NULL
2015/09/08(火) 13:47:43.27ID:???既に削除フラグや論理削除に発狂している人達がいるわけで・・・
0745NAME IS NULL
2015/09/08(火) 15:26:13.67ID:???> 削除フラグだろうがstatusだろうがdelete_atだろうが似たり寄ったり。
これ全部、論理削除
0746NAME IS NULL
2015/09/08(火) 15:35:15.32ID:???削除したいけど削除したら困るから何かと理由をつけて残していますというだけで、
つまりは「削除できませんでした(orしたくありません)」の意思表明なんだよね。
0747NAME IS NULL
2015/09/08(火) 15:37:22.76ID:???削除しても困らないけどとりあえず残しとくという話でないの？
0748NAME IS NULL
2015/09/08(火) 15:43:29.76ID:???売上管理ができないとかなんとか。まさかｗって思うよね。
0749NAME IS NULL
2015/09/08(火) 16:04:08.78ID:???行うにしても履歴を残さないとまずい事が起きる。
0750NAME IS NULL
2015/09/08(火) 17:37:35.06ID:???経理処理の時に精査するんじゃないの？
わざわざDBのデータ参考にするって、外部のサービスでも使わないかぎり、
証拠になりづらいと思うんだけど。（値なんていくらでも操作できるんだし
0751NAME IS NULL
2015/09/08(火) 17:48:28.20ID:???「当該情報に含まれる…記述により」(それ自体、あるいは他の情報と照合して)特定できる、なので
個人情報とは、個人がどこの誰かを述べる機能を担う部分だけを指すのでなく
特定個人と結びつく情報の全体をさす。
注文履歴にお客様IDが入っていないとは考えにくいから、
個人情報保護法で注文履歴は保護される。
0752NAME IS NULL
2015/09/08(火) 17:56:52.41ID:???履歴とIDだけ流出したって何の情報にもならない
0753NAME IS NULL
2015/09/08(火) 18:23:59.12ID:???もっと勉強しなよ
0754NAME IS NULL
2015/09/08(火) 18:25:54.13ID:???0755NAME IS NULL
2015/09/08(火) 19:24:06.76ID:???0756NAME IS NULL
2015/09/08(火) 19:44:00.31ID:???独自IDと違って変わらない番号だから取り扱いに気を使いそうだ
0757NAME IS NULL
2015/09/08(火) 23:04:24.85ID:???個人情報保護法的に削除してって言われた個人情報をバックアップデータに保存してるのは許されるんだっけ？
詳しい人解説よろ
0758NAME IS NULL
2015/09/09(水) 00:24:03.03ID:???法が注文履歴を個人情報として保護するかどうかは、流出するかしないか、
流出先あるいは事業者が外部に提供した先で紐づくかどうかは無関係。
「当該情報を保有する事業者において」他の情報との照合ができれば個人情報となるという解釈とされているから。
お客様IDを削除または一方向ハッシュ関数などで変換すると今度の改正で出来た「匿名加工情報」になる。
0759NAME IS NULL
2015/09/09(水) 00:44:03.13ID:???今度の改正で「個人識別符号が含まれるもの」が陽に追加されてた。
http://www.cas.go.jp/jp/houan/150310/siryou3.pdf (11-12ページ)
ここも参照
http://japan.zdnet.com/article/35066449/2/
0760NAME IS NULL
2015/09/09(水) 01:46:42.69ID:???他の情報とどうやって照合するの？
ただの数字しかないんだよ
0761NAME IS NULL
2015/09/09(水) 01:50:49.26ID:T/RvuaVF例えばSNSなんかの会員テーブルには、
アカウントとプロフィールと称したカラムが複数存在します。
ですので、1対1であっても垂直分割して
アカウント関係だけのテーブルと、プロフィール関係のテーブルを作る事があります。
こういうやり方はアンチパターンとして、やはり駄目なのでしょうか？
0762NAME IS NULL
2015/09/09(水) 07:50:49.87ID:???垂直分割がアンチパターンだってソースは？
ふつうアンチパターンだって説明してあるなら、そこになぜダメかも書いてあるだろ
0763NAME IS NULL
2015/09/09(水) 12:52:41.95ID:???「達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ」
って本に書いてありました。割と有名な本かと。
ですが、アンチパターンとしての意味は書いてあるものの、
要件毎については書いてないので、>>761みたいな場合でも
アンチパターンに該当する（やっちゃ駄目）なのかと思い、質問しました。
0764NAME IS NULL
2015/09/09(水) 13:40:16.82ID:???確認したら、ちゃんと理由がかかれてたけど。
> 欠点1 分割する意味的な理由がない これはすべてのパターンのテーブル分割に該当することですが、
> このようにテーブルを分割する理由は、正規化の理論からは出てきません。純粋にパフォーマンスという
> 物理レベルの要請によるものなので、逆に言うとその要請がなければ実施する必要のないものです
0765NAME IS NULL
2015/09/09(水) 14:31:15.51ID:???ですので、>>763の4行目にも書きましたが、
>>761こういう要件についてはどうかな？と思い、質問しました。
0766NAME IS NULL
2015/09/09(水) 14:33:19.27ID:???？
要請があったのなかったの
0767NAME IS NULL
2015/09/09(水) 14:37:17.18ID:???何の要請ですか？
0768NAME IS NULL
2015/09/09(水) 14:38:30.49ID:???いや。この日本語の意味分かってんのかなーって。
> 純粋にパフォーマンスという
> 物理レベルの要請によるものなので、逆に言うとその要請がなければ実施する必要のないものです
0769NAME IS NULL
2015/09/09(水) 14:41:18.24ID:???もちろんです。>>763にも書きましたが、本を読んだ上で質問しているので。
とりあえずらちがあかないので、>>761でも正規化の概念からアンチパターンだとします。
0770NAME IS NULL
2015/09/09(水) 14:43:45.69ID:???アカウントテーブルにプロフィールを載せるべきか否かって話をしようとしているなら、
そこに垂直分割なんて言葉は出てこないはずだもんな。本を読んだなら。
0771NAME IS NULL
2015/09/09(水) 14:52:49.09ID:???すくなくとも翔泳社のサイトで見れる範囲で確認したとろこでは、それは水平分割の話だが
すべてのパターンってのがどこまでかかってるのかはよくわからんけどな
0772NAME IS NULL
2015/09/09(水) 14:54:49.89ID:???いや、キレてないです。
著者の言うとおり、パフォーマンスの問題がある時は分割する事を考えろ
ってスタンスは確かにそのとおりだと思うのですが、
設計って開発前段階の事じゃないですか。
開発前で1テーブルにカラム数が増える。
これは1対1でも用途毎に分けるべきじゃないか？
それも正規化の内に入らないか？いやいや、アンチパターンに変わりないか。
そう、色々と考えて質問した次第です。
「俺はこうしてるよ」とかそういう意見が聞きたかったのですが、
日本語の意味とか質問の粗を指摘されているようで話が進まないので、
「それでは>>761はアンチパターンという事で、皆さんも使わないんですね」
として、理解させていただいた次第です。
0773NAME IS NULL
2015/09/09(水) 15:03:11.37ID:???そもそも性能対策としてテーブル分割するのはバッドノウハウだって話なんじゃないのか
0774NAME IS NULL
2015/09/09(水) 15:09:28.15ID:???そう書いてくれりゃいいのに。
逆に言えば、意味的に異なる情報群が存在するとき、
関係が1対1のものはすべてひとつのテーブルにまとめるべきか否か。
で、>>772の出した結論は、まとめないのはアンチパターンであると。
0775NAME IS NULL
2015/09/09(水) 15:13:24.54ID:???いや、私自身の結論は全てに>>761で書いてます。
「やっぱりアンチパターンとして駄目ですかね？」って聞いてるわけですから。
ですが、「アンチパターンだけどこういう時に使うよ」とか
「それはアンチパターンとは思わない」とか、”自分なりの意見”があると思います。
ですが、ここまで私にそれを指摘してくれた人は居ません。
”自分はこうしてる・こう思う”という意見が聞きたかったのですが、
結局、自分で納得するしか他ありませんでした。
0776NAME IS NULL
2015/09/09(水) 15:15:35.57ID:???そもそも、ここでいう「垂直分割」に当てはまらないよねというのが、すでに提示した俺の意見だけど。
0777NAME IS NULL
2015/09/09(水) 15:19:52.22ID:???では、「どうして垂直分割に当てはまらないと思ったか」
を教えてくれたら良かったのではないですか？
上で話されている削除フラグの件は、皆さん自分なりの考え方をされています。
頭ごなしに「削除フラグはアンチパターンだから駄目」とかそういう決め付けをせずに、
自身の経験と考えのもと、「俺はこう思う」と話をされています。
ですが、あなたは基本的に私の質問を指摘したいだけで、
自分の意見も答えの導きもされていないように感じます。偉そうで申し訳ないですが。
0778NAME IS NULL
2015/09/09(水) 15:27:49.06ID:???正規化のみでは発生しないけれど、モデリングの観点で分割すべきと判断した結果生まれた1...1のリレーションでしょ？
今言っている「垂直分割」は、パフォーマンスを理由に、あるモデルをそれ以上分割することでしょ？
だから違うものだよ。
0779NAME IS NULL
2015/09/09(水) 15:30:29.96ID:???>バッドノウハウ(アンチパターンの事だな)は、正規化からは導かれません。また、非正規化によって生まれるわけでもありません
って書いてあるのに、なんで
>正規化の概念からアンチパターンだとします。
という結論になるのか理解できん
0780NAME IS NULL
2015/09/09(水) 16:23:11.48ID:???「こういう要件」って言われても、会員を管理することと、アカウントとプロフィールを管理するという
だけで、それは要件とは言いません。
それら情報の位置づけはどうなのか、データの発生時期はいつなのか、それら情報の公開範囲は
どうなのか等々、そういうのが要件です。
そういう要件を加味してモデリングするのが設計です。
「会員がいてアカウント情報とプロフィールがあるんだけど、それを別テーブルにするのは
アンチパターンですか？」という問いには、誰も答えられません。
>>771
「すべて」には水平分割も垂直分割も含まれています。
0781NAME IS NULL
2015/09/09(水) 16:38:12.51ID:???0782NAME IS NULL
2015/09/09(水) 16:52:59.54ID:???> これは1対1でも用途毎に分けるべきじゃないか？
用途毎に分けるべき。
> それも正規化の内に入らないか？
用途毎に分けることを正規化とは言わない。
> いやいや、アンチパターンに変わりないか。
用途毎に分けることは、アンチパターンではない。
0783NAME IS NULL
2015/09/09(水) 16:55:45.60ID:???「課金情報」と「請求情報」は分けるべきか否か。
0784NAME IS NULL
2015/09/09(水) 16:59:04.24ID:???良薬口に苦しって昔の人も言ってたし。
0785NAME IS NULL
2015/09/09(水) 17:03:17.24ID:???EC-CUBEとか1つのテーブルでアカウントとプロフィールを一緒くたにしてるけど
俺の感覚では、あれは酷いなって思ったけどなぁ
0786NAME IS NULL
2015/09/11(金) 23:18:54.06ID:cnT3g/XIよかったら、「BeLongs! - トップ」で検索してみて！
0787NAME IS NULL
2015/09/12(土) 00:15:45.91ID:???0788NAME IS NULL
2015/09/12(土) 00:18:47.06ID:???0789NAME IS NULL
2015/09/12(土) 02:14:01.61ID:???0790NAME IS NULL
2015/09/14(月) 08:59:25.35ID:???Androidアプリで使用するデータベースの設計をしています。その中でユーザーにアンケートを定期的に配信してデータを管理したいと考えています。
初めは、回答ID、設問ID*、ユーザーID*、回答結果みたいなテーブルを考えていますが、何となくこれでいいのかなーと疑問があります。
このような持ち方の場合アンケート配信が増えれば増えるほどレコードは増えていきます。集計してデータを使う時に負荷は大丈夫なのかな？と素人ながらに考えてしまいます。
データの利用方法はアンケート結果を元にユーザーを絞り、関係性の高いユーザーに特定の更新情報をプッシュ通知するという使い方なので、頻度がかなり高いです。
検索ワードでも結構なのでヒントを頂けないでしょうか。よろしくお願いいたします。
0791NAME IS NULL
2015/09/14(月) 09:46:32.25ID:???1回のアンケートの回答数なんてせいぜい数百件程度だろw
その心配は杞憂だから気にすんなw
0792NAME IS NULL
2015/09/14(月) 10:02:50.43ID:???ありがとうございます。気にせずに行きます。
0793NAME IS NULL
2015/09/14(月) 17:24:05.90ID:???RDBMSじゃなくてRedisとかがいいかもよ。
使ったことないけど。
0794NAME IS NULL
2015/09/14(月) 18:25:12.25ID:???この設計なら回答テーブルはほぼID管理になるから、
レコード数が数千万とかになっても大丈夫じゃないか？インデックスも効くし。
フリーテキスト（備考とか）を入力させたい場合は、別にテーブル作ればいいじゃん。
0795NAME IS NULL
2015/09/15(火) 10:55:56.48ID:???「関連性の高いユーザ」を決定するのに、常に全件検索になったりしない？
0796NAME IS NULL
2015/09/15(火) 11:03:42.87ID:???0797NAME IS NULL
2015/09/15(火) 12:12:27.15ID:???どういう関連性かわからないからなんとも。
ただ、「設問ID1を3と答えた男性のみ絞り込み」などの条件検索をする場合、
>>794の設計だとインデックスが効くから問題ないと思うよ。
気になるなら1度にSQLを実行しようとせずに、
まずは回答テーブルから条件に一致するユーザーIDを取得して、
それからユーザーテーブルを絞り込めばいい。
0798NAME IS NULL
2015/09/15(火) 12:48:52.29ID:???丁寧に議論して頂きありがとうございます。
あるジャンルに特化したQ&Aサービスの設計をしています。
QAサービスは質問内容がマニアックになればなるほど回答数が減ってしまいます。それを改善するために、質問内容や質問者の属性に近い人にのみ質問内容をプッシュ通知したいと考えています。
利用者全員に毎回プッシュすると、利用者はうっとおしくなるので、回答結果を見ながら少しずつプッシュするユーザーを広げていく仕組みです。
本当は沢山の係数を保持してベイジアンネットワークのような仕組みで自動的に絞り込みたいのですが、初心者の僕にはそのようなものを作るのは無理なので、最初は簡易的な仕組みを構築したいと考えています。
スタート時のアンケート結果はyes or noのみになるように考えています。
集計するタイミングは二通りになります。
2,3個の属性から該当ユーザーを絞り込み、さらにそこからランダムで数十人程度に絞り混むプログラムでの使用。
回答が集まらない場合に運用側が任意に再度集計し直して再配信するときに使用。
ディレクター経験はありますがプログラム、データベースの経験は皆無なので今は仕様を固めながらデータモデリングをしている最中です。
曖昧な内容の質問に対して議論して頂きありがとうございます。参考になります。
0799NAME IS NULL
2015/09/15(火) 13:09:35.90ID:???0800NAME IS NULL
2015/09/29(火) 21:57:10.96ID:SiAsvmBt利点があると書いてありましたが、それって利点なのでしょうか？
なんか、非正規化されたデータを扱うってだけじゃないかと
思いました。
0801NAME IS NULL
2015/09/29(火) 22:00:03.05ID:???0802NAME IS NULL
2015/09/29(火) 22:12:40.37ID:???本当にjoinを使わないことが利点だと書いてあったんだったらちょっとURL晒してみそ。
0803NAME IS NULL
2015/09/29(火) 22:32:20.58ID:SiAsvmBthttp://www.wingarc.com/product/dr_sum/lineup/engine/engine_01.html
このビックデータを扱う製品を調べているのですが、一番下に
「DB設計による正規化の作業は不要」とあるんですよ。
つまり、結合操作を利用しないことが利点として書かれていると思うのですが、
何か引っかかるものがありまして。。。
0804NAME IS NULL
2015/09/29(火) 23:05:39.51ID:???まあたしかに、そこに書いてある謳い文句もインチキくさいけどな。
そもそも正規化はパフォーマンスを目的にやるもんじゃないし、ユーザーが理解しやすい形式
云々については>>800の言うとおりだと思う。
0805NAME IS NULL
2015/09/30(水) 01:13:07.00ID:???まあ、単なる宣伝文句だな。言葉半分ぐらいに受け取っておくべし
0806NAME IS NULL
2015/10/02(金) 00:37:55.33ID:d8XiKdgT0807NAME IS NULL
2015/10/02(金) 04:47:54.88ID:???そのサイト・プロジェクト・アプリならではの設計をしていたりするので、
オーソドックスな使い方では無理だったりするし。
結局、設計思想まではパクれないってことで。
0808NAME IS NULL
2015/10/03(土) 12:14:09.12ID:/Pljy+Uz上のレスに削除フラグの話がありまして、
「削除フラグを止めて、削除履歴が必要な場合は別テーブルに保存する」
というのがベストプラクティスな方法としてオススメされているかと思います。
そこで疑問に思ったのが、ユーザーデータやユーザが投稿したテーブルのデータは
どのように扱うべきなのでしょうか？削除（退会/解約）申し込みがあった時点で、
DBから全ての関連データを削除するべきでしょうか？
それともユーザーテーブルのみ削除して、
関連テーブルのデータは残しておくべきでしょうか？
要件や仕様次第というのは分かりますが、オーソドックスな方法として、
「まずはこうするべき」という考え方が知りたいので、ぜひ教えてください。
0809NAME IS NULL
2015/10/03(土) 13:40:32.70ID:???>関連テーブルのデータは残しておくべきでしょうか？
参照整合性を考えるとあり得んな
マスタレコードを履歴テーブルに移動させるなら、そのタイミングで
関連テーブルも履歴テーブルに移動させるのが順当だろ
0810NAME IS NULL
2015/10/03(土) 13:52:06.57ID:???>マスタレコードを履歴テーブルに移動させるなら、そのタイミングで
>関連テーブルも履歴テーブルに移動させるのが順当だろ
それだとユーザーが使用する関連テーブルが複数あると
その数だけ履歴テーブルも増えるわけですが、おかしくないでしょうか？
マスターを履歴テーブルに残すだけなら、最低限「どのユーザーが削除したか」
が分かりますし、後でバックアップから復元もできます。
でも、関連テーブルも同じように「履歴」とするのは違和感あります。
0811NAME IS NULL
2015/10/03(土) 14:02:29.62ID:???履歴を別テーブルにして持つなら、履歴とるテーブル数だけ履歴テーブルが必要なのは当然
なにがおかしいのか分からんが
>関連テーブルも同じように「履歴」とするのは違和感あります
お前の違和感はお前が解明して説明してもらわんと知らんがな
関連データってのがまさにトランザクションで履歴そのものでもあるってならほっとけば良いんじゃね
0812NAME IS NULL
2015/10/03(土) 15:04:38.72ID:???厳密に言うと、あり得んのは参照整合性が必須な場合だけであって、それが必要ない設計なら
別に問題ないな。
参照整合性が必須な場合というのはたとえば、サロゲートキーを使用していてマスターを削除すると
キーが意味を持たなくなる場合とか。
0813NAME IS NULL
2015/10/03(土) 18:49:33.94ID:???参照整合性が必要ないデータを関連データと呼ぶのか
0814NAME IS NULL
2015/10/03(土) 19:09:14.01ID:???そういう文脈以外で一般名詞として使うことはあるだろ。
>>808はどうみてもモデリングの用語として使っているようには見えないし。
0815NAME IS NULL
2015/10/03(土) 21:28:49.11ID:???ユーザーテーブル
└日記テーブルへの投稿
└写真テーブルへの投稿
└掲示板テーブルへの投稿*
└お問い合わせテーブルへの投稿*
このうち、*はユーザーテーブルを削除しても元テーブルに残しても良いと思う。
ユーザーの個人情報となる、日記・写真に関しては削除して、
履歴テーブルへの移行もいらないと思う。
0816NAME IS NULL
2015/10/03(土) 22:59:32.81ID:???0817NAME IS NULL
2015/10/03(土) 23:37:53.50ID:???退会するユーザに選択権があってもいいんじゃないって思う
0818NAME IS NULL
2015/10/04(日) 00:36:09.65ID:???投稿したユーザが分からん投稿は、投降したユーザの関連データなのか？
ユーザが削除されたときに、そのユーザの過去の投稿は履歴として保存する必要があるのか？
0819NAME IS NULL
2015/10/04(日) 00:43:43.58ID:???NULLになったり元に戻ったりするとか
おっかなくて触りたくないぜ
0820NAME IS NULL
2015/10/04(日) 03:52:52.19ID:???退会するユーザに選択権って、
「退会しますが、あなたのデータを削除しますか？残しますか？」
ってことか？そんなサイト見たこと無いんだが。あるなら教えてくれw
0821NAME IS NULL
2015/10/04(日) 08:29:49.58ID:???珍しい機能が付いてるな
0822NAME IS NULL
2015/10/04(日) 18:19:16.82ID:???0823NAME IS NULL
2015/10/04(日) 18:43:25.31ID:???0824NAME IS NULL
2015/10/05(月) 10:33:43.19ID:???答えは「論理削除しない」だ。物理削除すればいい。
ユーザーが投稿した関連テーブルも全てだ。
そして退会情報が欲しい場合は履歴テーブルに最低限の情報を移せばいい。
どうせ退会日時と退会理由ぐらいしか保存しないだろ。
万が一過去データを閲覧する必要があった場合にそなえ、
バックアップを取ればいいだけ。アーカイブから復元して確認しろ。
0825NAME IS NULL
2015/10/05(月) 10:34:11.90ID:???根本から勘違いしてるよ。
> そこで疑問に思ったのが、ユーザーデータやユーザが投稿したテーブルのデータは
> どのように扱うべきなのでしょうか？削除（退会/解約）申し込みがあった時点で、
> DBから全ての関連データを削除するべきでしょうか？
「削除すべき」場合にどう「削除」するのかというのが削除フラグの議論。
0826NAME IS NULL
2015/10/05(月) 10:40:34.39ID:???> 要件や仕様次第というのは分かりますが、オーソドックスな方法として、
> 「まずはこうするべき」という考え方が知りたいので、ぜひ教えてください。
まずはこうするべきなんて考え方はない。
削除するのかしないのかは要件次第。
例えば、BTSならあるユーザが「削除」されたとき、そのユーザがOpenしたTicketが消えたら困るだろ？
0827NAME IS NULL
2015/10/05(月) 10:43:28.40ID:???* ユーザは「削除する」
* そのユーザの過去の行動履歴(TicketのOpen/Assigned/Closeなど）は残さなければならない
という要件を満たす必要があり、「ユーザを削除する」方法はどうすべきかというのが
削除フラグの議論。
0828NAME IS NULL
2015/10/05(月) 10:46:18.54ID:???これに一票
基本は『ユーザは「削除する』をしてれば問題ないよ。
どうすべきか否かや履歴テーブルは次のステージだと割り切ればいい。
0829NAME IS NULL
2015/10/05(月) 12:23:44.90ID:???0830NAME IS NULL
2015/10/05(月) 14:35:05.67ID:???0831NAME IS NULL
2015/10/05(月) 15:16:31.13ID:???0832NAME IS NULL
2015/10/05(月) 15:40:29.31ID:???気持ち悪い
0833NAME IS NULL
2015/10/05(月) 16:24:42.06ID:???0834NAME IS NULL
2015/10/05(月) 16:46:16.36ID:???0835NAME IS NULL
2015/10/05(月) 17:09:06.58ID:???0836NAME IS NULL
2015/10/05(月) 17:56:57.57ID:???煽っても無駄だよ
知りたきゃググれ
0837NAME IS NULL
2015/10/05(月) 17:57:52.95ID:???0838NAME IS NULL
2015/10/05(月) 18:06:58.26ID:???削除フラグをやめる＝そのテーブルから削除する（履歴テーブルへの移動含む）
じゃないぞ。
日付情報を付加するというやり方もある。
0839NAME IS NULL
2015/10/05(月) 21:04:32.15ID:???0840NAME IS NULL
2015/10/05(月) 23:03:31.04ID:???「過去の行動履歴」を残すことが「ユーザー」を削除することの妨げになるってのがそもそもわからん。
それが問題となるような設計が前提だから問題なんじゃねぇの？と思う。
0841NAME IS NULL
2015/10/05(月) 23:49:39.13ID:???行動履歴テーブルにユーザ一名をそのまま入れてるとか？
それはそれであまり近くにいて欲しくないなぁ
0842NAME IS NULL
2015/10/06(火) 00:13:11.62ID:???されるべきではないし、履歴の方に持たせて更新異常の問題が発生するならば
正規化すればいいだけの話。
逆に、そういう問題がないのであれば別に履歴の方にあってもいいわけで。
0843NAME IS NULL
2015/10/06(火) 05:57:20.47ID:???要はテーブル見たら誰の履歴かわかりやすくするためだけだろ？
それってつまり履歴テーブルを見る事前提な設計なわけで、
削除フラグの代わりとして使うという意味ではなくなるぞ。
0844NAME IS NULL
2015/10/06(火) 06:38:16.04ID:???0845NAME IS NULL
2015/10/06(火) 10:07:23.63ID:???>>596のようなテーブルの場合、ユーザレコードをDELETEするとaccount_nameを表示できなくなってしまう。
では、Accountsの内容を、それを参照する全てのテーブルにコピーしておくかというと、大抵はそうはしない。
なぜなら、それは正規化に反するから。
この設計が問題であるとするなら、どう設計する？
0846NAME IS NULL
2015/10/06(火) 10:08:23.34ID:???0847NAME IS NULL
2015/10/06(火) 10:15:28.45ID:???・Accountsに削除フラグを追加
・Accountsに有効期限情報を追加
・Accounts_Archiveに削除されたユーザのレコードを移す
・削除されたユーザであることを示すAccounts_deletedテーブルを追加
などの実装手段があり、どれを選択しても「ユーザ削除後も、削除前と同じように
Ticketの表示ができるようにする」という要件は満たす。
「削除フラグ駄目絶対」な人は、このケースにおいても削除フラグ追加という実装手段は駄目だって
言ってる人が多いね。
0848NAME IS NULL
2015/10/06(火) 11:52:00.44ID:???0849NAME IS NULL
2015/10/06(火) 12:26:07.11ID:???>なぜなら、それは正規化に反するから。
データ発生時のAccountsの内容を保持するという要件なら正規化には反しないぞ
0850NAME IS NULL
2015/10/06(火) 12:37:52.49ID:???履歴を保持する必要があるのなら、現行のマスターに依存しないモデルを作れば良いだけだぞ。
0851NAME IS NULL
2015/10/06(火) 13:13:18.52ID:???> データ発生時のAccountsの内容を保持するという要件なら正規化には反しないぞ
微妙に異なる要件を入れないでくれよ。
誰も「データ発生時のAccountsの内容を保持する」とかいう話はしていない。
>>596のようなデータを管理するときに、BTSからユーザを削除するときの話。
0852NAME IS NULL
2015/10/06(火) 13:14:52.53ID:???> 履歴を保持する必要があるのなら、現行のマスターに依存しないモデルを作れば良いだけだぞ。
履歴を保持しなくて良いシステムと、履歴を保持するシステムにわけられるとき、
後者は同じ情報を至る所に持つテーブル設計にするのか？
0853NAME IS NULL
2015/10/06(火) 13:24:00.14ID:???Ticketを表示するとき、reporterd_by, assigned_to, verified_byしたユーザのportraitとnameが表示される。
さて、ユーザを削除できるのが前提の場合、どういう設計にするのが良いだろうか？
CREATE TABLE Accounts (
account_id SERIAL PRIMARY KEY,
account_name VARCHAR(20),
first_name VARCHAR(20),
last_name VARCHAR(20),
email VARCHAR(100),
password_hash CHAR(64),
portrait_image BLOB,
hourly_rate NUMERIC(9,2)
);
CREATE TABLE Bugs (
bug_id SERIAL PRIMARY KEY,
date_reported DATE NOT NULL,
summary VARCHAR(80),
description VARCHAR(1000),
resolution VARCHAR(1000),
reported_by BIGINT UNSIGNED NOT NULL,
assigned_to BIGINT UNSIGNED,
verified_by BIGINT UNSIGNED,
status VARCHAR(20) NOT NULL DEFAULT 'NEW' ,
priority VARCHAR(20),
hours NUMERIC(9,2),
FOREIGN KEY (reported_by) REFERENCES Accounts(account_id),
FOREIGN KEY (assigned_to) REFERENCES Accounts(account_id),
FOREIGN KEY (verified_by) REFERENCES Accounts(account_id),
FOREIGN KEY (status) REFERENCES BugStatus(status)
);
0854NAME IS NULL
2015/10/06(火) 13:29:27.95ID:???いや、反するよ。
>>851
混ぜる必要のない要件であることは確かだが、反するってちゃんと言っとかないと後々面倒なことになると思う。
0855NAME IS NULL
2015/10/06(火) 13:31:45.83ID:???俺だったら、Accounts.delete_at DATEを追加するね
0856NAME IS NULL
2015/10/06(火) 13:37:42.60ID:???横だけど、後者は同じ情報に至るテーブルを作ってるケースをよく見るな。
ほぼ同じテーブルが複数あるのに違和感を感じるが
用途が違うって事で許容してるのかもしれない。
0857NAME IS NULL
2015/10/06(火) 22:22:40.24ID:???>>596のテーブルで、account_idもaccount_nameも残す必要があるのに
Accountsのレコードを削除するという問題設定がそもそも意味不明なんだが？
何がしたいんだ？
0858NAME IS NULL
2015/10/07(水) 10:05:50.93ID:???いやだから、BTSでユーザを削除するという要件を、どう設計/実装するかという話なんですけど。
0859NAME IS NULL
2015/10/07(水) 10:37:17.60ID:???いまさら何言ってるんだか。
0860NAME IS NULL
2015/10/07(水) 12:33:50.62ID:???ユーザーデータを削除するという要件なら
文字通り削除するしかないんだが
お前何に悩んでるの？
0861NAME IS NULL
2015/10/07(水) 12:36:21.60ID:???相手の意見が間違っていると思うなら、論理的かつ冷静に諭せ
0862NAME IS NULL
2015/10/07(水) 12:39:39.29ID:???お前が落ち着けｗ
0863NAME IS NULL
2015/10/07(水) 12:50:36.73ID:???> ユーザを削除できるのが前提の場合
ユーザを削除した場合に何を残すのかという要件もセットで提示しないと。
0864NAME IS NULL
2015/10/07(水) 12:54:25.16ID:???BTSなんでTicket(Bugsレコード)は残さないといけないんですが、明示しないとわかんないですかね。
0865NAME IS NULL
2015/10/07(水) 12:57:45.29ID:???> ユーザーデータを削除するという要件なら
「ユーザーデータを削除する」じゃなくて、「ユーザーを削除する」が要件ね。
> 文字通り削除するしかないんだが
ユーザを削除するというのは要件（要求仕様）、それを設計/実装仕様ではどうするのって話。
0866NAME IS NULL
2015/10/07(水) 13:09:21.49ID:???0867NAME IS NULL
2015/10/07(水) 13:23:35.25ID:???Accountsに削除フラグを追加するのはどうかという話をして欲しかったね。
0868NAME IS NULL
2015/10/07(水) 13:57:30.69ID:???結局、要件次第といういつもの何の参考にもならない結論だな
0869NAME IS NULL
2015/10/07(水) 14:02:04.40ID:???削除フラグの件で言えば、基本的には物理削除でおｋなんだよ。
もうそれで要件の90％は満たされていると言っていい。
残りの1割ぐらいの人が「誰が削除したいか知りたい」とか”要件”を言い出すから、
そういう場合はその都度対応すればいいだけ。
0870NAME IS NULL
2015/10/07(水) 14:25:11.87ID:???復活を認めるって所があるな。
この場合は、物理削除するにしても一ヶ月間保留される。
レコードは移動してないと思う。
移動したら、復活がめんどくさいだろうね。
0871NAME IS NULL
2015/10/07(水) 14:27:29.13ID:???だから何度でも復活できる。これはこれで嫌だなぁ
0872NAME IS NULL
2015/10/07(水) 15:39:24.18ID:???0873NAME IS NULL
2015/10/07(水) 18:23:03.80ID:???> 要件次第だけど、大方決まってる道筋ってあるじゃん？
なんでそういうのがあるってことにしたいんだろう？
そうしとかないと、何か安心しないとか？
0874NAME IS NULL
2015/10/07(水) 18:50:12.87ID:???お前が言ってるのはユーザーを削除する機能の仕様な。
例えばお前に渡された「ユーザー削除画面」の仕様が
ユーザーを削除しますがユーザーデータは参照出来るようにします
という代物だったら、そもそも上流が間違ってる。
お前が考えてどうにかなる問題じゃないぞ。
0875NAME IS NULL
2015/10/07(水) 19:43:58.74ID:???そもそも削除フラグよりも履歴の方が良いだなんて何時このスレでまとまったのか？
件のスライドショーは削除フラグの話と見せかけて
「お客の話聞いてないだけでした」というオチだったと記憶しているが
0876NAME IS NULL
2015/10/07(水) 20:54:05.59ID:???その「ユーザーの削除」が発生したときに、じゃあログインはもうしないからパスワードは消す、
アカウント名は履歴の表示に必要だから残すとか、そういった落とし込みまでできてなきゃ要求分析が
終わったとは言えんだろう。
なんかそのへんすっ飛ばしたまま「ユーザーの削除」=「ユーザーテーブルのレコード削除」という
考えから抜け出せていないから悩んでいるようにしか思えんが。
0877NAME IS NULL
2015/10/07(水) 22:43:53.62ID:???ユーザーを削除するっていう言い方が良くない気がするな
実際はユーザの利用を停止させるだけだったり、ユーザの登録情報の抹消だったり
そのユーザが関わった全ての痕跡の消去だったりするわけで
0878NAME IS NULL
2015/10/08(木) 00:06:24.54ID:???チケットさえ残ればいいのか？って話なんだが。
それなら外部制約はずしてユーザ削除すればいいだけだし。
0879NAME IS NULL
2015/10/08(木) 06:49:38.95ID:???普通に BTS 使ってたら起票した人の名前がないとかは色々まずいと思うと思うが？
そう言う常識もない様な奴はレスするなよ…
0880NAME IS NULL
2015/10/08(木) 07:41:37.83ID:???BTSのチケットで個人を特定するのはIDでも本名でもなんでもいいだろ。そんな常識はない。
で、>>853のテーブルでAccountsのレコードだけ削除して問題があるのはBugsがAccountsの
account_idを外部キー参照しているから。
おそらくAccounts.account_idはAccountsレコードが存在しなければ意味を持たない人工キー
なんだと思うが、その場合はIDのマスタと個人に属する情報の管理テーブルとに分ければよい。
IDが自然キーなんであれば最初から問題はない。
0881NAME IS NULL
2015/10/08(木) 08:39:27.34ID:???なら文字通り「レコードを削除する」で良いだろ。
なんかお前らはあれこれ理由つけて煽るからややこしくなる。
まずは物理削除の事を考え、それから要件に合わせて
論理削除を考えればいいだけだろ。
「物理も論理もあるし、それは要件次第だし〜」とか言い出すから
ややこしくなっているんだといい加減気づけ
0882NAME IS NULL
2015/10/08(木) 10:29:08.14ID:???0883NAME IS NULL
2015/10/08(木) 10:30:16.84ID:???BTSのこと知らないどころか、SERIALのことも知らない奴だったか
0884NAME IS NULL
2015/10/08(木) 10:46:24.67ID:???> ログインはもうしないからパスワードは消す
これは実装仕様だな。
削除されたユーザはログインできない、が要件。
> アカウント名は履歴の表示に必要だから残す
こっちは要件。
ただし、どちらもBTSでは「常識」。
0885NAME IS NULL
2015/10/08(木) 10:59:26.86ID:???・だが、誰がいつ削除したかの情報だけは残したい（DB上に履歴が残ればいい）
と言った場合ならどうするのが常識なの？
0886NAME IS NULL
2015/10/08(木) 11:51:30.70ID:???いい加減、実装仕様と要求仕様の違いを認識してくれよ。
> ・退会したユーザーはユーザーテーブルから削除する
これは実装仕様。
> ・だが、誰がいつ削除したかの情報だけは残したい
これは要求仕様。
「誰がいつ削除したかの情報だけは残したい」という要件を満たすために、
・ユーザーテーブルから削除する
・「誰がいつ削除したかの情報」テーブルを追加する
という設計にする。
なお、ユーザーテーブルから削除しない「論理削除」という実装方法もある。
どっちかというと、前者の方法がとられることが多い（個人的観測）。
0887NAME IS NULL
2015/10/08(木) 12:37:37.91ID:???そんな隠し要件あるなら、
ユーザテーブル(ユーザ名を含み、ユーザ削除時に削除しない)
ユーザ属性テーブル(ユーザ名以外の情報。認証情報やらなにやら。ユーザ削除時に削除する)
ってしなきゃいけないな。
0888NAME IS NULL
2015/10/08(木) 12:41:24.45ID:???要件定義の時点でそこを間違うから、憐れな混乱したプログラマが後を断たないんだな。
0889NAME IS NULL
2015/10/08(木) 13:08:24.40ID:???0890NAME IS NULL
2015/10/08(木) 13:11:21.15ID:???「削除」とそのユーザが表示されたところが全部anonumousになるってのもある。
つまり、要件次第。
0891NAME IS NULL
2015/10/08(木) 13:53:12.56ID:???0892NAME IS NULL
2015/10/08(木) 14:03:13.46ID:???こう思ってるユーザは多いんだが、開発者側にもこう思ってるやつがいたとは
0893NAME IS NULL
2015/10/08(木) 14:10:13.94ID:???それこそ、(ユーザの)削除という用語の定義の問題
ちゃんと用語定義してない言葉を使うから、きちんと意思の疎通ができない
0894NAME IS NULL
2015/10/08(木) 15:32:44.00ID:???0895NAME IS NULL
2015/10/08(木) 15:43:19.54ID:???0896NAME IS NULL
2015/10/08(木) 16:42:06.07ID:???逆じゃね？ユーザ（てか依頼者）側が思ってるから、
開発者側もそれに従うしか無いんだろ。1から10まで説明求めると嫌がるんだし。
0897NAME IS NULL
2015/10/08(木) 17:11:07.38ID:???>>890が言ってるのかこれかな？
で、複数人削除すると、anonymousが氾濫してカオスになるとか。
じゃRedmineはどうしてるかというと、上で言っている「削除」は、「ユーザをロックする」という機能で実現してる。
0898NAME IS NULL
2015/10/08(木) 17:18:13.39ID:???別にカオスにはならないよ。このスレ、名前共通、ID非表示でしょ。
0899NAME IS NULL
2015/10/08(木) 17:45:02.23ID:???それは価値観が違うとしか言えない。
0900NAME IS NULL
2015/10/08(木) 19:14:57.30ID:???なんだそれ？
0901NAME IS NULL
2015/10/08(木) 23:57:27.33ID:???何を問題視してるのか明示しないあたりがもうダメダメだと思うんだけどさ、
もしも匿名ユーザの区別がつかないことが問題だと考えてるなら退会ユーザ1 2 3 って名前挿げ替えればいいじゃん。
個人情報保護の目的で削除してくれっていわれても残しちゃう系なの？
0902NAME IS NULL
2015/10/09(金) 03:31:44.52ID:???0903NAME IS NULL
2015/10/09(金) 06:45:52.32ID:???何を問題視してるのか理解してないあたりがもうダメダメだと思うんだけどさ…
業務システム知らないならいちいち絡んで来るなよ
0904NAME IS NULL
2015/10/09(金) 07:12:17.08ID:???しまいには「BTSの常識」で考えろとか言い出した。
0905NAME IS NULL
2015/10/09(金) 07:28:08.60ID:???0906NAME IS NULL
2015/10/09(金) 07:47:31.08ID:???常識（デファクトスタンダード）知らないと、個々の開発者で違ったものが出来るだろ
0907NAME IS NULL
2015/10/09(金) 08:23:50.39ID:???だからこそ要件定義や議論の前提なんかではそれに依存しないようにすることが必要なわけで。
唯一の正しい「常識」が存在して、それと異なる考えを持つ人は「常識を知らない人」と
考えちゃうのはアレだ。小児期にみられる、自己と世界の区別が確立していないやつ。
0908NAME IS NULL
2015/10/09(金) 10:07:09.06ID:???だから、一致させようって話だろうが。
お前頭固すぎだな。我も強いし、協調性0かよ
0909NAME IS NULL
2015/10/09(金) 11:10:26.74ID:???さすがに、BTSでユーザを削除したら、そのユーザが起こしたチケットも削除されてもいいとか思ってるなら
常識無しと言われてもしかたがない。
0910NAME IS NULL
2015/10/09(金) 11:50:53.16ID:???0911NAME IS NULL
2015/10/09(金) 12:09:05.93ID:???対案も出してるし、聞いてることには答えないし、むしろ業務システム知らないんじゃないの？
0912NAME IS NULL
2015/10/09(金) 13:11:35.67ID:???> 何を問題視してるのか明示しないあたりがもうダメダメだと思うんだけどさ、
なんだろう、この無力感。
「業務で管理するデータの何パーセントかがつぎつぎに匿名に置き換わってい」くって書いてるじゃん。
俺がそれを問題だと思ってると読めないのか？
0913NAME IS NULL
2015/10/09(金) 13:12:35.77ID:???>>901
> 個人情報保護の目的で削除してくれっていわれても残しちゃう系なの？
俺がBTSについて話してるのが理解できてないみたいだな。
0914NAME IS NULL
2015/10/09(金) 13:32:59.21ID:???0915NAME IS NULL
2015/10/09(金) 14:09:39.29ID:???みんなでトコトン話し合おう
0916NAME IS NULL
2015/10/09(金) 14:10:21.10ID:???匿名に変わって困るような、業務上生きてるデータって誰かに引き継がれるだろ
0917NAME IS NULL
2015/10/09(金) 14:30:06.11ID:???理由を聞かれて、常識だろって説明する奴は信用ならん
0918NAME IS NULL
2015/10/09(金) 14:53:08.87ID:???クライアントなら丁寧に説明するが、同僚なら「常識だろ」って言いたくなる。
0919NAME IS NULL
2015/10/09(金) 18:54:46.38ID:???それが削除フラグの話題とは何の関連もない件
0920NAME IS NULL
2015/10/09(金) 20:44:53.63ID:???誰が起票したとかは業務遂行上はどうでもいいことというのが、通常の開発者が持ってる常識だと思うよ。
0921NAME IS NULL
2015/10/09(金) 21:34:36.05ID:???0922NAME IS NULL
2015/10/09(金) 22:01:56.69ID:???役に立たない戯れ言を対案って言われてもね ｗ
>>920
BTSで人の情報は結構重要だよ
少し大き目のプロジェクトで開発管理したことないだろ
0923NAME IS NULL
2015/10/09(金) 23:03:20.50ID:???いやお前は開発した事ないだろｗ
0924NAME IS NULL
2015/10/09(金) 23:28:16.30ID:???それを「常識だろ」で片付けていたらいつまでも一致するわけがないわな。
0925NAME IS NULL
2015/10/10(土) 00:42:49.47ID:???少し大き目ってどの程度を指してんのか知らんが、
誰がっていうのを意識できる程度の規模に収まってる現場かなって思えてしまうよ。
人の情報、どう使ってんの？話の流れに沿わせるとすでに現場にはいない人の情報。
0926NAME IS NULL
2015/10/10(土) 00:47:44.65ID:???・常識だろ
・そんなの話にならない
・価値観が違う
・BTS知らないんじゃないの？
・いろいろまずいだろ
0927NAME IS NULL
2015/10/10(土) 06:16:42.38ID:???つまりお前は狭量ってことだ。
他の奴は他人の意見を踏まえた上でレスしてる
0928NAME IS NULL
2015/10/10(土) 09:56:40.70ID:???相手を分かろうとしない、自分が絶対なレスばっかりだな
0929NAME IS NULL
2015/10/10(土) 11:31:08.78ID:???そう言う悔し紛れのレスしかできないならおとなしくＲＯＭっとけよ…
>>925
そいつが書いた設計資料を見たいとかないのか？
構成管理が完璧で資料も完全に紐付けられてるなら良いのかもしれないけど
0930NAME IS NULL
2015/10/10(土) 13:19:28.89ID:CZUC3EIRhttps://youtu.be/yZG2-L5H-Yk
https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E3%83%94%E3%83%AD%E3%83%BC%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF
堺市の小林由佳って、上西以上の感じ悪さだな。
こういうのどんどん放映して、維新の悪を暴いてほしい
0931NAME IS NULL
2015/10/10(土) 13:23:53.94ID:???もともとユーザーを削除する話だし、チケットを削除するなんて誰も言ってないと思うが。
もしかして、「ユーザーテーブルのレコードを削除する」→「それを外部キー参照する
レコードは存在し得ない」ってところで思考停止してんのかね？
0932NAME IS NULL
2015/10/10(土) 13:48:46.64ID:???いやだからｗ悔しくて仕方がないのはお前だろｗ
0933NAME IS NULL
2015/10/10(土) 19:52:53.87ID:???設計資料？BTSの話だよね？
0934NAME IS NULL
2015/10/10(土) 20:09:55.86ID:???そうだよ
設計書の修正管理を BTS でやるのは珍しくないし、ある不具合を作り込んだ奴が他に変な設計してないか確認したいこともあるだろ
>>932 みたいに設計が何をするのか理解してないアホじゃないならわかると思うけど ｗ
0935NAME IS NULL
2015/10/10(土) 20:39:45.45ID:???>>934
> ある不具合を作り込んだ奴が他に変な設計してないか確認したいこともあるだろ
そういうのはレビューでやるもんだ。
お前本当に開発した事ないだろ。
0936NAME IS NULL
2015/10/10(土) 20:43:48.38ID:???0937NAME IS NULL
2015/10/10(土) 20:46:13.41ID:???まぁ、無いとは言えんがそんなのが頻発するようなら管理方法見直せ。なんのためにBTS使ってんだか。
0938NAME IS NULL
2015/10/10(土) 20:47:32.26ID:???言いたいことは分かるが、そこまで人依存しちゃってる現場って長らく経験してないな。
でもまぁ、そうやって人名に依存したい(そしてそれが価値のある体制)のなら
ユーザ削除時にも名前は残すようなDB設計にしないといけないだろうなと思うよ。
どの人がどの設計書を書いたのかってのがとても重要そう。
0939938
2015/10/10(土) 20:49:14.06ID:???0940NAME IS NULL
2015/10/10(土) 20:51:09.93ID:???> そういうのはレビューでやるもんだ。
どこまでアホなんだよ…
レビューするための設計書をどうやって見つけるかって話で、確認の方法なんて言ってないぞ
> お前本当に開発した事ないだろ。
開発云々以前に頭が設計に向いてないんだろうな w
0941NAME IS NULL
2015/10/10(土) 20:58:09.28ID:???まあ業種にも依るだろうけどうちだと保守とかで15年以上前のコードがあったりするし
0942NAME IS NULL
2015/10/10(土) 20:59:16.52ID:???あなたのいうレビューと>>935のいうレビューは違うものだと思う。
そして>>935の方が一般的な開発現場で使われているものだ。
0943NAME IS NULL
2015/10/10(土) 21:00:29.66ID:???別に15年だろうが20年前だろうがあっても問題ないでしょ。
15年前に起票されたチケットがクローズされずに残ってるわけじゃないんでしょ？
0944NAME IS NULL
2015/10/10(土) 21:10:53.14ID:???元の担当者がいなくなった古いコードなんてのはどこにでもあるだろうけど、>>934みたいな
属人的な確認を後からやるなんてのはめったにあるもんじゃないな。
0945NAME IS NULL
2015/10/10(土) 21:24:43.69ID:???同一人物とも限らんよな。
0946NAME IS NULL
2015/10/10(土) 21:35:01.59ID:???だからレビューの話なんてしてない
指摘されてもわからんとか終わってるな
0947NAME IS NULL
2015/10/10(土) 21:42:58.51ID:???まあ毎日あるとは言わない
滅多にないと言う方が正しいけど何回かあったのも事実
あと外注さんが設計してシステムテストの前にいなくなると言うのもあったりするし
>>945
うちは原因を作り込んだ人の名前も入れてる
0948NAME IS NULL
2015/10/10(土) 21:45:04.90ID:???あなたの現場では違うんだろうけど、規模が大きければ大きいほど、レビューでやるもんだよ。
0949NAME IS NULL
2015/10/10(土) 21:46:11.76ID:???原因を作りこんだ人の名前を入れてるならユーザ削除されても問題ないんじゃないの。
0950NAME IS NULL
2015/10/10(土) 22:05:26.85ID:???バカの上に粘着かよ…
0951NAME IS NULL
2015/10/10(土) 22:07:56.06ID:???作り込んだ人の名前もユーザーテーブルから引いてる場合の話だろ
見たら「匿名123」とか表示されてても困るとは思う
0952NAME IS NULL
2015/10/10(土) 22:10:14.70ID:???おい>>948は俺じゃないぞｗ
もう諦めろｗ
0953NAME IS NULL
2015/10/10(土) 22:16:52.40ID:???上で何度も言われている通り、それが要件ならユーザー削除でレコードが削除される
テーブルに入れなきゃいいだけ。
0954NAME IS NULL
2015/10/10(土) 22:32:58.38ID:???お前が誰かは知らんけどいつまでもレビューって言い続けてる奴は粘着質だろ
0955NAME IS NULL
2015/10/10(土) 22:35:09.61ID:???そう言うのは >>901 辺りに言ってくれ
0956NAME IS NULL
2015/10/10(土) 22:44:46.95ID:???0957NAME IS NULL
2015/10/10(土) 22:49:51.24ID:???客「は？」
0958NAME IS NULL
2015/10/10(土) 22:51:43.79ID:???外注のAさんが原因を作りこみました。
外注のAさんが設計したのはこれらです。
で、Aさんが匿名1に変わって何が問題なの？
0959NAME IS NULL
2015/10/10(土) 22:58:23.22ID:???客「それが要件なら」
開発者「は？」
0960NAME IS NULL
2015/10/10(土) 23:07:19.40ID:???> で、Aさんが匿名1に変わって
の状態でどうやって
> 外注のAさんが設計したのはこれらです。
って言うのさ
Ａさんがいなくなる時にＡさんが作成した全てのドキュメントの作成者を匿名1に書き換えるのか？
0961NAME IS NULL
2015/10/10(土) 23:14:10.57ID:???だからそんな「BTSの常識」から外れた運用するんでなけりゃ問題ない。
0962NAME IS NULL
2015/10/10(土) 23:33:56.66ID:???設計書もBTSのユーザに紐付けた形で管理してるって話だったんじゃ？
修正者は残すが作者は残ってないっていう状態なのかな。
0963NAME IS NULL
2015/10/10(土) 23:35:02.20ID:???外れてることにしないと自我が保てないの？
0964NAME IS NULL
2015/10/10(土) 23:39:04.95ID:???0965NAME IS NULL
2015/10/10(土) 23:39:24.15ID:???メジャーなBTSでチケットにバグの原因者を入力させるようなのがどれだけ存在する？
0966NAME IS NULL
2015/10/10(土) 23:39:35.76ID:???だから >>929 にも書いたけど現状では完全には紐づけできてないってこと
できてりゃいいのかも知れない
0967NAME IS NULL
2015/10/10(土) 23:39:50.57ID:???チケットに不具合を埋め込んだユーザも持たせる運用にする。
だが、設計書の作者とBTSのユーザマスタとは連携していない。
ということ？
0968NAME IS NULL
2015/10/10(土) 23:45:29.29ID:???じゃあ、設計書はBTSで管理できてないっていうのと同じだ。
BTSで管理するならVCSとも連携してるだろうし、そっちのリビジョン番号書いとくほうが便利そうな気がしない？
0969NAME IS NULL
2015/10/10(土) 23:50:00.55ID:???0970NAME IS NULL
2015/10/10(土) 23:58:42.37ID:???この場合、むしろBTS名聞いたほうがはやい。
一般的なBTSの常識だろっていわれたらひっくり返るしかない。
0971NAME IS NULL
2015/10/11(日) 00:13:14.25ID:???そう、残念ながらできてない
少しずつはやってるけど、設計書とかはワード・エクセルで作成されることが多いのでマージできないのが辛い
>>970
Redmine の項目に作り込んだ人の名前を追加してるだけだが珍しいのか？
0972NAME IS NULL
2015/10/11(日) 00:18:21.83ID:???設計書が生まれた時点で、適当なチケット起こして名前入れてクローズしとけば？
0973NAME IS NULL
2015/10/11(日) 00:32:01.72ID:???ユーザマスタからはユーザを削除しても問題ないってことにはならないのだろうか。
なんでDB設計スレで運用レイヤ視点で話さないといけないのかモヤモヤするけど、
そうしないと伝わらない感が強い。
0974NAME IS NULL
2015/10/11(日) 00:33:31.47ID:???VCS との連動まではできてるからコードはそうやってる
ドキュメントも同じようにすればいいんだけど、なかなか運用に載せられない
0975NAME IS NULL
2015/10/11(日) 00:38:04.25ID:???俺はそれでいいと思うけど、納得しない人がいるってだけでしょ
0976NAME IS NULL
2015/10/11(日) 00:47:47.97ID:???設計スレなんだから、「そうしたければそう設計する」でいいと思う。
0977NAME IS NULL
2015/10/11(日) 00:52:54.30ID:???0978NAME IS NULL
2015/10/11(日) 01:04:27.65ID:???0979NAME IS NULL
2015/10/11(日) 01:32:58.02ID:???0980NAME IS NULL
2015/10/11(日) 01:48:07.95ID:???0981NAME IS NULL
2015/10/12(月) 15:22:21.22ID:???0982NAME IS NULL
2015/10/13(火) 10:21:40.93ID:???> 言いたいことは分かるが、そこまで人依存しちゃってる現場って長らく経験してないな。
普通に考えて、俺が登録したなにがしかの情報を、誰だかわかんない奴に修正されても困る。
0983NAME IS NULL
2015/10/13(火) 10:26:06.78ID:???個人営業の企業くらいだろ、そんなこと平気でするのは
0984NAME IS NULL
2015/10/13(火) 10:34:45.77ID:???0985NAME IS NULL
2015/10/13(火) 14:26:58.48ID:???履歴テーブル使うのでFAか？
0986NAME IS NULL
2015/10/13(火) 14:34:08.32ID:???つまり、要件次第
0987NAME IS NULL
2015/10/13(火) 14:37:25.25ID:???0988NAME IS NULL
2015/10/13(火) 14:40:52.88ID:???無効になるかもしれない何らかの情報があるときどう設計すべきか、って話
・無効になるとはどういう事か
・無効になった情報と、その関連情報はどうするべきか
最低この２点は決定しないと話にならん
0989NAME IS NULL
2015/10/13(火) 14:46:02.54ID:???アカウント停止措置なんかで
0990NAME IS NULL
2015/10/13(火) 16:41:38.79ID:???バカすぎ、考えるのやめちゃう奴の方がマシ
0991NAME IS NULL
2015/10/13(火) 16:49:53.97ID:???どうすべきかを判断できるだけの要件を考えることをやめる奴よりはまし
0992NAME IS NULL
2015/10/13(火) 17:09:57.44ID:???俺が思う要件は常識だろって奴もいるぞ
0993NAME IS NULL
2015/10/13(火) 17:20:50.28ID:???http://qiita.com/Jxck_/items/156d0a231c6968f2a474
http://fujiiyuuki.blogspot.jp/2010/05/blog-post.html
http://ledsun.hatenablog.com/entry/2015/03/27/015203
http://mike-neck.hatenadiary.com/entry/2015/03/24/231422
0994NAME IS NULL
2015/10/13(火) 17:38:12.72ID:???0995NAME IS NULL
2015/10/13(火) 17:43:13.27ID:???いつも思うが、他人をアホだと思うなら、何ならアホと思わないのか代替案を言えよ。
批判するだけなら誰でも出来る
0996NAME IS NULL
2015/10/13(火) 17:50:34.57ID:???だーかーらー
よーうーけーんーしーだーいー
0997NAME IS NULL
2015/10/13(火) 17:58:33.91ID:???0998NAME IS NULL
2015/10/13(火) 18:04:14.48ID:???BTS とかに限定すりゃそれなりに常識ってものがあると思うが、社内システムとかだと色々ありすぎ
0999NAME IS NULL
2015/10/13(火) 18:04:15.76ID:???1000NAME IS NULL
2015/10/13(火) 18:23:45.54ID:???要件次第なのに、一般論で削除フラグは悪というのがアホ
1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
1002１００２
Over 1000Thread運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
http://premium.2ch.net/
レス数が1000を超えています。これ以上書き込みはできません。