DB設計を語るスレ 6

語れ

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

関連スレ

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

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

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

>>4
> もっと頭良い方法があったら意見を聞きたいです。

まず、DB設計のスレで「セル」とか言うのを止める。

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

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

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

>>5
どう呼ぶか知らないのでセルって言ってるんだけど普通はどう呼ぶのでしょう？ マス目？ｗ

>>8
正規化の概念があるなら
>全部のタグをタブ（など）で連結してひとつのセルに入れる
がありえん事ぐらい解るだろうに

>どう呼ぶか知らないのでセルって言ってるんだけど
>カラムをひとつ用意して(中略)セルに入れる
用意したんならせめてそれに入れようぜ

先人の方法論は、本屋いけばいっぱいあるから
DB設計の初心者向けの本買って読め

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

>>9
ありえんこともわからんから素人なんだなｗ
ということはタグ検索をしたい時は WHERE col1='タグ' OR col2='タグ' ... ってカラムの数だけ並べないといけないのか…な
DBの本は一応持ってるけど説明がまわりくどくてわかりにくいんで明日にでももっと易しいのないか探しに行ってきます。

>>10
正規化のことはまだ理解できてないけどDB使う上では避けて通れない道って程度にはわかってるんで色々作って数こなしながら身体で憶えていこうと思います。
実際に作って実際に使って、このやり方だとどういう時にまずいことになるのかってのは時間かけて自分で経験しないとなかなか憶えられないしね…

場違いな素人の相手してくれて�dです。

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

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

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

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

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

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

DBの設計で質問があります。

クラスの時間割(6時間)を5日分DBに登録するとします。
これを一つのテーブルに登録すると30行になると思います。
後で水曜日の時間割が一時間増えたってなったとき、
挿入しようとしてもDBって末尾にしか追加できないから、
その追加した水曜日の1時間だけ31行目に追加されてしまい、
GUIベースで表示しくてれるツールでDBを見たときに汚くなってしまいます。

なので月〜金までのテーブルを５つ作ったほうが、
後から追加しやすくなるかなと思ったのですが、どっちがいいでしょうか？

最初の方法でもどうせ曜日で検索かければデータとしては取得できるのでいいかなと思ったのですが、
実際は皆どうやってるのかなーと思いまして。

基本的にDBって書き込まれてる場所はどこでもよくて、
表示するときにちゃんと表示できれば問題ないって感じですか？
実際の現場でも？
アドバイスください

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

パフォーマンスに問題ない限りこれでいい

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

ID　数値
曜日　文字列　--月曜日
時限　数値　--1
教科　文字列　--数学
クラス　文字列　--1-A

曜日を文字列にしたが1を月曜7を日曜とかに見立てた数値でもよろしい

select 時限, 教科 from t where クラス='1-A' and 曜日='月曜日' order by 時限
1-Aの月曜日の時間割

どういうデータが欲しいかとか
登録数の規模によって後は適当に正規化すればよろしい

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

>>挿入しようとしてもDBって末尾にしか追加できないから
まずこれに突っ込んでやれよお前ら
基本として行の格納順序には意味がないってのが原則だぞ
行の格納順序は追加した順とはかぎらないし、出力される順序も指定しなければ不定

数十行程度のテーブルなら、実際の格納順序まで考慮する必要性は少ないと思うけど
そのへんはDBMSの実装に大きく依存する

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

制約は無しの方向で

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

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

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

単一のプログラムからしか使わんDBなら、制約なしでもいいけど
複数システムから使うようなDBなら、単一システムのバグで全システムがバグるぞ

>>28
> DBの保全のために制約が必要なわけで

そんなことはわかってて、それでも性能足りないとどうしようもないことがありえるから
アホな突っ込み防止のために念のために「性能に問題ないなら」って書いてあるんだが、
それでもアホな突っ込みする奴はいるんだな…

> 単一のプログラムからしか使わんDBなら、制約なしでもいいけど

意味わからん。
単一のプログラムからしか使わないなら不正なデータ格納されていいのか？

データベース覚えたて厨房のアホレスにしか見えないぞ。(w

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

８時頃はエアコンなしでもそんなに暑くなかったけど？

というか、>>29 がいらいらした文章に見えるなら、
君こそエアコンの冷風頭にあててた方がいいと思うぞ。(w

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

悔しいねぇ。(w

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

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

>>35
どうみても >>24 は、制約の意味を理解していると思うが。
伝わっていないと言う理由でもあるのか？

> 性能＞保全性なのな

別に DB でしか保全性が保てないわけじゃないだろ、馬鹿じゃねーの？

>>36
すくなくとも>>24が、制約の意味がDBの保全にあると思ってるようには見えん
それが解ってるなら、アプリでのチェックで代替出来るようなもんじゃないと解るからな

>DB でしか保全性が保てないわけじゃないだろ
おまえ、DBの保全って意味理解してるか？
たとえばDBからみた不正な操作に対してDB側でどう防御できるかって話だぞ

>>37
>たとえばDBからみた不正な操作に対してDB側でどう防御できるかって話だぞ

誰もそんな話してないし。

今回の件は、DBに入れるデータのチェックをアプリでやるかDBMSでやるか、は
たまたその両方でやるかと言う単純な話。

勝手に違う言葉出してきて、自滅してるアホがいるみたいだが。(w

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

>>39
>Perlでチェックしたものは十分信頼にあたるはずなのでそのまま突っ込んでも問題ない

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

普通は単一なのでは

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

何で複数にこだわるんだろう…

単一の AP でも、バグって DB 壊すこともあるし、
複数でもきちんとテストされててうまく動いているシステムももちろんある。

そもそも単一のAPでも、複数のモジュールで構成されてて、複数人で開発していることもあるんだし。

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

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

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

>>45
>可能性の問題だな

まあ、そういうこと。
単一かどうかの問題じゃない。

プログラムのバグも怖いよ…

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

まだ複数とか言ってるのか…

単一でも極力やるべきだと思うが。

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

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

ネットショップでの注文に対し、
○○をした日時、××をした日時など操作した日時を記録したいのですが、
どの方法がいいでしょうか？

１．注文テーブルに操作の数だけカラムを追加する
２．別テーブルを作り、操作の数だけカラムを作る（注文テーブルと１対１）
３．注文番号、日時、操作内容のカラムを持つテーブルを作る（注文テーブルと1対多）

１のメリット・デメリット
○構造がシンプル
×カラムが非常に多くなる
２のメリット・デメリット
○注文テーブルのカラムは増えない
×構造とSQLがわずかに複雑になる
３のメリット・デメリット
○操作を複数回行った場合も各回の日時を記録しておける
○操作の数が増えた場合もカラムを増やさなくてすむ
○注文テーブルのカラムは増えない
×構造が複雑
×SQLが複雑、遅くなる

あと、２を採用する場合、注文テーブルにインサートするとトリガーで時刻テーブルにも
インサートし、デリートも制約で行うというのはどうでしょうか？

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

３の場合、最終○○時刻を出すには
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万行くらいあってもパフォーマンスは大丈夫ですかね？

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

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

MySQL InnoDBで実験してみたところ、orders30万行、logs150万行、サブクエリ30個でも
ちゃんとパフォーマンスが出たので、大丈夫そうでした。

説明不足だったかもしれませんが、
>最終操作時刻のみを別テーブルで管理
これが２ですね。

>種別、日付、数値ぐらいしかないレコードサイズ
これはlogsのことですね。ordersが10万行の場合、logsはその数倍になる見込みです。

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

ビジネスロジック？

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

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

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

>> ビジネスロジックをDBの制約で実装するなんて論外。

バカの上塗り。(w

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

一つのテーブルに履歴番号を持たせて、最新のデータと履歴を同一テーブルに保持するやり方って古いように思うのですがどうでしょうか？

顧客テーブルに、
顧客番号　履歴番号　名前
0000001　　01　　　山田太郎
0000001　　02　　　山田太郎
…
みたいな持ち方をして、履歴番号が一番大きいレコードが最新のデータとなります。

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

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

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

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

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

いや正規化だろ

>>68
正規化を考えて普通にDB設計すれば、顧客(そのもの)と顧客履歴は別々のエンティティになるよね
・顧客(顧客ID, 取引開始日時)
　　　-- 顧客IDがプライマリキー
・顧客履歴(顧客ID, 履歴番号, 履歴変更日時, 名前, 住所, メールアドレス, ...etc)
　　　-- 顧客IDと履歴番号との対(つい)でプライマリキー
　　　-- 顧客IDは顧客テーブルへの参照キー

人は引っ越しがあれば住所や電話番号は変わるし、氏名も結婚で変わることがある
でも、もしも顧客そのものに一意性(identity)が無ければ(無くしたDB設計にしてしまえば)、
後々の監査の時に、ある対象顧客の取引記録を追跡できなくなる
(あるいは社会保険庁での事例の様に、血税を使って人海戦術で追跡することになる)

ここで、もし「正規化」を崩すのであれば以下のようになるけど、これをOKとするのかな？って話だ
・顧客(顧客ID, 取引開始日時, 履歴番号, 更新日時, 名前, 住所, メールアドレス, ...etc)

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

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

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

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

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

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

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

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

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

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

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

「履歴変更日時」にするだけじゃん、バカなの？

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

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

>>81
> 「履歴変更日時」にするだけじゃん、バカなの？

お前のほうが馬鹿だったわけだがｗ

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

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

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

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

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

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

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

>>90
データ量の件は場合によるけど、最近の環境だとよほどでない限り問題になることは
少ないと思う。

検索時の指摘はそうだけど、ビュー作っとくとかでなんとでもなるでしょ。

カテゴリ登録みたいに、1つのカラムに複数登録するとき、
たとえば1の記事は

1,2
1,3
1,5

みたいに２，３，５のカテゴリIDを登録するためにレコードを三つ追加してるんですが、
あとからこれを修正するときは、一度deleteで1の記事のレコードを全部消して、
全部再登録した方が早い気がします

それともそれぞれの組み合わせが存在すれば更新 or 削除って形にしたほうがいいでしょうか？

後者の方がsql文を実行する回数が増える気がするのですが。。

適切なインデックスがあればどっちでも大差ないだろう
まあDELETEする行が大量になるようならUPDATEのほうがいいだろうけど

あと最近のSQL標準ではMERGE文（いわゆるUPSERT操作を行う文）
なんてものもある

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

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

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

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

まあ、階層的な選択項目を管理したいんだろうなとエスパーしてみる。
一例はこんな感じ…
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
以下同文…

すげー w

ひどい自演を見た

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

で、その続きでもっと聞きたいことあるんだけどあとでかく

KVSですねわかります

最上位のParentはNULLがいいな

続き

ユーザーに入力してもらう項目は、
１…性別の選択
２…kimootaなどの種類
３…好きな色（０〜複数選択、性別が男女どちらでも表示して入力もらう）
４…趣味（０〜複数選択、性別が男のときだけ表示して入力してもらう）
５…好きな有名人（０〜複数選択、kimootaなどの種類がbisyoujyoのときだけ表示して入力してもらう）
６…収入（数値を入力してもらう、性別が男のときだけ表示して入力してもらう）

として、

最終的には、ユーザーに入力してもらったものは保存し、
過去の入力したものを検索したりとか編集したりとかしたい。

のだけど、

その入力画面の項目用のテーブルと、
ユーザーに入力してもらった内容を保存するテーブルと、
どんな設計にすればいいのでしょう。

あと、将来、好きな色を追加したりとかできるようにしておきたい。

お願いします

>>103
KVS検索しました　勉強します

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

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

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

おまいあたまいいな

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

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

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

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

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


アルバム名　　　　曲名
hoge　　　　　　　　AAA
hoge　　　　　　　　BBB
hoge　　　　　　　　CCC
hoge　　　　　　　　DDD
hoge　　　　　　　　EEE
hoge　　　　　　　　FFF
fuga　　　　　　　　GGG
fuga　　　　　　　　HHH
fuga　　　　　　　　ＩＩＩ

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

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

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

>>116
「関係データベースでは表の中の行は順序を持たない」

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

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

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

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

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

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

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

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

条件色々だから、あまり条件変わらないならアプリ側で制御した方がいいよ。

特に、全て単純な選択ならいいけど、複数選択とか、さらにはいきなり項目に
よっては数値入力とかは結構大変。

条件とか入力項目を動的に変えたいとか言われたら、簡単なインタープリター
を作るぐらいのことが必要だと思う。

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

正直インタープリターと聞いてもわからん…けどそれは後で調べるとして
とにかくありがとう

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

ユーザーIDを下記のような組み合わせで管理していきたいと思っています。
組…101等
番号…001等（前述の組の中での連番）
ユーザーID…101001等（組と番号の組み合わせ）

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

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

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

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

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

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

view

>>129-134
単純に登録後の編集や他テーブルとのユーザー関連付けの利用を考えていました。

複合キーとした場合、１つのテーブルで全ユーザーを…とした場合、登録時に採番の手段が思いつきませんでした。
また、実テーブルにこそ、ユーザーIDを置いておいた方が個々のユーザー情報にアクセスするのに便利かと
考えていましたが、そうでもないようなご意見もあり、viewをユーザー情報のマスター（一元管理元）と
するのもアリなのでしょうか。

組毎のテーブル…初回登録時に利用。存在する組分テーブルを作成（番号カラムをAUTO_INCREMENTで採番）
マスターテーブル（view）…登録後の編集及び他テーブルと連携（ユーザーIDカラムをconcatで作成）

として、登録後は、マスターテーブルを軸にユーザー情報にアクセスしていく考えはそれほど外れてはいないでしょうか？

プライマリキーについて質問です。
左二桁を年にして残りを年ごとの連番で固定長にしてるんだけど、
可変長の連番より優れた点があるのでしょうか？

うちの会社はみんなそうなんだけど、
聞くと桁数が増えすぎるからって言うんです。
残りを仮に五桁として一年で8000件だったら、
逆に2000ぶんの番号が無駄な気がします。

見た目の問題ですかね？

DBによる

>>135
パーティションテーブルでもなく、同じ構造のテーブルを沢山作ろうという発想がまずありえない。
単に組番号ごとの最大値を保持するためのテーブルを作ればいい。
MySQLにシーケンスはないが、手動でそれと同様の処理を行うことはできる。

テーブル
組番号　PK
枝番　integer　default　1

INSERT　INTO　テーブル　(組番号)　VALUES　(x)　ON　DUPLICATE　KEY　UPDATE　枝番　=　枝番　+　1;
SELECT　枝番　FROM　テーブル　WHERE　組番号　=　x;
で次の枝番を取得してユーザIDを整形して返すようなfunctionでも作ればいい
当たり前だがトランザクション処理の出来ないストレージエンジンだと無理

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

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

みなさん、色々ご指摘いただき、ありがとうございました。

犯罪者個人に対して告訴状を違法派遣・偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料)　or 司法書士が代筆（料金は5万円ぐらい）※コピペ歓迎
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付（疎明資料・証拠にはＩＣレコーダー、スマホによる録音が適しています）
↓
審査　→　不受理　→　告訴状再提出または刑法 第193条で訴えを起こす
↓
受理　→　告訴事実を認め示談交渉（↓）　→示談成立　→　法廷相場50〜100万円の示談金　※示談拒否が良い
↓　　　　　　　　　　　　　　　　↓
事案化←　前科あり　←示談不成立（↓）→　示談外交渉→　犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓　　　　　　　　　　　　　　　　↓
↓　　　　　　　　　　　　　　　起訴　→公判　→　罰金刑＝前科（起訴事実を認めてるため）→追討ち民事訴訟
↓　　　　　　　　　　　　　　　　　　　　
審査　→　起訴（強制捜査・留置場）→　公判　→　懲役刑などの厳罰（反省が認められないため）→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第３０条（検察審査会へ申し立て）→　起訴　→　起訴後は同上
刑法 第193条（公務員職権濫用）で検察事務官を刑事告訴　→　同上

◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約（公正証書・即決和解で秘密保持契約）
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発（刑事訴訟法239条1項）も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。

注意：告訴が受理されない理由
●３年間（※）の時効が過ぎたもの　※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの　※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。

３行でお願いします。

告訴の趣旨
　被告訴人は、以下に該当すると考えるので、被告訴人の厳重な処罰を求めるため告訴します。
　職務経歴書を提示した事前面接を実施　または　偽装請負　または　偽装出向
　　労働者派遣法第26条（契約の内容等）、職業安定法第44条（労働者供給）に違反
　多重派遣・多重出向
　　労働基準法第6条（中間搾取の禁止）に違反
疎明資料
　事前面接日時、場所、出席者、資料のコピー、音声記録
　就業場所・就業期間・就業時間
　指揮命令
　　指示を誰が行っているかの記録、音声記録
　仕事で使う道具や、資材の負担（所有）のあり方
　　業務で使用しているパソコン・備品などの所有者
　契約書
　　請負、雇用契約書、出向指示など書面のコピー

刑事告訴ガイダンス　
★痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払わせて解決するのが絶対的過半数です。和解で解決しない事案、つまり公訴までいって判例となる事例を探すほうが難しいことでしょう。
★録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
★告訴状を検察に提出しても受理されなければ加害者側には知られることはありません。不受理の場合は何事も起きてないように粛々と振る舞ってください。
★告訴を取り下げるとき検察に提出した資料は全て返却されます。また検察があなたが提出した証拠をあなたの許可なく裁判の証拠として使用はできません。告訴を取り下げたのちの録音資料には当事者の立場が失われるため証拠能力はありません。
★和解時に告訴した事実は秘匿事項となります。犯罪者が秘密保持契約に違反した場合の損害賠償金は「即決和解」か「公正証書」で最低5000万円〜にしましょう。支払いを拒否すれば強制執行手続きを地方裁判所に上訴（裁判不要）してください。
★派遣会社や事業会社が同業者に貴方の情報をリークしたなら、同業者（又は競合他社）に弱みを握られることになります。
余程信用のおける相手でなければ、リークはできないでしょう。信頼のおける方にしても、その方の口が軽ければ、いずれ事実は分かります。
★リークの情報を得た事業者のなかには、リークの事実を貴方に教えてくれる方がいるかもしれません。その際は損害賠償金で得たお金の３割程度を謝礼金として渡してください。

　　●●●ケネディ大統領は何故、死なねばならなかったのか？●●●
　　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
　　　　メール　　[email protected]

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

パワハラ犯罪にたいする刑事罰(※本投稿のコピペ歓迎です)
人事原則
１　現行法では、社員が仕事を怠けたり、能力不足、就業規則違反、目標を達成できなくても解雇をしたり叱責することは違法です。どんな駄目社員、嘘つき社員、怠け者も定年まで解雇が違法なのが現行の正社員制度です。
２　パワハラは社風にあわない社員、成績の振るわない社員を自主退職に追い込む言わば人事的措置として用いられることが多い。
※違法な解雇の和解金相場は、労働審判で３ヶ月、通常裁判で１年以上の報酬、さらに社員が和解を拒めば復職が可能です。弁護士への着手金は12〜15万円＋20%の和解金、和解拒否なら20〜50万円程度。

人事部・ホットライン・御用組合へ直訴
メリット：　一時的緩和や人事異動
デメリット：　役員へ情報筒抜け、危険分子の烙印（情報漏洩がホットライン直訴者に多いのは人事部の常識）、パワハラ放置で自主退職に追い込まれる

民事訴訟・調停・労働審判
メリット：　損害賠償
デメリット：　裁判費用、解雇措置、民事不介入で刑事事案化を阻止、長期係争、パワハラ上司の継続雇用

刑事告訴
メリット：　１パワハラ上司の解雇・懲戒、または２多額の和解金、１と２どちらでも被害者の雇用は維持
デメリット：　人事異動（出世コースから外れる）
◎録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
◎告訴受理後の和解金は加害者の資産・収入に応じて変えてください。犯罪者の昨年の年収の半額程度×最大懲役年数が妥当です。
◎パワハラの被害についての告訴は１侮辱罪２脅迫罪３強要罪４威力業務妨害罪５傷害罪の順序で行ってください。警察・検察の協力（犯罪者の自宅・職場の強制捜査、留置所勾留）により罪の立証が楽になります。
◎刑事告訴した社員を解雇したり処遇面で著しい差別を行うことはないでしょうが、出世や管理職以上の昇進の可能性はあきらめるべきでしょう。
◎刑事告訴は民事訴訟と違って裁判による被害者への2次被害にありません。検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間も告訴状をかくことと音声録音を残すだけです。
◎和解契約（公正証書・即決和解）では告訴した事実は秘匿事項となります。犯罪者が秘密保持契約を違反した場合の損害賠償金は、最低5000万円〜にしましょう。

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

※本投稿の拡散お願い致します。
◯外国労働者を海外から日本の企業での作業（物理的に日本にいる必要はない）に従事させる場合、海外の受注者は派遣業者として登録し派遣法に準拠しなければならない。違反すれば職安法違反となる。

◯事前面接時の会話、テレビ会議、国際電話を通じた日本からの指揮命令・技術指導はICレコーダー・スマホで録音してください。

◯中国・インド・ベトナム・韓国でのアウトソースを標榜しても派遣とみなす作業があれば労働基準法、職業安定法の責任は雇用主＝発注者にあります。

◯雇用主とは外注している元請けと下請けを含みます

◯中国人、ベトナム人、インド人、韓国人の方で偽装請負、偽装出向、多重派遣の被害を受けた方は日本の検察に刑事告訴をしてください。

◯国境が違っても顧客＝発注者が日本にいれば、日本の法律を適用できますので是非ご活用ください。

◯刑事告訴は無料です。元請けの各役員報酬は数千万円はゆうに超えているでしょうから、
総額で４０００万円〜程度の和解金となるでしょう。
和解金の相場は日本の相場に準拠しますので、皆様の国の平均生涯年収を超えることは間違いないでしょう。

操作ログやアクセスログをユーザ毎に保存するテーブルがあります。
今までは1つのテーブルで全ユーザのログを保存していたのですが、
ユーザが増えてくると、かなりSELECTが遅くなりました。
1000万件をWHEREで抽出する場合、1分弱かかります。
（インデックスは適切に貼っています）

ORDERを指定しないと早く表示できるのですが、
記録日時を降順にしたいので、ORDERを使う必要があります。

そこで「ユーザごとにログを記録するテーブルを作成する」
という事を思いついたのですが、これは設計として正しいのでしょうか？
テーブルのカラム構成は後々変わらないとは思います。

ただ、ユーザごとにテーブルを作ると、
ユーザ1万人にテーブル1万個とかになるので、正しくない気がしています。
何か良いアドバイスがあったらお願いします。

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

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

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

>>148
まず確認
>1000万件をWHEREで抽出する場合、1分弱かかります
1000万件を抽出するのか？
1000万件から抽出するんじゃないのか？そのばあい抽出される件数は何件ぐらいだ？

ORDERなしで早いってことは、時間かかってるのはソートだと思われる
つまりORDERにインデックスは（あっても）効いてない
まあまずは実行計画確認するべきだが

ここ設計スレなんで本題
>ユーザ1万人にテーブル1万個とかになるので、正しくない気がしています。
正しくありません
まずはDBMSの機能で、テーブルを分離する機能の検討を

>>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を思いついた次第です。

>>152
テーブル構成や諸々の条件は>>153に書きました。
インデックスはuser_idとdateに貼っています。
LIMITを1にしても1分以上はかかります。

>>148の設計が正しくないとすれば、どうするのが最善なのでしょうか？
EXPLAINをしてもよくわからないので、悩んでいます。

EXPLAINしてみ

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

>>152
いやいや、ORDERなしなら速いということだから、
> まずはDBMSの機能で、テーブルを分離する機能の検討を
の必要は多分ないんじゃないか？

適切なINDEXが本当に貼られてるのか、適切なクエリなのかをまず考えるべき。

1000万件にまで成長したのがサービス開始から1年で、これ以降数年、10数年そのまま運用するとかいう
ことなら、パーティショニングを考えたほうがいいとは思うけど。

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

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

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

>>153
LIMIT 1とかじゃなくて、検索結果は全部で何件あるんだって話
極端な話、1000万件全部'2013-02-06' だったらインデックス意味ないから
あとMySQLよく知らないが、サーバマシンの全CPUと全メモリ使ってるとは限らんぞ

インデックスはuser_idとdate、それぞれに張ってるのか？
その条件で(user_id,date)の複合インデックスだと多分役に立たない
(date,user_id)の複合インデックスなら(dateの単独よりちょっとだけ)効果あるかもな

でも普通に考えるとdateのインデックスが効いてない気がする
MySQLってインデックスに順序指定あるか？あるならちゃんとdate DESCで定義してるか？

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

他にもテーブルの時期別の重複分割
を行うなどの方法も有力な感じですが...

>>161
それ最悪

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

>>160
>インデックスはuser_idとdate、それぞれに張ってるのか？
いえ、複合です。その複合の順序もどっちが速いか検査しました。

正直、あまりインデックスが効いてない気がするのですが、
効いてるかどうか調べる方法ってあるんですかね？
EXPLAINでも特に以上は無さそうですし。

>>161
とにかくORDERしないと速いんです。1秒もかかりません。
日付に関してはDATEとTIMEで分けてますが、
タイムスタンプは保存していません。

どうやったら1000万件のレコードをORDERしても
速くSELECT出来るのかわかりませんが、
取り敢えず設計的に>>148が間違っているのでしたら
代替え案をお願い出来ればと思います。
SELECTの速さやパーティショニングの切り方については
またMySQLスレで聞きます。

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

>>164
何回も聞いてるが、出力される件数は何件なんだよ？
SELECTした結果が1000万件なのか？1000万件の並べ替えならある程度時間かかるのはしょうがないかもしれん
SELECTした結果が数千件なら何分もかかるのはおかしい

代替え案なんかねえよ
設計かえるんじゃなくて正しくチューニングしろ

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

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

>>166
>>154にLIMIT 1って書きましたが、これでは不足でしょうか？
SELECTした結果は1件です。LIMITしてない場合の条件でも。

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

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

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

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

>>171は私ではありません。

とりあえず、皆さんの意見を見ると
複数テーブルに分けないのが正しいと思いますので
その方向性で考えてみます。
たぶん>>168の記事をするとだいぶ変わると思います。

色々とアドバイスありがとうございました。

>>169
カーディナリって理解してるか？
検索対象全体のうちでインデックスにより取得される件数の割合聞いてるの
それが多いとインデックス使っても早くならなくなるから
LIMIT 1でも、その1件を調べるには検索結果を全て並べ替える必要があるのは理解できるか？

>>172
カーディナリが複雑とか単純とか初めて聞いたけど
カーディナリが複雑ってのはどういう状況か説明してくれんか
あとカーディナリ低いキーを分割してもカーディナリは高くはならんと思うが
キー分割でインデックスが効率化される理由も教えてくれんか

>>173
設計については複数テーブルなんてパーティショニング出来なかった時代ならともかく
今時のDBでは普通は正規化崩してまでやる必要ない
ざっと見た感じ>>168の記事の内容は最後のとんでもないの除けばすでに全部言われてるだろ

あとちょっと調べたところだと、MySQLではインデックスの順序指定は無効らしい
昇順で遅いかどうか調べて実行計画比較すれば何かわかるかもな

概念的には、1000万行程度なら一つのテーブルでいいに決まってるんだから、現状遅い原因をつきとめ、
それを解消するのをテーブル設計に求めるのか、その他の物理設計（パーティショニング等）に求めるのか、
あるいはMySQLのパラメータチューニングをするのかを判断しないとだよ。

で、それをするには、今使っているMySQLのバージョンとサーバのスペック、テーブル定義情報、
クエリの内容、EXPLAINの結果を出すしかなく、そしてそれはMySQLスレが適切な場所。

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

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

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

色んなユーザーのログを見たいときに、いちいち一分待つのか？

タイトな状況での障害解析したことない素人さんならではの発想だな。

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

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

>>181

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

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

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

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

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

>>187
私の言い方が悪いのか、内容が伝わってない気がします。

カラムの追加が必要になる場合の話なので、一つのカラムに着目するのは当然です。
そして、その追加されるカラムがNOT NULLなのであれば、NULL許容派もNULL撲滅派も
ADD COLUMNすることに異議は無いと思います。

しかし、そのカラムがnullableの場合にどうすべきかという話で、なぜ別テーブルにした方が
良いとその人が主張していたのかを今一度確認したいので、そのような記事を見かけた人は
居ませんかと質問した次第です。

第6正規形の話かな。

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

>>188
>カラムの追加が必要になる場合の話なので、一つのカラムに着目するのは当然です。

カラムを追加するのであれば既にテーブルに存在しているカラムとの従属性などを
分析するのは当然だし、既にテーブルに入っているデータのマイグレーションと
いう観点からだとスキーマだけではなく既にあるデータとの関連も検討しなく
ちゃいけない。
そして別テーブルに分けるとなると参照はともかく更新処理は一段と複雑になる
のでアプリケーション側との関係も見なくちゃいけない。

>そして、その追加されるカラムがNOT NULLなのであれば、NULL許容派もNULL撲滅派も
>ADD COLUMNすることに異議は無いと思います

許容派だろうが撲滅派だろうが異論以前の話。
「NOT NULL云々だけで判断するかボケ」で終わる話。

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

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

なかなか真意が伝わりません。

別テーブルに分けることの是非を聞きたいのではなくて、「別テーブルにすべしという主張があるなら、
その理由を知りたい」のです。

以前、そうすべしという記事を見かけた記憶があり、もし誰かご存じならもう一度読み直してみたいのです。

「NULL撲滅派だから、別テーブルにするよ」以外の理由で、同じく別テーブルにすべしと考えている方が
いらっしゃるなら、是非その理由を教えて下さい。

>>193
NOT NULLだと自動的にADD COLUMNという話になるわけじゃないでしょ。

NOT NULLだろうが追加するカラムが推移的従属にあるのなら別テーブルに分ける
ことも検討するし、NOT NULLであっても既存のレコードのカラムに埋められるのが
単なる空値であれば空値を取っ払って別テーブルにすることもある。
そしてnullableにする場合はデータの文脈の中でnullの指し示す意味をはっきりさせ
なくちゃいけない。

つまるところ別テーブルにするかなんて基本的にはNOT NULL以前のデータモデリング
の段階でケリがついているべき話であって、一つのカラム定義を見て別テーブルに分ける
のを悩むヒマがあるのならモデル設計に立ち戻らんと意味が無いと言うこと。

仮にパフォーマンス云々の話であれば、どのようなDBMSの上でどのようなクエリや
トランザクションが走るのかが問題なので、一つのカラムのNOT NULL云々だけ見て忖度
することにはますます意味が無い。

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

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

それと、多分、君の持論なんか聞きたくないと思うよ。

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

>>197
>データの文脈の中でnullの指し示す意味をはっきりさせた結果、nullableなとして追加する必要があるとき

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

>それをadd columnするか別テーブルにするかって話でしょ
要約「ケースバイケースだからなんとも言えない」。NOT NULLだけでは何も言えない。

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

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

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

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

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

まあとりあえず>>183にどこでそんな記事をみたのか思い出してもらって
そこにどんな前提でそうしろと書いてあったかだな

まあ俺ならどんな理由であれそんな記事信用しないが
特別な前提でパフォーマンスに有利だとしても他人に薦めるようなもんじゃないだろ

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

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

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

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

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

>>210-211
>>210

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

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

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

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

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

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

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

お久しぶりです。
私の書き込みが、一部の人をモヤモヤさせていたらすみません。

さて、あれからも時々一体どこで見たのか思い出してみたり、思いついたキーワードで検索してみたり
してるのですが、ひょっとしたらこれなのかもというキーワードを発見しました。

Records with extra properties: sparse table or EAV?
http://stackoverflow.com/questions/3486019/records-with-extra-properties-sparse-table-or-eav

キーワードは、sparse tableとEAVです。
なお、このページは、最初に読んだページではありません。

軽くググったところ、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"というのを使うのがベストプラクティス
なんでしょうか。

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

だから場合によるとしか・・・

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

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

中学生だから

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

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

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

論理設計はできないけど
物理設計はできると思いますって言っちゃったけど
どう面接を切り抜けたらいいかな？

やっぱ実務経験ないのになんでできるんだよ
って突っ込まれると想う

自分なりに勉強してると思ったら、
それぐらい勢いがあってもいいと思う。
面接では、結局はその人の回答の仕方や態度なんかを見ると思うから。
一緒に仕事がやっていけるやつかどうかを見る。

本当に論理設計や物理設計をできるやつを求めてて、
付け焼き刃でもそれに関する当面の仕事をこなせないと思ったら、事実を話した方がいいが、
迷惑をかけてでもその仕事をやりたいのであれば、押し通すことも否定はしない。
その場合死ぬ気でがんばるしかない。

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

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

※本投稿の拡散歓迎です。
派遣労働者のパワハラ・セクハラ対応策について

下請け労働者、業務委託、派遣労働者は契約期間が短期という制約があり、契約更新拒否をちらつかせた不当な労働強要の実態があります。
雇用形態における壁・差別は法律に直接的規程はなくとも認められているわけではありません。
「正社員の有期雇用労働者に対する優先的地位乱用」による「侮辱罪」、「脅迫罪」、「強要罪」、「傷害罪」、条例違反で刑事告訴できるが、
本稿では刑法ではなく労基法関連の対策に焦点をあてます。

労働基準法第5条（強制労働の禁止）（1年以上10年以下の懲役又は20万円以上300万円以下の罰金）
■精神の自由を不当に拘束する手段によつて、労働者の意思に反して労働を強制してはならない。
例：正規労働者（同僚）による残業の強制。仕事の期限が遅滞した際に「繰り返し」残業を示唆する。
例：派遣の仕事の回し方の裁量を正社員が決めるなどと示唆する。
例：飲み会、昼食、たばこの同伴を強要する。

労働基準法3条 （六箇月以下の懲役又は三十万円以下の罰金）
■社会的身分を理由として労働条件について差別的取扱をしてはならない。
例：社内制度に明示されていない指揮命令系統が正社員と派遣社員に存在する。
派遣社員も正社員と同様に社内制度に準じるという契約上、業務で平等に取り扱う必要がある。
例：社内制度上の上司でもない正社員が命令をしたり、仕事上の指導権・裁量・許可権限をもつこと
派遣契約の内容にそうした区別を制度化するような客観的な証拠がなければ派遣社員側に有利といえる。
例：派遣社員に業務上における裁量を一切与えず、非管理職の正社員が許可を与える

労基法3、5条については、経営責任も問えますので、刑事告訴できる相手は以下のとおり。

派遣先　当該正社員
派遣先　指揮命令者
派遣元・派遣先　代表取締役

刑事告訴（告発）の行い方ですが、内容証明郵便で告訴状（告発状）を地方検察の直告班に郵送してください。

属性が定まらない物はどういう方針でテーブルに落とし込めばいいですか？
例えば色々なサイトのアカウント情報を管理するテーブルを作りたいとします

サイトのログインに必要な情報は、ログインIDとパスワードの時もあれば、
ログインIDとメールアドレスとパスワードの時もあり、
またログインIDとパスワードと秘密の質問の時もあり、生年月日が必要な時もあります

実際にどんな情報が必要になるかは不定なので、必要になりそうな情報を前もって属性として用意しておくのは無理ですし、
かといって必要な属性が増えるたびに属性を追加すると、特定のサイトでしか必要ない属性が大量に増えて
テーブルがnullだらけになってしまいます

今自分で思いついている案は三つです
　・新たな属性が必要になるたびにどんどんテーブルに属性を追加していき、テーブルがnullだらけになっても気にしない
　・>>183の方法で新たな属性が増えたら新しいテーブルを作って管理する
　・そもそも「メールアドレス」や「パスワード」などを独立した属性として扱わず、>>219の方法で汎用属性テーブルで管理する

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

入力項目1 入力項目2 ... 入力項目n　だけは事前想定できるんだから

サイトID int,
入力順 int,
入力内容 varchar(適当)

こんな感じでいいんじゃね

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

KVS

回答ありがとうございました。
>>234-236の案については昨日購入した書籍「SQLアンチパターン」にまさにその案が書いてあり、
それぞれのメリットとデメリットが書いてあったのでコメントは差し控えます。

>>237
アカウント情報の管理なんて教科書的な課題ですら関係データベースではうまく扱えないのですか？
もしそうなら関係データベースには失望しました。

教科書的には(3)だと思うけれどもなぁ。
スキーマってのは一般に時間不変な構造をあらわすものでデータの追加と共にポンポコ列を
増やしたりテーブルを新設することが初めから前提になっている設計はちょっと疑ってか
かった方が良い。

この場合時間不変な構造は例えば「ユーザはあるサイトの入力項目のそれぞれについて値を
持つ」ということだろうから、関数従属性としては、

ユーザ, サイト, 入力項目 -> 値

という事になって、テーブル設計もそのまま、

userId, siteId, fieldId, value key: (userId, siteId, fieldId)

になると思うけど。

>>239
本来異なる属性をひとつのカラムにまとめるのをよしとする教科書なんてないだろ。
新しい属性を追加するってのはスキーマの変更に他ならない。

>>238
RDBは一階述語論理に基づくものだからね。そこで表現できるところまでが限界。

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

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

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

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

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

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

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

何が属性になって何が属性にならないのかというのは決して自明ではないよ。

ログインに必要な項目の定義と、ユーザの属性をごっちゃにしてるんじゃないかな。
ユーザの属性ならユーザマスタのカラムとしてidや氏名、メールアドレスなんかを
定義して、新規に属性が必要になったらカラム追加でいい。

でも今回はサイトごとのログインに必要な項目の定義をどう実現するかという
話だから、ユーザマスタのようにカラムを追加していけばいいって話じゃないよ。

送信してしまった。

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

新しいサイトの登録が必要になった場合、シス管がシステム止めて個別に登録していくので
あればカラムの追加でもテーブルの追加でも好きにやればよい。

でもユーザが新しくサイトを登録する場合など、DBに対するトランザクションの結果として
カラムやテーブルの追加が必要となるとすればそれは筋が悪い設計と言わざるを得ない。
(3)は教科書的ではないとか言うけれども、運用からみれば(1)(2)は論外だ。

ただ無意味に「汎用属性テーブル」とかいう名前に引きずられていないか。

製品個体番号, 部品ID, 部品製造年月日 key: (製品個体番号, 部品ID)

と

サイトURL, フィールドID, 入力値 key: (サイトURL, フィールドID)

ではどこが違うの? 後者は「汎用属性テーブル」とやらで前者はそうではないの?

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

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

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

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

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

数日間調べてとりあえずの結論が出ました。

>>233の問題の本質は「非構造化データをどうやってRDBで扱うか」ということになりそうです。

>>233のようなデータは「非構造化データ（半構造データ）」と呼ばれます。
非構造化データをRDBで扱う方法についてはまだ模索中の段階であり決定的な方法論は見つかっていません。
つまり>>233について「正解」と呼べる答えはまだないということです。

しかし一長一短があるにせよRDBで半構造データを扱う方法についてはいくつか考案されています。
以下のページでは4つの方法が紹介されています。
> スキーマ不定のデータをRDBに永続化する方法の比較
> http://dev.ariel-networks.com/Members/inoue/schemaless/

> 非構造化データをRDBで扱う方法についてはまだ模索中の段階であり

補足ですが、これはDB業界全体で模索しているという意味です。
個人的に模索中という意味ではありません。

「非構造化データをRDBで扱う方法」に関してはRDBが始まった当初から、半構造化データが専ら
XMLの文脈で語られるようになって以降でも20年近く延々と模索されていて、主だった方法は殆ど
出尽くしている。

はっきりしているのはSQL92で議論できる範囲には「たった一つの気のきいた方法」は無い事で、
開発者それぞれが模索して受け持つ問題に対する最適な方法を選んだり、ベンダー拡張を使ったり、
既存の方法と知らずに車輪の再発明をしたあげくに意気揚々とblogに書いちゃう、というのが現状。

ただこれはあらゆる問題に対応する「たった一つの気のきいた方法」が無いことにすぎないのであって
>>233の例のように問題領域を絞ればそれなりに答えはあったりする。

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

だからどうした

確率

実習を兼ねてRSSリーダーを作ろうとDB設計中なんだが
ユーザーがどのフィードアイテムを
どういうステータスにしているか（未読、既読等）管理したいとき
レコードが肥大化するのが気になってしまう

使用DBはMySQL

以下のテーブルがあって
・ユーザマスタ
・フィードアイテムテーブル
・フィード管理テーブル

以下の関係性
<--> 1:1
<-->>1:N
ユーザマスタ <-->> フィード管理テーブル
フィードアイテムテーブル <-->> フィード管理テーブル

懸念は、日に1000件フィードアイテムが追加されると
*ユーザの数だけフィード管理テーブルが追加されてしまう事

定期的にレコードを削除する運用を考えてるけど
何か他の設計方法ってあるかな

ユーザとフィード(RSSとかATOMとか。フィード「アイテム」ではなく)の間に「購読」関連を入れる。
これにより一日1000件フィードアイテムが追加されてもフィードアイテムテーブルは1000件しか増えない。

ユーザー <- (フィード購読) -> フィード <->> フィードアイテム

その上で、ナイーブな方法としてはユーザとフィードアイテムの間に「未読」関連テーブルを入れる。

ユーザー <- (未読) -> フィードアイテム

フィードアイテムが追加されたら、そのフィードを購読しているユーザに「未読」を追加する。
ユーザがアイテム読んだら未読テーブルから該当するレコードを削除する。
全てのユーザが全てのフィードを購読しているのならともかく、普通はそれぞれのユーザは幾つかのフィード
しか購読しないので、「未読」テーブルへの追加数は「アイテム追加数 x ユーザ数」よりは少なくなる。

ただこれだと未読を何千件も抱えるようなユーザが多くなると厄介。
その場合は単純な「未読」関連の代わりに「フィード購読」関連に「ここまで読んだ」タイムスタンプを入れて、
これ以前の例外的な未読アイテムとこれ以降の例外的な既読アイテムを「アイテム状態」テーブルで管理する。

ユーザー <- (フィード購読, ここまで読んだ) -> フィード <->> フィードアイテム
ユーザー <- (アイテム状態, 既読or未読) -> フィードアイテム

この場合、フィードアイテムを追加しても「アイテム状態」テーブルには何もしない。
ユーザが未読アイテムを読んだときに「アイテム状態」テーブルにアイテムを「既読」として追加する。
「ここまで読んだ」以前のアイテムをユーザが手動で「未読」にした場合はアイテム状態テーブルにアイテムを
「未読」として追加する。
それ以前の既読数がゼロになったり「全てを既読にする」操作をユーザが行ったら「ここまで読んだ」タイム
スタンプを更新して不要なアイテム状態レコードを掃除する。ユーザの操作シナリオに応じて「ここまで読んだ」
タイムスタンプをどう上手く更新して状態レコードを掃除するかが勘所になると思う。

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

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

ユーザテーブル
フィードの情報を入れるフィードテーブル
フィードアイテムテーブル
ユーザがどのフィードを購読しているかを入れる購読テーブル

購読テーブルにユーザ、フィードごとの未読ポイントを入れる。
フィードアイテムは消さない。

こんなかんじか。

>>263
ありがとう
既読の線引きと 未読状態のレコード追加、参考にする

>>265
問題点を綺麗に切り取って説明できてない以上、
中途半端な情報じゃ別の疑問点が出てしまうな
申し訳ない

制作途中のER図
http://www1.axfc.net/uploader/so/2860702.png

※図、誤字訂正　「フィード管理」 -> 「フィードアイテム管理」

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

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

扱うデータが複雑すぎてどう設計してもテーブル数または属性数が膨大になってしまうようなデータは、
そもそもリレーショナルデータベースで扱うのが間違っているということでしょうか？

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

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

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

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

>>270
> 際限なく抽出できると思います

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

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

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

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

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

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

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

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

>>281
> やっぱり使い切りませんか。
少しは考えようよ。

BIGINTが「1億×1億×1800くらい」というのが何を意味するかというと、
「1日1億件登録するのを1800億日続けるといっぱいになる」
↓
「1日1億件登録するのを続けても、約5億年はいっぱいにならない」

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

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

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

簡単なメールの配信システムを検討してるのですが、
一般的にメールアドレスに関しては、暗号化してデータベースに入れてるもんなんでしょうか？
今のところ考えてるのは、メールアドレスのみ生データ、それ以外は暗号化もしくは記号化しようかと

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

ぐだぐだ書いたのですが、要はメールアドレスは生データにしてもよいもんか、御法度なのかということです・・・

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

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

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

>>286
どんな些細な情報であれ「流出したら客が怒る情報」は暗号化するのが普通です
万が一情報が流出した際に「無意味だと思ったので暗号化はしてませんでした」だと印象は非常に悪くなります

その暗号化の方法としてDBの行レベル・表レベルの暗号化機構を使うのか
あるいはアプリケーションレベルで暗号化してデータを出し入れするのか
それはデータベースの設計とは関係がない事項なのでこれ以上の回答は控えます

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

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

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

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

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

>>293
例えばPSNの大規模流出事件でクレカ情報が漏れなかったのは、
クレカ情報はDBには暗号化されて保存されていたため。

クレカ情報にアクセスする必要があるプログラムは非常に少ない。
だからクレカ情報を復元できるプログラムを限定しておけば、
それ以外のプログラムがSQLインジェクションで操り人形になってしまったとしても
そのプログラムからはクレカ情報が復元できないから流出もしないということ

そんなバナナｗ

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

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

今テーブルのチューニングで悩んでいます。
DBはSymfowareV10です。

テーブルの列数が70ぐらいあるんですけど、その内の半分ぐらいが検索対象項目になっています。

想定する検索条件のパターン用の複合インデックスを全部つくったら容量が大変なことになってしまいます。
そもそもそんなに大きいインデックスに意味があるのでしょうか。
こういう場合の解法ってどういったものがあるでしょうか。

複合インデックスに対してWhere句の内容が歯抜けのような状態でも効果的にインデックスを効かせる方法があったりするとうれしいです。
もしかして文字型で本来歯抜けになる検索条件に「c1 >''」みたいな条件を入れたらごまかせたりしないですかね。

乱文での質問で本当にすみません。
よろしくお願いします。

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

テーブルを分割するとか

>>301
レコード数は1000万件位です。
1レコード400バイト位です。
数値型は範囲検索、それ以外は完全一致で検索します。　

>>302
やっぱりテーブルを分割するしかないですかね。
検索用の分割テーブルを用意して結合とか色々試行錯誤してます。

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

インデックスで考慮すべきはまずカーディナリ
複合インデックスは一般的に頭がヒットしないと効果薄い

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

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

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

>>307
馬鹿には無理

Symfowareって触った事無いけど、現状の行あたり400バイト
構成の列数とかにもよると思う。
列数が多いなら、数値型の範囲指定検索項目と、完全一致項目を分けて
データ作るとか。（二つのテーブルに外部キー貼るとか）

時間の猶予があるなら、何パターンがテーブル作って、
効率のいいデータ取得方法見つければいいんでない？

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

現在MySQLを利用したWebサービスを製作中で、
複数の姉妹サイトを運営しようと考えています。

1つのサイトに25程度のテーブルがあり、
10サイト程度を予定しているので全体で250のテーブルになります。

そこで質問なんですが、
1つのデータベースにサイトごとに接頭辞を変えたテーブルを複数作ったほうがいいのか
そもそもサイトごとにデータベースを分けたほうがいいのか悩んでいます。


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

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

ユーザー情報なんかは共通するんですが、
それだけは別のデータベースに…。
と考えると、やはり1つで管理したほうが良さそうですね。

調べてわかった範囲では、
同一サーバ内でデータベースを分割してもパフォーマンスは上がらないとのことなので、
1つのデータベースにテーブルを作成する形にすることにしました。

複数のサーバでデータベースを分散する必要がでたら…、その時考えますｗ

>>311
>1つのデータベースにサイトごとに接頭辞を変えたテーブルを複数作ったほうがいいのか

これはあまり無いかなぁ。

・ORMを使うにせよ自分でクエリ吐くにせよテーブル名が固定にならないのは普通に開発が
　面倒で既存のツールも使いにくく落とし穴も多い。殆どのテーブルのアクセスに関して
　サイト毎にテーブル名を振り分けるロジックを書く必要がある。
・あるサイトから隣のサイトの情報を見られないようにするのがアプリケーションレイヤー
　の責務になる。サイト毎にDBを分ければ見える情報の範囲はDBMS上で綺麗に分断される。
・運用が面倒。サイトの停止時もサイト毎に分けておけば普通にDROP DATABASEで済む
　ものが、一つのデータベースだとその都度個別のSQLスクリプトを用意する必要がある。
　データベースのリカバリ等についても他サイトを巻き添えにせず個別に行うのが面倒。

一般論として一つのデータベースで複数のサービスを運用するマルチテナントはそうでない
ものに比べて開発は面倒だし運用も気を使う。
マルチテナントにしても新しいサイトを作る度にポコポコと新規テーブルを作るのは筋が
よいやり方とは思わない。これをするぐらいなら普通にデータベースを分けた方が良い。

>>314
あまりないですか。

テーブル振り分けや見える範囲なんかは、さくっとできるんですが、
運用が面倒というのは確かにその通りですよね。

規模が大きくなった場合は分けたほうが運用が楽そうなんですが…。
Webサービスが大きく成長してほしい反面、小規模なら1つでもいいかと。
悩ましい…ｗ

しかし考えたらブログ程度の情報量でも数百MBになることを考えたら、
バックアップ、メンテナンス、復旧を一括でってのは現実的じゃないですね…。

うし。助言を参考に、今回は分けてやってみます。
ありがとうございました。

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

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

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

>>318
同一データベースで、
site1_users
site2_users (site1_usersとスキーマは同一）
というようにしようかなってことだと思うよ。

それとも、データベースを分けて
site1.users
site2.users
にすべきか迷っていると。

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

>>319
その通りです、説明ベタですいません。（というより知識不足ですがｗ）

確かにデータ量わからないと、アドバイスしようがないですよね。
私もどれくらいになるのか現時点で全然わからないんですｗ

将来もしも大規模になった際に運用が成り立たなくなるようだと困るなと思って質問しました。

初心者ほど何故か「データ量が〜」「パフォーマンスが〜」とかいってヘンテコなスキーマを
持ち出す法則。教科書通りの基本的な設計から始めようよ。

接頭辞つけて同一スキーマのテーブルを必要に応じて増やすのは特殊な事情が無い限り大抵は
バッドノウハウ。で、こんな事を気にしているレベルならデータ量とかパフォーマンス云々は
とりあえず忘れた方が良いと思う。ホントに。

まずドメインモデルを素直にスキーマに落として、そこから必要に応じて手を入れれば十分。
無理してトリッキーなスキーマを使わなくともサイト毎にクラスタ化するとかシャーディング
するとか、いくらでも解決策はあるのだから。

それよか運用形態とかシステムの構成の方がずっと重要。
姉妹サイト間の運用の独立性はどの程度か、どのような頻度でサイトを新設したり削除したり
するのか、ウェブアプリの一つのインスタンスで全ての姉妹サイトをホストするのか、それとも
サイト毎にインスタンスをあげるのか、姉妹サイト間での共有する情報は何か、個々の姉妹
サイトでカスタマイズや機能拡張はあるのか、開発言語やフレームワークは、など。

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

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

知らんが。

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

上で質問したものですが、無事サイトごとに個別のデータベースを作り、
シングルサインオン用のデータベースからユーザー情報を取得。

という形にしました。

設計していく中でこの方法で良かったと思うことちらほら。
メンテもこの方が楽そうです。
ありがとうございました。

真偽と未定義等の3値論理のカラムを定義するときって
最小サイズの数値型使うのが普通ですか？
BooleanがあるDBだとNULL許可で扱うのが一番自然なんですが

数値型の場合、各値の割り当ても若干悩みます

定番だけれどもNULL撲滅委員会
http://www.geocities.jp/mickindex/database/db_getout_null.html

個人的には
・ORM使用する場合は結局DB中のNULLはホスト言語のnullにマッピングされるし、
　NULLの問題が絡むような凝った条件式は書かなかったり書けなかったりするので
　結局ホスト言語で未定義値をどう扱うかで決めてしまった方が良い気がする。

・ただbooleanに限ってはnullableだとアプリケーションのロジックが解りにくく
　なりがちでバグのもとなので意識して避けるようにしている。
　例えばdeleted != trueとdeleted == falseの結果が異なるかもしれない、って
　コードの上だと気がつきにくいと思う。

>>328
・3値論理
・値を3つしかとらないカラム

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

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

>>330がこのスレ的に最も適切なレスだと思う

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

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

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

>>334
例えば？

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

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

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

>>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」などに詳しい解説があるから、一読を勧める

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

>>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は駄目だから楽なんだけど。

ごめん。難しくなりすぎたから>>341は取り消す。

知りたいのはこれだけです。

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

3値論理のとき、だろ

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

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

これはちょっと重症な感じだからきちんと説明しよう。

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を返すため区別できないからね。

is nullの立場は？

NULLとの比較結果が不定になるだけで、NULLと不定(UNKNOWN)は違うぞ
is nullはNULLかどうかを検査する。結果が不定にはならないだけ

ただし、３値論理を扱いたければNULLとの比較しか不定が起こりえないから
必然的にNULLを使う必要がある

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

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

例えば
select * from TAB_1 where COL_A = 'T' or COL_A <> 'T';
が必ず全件返すかという問題。

COL_Aがnullを許さなければ必ず全件返す。これが2値論理。
COL_Aがnullを許せば全件返すとは限らない。これが3値論理。

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

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

そんな難しい話か？

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

>>330が元凶

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

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

デイト先生はnullの振る舞いについて20ページ以上を費やし懇切丁寧に説明しました。
スカラー式、様々な条件式、テーブル式、整合制約・・・

そしてその章の結びとして、最後にポツリと一言言いました。

「nullは避ける」

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

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

>>361
対象の状態として「真・偽・未定義」という三つの状態が存在するのと
その状態に対する比較演算の結果がSQLにおける値「True/False/Unknown」になるのは全く異なる意味だとわかっているのかね

通常は比較演算の結果は「True/False」で事足りる。
比較演算の結果としてUnknownが返ってきて欲しいという積極的な意思表示がnullの導入なわけだが、
その理由は如何に？

例えば年齢を　{0〜9　10〜19　20〜99　100〜　未定義}
の5つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？

次に年齢を　{0〜19　20〜　未定義}
の3つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？

カラムの取り得る値の数とnull導入の可否は全く関係ないとわかるだろ
「真・偽・未定義」の3つだからnull導入しますってのは全く筋の通らない話だ

>>361
三値論理を積極的に使いたいケースや不可欠なレースが比較的レアだからでは?
個人的にも理由には興味がある。

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

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

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

>>364
> 三値論理を積極的に使いたい

なんて誰も言ってないし。
アホ丸出し。

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

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

>>363
> 例えば年齢を　{0〜9　10〜19　20〜99　100〜　未定義}
> の5つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？
>
> 次に年齢を　{0〜19　20〜　未定義}
> の3つに区分したとしよう。ここで未定義にnullを使うか否かは自明か？

どうして「自明か否か」という問題にしたがるんですか？
nullでもいいし、nullじゃない方がいい場合だってあるでしょ。

> カラムの取り得る値の数とnull導入の可否は全く関係ないとわかるだろ

何も説明せずに「全く関係ないとわかるだろ」と言われてもわかりません。

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

夏休みか

>>367

>>328

コッドが悪い

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

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

>>364
>空値にnullを使って三値論理が入り込んでも空値を表す特別な値を使った場合と同じ結果を
>常に返すのであれば実用上は確かに問題は無いのだけれども、

いや、同じ結果にはならない。その反例の一つが>>351になる。
だから、(２値論理を前提とする)常識とは異なる結果を返す３値論理は避けましょう、という話。

>>367
>> 三値論理を積極的に使いたい
>
>なんて誰も言ってないし。

言ってないから(３値論理は避けて)２値論理を使いましょう、という原則の提案だよ。
そして、その「２値論理を使う」ことを具体的にしたのが「null可は禁止」になる。

>>377
> 言ってないから(３値論理は避けて)２値論理を使いましょう、という原則の提案だよ。
> そして、その「２値論理を使う」ことを具体的にしたのが「null可は禁止」になる。

アホすぎて話にならんわ。
真偽と「未定義」を使いたいんだぞ？

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

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

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

>>378と>>328はおそらく未定義と不定の区別がついてない

未定義を扱うだけなら、必ずしもNULLである必要はない
もちろんNULLでもいいが、３値理論まともに扱えない人がNULL使うとろくなことにならない
だからNULLの必要がなければNULL不許可にしとくほうがいいよ、ってのが撲滅委員会含め大方の意見

まあ俺は３値論理の必要がなくても未定義には積極的にNULL使う派だが
他人に進められるかといえば微妙

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

日時はnull使ってほしい

白熱してるなぁ。

自己レスで書き直し

X: だから、(２値論理を前提とする)常識とは異なる結果を返す３値論理は避けましょう、という話。

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


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

自分は３置論理体系を完璧に理解していると自信のある人は、好きにすればいいんじゃまいかと思う。

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

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

後はその時々の状況次第ですね。

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

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

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

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

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

それとも単にN値論理という言葉を最近知っただけ？

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

えっ？

議論が長引いてるのは特定の一人が極めて不誠実な態度でスレに書き込んでるからだよ
元凶の人物→　>>361 >>378 >>366-367

他人のレスを片っ端から否定。
でも否定する割に一切その根拠を書かない。
しかもどのレスにも「馬鹿」「アホ」「何言ってる」とか他人を罵倒する書き込み。

IDが出ないのをいいことに他人を煽って楽しんでるわけだ。

スルーしなよ...

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

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

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

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

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

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

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

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

>>394
はっ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ご意見お願いします

>>419
> こういった機密情報をそのままwebにつながってるDBに入れっぱなしって良いんでしょうか？

普通 DB サーバーを Web (インターネットのことだよな？) に直結なんてしない。

個人サイト最低...

インターネット 〜 外部ファイヤーウォール 〜 Web サーバー 〜 内部ファイヤーウォール 〜 DB サーバー

ぐらいはやる。

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

>>420
ありがとうございます

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

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

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

>>423
それは玄関のダブルロックが意味ないと言ってるアホと同じ

盗もうとする奴で時間や手間がかかるというだけで諦める奴は珍しくない

今回の相談者の場合、とりあえずWebにつながったDBに保存するんだから、
侵入されたらヤバいのはどうしようもないんだけどね。
古いのを退避させたら1万件流出するか、10万件流出するか、の違いで。

俺なら運用コストとか考えて、原則として暗号化して保存。
復号化するキーはアプリ側に保持して、定期的に更新、とかかな。

前に担当してた顧客は平文で保持してたけどね！

>>425
その意見そのものには同意するが、>>420には全く同意できない
ファイアウォールをいくつ設置しようがSQLインジェクションで「正当なパケット」としてDBのデータが流れていったらファイアウォールなんて何の意味もないわけで

ファイアウォールはサーバー本体を対象とした直接的なアタックを防ぐには役に立つが、
不正なSQLの発行などアプリケーション層でのトラブルについては何の意味もない
そしてDB使うプログラムでは後者の方が圧倒的に脅威

>>427
アプリ層のトラブルの方が怖いのは同意するが、だからと言ってサーバに対する攻撃を放置できるのか？
それこそダブルロックに意味がないという意見だが

まあ、これ以上はセキュリティ関連のスレ立てるなりしてそこでやってくれ

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

自分も興味ある話だなぁ

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

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

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

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

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

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

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

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

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

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

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

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

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

>>435
ファッキンなウェブアプリだとインジェクションで経由でXSSとか。

他スレから誘導されてきたのですが、

逆アクセス解析を作りたいのですが、
1年分のデータを蓄積する場合にテーブル設計はどのようにするのがいいのでしょうか
それとも、ログに書き込む方が理想的なのでしょうか

>>444
データベースを使うまでもなく、テキストベースのログファイルと、ログ解析ツールでいいでしょ

>>444
解析したい元情報と欲しい解析結果分からんとどうしようもないぞ

どう考えてもDB案件じゃないな
他逝けWebProg板あたり

ゲームで1キャラが複数の攻撃手段(個数制限無し)を持つ場合
リレーションナル　データベースで表現できないと思うんだけど､
上限無しで｢何個でも｣を表現するにはどうすればいいの

>>448
キャラID, 攻撃手段
1, 剣
1, 魔法
1, 銃
2, 素手
2, 銃

むしろどうやって上限を制限するかのほうが工夫が要ると思うんだが

キャラID,攻撃手段ID,メニュー上の位置No. としてこれらを複合プライマリキーにすれば楽勝

SQL質疑応答スレより誘導されてきました
よろしくお願いします

ファイルをgmailのようにラベルで管理するプログラムを作りたいんですが
データベースをどういう構造にすればいいか悩んでいます
以下は思い付いた構造と検索方法なんですが、もっといい方法があればアドバイスお願いします

・ひとつのテーブルに <ファイルパス>|<区切り文字で区切ったラベルリスト、たとえばlabel1,label2,label3> として
LIKEやMATCHでラベルリストを検索後、マッチしたラベルリストを区切り文字で分解し、検索とラベルの精査をする方法
・ラベルごとにテーブルを設けてファイルパス(又は他テーブルでファイルパスをインデックス化したもの)を格納する方法

1)uid,ラベル名って列のテーブル作る
2)ファイルテーブルに上記のuid列を作る
3)後は結合でなんとかする
4)ね?簡単でしょう?

テーブルのカラムには、データの最少単位で格納するのが基本
カラム中に区切り文字で複数のデータ入れるとかRDBでは普通やっちゃいかん

>>453
ファイルテーブルに現存ラベルと同じ数だけuid列を作るという意味ですか？

>>455
厳密にはテーブル3つ作った方がいいと思うよ。
idとファイルパスのテーブル(テーブルa)
idとラベル名のテーブル(テーブルb)
idと、テーブルaのidとテーブルbのidのテーブル

>>456
ネタで言ってるんでなきゃ、バカすぎ

>>455
いやそうじゃないぞ
ファイルパス(或いはファイル識別子)とラベルIDで複合キーにしろって話だろ>>453は
その場合ラベルIDはNULL非許容になるからラベル無しを意味する値を事前に決めて置かなければならない
uidでやるならempty(オール0)かな

>>456が普通でしょ
>>453だとラベルを追加するときにファイルパスをコピーした
新規レコードを作ることになるのが気持ち悪い

どこがバカなのかは不明だが
「厳密には」って言い方が変なのと、
3つめのレコードにIDはいらないとこかな。あってもいいと思うが

訂正
×3つめのレコードに
○3つめのテーブルに

レスしてくださった方々どうもありがとうございます

ファイルテーブル(ファイルパス、ユニークID、その他ファイルと一対一対応するもの)
ラベルテーブル(ラベル、ユニークID)
ファイルーラベルテーブル(ファイルのユニークID、ラベルのユニークID)

大まかにはこういう感じで行こうと思います

>>459
>>456 の「テーブルaのidとテーブルbのidのテーブル」なんて要らんだろ。
テーブルb の各レコードにテーブルa の id 入れときゃいいでしょ。

3個要るのは、ファイルとラベルが多対多の時だよ。

gmailのラベルって多対多だろ

>>463
マジか？
なら、すまん、俺がバカだったわ。

> ・ひとつのテーブルに <ファイルパス>|<区切り文字で区切ったラベルリスト、たとえばlabel1,label2,label3> として

Gmail以前にこの時点で気付こうぜ！

色んな専門分野を経験して、それなりに専門家として認知されてきたけど
データベースとその設計を専門すると言ってる連中が一番技術力が低かった。
ま、一番簡単だし当然だよね。

通貨をのデータ型には通貨型やDECIMALがありますが、
小数がほとんど使われない日本円を扱うときに整数型とどちらがよいのでしょうか？

>>467
RDBMSによるが
演算の最終桁数や中間結果の桁数とかまで考慮すると整数型使うのは危険
消費税計算中に途中で丸められたら困るだろ

商品マスタに単価を持たせているのだけれど
特売品などある期間だけ価格が変わる場合、テーブル設計はどうしておくのが良いのでしょうか？

今のところ特売テーブル（商品ID、開始日、終了日、特売価格）を作って、
納品日などの基準となる日付が特売期間に存在したら特売価格を優先にする
っていう方向で考えていました。

価格を取得する処理が現行アプリに点在していて修正影響が大きいのと、
そもそも価格取得の際に基準日となる日付が未決定の場合がある
ので、ほかの方法はないかといわれてまいました。

おしえてくださいまし。

特売のレイアウトはその構成でいいと思うよ。
PrimayKeyの設定しないだけで。Indexだけ貼るとか。
同一商品の登録順に連番ふる構成でもいいかな？
（SEQ、商品ID、開始日、終了日、特売価格）
最大の番号は、基準日未設定がある仕様で。
（基準日未設定が1件の場合なら）

アプリの仕様が分からないから、ここからは感覚だけど。
どの道特売品はみないといけないだろうし、
商品マスタと特売品をVIEWにすれば、アプリの仕様変更は
少ないかもしれない。
VIEWには商品マスタのデータか、特売品のデータを判別できるよう
分類もたせておく。

どうでしょう？

基本的な要件が分からんと何とも言えんが

商品って何だ？特売価格の品物と通常価格の品物は同じ「商品」なのか？
その商品マスタにもってる単価って何だ？
現行アプリが取得してる価格って何だ？
特売の基準はなんだ？

エスパーで答えると、注文トランザクション内に注文時単価を持たせておくかな、自分の場合。
日々単価の上下がある商品だと再計算の度に商品マスタの有効期間まで参照するのは、
コストが高い気がします。

twitterはツイートをファボることができますが
ファボられ数はDBにどう持たせるのがいいのでしょうか
ユーザーとtweetを結ぶuser_favoriteみたいな中間テーブルを作ればいいと思ったのですが
tweetを表示するごとにfavorite数のカウントするのがけっこう負担になる気がします
tweetテーブルにもfavoriteカラムを作ってファボるたびに両方のテーブルを更新するのがいいんでしょうか
それだとトランザクションしなくちゃいけないのでファボるときの負荷が大きくなりそうです

どうするのが正解なのか教えていただきたいです

>>469
少々リスクのある方法だけど
・現行商品マスタの内実を販売価格テーブルとし、名称はそのままに販売時期列を追加
・商品マスタは別途新規作成し、販売価格テーブルが参照するUID列追加
多分これが最も工数かからない手　商品名変更やらをどうするかはそっちの都合で決めてくれ

>>473
ふぁぼるってなんのことやねんと思ったら被お気に入り数のことか
正しくインデックス貼られてれば集計はそこまで遅くはない
本家みたいな超大規模ならギリギリチューニング必要だが普通はそこまで考えなくて良い

>>474
ありがとうございます！
user_favoriteテーブルだけつくって集計するようにします
迷っていたので本当に助かりました

すみません、ちょっと相談です。
どこからも参照されないような、意味のないサロゲートキーは張るべきではないって指摘したら
全てのテーブルにサロゲートキー張るのが定石ですよ！って返事が来た。
そんな定石は聞いたことないし、むしろ何でもID(IDリクワイアド)って世間一般的には否定されてなかったっけ？

テーブルA
[ID(サロゲートキー)]
[Part Number]

テーブルB
[ID(サロゲートキー)]
[Product Name]

テーブルC
A.[ID]
B.[ID]

CがA,Bの組み合わせでユニークなとき、Cにサロゲートキーを持つ意味って何なんでしょう？
複合キーはバグの温床でそれを排除できる。 将来の変更に柔軟に対応できる。
といわれても意味が分からない。このケースにおいて複合キーにバグの温床となる要素があるんだろうか…？
今後のテーブル構造の変更に柔軟に対応できる要素があるんだろうか…？
いったいどんな変更を想定しているんだろうか…？

>全てのテーブルにサロゲートキー張るのが定石ですよ
そう言う主張をする人はいる
複合キーはORマッパーと相性わるい事だけは認める

バグの温床ってのは聞いたことがない

テーブル構造の変更については、たとえばテーブルCにおいて、A+Bでのユニーク保障が無くなったりしても平気とか
テーブル構造の変更じゃなくて、要件変更に対してDB設計（つかテーブルレイアウト）を変更しなくて済むだけだろうと思う
要件定義が甘い設計者の言い訳なんじゃないかとは思うんだがな

>全てのテーブルにサロゲートキー張るのが定石ですよ！
Rails界とそのクローン界での常識か

Webアプリ（非Rails）作ってると、idあると便利な場合が多い。Backbone.jsとか。

全部にIDとかアホかとは思うが、複合キーもチューニング上の問題出ることあるし場合による
複合2番目以降のみを検索条件にするとインデックスが機能しなくなるRDBあったりとか
そういう時はキーバラすしかないが、そうするとユニーク保証取るために別途PK必要になる

>>480
キーとインデックスは別物ですよ
その場合は２番目（必要なら＋１番目）の項目に別途インデックス張るもんでしょ

>>481
それMySQLの常識、他の非常識

>>482
大体のDBでは>>481だろ

少なくともOracleとSQLServerではPK作るとインデックスも勝手に作られるはずだが
別に列とインデックスは1:1でなくてもいいから複合PKに更にインデックス貼ることは可能だが気色悪い

>>484
気色悪いとか関係なしに、col1+col2の複合キーのテーブルでcol2で検索することがあるなら、
col2にインデックスを張るのを検討すべきじゃないのか？

>>485
複合インデックスには全部の分が含まれてるんだから無駄じゃん
PKからインデックス引っ剥がせるんなら別だが

>>486
どうして無駄なのかな？
col1+col2のインデックスがあったら、col2のみで検索するときにも使われると思ってる？

>>487
インデックス更新コストってもんがあるじゃん
それと使う使わないって話ならcol2のみ検索条件でも使われはする
ただSQLServerの場合はIndexScanになって期待通りの性能にならん

>>488
> ただSQLServerの場合はIndexScanになって期待通りの性能にならん
手元にSQLServerが無いので試せないが、普通はseq scanになる。これはインデックスの仕組み上当然のこと。

> インデックス更新コストってもんがあるじゃん
もちろん、seq scanになっても全く問題ない場合はインデックスは不要。
ただし、seq scanになるとパフォーマンス上多大な影響が出るような場合は、col2にもインデックスを張るのを検討する必要がある。

col1を条件に含めないと、PKのインデックスは使われないと思ってたが。
SQLServerではそうでもないのか？

>>489
実験した結果IndexScanなのよね、SQLServer2012Expressで確認
まあそれはともかく
どこのチューニング指南見ても「インデックスは最小限に」と書いてあるわけさ
大抵インデックスはメモリ大喰らいでキャッシュ他を圧迫するから
んでPKつかUNIQUE制約はインデックスで実現してるRDBが多い、故に大体不可分
だから結局のところ「複合PK使うんじゃねえ」とも書いてあるわけさねw>チューニング指南
まあ少量データで気にならん、それよりユニーク保証のが重要だってケースもあるから場合によるが

>>490
SQLServerのPKはなんも考えないとクラスタ化インデックスになる
多分その関係

複数列インデックスで、その一部特に後ろの部分だけを使えないのは
有名どころだとMySQLだけ、>>482はそれをいいたいんだろ

複数列インデックスの後ろの部分の利用は
独自で張ったインデックスより遅いから要注意

段々話がずれてきた気がする。
不要なインデックスを作れと言っているわけではない。
また、複合PKを使うべきかどうかは、検索要件とはあまり関係ない気がする。（そして、ここでこれに関して議論する気はない）

col1+col2がPKのとき、col2のみで検索するとPKのインデックスが使われない場合が多いから（少なくともPostgreSQLはそう）、
それで困るのならcol2にもインデックスを張るのを検討しましょうということ。

>>493
> 複数列インデックスで、その一部特に後ろの部分だけを使えないのは
> 有名どころだとMySQLだけ

そんなことない。上にも書いたとおりPostgreSQLは使われない。
Oracleも9までは使われなかった。10以降は知らない。

>>494
PostgreSQLはプランナが許せば使われる。
Oracleも然り。

検索すれば直ぐ出る

http://gihyo.jp/dev/feature/01/lets-postgresql/0005

mysql以外は複数列インデックスで順不同で使えるのは常識だぞ

>>496
使われないよ

>>497
> mysql以外は複数列インデックスで順不同で使えるのは常識だぞ

手元にある複数の複合PKのいくつかのテーブルで試した結果の>>494なんだが。
そこにあるとおり、Bitmap scanになることもあるんだろうが、ならない場合が多い。

いずれにしても、実行計画みないとどうなるかわからんよ

>>494
別にずれてないよ?
複合PKはチューニングに問題あるから大規模になること分かってる場合とかは
設計段階で可能な限り排除すべきって話(>>480)
PKは大抵もれなくインデックス作るから、その上に更にインデックス貼っつけるとかイカんでしょ

なんでインデックス使うよ派も使わないよ派も公式のドキュメントを示さないのか…
それはともかく、>>476のインデックスではなくキーについての質問に答えてあげようじゃないか

実行計画というより、複合PKの後ろのユニーク度で決まるよ
ユニークであればあるだけ使われない

試したって言ってる奴、インデックス利用をちゃんと強制してる？

みんな言ってること一緒だから大丈夫

複合キーのインデックスが複合2番目以降の検索で利用できるかは
・コスト次第で使える
SQLServer Oracle PostgreSQL
・使えない
MySQL

この利用は、1番目の検索より遅いので
必要に応じて、更新コストと比較しつつインデックスの作成を行えばよい

一人変な奴が混じってるな。

>>480
>そういう時はキーバラすしかないが、
別にばらす必要は無い。別途インデックスを作れば良い。

>そうするとユニーク保証取るために別途PK必要になる
ばらさないので別途PKは必要にならない。

>>484
>別に列とインデックスは1:1でなくてもいいから複合PKに更にインデックス貼ることは可能だが気色悪い
別に気色悪くない。必要なら作るだけ。

>>486
>PKからインデックス引っ剥がせるんなら別だが
何をいってるのかわからない。

>>476
A対Bの関係を表すだけならばサロゲートキーなんて要らんね
Cを更に参照するテーブルがある、追加する可能性があるのならまた別だけど

>>502
ほんじゃあまあお答えしてみようか>>476
バグがバカスカ発生するかはともかく、キーに相互依存性があるので仕様変更に弱いのは事実
桁数増やせとかはマシな方で、整数型が小数ありになったりだの唐突に日付型になったりとかもうね
最初からサロゲートキーで結合しとけば、変更は当該列直接参照している箇所だけで済む
ただしデメリットとして何回か言ってるようにユニーク保証をどうするかを別途考えなければならない
あと直接コンソールで覗く時に何の行かいちいち結合しないと分からんてのもウザい
まあこんなとこ?

おっとすまん、AB両方共サロゲートキーだったか
とするとメリットなんだろうなあ
パッとは思いつかないな

無論サロゲートであれナチュラルであれ、第2列以降の検索チューニングがメンドくさくなるのは
このスレでgdってるの見てもわかってもらえると思う
ただ、一般論ぽく全部に付ける「べき」ってほど強い理由は思いつかないな

とりあえず、キーとインデックスは少なくとも概念上は別物だって理解してくれ
多くのDBMSで主キー実装はユニークインデックス(+NOT NULL制約)が作成されるが、あくまでもキーとインデックスは別物だぞ

設計概念が美しければ性能どうでもいいなんて仏様のようなお客さんがいたらぜひ紹介してください
現実には性能込みでの設計さ

>>512
君は落ち着いて>>476を読もう
パフォーマンスでもインデックスの話でもないぞ

>>513
レスポンスが帰ってこないor遅いのもバグと言われますが何か

>>476
サロゲートキーA,Bの桁数・型が不変だと何時から錯覚していた？
てのは冗談にしても一意性さえ破れなければ論理性問題が出るとは思えない。
逆に一意でなくなるなら全部の設計窓から投げ捨てるくらいの大問題になるだろ。

>てのは冗談にしても一意性さえ破れなければ論理性問題が出るとは思えない。
>逆に一意でなくなるなら全部の設計窓から投げ捨てるくらいの大問題になるだろ。

そんなケースだと、Cにサロゲートキー設定しても意味ないね。
Cのサロゲートキーの役割自体が変わっちゃうわけだから、関係全部見直しだわ。

>>507
サロゲキーが無い場合、update/delete時に毎回where a_id=xxx and b_id=xxxとする必要がある。
AもBもサロゲキーで操作できるのに、Cだけできないと不便。

>>517
Cのサロゲートキーをどうやって知るかが問題だぞ

>>518
ちょっと意味わかんない。
selectしたときに持ってこれるじゃん。

>>519
どうやってselectするの？

>>520
え、どうやってって、AとBの関連を取得するときにはCも参照するはずだから、そのときC.idを持ってくればいいじゃん。

517は言い方が悪い
A→C→BまたはB→C→Aなjoinは普通に有り得るが、いきなりCから始めて何を検索するのか
サロゲートキーの値そのものに意味はないんだから

>>522
> いきなりCから始めて何を検索するのか
いや、それも意味分からん。
> A→C→BまたはB→C→Aなjoin
をしたときに、C.idも取得しとけば、update/delete時にidだけで指定できるじゃん。

あ、なんとなく言われてることが分かった気がする。
俺が言いたいのは、クライアントアプリレイヤーの話ね。
AとBの関連を取得して表示したときに、ある関連を削除したいときなんかの話。

まあこれ複合キーvsサロゲキーにも同じ事が言えるんだけどね。
update/deleteをするときに、テーブル毎に何を指定しないといけないかが変わるより、全部idだと便利だねってことで。

サロゲキー万歳。

>>524
updateすることってあるか？
deleteするときに関連を確認する必要あるか？

ここらが謎

>>525
> updateすることってあるか？
入力間違いしたときは、updateしたいよね。
delete->insertでもいいけど。

> deleteするときに関連を確認する必要あるか？
「関連を確認」ってどういうこと？
AとBの関連を取り消すには、delete from c where ...ってやるよね？確認とか必要なくね？

>>526
手入力？？入力間違いって

「関連を確認」ってCをselectする必要がないってことだよ

>>527
> 手入力？？入力間違いって
いやだからクライアントアプリレイヤーの話って言ってるじゃん。
人が関連づけを登録する場合、間違える場合もあるよね。

> 「関連を確認」ってCをselectする必要がないってことだよ
deleteするときにはselectはしないけど。

AとBの「ある行の関連性だけ」を解除するなんてケース存在するか?
間にC挟んでるだけの外部キーだろこれ
Cから除去する=AとBの該当行もdeleteが普通
それとどうやってCの不要行特定するかったらAからかBからかしかないだろ
Cだけ見て削除対象が判別できるのはエスパーだけだ

>>528
間違えてもdelete->insertっしょ。クライアントアプリならなおさら

要はさ、C.idを入手する機会がないんだよ。

書籍(books)と著者(authors)、そして書籍毎の著者テーブル(book_authors)がある。
books: id, book_name, ...
authors: id, author_name, ...
book_authors: book_id, author_id
で、これらを管理するアプリがある。

> AとBの「ある行の関連性だけ」を解除するなんてケース存在するか?
あるよ。例：book_authorsからレコードを削除する（登録間違い）

> Cから除去する=AとBの該当行もdeleteが普通
book_authorsの行を削除しても、booksもauthorsも削除しないよね。

> 間違えてもdelete->insertっしょ。クライアントアプリならなおさら
それはどういうアプリかによるよ。

> 要はさ、C.idを入手する機会がないんだよ。
いやだから何度も言うように、「書籍と著者一覧」を表示する時に、book_authorsにidがあればそれも持ってくればいいだけでしょ。

>>531が分かりやすい具体例付きで、
正解かつベストアンサーだね

>>531
>いやだから何度も言うように、「書籍と著者一覧」を表示する時に、book_authorsにidがあればそれも持ってくればいいだけでしょ。
やらんでしょ。表示時と、実行時は別でしょ。どうやってC.idの正当性確認するの？

>>533
> やらんでしょ。表示時と、実行時は別でしょ。

例えば「全書籍の著者付き一覧」を表示する時、
select books.book_name, authors.author_name
　from book_authors
　join books on books.id = ba.book_id
　join authors on authors.id = ba.author_id
　order by 1,2
とかやってクライアントに戻すよね。
このとき、
> select books.book_name, authors.author_name
のかわりに、
> select books.book_name, authors.author_name, book_authors.id
ってやるってこと。

> どうやってC.idの正当性確認するの？
正当性が危ぶまれることはどこにもないけど。
あ、前提としてサロゲキーはRDBMSのidentifyとかserialとかsequenceとか使うという前提ね。

>>534
C.idを返したとして、それをクライアントアプリが正しいものを返す保証は？

これで最後にするけど（まだ俺に質問したいのならごめんね。もうこの話題しないから）、
連関エンティティにサロゲキーを追加するのは、あくまでもクライアントアプリの都合であって、
RDBの関連モデルとかの話じゃ無いから。
サロゲキーあったら楽なことあるよってことで。

じゃ、この話題終わり。

>>535
最後の回答。
そんなこと言い始めたら、books.idもauthors.idも何もかも信頼できないよね。

これでホントに終わり。

見てておもろいな、>>531はセキュリティ感覚0。無縁の世界の人だろう
>>529は見当違い

>>537
そのレベルなら仕方ない。普通は確認するよ。

>>538
なんだ、C.idが信頼できるかどうかってのがセキュリティの話なら最初からそう言え。
その話はこのスレで話すべき事じゃないね。

ほんとおもろいな
C.idを使ってdeleteすることはないってのが結論か

>>540
セキュリティだけじゃないよ
設計の話ではないから板違いだな。>>517のときからな

ORMの話題とか今までもあったじゃん・・・

俺もC.idは入れる派だな。

今日も変なのが一人混じってたな。
こいつ何が目的で設計スレにレスしてんだろうか。

全部で4人か5人いたがどいつだろ。
C.idを作るか作らないかと別の話だったのがうざい。

>>531は逃げたようだが1つだけ言わせてもらう
そのキー群サロゲートじゃなく自然キーだよ
代理キーの値に意味は無く、同じ行にある自然キーを見ないと何の行か判らない
Cに自然キーは存在しない前提を都合で崩さんでくれ

>>547
お前だよ、変な奴は。

>>547
クライアントアプリとしては設計欠陥だし
理解度が低いのが明確だからほっとこうよ

DB設計の話とは絡まんし
あれでサロゲートキーを悪にされても困る

>>548
どれが同一人物だと思ってるの？

>>547
何言ってるんだ？
>>476でサロゲートキーだと書かれてるだろ。
> テーブルA
> [ID(サロゲートキー)]
> テーブルB
> [ID(サロゲートキー)]

>>549
まあな

Cに自然キーが存在しない限り、Cにサロゲートキーを付与しても参照する場面はない
単にこれだけの話

>>550
>>547は>>522と同一人物だろ。
> いきなりCから始めて何を検索するのか
関係を取得するなら、Cから検索するしかないだろ。
もし別人なら、変な奴は一人じゃ無くて二人だ。

>>552
お前も同一人物だろ。

>>552
C.idというサロゲートキーがあれば、MVCフレームワークなどとの親和性が高くなるという話だろ。
単にこれだけの話なのに。

MVCというよりORMとの親和性だね。

>>553
で?
クライアントアプリからどうやってCに到達させる気だ?
まさかいきなりCのサロゲートキー手入力させるんじゃあるまいな?

>>555
その親和性が高くなるMVCフレームワークって何？

少なくともRubyのAcrtiveRecordでは、
単なる関連テーブルであるCにサロゲートキーは不要

そのプロジェクト開発で採用したORMに制限があるという条件があるなら、
最初からサロゲートキーいらなくね？なんて疑問投げかけてこないだろ。
現時点で採用していない、今後も採用する予定がない、まだそれすら検討していないのどれかだな

つまり>>555,556は、
DB設計に無知なおバカさんの知ったかぶりというわけだ....

酷いありさまだな。
>>517で終わってる話じゃないの。

>>517のためだけに、DB設計上は必要とされない
サロゲートキーをCに追加すべきとでも言いたいん？

>>561
操作する機会がないのはその後のログでよくわかったよ

>>561
じゃあちょっと>>517と>>531の代わりにwhereに何書くかちょっと述べてみてくれ
アプリ視点でな

ORMから見るとObjectとしてはCって存在しないんよね

>>564
C.id がない場合のクライアント画面では、A.id B.id を取得しておく
C.id がある場合のクライアント画面では、C.id を取得しておく
これでwhere句書けるでしょ。

なので、>>517の主張は、C.idがないとA.id B.idの二つを使わないといけないから不便ってことよね。
何もない状態で、C.idが取得できないから困るだろって主張してる人の気持ちはまだ理解できてない。

>>566
で?
アプリ画面には一体何が出てるんですかー?
C.idをナマで出すんですかー?

>>567
何の話？セキュリティ？

>>567
C.id がない場合、A.id B.id および、A B の表示させたい情報
C.id がある場合、C.id および A B の表示させたい情報

てか、なにをこじらせたらそんなに混乱するんだ？

>>566
select C.id as yyy from C where A.id = xxx and B.id = xxx
delete from C where C.id = yyy

これ設計上分離できんよ？トランザクションでセットにするしかない

AかBを基点にした画面だと、whereにはAとBのIDが必用
AやBから、CのIDがわからないんだから
でも、Cを基点とした画面や、Cを参照する別のテーブルがあるなら
そこでの削除キーとしてCのIDは使える

>どこからも参照されないような、意味のないサロゲートキーは張るべきではないって指摘したら
つまり、このケースでは意味がないってことだ

>>569
>C.id がある場合、C.id および A B の表示させたい情報
この時点でA.idもB.idも取得してんのにC.id何しにいるん?
C.idのみをwhereに書く場面は結局無いの?

>>571
>Cを参照する別のテーブル
話し広げすぎ

>>572
今って、関連情報のみを操作するクライアントの話をしてんだよね？
後者だと、A.id B.id はクライアントに不要。

ああごめん、更新系を考えたらいるね。

C.idがあれば、それを使うことで少しだけ便利になる場面がある。それだけだと思うんだけどなぁ。
C.idがあろうがなかろうが機能は実現できるはずだし、俺はないほうが好み(どうでもいいか

たまにさ業務系にあるけど
Cのテーブル完全にロックして
Cの一覧出して削除するならC.idでいいんじゃないか？

C.idがあればA.idとB.idは解らなくてもOK
A.idとB.idがあればC.idは解らなくてもOK

結局これ以上の論議してないんだがお前ら

Cの変更、削除って
あるAとあるBの関係を変更したい
または削除したいってときに使うんだよな？

>C.idがあればA.idとB.idは解らなくてもOK
A⇒C⇒B,B⇒C⇒Aの経路ではA.id,B.idが必須だ

>>577
>C.idがあればA.idとB.idは解らなくてもOK
これが正しいのかどうかで論議が起きてるんじゃないのか？

>>580
いや、それが正しいかどうかじゃなくて、その前提なのに
C.id作るのが常識でしょって言うわれたけどどうなの？っていうのが元の質問だが

Cにはサロゲートキーしかないってのにどうやったら目的の行であると特定できるんだ?
意味を持つのは自然キーだけだぞ?

>>574
で?
C.id見るだけで関連付け正しいかどうか判んの?
AやらBにある情報出さないで判別できんの?

>>582
少なくとも行の特定はできる
その行が目的の行かどうかは、自然キーだろうと何だろうと判断できない
それは行の中身を見て人間が判断することだ

>>584
その人間様が判断するためにAまたはBの情報が常に必要だっつー話を延々してる訳だが
そろそろ分かっていただけませんかね

そしてAorBの情報が必須=アプリから検索かけるのは常にA.idまたはB.idとなり、C.idの出番なんかない
単なる死に列だ

>>585
だから、正確にはAまたはBの行を特定することが必要なだけで、自然キーとかサロゲートとか関係ないだろ、って言ってるんだが
それ以外は俺は否定してないぞ。他の発言は俺じゃない

>>586
C.idが無いと実現できない処理があるとか主張してる人いるか？
C.idが必須ではないのはみんな分かってる前提だとおもうが

だよね、あるとたまに便利な場合があるねって程度で。

>>589
kwsk

どんだけループさせたら気が済むんだ

たとえば一覧表示からの削除機能ならC.idだけでいいんじゃないの。

>>592
それは、C.idだけじゃ目的の内容かどうかわからないだろって言い出す人がいるぞ
そう言う場合は
where A.id=xx and B.id=yy と書くところを
where C.id=zz と書くだけで済む
と言っておけ

>>592
絞込とかソートどうすんだよ

>>594
C.idを指定してるんだから、Cの行は特定されている(=絞りこまれてる)
ソートって何をどうソートする事をイメージしてるの？
AやBの項目でソートするなら、C.idにあんまり意味ないから使う必要ないでしょ

一覧表示してから、削除するまで
Cテーブルが変わらないならC.idでいいんじゃないか？

Cテーブルのupdateを禁止してdelete,insertのみにし
一覧表示してから、削除するとして
あくまでCを消したいのであって
あるAとあるBの関係を消したいわけじゃないならいいんじゃないか？

C.idで消すことはありえるけど、前提が難しい。

>>594
ユーザーが画面でレコードを1件1件選択する場合には有効だが
使われる場所がもの凄く限定的。
UI次第では全く使われない可能性も有る。

ぶっちゃえ、今回のケースだと、delete/Updateでメリットといえる
程の価値はないと思うが。条件指定のバッファサイズが僅かに縮まる
可能性がある程度。

C.idの有用性が薄いのはみんな解ってるだろ
そのうえでC.id作るのが常識ですよって言われたけどどうよって話じゃなかったのか

>>598
この不毛な話は>>517の話から生まれている。
この話はトランザクション単位がどこまで必要か等々の要件次第であって答えは出ない。

>この話はトランザクション単位がどこまで必要か等々の要件次第であって答えは出ない。
要件を考えてサロゲートキーを設定するのならわかるんだけどなー。
要件も考えずにとりあえず全設定という常識は理解できないわー。

>>599
Cが(AとBとのm:n対応を表現する)単になる関連テーブルであるなら、
DB設計上でCの列にサロゲートキーは不要だ
セキュリティ、ORMときて今度はトランザクションとか言い始めているが、
サロゲートキーが不要である事実は変わらない

DB設計も知らぬのに、これ以上の屁理屈は恥ずかしいよ

サロゲートキーの有用性が要件で決まるとは思えんが
トランザクション単位とサロゲートキーの用不用がどう関係するのか説明してくれ

>>601
>>517についての話だけであって、サロゲートキーの必要性なんてしらねぇよ

>>602
サロゲートキーの有用性ではなくて
関連テーブルCをC.idで消せるのかどうかだけだ

議論の内容が各人全然かみ合ってないように見える

>>603
おれはこの話というのは、サロゲートキーの有用性の話だと思ってたんだが
お前の言う「この話」と「トランザクション単位」って何？

>>605
有用性の話ともいえるな。わるかった。

>>596あたりがわかりやすい。
要件前提がないとC.idは使い物にならないが俺の意見

>>605
トランザクション単位は例えば>>570が書いてあるのがそう
> select C.id as yyy from C where A.id = xxx and B.id = xxx
> delete from C where C.id = yyy

>>606
それ、C.idのケースにおけるサロゲートキー有用性の話だと思うが

>>606
C.idが必須ではないし、有用性がうすい
それはその通り

で、トランザクション単位って何？
アプリがキーを保持してる期間か？それなら代理キーだろうと自然キーだろうと関係ないわな
代理キーなら書き換えるけど自然キーなら書き換えないとか言うなよ

>>607
意味がわからない
その２文を１トランザクションで流すこともあれば
別のトランザクションで流す事もあるだろう

で、そのトランザクション単位がどうなれば、サロゲートキーの有用性はどうなるの？

>>610 >>609
>>596が書いてあることが全て

>>611
>一覧表示してから、削除するまで
がトランザクション単位だとして
>Cテーブルが変わらないならC.idでいいんじゃないか？
A.idとB.idでも良いよね

トランザクション単位関係ないでしょ

>>595
Cの編集画面UIちょっとでも想像すれば容易に分かる
Cを絞り込む上でAとBの「両方」が絶対に必要になるんだよ
Cの内容全垂れ流しのUIなんかお客さんに持ってったら殴られるわ

DB設計鉄の掟
使い道のないカラム追加する奴は死刑

>>612
A.idとB.idでよいよ
C.idが使える可能性の話だけだ。

間違えられちゃ困るからかいとくけど
俺は、Cテーブルにサロゲートキーなんて振らない。必要ではないから
その上での話を書いてるだけ

極論を言えば、サロゲートキーが「必要」な事なんて、ＤＢ設計段階ではあり得ないんだが
アプリ作成のためのフレームワーク等が複合キーをサポートしないとか、ＤＢ設計以外の理由で必要になる事はあったとしても

>>615
もともとC.idの有用性の話だから、そんなことはわかってる
それとトランザクション単位がどう関係するのか？ってきいてるんだが

>>618
単純に、A.idとB.idからC.idを手に入れた後
C.idを利用して何か(deleteとかupdateとかな)をするまでの間に
割り込まれたらアウトだろって意味だが

>>596の内容だよ

>>619
A.idがかわらなければいいんだが。
まぁ、通常の運用がなされれば、A.idが変更されることはないはずなんだけどね。
C.idが変わることがないとは言ってないよ。(そういう勘違いをする人が今の流れには多すぎる)

>>599のトランザクションの話が理解されないのってこれだろ。

太郎が A.id = 1 B.id = 1 C.id = 1 のレコードを抽出、画面表示
次郎が A.id = 1 B.id = 1 を削除
三郎が A.id = 1 B.id = 1 を追加。このとき、C.id = 2(default seqなどで採番)

こういう状態になった時に、太郎が、A.id B.id をもとに削除するなら正しく削除されるけど、
C.idじゃ無理って話だろ。

じゃあ、太郎が抽出して、何らかの作業を終えるまでロックし続けるの？
それはあまりにもばかげてるよね？って話だと思うよ。

Cの情報をクライアントに流すのがありえないっていってる人はさらに別の話をしてると思う。

>>621はidをシリアル型で宣言できないバカなの？

まーたすぐ話がずれる。serialは内部的にsequence作るでしょ

ならば言い換えよう

>>621はC.idはseqを作る頭はあっても、A.idとB.idにseqを作る頭の無いバカなの？

>>624
多分根本間違えてるぞ

え、A Bテーブルにinsertしてるように見えたの？
こんなこといいたくないけど、馬鹿でしょ

>>621
それはアプリが（DBからみて）複数トランザクションで更新する話な
トランザクション単位ってのがDBのトランザクションを超えてアプリで整合性保障する必要がある範囲だって言うならその通りだな

それはDBとしてのトランザクションを超える範囲でキーを保持しても保障しません、って事
そのキーが自然キーか代理キーかの話ではない（状況的に自然キーの方が起こりにくいと言う事はあるが）

で、その場合はアプリの正しい作りとしては、C.idを使いたければ最新のC.idを取得し直す必要があるってだけの話
AもBもそのままでCだけ再作成される状況にどれだけ現実味があるかはしらんが
そもそもC.idが使える（有用）の話なのに、使っちゃいけない状況を出してどうするんだよ

＜チラシの裏＞
有用性ほとんど感じない。全くないとは言わないけど。
あっても雀の涙程度。生産性も変わらない。
その程度でテーブルに項目追加とか信じられない。
極力不要な情報は省けって思う。

サロゲートキーは一切禁止
全部のテーブルにサロゲートキー

どっち選ぶ？って聞かれたら俺なら後者だな

>>627
>C.idを使いたければ最新のC.idを取得し直す必要があるってだけの話
さすが、わかってるね
これが>>517-520の話だろ、最新のC.idを取らなければいけないのに、不便もクソもない

>そもそもC.idが使える（有用）の話なのに、使っちゃいけない状況を出してどうするんだよ
C.idを使えるパターンが>>596しかないんだよ

もういいだろCにおいてサロゲートキーの有用性はほぼない。>>517は不便もクソもない

>>629
その選択を迫ってきた人間には設計にもコードにも触らせない

その選択肢から答えを選んでしまうような人間も触らせるべきではない

まあなんだよ
617の御説ごもっともなんだが事実上設計段階からの制約ってのもある
先に言っとくがCにサロゲートキー付けるなんて馬鹿な話とは全く別個のこと
一番よくあるのはファイル名だね RDBの多くがPK長に制限あるからキーとして登録は実質無理
それとキーを可変にしたいって要求も意外とある
エクセル表みたいに座標で一意になるようなのはサロゲートあった方が圧倒的にやりやすい
だからまあ、サロゲートキー使う場合ってのは
1.DB制限により自然キーを指定することが出来ない
2.キーが実質的に可変(将来の仕様変更も含む)
この2つに限られるんでなかろうか
Cのサロゲートキーはどっちでもないから要らない子

>>633
PK長でファイル名が入らない可能性があるのってMysql以外はあまり知らんな
1データブロックに入りきれないといけないってのは良くある

他どんなDB？

トリガの一般的な事で質問させてください、社内の開発部門の人と打ち合わせしてて、昔の単純なクラサバのアプリだと
トリガは良く使われてたけど
今時の多階層のアプリだとそんなものは
使いませんよって言ってたんですが本当ですか?トリガだと簡単にできそうな事を
登録時にいろんな画面の複数箇所に
同じ変換処理を行う改修が必要と説明されてます。

既存システムの改修なら既存の流儀に従うべきだろ
そこだけトリガとか変なことやると後でまた別の人が担当になったときに
「誰だよこんなとこにトリガ仕込んだやつは！」とか言われちゃうよ
今から一から開発するシステムなら自分の流儀でやってもいいけどね

>>635
プレゼンテーションやビジネスロジックの変更をデータベースで吸収する
それって層を分ける意味があるかな？

何やるかによるよなー。どの層でやるかにもよるよなー、一番表でやるって読める

>>634
ORACLEとSQLSERVERは900バイト以内という制限がある
ファイル名はフォルダも込みでないと一意にならないから意外と足りなくなる
まあアプリで制限すりゃいいったらいいが、多階層でなければならない案件も多い
昔アプリならファイル名MAXが265文字(確か)だからまず起こらないが今どきはな
それとURLなんかもエンコードされてるのそのまんまだとド長くなるから不安

>>635
トリガはメンテ時に七面倒なことになるの結構あるから運用サイドから嫌われてる印象
あとトランザクションでもなんか面倒な副作用あったような

DBMS実装による制約と論理設計はまあ基本別物だとは思うが

どの段階での制約かってのはあるが
実装の制約がそのまま設計時の制約であるなら、ORマッパーの都合で
全テーブルにID振ってくれって言うのも設計時の制約だと

先の例のCはオブジェクトとしてマップしないから要らないとか言う話もあったけど
特殊な例外を判定して除外するぐらいなら全部そのルールでやってくれという話はまあ了承できる範囲

あんま実装都合に振り回されんのも考えもんだけどなー
コードファースト()じゃ複合キーサポートしてませーんｼﾞｮｶﾞｲｼﾞｮｶﾞｲ
とか言われたらニヤケ顔に全力ストレートぶち込みたくなる
いや言われたことないけど

>>633
キーが概念上のタプルで表現される場合、DB設計としてサロゲートキーは使用すべきでない
たとえばエクセル表みたいに "(列番号, 行番号)" という座標で一意になるのであれば、
DB設計上ではこの自然キーの対(つい)を複合キーとして扱うのが単純かつ好ましく、
わざわざサロゲートキーの列を追加して設計を複雑にさせるのは愚かと言わざるをえない

>>643
まあ実装時(あるいは詳細設計段階)で適宜カラム追加が認められるようなとこならいいんだが なかなか…ね

>>639
SQLサーバーは900バイト以内
Oracleは今はデータブロック
8iまでは758バイトじゃなかったけ

>>643
論理設計としてはそうでも実装都合でなかなかそうはいかないって話ですよ

>>633
> 2.キーが実質的に可変(将来の仕様変更も含む)
これを保証するのがめんどくさい場面は多いね
Cの場合は別テーブルのサロゲートキーだから保証できてはいるが

なので、サロゲートキーを使わないでもいい場面というのは、
・別テーブルのサロゲートキーをキーにできる場合
だけではないだろうか

俺個人は今回のケースに限らず、効果の薄いサロゲ使いまくりの奴とは組みたくないな
たとえば製品シリアル番号や社員番号、企業コードみたいに、運用キー1個で必ずユニークが保証され、
運用での変更が許容されないケースでも「サロゲ追加が常識ッスよ！」なんてドヤ顔されたらぶん殴りたくなるわ

俺は代理キーをサロゲと言うやつとは組みたくないな

>>649
おれも代理キーをサロゲという奴とは組みたくない。
けど代理キーは結構でてるけど、それをサロゲって言ってる奴いるか？
全部代替キーだと思うが

>>650
>>648

話の内容がどんどん低レベルになっててワロタ
ネタが尽きたってことだな

>>648
シリアル番号や社員番号はデータベース以外の場所でも使われるから、
そっちの要件との兼ね合いで「短めにしてくれ」とか「再利用したい」とか要件が変更される可能性もある
サロゲートキーなら論理的にその可能性は起きない

>>653
製品シリアル番号や社員番号、企業コードといったコード体系は、
企業のビジネスルールを間接的に表現するものだから、
（企業統合/合併/吸収といったごく稀な事態を除けば、）
企業のコード体系が要件の兼ね合いとやらでフラフラと変更されることはない

つまり、コード体系変更対応の柔軟性は、サローゲートキー導入の正当化理由として誤り

>>652
昔から畳の上の水練をしてる人しか討論してませんよ

thxそのあたりの理由が有るのでしょうね、理解しました。

>>654
> （企業統合/合併/吸収といったごく稀な事態を除けば、）

ここ 15年で 3回も合併した俺に言わせりゃ希でもなんでもないんだが (w

製品譲渡とかもあるから、それなりの対応は考慮すべきだよ。

>>654
合併吸収が稀って、今時大企業くらいだろ。

>>645
あれそうだったか
昔互換調べた時に同じ長さなんだーと思った記憶があってな

自由度を持たせるにしても、縛りを入れるべきところはあるんじゃないか？

>>654
お前が言ってるのは、コード体系は頻繁には変更されない　って事
コード体系対応の柔軟性ってのは、コード体系が変更されたときにどうか　って事

違う前提で話を比べられてもなぁ

吸収合併とかあったら、どっちにしろデータ統合で見直しかかるかコンバート入るだろ

>>661
>お前が言ってるのは、コード体系は頻繁には変更されない　って事

その通り

>コード体系対応の柔軟性ってのは、コード体系が変更されたときにどうか　って事

その通りだが、その変更頻度がどれだけあるのか？という事
たとえば>>657は15年で3回だから5年に1回だけど、
5年もの未来の変更を想定して「DB設計上は無駄なサロゲートキー」を作り込んでおくことは、
はたして有意義なのか？

そして>>662が指摘しているように、吸収合併に伴うコード体系の仕様変更では
大きな改修作業(=コスト)が必要になる
その時に「DB設計上は無駄なサロゲートキー」を作り込んでおくことは、はたして有意義なのか？
サロゲートキーにしておけばコード体系の変更に対応できる、という考え(>>653)は幻想だ

先週末からの連関エンティティの話題がさっぱりわからない。
例えばこれ。
>>621
> 太郎が A.id = 1 B.id = 1 C.id = 1 のレコードを抽出、画面表示
> 次郎が A.id = 1 B.id = 1 を削除
> 三郎が A.id = 1 B.id = 1 を追加。このとき、C.id = 2(default seqなどで採番)
>
> こういう状態になった時に、太郎が、A.id B.id をもとに削除するなら正しく削除されるけど、
> C.idじゃ無理って話だろ。

疑問その1:
次郎が A.id = 1 B.id = 1 を削除したとき、C:(a_id=1, b_id=1)は残ってるのか？

疑問その2:
三郎が A.id = 1 B.id = 1 を追加というのは、サロゲートキーの値を使い回すということか？

疑問その3:
> このとき、C.id = 2(default seqなどで採番)
これの意味がわからない。三郎があらたにC:(a_id=1, b_id=1)をInsertしたということか？

つまり、
> こういう状態
というのがさっぱりわからない。

>>664
前後読まないとわからんよ
Cテーブルのレコードを表示して削除することにおける
C.idの利用の問題点のやり取りだからな

>>621は
「Cテーブルの」と「のレコード」をつければ理解できるはず
> 太郎が Cテーブルの A.id = 1 B.id = 1 C.id = 1 のレコードを抽出、画面表示
> 次郎が Cテーブルの A.id = 1 B.id = 1 のレコードを削除
> 三郎が Cテーブルの A.id = 1 B.id = 1 のレコードを追加。このとき、C.id = 2(default seqなどで採番)

疑問その1: 残ってない
疑問その2: C.idは使いまわさない
疑問その3: そのとおり
こういう状態: 太郎次郎三郎と処理された後ってことだろ

>>665
> 前後読まないとわからんよ
全部読むことは読んだが、ハテナマークだらけ。

> 疑問その2: C.idは使いまわさない
疑問その2は、A.id(サロゲートキー)、B.id(サロゲートキー）の値を使い回すかどうか。

> 疑問その1: 残ってない
残ってないのであれば、仮にCテーブルにサロゲートキーがあった場合、太朗がC.id=1を削除しようとしても「そのレコードは
ありません」ということになり問題無いのでは？

> こういう状態: 太郎次郎三郎と処理された後ってことだろ
要するに、A.id=1, B.id=1のレコードが削除されたり再追加されたりするのに強烈な違和感があるわけ。

普通はサロゲートキーはsequenceなどのデータベースオブジェクトを使って実現するので、使用履歴のある値が再使用
されることはない。

あ−、勘違いしてた。
A:id=1, B:id=1のレコードを削除するわけじゃないのか。
だとしたら太朗がC.id=1のレコードを削除しようとしたとき、「そのレコードはありません」ということで良くないか？

>>667
C.id=1のレコードを削除するというのが仕様なら良いと思うよ

>>596に書いてある
> あくまでCを消したいのであって
> あるAとあるBの関係を消したいわけじゃないならいいんじゃないか？
ってことだよな

>>668
例えばこれがWebアプリケーションで、太朗・次郎・三郎がほぼ同時に同じ情報を変更しようとしていたときと考えると、
そもそもそんな状況になるのがどうなのとも思う。

まあ、それは置いといて、仮にCテーブルにサロゲートキーが無く、三郎がC:(id=2,a_id=1,b_id=2)を追加した直後に、
太朗がそれを削除できていいのかという気がする。内容を見て削除ってそういうことでしょ？
三郎は今それ追加してそのページを見てるのに、既にデータベースにはそのレコードは無いという…。

誤：三郎がC:(id=2,a_id=1,b_id=2)を追加した直後に、
正：三郎がC:(a_id=1,b_id=2)を追加した直後に、

>>669
> 三郎は今それ追加してそのページを見てるのに、既にデータベースにはそのレコードは無いという…。

この手のことはどういう状況でも起こり得る。
なので、このような現象とCテーブルにサロゲートキーを追加することの是非を関連づけては語れないよ。

>>663
hoge_master: (hoge_code: PK, col1, col2, col3, ...)
hoge_data: (hoge_code: PK,FK, fuga_code: PK, col1, col2, col3, ...)
みたいになっていたときに、hoge_masterのPKに更にカラムを追加しないといけなくなったときに、
hoge_masterもhoge_masternのPKをFKに持っているテーブルも全て変更になるが、

hoge_master: (id: PK, hoge_code: UK, col1, col2, col3, ...)
hoge_data: (hoge_id: PK,FK, fuga_code: PK, col1, col2, col3, ...)
みたいになっていれば、hoge_masterへのカラム追加だけで良い。

まあ楽観的ロックでggrksってことだ

>>673
Webアプリでロック使うの？

>>674
"ロック"とついてるが楽観的ロックはロックを保持しない
まあとにかくggrks

♪カスと〜言われて〜素直に〜ググった〜

まあ楽観的ロックにしても、三郎が登録後既にないデータを見ているという状況には変わりないんですけどね

>>666
一連の話の中で暗黙の了解になっていたのが、A.id や B.id ってのはCのカラムであるということ。>>476参照。
A_idと書くべきだっただろうけど、そこで混乱してる人はそうそう見受けられなかったな。

書く前に再読み込みすべきだったorz

>>677
既にないデータを見てるのは太郎だよね。
太郎が削除を行おうとしたタイミングでは、既にレコードが更新されているはずだから
破棄するというのが楽観的ロックなんだけど、まぁ、>>668 >>596の言ってる条件次第。

少し話を変えると、後勝ちを許すかどうかだね。
なお、後勝ちを許さない場合はC.idがあるほうが楽かもね。

>>679
> 既にないデータを見てるのは太郎だよね。
ちと言葉が足りなかったが、三郎がC.id=2を登録した後に太朗が削除しようとしてC.id=2が消せた場合、
楽観的ロックなんか関係無いよって話。

>>596の
> C.idで消すことはありえるけど、前提が難しい。
を見たとき、なんでこの人こんなこと考えてるんだろうってさっぱりわかんなかったけど、やっとわかった。

>>679
> 太郎が削除を行おうとしたタイミングでは、既にレコードが更新されているはずだから
> 破棄するというのが楽観的ロックなんだけど

CテーブルにサロゲートキーC.idを付加して、削除はdelete from C where id = ?とすれば、楽観的ロックとなる。

>>681
updateを禁止できてれば、楽観的ロックになりうるね

>>680
> >>596の
> > C.idで消すことはありえるけど、前提が難しい。
> を見たとき、なんでこの人こんなこと考えてるんだろうってさっぱりわかんなかったけど、やっとわかった。

あーそういうことか。最近の話の流れで俺もやっとわかった。
俺がイメージしてたのは、大部分の変更処理というのは属人性がある場合が多くて、その時はサロゲートキーのみで削除できる。
複数人が同時に同一リソースを変更可能な場合は、別途、要件と照らし合わせてどうすべきか考える必要があるね。ただ、そのときも別にサロゲートキーがあっても邪魔にはならない。

俺も腑に落ちた

まあ複数が同時にわらわら触っちゃうようなのの排他はDB側ではどうもならん罠
そゆのはアプリの仕事

idがあるかないかだけで楽観的ロックとか笑わせるな

誰がそんな話を？
ずっと変なレスばかりしてる人かな

(その)id(のレコード)があるかないかだけで楽観的ロックとか笑わせるな
ってことだな
それについては内容を変更禁止に出来ればって意見がすでに出てるが、それってあんまり現実的ではない
今回のようにそもそも代理キーの必要性がほとんどない関連テーブルだから通用する話
普通は楽観的ロックは、対象行が変更されてるかどうかチェックする必要があるって事だ

>>688
楽観的ロックも変更禁止もアプリ制約だから可能

それ以外は自分で言ってるよな。今回の場合は可能と

>>688
条件付で楽観的ロックとして機能するねって話をするからには、
レコード有無だけで楽観的ロックが実現できるなんて思ってないことはすぐ分かるでしょ。
なんでそんなに話をずらすんだ？

>>690
なにがずれてるんだい？

おどろいた

だれだよ楽観的ロックとか言い出した奴
元の話と楽観的ロックとは無関係だろう

688の説明フェイズが終わってないぜ

元の話には関係ないなｗ

>>690
>条件付で楽観的ロックとして機能する
条件後だしだろ
前提条件があるならちゃんと書いとけと

>>696
楽観的ロックが実現できるねって話と同時に条件が出てるよ。
どの流れを読んで後だしと判断したのか説明してみて。

>>681にたいして>>682の条件だろ

やっぱだめだな

条件付でって文字が読めなかったのかな

更新禁止できれば楽観的ロック可能
更新禁止も楽観的ロックもアプリ制約だから可能

が現状で>>688の説明フェイズか

関連テーブルを更新するって概念自体がキモいんだが

サロゲートキーがあれば楽観的ロック可能とか
更新禁止だから楽観的ロック可能とか

楽観的ロックに対して発言してるやつらの話が理解できん

さすがにサロゲートキーと楽観的ロックが無関係ってIQ100以上あれば理解できる暗黙の了解と思っていたが
本気で分かってない奴がいて真面目に驚愕

アプリからはINSERT/SELECT/DELETEしかしない場合は、Cテーブルにサロゲートキーがあれば
それを使って楽観的ロックができるというだけの話なんだけど、どこがわからないんだ？

普通、〜があれば可能、という日本語は、それが無いと不可能か非常に困難だっていうニュアンスなんだが

>>673が一体どういうつもりで
> まあ楽観的ロックでggrksってことだ
と言ったかの真意を明かさないと、この話題は終わらない。

>>706
Cテーブルにa_id, b_idしかなければ、楽観的ロックは実現できないだろ。

>>705
更新時にサロゲートキーを使い捨てする事で
行のバージョニングを実現させるという事かな？

>>709
> 更新時にサロゲートキーを使い捨てする
ってどういうことだ？
ここ最近、俺の常識では計り知れない文章を書く奴が多すぎて疲れる。

>>710
サロゲーキーの値を変化させる訳じゃないのか
ならなぜ楽観ロックが出来る出来ないの差が発生するんだろうか
サロゲートキーも複合主キーも同じキーなのに

>>711
> サロゲーキーの値を変化させる訳じゃないのか

俺の常識が本当に常識だったのか自信がなくなるわ

>>711
たぶん楽観的ロックというものを理解できてないだけかと

いやどういうもこういうも
"複数の更新者がいるWebアプリ"なんつーもんは楽観的ロックを使うのが常套で、
そしてちゃんとggrばサロゲートキーなんぞ何等カンケーねえ別件だってことくらい判るはずと思ったんだが
タイムスタンプなりの更新状態をどこかに持ってなきゃ楽観的ロックなんて成立しないし
それをサロゲートでやろうとか強引なんてレベル通り越して頭大丈夫かって話

そもそも、サロゲートキーの有効性の話だったはずだが
楽観的ロックとかどう考えても関係ないだろうに、誰が言い出したんだ

>>715
>>673が言い出した。で、>>714を読んでもなぜ>>673でいきなり楽観的ロックの話を持ち出したのか意味不明。

>>708
こいつは、楽観的ロックが理解できない　でＯＫ？

>>714
> タイムスタンプなりの更新状態をどこかに持ってなきゃ
だから、C.idがそれの代わりになりうるねって話の流れなんだけど。

>>714
思考停止過ぎ
一般的な楽観的ロックの実装は理解できてるが
楽観的ロックそのものは理解してませんって感じだな

太郎だの次郎だと言ってるやつと、その話が理解できないって言ってるやつに
それは楽観的ロックの話でサロゲートキー関係ないから、楽観的ロックでググれって言ってたのかね
それに対してさらにサロゲートキーで楽観的ロック出来るとか言い出した奴がいるから話がおかしくなってるんだな

>>718
その場合、C.idはもはやサロゲートキーと呼べない
C.idそのものがバージョン番号の意味をもつからな

>>721
> その場合、C.idはもはやサロゲートキーと呼べない

故に、サロゲートキーを使って楽観的ロックは行えない、という主張だとするなら、それはトートロジーだよ。

俺の主張は>>720の通りなんだが
>>719はどんな手段で楽観的ロックする気なのか御高説を賜わろうか

>>722
>サロゲートキーを使って楽観的ロックは行えない
そんな主張をした人がいたか？
サロゲートキーと楽観的ロックは無関係だぞ
自然キーでもサロゲートキーでも楽観的ロックはできる

サロゲートキーを使わないと楽観的ロックができないという主張は>>708がしてるけどな

>>724
> サロゲートキーと楽観的ロックは無関係だぞ
関係あるとは誰も言ってない気がするが。

> 自然キーでもサロゲートキーでも楽観的ロックはできる
なら、全員一致でめでたしめでたしだ。

> サロゲートキーを使わないと楽観的ロックができないという主張は>>708がしてるけどな
してないだろ。

だれか>>708の解説してくれ
俺にはC.idつまりサロゲートキーが無いと楽観的ロックは出来ないという主張に思えるんだが

念のためいっとくが、タイムスタンプとかないテーブルの楽観的ロックは原則として全項目比較で行うんだぞ

よかった。
あとは>>708さえ登場しなければ、この馬鹿げたやり取りは終わりだ。

もう>>518以降謎だらけだわ
多分同一人物なんだと思うけど

>>726
>>708じゃないが、解説する。

> サロゲートキーが無いと楽観的ロックは出来ないという主張に思える
この解釈は間違い。A.id B.id 以外の何らかの情報がないとダメだとまでしかいってない。
その何らかの情報がサロゲートキーであると思い込んだところが間違い。

あと、行バージョン(タイムスタンプなど)を用いる場合と、全項目比較の場合では
結果が異なりうるということを認識できていないなら、稀にまずい。

なんかDBに限らず、設計というものに携わるべきでない奴が交じってるな
デスマーチを産み出すのはこういう奴らか

打ち合わせ中に机叩き始めるんじゃないかって心配になるぐらいだね。

>>729

>>705
>>706
>>708

ここから、本人でもないのに
>A.id B.id 以外の何らかの情報がないとダメだとまでしかいってない
だとか
お前とは議論できんわ

>>517からここまで引っ張るとはな

>>732
まさか>>706を受け入れてる？

逆は必ずしも真ならず

DB設計するやつが判らないはずがない。まさかな

>>734
>>706=>>732なんだよ

>>706
どういう「普通」だよ？

そもそも太朗次郎三郎の例はレアケース中のレアケースで、それを元にサロゲートキーがどうとか楽観的ロックがどうとか話しても無駄だよ。

>>688とか>>732がここまで引っ張ってるのかよ。

>>738
太郎次郎三郎の例はレアケースではないよ。
このケースで楽観的ロックなんて必要な要件が稀なだけ

サロゲートキーで楽観的ロックが出来るとしてもだ
概念別物だから汚くてやらんだろう

>>738
昔々マーフィーの法則というものがあってな
起こる可能性のあるものは何時か必ず起こる
起こっても問題が出ない/そもそも起こりようがないようにするのが設計の仕事だ
今回の場合はDB屋の範疇じゃねえけどな

>>740
> 起こる可能性のあるものは何時か必ず起こる
そういう意味でレアケースだと言ってるのではない。

(a_id=1, b_id=1)という組み合わせを「二人が関連づけ」「二人が関連を解除しようとした」というのがまずレアケース。
長い時間軸で見たときに、時間経過とともに関連付いたり関連しなくなったりするケースはあるかもしれないが。

そして、「関連づけを解除しようとする太朗」「関連づけを解除した次郎」「関連づけた三郎」がほぼ同時に操作をするというのがレアケース。
関連づけるにせよ、関連を解除するにせよ、何かがトリガーとなるはずで、そのトリガーが同時期にいくつも起こることはほぼない。

さらに言えば、システム全体としてみたとき、三人の操作が終わったときに(a_id=1, b_id=1)は、それぞれの操作タイミングで存在する場合もあるし、そんざいしない場合もある。
その意味で現実味がない（具体的な要件と容易にマッチできない）例である。

つまり、一体どういう場合・要件のときにこんなことが起こり得て、どうするのが正解なのかもわからない例で議論しても無駄ってことだ。
上の方で出た「書籍-著者」のような、具体例と具体的な機能要件を示して議論しなければ意味が無い。

>>740
> 起こっても問題が出ない/そもそも起こりようがないようにするのが設計の仕事だ
これには同意するがね。

なんだおめー>>531か。
もう全行にツッコミくれてやりたいがいっこだけ。
レアだろうがなんだろうが発生しうるんなら対策しなきゃなんないんだよ。
その対策をどうするかは要件によりけりだが、要件よりけりで考慮もしなくていいなんてケースが有る訳ゃねーだろ。

>>743
> レアだろうがなんだろうが発生しうるんなら対策しなきゃなんないんだよ。
> その対策をどうするかは要件によりけりだが、要件よりけりで考慮もしなくていいなんてケースが有る訳ゃねーだろ。
だから、「良くありがちな要件を一般化したような例」であるなら議論の価値もあるが、そうではないレアなケースで議論する価値が無いと言っているだけだ。
もちろん、同時に複数人が同じ情報を編集できるようなアプリケーションを作ったとしたら、同時に操作された場合の処理も考える必要があるのは>>742で言った通り同意する。
ただし、考慮する視点はサロゲートキーが必要かどうかや楽観的ロックが必要かどうかではない。

>>741
書籍-著者の話って、太郎の話には結びつかないものなの？
「具体的な要件と容易にマッチ」できる話かと思ってた

もうお前らが何について論議してるのかが解らない

>>745
> 書籍-著者の話って、太郎の話には結びつかないものなの？
俺としては、結びつくような機能をすぐには思いつかない。
どのような機能のときに太朗の話のようなことが起こり得るのかを示せば、サロゲートキーがあればそれが使えるかどうか、楽観的ロックが必要かどうかなどの話に結びつくだろう。
ただそれはあくまでもその場合の議論であって、それをもって関連づけテーブルのサロゲートキーの有用性や楽観的ロックの議論には敷衍できないと思う。

具体的な要件に結びつかないと議論の意味がない
→具体的な要件に結びついたとしてもその場合のみにしか適用できないので汎用性がない

次はどうしようか

>>748
もう読み直す気力がないから記憶で書くが、そもそもの話は関連づけテーブルにidがあると便利派がいて、それに対してidで操作できる場面なんて極々限られているという主張が出た。多分後者が太朗の例を出したんだろう。

サロゲートキーがあるときのメリットは一般論で語ることができるが、そこに特殊例を持ってきて、この場合は使えないと反論しても、サロゲートキーのメリット全てが否定されるものではない。その意味で、太朗の例を元に議論しても意味ないということ。

もう太朗の話もサロゲートキーの話も楽観的ロックの話もいいよ。おなか一杯。

楽観的ロックの話を持ち出した奴がアホということで終劇。

なんか、太郎を太朗って書く人が一人だけいて
そいつが勘違いをいろいろしてかき乱してる

また>>749でかき乱す。前半2行はあってるが、後半は間違い

>>752
> なんか、太郎を太朗って書く人が一人だけいて
少なくとも、俺以外に一人はいるようだが。

> また>>749でかき乱す。前半2行はあってるが、後半は間違い
どう間違っているのか、ロジックを提示してくれ。

つか、>>673が何をやりたいのかさっぱりわからん。
こいつがこのスレをかき乱してるのだけは確か。

>>754
>>720

話を蒸し返すようだが、
>>714
> "複数の更新者がいるWebアプリ"なんつーもんは楽観的ロックを使うのが常套で、

俺はそうは思わないということだけ表明しとこう。

>>749
>>752じゃないけど説明する、、、のもめんどくさいので>>752に同意。

太郎だの次郎だの言ってる奴と、楽観的ロックを持ち出した奴は同一人物じゃないのか？
どっちも俺からすれば変。

>>758
宗教が反対側だから別の人

>>517から始まって、そんなに関連テーブルにサロゲートキー作ることに
メリットを強調して何が良いのだろう
>>749も同系だよな、もしかしたら同じ奴

俺には何もメリット感じないし、関連テーブルにサロゲートキーがあるDB設計に出会ったことがない

>>760
> 俺には何もメリット感じないし、関連テーブルにサロゲートキーがあるDB設計に出会ったことがない

お前がメリットを感じないからといって、メリットがあるという奴を否定するんじゃないと
ずっと言われてるのに気づかないのか？

>>760
> メリットを強調して何が良いのだろう
俺は逆に、メリットがあると言う奴に対して「いや無い」と説得（？）する意味がわからんわ。

メリットって、例えばずっと上で書いて無視されたんだが、Backbone.jsではModelがid持ってると
デフォルトでmodel.destroy()がHTTP DELETE idとかしてくれるので便利なんだよ。

>>763
>>617

メリットって何か説明できたっけ？
苦し紛れに出した楽観的ロックだけじゃね？

>>764
何を言いたいのか良くわからんが、別にBackbone.jsは複合キーでも使えるぞ？
使えるけど、idがあればさらに便利ということなんだよ。
・・・ということで、メリットはわかったね？

>>765
楽観的ロックに使う奴なんかいないだろ（と思ってました）。

>>765
サロゲートキーだけで処理すれば、自分が取得した時点のデータ以降にできたものは削除されない。
太朗次郎三郎の例で言えば、太朗は三郎が作った関連は削除できない。
それが、要件とマッチするかどうかは別の話だが、メリットになり得る場合もある。

>>768
それはメリット・デメリット双方よ

>>769
それはその通り。
「メリットは無い」の反論。

もう最初っから「あれば便利に使える場面もある」ってだけの話なのに、なんでこんなに紛糾するのか

>>771
「あれば便利に使える場面は、あったとしても極めて限定的だし、そうする必要はほとんど無いので無くていいよ。」
という話だと思うよ。

>>765
うん。苦し紛れ。

>>766
三郎が作った関連を、太郎が削除できるべきという要件の場合にもその便利なものは使えるのかな。

>>770
その機能を実現するために「楽観的ロック」というキーワードがあるから調べてみなさい。
そうすれば、その機能をサロゲートキーをつかって実現するのがおかしいということも分かるでしょう。
つまり、サロゲートキーを追加することのメリットとしては不適切ですよ。
と、>>673は言ったつもりなのだろう。(その後のレスを見る限り)

そのあとの流れは以下のループじゃない？
・まぁ、条件さえ整えば楽観的ロックに使えなくも無いよね(普通しないけど…苦笑)
・楽観的ロックってそうじゃねえから！！！(本気)

サロゲートキーにそれ以上の機能をもたせて
サロゲートキーは便利だろ、っていう理論を展開してるやつがいるんだが
わざとなのか、理解できてないのか

このスレはレスにID付いたほうがいいんじゃないの。 >スレ立ててくれてる人
ちょっとはわかりやすくなるような気がする

ID出る出ないは板ごとに決まってるもので
スレごとに変えれるわけじゃない

データベース板だからこそIDが有った方が良いというかスキーマにユーザIDが無いと
モヤモヤ気持ちが悪いというかいやむしろ最近話題の匿名化ですよ連結不可能だと
思えば無意味に納得できるかもとかよくわかんね。

そのIDはユーザーを特定できるものじゃないってことに注意な。
テーブルのIDもそうだが、そのIDが何をidentifyするものなのかを
常に念頭におく必要がある。

>>776
そうなんだ、板の決まりは変更しにくそうだな
まあ、暗中模索状態で誰が何言ってんのかわからんのも、闇鍋みたいでまあいいか

>>779
板の設定は99.99%変更できないと考えていいよ。どこに要望しても。
もとから強制ID制だったら良かったのにね。

今日書いたWebアプリのページでも、関連テーブルのidが大活躍したよ。
関連テーブルにidいらないって人、頭固いよ。

ふーん

どう活躍したかを言わないで意味があると思って？

え、どうって、idのみで取り回せるってことだけど。

それがどう大活躍なのよ

>>784
・クライアントコードがシンプルになる
・テストしやすい

ふーん

よかったね

>>781
要件次第だって、これまで読んでてわからないかな
スペックもそれぞれ違うし、トランザクションの量も違う
そういうのを考慮せずに正解だせるとでも思ってるの？

>>787
別に何かの正解を出そうだなんて思ってないけど。
便利だったよって報告。
なんでいちゃもん付けたがるの？

>>785
クライアントコードがシンプルになるのは
これまでずっと話されてたことで置いといてだ

テストしやすいはわかんないな

>>789
> テストしやすいはわかんないな

Webアプリのテストはどうやってる？

>>790
どういう意味だろ

自動で内部も外部もやってる
DBは消したり消さなかったり両方

>>791
> どういう意味だろ

Webアプリのクライアント側のテストを、何を使ってテストしてるか。

外部からのテストってことか
Selenium使ってることが多いかな

>>793
外部と内部の区分けが良くわからないんだけど、例えばGmailのように何かが一覧表示されてて、
そのそれぞれの項目がGmailで言うところのラベルを複数持っているようなページがあるときに、
・期待するラベルが表示されているか
・あるラベルをはがすと正しく動作するか
・ラベルを追加すると正しく動作するか
のようなテストは、そのラベルがidで特定できれば、Seleniumを使ってテストするときに便利じゃない？
Seleniumはあまり使ったことないから、外してる可能性もあるけど。

用件次第だってのになぁ。
あれば便利なこともある。
あることで、間違えた使い方をされてバグを生み出すこともある。

>>794
「idで特定できれば」って特定できなくない？
サロゲートキーがどの番号から始まってもテストとおらないとダメだしな

Gmailの例だと、要件としてきつめ
・期待するラベルが表示されているか
・あるラベルをはがすと正しく動作するか
これらの保証って、サロゲートキー確認ではダメで、ラベルのID調べなきゃダメよ

>>796
> Gmailの例だと、要件としてきつめ

きついとか緩いの判断基準が良くわからないんだけど…。

> これらの保証って、サロゲートキー確認ではダメで、ラベルのID調べなきゃダメよ

いや、例えばSeleniumを使ってテストするのなら、ラベルのIDを"label-{サロゲートキー}"
みたいにしとけばテストしやすいんじゃないのということなんだけど。
それで本当にSeleniumでテストし易くなるのかどうかは、俺はSelenium使いじゃ無いから
外してるかもしれない。

>>797
ちょっと理解できなくなったが
>ラベルのIDを"label-{サロゲートキー}"
って何？

要件としてきついのは、Gmailはラベルの名前で判断してるけど
特定のラベルを消しているのであって
特定の関連が消しているわけではないのできついと書いた

798
日本語が変だった

特定のラベルを消しているのであって
特定の関連を消しているわけではない

のできついと書いた

サロゲートキーでいいって要件だったらサロゲートキーのが楽なのは
実装もテストも理解できるところ

要件としてサロゲートキー判断で良いってのを俺は見たことがないが
要件が満たすなら便利でいいんじゃないか？

>>788
要件によってはトラブルの元だよって話
便利だった状況が分からないとなんの参考にもならないよ
DBの代わりにExcel使ったら便利だったよ、って報告されても役に立たないだろ？

>>798
> ちょっと理解できなくなったが
> >ラベルのIDを"label-{サロゲートキー}"
> って何？

例えばラベルを
<span class="mail-label" id="label-12345">新着<span>
のように表現するってこと。

他人の頭がカタいと感じるときの半分くらいは、自分の頭がカタいからであると自戒をこめて。

>>802
テストをするたびにテーブルもシーケンスもリセットするの？

>>802
「新着」ラベルを消すの？
サロゲートキー12345を消すの？

>>804
> テストをするたびにテーブルもシーケンスもリセットするの？

俺はしないし、Seleniumを使ったテストでも不要じゃないの？
なぜそんな疑問が湧くのかがわからない。

>>805
新着ラベルを消す
↓
id=12345を消すリクエストをする
↓
そのレコードが消える
↓
ページから新着ラベルが消える

なんだけど。

>>807
"id="label-12345"のラベルが消えている状態"
"新着という名称のラベルが消えている状態"
これを別物に扱えないとテストもかけないぞ？

>>808
俺に書けるか書けないか聞かれても困るよ。Selenium使ってないし。
Seleniumを使ってるというから、idで特定できるとテストが簡単になりはしませんかって質問してるんだけど。

簡単になりませんってことなら、そうですかで終わり。

>>809
Seleniumの話なんて誰もしてないぞ
>>793が自分の使ってるものを言っただけだぞ

根本概念理解してないだろ？過去ログよめよ

>>810
一般的な話なら、
>>800
> サロゲートキーでいいって要件だったらサロゲートキーのが楽なのは
> 実装もテストも理解できるところ
で終わりでしょ。

Seleniumを使っているという>>789が、コードがシンプルになるのはいいとしてテストしやすくなるのが
わからないという流れになったから、Seleniumでも楽なんじゃないの？という流れになってるだけ。

テストの楽さは一緒だと思うよ
>>802のやつで
・新着って文字のラベルがなければ良い
・id="label-12345"のラベルがなければ良い
同じ

要件次第で終わってる話をぶり返さなくてもいいんじゃないか？

ぶり返す方が頭固いとしか思えんわ

>>812
> テストの楽さは一緒だと思うよ

Seleniumの人？だったらSeleniumじゃidあっても別に変わらないってことですね。
（ただ、Seleniumをちょっとしか使ったことない俺でも、idあったら便利そうな気がするんだが・・・）

>>814
id="label-ラベルのID"でもいいよ

ラベルのIDを使えるかは要件次第

>>815
その「ラベルのID」ってサロゲートキー？

>>816
ラベルのサロゲートキー

釣り放題ですな

代替物でテストするって、要件をテストしたことになるんかいな

テストの根幹の理解がおかしいような

>>819
> テストの根幹の理解がおかしいような
お前の理解がおかしいわ

>>820
そうかそうか

>>819
Railsだと要件のテストが全くできないということですね

>>819
該当代替IDが消えていることって要件だったら
テストしたことになる

該当名称とか代替ID以外の該当○○が消えていることって要件だったら
テストしたことにならない

要件次第だから膨らますのやめようよ

>>822
Railsのテストは関連のサロゲートキーで行わないよ
Railsを悪く言うのやめてくれ

>>805
> 「新着」ラベルを消すの？
> サロゲートキー12345を消すの？
こいつがいつも話をややこしくする

>>825
理解してるのそれ？

>>819
> 代替物でテストするって、要件をテストしたことになるんかいな
意味が分からない

>>827
>>823が答えてくれたからいいよ

>>826
また、太郎次郎の例を出すのか？

>>828
それも意味分からんわ
Gmailを例に説明してくれ

>>830
Gmailがサロゲートキーをつかてないから無理だろ

>>831
アスペかよ
Gmail的なアプリケーションだとどういうことなのか説明してくれ

>>832
アスペもクソも、代替IDで判断するアプリをシラネ。
例出せ

>>833
知らないなら、何がテストしたことになって、何がテストしたことにならないかわからんだろ
黙っとけ

>>834
あらあら、例を出してきたのはそっちなのにな。答えられないだけか

純粋な疑問、あるの？関連をサロゲートキーにしてるサイト

>>823が理解できないなら結構まずいんじゃないか？
理解できないならまず何が理解できないか言わないとな

>>836
> 純粋な疑問、あるの？関連をサロゲートキーにしてるサイト

俺に言わせれば、なんで無いだろうと思ってるのかがわかんない。

800俺だけど
> サロゲートキーでいいって要件だったらサロゲートキーのが楽なのは
> 実装もテストも理解できるところ
このテストって内部テストな
外部テストは一緒だと思う

>>837
単純にみたことない
悪魔の証明系だから例あげれば終わるんだから出して欲しいんだけど

>>838
> 外部テストは一緒だと思う

やっぱり外部と内部がよくわからないけど、ヘッドレスブラウザ使って何かを行って、Assertionは
DOMをパースする的なテストでidがあれば便利かもと思ったんだよ。これ外部？

ついでに>>833
redmine(Railsアプリ）はプロジェクトにメンバー登録するなどは関連テーブルでなおかつサロゲートキーを
持っていて、「プロジェクトからユーザを削除する」はHTTP DELETE {関連テーブルのサロゲートキー}ってやってるよ。
多分他の関連づけパターンも同じだと思う。

>>823でケリついてるから終わろうぜ

要件次第で幕

>>841
例も出たことだし、redmineで説明よろ

Railsアプリは糞で終了

Redmineはサイトじゃないとか言い出しそう

もしかして、RedmineのMembersが関連テーブルとか思ってるの？
さすがにやばくない？

残念だけど、Redmineのmembersであってるんかな？
これは関連テーブルじゃないんだよ
role_idをもってしまってる

custom_fields_projects
custom_fields_trackers
permissions_roles
これらは関連テーブルだけど、サロゲートキーを使ってない

membersでも説明できるが俺が説明するより
>>823が説明した方がわかりやすいとは思うけどな
単に、メンバーとプロジェクトの関連が残ってるのがいけないのか
該当関連IDの関連が消えていれば良いのかだけだろ
今回ロールIDが絡むから、要件はさらに複雑

Railsの関連テーブルってサロゲートキーで消せたっけ。
モデルも持たないはずだし、コントローラーも持たない。
A_Bってテーブル名に普通なるはずよ。

DELETEで消すことができるのはリソースがあるはず。

>>840
外部テストはブラックボックステストね

>やっぱり外部と内部がよくわからないけど、ヘッドレスブラウザ使って何かを行って、Assertionは
>DOMをパースする的なテストでidがあれば便利かもと思ったんだよ。これ外部？
これは内部だよ

流れがネタとしか思えん

要件次第で幕

>>823のいう
> 該当代替IDが消えていることって要件だったら
> テストしたことになる
って、テストするたびにシーケンスリセットしないとうまくうごかなくない？
IDの値を意識したテストってことだよね。。
でも彼はシーケンスリセットなんてしないっていってる。でもサロゲートキーでテストしてるっていってる。
そこが解せない。

別にシーケンスとかリセットせんでも
100を指定して100が消えてる＝ＯＫ
200を指定して200が消えてる＝ＯＫ
ってだけの話
消すべき行のIDが100で正しいのか200で正しいのかは分かりませんよ、と

>>850
> でも彼はシーケンスリセットなんてしないっていってる。でもサロゲートキーでテストしてるっていってる。
> そこが解せない。

あくまでもクライアント側の話だけど、

新規登録するテスト：
　POSTして、サーバから新しいサロゲートキーを含むデータが戻ってくればOK。
　それが正しいかどうか（新規に作成されたレコードのサロゲートキーかどうか）は、サーバ側の
　テストで確認する。

削除するテスト：
　取得済みのデータのサロゲートキーをサーバに送信して、エラーがなければOK。
　本当に消えたかどうかは、サーバ側のテストで確認する。（というか、行をDELETEするかどうかは
　サーバ側の都合なので、クライアント側は関係無い）

みたいな感じ。

>>846
> 残念だけど、Redmineのmembersであってるんかな？
> これは関連テーブルじゃないんだよ
> role_idをもってしまってる

俺の使ってるバージョン(2.3.0.stable)では、role_idは持ってないよ。

>>851-852
あぁ、なるほど。説明ありがとう。

>>853
https://github.com/redmine/redmine/blob/2.3.0/db/migrate/001_setup.rb

>>855
新規にインストールしたらそうなるんでしょうね。
うちのは古いバージョンから何度かアップグレードをかけたものだから構造が違うのかも。

mysql> desc members;
+-------------------+------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| user_id | int(11) | NO | MUL | 0 | |
| project_id | int(11) | NO | MUL | 0 | |
| created_on | datetime | YES | | NULL | |
| mail_notification | tinyint(1) | NO | | 0 | |
+-------------------+------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

・・・と思ったんだけど、2.3.0を新規にインストールしたやつを確認したら、
.../redmine-2.3.0/db/schema.rb
というファイルができてて、
create_table "members", :force => true do |t|
t.integer "user_id", :default => 0, :null => false
t.integer "project_id", :default => 0, :null => false
t.datetime "created_on"
t.boolean "mail_notification", :default => false, :null => false
end
to
ってなってた。できたデータベースもこうなってる。
CREATE TABLE members
(
id serial NOT NULL,
user_id integer NOT NULL DEFAULT 0,
project_id integer NOT NULL DEFAULT 0,
created_on timestamp without time zone,
mail_notification boolean NOT NULL DEFAULT false,
CONSTRAINT members_pkey PRIMARY KEY (id)
);

Redmineの話はこの辺でやめとく。

それも関連テーブルじゃないし

>>858
だね、プライマイリキー id があるのだからDB設計上は
エンティティであって、関連テーブルではない

関連テーブルにサロゲートキーをつけるかどうかという話だった気がするが

CREATE TABLE members
(
user_id integer NOT NULL DEFAULT 0,
project_id integer NOT NULL DEFAULT 0,
CONSTRAINT members_pkey PRIMARY KEY (user_id, project_id)
);
というスキーマだとしても、これは関連テーブルではないということなのかな？
それとも、上は関連テーブルだが、
CREATE TABLE members
(
id serial NOT NULL,
user_id integer NOT NULL DEFAULT 0,
project_id integer NOT NULL DEFAULT 0,
CONSTRAINT members_pkey PRIMARY KEY (id)
);
は関連テーブルではないということ？

>>861
そこまでじゃないか〜

>>860
モデリングのことのみを考えるなら不要。明確なのはここまで。

モデリング上明らかに不要な項目を追加するのには、そのデメリットを補う何らかの理由が必要。
でも今のところはそこまでの理由は見出せていないという状況かな。

Railsの関連テーブルにサロゲートキーは必要ない

Redmineの関連テーブルにサロゲートキーはない
これはRedmineの初期バージョンからだよ

関連テーブルにサロゲートキーなんて低レベルな話を
RailsやRedmineに絡めないでくれ

Rails のバイブルである書籍「Rails によるアジャイルWebアプリケーション」の
初版から第３版には、「関連テーブル」と「(関連テーブルとして振る舞う)モデル」との
違いが明解に解説されていた（注：書籍内では関連テーブルを結合テーブルと呼んでいる）
ところが最新版の第４版では、この解説が章ごと欠落している

>>864
Railsの関連テーブルにサロゲートテーブルを絡めようとするお馬鹿さん達は、
もしかすると第４版からRailsを触り始めた初心者なんだと思う

あるいはバイブルではない「レシピブック」みたいな HOWTO本で
Railsを分かった気になっている素人なのかもしれない
こういったHOWTO本は、このスレで扱うDB設計の本質をすっ飛ばして
設定方法を詳しく解説しているから、コピペを駆使すればRailsを動かせる
だからモデル/関連テーブル/一意性(identity)といったデータモデリングといった
「設計」に必要な基礎概念を理解できていないのに「Railsが分かった」気分になってしまう
単純に言えば、(設計ができる)プログラマと(設計ができない)コーダの違い

githubでredmineのソースみれば
0.2のときから、membersは関連テーブルではないし
role_idだってあることがわかる
その程度もできないなんて

>>866
インストールしてみれば？

つか、Redmine(Rails)の実装の都合なんか関係なしに、データモデリングの世界では
関係テーブル（関連エンティティ）とは、多対多を1対多に落とし込むものであってそれ
以上でも以下でもない。

>>867
インストールしてもrole_idあるよ

かわいそRails、Redmine
住んだ人が悪かった

railsの話はrailsスレでやれよ

どうみても引き取ってもらえなさそう