DB設計を語るスレ 6

1 ：2012/06/30 〜 最終レス ：2013/09/09

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

2 ：

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

3 ：

TMのリンク入ってて嬉しい。
ERなんてTMの補強理論でしかないのに、本屋行くとこればっかだな。

4 ：

最近DB始めてブログとかニコ動とかでよくあるタグ機能を作ろうとしてるんだけど一般的にはどう作るんだろう。
今考えてるのは
・タグ用のカラムをひとつ用意して、全部のタグをタブ（など）で連結してひとつのセルに入れる
・カラムを10個用意して1カラムごとに1タグずつ入れる
検索とかで効率良さそうなのは前者に思えるけど、もっと頭良い方法があったら意見を聞きたいです。

5 ：

>>4
> もっと頭良い方法があったら意見を聞きたいです。
まず、DB設計のスレで「セル」とか言うのを止める。

6 ：

正規化、非正規化でぐぐれ

7 ：

RDBに限定することもないだろ。

8 ：

レストンです。正規化とか一応概念だけは頭に入ってる感じですがなにせ経験が伴ってないんでよくわかってないのが正直なとこです。
できたら「俺ならこういう設計にするぜ」みたいな先人の方法論を聞いてみたいな、と。
ちなみにPerl+SQLite3で作ってます。いつかはログインが必要なDBも使ってみたいね…
>>5
どう呼ぶか知らないのでセルって言ってるんだけど普通はどう呼ぶのでしょう？ マス目？ｗ

9 ：

>>8
正規化の概念があるなら
>全部のタグをタブ（など）で連結してひとつのセルに入れる
がありえん事ぐらい解るだろうに
>どう呼ぶか知らないのでセルって言ってるんだけど
>カラムをひとつ用意して(中略)セルに入れる
用意したんならせめてそれに入れようぜ
先人の方法論は、本屋いけばいっぱいあるから
DB設計の初心者向けの本買って読め

10 ：

>>8
参照だけじゃなく更新や検索、集計したいときに
どんなクエリを書かなくてはならないのか想像するといいよ
正規化の必要性が理解できるようになるから

11 ：

>>9
ありえんこともわからんから素人なんだなｗ
ということはタグ検索をしたい時は WHERE col1='タグ' OR col2='タグ' ... ってカラムの数だけ並べないといけないのか…な
DBの本は一応持ってるけど説明がまわりくどくてわかりにくいんで明日にでももっと易しいのないか探しに行ってきます。
>>10
正規化のことはまだ理解できてないけどDB使う上では避けて通れない道って程度にはわかってるんで色々作って数こなしながら身体で憶えていこうと思います。
実際に作って実際に使って、このやり方だとどういう時にまずいことになるのかってのは時間かけて自分で経験しないとなかなか憶えられないしね…
場違いな素人の相手してくれて�dです。

12 ：

>>11
つまり正規化の概念も頭に入ってないんだな
お前の提示した方法はどっちも(RDBでは)普通はやらない
普通は１レコードでタグ一つで、そのタグと親を紐つけるんだ

13 ：

>>12
その普通が理解できてないから素人なのでございます。というかズブすぎる…
なるほど、普通はそんな感じにするんですね。参考になります。
とりあえず具体的にどういうテーブル構成にしたらいいのか自分で考えてみます。
その後で本屋行こう。

14 ：

本屋行って勉強してそれから考えたほうが良いと思うんだが

15 ：

>>14
ごもっともですｗ
でもせっかくヒントもらったことだし、ロジック？を考えるのも楽しいし、
回答を見る前に少し余分に回り道してみようかな、なんて…

16 ：

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

17 ：

↑のキモい文章はなんなんさ

18 ：

DBの設計で質問があります。
クラスの時間割(6時間)を5日分DBに登録するとします。
これを一つのテーブルに登録すると30行になると思います。
後で水曜日の時間割が一時間増えたってなったとき、
挿入しようとしてもDBって末尾にしか追加できないから、
その追加した水曜日の1時間だけ31行目に追加されてしまい、
GUIベースで表示しくてれるツールでDBを見たときに汚くなってしまいます。
なので月〜金までのテーブルを５つ作ったほうが、
後から追加しやすくなるかなと思ったのですが、どっちがいいでしょうか？
最初の方法でもどうせ曜日で検索かければデータとしては取得できるのでいいかなと思ったのですが、
実際は皆どうやってるのかなーと思いまして。
基本的にDBって書き込まれてる場所はどこでもよくて、
表示するときにちゃんと表示できれば問題ないって感じですか？
実際の現場でも？
アドバイスください

19 ：

＞基本的にDBって書き込まれてる場所はどこでもよくて、
＞表示するときにちゃんと表示できれば問題ないって感じですか？
パフォーマンスに問題ない限りこれでいい

20 ：

>>19
あざっす！
気が楽になりました！！！

21 ：

ID　数値
曜日　文字列　--月曜日
時限　数値　--1
教科　文字列　--数学
クラス　文字列　--1-A
曜日を文字列にしたが1を月曜7を日曜とかに見立てた数値でもよろしい
select 時限, 教科 from t where クラス='1-A' and 曜日='月曜日' order by 時限
1-Aの月曜日の時間割
どういうデータが欲しいかとか
登録数の規模によって後は適当に正規化すればよろしい

22 ：

>>21
おお〜！すげえ！
ありがとうございました！

23 ：

>>挿入しようとしてもDBって末尾にしか追加できないから
まずこれに突っ込んでやれよお前ら
基本として行の格納順序には意味がないってのが原則だぞ
行の格納順序は追加した順とはかぎらないし、出力される順序も指定しなければ不定
数十行程度のテーブルなら、実際の格納順序まで考慮する必要性は少ないと思うけど
そのへんはDBMSの実装に大きく依存する

24 ：

CHECK制約をDB側に書きまくるか
プログラム側でチェックしてDBにはプログラムからそのまま値を通すかで悩んでますが
どちらが一般的でしょう？

25 ：

制約は無しの方向で

26 ：

ありがとうございます
なしの方向でいきます

27 ：

性能に問題ないなら、両方やればいいと思うが…
まあ、CHECK 制約書きまくるとインポートの時に苦労したりするけど。

28 ：

性能うんぬんより、DBの保全のために制約が必要なわけで
そのプログラムがバグったときに、DBに不正なデータが格納されて良いなら
制約つけなくてもいいよとしか
単一のプログラムからしか使わんDBなら、制約なしでもいいけど
複数システムから使うようなDBなら、単一システムのバグで全システムがバグるぞ

29 ：

>>28
> DBの保全のために制約が必要なわけで
そんなことはわかってて、それでも性能足りないとどうしようもないことがありえるから
アホな突っ込み防止のために念のために「性能に問題ないなら」って書いてあるんだが、
それでもアホな突っ込みする奴はいるんだな…
> 単一のプログラムからしか使わんDBなら、制約なしでもいいけど
意味わからん。
単一のプログラムからしか使わないなら不正なデータ格納されていいのか？
データベース覚えたて厨房のアホレスにしか見えないぞ。(w

30 ：

イライラし過ぎｗ
暑いならエアコン使え

31 ：

８時頃はエアコンなしでもそんなに暑くなかったけど？
というか、>>29 がいらいらした文章に見えるなら、
君こそエアコンの冷風頭にあててた方がいいと思うぞ。(w

32 ：

>>29は夏休み仕様だろｗ

33 ：

悔しいねぇ。(w

34 ：

プログラマは他のプログラマを信用せず、
DBAはプログラマを全員信用しない。

35 ：

>>29
お前が制約の意味を理解してるとして、それが>>24に伝わってると思うか？
つか、お前の所は性能＞保全性なのな

36 ：

>>35
どうみても >>24 は、制約の意味を理解していると思うが。
伝わっていないと言う理由でもあるのか？
> 性能＞保全性なのな
別に DB でしか保全性が保てないわけじゃないだろ、馬鹿じゃねーの？

37 ：

>>36
すくなくとも>>24が、制約の意味がDBの保全にあると思ってるようには見えん
それが解ってるなら、アプリでのチェックで代替出来るようなもんじゃないと解るからな
>DB でしか保全性が保てないわけじゃないだろ
おまえ、DBの保全って意味理解してるか？
たとえばDBからみた不正な操作に対してDB側でどう防御できるかって話だぞ

38 ：

>>37
>たとえばDBからみた不正な操作に対してDB側でどう防御できるかって話だぞ
誰もそんな話してないし。
今回の件は、DBに入れるデータのチェックをアプリでやるかDBMSでやるか、は
たまたその両方でやるかと言う単純な話。
勝手に違う言葉出してきて、自滅してるアホがいるみたいだが。(w

39 ：

例えばJavaScript→Perl→DBを例にあげると
最初のJavaScriptからPerlはクライアントサイド→サーバサイドだから
JavaScriptでチェックをしていてもすり抜けてくる可能性があるので
Perlでもチェックしないといけない
次のPerlからDBはサーバサイド→サーバサイドであって
Perlでチェックしたものは十分信頼にあたるはずなのでそのまま突っ込んでも問題ない
ただlocalhostじゃなくサーバをまたぐ場合は途中で改変される可能性はなきにしもあらず

40 ：

>>39
>Perlでチェックしたものは十分信頼にあたるはずなのでそのまま突っ込んでも問題ない
いや、DBを複数かつ異種のAPがアクセスするシステムであれば必要だ
　JavaScript→Perl→DB←Java
この場合、片方の更新処理にバグがあった場合、他方へ予期できない障害が発生する可能性がある
だからDB側でもチェックは必要（これが誰かが言ってる「保全性」の意味だと思う）
まあDB設計の時点で単一APであることが「将来に渡って保証」できるのなら、
あるいは新規開発だけ請け負って保守せず逃げ出せる立場ならかまわんのだろうけどね

41 ：

普通は単一なのでは

42 ：

将来の話まで保証できるシステムなんて一つもない
現状の可能性で判断すべき

43 ：

何で複数にこだわるんだろう…
単一の AP でも、バグって DB 壊すこともあるし、
複数でもきちんとテストされててうまく動いているシステムももちろんある。
そもそも単一のAPでも、複数のモジュールで構成されてて、複数人で開発していることもあるんだし。

44 ：

JavaScript→Perl→DB←Perl←Java
普通こういうふうにするのでは？
Perl以外からは直接DBを操作させないで
Perlで用意したAPIを他のアプリケーションで叩くみたいな使い方で

45 ：

>>43
可能性の問題だな
単一システム前提なら、DB設計者とアプリ開発者の意思疎通がやりやすい
新規開発なら、DB設計もそのシステムに合わせて設計できるから問題が起きにくい
怖いのはプログラムのバグじゃなくて、設計段階での食い違い

46 ：

他社が作ったすでに動いてるシステムのテーブルを
更新する別のシステムを新規でつくった。
しかもその他社システムはテスト環境が無い。オワタ。

47 ：

>>45
>可能性の問題だな
まあ、そういうこと。
単一かどうかの問題じゃない。
プログラムのバグも怖いよ…

48 ：

アプリでやるのは当然として、
複数のプログラムから参照•更新するテーブルは、極力DB側の制約も入れとくのが吉。
ナチュラルキーの一意制約、日付型以外のNull禁止、フラグや区分も取りうる値のみ許可、項目間の整合性ルールなど。

49 ：

まだ複数とか言ってるのか…
単一でも極力やるべきだと思うが。

50 ：

フラグや区分は微妙だな。

51 ：

DQ10のバザーってSQLでも実装可能だろうか
どれくらいのテーブルが必要なのだろう

52 ：

ネットショップでの注文に対し、
○○をした日時、××をした日時など操作した日時を記録したいのですが、
どの方法がいいでしょうか？
１．注文テーブルに操作の数だけカラムを追加する
２．別テーブルを作り、操作の数だけカラムを作る（注文テーブルと１対１）
３．注文番号、日時、操作内容のカラムを持つテーブルを作る（注文テーブルと1対多）
１のメリット・デメリット
○構造がシンプル
×カラムが非常に多くなる
２のメリット・デメリット
○注文テーブルのカラムは増えない
×構造とSQLがわずかに複雑になる
３のメリット・デメリット
○操作を複数回行った場合も各回の日時を記録しておける
○操作の数が増えた場合もカラムを増やさなくてすむ
○注文テーブルのカラムは増えない
×構造が複雑
×SQLが複雑、遅くなる
あと、２を採用する場合、注文テーブルにインサートするとトリガーで時刻テーブルにも
インサートし、デリートも制約で行うというのはどうでしょうか？

53 ：

一つの注文に対する操作が、事前に完全に限定できるのでなければ１も２もあり得ん
この程度で構造が複雑とか言ってるレベルでネットショップとか話にならんぞ

54 ：

３の場合、最終○○時刻を出すには
SELECT order_no, (SELECT MAX(time) FROM logs WHERE logs.order_no = orders.order_no AND operation='XXX') AS last_XXX_time, ...
のようになりますよね？
operationの種類が30個あって、ordersが10万行くらいあってもパフォーマンスは大丈夫ですかね？

55 ：

それ、逆に1/2でやったら相当複雑なクエリになるしスピードも出ないだろ。
ほとんどfull-scanになるし。
もしそのクエリの速度が本当に問題になるんなら、最終操作時刻のみを
別テーブルで管理するんだな。

56 ：

今時のサーバスペックで考えたら
種別、日付、数値ぐらいしかないレコードサイズなら１０万行とか余裕
フルスキャンしても待てるぐらい
数千万行オーダーになってから心配しろ。それでも適切にインデックス効けば余裕だが

57 ：

MySQL InnoDBで実験してみたところ、orders30万行、logs150万行、サブクエリ30個でも
ちゃんとパフォーマンスが出たので、大丈夫そうでした。
説明不足だったかもしれませんが、
>最終操作時刻のみを別テーブルで管理
これが２ですね。
>種別、日付、数値ぐらいしかないレコードサイズ
これはlogsのことですね。ordersが10万行の場合、logsはその数倍になる見込みです。

58 ：

>>48
こんなDB使えない。
ビジネスロジックをDBの制約で実装するなんて論外。
アプリの不具合をDBでフォローしないといけないなんて運用に問題あるでしょ。

59 ：

ビジネスロジック？
※ こういう人は、アプリの不具合で OS API からエラー返されても文句言うんだろうか…

60 ：

そもそもビジネスロジックをDBの制約で実装しろなんて誰か言ってるか？

61 ：

>>60
>そもそもビジネスロジックをDBの制約で実装しろなんて誰か言ってるか？
>> ビジネスロジックをDBの制約で実装するなんて論外。
バカの上塗り。(w

62 ：

日本語読めない奴がいるな。
誰もそんな実装しろとも言ってないのに、そんなの論外と言う>>58がアホだという意味だろ。

63 ：

一つのテーブルに履歴番号を持たせて、最新のデータと履歴を同一テーブルに保持するやり方って古いように思うのですがどうでしょうか？
顧客テーブルに、
顧客番号　履歴番号　名前
0000001　　01　　　山田太郎
0000001　　02　　　山田太郎
…
みたいな持ち方をして、履歴番号が一番大きいレコードが最新のデータとなります。

64 ：

履歴番号じゃなくて日付（変更日）を持たなくて良いのか？

65 ：

63ですが、変更日付、変更ユーザIDなんかは全てのテーブルに持っています。
上の例で言えば、顧客番号と履歴番号でプライマリキーになるので、
外部キーが非常に張りにくい(と言うか事実上不可能)構造になっちゃってるのが、
少しアレかなー？と思っています。
しかもレコードを検索する際に副問い合わせ必須ですし…。

66 ：

じゃあどういうのが新しいんだ？
つか最新状態と履歴と別テーブルに持つ設計だって昔からあるけど

67 ：

どこまで正規化するかっちゅう話し
そんなのプロジェクト毎に違うっちゅう話し
でも履歴くらいは分けろっちゅう話し

68 ：

履歴を１テーブルに持つか別テーブルに持つかは、正規化の話じゃないし

69 ：

いや正規化だろ

70 ：

>>68
正規化を考えて普通にDB設計すれば、顧客(そのもの)と顧客履歴は別々のエンティティになるよね
・顧客(顧客ID, 取引開始日時)
　　　-- 顧客IDがプライマリキー
・顧客履歴(顧客ID, 履歴番号, 履歴変更日時, 名前, 住所, メールアドレス, ...etc)
　　　-- 顧客IDと履歴番号との対(つい)でプライマリキー
　　　-- 顧客IDは顧客テーブルへの参照キー
人は引っ越しがあれば住所や電話番号は変わるし、氏名も結婚で変わることがある
でも、もしも顧客そのものに一意性(identity)が無ければ(無くしたDB設計にしてしまえば)、
後々の監査の時に、ある対象顧客の取引記録を追跡できなくなる
(あるいは社会保険庁での事例の様に、血税を使って人海戦術で追跡することになる)
ここで、もし「正規化」を崩すのであれば以下のようになるけど、これをOKとするのかな？って話だ
・顧客(顧客ID, 取引開始日時, 履歴番号, 更新日時, 名前, 住所, メールアドレス, ...etc)

71 ：

>>70
リレーションの正規化は本来、値とその関係に基づいて行うものであって、
エンティティという考え方はないよ。

72 ：

開始日があれば履歴番号は要らないだろ。

73 ：

開始日じゃなくて変更日だった。

74 ：

1日に1回しか変更できない仕様ならね

75 ：

顧客情報が一日に2度以上変更されたら上書きするだろう。

76 ：

つかお前ら前提となる要件も確認せずに好き勝手言いたい放題だな

77 ：

まぁ大体言いたいことは上で言いたい放題言われてるわけですが、
顧客マスタとか受注トランザクションとかの件数が多く、
将来的にも増える可能性が高く、且つ更新頻度が高いテーブルで、
この手の設計すると、レコード数が実データに比べても数倍に膨れ上がるため、
パフォーマンス面でも良くないと思う次第です。

78 ：

>>77
これにて一件落着なのか？

79 ：

まったく解決してないとも言えるが、そもそも別に何も問題などないからな
単にとある設計をみて古いとか言い出した奴がいるだけで

80 ：

まぁ単なる相談なんで、こう言う設計も普通にあるんですね、と言うことで。

81 ：

>>74
>1日に1回しか変更できない仕様ならね
「履歴変更日時」にするだけじゃん、バカなの？

82 ：

>>81
顧客情報を時間単位で変更する馬鹿が居るのか？

83 ：

それは仕様を決める奴に言ってくれ。
そんなバカな仕様でも対応は簡単だと言ってるだけなんだから。

84 ：

>>81
> 「履歴変更日時」にするだけじゃん、バカなの？
お前のほうが馬鹿だったわけだがｗ

85 ：

意味わからん、どこがバカなのか説明してみな。

86 ：

完全な履歴をとれって要件で、日時の分解能以上の頻度で更新された場合を考えると
日時じゃ無理だわな
それ以上の話はDB設計の話じゃなくて要件と仕様の話だから他所でやってくれ

87 ：

顧客情報がミリ秒以下で更新とか？(w
もやは反論したいだけの詭弁だな。

88 ：

要件の話は他所でやってくれるかな

89 ：

要件じゃなくて常識の話しだな。

90 ：

でも履歴と現在のデータを同一テーブルに持たせると、
データ件数が本来の件数の数倍になっちゃうし、
検索時も履歴番号なり履歴更新日時なりの指定が必須になるから、
プログラムミスとかにもつながるし、
設計としてはまずい気がするけどな。

91 ：

>>90
良く読めば顧客マスタと顧客履歴のことを話題にしているのは分かると思うよ。
日付（日時）は当然履歴のこと・・・

92 ：

>>90
データ量の件は場合によるけど、最近の環境だとよほどでない限り問題になることは
少ないと思う。
検索時の指摘はそうだけど、ビュー作っとくとかでなんとでもなるでしょ。

93 ：

カテゴリ登録みたいに、1つのカラムに複数登録するとき、
たとえば1の記事は
1,2
1,3
1,5
みたいに２，３，５のカテゴリIDを登録するためにレコードを三つ追加してるんですが、
あとからこれを修正するときは、一度deleteで1の記事のレコードを全部消して、
全部再登録した方が早い気がします
それともそれぞれの組み合わせが存在すれば更新 or 削除って形にしたほうがいいでしょうか？
後者の方がsql文を実行する回数が増える気がするのですが。。

94 ：

適切なインデックスがあればどっちでも大差ないだろう
まあDELETEする行が大量になるようならUPDATEのほうがいいだろうけど
あと最近のSQL標準ではMERGE文（いわゆるUPSERT操作を行う文）
なんてものもある

95 ：

>>94
ありがとうございます。
でもupdateする場合だと、事前にselectでその組み合わせが存在するか調べて、
あればupdate、なければinsertって複雑になるしselectの処理が一回増えるので無駄かと思いました。
大量って言ってもせいぜい10個ぐらいですので、一旦消してからinsertするようにします
ありがとうございました

96 ：

入力画面にて、
選択項目により次の入力項目が枝分かれしていくような場合、
どのようなDB設計にするのでしょうか。

97 ：

馬鹿には無理なので誰かに頼みなさい。

98 ：

それだけ聞かれてどう設計すれば良いかなんて答えられる人間がいたらすごいと思います

99 ：

まあ、階層的な選択項目を管理したいんだろうなとエスパーしてみる。
一例はこんな感じ…
create table menu (Id int primary key, Parent int not null,Item text);
insert into menu values(1, 0, 'Man');
insert into menu values(2, 0, 'Woman');
insert into menu values(3, 1, 'Dotei');
insert into menu values(4, 1, 'kimoota');
insert into menu values(5, 2, 'bishoujyo');
insert into menu values(6, 2, 'busu');
insert into menu values(7, 2, 'BBA');
トップレベルのメニューは Parent = 0 で検索
select Id, Item from Menu where Parent = 0;
1|Man
2|Woman
で、例えば 'Women' が選択されたら Id = 2 とわかるから、Parent = 2 で検索
select Id, Item from Menu where Parent = 2;
5|bishoujyo
6|busu
7|BBA
以下同文…

100 ：

すげー w

101 ：

ひどい自演を見た

102 ：

>>99
やった　ありがとう　ｿﾚｿﾚーそんな感じ　さすが
なんか選択項目ごとにテーブルを作っていくと数が多くなってしまって
普通どうやってるんだろと思ってたんだよ
でも一例ってことはいろいろやり方あるんだよね
で、その続きでもっと聞きたいことあるんだけどあとでかく

103 ：

KVSですねわかります

104 ：

最上位のParentはNULLがいいな

105 ：

続き
ユーザーに入力してもらう項目は、
１…性別の選択
２…kimootaなどの種類
３…好きな色（０〜複数選択、性別が男女どちらでも表示して入力もらう）
４…趣味（０〜複数選択、性別が男のときだけ表示して入力してもらう）
５…好きな有名人（０〜複数選択、kimootaなどの種類がbisyoujyoのときだけ表示して入力してもらう）
６…収入（数値を入力してもらう、性別が男のときだけ表示して入力してもらう）
として、
最終的には、ユーザーに入力してもらったものは保存し、
過去の入力したものを検索したりとか編集したりとかしたい。
のだけど、
その入力画面の項目用のテーブルと、
ユーザーに入力してもらった内容を保存するテーブルと、
どんな設計にすればいいのでしょう。
あと、将来、好きな色を追加したりとかできるようにしておきたい。
お願いします

106 ：

>>103
KVS検索しました　勉強します
>>104
性別のところのParentが0ではなくNULLにしたほうがいいってこと？なぜですか？

107 ：

NULLの意味が分からないなら0でも良いよ。

108 ：

まぁこの場合、parentをNULLにするよりid=0の root node を追加する方がマシだろうな。

109 ：

おまいあたまいいな

110 ：

たぶん質問者が学ぶべきは第二正規化とかそういう次元だと思う

111 ：

>>99のように具体例が知りたいです

112 ：

階層が固定なら、それぞれの階層ごとのマスタもて

113 ：

お前ら再帰テーブルに参照整合性設定しないの？

114 ：

音楽のアルバムをデーターベースに格納するとしたらどういう方法が適切でしょうか？
一つのテーブルに複数のアルバムデータを突っ込む場合、

アルバム名　　　　曲名
hoge　　　　　　　　AAA
hoge　　　　　　　　BBB
hoge　　　　　　　　CCC
hoge　　　　　　　　DDD
hoge　　　　　　　　EEE
hoge　　　　　　　　FFF
fuga　　　　　　　　GGG
fuga　　　　　　　　HHH
fuga　　　　　　　　ＩＩＩ
って感じでデータを入れていこうと思ったんですが、
もし後から、hogeのアルバム曲を一曲入れ忘れてた！ってことになった時、
その時点で挿入するとfugaの後ろに挿入されてしまうことになって順番がおかしくなってしまいます。
こんな設計ってまずいですよね？
何か良い設計方法があればアドバイスください

115 ：

>>114
良い設計法を聞く前にまず教科書を開いた方がよい。
データベースってどのDBのことを言っているか分からないけれども、関係
データベースのことであれば本当に一番の基本を理解していない。

116 ：

>>115
基本ってどの辺のことを言ってますか？
当然上記のイメージはわかりやすくするために書いただけであって、
アルバム名とか曲名にはそれぞれIDを割り振ってあり、それをもとにテーブルを作るつもりです。
一応参考書を読んできた上で質問してます
よろしくお願い致します。

117 ：

>>116
「関係データベースでは表の中の行は順序を持たない」
関係データベースの大前提。読み飛ばしたのかこんな事も書いていない半端な
ハウツー本を読んでいるのかはっきりしてほしい。

118 ：

>>117
ありがとうございます。
WEBデーターベースの構築技術ってのを読みました
そんなこと書いてなかった気がします。
つまり、順序は気にしなくていいから今までどおりでいいって事でしょうか？

119 ：

1対多テーブルを結合して横持ちデータのように表示したいことってよくあると思うけど、
何で一発でそれができるクエリってないのかな？
俺が知らないだけですか？

120 ：

>>118
そゆこと。行が格納されている順序は気にしなくて良いというか、その
順序は意味を持たないし、行を挿入した順序が保存される保証もない
ということ。別に順序が無くたってhogeで絞り込めばhogeに含まれる曲は
過不足無く出てくるので、それで良い。

121 ：

電磁波犯罪集団ストーカー認知撲滅！！

122 ：

>>120
なるほど！
本当にありがとうございました！

123 ：

>>119
http://toro.2ch.net/test/read.cgi/db/1343899481/7

124 ：

>>105のやつってやっぱり難しいですか？

125 ：

条件色々だから、あまり条件変わらないならアプリ側で制御した方がいいよ。
特に、全て単純な選択ならいいけど、複数選択とか、さらにはいきなり項目に
よっては数値入力とかは結構大変。
条件とか入力項目を動的に変えたいとか言われたら、簡単なインタープリター
を作るぐらいのことが必要だと思う。

126 ：

>>125
そっか　ありがとう　自分で難しいと思いつつ、
アンケートとかでこうゆうのって結構ありそうだから
普通はどうやってるのか、なんかよくあるやり方あるのかと思って気になってたんだ
実際受けた仕事だったんだけどこれでいいのか？と思いつつやってて気になってた
色だったら「黄色」っていうカラムを作ったりしたの
正直インタープリターと聞いてもわからん…けどそれは後で調べるとして
とにかくありがとう

127 ：

>>108
定期的にこの手の話題出るよな

128 ：

ユーザーIDを下記のような組み合わせで管理していきたいと思っています。
組…101等
番号…001等（前述の組の中での連番）
ユーザーID…101001等（組と番号の組み合わせ）
組毎のテーブルを作成して、番号をAUTO_INCREMENTで採番していく…など考えたのですが、
この場合、ユーザーIDというカラムが作成できない、など初歩的な問題で躓いています。
ユーザーIDのカラムは、今後管理していく上で必須と考えていますが、それを持たせる方法が思いつきません。
MySQLのハウツー本などを読んでいますが、利用できる機能などが目に止まらず、
アドバイスいただけると助かります。

129 ：

組と番号で複合キーにすれば？

130 ：

ユーザーIDは、組と番号から出来てる
算出できるので、実テーブルのデータとしては不要、というか持っちゃいけない

131 ：

ユーザIDに意味をもたせようと思うのがそもそもの間違い

132 ：

ユーザIDに意味はあるだろ。
そして、ユーザーIDにどういう形式を望むかというのも要件の内だ。

133 ：

その場合はそのユーザＩＤと呼ばれる情報がどういう情報か判断し
それがそのままテーブルのカラムとして適合するか、行の識別子として
ふさわしいかどうかを判断する必要がある

134 ：

view

135 ：

>>129-134
単純に登録後の編集や他テーブルとのユーザー関連付けの利用を考えていました。
複合キーとした場合、１つのテーブルで全ユーザーを…とした場合、登録時に採番の手段が思いつきませんでした。
また、実テーブルにこそ、ユーザーIDを置いておいた方が個々のユーザー情報にアクセスするのに便利かと
考えていましたが、そうでもないようなご意見もあり、viewをユーザー情報のマスター（一元管理元）と
するのもアリなのでしょうか。
組毎のテーブル…初回登録時に利用。存在する組分テーブルを作成（番号カラムをAUTO_INCREMENTで採番）
マスターテーブル（view）…登録後の編集及び他テーブルと連携（ユーザーIDカラムをconcatで作成）
として、登録後は、マスターテーブルを軸にユーザー情報にアクセスしていく考えはそれほど外れてはいないでしょうか？

136 ：

プライマリキーについて質問です。
左二桁を年にして残りを年ごとの連番で固定長にしてるんだけど、
可変長の連番より優れた点があるのでしょうか？
うちの会社はみんなそうなんだけど、
聞くと桁数が増えすぎるからって言うんです。
残りを仮に五桁として一年で8000件だったら、
逆に2000ぶんの番号が無駄な気がします。
見た目の問題ですかね？

137 ：

DBによる

138 ：

>>135
パーティションテーブルでもなく、同じ構造のテーブルを沢山作ろうという発想がまずありえない。
単に組番号ごとの最大値を保持するためのテーブルを作ればいい。
MySQLにシーケンスはないが、手動でそれと同様の処理を行うことはできる。
テーブル
組番号　PK
枝番　integer　default　1
INSERT　INTO　テーブル　(組番号)　VALUES　(x)　ON　DUPLICATE　KEY　UPDATE　枝番　=　枝番　+　1;
SELECT　枝番　FROM　テーブル　WHERE　組番号　=　x;
で次の枝番を取得してユーザIDを整形して返すようなfunctionでも作ればいい
当たり前だがトランザクション処理の出来ないストレージエンジンだと無理

139 ：

>>135
まず正規化を理解しろ

140 ：

>>138
ありがとうございます。アドバイスいただいた内容が大変ためになりました。
ご指摘の点は最もで、その実装方法に妥当な手段が見いだせず、前述のような拙い構想となってしまいました。
アドバイスいただいた通りにfunctionを作成して、採番していくようにしたいと思います。
みなさん、色々ご指摘いただき、ありがとうございました。

141 ：

犯罪者個人に対してR状を違法派遣・偽装請負・偽装出向・多重派遣の被害者が作成(刑事Rは無料)　or 司法書士が代筆（料金は5万円ぐらい）※コピペ歓迎
↓
R状を【検察の直告班】に郵便局の内容証明付で送付（疎明資料・証拠にはＩＣレコーダー、スマホによる録音が適しています）
↓
審査　→　不受理　→　R状再提出または刑法 第193条で訴えを起こす
↓
受理　→　R事実を認め示談交渉（↓）　→示談成立　→　法廷相場50〜100万円の示談金　※示談拒否が良い
↓　　　　　　　　　　　　　　　　↓
事案化←　前科あり　←示談不成立（↓）→　示談外交渉→　犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓　　　　　　　　　　　　　　　　↓
↓　　　　　　　　　　　　　　　起訴　→公判　→　罰金刑＝前科（起訴事実を認めてるため）→追討ち民事訴訟
↓　　　　　　　　　　　　　　　　　　　　
審査　→　起訴（強制捜査・留置場）→　公判　→　懲役刑などの厳罰（反省が認められないため）→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第３０条（検察審査会へ申し立て）→　起訴　→　起訴後は同上
刑法 第193条（公務員職権濫用）で検察事務官を刑事R　→　同上
◎R→R受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約（公正証書・即決和解で秘密保持契約）
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者にRできます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事R（刑事訴訟法239条1項）も可能です。
加害者本人、管理間接部門の社員が刑事Rに踏み切る場合も和解金による解決が妥当です。
注意：Rが受理されない理由
●３年間（※）の時効が過ぎたもの　※違法派遣
●同一事実について過去にR取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの　※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事Rは有効です。

142 ：

３行でお願いします。

143 ：

Rの趣旨
　被R人は、以下に該当すると考えるので、被R人の厳重な処罰を求めるためRします。
　職務経歴書を提示した事前面接を実施　または　偽装請負　または　偽装出向
　　労働者派遣法第26条（契約の内容等）、職業安定法第44条（労働者供給）に違反
　多重派遣・多重出向
　　労働基準法第6条（中間搾取の禁止）に違反
疎明資料
　事前面接日時、場所、出席者、資料のコピー、音声記録
　就業場所・就業期間・就業時間
　指揮命令
　　指示を誰が行っているかの記録、音声記録
　仕事で使う道具や、資材の負担（所有）のあり方
　　業務で使用しているパソコン・備品などの所有者
　契約書
　　請負、雇用契約書、出向指示など書面のコピー
刑事Rガイダンス　
★痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払わせて解決するのが絶対的過半数です。和解で解決しない事案、つまり公訴までいって判例となる事例を探すほうが難しいことでしょう。
★録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
★R状を検察に提出しても受理されなければ加害者側には知られることはありません。不受理の場合は何事も起きてないように粛々と振る舞ってください。
★Rを取り下げるとき検察に提出した資料は全て返却されます。また検察があなたが提出した証拠をあなたの許可なく裁判の証拠として使用はできません。Rを取り下げたのちの録音資料には当事者の立場が失われるため証拠能力はありません。
★和解時にRした事実は秘匿事項となります。犯罪者が秘密保持契約に違反した場合の損害賠償金は「即決和解」か「公正証書」で最低5000万円〜にしましょう。支払いを拒否すれば強制執行手続きを地方裁判所に上訴（裁判不要）してください。
★派遣会社や事業会社が同業者に貴方の情報をリークしたなら、同業者（又は競合他社）に弱みを握られることになります。
余程信用のおける相手でなければ、リークはできないでしょう。信頼のおける方にしても、その方の口が軽ければ、いずれ事実は分かります。
★リークの情報を得た事業者のなかには、リークの事実を貴方に教えてくれる方がいるかもしれません。その際は損害賠償金で得たお金の３割程度を謝礼金として渡してください。

144 ：

　　●●●ケネディ大統領は何故、死なねばならなかったのか？●●●
　　http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1226114724/53
　　￥￥￥￥￥￥￥『万有サロン』書き込み大賞・総額100万円￥￥￥￥￥￥￥￥￥￥￥￥
　　この掲示板に優秀な書き込みをして、総額100万円の賞金をゲットしよう！(*^^)v
　　　　万有サロン
　　　　　　http://jbbs.livedoor.jp/study/3729/
　　　　書き込み大賞の詳細
　　　　　　http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1069922074/78-
　　　　書き込み大賞の詳細(資料倉庫内)
　　　　　　http://www2.tba.t-com.ne.jp/a-z/omake/banyu/taisho.htm
　　また、あらゆる疑問に関する質問を、携帯電話やメールでも受け付けています。
　　　　電話番号　080-4437-4187
　　　　メール　　aaa-zzz@tba.t-com.ne.jp

　　￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥

145 ：

パワハラ犯罪にたいする刑事罰(※本投稿のコピペ歓迎です)
人事原則
１　現行法では、社員が仕事を怠けたり、能力不足、就業規則違反、目標を達成できなくても解雇をしたり叱責することは違法です。どんな駄目社員、嘘つき社員、怠け者も定年まで解雇が違法なのが現行の正社員制度です。
２　パワハラは社風にあわない社員、成績の振るわない社員を自主退職に追い込む言わば人事的措置として用いられることが多い。
※違法な解雇の和解金相場は、労働審判で３ヶ月、通常裁判で１年以上の報酬、さらに社員が和解を拒めば復職が可能です。弁護士への着手金は12〜15万円＋20%の和解金、和解拒否なら20〜50万円程度。
人事部・ホットライン・御用組合へ直訴
メリット：　一時的緩和や人事異動
デメリット：　役員へ情報筒抜け、危険分子の烙印（情報漏洩がホットライン直訴者に多いのは人事部の常識）、パワハラ放置で自主退職に追い込まれる
民事訴訟・調停・労働審判
メリット：　損害賠償
デメリット：　裁判費用、解雇措置、民事不介入で刑事事案化を阻止、長期係争、パワハラ上司の継続雇用
刑事R
メリット：　１パワハラ上司の解雇・懲戒、または２多額の和解金、１と２どちらでも被害者の雇用は維持
デメリット：　人事異動（出世コースから外れる）
◎録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
◎R受理後の和解金は加害者の資産・収入に応じて変えてください。犯罪者の昨年の年収の半額程度×最大懲役年数が妥当です。
◎パワハラの被害についてのRは１侮辱罪２脅迫罪３強要罪４威力業務妨害罪５傷害罪の順序で行ってください。警察・検察の協力（犯罪者の自宅・職場の強制捜査、留置所勾留）により罪の立証が楽になります。
◎刑事Rした社員を解雇したり処遇面で著しい差別を行うことはないでしょうが、出世や管理職以上の昇進の可能性はあきらめるべきでしょう。
◎刑事Rは民事訴訟と違って裁判による被害者への2次被害にありません。検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間もR状をかくことと音声録音を残すだけです。
◎和解契約（公正証書・即決和解）ではRした事実は秘匿事項となります。犯罪者が秘密保持契約を違反した場合の損害賠償金は、最低5000万円〜にしましょう。

146 ：

楽々ERDレッスンを読んだら無性にER図が描きたくなったけどネタがない

147 ：

※本投稿の拡散お願い致します。
◯外国労働者を海外から日本の企業での作業（物理的に日本にいる必要はない）に従事させる場合、海外の受注者は派遣業者として登録し派遣法に準拠しなければならない。違反すれば職安法違反となる。
◯事前面接時の会話、テレビ会議、国際電話を通じた日本からの指揮命令・技術指導はICレコーダー・スマホで録音してください。
◯中国・インド・ベトナム・韓国でのアウトソースを標榜しても派遣とみなす作業があれば労働基準法、職業安定法の責任は雇用主＝発注者にあります。
◯雇用主とは外注している元請けと下請けを含みます
◯中国人、ベトナム人、インド人、韓国人の方で偽装請負、偽装出向、多重派遣の被害を受けた方は日本の検察に刑事Rをしてください。
◯国境が違っても顧客＝発注者が日本にいれば、日本の法律を適用できますので是非ご活用ください。
◯刑事Rは無料です。元請けの各役員報酬は数千万円はゆうに超えているでしょうから、
総額で４０００万円〜程度の和解金となるでしょう。
和解金の相場は日本の相場に準拠しますので、皆様の国の平均生涯年収を超えることは間違いないでしょう。

148 ：

操作ログやアクセスログをユーザ毎に保存するテーブルがあります。
今までは1つのテーブルで全ユーザのログを保存していたのですが、
ユーザが増えてくると、かなりSELECTが遅くなりました。
1000万件をWHEREで抽出する場合、1分弱かかります。
（インデックスは適切に貼っています）
ORDERを指定しないと早く表示できるのですが、
記録日時を降順にしたいので、ORDERを使う必要があります。
そこで「ユーザごとにログを記録するテーブルを作成する」
という事を思いついたのですが、これは設計として正しいのでしょうか？
テーブルのカラム構成は後々変わらないとは思います。
ただ、ユーザごとにテーブルを作ると、
ユーザ1万人にテーブル1万個とかになるので、正しくない気がしています。
何か良いアドバイスがあったらお願いします。

149 ：

ORDER指定するカラムにはインデックスあるの？
1000万件程度で1分かかるのはおかしいな。

150 ：

>>149
あります。インデックスの指定やSQL文を色々試したのですが、
やはり1分以上かかります。ORDER指定しないと速いのですが。

151 ：

>>148
何のデータベースを使ってるのかしらないけど、まず実行計画を見てどうやって検索されているのか把握

152 ：

>>148
まず確認
>1000万件をWHEREで抽出する場合、1分弱かかります
1000万件を抽出するのか？
1000万件から抽出するんじゃないのか？そのばあい抽出される件数は何件ぐらいだ？
ORDERなしで早いってことは、時間かかってるのはソートだと思われる
つまりORDERにインデックスは（あっても）効いてない
まあまずは実行計画確認するべきだが
ここ設計スレなんで本題
>ユーザ1万人にテーブル1万個とかになるので、正しくない気がしています。
正しくありません
まずはDBMSの機能で、テーブルを分離する機能の検討を

153 ：

>>151
MySQLの5.5.16を使っています。
テーブルのカラムは、id・user_id・date・timeとシンプルな構成です。
これに1000万件のデータが有る状態で
SSHのコマンドから
SELECT user_id FROM access WHERE date='2013-02-06' ORDER BY date DESC
みたいなSQL文を実行すると、1分はかかります。
サーバはCentOS5のCore i5でRAM8GBなので
そこそこのスペックではあると思います。
パーティショニングも考えたのですが、
会員が1万人以上いますし、テーブルを分けたほうがいいのではないか？
と思い、>>148を思いついた次第です。

154 ：

>>152
テーブル構成や諸々の条件は>>153に書きました。
インデックスはuser_idとdateに貼っています。
LIMITを1にしても1分以上はかかります。
>>148の設計が正しくないとすれば、どうするのが最善なのでしょうか？
EXPLAINをしてもよくわからないので、悩んでいます。

155 ：

EXPLAINしてみ
テーブル分けて会員ごとに検索するテーブル替えるのかよ

156 ：

>>152
いやいや、ORDERなしなら速いということだから、
> まずはDBMSの機能で、テーブルを分離する機能の検討を
の必要は多分ないんじゃないか？
適切なINDEXが本当に貼られてるのか、適切なクエリなのかをまず考えるべき。
1000万件にまで成長したのがサービス開始から1年で、これ以降数年、10数年そのまま運用するとかいう
ことなら、パーティショニングを考えたほうがいいとは思うけど。

157 ：

あと、いくらテーブル分けたって、同一の会員のレコード数が同じなら
結局ソートにかかる時間はかわらないと思うが。

158 ：

パーティショニングするにしても、日付が条件なのだから年単位とかでパーティショニングすべき

159 ：

MySQLスレに行った方がいいかも・・・

160 ：

>>153
LIMIT 1とかじゃなくて、検索結果は全部で何件あるんだって話
極端な話、1000万件全部'2013-02-06' だったらインデックス意味ないから
あとMySQLよく知らないが、サーバマシンの全CPUと全メモリ使ってるとは限らんぞ
インデックスはuser_idとdate、それぞれに張ってるのか？
その条件で(user_id,date)の複合インデックスだと多分役に立たない
(date,user_id)の複合インデックスなら(dateの単独よりちょっとだけ)効果あるかもな
でも普通に考えるとdateのインデックスが効いてない気がする
MySQLってインデックスに順序指定あるか？あるならちゃんとdate DESCで定義してるか？

161 ：

テーブルの性器性が高すぎるのでは？
例えば、重複するかもしれないけど
user_id_kami_yonnketa
user_id_simo_yonnketa
YYYYMM
MMDD
HHMM
MMSS
とか汎用するクェリーに合わせて
検索加速用の項目を追加するというのが
定石
一時テーブルなどに絞込みを落としてから
再度詳細検索をすると早くなると思います。
他にもテーブルの時期別の重複分割
を行うなどの方法も有力な感じですが...

162 ：

>>161
それ最悪

163 ：

>>161
>検索加速用の項目を追加するというのが 定石
>一時テーブルなどに絞込みを落としてから
それ何年前の話なんだ
今時ならビューつくってインデックス張るだろ
それが出来ないDBMSなら大規模データの取り扱い諦めろ

164 ：

>>160
>インデックスはuser_idとdate、それぞれに張ってるのか？
いえ、複合です。その複合の順序もどっちが速いか検査しました。
正直、あまりインデックスが効いてない気がするのですが、
効いてるかどうか調べる方法ってあるんですかね？
EXPLAINでも特に以上は無さそうですし。
>>161
とにかくORDERしないと速いんです。1秒もかかりません。
日付に関してはDATEとTIMEで分けてますが、
タイムスタンプは保存していません。
どうやったら1000万件のレコードをORDERしても
速くSELECT出来るのかわかりませんが、
取り敢えず設計的に>>148が間違っているのでしたら
代替え案をお願い出来ればと思います。
SELECTの速さやパーティショニングの切り方については
またMySQLスレで聞きます。

165 ：

いや、そのインデックスが効いてるかどうか見るのが実行計画なんだが

166 ：

>>164
何回も聞いてるが、出力される件数は何件なんだよ？
SELECTした結果が1000万件なのか？1000万件の並べ替えならある程度時間かかるのはしょうがないかもしれん
SELECTした結果が数千件なら何分もかかるのはおかしい
代替え案なんかねえよ
設計かえるんじゃなくて正しくチューニングしろ

167 ：

情報をなるべく出さないで解答を引き出すやり方は公務員か？

168 ：

http://d.hatena.ne.jp/rti7743/20080629
これのことか？

169 ：

>>166
>>154にLIMIT 1って書きましたが、これでは不足でしょうか？
SELECTした結果は1件です。LIMITしてない場合の条件でも。
出来るだけ情報は出してきたつもりですし、
MySQLのkey_buffer_sizeやsort_buffer_sizeのチューニングはしましたが、
本題は>>148の通り、設計の相談です。
皆さんの回答が「1つのテーブルで何とかするのが定石だ。
だからSQLの結果について尋ねてる」と言われるなら納得しますが、
あくまでDB設計について相談したいのです。

170 ：

インデックスは適切に張ってるとかEXPLAINは問題ないとか言われても、
「じゃあ問題ないんだろう」としか言えんわな。

171 ：

SQLの相談じゃなくて設計の相談だって言ってるだろうが
いい加減分かれよクズどもが

172 ：

ヒット率が高いSelectならOrderしない場合早くても
不思議はないが、Orderすると遅いのは
インデクスが効率的になっていないからじゃね？
キーのカーディナリティが複雑になってたりすると
インデクスの手段がカーディナリティにマッチして
いない可能性がある。
キーのカーディナリティを単純にする方法は
やはりキーの分割ね。非正規項目に分割して
それぞれにインデクスを振るって幹事。

173 ：

>>171は私ではありません。
とりあえず、皆さんの意見を見ると
複数テーブルに分けないのが正しいと思いますので
その方向性で考えてみます。
たぶん>>168の記事をするとだいぶ変わると思います。
色々とアドバイスありがとうございました。

174 ：

>>169
カーディナリって理解してるか？
検索対象全体のうちでインデックスにより取得される件数の割合聞いてるの
それが多いとインデックス使っても早くならなくなるから
LIMIT 1でも、その1件を調べるには検索結果を全て並べ替える必要があるのは理解できるか？
>>172
カーディナリが複雑とか単純とか初めて聞いたけど
カーディナリが複雑ってのはどういう状況か説明してくれんか
あとカーディナリ低いキーを分割してもカーディナリは高くはならんと思うが
キー分割でインデックスが効率化される理由も教えてくれんか
>>173
設計については複数テーブルなんてパーティショニング出来なかった時代ならともかく
今時のDBでは普通は正規化崩してまでやる必要ない
ざっと見た感じ>>168の記事の内容は最後のとんでもないの除けばすでに全部言われてるだろ
あとちょっと調べたところだと、MySQLではインデックスの順序指定は無効らしい
昇順で遅いかどうか調べて実行計画比較すれば何かわかるかもな

175 ：

概念的には、1000万行程度なら一つのテーブルでいいに決まってるんだから、現状遅い原因をつきとめ、
それを解消するのをテーブル設計に求めるのか、その他の物理設計（パーティショニング等）に求めるのか、
あるいはMySQLのパラメータチューニングをするのかを判断しないとだよ。
で、それをするには、今使っているMySQLのバージョンとサーバのスペック、テーブル定義情報、
クエリの内容、EXPLAINの結果を出すしかなく、そしてそれはMySQLスレが適切な場所。

176 ：

そもそもアクセスログなんて頻繁に見るものかいな？

177 ：

めったに見ないとしても、見るときに一分近くもかかるのはどうかと思う。

178 ：

ログなんてユーザーが見るもんじゃないだろ
何かあったとき見りゃいいんだから
一分ぐらい待ってやれよｗ
148がログを取ってる目的はよくわからんが

179 ：

色んなユーザーのログを見たいときに、いちいち一分待つのか？
タイトな状況での障害解析したことない素人さんならではの発想だな。

180 ：

どうしても1分かかるならしょうがないんだが
少なくとも今の前提で1分かかるのはおかしいって話だからな

181 ：

なんだこの板は・・・質問者も回答者もレベルが低すぎてお話にならぁぁぁあぁん

182 ：

>>181

183 ：

テーブルにカラムを追加する必要があって、なおかつそのカラムがNULLになる可能性があるとき、
カラムを追加するより
create table new_attr (
id integer not null, -- fk
attr text not null
);
みたいなテーブル作れって記事をどこかで見かけたんだけど、その記事見たことある人いますか？

184 ：

>>183
そのテーブルは「縦持ち」や「行持ち」と言われる構造。
「縦持ち」「横持ち」とか「行持ち」「列持ち」でググればそれぞれの長所短所を紹介したページは引っかかるよ。

185 ：

カラム追加するのに別テーブルにしろって話だろ
縦持ち横持ちとはちがうんじゃね

186 ：

>>184
「縦持ち」「横持ち」というより、nullable columnの追加に関するトピックです。
なお、その記事を書いた人が、カラム追加時のみならず、最初からnullable columnは別テーブルに
しろと言ってたかどうかはわかりません。

187 ：

nullableだとか一つのカラムだけ見ていてテーブル設計を云々する記事は読む価値無し。

188 ：

>>187
私の言い方が悪いのか、内容が伝わってない気がします。
カラムの追加が必要になる場合の話なので、一つのカラムに着目するのは当然です。
そして、その追加されるカラムがNOT NULLなのであれば、NULL許容派もNULL撲滅派も
ADD COLUMNすることに異議は無いと思います。
しかし、そのカラムがnullableの場合にどうすべきかという話で、なぜ別テーブルにした方が
良いとその人が主張していたのかを今一度確認したいので、そのような記事を見かけた人は
居ませんかと質問した次第です。

189 ：

第6正規形の話かな。

190 ：

>>188
論理設計ではnullableか否かは全く関係ないから物理設計の話だな
つまりパフォーマンス以外の理由は存在しない。特定のDBMSではnullableカラムを追加する場合は別テーブルに分けるとパフォーマンス的に良いって話だろ

191 ：

>>188
>カラムの追加が必要になる場合の話なので、一つのカラムに着目するのは当然です。
カラムを追加するのであれば既にテーブルに存在しているカラムとの従属性などを
分析するのは当然だし、既にテーブルに入っているデータのマイグレーションと
いう観点からだとスキーマだけではなく既にあるデータとの関連も検討しなく
ちゃいけない。
そして別テーブルに分けるとなると参照はともかく更新処理は一段と複雑になる
のでアプリケーション側との関係も見なくちゃいけない。
>そして、その追加されるカラムがNOT NULLなのであれば、NULL許容派もNULL撲滅派も
>ADD COLUMNすることに異議は無いと思います
許容派だろうが撲滅派だろうが異論以前の話。
「NOT NULL云々だけで判断するかボケ」で終わる話。

192 ：

3値論理って物理設計の話だったのか

193 ：

>>191
> 許容派だろうが撲滅派だろうが異論以前の話。
> 「NOT NULL云々だけで判断するかボケ」で終わる話。
NOT NULLなカラムなら両派とも異論はないだろうが、NULL可なカラムだと違うんじゃないのってことでしょ。

194 ：

なかなか真意が伝わりません。
別テーブルに分けることの是非を聞きたいのではなくて、「別テーブルにすべしという主張があるなら、
その理由を知りたい」のです。
以前、そうすべしという記事を見かけた記憶があり、もし誰かご存じならもう一度読み直してみたいのです。
「NULL撲滅派だから、別テーブルにするよ」以外の理由で、同じく別テーブルにすべしと考えている方が
いらっしゃるなら、是非その理由を教えて下さい。

195 ：

>>193
NOT NULLだと自動的にADD COLUMNという話になるわけじゃないでしょ。
NOT NULLだろうが追加するカラムが推移的従属にあるのなら別テーブルに分ける
ことも検討するし、NOT NULLであっても既存のレコードのカラムに埋められるのが
単なる空値であれば空値を取っ払って別テーブルにすることもある。
そしてnullableにする場合はデータの文脈の中でnullの指し示す意味をはっきりさせ
なくちゃいけない。
つまるところ別テーブルにするかなんて基本的にはNOT NULL以前のデータモデリング
の段階でケリがついているべき話であって、一つのカラム定義を見て別テーブルに分ける
のを悩むヒマがあるのならモデル設計に立ち戻らんと意味が無いと言うこと。
仮にパフォーマンス云々の話であれば、どのようなDBMSの上でどのようなクエリや
トランザクションが走るのかが問題なので、一つのカラムのNOT NULL云々だけ見て忖度
することにはますます意味が無い。

196 ：

>>195
DBMSによってはnullableの場合のみ別テーブルにカラム追加したほうがパフォーマンスが向上する、
という可能性はあるのでは？

197 ：

>>195
データの文脈の中でnullの指し示す意味をはっきりさせた結果、nullableなとして追加する必要があるとき、
それをadd columnするか別テーブルにするかって話でしょ。
それと、多分、君の持論なんか聞きたくないと思うよ。

198 ：

>>195
要約「ケースバイケースだからなんとも言えない」

199 ：

>>197
>データの文脈の中でnullの指し示す意味をはっきりさせた結果、nullableなとして追加する必要があるとき
結構。ちゃんとnullの指し示す意味がはっきりしたのであれば、add column云々の
是非はまず「nullの指し示す意味」に依存でしょ。例えばnullが指し示すのが単なる空値で
あればadd columnではなくnot nullなカラムを持つ別テーブルに分ける選択肢は出てくる。
他方でnullを「未定義」として扱いIS NULL等でクエリの中でも使うのであれば別のテーブル
に分けるメリット少なくなる可能性は出てくる。
さらにパフォーマンス云々を言うのであればnullが占める割合も考える必要はある。よって
>それをadd columnするか別テーブルにするかって話でしょ
要約「ケースバイケースだからなんとも言えない」。NOT NULLだけでは何も言えない。

200 ：

>>199
マジで何を言いたいのか良くわからんわ。

201 ：

>>200
別テーブルに分けるという行為が及ぼす副作用が良い点悪い点含めて多岐に及ぶため、
一概に「どうすべき」という話はできないということ

202 ：

>>195
別テーブルにしたらnullableになるじゃん。NOT NULL制約を保証できないんだから。

203 ：

べき論ができないのなら、最初からシンプルにそれだけ言えばいいのに

204 ：

パフォーマンス云々ていうけどテーブルにaddしようが別テーブルにしようが
実際に物理的にどう配置されるかはDBMSの設計次第じゃないの？

205 ：

まあとりあえず>>183にどこでそんな記事をみたのか思い出してもらって
そこにどんな前提でそうしろと書いてあったかだな
まあ俺ならどんな理由であれそんな記事信用しないが
特別な前提でパフォーマンスに有利だとしても他人に薦めるようなもんじゃないだろ

206 ：

単純に、主テーブルがでかくて、その属性を持つレコードが少ない時に
>>183 みたいにすれば、パフォーマンスがあがるケースがあると言うだ
けのことだろ。

207 ：

そんなの実装依存じゃんｗ

208 ：

読む価値無し臭は普通に漂う。

209 ：

>>207
実装依存としか書けないなら、いちいちでてくるなよ… ウザイから。

210 ：

>>209
いちいち指摘するお前もウザいけどな

211 ：

>>210-211
>>210

212 ：

元のテーブルに列追加すると、関連するプログラムの再テストが必要になるから、
別にID+追加項目のテーブルを作って、必要な箇所だけ修正する、
と言うのが、パッケージに近いシステム開発の場合の設計としてあるって聞いたことがある。

213 ：

それはシステム開発としてはあり得るが、ＤＢ設計としては間違ってる
つかそれNULL可とか関係ないし

214 ：

>>213
1対1のデータはテーブル分割したらダメってことですか？

215 ：

あとから列を追加するような設計ってことだろｗ

216 ：

本来テーブルに追加すべき項目を別テーブルに持たすのはＤＢ設計として間違ってるって言ってるんだよ
>>214
１対１とかテーブル分割とかどっから出てきた話なんだよ
>>215
むしろ後から要件変更で（本来なら）列を追加する話なんだが

217 ：

>>214
そもそも、分割したら1:1じゃなくて1:0-1になるわけだが。

218 ：

は？
設計段階で追加がありうる話をすること自体おかしいだろｗ

219 ：

お久しぶりです。
私の書き込みが、一部の人をモヤモヤさせていたらすみません。
さて、あれからも時々一体どこで見たのか思い出してみたり、思いついたキーワードで検索してみたり
してるのですが、ひょっとしたらこれなのかもというキーワードを発見しました。
Records with extra properties: sparse table or EAV?
http://stackoverflow.com/questions/3486019/records-with-extra-properties-sparse-table-or-eav
キーワードは、sparse tableとEAVです。
なお、このページは、最初に読んだページではありません。

220 ：

軽くググったところ、EAVは書籍『SQLアンチパターン』（私は未読）にも取り上げられてますね。
メリットは多少あるけど、デメリットの方が多い「アンチパターン」として評価されています。
http://penguinlab.jp/wiki/SQL_%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3#Entity-Attribute-Value
を見ると、『SQLアンチパターン』の解決方法は、テーブル継承か準構造化データ（subtype の属性を、
BLOB な列に XML や JSON などでシリアライズしたデータを保持する）みたいですが、これらを
ネイティブに扱えるRDBMSは少ないんじゃないでしょうか。
SQL Serverでは、>>219のリンク先にあるように、"Sparse Columns"というのを使うのがベストプラクティス
なんでしょうか。

221 ：

訂正。
テーブル継承は、PostgreSQLで言うところのものではなかったです。勘違いしてました。

222 ：

だから場合によるとしか・・・
NOT NULLだとかスパースだとか、RDBMSが何だとかそんな断片的な話だけで判断する人なんかいないよ。

223 ：

何も言うこと持ってないのに、なんでコメントするんだか

224 ：

中学生だから

225 ：

必須でない属性を追加するときの話なんだからNULLかどうかは関係あるし、
処理系によってベストな物理設計があるなら、その話してもいいじゃん。
俺もよくこの手の問題にぶちあたることがあったけど、EAVっていう概念を
知らなかったから、選択肢を知れてよかったよ。

226 ：

そもそも、SQLアンチパターンに取り上げられる程の一般的な話題なんだから、
ケースバイケースだから何も言えないなんてことはないわけで。

227 ：

>>223
お前らの議論なんかくだらないんだよと言えば、自分がより上位にいる気分になるから。

228 ：

論理設計はできないけど
物理設計はできると思いますって言っちゃったけど
どう面接を切り抜けたらいいかな？
やっぱ実務経験ないのになんでできるんだよ
って突っ込まれると想う

229 ：

自分なりに勉強してると思ったら、
それぐらい勢いがあってもいいと思う。
面接では、結局はその人の回答の仕方や態度なんかを見ると思うから。
一緒に仕事がやっていけるやつかどうかを見る。
本当に論理設計や物理設計をできるやつを求めてて、
付け焼き刃でもそれに関する当面の仕事をこなせないと思ったら、事実を話した方がいいが、
迷惑をかけてでもその仕事をやりたいのであれば、押し通すことも否定はしない。
その場合死ぬ気でがんばるしかない。

230 ：

>>229
もう30だしターニングポイントだとおもうの
ちょっと頑張ってみようかな
ありがとうございます

231 ：

そんな質問する暇あったら、データベースの設計関連の本買って読めばいいのに。

232 ：

※本投稿の拡散歓迎です。
派遣労働者のパワハラ・セクハラ対応策について
下請け労働者、業務委託、派遣労働者は契約期間が短期という制約があり、契約更新拒否をちらつかせた不当な労働強要の実態があります。
雇用形態における壁・差別は法律に直接的規程はなくとも認められているわけではありません。
「正社員の有期雇用労働者に対する優先的地位乱用」による「侮辱罪」、「脅迫罪」、「強要罪」、「傷害罪」、条例違反で刑事Rできるが、
本稿では刑法ではなく労基法関連の対策に焦点をあてます。
労働基準法第5条（強制労働の禁止）（1年以上10年以下の懲役又は20万円以上300万円以下の罰金）
■精神の自由を不当に拘束する手段によつて、労働者の意思に反して労働を強制してはならない。
例：正規労働者（同僚）による残業の強制。仕事の期限が遅滞した際に「繰り返し」残業を示唆する。
例：派遣の仕事の回し方の裁量を正社員が決めるなどと示唆する。
例：飲み会、昼食、たばこの同伴を強要する。
労働基準法3条 （六箇月以下の懲役又は三十万円以下の罰金）
■社会的身分を理由として労働条件について差別的取扱をしてはならない。
例：社内制度に明示されていない指揮命令系統が正社員と派遣社員に存在する。
派遣社員も正社員と同様に社内制度に準じるという契約上、業務で平等に取り扱う必要がある。
例：社内制度上の上司でもない正社員が命令をしたり、仕事上の指導権・裁量・許可権限をもつこと
派遣契約の内容にそうした区別を制度化するような客観的な証拠がなければ派遣社員側に有利といえる。
例：派遣社員に業務上における裁量を一切与えず、非管理職の正社員が許可を与える
労基法3、5条については、経営責任も問えますので、刑事Rできる相手は以下のとおり。
派遣先　当該正社員
派遣先　指揮命令者
派遣元・派遣先　代表取締役
刑事R（R）の行い方ですが、内容証明郵便でR状（R状）を地方検察の直告班に郵送してください。

233 ：

属性が定まらない物はどういう方針でテーブルに落とし込めばいいですか？
例えば色々なサイトのアカウント情報を管理するテーブルを作りたいとします
サイトのログインに必要な情報は、ログインIDとパスワードの時もあれば、
ログインIDとメールアドレスとパスワードの時もあり、
またログインIDとパスワードと秘密の質問の時もあり、生年月日が必要な時もあります
実際にどんな情報が必要になるかは不定なので、必要になりそうな情報を前もって属性として用意しておくのは無理ですし、
かといって必要な属性が増えるたびに属性を追加すると、特定のサイトでしか必要ない属性が大量に増えて
テーブルがnullだらけになってしまいます
今自分で思いついている案は三つです
　・新たな属性が必要になるたびにどんどんテーブルに属性を追加していき、テーブルがnullだらけになっても気にしない
　・>>183の方法で新たな属性が増えたら新しいテーブルを作って管理する
　・そもそも「メールアドレス」や「パスワード」などを独立した属性として扱わず、>>219の方法で汎用属性テーブルで管理する

234 ：

フィールドじゃなくてレコードで管理したら？

235 ：

入力項目1 入力項目2 ... 入力項目n　だけは事前想定できるんだから
サイトID int,
入力順 int,
入力内容 varchar(適当)
こんな感じでいいんじゃね

236 ：

>>233
教科書的にいえば最初の案でいい

237 ：

KVS

238 ：

回答ありがとうございました。
>>234-236の案については昨日購入した書籍「SQLアンチパターン」にまさにその案が書いてあり、
それぞれのメリットとデメリットが書いてあったのでコメントは差し控えます。
>>237
アカウント情報の管理なんて教科書的な課題ですら関係データベースではうまく扱えないのですか？
もしそうなら関係データベースには失望しました。

239 ：

教科書的には(3)だと思うけれどもなぁ。
スキーマってのは一般に時間不変な構造をあらわすものでデータの追加と共にポンポコ列を
増やしたりテーブルを新設することが初めから前提になっている設計はちょっと疑ってか
かった方が良い。
この場合時間不変な構造は例えば「ユーザはあるサイトの入力項目のそれぞれについて値を
持つ」ということだろうから、関数従属性としては、
ユーザ, サイト, 入力項目 -> 値
という事になって、テーブル設計もそのまま、
userId, siteId, fieldId, value key: (userId, siteId, fieldId)
になると思うけど。

240 ：

>>239
本来異なる属性をひとつのカラムにまとめるのをよしとする教科書なんてないだろ。
新しい属性を追加するってのはスキーマの変更に他ならない。
>>238
RDBは一階述語論理に基づくものだからね。そこで表現できるところまでが限界。

241 ：

>>240
サイトの入力項目名を属性とするからおかしな事になる。そうしなければならない理由
なんてどこにもないのに。

242 ：

>>239は入力項目名を属性にしているが、それ自体は問題じゃない。
問題なのは値の属性が異なること。
まぁ、それも「なんでもあり」というひとつの属性だとみなすならば
ありっちゃありだけど、少なくとも教科書に出てくるような話じゃない。

243 ：

>>242
「値の属性」はvalueただ一つだけど。もしかして値のドメインの話をしている?

244 ：

お互いの教科書が違う気がするが。
いずれにせよ、どっちが正しくてどっちが間違いなんてことは無いんじゃないかな。
それとも、白黒はっきりさせないと死んじゃったりするの？

245 ：

>>244
業務でDB設計するときに気分で決めるの？
どっちにすべきかはっきりさせないってのはそういうことだよ

246 ：

>>245
つまり、どっちかに決めないと君は困るってこと？
だったら口出すのやめるから、思う存分どうぞ。

247 ：

>>240
う〜ん、「本来異なる」と書いているけれども、まずそこんところから疑った方が
良いんじゃないのかな。
ユーザー名やパスワードとかをそれぞれ「本来異なる」属性として表現する必要が
仮にあるとして、その具体的な根拠は何だろう?
何が属性になって何が属性にならないのかというのは決して自明ではないよ。

248 ：

ログインに必要な項目の定義と、ユーザの属性をごっちゃにしてるんじゃないかな。
ユーザの属性ならユーザマスタのカラムとしてidや氏名、メールアドレスなんかを
定義して、新規に属性が必要になったらカラム追加でいい。
でも今回はサイトごとのログインに必要な項目の定義をどう実現するかという
話だから、ユーザマスタのようにカラムを追加していけばいいって話じゃないよ。

249 ：

送信してしまった。
今回の属性は「ログインに必要な項目」で、その具体的な値がサイトごとにユーザidとか
パスワードとか生年月日とかをデータとして持つという設計の方が自然だと思う。

250 ：

新しいサイトの登録が必要になった場合、シス管がシステム止めて個別に登録していくので
あればカラムの追加でもテーブルの追加でも好きにやればよい。
でもユーザが新しくサイトを登録する場合など、DBに対するトランザクションの結果として
カラムやテーブルの追加が必要となるとすればそれは筋が悪い設計と言わざるを得ない。
(3)は教科書的ではないとか言うけれども、運用からみれば(1)(2)は論外だ。
ただ無意味に「汎用属性テーブル」とかいう名前に引きずられていないか。
製品個体番号, 部品ID, 部品製造年月日 key: (製品個体番号, 部品ID)
と
サイトURL, フィールドID, 入力値 key: (サイトURL, フィールドID)
ではどこが違うの? 後者は「汎用属性テーブル」とやらで前者はそうではないの?

251 ：

森羅万象テーブルってのが前なかったっけ。

252 ：

今行ってる現場のメイン設計者が森羅万象テーブル大好きに森羅万象クラス大好き。
汎用的にデータを格納しておくセッションのようなものです、って
それじゃ影響範囲調べるときに一苦労じゃあーりませんか
とは思っても、新参外様の俺が意見したところでろくに聞く耳持たないので、
適当に流すことにする。

253 ：

「色々なサイトのアカウント情報を管理したい」ってこんなに面倒な議論が必要になるような話なの？

254 ：

つまり面倒な議論の余地がない程度には確固ある答えがあると。

255 ：

設計論なんて正解はないしまじめに議論したら面倒にきまってる

256 ：

数日間調べてとりあえずの結論が出ました。
>>233の問題の本質は「非構造化データをどうやってRDBで扱うか」ということになりそうです。
>>233のようなデータは「非構造化データ（半構造データ）」と呼ばれます。
非構造化データをRDBで扱う方法についてはまだ模索中の段階であり決定的な方法論は見つかっていません。
つまり>>233について「正解」と呼べる答えはまだないということです。
しかし一長一短があるにせよRDBで半構造データを扱う方法についてはいくつか考案されています。
以下のページでは4つの方法が紹介されています。
> スキーマ不定のデータをRDBに永続化する方法の比較
> http://dev.ariel-networks.com/Members/inoue/schemaless/

257 ：

> 非構造化データをRDBで扱う方法についてはまだ模索中の段階であり
補足ですが、これはDB業界全体で模索しているという意味です。
個人的に模索中という意味ではありません。

258 ：

「非構造化データをRDBで扱う方法」に関してはRDBが始まった当初から、半構造化データが専ら
XMLの文脈で語られるようになって以降でも20年近く延々と模索されていて、主だった方法は殆ど
出尽くしている。
はっきりしているのはSQL92で議論できる範囲には「たった一つの気のきいた方法」は無い事で、
開発者それぞれが模索して受け持つ問題に対する最適な方法を選んだり、ベンダー拡張を使ったり、
既存の方法と知らずに車輪の再発明をしたあげくに意気揚々とblogに書いちゃう、というのが現状。
ただこれはあらゆる問題に対応する「たった一つの気のきいた方法」が無いことにすぎないのであって
>>233の例のように問題領域を絞ればそれなりに答えはあったりする。

259 ：

トレンド的には2000年代始めにベンダー拡張としてRDBMSのXML対応を競った時期があって、
それと並んでRDBMSなんてオワコンだとネイティブXML DBを称する製品がポコポコ出てきて、
でも前者は何時までベンダー拡張なんだ、後者もXQuery update facilityを決めるのに何年かか
っているんだコラ云々というデジュール標準の確率で足踏みしている間に大規模なスキーマレス
データの扱いに関してはドキュメント指向DBやらBig tableクローンにごっそり客をもっていかれ
SQL2003のXML対応もXML DBもイマイチ息しているようにみえない今日この頃。

260 ：

だからどうした

261 ：

確率

262 ：

実習を兼ねてRSSリーダーを作ろうとDB設計中なんだが
ユーザーがどのフィードアイテムを
どういうステータスにしているか（未読、既読等）管理したいとき
レコードが肥大化するのが気になってしまう
使用DBはMySQL
以下のテーブルがあって
・ユーザマスタ
・フィードアイテムテーブル
・フィード管理テーブル
以下の関係性
<--> 1:1
<-->>1:N
ユーザマスタ <-->> フィード管理テーブル
フィードアイテムテーブル <-->> フィード管理テーブル
懸念は、日に1000件フィードアイテムが追加されると
*ユーザの数だけフィード管理テーブルが追加されてしまう事
定期的にレコードを削除する運用を考えてるけど
何か他の設計方法ってあるかな

263 ：

ユーザとフィード(RSSとかATOMとか。フィード「アイテム」ではなく)の間に「購読」関連を入れる。
これにより一日1000件フィードアイテムが追加されてもフィードアイテムテーブルは1000件しか増えない。
ユーザー <- (フィード購読) -> フィード <->> フィードアイテム
その上で、ナイーブな方法としてはユーザとフィードアイテムの間に「未読」関連テーブルを入れる。
ユーザー <- (未読) -> フィードアイテム
フィードアイテムが追加されたら、そのフィードを購読しているユーザに「未読」を追加する。
ユーザがアイテム読んだら未読テーブルから該当するレコードを削除する。
全てのユーザが全てのフィードを購読しているのならともかく、普通はそれぞれのユーザは幾つかのフィード
しか購読しないので、「未読」テーブルへの追加数は「アイテム追加数 x ユーザ数」よりは少なくなる。
ただこれだと未読を何千件も抱えるようなユーザが多くなると厄介。
その場合は単純な「未読」関連の代わりに「フィード購読」関連に「ここまで読んだ」タイムスタンプを入れて、
これ以前の例外的な未読アイテムとこれ以降の例外的な既読アイテムを「アイテム状態」テーブルで管理する。
ユーザー <- (フィード購読, ここまで読んだ) -> フィード <->> フィードアイテム
ユーザー <- (アイテム状態, 既読or未読) -> フィードアイテム
この場合、フィードアイテムを追加しても「アイテム状態」テーブルには何もしない。
ユーザが未読アイテムを読んだときに「アイテム状態」テーブルにアイテムを「既読」として追加する。
「ここまで読んだ」以前のアイテムをユーザが手動で「未読」にした場合はアイテム状態テーブルにアイテムを
「未読」として追加する。
それ以前の既読数がゼロになったり「全てを既読にする」操作をユーザが行ったら「ここまで読んだ」タイム
スタンプを更新して不要なアイテム状態レコードを掃除する。ユーザの操作シナリオに応じて「ここまで読んだ」
タイムスタンプをどう上手く更新して状態レコードを掃除するかが勘所になると思う。

264 ：

>>263
フィードは100,200当たり前の世界だよ。
ちなみに俺は300個くらい購読してる。

265 ：

フィード管理とフィードアイテムがイマイチ何なのかよくわからんが
マルチユーザでの使用を前提としてるのか？
なのにフィードアイテムは全ユーザで共有するのか？

266 ：

ユーザテーブル
フィードの情報を入れるフィードテーブル
フィードアイテムテーブル
ユーザがどのフィードを購読しているかを入れる購読テーブル
購読テーブルにユーザ、フィードごとの未読ポイントを入れる。
フィードアイテムは消さない。
こんなかんじか。

267 ：

>>263
ありがとう
既読の線引きと 未読状態のレコード追加、参考にする
>>265
問題点を綺麗に切り取って説明できてない以上、
中途半端な情報じゃ別の疑問点が出てしまうな
申し訳ない
制作途中のER図
http://www1.axfc.net/uploader/so/2860702.png
※図、誤字訂正　「フィード管理」 -> 「フィードアイテム管理」

268 ：

いや、ＥＲ図だけ出されても、それがどういう要件で書かれたのかわからんと何とも言えんが

269 ：

ER図を起こすと、なんだか設計した気分になるの法則発動

270 ：

扱うデータが複雑すぎてどう設計してもテーブル数または属性数が膨大になってしまうようなデータは、
そもそもリレーショナルデータベースで扱うのが間違っているということでしょうか？
例えばインターネットのWebページを保存し検索するシステムを作る場合、
各ページの持っている属性は際限なく抽出できると思います（著者名、作成日、容量、言語、文字数、タイトル、更新回数など）
これらの属性をデータベースに格納しようとすると、属性が増えれば増えるほどテーブル設計が複雑になって
しまいには全く管理不能なデータベースになってしまうと思います

271 ：

>>270
抽出はいくらでもできるだろうけど、それを何に使うの？
普通使う目的を考えてから設計するから、むやみやたらに管理不能になんてならないよ。

272 ：

>>271
データを色々な角度から分析できるようにするために、とりあえずデータの持つ属性を大量に格納して
それからSQLで色々集計して試してみようと思ってました。例えば更新回数でソートしてみたり、作成日でソートしてみたり
そういった用途を設計時に具体的に限定しなければならないということですね、わかりました

273 ：

何に使うか決まらないうちから設計するのがおかしいだろｗ

274 ：

>>270
> 際限なく抽出できると思います
一回自分で思いつく属性書き出してみなよ。
管理不能になるほど思いつけたらたいしたもんだと思うよ。

275 ：

森羅万象テーブルでも作ろうとしてるのかね
汎用的なものを作ろうという試みはDB設計に限らずあらゆる分野でうまくいかないよ

276 ：

>>272
OLAPやROLAPというキーワードで調べてみると目的に近いものが見つかるかもしれない。
RDBも普通に使われる分野だよ。

277 ：

>>270
「人」が持っている属性は際限なく抽出できると思うけど、大抵のシステムでは
usersテーブルとかcustomerテーブルのように管理できている。

278 ：

よく使う一般的な属性と訳わかめなカオスな属性とで
テーブル分けておけばいいんでね？
逆にRDBMSの得意分野だと思うが
最悪カオスな方はデータぶっこ抜いてテーブルポイしちゃってもいいんだし

279 ：

DB設計で顧客テーブルのような、どんどんレコードが増えるテーブルに一意制約のキーを設定する場合、MYSQLのBIGINTで定義すると、最大値を超えてしまうケースがあります。
その場合、どのように設計すればいいのでしょうか。
複合キーにするのがいいのでしょうか。

280 ：

>>279
MySQLのBIGINTって、符号なしで10^20だぞ。
1億×1億×1800くらい。
どうやったら最大値を超えるんだ？

281 ：

>>280
やっぱり使い切りませんか。
使い切ってしまったことを考慮しようかどうか悩んでいました。

282 ：

>>281
> やっぱり使い切りませんか。
少しは考えようよ。
BIGINTが「1億×1億×1800くらい」というのが何を意味するかというと、
「1日1億件登録するのを1800億日続けるといっぱいになる」
↓
「1日1億件登録するのを続けても、約5億年はいっぱいにならない」

283 ：

そう説明しても、でも使い切ったらどうするんだ、ちゃんと対応しとけ
というクライアントは実在する

284 ：

>>283
「切腹します」でいいんじゃね？

285 ：

これが有名な5億年問題か

286 ：

簡単なメールの配信システムを検討してるのですが、
一般的にメールアドレスに関しては、暗号化してデータベースに入れてるもんなんでしょうか？
今のところ考えてるのは、メールアドレスのみ生データ、それ以外は暗号化もしくは記号化しようかと
送信には、設計者以外が送信するため、簡単に扱える専用クライアントソフト（送信速度などを細かく設定できる）を
使いたいなと思ってるのですが、そうなると、そのクライアントソフトが
データベースに取りに行ったときに復号する機能はありません
素直に、送信側のプログラムも自分で作ってしまった方がよいもんでしょうか・・・
データベースにハッキングできるくらいの人なら、メールアドレスそのものは、ヘッダなどいくらでも
調べてアドレスとれるとは思うのですが、やっぱりリスト化されたものというのが漏れる危険性を
最優先に考慮すべきなのでしょうか
ぐだぐだ書いたのですが、要はメールアドレスは生データにしてもよいもんか、御法度なのかということです・・・

287 ：

>>286
セキュリティ要件はお前が決めるもの
やりたいようにやればとしか言えん

288 ：

>>287
それはそうなのですが、本業ではないのでやっぱりプロの方々の意見を拝聴したくて
もちろん現場なら、クライアントの意向が全てかとは思いますが・・・

289 ：

>>288
セキュリティ要件はスレ違いなんで、他で論議して下さい

290 ：

>>286
どんな些細な情報であれ「流出したら客が怒る情報」は暗号化するのが普通です
万が一情報が流出した際に「無意味だと思ったので暗号化はしてませんでした」だと印象は非常に悪くなります
その暗号化の方法としてDBの行レベル・表レベルの暗号化機構を使うのか
あるいはアプリケーションレベルで暗号化してデータを出し入れするのか
それはデータベースの設計とは関係がない事項なのでこれ以上の回答は控えます

291 ：

世の中のデータ流出の場合、データベースからデータを抽出して流出ってあるものなの。
データベースのデータファイルをコピーされて解析されてということなのかな。

292 ：

SQLインジェクションとか。

293 ：

SQLインジェクションを防ぐ場合に、データの暗号化って役に立つのかな。
SQL文を偽装された場合、結果セットを復号化して結局渡してしまうんじゃないのかな。

294 ：

>>293
>結果セットを復号化
それを気にしてる段階で、SQLインジェクションが防げてないわけだが
もしくはインジェクションよりもっと悪いDBにログインされている状態か

295 ：

>>294
お前、SQLインジェクションが何だかわかってないだろ

296 ：

>>293
例えばPSNの大規模流出事件でクレカ情報が漏れなかったのは、
クレカ情報はDBには暗号化されて保存されていたため。
クレカ情報にアクセスする必要があるプログラムは非常に少ない。
だからクレカ情報を復元できるプログラムを限定しておけば、
それ以外のプログラムがSQLインジェクションで操り人形になってしまったとしても
そのプログラムからはクレカ情報が復元できないから流出もしないということ

297 ：

そんなバナナｗ

298 ：

復号化のロジックがRDBMSとは別のところに実装されていれば攻撃する方も
普通に面倒だと思うけれども。

299 ：

データの暗号化ってのは、DBの機能としての話なのか
それともアプリで暗号化して格納するって話なのか

300 ：

今テーブルのチューニングで悩んでいます。
DBはSymfowareV10です。
テーブルの列数が70ぐらいあるんですけど、その内の半分ぐらいが検索対象項目になっています。
想定する検索条件のパターン用の複合インデックスを全部つくったら容量が大変なことになってしまいます。
そもそもそんなに大きいインデックスに意味があるのでしょうか。
こういう場合の解法ってどういったものがあるでしょうか。
複合インデックスに対してWhere句の内容が歯抜けのような状態でも効果的にインデックスを効かせる方法があったりするとうれしいです。
もしかして文字型で本来歯抜けになる検索条件に「c1 >''」みたいな条件を入れたらごまかせたりしないですかね。
乱文での質問で本当にすみません。
よろしくお願いします。

301 ：

>>300
要件やレコード数の規模感なんかがわからないと回答不能。

302 ：

テーブルを分割するとか

303 ：

>>301
レコード数は1000万件位です。
1レコード400バイト位です。
数値型は範囲検索、それ以外は完全一致で検索します。　
>>302
やっぱりテーブルを分割するしかないですかね。
検索用の分割テーブルを用意して結合とか色々試行錯誤してます。

304 ：

1000万？
今時大したこと無いな…

305 ：

インデックスで考慮すべきはまずカーディナリ
複合インデックスは一般的に頭がヒットしないと効果薄い
まあ、良く検索される項目三つ四つぐらいの組み合わせで複数インデックス作っとけば
オプティマイザが賢ければ最適なインデックス使ってくれるかもしれん
実際にはそのDBMSの実行計画を決定する方法やタイミングにもよるし
素直に専門のとこにコンサル頼め

306 ：

でも、ほら、あなた、Symfowareですし…

307 ：

分割すると改善しそうとか、どういうテーブル・検索条件なのかよくわからんな。

308 ：

>>307
馬鹿には無理

309 ：

Symfowareって触った事無いけど、現状の行あたり400バイト
構成の列数とかにもよると思う。
列数が多いなら、数値型の範囲指定検索項目と、完全一致項目を分けて
データ作るとか。（二つのテーブルに外部キー貼るとか）
時間の猶予があるなら、何パターンがテーブル作って、
効率のいいデータ取得方法見つければいいんでない？

310 ：

>>308
あきらめんなよ、頑張れ。

311 ：

現在MySQLを利用したWebサービスを製作中で、
複数の姉妹サイトを運営しようと考えています。
1つのサイトに25程度のテーブルがあり、
10サイト程度を予定しているので全体で250のテーブルになります。
そこで質問なんですが、
1つのデータベースにサイトごとに接頭辞を変えたテーブルを複数作ったほうがいいのか
そもそもサイトごとにデータベースを分けたほうがいいのか悩んでいます。

パフォーマンスやメンテナンスを鑑みた場合、どちらのほうが有利でしょうか？

312 ：

共通するものが全くないなら分ける、あるなら一緒に、でいいのでは

313 ：

ユーザー情報なんかは共通するんですが、
それだけは別のデータベースに…。
と考えると、やはり1つで管理したほうが良さそうですね。
調べてわかった範囲では、
同一サーバ内でデータベースを分割してもパフォーマンスは上がらないとのことなので、
1つのデータベースにテーブルを作成する形にすることにしました。
複数のサーバでデータベースを分散する必要がでたら…、その時考えますｗ

314 ：

>>311
>1つのデータベースにサイトごとに接頭辞を変えたテーブルを複数作ったほうがいいのか
これはあまり無いかなぁ。
・ORMを使うにせよ自分でクエリ吐くにせよテーブル名が固定にならないのは普通に開発が
　面倒で既存のツールも使いにくく落とし穴も多い。殆どのテーブルのアクセスに関して
　サイト毎にテーブル名を振り分けるロジックを書く必要がある。
・あるサイトから隣のサイトの情報を見られないようにするのがアプリケーションレイヤー
　の責務になる。サイト毎にDBを分ければ見える情報の範囲はDBMS上で綺麗に分断される。
・運用が面倒。サイトの停止時もサイト毎に分けておけば普通にDROP DATABASEで済む
　ものが、一つのデータベースだとその都度個別のSQLスクリプトを用意する必要がある。
　データベースのリカバリ等についても他サイトを巻き添えにせず個別に行うのが面倒。
一般論として一つのデータベースで複数のサービスを運用するマルチテナントはそうでない
ものに比べて開発は面倒だし運用も気を使う。
マルチテナントにしても新しいサイトを作る度にポコポコと新規テーブルを作るのは筋が
よいやり方とは思わない。これをするぐらいなら普通にデータベースを分けた方が良い。

315 ：

>>314
あまりないですか。
テーブル振り分けや見える範囲なんかは、さくっとできるんですが、
運用が面倒というのは確かにその通りですよね。
規模が大きくなった場合は分けたほうが運用が楽そうなんですが…。
Webサービスが大きく成長してほしい反面、小規模なら1つでもいいかと。
悩ましい…ｗ
しかし考えたらブログ程度の情報量でも数百MBになることを考えたら、
バックアップ、メンテナンス、復旧を一括でってのは現実的じゃないですね…。
うし。助言を参考に、今回は分けてやってみます。
ありがとうございました。

316 ：

管理する人が同じ人なら同じDBで同じテーブル使ってもいいんでないの。
siteidみたいなのを最小限の範囲でつけて。

317 ：

そのサイト間で共通するデータ量がどのくらいか考えないと何とも言えん
あとは使うDBMSでデータベース間のデータのやり取りがどのくらいの手間なのかとか

318 ：

サイトごとに接頭辞ってのがおかしいとは思うぜ
カラムが共通なら全部一緒でいいよな

319 ：

>>318
同一データベースで、
site1_users
site2_users (site1_usersとスキーマは同一）
というようにしようかなってことだと思うよ。
それとも、データベースを分けて
site1.users
site2.users
にすべきか迷っていると。

320 ：

siteの項目も含んだusers一個でいいんじゃね

321 ：

>>319
その通りです、説明ベタですいません。（というより知識不足ですがｗ）
確かにデータ量わからないと、アドバイスしようがないですよね。
私もどれくらいになるのか現時点で全然わからないんですｗ
将来もしも大規模になった際に運用が成り立たなくなるようだと困るなと思って質問しました。

322 ：

初心者ほど何故か「データ量が〜」「パフォーマンスが〜」とかいってヘンテコなスキーマを
持ち出す法則。教科書通りの基本的な設計から始めようよ。
接頭辞つけて同一スキーマのテーブルを必要に応じて増やすのは特殊な事情が無い限り大抵は
バッドノウハウ。で、こんな事を気にしているレベルならデータ量とかパフォーマンス云々は
とりあえず忘れた方が良いと思う。ホントに。
まずドメインモデルを素直にスキーマに落として、そこから必要に応じて手を入れれば十分。
無理してトリッキーなスキーマを使わなくともサイト毎にクラスタ化するとかシャーディング
するとか、いくらでも解決策はあるのだから。
それよか運用形態とかシステムの構成の方がずっと重要。
姉妹サイト間の運用の独立性はどの程度か、どのような頻度でサイトを新設したり削除したり
するのか、ウェブアプリの一つのインスタンスで全ての姉妹サイトをホストするのか、それとも
サイト毎にインスタンスをあげるのか、姉妹サイト間での共有する情報は何か、個々の姉妹
サイトでカスタマイズや機能拡張はあるのか、開発言語やフレームワークは、など。

323 ：

DB１つにしたら、DB止めてメンテするとき全サイト停止するんだぜ
それで良いならDBは１つでいいんじゃね
あと>>319の後半って、それDB分けてるのか？
普通のDBMSなら、それ同一DBでスキーマ(DBユーザ)変えてるだけじゃねえの？

324 ：

DBとインスタンスはイコールじゃないぜ。
いわゆるスキーマを「データベース」と呼ぶDBMSもある。Symphowareがどうか

325 ：

知らんが。

326 ：

DBとインスタンスは比較できるのか？

327 ：

上で質問したものですが、無事サイトごとに個別のデータベースを作り、
シングルサインオン用のデータベースからユーザー情報を取得。
という形にしました。
設計していく中でこの方法で良かったと思うことちらほら。
メンテもこの方が楽そうです。
ありがとうございました。

328 ：

真偽と未定義等の3値論理のカラムを定義するときって
最小サイズの数値型使うのが普通ですか？
BooleanがあるDBだとNULL許可で扱うのが一番自然なんですが
数値型の場合、各値の割り当ても若干悩みます

329 ：

定番だけれどもNULL撲滅委員会
http://www.geocities.jp/mickindex/database/db_getout_null.html
個人的には
・ORM使用する場合は結局DB中のNULLはホスト言語のnullにマッピングされるし、
　NULLの問題が絡むような凝った条件式は書かなかったり書けなかったりするので
　結局ホスト言語で未定義値をどう扱うかで決めてしまった方が良い気がする。
・ただbooleanに限ってはnullableだとアプリケーションのロジックが解りにくく
　なりがちでバグのもとなので意識して避けるようにしている。
　例えばdeleted != trueとdeleted == falseの結果が異なるかもしれない、って
　コードの上だと気がつきにくいと思う。

330 ：

>>328
・3値論理
・値を3つしかとらないカラム
これらは全く違う意味だけどそれはOK？
3値論理なら当然nullを使う。値を3つしかとらないだけならnullは厳禁
つまり自動的に決まる話

331 ：

>>328
私的には文字型。
画面作ってる奴が、時々すごいSQL作ってくるから

332 ：

>>330がこのスレ的に最も適切なレスだと思う
ほとんどのケースでは後者だろうから、もし>>331に従って文字列型にするなら、
その値は、たとえば 'TRUE', 'FALSE', 'NONE' もしくは 'T', 'F', 'N' として
カラム定義には値制約を書いておくのがいいんじゃまいかと

333 ：

未定義をnullで表現するのか、別の表現法法にするのかって自動的に決まる話なの？
T,F,Nにするのか、T,F,nullにするのか、どっちも変わらない気がするけど。

334 ：

>>333
それSQLの実行結果が変わるよ

335 ：

>>334
例えば？

336 ：

INNER JOINとかじゃないの？
既に入ってる値をわざわざnull値に設定することがありうるなら
null以外の未定義値を使うかなあ

337 ：

>>336
ちょっと良くわからないんだけど、未定義なものに対してINNER JOINするってどういうとき？

338 ：

NULL撲滅委員会じゃないなら、「未設定」「true」「false」を表現したいのなら、null可にするのが自然だと思うんだけど。

339 ：

>>333
SELECTのWHERE節で、T/F/N にすれば Column = 'N' みたいに比較演算子が使える
でもT/F/null だと Column IS NULL と書かなければならない
同様に、３種類の値別に異なる結果が必要な場合、T/F/N にすれば単純なCASE式で書けるけど、
T/F/null だと NULL か否かを判定した後でT/Fを判定するという二度手間が必要になる
他にもNULLの弊害は多々あるけどきりがない
書籍「プログラマのためのSQL」などに詳しい解説があるから、一読を勧める

340 ：

>>339
それってnullはいつでも駄目って話？
俺が聞きたいのは、nullを使うかどうかがどういうロジックで自動的に決まるかなんだけど。

341 ：

>>330と>>333をまとめると、
* 3値理論なら当然nullを使う (A)
* 値を3つしかとらないだけならnullは厳禁(B)
* (A)か(B)かは自動的に決まる
* ほとんどの場合(B)だから'T', 'F', 'N'などを使うのが良い
で、>>328にもどって
> 真偽と未定義等の3値論理のカラムを定義するとき
に、自動的に(A)と決まるのはどういうときなんだろうかという疑問。
> 真偽と未定義等の3値論理のカラムを定義するとき
なら、'T', 'F', 'N'だろうとtrue/false/nullだろうとそれほど変わらないから、
自動的には決まらないんじゃ無いかと思ってる（つまり、検索要件等から
考慮しなければならない）。
NULL撲滅委員会なら、自動的にnullは駄目だから楽なんだけど。

342 ：

ごめん。難しくなりすぎたから>>341は取り消す。
知りたいのはこれだけです。
> 真偽と未定義等の3値論理のカラムを定義するとき
という要求があったときに、
> 3値理論なら当然nullを使う
というのが自動的に決まる場合があるとしたら、それはどんなときか？
です。

343 ：

3値論理のとき、だろ

344 ：

未定義であること自体が意味を持つならnullにはしない。そんだけじゃないの。

345 ：

>>344
うーん、わかったようなわからないような…。
でも、レスありがとうございました。

346 ：

これはちょっと重症な感じだからきちんと説明しよう。
SQLのブール式は「True/False/Unknown」の三種類の値を返すんだ。
これはカラムとか関係なく、SQLの仕様としてブール式は三種類の値を返すことになっている。
ただしブール式がUnknownを返すケースは限られている。
それは「nullと何かを比較したとき」限定なんだ。
よってnullを禁止すればブール式は常に「True/False」のいずれかを返すようになる。
つまり
　・「True/False/Unknown」の3値論理を使いたければnullを使う
　・「True/False」の2値論理を使いたければnullは禁止する
という実に簡単な問題になるんだ。
もっと簡単な言葉で言うと
　・未定義値に関して行われるあらゆる比較の結果が全て「Unknown」になり、それ以上の情報を求めないのならnullを使う
　・「未定義値を含むカラムを検索する」のように、未定義値に対するブール式の結果がUnknownでは困り、
　　True/Falseの結果が欲しい場合はnullは禁止する
ということになる。
ここまでの説明を一文で示すと>>344ということになる
「この値は未定義値か？」という比較の結果すらnullの場合はUnknownを返すため区別できないからね。

347 ：

is nullの立場は？

348 ：

NULLとの比較結果が不定になるだけで、NULLと不定(UNKNOWN)は違うぞ
is nullはNULLかどうかを検査する。結果が不定にはならないだけ
ただし、３値論理を扱いたければNULLとの比較しか不定が起こりえないから
必然的にNULLを使う必要がある

349 ：

自動的にとか必然とかさっぱりわけわからんわ

350 ：

>>347
使っても使わなくてもどっちでもいい。
3値論理か2値論理かどちらを選ぶのかが重要なのであって、
IS NULLは選んだ「後」の問題だから。

351 ：

例えば
select * from TAB_1 where COL_A = 'T' or COL_A <> 'T';
が必ず全件返すかという問題。
COL_Aがnullを許さなければ必ず全件返す。これが2値論理。
COL_Aがnullを許せば全件返すとは限らない。これが3値論理。

352 ：

もはや>>328とは何の関係も無いな

353 ：

>>328が良く理解せずに3値論理とか言いだしたからだろ

354 ：

そんな難しい話か？

355 ：

>>328への回答としては、彼の考えを汲むとnull 0 1以外にありえないからな

356 ：

>>330が元凶

357 ：

騒がせてすみませんが、回答踏まえたうえで、
今回はNULL許可の0,1の数値型でいこうかと思います。
ありがとうございました。

358 ：

null撲滅派の人も9999年12月31日問題対策はしとけよ

359 ：

デイト先生はnullの振る舞いについて20ページ以上を費やし懇切丁寧に説明しました。
スカラー式、様々な条件式、テーブル式、整合制約・・・
そしてその章の結びとして、最後にポツリと一言言いました。
「nullは避ける」

360 ：

>>357
null許可ってことは3値論理を使いたい積極的な理由がなければおかしいわけだが
なぜ3値論理を使いたいんだ？

361 ：

>>360
真偽と未定義があるからだろ。
馬鹿なの？

362 ：

>>361
対象の状態として「真・偽・未定義」という三つの状態が存在するのと
その状態に対する比較演算の結果がSQLにおける値「True/False/Unknown」になるのは全く異なる意味だとわかっているのかね
通常は比較演算の結果は「True/False」で事足りる。
比較演算の結果としてUnknownが返ってきて欲しいという積極的な意思表示がnullの導入なわけだが、
その理由は如何に？

363 ：

例えば年齢を　{0〜9　10〜19　20〜99　100〜　未定義}
の5つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？
次に年齢を　{0〜19　20〜　未定義}
の3つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？
カラムの取り得る値の数とnull導入の可否は全く関係ないとわかるだろ
「真・偽・未定義」の3つだからnull導入しますってのは全く筋の通らない話だ

364 ：

>>361
三値論理を積極的に使いたいケースや不可欠なレースが比較的レアだからでは?
個人的にも理由には興味がある。
実際のところnullなんて三値論理云々とは無関係に単に空値代わりに使われているケースが
多いわけで。
空値にnullを使って三値論理が入り込んでも空値を表す特別な値を使った場合と同じ結果を
常に返すのであれば実用上は確かに問題は無いのだけれども、それは積極的に三値論理を
使ったこととはちょっと言えないよね。

365 ：

0,1,-1,2,9とかから決めるのめんどいじゃん

366 ：

>>362-363
何言ってるの？
比較演算なんかどうでもいいし。

367 ：

>>364
> 三値論理を積極的に使いたい
なんて誰も言ってないし。
アホ丸出し。

368 ：

未定義と0, 1を使いたいってことだから、null可のカラムでいいでしょ。

369 ：

boolとnullってことだから別にいいかぐらいの問題でOK

370 ：

>>363
> 例えば年齢を　{0〜9　10〜19　20〜99　100〜　未定義}
> の5つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？
>
> 次に年齢を　{0〜19　20〜　未定義}
> の3つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？
どうして「自明か否か」という問題にしたがるんですか？
nullでもいいし、nullじゃない方がいい場合だってあるでしょ。
> カラムの取り得る値の数とnull導入の可否は全く関係ないとわかるだろ
何も説明せずに「全く関係ないとわかるだろ」と言われてもわかりません。

371 ：

「3値論理」について語りたくて仕方がないんだよ。

372 ：

夏休みか

373 ：

>>367
>>328

374 ：

コッドが悪い

375 ：

>>373
「真偽と未定義等の3値論理のカラムを定義するとき」
が「積極的に使いたい」ってことになるのか？

376 ：

もともと>>328は3値論理なんかどうでも良かったと思うが。

377 ：

>>364
>空値にnullを使って三値論理が入り込んでも空値を表す特別な値を使った場合と同じ結果を
>常に返すのであれば実用上は確かに問題は無いのだけれども、
いや、同じ結果にはならない。その反例の一つが>>351になる。
だから、(２値論理を前提とする)常識とは異なる結果を返す３値論理は避けましょう、という話。
>>367
>> 三値論理を積極的に使いたい
>
>なんて誰も言ってないし。
言ってないから(３値論理は避けて)２値論理を使いましょう、という原則の提案だよ。
そして、その「２値論理を使う」ことを具体的にしたのが「null可は禁止」になる。

378 ：

>>377
> 言ってないから(３値論理は避けて)２値論理を使いましょう、という原則の提案だよ。
> そして、その「２値論理を使う」ことを具体的にしたのが「null可は禁止」になる。
アホすぎて話にならんわ。
真偽と「未定義」を使いたいんだぞ？

379 ：

「比較結果がUNKNOWNになる」というところから抜け出せない馬鹿がいるな。

380 ：

まあ最初にいろいろ考えておかないとnull混ざってると面倒なことが起きる場合があるからなｗ

381 ：

好きなものを使えばいいじゃん

382 ：

>>378と>>328はおそらく未定義と不定の区別がついてない
未定義を扱うだけなら、必ずしもNULLである必要はない
もちろんNULLでもいいが、３値理論まともに扱えない人がNULL使うとろくなことにならない
だからNULLの必要がなければNULL不許可にしとくほうがいいよ、ってのが撲滅委員会含め大方の意見
まあ俺は３値論理の必要がなくても未定義には積極的にNULL使う派だが
他人に進められるかといえば微妙

383 ：

あ、念のために言っとくが
NULLとは値がないことを示すのであって、厳密には未定義とも違うからな
NULL使うな派の考え方の原則は、未定義には未定義を表す値を割り付けろってこと

384 ：

日時はnull使ってほしい

385 ：

白熱してるなぁ。

386 ：

自己レスで書き直し
X: だから、(２値論理を前提とする)常識とは異なる結果を返す３値論理は避けましょう、という話。
O: だから、(２値論理を前提とした)常識とは異なる結果を返す３値論理の利用は
　実用上の「問題が起きやすい」ので避けましょう、という話。

３値論理体系に欠陥があるわけでもなく、それを利用したから必ず「問題が起きる」わけでもない。
DB設計者やSQLプログラマ達が完璧に３値論理体系を理解して正しくコード化できるのなら、
３値論理を止めよう！、つまりNULL化を禁止しよう！！なんて主張したくはない。
でも現実には限られた時間での開発だから、NULL化は予期しないバグを作り込みがち。
だから、３値論理は避けたほうがいいよ、という提案(推奨)なんだよね、個人的には.....。
自分は３置論理体系を完璧に理解していると自信のある人は、好きにすればいいんじゃまいかと思う。

387 ：

言語仕様にあるものは何を使っても良いだろう。
それでバグるのは使用者の責任。

388 ：

nullの悪いところは、3値論理で評価されることを忘れてうっかりミスする可能性があること（外部結合もそうだけど）。
nullの良いところは、導入するのにドメインを変えたり（bool型→文字列型など）、特別な値を考えたり（-1,999など）
しなくていいこと。
後はその時々の状況次第ですね。

389 ：

>>387
使用者本人が責任を取れるなら、それでもいいだろね
たとえば個人の趣味プロジェクト向けDB設計とか、メンテの必要が無い一時的DBならば

390 ：

バカは数値に-1を定義してSUMする

391 ：

null撲滅委員会だかなんだか知らないけど、うぜーよ

392 ：

>>390
nullに四則演算するバカもいるんだからどっちでもダメじゃね

393 ：

>>386
RDBMSにおいてNULLを避けることができないのはわかるよね。
> NULL化は予期しないバグを作り込みがち。
> だから、３値論理は避けたほうがいい
こんなこと言うのは、かなりの重症。
もしも、テーブル設計の段階の話しかしていないよというのなら、それもまたかなりの重症。
それとも単にN値論理という言葉を最近知っただけ？

394 ：

>>393
> RDBMSにおいてNULLを避けることができないのはわかるよね。
えっ？

395 ：

議論が長引いてるのは特定の一人が極めて不誠実な態度でスレに書き込んでるからだよ
元凶の人物→　>>361 >>378 >>366-367
他人のレスを片っ端から否定。
でも否定する割に一切その根拠を書かない。
しかもどのレスにも「馬鹿」「アホ」「何言ってる」とか他人を罵倒する書き込み。
IDが出ないのをいいことに他人を煽って楽しんでるわけだ。

396 ：

スルーしなよ...

397 ：

議論が長引いているのはどちらも一長一短ありケースバイケースだからでしょ。
少なくとも>330のいうような「自動的に決まる」話ではない。

398 ：

議論が長引いてるのは、何かを説明しようとしてる奴が的を外している上に説明がど下手だから。

399 ：

RDBベストプラクティス とか SQL Good Parts & Bad Parts みたいなタイトルの
書籍がO'Rellyから出版されれば、NULLの利用は避けるべきという話も常識になるんだろ

400 ：

そういやSQLアンチパターンにNULLの話出てたっけ？

401 ：

"SQLアンチパターン NULL" でGoogle様に相談すれば答えてくれるよ

402 ：

NULL撲滅委員会の布教はやめてくれ

403 ：

"達人に学ぶ SQL徹底指南書 NULL" でも答えてくれるね

404 ：

自分の言葉で語れない馬鹿

405 ：

>>394
はっ？

406 ：

結合条件や検索条件、集計項目にならないカラムについては、NULL可でも不可でもどっちでも良い。
俺個人はINSERT文書くのがだるいので、積極的にNULL可にする。

407 ：

NULL不可ならデフォルト値設定しとけばINSERTいらん

408 ：

>>407
あー、ここ数年default設定なんかしたことなかったからすっかり忘れてたわ

409 ：

>>393
外部結合したらNULLが登場するという話？

410 ：

>>393は、プログラマにとんでもないSQL書かれたことのない幸せな人なんだなぁあ
NULLあると言ってるのにDBバグってるとかわけわからん事言うやつは現実にいるんだぜ

411 ：

そんな低レベルな奴にあわせて設計するのか?

412 ：

きっとプロの設計者じゃないんだろう

413 ：

数人規模の開発なら多少難しい設計でもなんとかなるかもしれんが
数十人規模だとサルでも書けるような設計にしないとだめだろう

414 ：

そうするための第一ステップは正規化しないことだね

415 ：

>>413
サルには生クエリは書かせないので問題無い

416 ：

>>415
チームリーダがザルなケースもある
機能追加、仕様変更入ってくるとチェックしきれないだろ？

417 ：

>>402,403
なんのことか意味不明だったけど、書店で立ち読みして判明
本の節の一つがそのまま「NULL撲滅委員会」だったw

418 ：

nullスレでも立ててそっちでやってくれ

419 ：

DB設計というか、セキュリティについての考え方を相談させてください。
たとえば、顧客の銀行口座情報をwebアプリを通じて入力してもらい、DBに（とりあえず）保存するという
状況を考えたいんですが。
こういった機密情報をそのままwebにつながってるDBに入れっぱなしって良いんでしょうか？
理屈では定期的に該当情報をローカルにコピーして消去してくというようなことをした方が良い気がしますが
現実ではamazonやその他のサービスはそんなことやってるんでしょうか
最近2chもですが機密情報が漏れる話が多くて、自分はそういうシステムを作った経験ないんですが
もし担当するとしたらどのように設計すべきか疑問に思いました
ご意見お願いします

420 ：

>>419
> こういった機密情報をそのままwebにつながってるDBに入れっぱなしって良いんでしょうか？
普通 DB サーバーを Web (インターネットのことだよな？) に直結なんてしない。
個人サイト最低...
インターネット 〜 外部ファイヤーウォール 〜 Web サーバー 〜 内部ファイヤーウォール 〜 DB サーバー
ぐらいはやる。

421 ：

× > 個人サイト最低...
○ > 個人サイトでも最低...

422 ：

>>420
ありがとうございます
>>420さんの提案されてる方法は、アプリケーションサーバとDBサーバが分離してることが前提ですよね？
（理解が違ってたらすみません）
同居してる場合はどういう方法がいいでしょうか
DB設計そのものとずれてしまってすみません

423 ：

>>422
適切に暗号化してあればどこに保存してあっても問題ない
逆に言えば、どこに保存しようと暗号化や認証システムに穴があれば復号後の情報が抜かれるので意味がない

424 ：

>>422
情報漏洩心配するのにサーバー一台とか、ありえない

425 ：

>>423
それは玄関のダブルロックが意味ないと言ってるアホと同じ
盗もうとする奴で時間や手間がかかるというだけで諦める奴は珍しくない

426 ：

今回の相談者の場合、とりあえずWebにつながったDBに保存するんだから、
侵入されたらヤバいのはどうしようもないんだけどね。
古いのを退避させたら1万件流出するか、10万件流出するか、の違いで。
俺なら運用コストとか考えて、原則として暗号化して保存。
復号化するキーはアプリ側に保持して、定期的に更新、とかかな。
前に担当してた顧客は平文で保持してたけどね！

427 ：

>>425
その意見そのものには同意するが、>>420には全く同意できない
ファイアウォールをいくつ設置しようがSQLインジェクションで「正当なパケット」としてDBのデータが流れていったらファイアウォールなんて何の意味もないわけで
ファイアウォールはサーバー本体を対象とした直接的なアタックを防ぐには役に立つが、
不正なSQLの発行などアプリケーション層でのトラブルについては何の意味もない
そしてDB使うプログラムでは後者の方が圧倒的に脅威

428 ：

>>427
アプリ層のトラブルの方が怖いのは同意するが、だからと言ってサーバに対する攻撃を放置できるのか？
それこそダブルロックに意味がないという意見だが
まあ、これ以上はセキュリティ関連のスレ立てるなりしてそこでやってくれ

429 ：

ファイアーウォールってSQLインジェクションとかに対応したって意味じゃね？
特に機密情報に関数るSQLを限定する方法もあるし。

430 ：

自分も興味ある話だなぁ
>>420さん、質問者はシステム構成をどうしたらいいかじゃなくて
その内側、データベースに入れる機密情報の取り扱い方を知りたいと思うんですよね

431 ：

いつも思うんだがライトオンリーのアカウントって作れないのかな？
これだと仮にSQLインジェクション受けてもリード出来ないから何も
表示されないだろうし

432 ：

書き込み専用のアカウントを作ったとしても、データを書き換えるにはそのデータを読み込む必要があるわけだが
仮に追加専用のアカウントだとしても、そうすると情報を表示するには別アカウントが必要
そのアカウントからの情報漏えいが防げても、システム全体として情報漏えいの可能性は下がらん
アプリ作成に要らん手間が増えてバグを作りこむ可能性が上がるだけの気がする

433 ：

でもインジェクションって殆ど書き込みの時にSQLコマンド
渡されるんだよね。システム自体がハックされてれば別だけど
読み込み専用のアカウントは色んな形で監視出来るしデータ
抜かれる可能性はかなり減ると思うんだが。

434 ：

ウェブアプリと社内アプリが同じDBにアクセスする時は
権限を変えるとか普通にやるよね？
行レベルのアクセス制御もRDBMSが面倒見てくれないかな

435 ：

インジェクションで書き込みはあんまりないんじゃない？
select文にインジェクションされて情報漏えいが起きるのがほとんどじゃないかな
いや、インジェクションされるもとのSQLはSELECTでもUPDATEでも良いんだが
インジェクションによる改ざんは防げても漏えいが防げないんじゃ、あんまり意味はないかと

436 ：

>>434
ビューを使って行レベルのアクセス制御してるシステムなら見たことがある。

437 ：

>>435
ああごめん、433で言う書き込みってweb鯖のpostメソッドとか
の意味の書き込みね
そこにSELECT文流し込まれて漏洩する

438 ：

プリペアード・ステートメントとか、SQL文のバリデーションしてれば十分じゃね？

439 ：

>>437
DBから見たらPOSTもGETも関係ない
サーバアプリにとってもどっちかは大差ない
クライアントからサーバアプリにデータ渡せる以上、渡されたデータを適切に扱うしかない

440 ：

適切に扱われないからインジェクションが起こるんでしょ？
サーバーサイドで仮に完璧なプログラムを組んだとしても
必ずどこかに穴があるし
そういう環境でも少しでも情報漏洩起こらないようにするには
どうしたらいいかって話じゃないの？

441 ：

>>440
そんな話は完全にスレ違いだからよそでやってくれ

442 ：2013/09/09

>>436
こうですかね？
コレクションプーリングとかどうするんだろう…
CREATE VIEW public AS SELECT a FROM private WHERE db_user = USER();
CREATE USER user_a;
REVOKE SELECT ON private FROM user_a;
SELECT * FROM public WHERE app_user = 'user_a'