DB設計を語るスレ２

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/09 18:33 / Filesize : 242 KB / Number-of Response : 874
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

DB設計を語るスレ２

1 名前：NAME IS NULL [2008/10/08(水) 18:34:13 ID:PQV+Wmyc]: 引き続き語れ！！

前スレ
DB設計を語るスレ
pc11.2ch.net/test/read.cgi/db/1166540159/
2 名前：NAME IS NULL mailto:sage [2008/10/08(水) 18:39:40 ID:???]: ふむ
3 名前：NAME IS NULL mailto:sage [2008/10/08(水) 18:41:25 ID:???]: 早速質問なのですが、
日付を「昭和60年2月3日」のように和暦で扱うアプリの場合、カラム型は
普通に日付型を使った方がいいでしょうか？

アプリは.NETで作っていて、
元号をコンボボックス、年月日をテキストボックスで選ばせるUIなので、
元号、年、月、日を別カラムで保持すれば楽かなーと思うのですが。
どうでしょう？
4 名前：NAME IS NULL mailto:sage [2008/10/08(水) 19:52:25 ID:???]: また落ちたのか。12までいってたから安心してたのに。
この板の即死判定って何レス？

しかしまぁ、はっきりいって需要ないのかも。
5 名前：NAME IS NULL mailto:sage [2008/10/08(水) 20:08:27 ID:???]: 大坊設計
6 名前：NAME IS NULL mailto:sage [2008/10/08(水) 23:14:26 ID:???]: 支援ついでに
>>3
日付型を使うべき
7 名前：NAME IS NULL mailto:sage [2008/10/08(水) 23:48:08 ID:???]: DB設計ってどうやって勉強してる？
よい書籍とかあったら教えて下さい。
8 名前：NAME IS NULL mailto:sage [2008/10/10(金) 14:54:01 ID:???]: 文字列が全部固定長・・・
３文字くらいしか入力しないのに、
１００文字の固定長ｗ
理由をたずねたら、
ﾃﾞｰﾀﾍﾞｰｽの構造上、固定長のほうが処理が
パフォーマンスがいいんだよって

ＳＱＬみてみたら
全部のＳＱＬに毎回ＴＲＩＭかけてるしｗ
ＴＲＩＭするなら、最初から可変長にしてくれｗ
9 名前：NAME IS NULL mailto:sage [2008/10/10(金) 23:11:15 ID:???]: >>7
ERDレッスンかなあ。

業務ごとの濃い話になると別。
10 名前：NAME IS NULL mailto:sage [2008/10/20(月) 14:21:28 ID:???]: Webのシステムでキャッシュっぽいテーブルは固定長レコードになるようにしてる
11 名前：NAME IS NULL mailto:sage [2008/10/20(月) 16:38:57 ID:???]: ＞ﾃﾞｰﾀﾍﾞｰｽの構造上、固定長のほうが処理が
＞パフォーマンスがいいんだよって

COBOLerの脳内妄想かと。
固定長しか知らん人種だし。
12 名前：NAME IS NULL mailto:sage [2008/10/20(月) 19:34:57 ID:???]: 完全な固定長のレコードにアドバンテージを設けているRDBMSはMySQLのMyISAMくらいしか知らない。
13 名前：NAME IS NULL mailto:sage [2008/10/20(月) 22:34:36 ID:???]: 削除・更新が頻繁なテーブルでは、可変長だと行連鎖・行移行が発生
しやすいというのはあるな。
まぁ、ほぼ3文字しか必要ないのに100文字ってのはページ使用効率が
悪くて逆にパフォーマンスを落としそうだが。
14 名前：NAME IS NULL [2008/10/21(火) 22:22:08 ID:JfHp8/7P]: テーブル設計（論理設計）などの初心者が読むべき本とかありますか？
教えていただけたら幸いです
15 名前：NAME IS NULL mailto:sage [2008/10/22(水) 11:05:30 ID:???]: >>14
>>9
16 名前：NAME IS NULL mailto:sage [2008/10/24(金) 10:23:09 ID:???]: DB設計は、そのノウハウが書かれている書籍とか結構あるし、
テーブルの正規化はこうだといわれてたりするけれど、
人の作ったDB見てると、それらが必ずしも守られていなかったりしていて、
そのDBを作った人の個性があるように感じる。
誰かが作ったDBを、他の人が見ると、「これはこういう効率の悪さがある」と
設計を批判する事もあるようだが、システムとしては稼動しているし、
使用者にとっては特別致命的なものがあるわけでもなかったりする。

となると、DB設計というのは、これが正しい、これが結論だというものは
無くて、結局はその人の考え方（速度、保守性、拡張性、引継ぎ、などで
何処を重要視するか）の世界みたいなところなのかなと思う。

このスレに来てる人はどう思う？
17 名前：NAME IS NULL [2008/10/25(土) 00:53:05 ID:Hv10EAg0]: 基本的かも知れないけど、質問させてください。

固定長の文字列を格納するのにchar、とvarchar2ではやっぱりcharのほうが速度的に良いの？
今まで行ったたいていの現場では「文字列は固定長・可変長関わらずvarchar2で」っていう感じでした。

理由はいろいろあったんだけど、

・「こっちは固定長だからcharで、あっちは可変長varchaｒ2で」っつーのが単純にわずらわしい
→設計効率重視意見

・「固定長をvarchaｒ2に入れてもcharに入れるのと速度的に大して変わらない。大勢に影響なし」
→性能変わらない意見

・charだと「固定長だと思っていたけど、その後に可変長になった」っていう仕様変更に弱い。
→当初より短い文字列を入れることになった→アプリ側でtrimを入れることに→うざい
→心配だから全部trimを入れた→アプリ開発当初からうざい

という感じで、固定長ならcharを使おうって積極的に押す人はいませんでした。

これまで固定長文字列をvarchar2で扱ってもcharで扱っても速度的に違いを感じたことは無いんだけど、

固定長ならやっぱりcharのほうが良いの？
最大で1万レコードくらいしか扱ったことが無いんだけど、でかいと違うのかね？
18 名前：NAME IS NULL mailto:sage [2008/10/25(土) 05:51:16 ID:???]: >>17
DBMSによる。varchar2といってるからOracleなのだろうけど。
19 名前：NAME IS NULL mailto:sage [2008/10/26(日) 11:27:45 ID:???]: >>17
制約とかINDEXとかにも関わってくるけど、DB2とかだとCHARの方が速いな。

1万レコードってそりゃExcelでも処理できなくもない処理量だから、
性能変わらないって意見も解る。

そういう現場なら設計効率重視で可変長のみでもいいと思うけど。

個人的にはそういう重要な作業を「わずらわしい」と感じるヤツに設計は
して欲しくないんだが。
20 名前：NAME IS NULL [2008/10/27(月) 01:45:28 ID:eNeS7+/+]: このスレの人はT字型ERをどう思います？
あれってほんとうに効果あるの？
21 名前：NAME IS NULL mailto:sage [2008/11/02(日) 10:48:06 ID:???]: コボルの頃のじり貧ハードなら固定長で速度稼いでってテクも必要だろうけど。
今はハードの圧倒的進化とRACで、ほぼ限界無く欲しい処理能力得られるから可変長でも良いと思うけどね。

どうせミドルのCやJavaの時点でポインタという名の可変長メモリ管理してるから、速度気にしてもしょうがない。
可変長で処理できるほどの潤沢なメモリが無かった時代に使ってたようなコボルのようにどこまでも固定長で処理してる訳じゃないし。

業務だといろいろ小手先の要求が有るから、表記用の文字列と処理用の日付の両方で持ってる。
３２日って入力して月末処理したいだとか。orz
伝票や帳簿には末日って書いてたからシステムでも同じようにやりたいとか。orz
締めのタイミングが、後藤日＋末日だったりするし。日付型で末日とか持てりゃ苦労は無いが。
22 名前：NAME IS NULL mailto:sage [2008/11/02(日) 21:39:17 ID:???]: ３２日を使いたいから日付に文字列型を使うってのはそもそもの設計がイカれている印象しかないが･･･。
COBOLerがいるならある意味仕方ない感はあるんだが、
そこでCOBOLerのイカれた提案を拒否して、美しい設計を目指すべきだと思うけど。

つか月末（営業）日や五十（営業）日を算出する関数やクラスを定義するだけだろうに。
23 名前：NAME IS NULL [2008/11/02(日) 21:49:46 ID:JdZg49uN]: アッー！
24 名前：NAME IS NULL mailto:sage [2008/11/03(月) 23:29:45 ID:???]: 何でも計算させないで、閉め日テーブル作っちゃえばいいじゃん。
1年に何十回もあるわけじゃないしユーザー側で決めさせれば良い。
規則的ではない変な締めがあっても対応出来る。
25 名前：NAME IS NULL [2008/11/07(金) 03:23:17 ID:eToAOLwU]: 期間で値が決まるテーブルってどやって設計すればいいのかな？

具体的には
１０日から、２０日まで３００円、２１日から３０日まで１５０円　ってテーブルと
毎日の売上数の入ったテーブルをつくって
１４日から２４日までの、売上高を算出させたい！
とか思ってるんだけど

☆売価テーブル

期間開始日　期間終了日売価
___________10______________20____300
___________21______________30____300

☆売上数テーブル

日付売上数
____1__________5
____2__________3
____3__________2
____4_________10
____5__________8
　．

　．

　．

___30_________7

こんなかんじ？

でも、これだとＳＱＬでデータ拾ってくるのに
日付ＪｉｏｎでＳｕｍってもってこれないから、めんどくさいよね？

かといって

☆売価テーブル

日付　　売価
____1_______300
____2_______300
____3_______300
____4_______300
____5_______300
　．

　．

　．

___29______150
___30______150

とかいう、売価テーブルつくるのも、いくら領域いるんじゃーって感じじゃない？
なんか、いいほうほうないかな？
26 名前：NAME IS NULL mailto:sage [2008/11/07(金) 04:15:33 ID:???]: パフォーマンスは別途検討するとして

SELECT
　SUM(売上数 * 売価)
FROM
　売上数テーブル
　JOIN 売価テーブル ON 日付 BETWEEN 開始日 AND 終了日
WHERE
　日付 BETWEEN 14 AND 24

価格がどの時点で確定するかというのが重要なので
売上テーブルに売価が必要なこともあるでしょう。
売ったあとに売価テーブルの内容が変わったら大変なことになってしまうし。
27 名前：NAME IS NULL mailto:sage [2008/11/07(金) 22:16:08 ID:???]: >>25
人によって好みは分かれるだろうけども、自分なら日毎に持つな。

それと、開始日/終了日の方は終了日を省略して開始日のみにした方がまし。
28 名前：NAME IS NULL [2008/11/09(日) 23:12:05 ID:IPd6NExy]: ERの記法ってどれが標準なのかね？
やっぱIE？
29 名前：NAME IS NULL mailto:sage [2008/11/10(月) 00:30:01 ID:???]: >>25
日付ごとに売値を持ってるほうが、メンテ楽そう。
売価テーブル、売価履歴テーブル、売上数テーブルを作って、
価格改定があったら売価テーブルを更新。一日の〆でその日の
売価テーブルを売価履歴テーブルにバッチでコピー。
で、

select
　　sum(売上数テーブル.売上数 * 売価履歴テーブル.売価)
from
　　売上数テーブル
　　left join 売価履歴テーブル on
　　売上数テーブル.日付 = 売価履歴テーブル.日付
where
　　売上数テーブル.日付 between '2008-11-14' and '2008-11-24'

みたいな。
30 名前：NAME IS NULL mailto:sage [2008/11/10(月) 08:39:10 ID:???]: >>25
>いくら領域いるんじゃーって感じじゃない？
１年でたった365レコードでしょ？
31 名前：NAME IS NULL mailto:sage [2008/11/10(月) 11:00:54 ID:???]: SQLやたら長くなりがちだけど、期間指定でもできないことはない。
32 名前：NAME IS NULL [2008/11/10(月) 20:20:30 ID:1PkOr8o/]: >>30
一品目なら３６５レコードだけど
これが、数万品目あつかう小売チェーン店とかだったら年、数百万～数千万レコード
これを何に使うのかによるけど、売り上げを算出するってことは前年比とか
数年分の比較に使うんだろうから、その３，４年分

って考えたら、結構な量になるんじゃね？

でも、実際売価が変更されるのは、週一回あればいいとこだろうし
ものによっては数年変えないとかあるだろうに、余計なデータ増やすのは
パフォーマンスからみるとイマイチな設計なきがするなぁ

＞日付 BETWEEN 開始日 AND 終了日

で取れるようにしたほうが、ＤＢサイズ小さくなってキャッシュ利き易くなるし、いいんじゃね？
33 名前：NAME IS NULL mailto:sage [2008/11/16(日) 01:56:57 ID:???]: データベース設計にも、デザパタみたいなものあるのかね？
34 名前：NAME IS NULL mailto:sage [2008/11/16(日) 03:29:23 ID:???]: こういう業務はこんな感じとかいう本はあるけど
デザパタというよりアナパタに近いよな。
35 名前：NAME IS NULL mailto:sage [2008/11/16(日) 04:13:49 ID:???]: >>34
是非、その本を教えてください
お願いします
36 名前：NAME IS NULL mailto:sage [2008/11/16(日) 05:39:40 ID:???]: アマゾンで「渡辺幸三」で検索すると何冊か出てくる。
生産管理のはかなりレベル高い。生産管理やった事ないけど
読み応えあって面白かった。

あとは「グラス片手に」シリーズとか。
DBマガジン連載時によく読んでて会社のバックナンバー揃えて貰ったら
とたんに書籍が出おった・・・。

もうちょっと業務から設計よりになると「楽々ERDレッスン」も面白いです。
渡辺氏とは犬猿の仲。でも実装はこっちのが現実的かと俺は思う。

あとは本じゃないけど渡辺氏の公開してる
データモデルはいやーお世話になりました。
homepage2.nifty.com/dbc/
37 名前：NAME IS NULL mailto:sage [2008/11/16(日) 14:29:38 ID:???]: 今ひどい自演を見た
38 名前：NAME IS NULL mailto:sage [2008/11/16(日) 14:31:57 ID:???]: このまえ『データベース・リファクタリング』て本買って読んでたけど
結局ケースバイケースで全然逆のこと書いてあったりして、途中で
読むの放棄した。結局ケースバイケースのバランスなんだよ！
39 名前：NAME IS NULL mailto:sage [2008/11/16(日) 17:22:43 ID:???]: >>37
ばれちゃーしょうがーねーな

でも本はいい本だから読んでね
40 名前：NAME IS NULL mailto:sage [2008/11/16(日) 19:33:51 ID:???]: まぁ、渡辺さんの本が良いってより他にあんまりないんだよな。
羽生さんは大規模システムもちゃんとやってきてる人なのかな？
ABDとか大きいレガシーシステムでどうせいっちゅーんじゃ、みたいな。

業務系は技術系と比べて情報少ないんで、
自分のやってることになかなか自信がもてない。
各社ごとではちゃんとノウハウたまってんのかね？
41 名前：NAME IS NULL mailto:sage [2008/11/16(日) 22:20:46 ID:???]: >>40
貯まってたら3Kとか最下層とか言われて無いだろｗ
42 名前：NAME IS NULL mailto:sage [2008/11/17(月) 02:58:17 ID:???]: >>40
そうですね・・・他にないってだけかw
だけっていっちゃ悪いか。

業務系、バッドノウハウは立派にたまってましたねぇ。
とくに大手製造業の子会社行った時は恐れ入った。
43 名前：NAME IS NULL mailto:sage [2008/11/19(水) 00:11:57 ID:???]: 全てのテーブルは主キーをもつべきですか？
44 名前：NAME IS NULL mailto:sage [2008/11/19(水) 00:23:52 ID:???]: リレーションテーブルは要らないかも
複合インデックスさえあれば
45 名前：NAME IS NULL mailto:sage [2008/11/19(水) 00:38:37 ID:???]: あったほうが楽じゃね。
46 名前：NAME IS NULL mailto:sage [2008/11/19(水) 02:49:26 ID:???]: 例えばペットショップのＤＢを作るとして
犬テーブルと猫テーブルとかってわける？
動物テーブルでまとめる？
47 名前：46 [2008/11/19(水) 02:53:38 ID:PDW1LNDk]: 別の言い方をすれば、
複数のテーブルで一意なIDが欲しくなった時どうする？
48 名前：NAME IS NULL mailto:sage [2008/11/19(水) 03:04:51 ID:???]: >>46
動物テーブルで分ける
ＩＤ＋種別（イヌ/ネコ/ハムスター・・）
49 名前：NAME IS NULL mailto:sage [2008/11/19(水) 03:07:52 ID:???]: その場合、犬専用フィールドとか猫専用フィールドがあるならどうする？
動物テーブルには犬猫以外にも数十種の動物が含まれる
それぞれが専用フィールドを持っていたら？
50 名前：NAME IS NULL mailto:sage [2008/11/19(水) 03:09:43 ID:???]: ヌルだらけの巨大なテーブルが１つなのと
データがみっちり詰まった普通サイズのテーブルが複数なのと
どっちが良いか

後者にした場合、動物全体での一意ＩＤが欲しい場合どうするか？が問題になる
51 名前：NAME IS NULL mailto:sage [2008/11/19(水) 03:18:30 ID:???]: テーブルを犬猫で分けて、一意ＩＤ用１対多リレーションテーブルを作る場合

フィールド：一意ID、犬ID、猫ID、、、、

これだと動物の種類の数だけフィールドが必要で、
新しく動物の種類が追加された時にテーブルの追加だけでなく
ここへのフィールド追加もやらなきゃいけない。
テーブル追加だけで済んだ方が良い。
52 名前：NAME IS NULL mailto:sage [2008/11/19(水) 03:26:29 ID:???]: 色々書いたが
１つの巨大テーブルにするほうが
実用上の障害が思いつかない

誰か思いつく？
53 名前：NAME IS NULL mailto:sage [2008/11/19(水) 04:42:21 ID:???]: >>49
ＩＤ＋種別（イヌ/ネコ/ハムスター・・）＋属性
54 名前：NAME IS NULL mailto:sage [2008/11/19(水) 10:40:33 ID:???]: １つの巨大テーブルがいい人はExcelでもいいんじゃ？
55 名前：46 mailto:sage [2008/11/19(水) 16:21:28 ID:???]: >>53
それは属性テーブルを動物別に作って外部キーはるってこと？
結局>>51だと思うけど

今のところの結論としては、
動物テーブルでまとめて、動物別にビューを作るのがいいかなと
56 名前：NAME IS NULL mailto:sage [2008/11/19(水) 16:22:53 ID:???]: 一意ＩＤ用リレーションテーブル作っても同等の機能は達成できるんだけど
パフォーマンス的に不利だからね

かといってテーブル間の一意ＩＤが欲しいがために１つのテーブルにまとめるってのも
おかしいとは思うけどね
57 名前：46 mailto:sage [2008/11/19(水) 17:43:56 ID:???]: 一応、複数のテーブル間で一意ＩＤを得る方法はあるらしいんだが
単に一意ＩＤを振っても、あるＩＤがどのテーブルのどのレコードなのか
を特定できなきゃいけないからリレーションテーブルは必要なんだよね
そしてパフォーマンスの不利は避けられない

やはり動物テーブル＋ビューが最適と判断した
58 名前：NAME IS NULL mailto:sage [2008/11/19(水) 17:52:22 ID:???]: >>55
例えば明日からペットショップでマンモスハナアルキの扱いを
新たにはじめるとして、そんなマイナー動物一種類のために
巨大な動物テーブルのスキーマを変更するのもどうかと。

ID+共通データの動物リレーションと動物別リレーションに分けて
ある場合、ハナアルキ類のためのリレーション一つ作成して後は
幾つかビュー定義をちょこまか修正すれば完了。
既にストアされているデータへの影響は少なくて済むはずです。
59 名前：NAME IS NULL mailto:sage [2008/11/19(水) 17:53:20 ID:???]: >>57
下らなすぎてスルーしてたけど

> やはり動物テーブル＋ビューが最適と判断した

最適かどうかは場合によるわな。
NULLだらけの横長テーブルなんて保守したくないし。
パフォーマンスの不利がどれほどのもんかとかな。
60 名前：46 mailto:sage [2008/11/19(水) 18:13:15 ID:???]: >>58
そういえばテーブルへのフィールド追加って登録されてるレコード数に依存して負荷上がるのか。
でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？
WEBアプリフレームワークが自動認識してくれるような形で張るには、（つまりRDBの基本仕様上で張るには）
>>51みたいに動物の種類数だけフィールドを用意しないといけないと思うんだけど。
61 名前：46 mailto:sage [2008/11/19(水) 18:14:08 ID:???]: >>59
明確な答えを持っているなら教えてください。
邪魔がしたいだけならお帰りください。
62 名前：46 mailto:sage [2008/11/19(水) 18:17:11 ID:???]: 動物別テーブル側に動物テーブル上のIDを持たせて
動物別テーブルと動物テーブルを結合したビューを作っておけば良いのかな

その結合処理って高速に出来るのかな？
63 名前：NAME IS NULL mailto:sage [2008/11/19(水) 18:17:32 ID:???]: ここはお前の専用スレじゃないんで、私物化するなら出てってくれない？
64 名前：46 mailto:sage [2008/11/19(水) 18:18:38 ID:???]: >>63
スレに沿った話題であり問題はないと思います。
65 名前：NAME IS NULL mailto:sage [2008/11/19(水) 18:29:09 ID:???]: >>60
>でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？

基本的には>>62の通りで良いのではないかと。

アプリケーションフレームワーク云々は別として、Relational Database Model
に基づいて実装するなら、動物リレーションで各動物に一意な動物IDをキーと
して振って、種類別リレーションからはその動物IDを参照。
後は動物リレーションと各種類別リレーションの間に外部キー制約を定義。

種類別にIDを振っても良いけど、基本的には冗長になるので必要無いはずです。

あとこういう分割は普通に行われているので、実用的な速度で結合処理を実現
する方法についてはちゃんと解が存在しています。
インデックス等々に関して調べると良いのではないかと。
66 名前：46 mailto:sage [2008/11/19(水) 18:32:26 ID:???]: それで良さそう。
ありがとう。
67 名前：NAME IS NULL mailto:sage [2008/11/22(土) 03:29:20 ID:???]: >>44
あれ、もしかしてリレーションテーブルには各外部キーにインデックス張っても
意味ないの？
>>62
DB構築者がビュー作って使う利点ってあるの？
68 名前：NAME IS NULL mailto:sage [2008/11/23(日) 02:48:09 ID:???]: >>44は、リレーションテーブルに行われる検索はほとんどの場合
他の２つのテーブルを繋ぐ処理だけだろうって事。
69 名前：NAME IS NULL mailto:sage [2008/11/23(日) 02:50:12 ID:???]: ＤＢ構築者がビュー使う利点無かったら誰にあるんだよ
ビューの利点＝プログラムでＳＱＬ書かなくて済む、なんて理解してるんだったら
そんなの定数定義しておけば良いだけだしＤＢにビューなんて機能持たせる意味ないだろ
70 名前：NAME IS NULL mailto:sage [2008/11/23(日) 11:32:04 ID:???]: 設計レベルでビューは使わないだろうな
ビューは実装寄りの話だ
71 名前：NAME IS NULL mailto:sage [2008/11/23(日) 12:07:03 ID:???]: >>68
リレーションテーブルって複合インデックスのほうがいいんでしょうか
72 名前：NAME IS NULL mailto:sage [2008/11/23(日) 17:46:01 ID:???]: どんなインデックスもそうだけど、クエリによると思う。
73 名前：NAME IS NULL mailto:sage [2008/11/23(日) 21:17:09 ID:???]: ユーザーは複数の権限を持っている事がある
ユーザーは複数の組織に所属している事がある
ユーザーが特定の部門に属しているか、特定の権限を持っている場合ににのみ
特定のテーブルと1:1の関連を持たせる
しかし、権限や部門がが重複すると、そのたびにユーザーが抽出されるので
同じユーザーのデータなのに、複数データが出来てしまう。

こういうとき、どうするのが一般的なんでしょう？
74 名前：NAME IS NULL mailto:sage [2008/11/23(日) 21:48:57 ID:???]: とりあえず「組織」と「部門」の関連がよく分からないのですが・・・
DISTINCT一発で解決する問題のようにも見えます。
75 名前：NAME IS NULL mailto:sage [2008/11/23(日) 22:12:47 ID:???]: DISTINCT以前にもしかしてリレーションを理解してないんじゃないか
１つのユーザーテーブルに組織も権限も部門も全部つっこもうとしてるんだろ？
76 名前：NAME IS NULL mailto:sage [2008/11/23(日) 22:15:37 ID:???]: >>75
元のユーザーTBLがそういう感じなんよ
そこの部分はいじれない状況ということで許してくれ

やっぱり重複排除しかないのかねぇ
77 名前：NAME IS NULL mailto:sage [2008/11/23(日) 22:27:58 ID:???]: >>76
>元のユーザーTBLがそういう感じなんよ

もうテーブルが存在するなら、質問するときはそのスキーマの概略
程度でも示さないと。でないと答える方も>>74とか>>75みたいに無駄な
推理に頭を使う事になるでしょう？
78 名前：NAME IS NULL mailto:sage [2008/11/23(日) 22:37:37 ID:???]: >>77
すまん
79 名前：NAME IS NULL mailto:sage [2008/11/23(日) 22:51:55 ID:???]: リレーション理解してるならそんなの問題が既存のテーブル設計にあるの明らかだし
こういう糞テーブルの保守が必要なんですけど、って話すだろｗ
80 名前：NAME IS NULL mailto:sage [2008/11/24(月) 01:31:03 ID:???]: >>76
普通に再設計して既存アプリのインターフェース(元TBL型のVIEW)用意すればいんでね？
81 名前：NAME IS NULL mailto:sage [2008/11/24(月) 02:03:02 ID:???]: スレ違いかもしれんが、
郵便番号マスタ、市区町村マスタ、銀行マスタ、法定休日マスタ、和暦マスタ、消費税率マスタ
みたいなマスタテーブルを作ることに疑問を覚えるのは俺だけか？
何故、日本全国共通の情報を各々のDBに持ってちまちまメンテするんだろう？
疑問に思っちゃいけないことなのか？
82 名前：NAME IS NULL mailto:sage [2008/11/24(月) 02:11:33 ID:???]: ・パフォーマンス
・完全参照系データでしかもそれほど動的に変わるものではないからWebAPIにする価値無し
83 名前：NAME IS NULL mailto:sage [2008/11/24(月) 02:45:40 ID:???]: セキュリティ
84 名前：NAME IS NULL mailto:sage [2008/11/24(月) 02:59:24 ID:???]: セキュリティが一番大きいね
WebAPIにしたらどこの誰が利用してるか分かる可能性がある
85 名前：NAME IS NULL mailto:sage [2008/11/24(月) 09:37:58 ID:???]: 切り替えのタイミング
86 名前：NAME IS NULL mailto:sage [2008/11/24(月) 10:21:38 ID:???]: >>81
じゃあ、どうしろと？
87 名前：NAME IS NULL mailto:sage [2008/11/24(月) 13:27:15 ID:???]: >>81
その中でもファイルとして公開されてる物はある。
でも、提供先が国外だったりしてデータおかしかったりする物もある。

郵便番号なんかはバッチ処理でWebから落としてきて～ってどこでもやってるでしょ。
↑をメンテ処理って言ったらそれまでだけどｗ
88 名前：NAME IS NULL mailto:sage [2008/11/24(月) 15:37:55 ID:???]: NTPサービスみたいに、定期的に全自動的でデータが補正されるようにならんものかね。
この手のマスタを毎月（或いは毎年）メンテしてるやつらって、
ホントくだらない人生送ってるな思うよ。
89 名前：NAME IS NULL mailto:sage [2008/11/24(月) 15:59:02 ID:???]: つまり、>>88はそんな仕事をやらされている自分の人生にうんざりしているというわけだな。
90 名前：NAME IS NULL mailto:sage [2008/11/24(月) 16:09:58 ID:???]: いや、そんな仕事もまともにできない部下にうんざりしてる。
91 名前：NAME IS NULL mailto:sage [2008/11/24(月) 16:21:56 ID:???]: 全自動でやるシステムを提案すればいいじゃねーか
92 名前：NAME IS NULL mailto:sage [2008/11/24(月) 16:22:19 ID:???]: >>85の切り替えのタイミングと、切り替える際の責任の所在かなぁ。
俺様に無断で祝日増やしやがって馬鹿政府のこんちくしょう。

将来なんちゃらクラウドの上にテータベースに乗っけて運用するよう
になると、この手のマスターデータは標準部品として提供されるように
なるのでしょうか。
93 名前：NAME IS NULL mailto:sage [2008/11/24(月) 16:42:55 ID:???]: >>90
部下ねぇw
部下のことをくだらない人生送っていると思いながら、その仕事をやらせているわけか。
それが本当なら、そりゃまともにやろうという気がうせるだろう。
94 名前：NAME IS NULL [2008/11/24(月) 18:46:07 ID:4T2xxdv4]: そういや地方自治体のシステムなんか
国会で法律が変わるたびに各々の自治体で
ベンダーに依頼して改修してるんだよな。
後期高齢者医療制度対応とかさ。
この国はどんだけアホなんだろう？
95 名前：NAME IS NULL mailto:sage [2008/11/24(月) 22:59:03 ID:???]: >>94
ＳＩ企業にとっちゃ、仕事が増えるからいいんじゃない。
96 名前：NAME IS NULL mailto:sage [2008/11/25(火) 01:12:59 ID:???]: ピラミッド立てるのと一緒でみんな無駄だとわかってても
世の中がまわる為に必要だから止められないんだよ
97 名前：NAME IS NULL mailto:sage [2008/11/25(火) 01:28:14 ID:???]: 自治体のは無駄だと思うが
住所データとかは各ベンダーが持たないなら国がWebAPI提供するしかないし
今の形が妥当
98 名前：NAME IS NULL mailto:sage [2008/11/25(火) 03:17:40 ID:???]: >>94
>　後期高齢者医療制度対応とかさ。
上手に作られたシステムなら、マスターの変更だけでＯｋ。
でも、テストは必要。
結局、ベンダーに発注するしかない。
99 名前：NAME IS NULL [2008/11/25(火) 11:32:56 ID:rHJnodNO]: 全体最適化とかまったく考えず各々価格だけで競争入札するから結果的に無駄に税金がかかる。
道路や建物つくる感覚で発注してるんだろうね。
100 名前：NAME IS NULL mailto:sage [2008/11/25(火) 15:22:35 ID:???]: ＤＢ設計を語るスレが制度設計を語るスレになっている件。
101 名前：NAME IS NULL mailto:sage [2008/11/25(火) 17:56:35 ID:???]: このスレで聞いていいのかな
商品テーブルにジュース　ポテト　ハンバーガーって商品があって
この3つを組み合わせでバリューセットって商品を作りたいとすると
商品テーブルのバリューセットの主キーとジュースの主キーを組み合わせるテーブル作ればOKだよね？
102 名前：NAME IS NULL mailto:sage [2008/11/25(火) 18:04:20 ID:???]: バリューセットっていう１商品で別に他とつなげる必要があると思えんが
103 名前：NAME IS NULL mailto:sage [2008/11/25(火) 18:08:08 ID:???]: そもそも４行目の意味が分からん
お前は同じテーブル内のレコードを繋げるリレーションテーブルを作ろうとしてるのか
別にそれでも実装上の問題はないのか・・・
104 名前：NAME IS NULL mailto:sage [2008/11/25(火) 18:18:18 ID:???]: >>102
この商品はこの3つの商品の組み合わせですみたいな感じで
セットの値段とバラの値段を表示したいなと思いまして。
>>103
実装上は大丈夫なんですが、もっといい方法があるかなと思って質問させて貰いました
105 名前：NAME IS NULL mailto:sage [2008/11/25(火) 18:58:29 ID:???]: 全てのバリューセットが主菜(ハンバーガ)・副菜(ポテト)・ドリンク(ジュース)の
三点セットなら、バリューセットのキーと主菜・副菜・ドリンクのキーの計4つの
キーを含むリレーションを作成。

セットによって副菜が2つになったりドリンク無しだったりと構成要素が大きく
異なる場合はバリューセットのキーと構成要素のキーを含むバイナリ
リレーションで表現。
106 名前：NAME IS NULL mailto:sage [2008/11/25(火) 19:17:48 ID:???]: 商品テーブル（IDと名前とその他共通属性）

単品テーブル（商品テーブルID＋その他属性）

セットテーブル（商品テーブルID＋その他属性）

単品セット間リレーションテーブル（単品テーブルＩＤ＋セットテーブルＩＤ）

これでセットメニューがどんな構成だろうと対応出来るぞ
バイナリも使う必要ない
107 名前：NAME IS NULL mailto:sage [2008/11/25(火) 19:29:56 ID:???]: >>105
>>106
ありがとうございます。
家帰ったらテーブル作ってみて試してみます！
108 名前：NAME IS NULL [2008/11/25(火) 19:30:26 ID:Y/2zDRqR]: ありゃ、誤解があったようで、

>単品セット間リレーションテーブル（単品テーブルＩＤ＋セットテーブルＩＤ）

これがまさに、バイナリリレーション(binary relation: 二項関係)ですね。

あとこの手のスキーマ設計の場合、

・単品商品とセット商品の共通部分を商品テーブルとして切り出す
・単品テーブルとセットテーブルはそれぞれ共通属性も含めて保持
全商品の共通属性に関しては別途商品ビューを用意して参照

のどちらもアリなので、お好きな方をどうぞ。
109 名前：NAME IS NULL mailto:sage [2008/11/25(火) 23:18:29 ID:???]: まさにこんな問題が、テクデの過去問にあったな。
110 名前：NAME IS NULL mailto:sage [2008/11/26(水) 00:35:25 ID:???]: バリューセットは難しいね。
原価とか利益をどう持つかで色々な設計のパターンが出てきそうだ
111 名前：NAME IS NULL mailto:sage [2008/11/26(水) 15:15:15 ID:???]: リレーションテーブル・・・・難しい言葉ですね・・・
112 名前：NAME IS NULL mailto:sage [2008/11/26(水) 15:18:27 ID:???]: 正しい言葉だと思うけど、何か意見があるなら聞かせて欲しい。
具体的な指摘をして欲しい。

俺がリレーションテーブルと言う言葉を使うのは、
マスタもテーブルもテーブルなのにおかしいと思うから。
かといってリレーションと言うだけではＦＫなども含まれてしまう。
113 名前：NAME IS NULL mailto:sage [2008/11/26(水) 16:16:47 ID:???]: >>112
>>111はなんだか意地悪な感じだね。
「リレーション」というのは「テーブル」の事を指します。
なので「リレーションテーブル」っていうと「犬ドッグ」的な感じになっちゃいます。
RDBの基となる関係代数からの用語ですが。
テーブル：リレーション
レコード：タプル
フィールド：カラム

テーブルとテーブルの関連のことは「リレーションシップ」と呼びます。
114 名前：NAME IS NULL mailto:sage [2008/11/26(水) 16:18:20 ID:???]: >>112
>マスタもテーブルもテーブルなのにおかしいと思うから。
>かといってリレーションと言うだけではＦＫなども含まれてしまう。
ってか、この２行の意味が分かんない。
115 名前：NAME IS NULL mailto:sage [2008/11/26(水) 16:29:01 ID:???]: >>113
それは文脈によらない？
DBの実装上の用語ではおかしい事は言ってないよ。

pgyougo.seesaa.net/article/21114655.html
マスタなのかテーブルなのかを明示したい場合、どういい分ければいいの？

リレーションとリレーションシップで言い分けるより通じる。
116 名前：NAME IS NULL mailto:sage [2008/11/26(水) 16:46:11 ID:???]: ついでに
homepage1.nifty.com/silabel/it/master_table.html

さらに、リレーションシップという言葉がＦＫを含む例は
mysql workbenchがある。
リレーションシップという言葉はＦＫもリレーションテーブルも含んで使われている。
リレーションシップを示す”テーブル”のみを表現する言葉を俺は知らない。
ここで言うテーブルとはRDBMSに対するSQLでcreate tableで作成されるもののみを指す。

関係代数における概念は、実際のRDBMSやその関連ソフトにおいて
「不都合なく実装出来る形」にしか実装されていない。
概念的に忠実に再現されているとは限らない。

マスタ＝基幹データ
（マスタと比較される文脈で出される）テーブル（俺がリレーションテーブルと呼ぶもの）＝マスタ間のリレーションシップを示したテーブル
テーブル＝マスタとリレーションテーブルを含んだもの（SQLでcreate tableで生成するもの）

果たして、この世に存在し得るデータ一般を表現する一形式を議論する場合と
ある業務のＤＢ設計を議論する場合で
同じ用語体系が使われるべきだろうか？
117 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:00:17 ID:???]: >>115
>マスタなのかテーブルなのかを明示したい場合、どういい分ければいいの？

ディメンジョンとファクトかな、と思ったりするのはOLAP畑の自分。
(いや、厳密に対応するわけではないのでツッコミは勘弁ですｗ)

>リレーションシップを示す”テーブル”のみを表現する言葉を俺は知らない。

このようなエンティティ間の関係だけを格納するテーブルを定義する
というのはデータベーススキーマ設計におけるベストプラクティスと
いうかデザインパターンの一つで、でもそれには決まり切った名前が
ない、という不幸なんでしょうね。

昨日もバイナリリレーションと書いてやばっ、と思ったらやはり誤解が。
言葉って難しいです。
118 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:01:12 ID:???]: と自分で出したページに「ディテール・テーブル」と言う用語がかかれてたから今後はこれを使うよ。
検索してもほとんど出てこないから通じない可能性が怖いけどね。

あとさらに言えば、リレーションがリレーションシップと同じ意味で使われる場合がかなり多い。
今検索して見つけた例
support.codegear.com/print/35960#5%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E9%96%93%E3%81%AE%E3%83%AA%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3
「テーブル間のリレーション」と言う言葉が使われている。
>>113によれば「ドッグ間の犬」だな。
119 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:06:02 ID:???]: 他人と話す時は、自分勝手な用語はつつしんだ方がよいと思う。
意味は通じるけど111のようなツッコミが入るのは不思議じゃない。
>>112で「正しい言葉だと思うけど」と言ってたけど、正しい言葉ではないだろ。
通じるけど。

>マスタなのかテーブルなのか
これはもう通じない。なにを言ってるの？

>リレーションとリレーションシップで言い分けるより通じる。
まともに勉強している人はリレーションとリレーションシップで通じる。
120 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:14:56 ID:???]: そもそもrelationとは米中関係のことらしいという件。
121 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:21:30 ID:???]: >リレーションがリレーションシップと同じ意味で使われる場合がかなり多い
誤用が広まっていても、正しいことにはならないよ。
日常会話ならともかく、開発のときは気をつけるべきだね。

そして
homepage1.nifty.com/silabel/it/master_table.html
は酷すぎ。信用しちゃいけない。
122 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:44:34 ID:???]: 確かにリレーションとリレーションシップは実際扱いにくい言葉だな

今話題になってるのは「関連テーブル」と呼ぶことが多いような気がする
T字形では「対照表」と呼ぶのかな

>>118のディテールテーブルというのは違うよね？
・単品テーブル
・セットテーブル
・単品セット関連テーブル
で言うと、単品テーブルの事をディテールテーブルと呼ぶ。

マスタ/ディテールという呼び方は、マスタ/トランザクションのマスタと用語が重複してしまうので、ヘッダ/ディテールとか親/子を使うようにしている。

>>121
>homepage1.nifty.com/silabel/it/master_table.html
>は酷すぎ。信用しちゃいけない。
ひどいね
123 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:47:40 ID:???]: >>119
＞自分勝手な用語は
一般的な用語しか使っていない。
リレーションテーブルと言う言葉はテーブルと言う言葉を含んでいてマスタと比較する文脈であれば問題は無いと思う。

＞これはもう通じない。なにを言ってるの？
一般的な用語であるかどうか検索して確認してから発言しろ。

>>121
酷すぎるという根拠は貴方の主観以外にあるの？
俺は検索と言う方法でそれが一般的な用語であると言う客観的な根拠を示したつもりなんだけど。
124 名前：NAME IS NULL mailto:sage [2008/11/26(水) 17:55:56 ID:???]: ディテールテーブルと言う言葉を上で使うべきかと書いたけど、
それは間違いだったね。
>>122の通りディテールテーブルと俺が言うマスタ文脈上のテーブルは意味が違う。
関連テーブルだと英訳すればリレーションテーブルになるけど、
もし英語で設計書かけと言われたらどう書くの？
125 名前：NAME IS NULL mailto:sage [2008/11/26(水) 18:18:41 ID:???]: さらに検索

q.hatena.ne.jp/1177173258
これのtbl_は恐らく関連テーブルを指してるだろうね。
マスタとトランが示されてるのに同列で語られるものは関連テーブルしかないからね。
本来の意味通りのテーブルならテーブル名の接頭辞にする意味ないからね。

72.14.235.132/search?q=cache:yznFGh5_EJ8J:questionbox.jp.msn.com/qa763441.html+http://www.leasekin.com/rodan/mag2pos/002/00046.htm&hl=ja&ct=clnk&cd=1&gl=jp
これも同じで、本当は質問者が遭遇していたのは「関連テーブルを指す”テーブル”」なんだろうけど、
回答者はテーブルという用語が文脈によって意味が変わる場合もある事に気付いてない。
本当にただのテーブルと言う意味なら質問者はマスタやトランと並べて質問しないだろうね。
126 名前：NAME IS NULL mailto:sage [2008/11/26(水) 18:30:04 ID:???]: ちなみにマスタという言葉も曖昧で実際のシステムの保守においては多様な意味を知っている必要がある。
blog.goo.ne.jp/xmldtp/e/a416473823c05b2b24108981b3025bad

結局、関連テーブルに対し適当な名前が付けられていない。
関連テーブル以外には名前が付けられている事があって、
単にテーブルと呼べば関連テーブルを指すと言うケースがある。
関連テーブルは英訳すればリレーションテーブルになってしまい、これも適当な用語ではない。
127 名前：NAME IS NULL mailto:sage [2008/11/26(水) 18:41:31 ID:???]: 突っ込みどころが多すぎてめんどくさい
128 名前：NAME IS NULL mailto:sage [2008/11/26(水) 18:43:50 ID:???]: >関連テーブルは英訳すればリレーションテーブル

バリューセットの例でいえばmany-to-manyの関連なので
「association table」かなぁ。
129 名前：NAME IS NULL mailto:sage [2008/11/26(水) 19:11:52 ID:???]: > q.hatena.ne.jp/1177173258
> これのtbl_は恐らく関連テーブルを指してるだろうね。
質問には「普通のテーブル」って書いてあるよw
普通のテーブルって何よ！！！
ってくらいの低レベルな質問者なので、こんなの引用されてもなあ

> 本当にただのテーブルと言う意味なら質問者はマスタやトランと並べて質問しないだろうね。
質問者はそのくらいDBについて分かってないだけでしょ。

>結局、関連テーブルに対し適当な名前が付けられていない。
「関連テーブル」でいいじゃん。

>単にテーブルと呼べば関連テーブルを指すと言うケースがある。
非常に特殊な低レベルのバカの場合だけだろ。
「リレーションテーブル」は正確ではないけど意味も通じるしいいけど
「マスタテーブルとディテールテーブル」を「マスタとテーブル」と表現するのは
だめすぎだよ。

> 関連テーブルは英訳すればリレーションテーブルになってしまい、これも適当な用語ではない。
relationship tableではいかんのか？

T字形だと「対照表」と呼ぶよな。
ネットで初心者が用語を混同して質問しているのをいくら挙げられても、なんにもならないよ。
130 名前：NAME IS NULL mailto:sage [2008/11/26(水) 19:17:56 ID:???]: ふと思ったけど
「マスタとテーブル」って汎用機時代のオッサン用語だったりするかも。
131 名前：NAME IS NULL mailto:sage [2008/11/26(水) 20:12:46 ID:???]: >>129
＞質問には「普通のテーブル」って書いてあるよw
その質問者が普通のテーブルが何を意味してるのかが分かってないから聞いてるんだよね？

俺が挙げたのは用語を混同している初心者の質問でなく、
用語を混同して設計されたＤＢの保守作業をする事になった初心者の質問だよ。
実際俺も保守作業において、実際のテーブル名及び設計書でそういう用語が使われていて知った。
事実、その用語を紹介しているサイトも紹介した。
マイナーだとしても認知されている用語なのは間違いないと思うが？

カタカナ化せず関連テーブルと呼ぶなら、
mst_ trn_ とつけて kanren_ってつけるの？
それとも普段からの呼び方は「関連テーブル」で設計書上では「rel_」とするの？
132 名前：NAME IS NULL mailto:sage [2008/11/26(水) 20:20:22 ID:???]: >>123
> >>121
> 酷すぎるという根拠は貴方の主観以外にあるの？
正しい事が書いてある項目を見つけるのが難しいっす
133 名前：NAME IS NULL mailto:sage [2008/11/26(水) 20:27:43 ID:???]: >>132
そのサイトに書かれている項目のうち何割が間違っていますか？
偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。

俺の認識では、確かに誤用かもしれないが確実にこの用語で作られたシステムはかなりある。
かなりのエンジニアに通じる。
全く認知されていない「勝手な用語」であると思えてしまう人が居るのは、単に知らないだけ。
と言う認識。
134 名前：NAME IS NULL mailto:sage [2008/11/26(水) 20:41:20 ID:???]: >>131
"rel_"とか"r_"とか"kanren_"とかなんでもいいけど"tbl_"とはしないよな。

ダメ設計者が関連テーブルに"tbl_"と接頭辞をつける事例はあるんだろうけども
それは積極的に「関連テーブルはtbl_とつけよう」とした訳ではないと思う。

ほんのちょっと、ほんのちょっとだけでも論理的に考える頭を持っているならば
「関連テーブルはtbl_」なんて考えるわけがないし。

>>133
>この用語で作られたシステムはかなりある。
じゃあ俺が寡聞にして知らないだけなんだろうね。
なるべくならそんな「エンジニア」さんとは仕事したくないけど。

件のサイト、２０件とかメンドクサイです。ただこの先参照する時には
眉につばをつけてみる、本を読んだり他で調べて自分で考えてみる、
ということをお薦めします。

スクリプト言語 = 文法が簡単なプログラミング言語
シーケンシャルファイル =「1行1データ」で表されるデータ。
トランザクション・ファイル = プログラムの処理の過程で削除されてもよいファイル
オブジェクト指向 = 既にあるものを組合せ、短期間でよりよいプログラムを作ること。
135 名前：NAME IS NULL mailto:sage [2008/11/26(水) 20:42:53 ID:???]: 追加。これももちろん違う
■テーブル
　マスター・データの関連データを格納したファイル
　またの名を「ディテール・テーブル」
136 名前：NAME IS NULL mailto:sage [2008/11/26(水) 20:43:35 ID:???]: >>135
というか汎用機時代はそうだったのかもしらん
137 名前：NAME IS NULL mailto:sage [2008/11/26(水) 23:17:28 ID:???]: >>130
汎用機出身のオッサンはテーブルのことを「ファイル」と呼んだりするからあなどれないw
138 名前：NAME IS NULL mailto:sage [2008/11/26(水) 23:19:51 ID:???]: >>134
>スクリプト言語 = 文法が簡単なプログラミング言語
これは間違ってはいないと思う
139 名前：NAME IS NULL [2008/11/26(水) 23:24:13 ID:v/u6t0ex]: >>138
かなり的を外していると思う。
140 名前：NAME IS NULL mailto:sage [2008/11/26(水) 23:32:56 ID:???]: >>133
>そのサイトに書かれている項目のうち何割が間違っていますか？
>偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
>それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。

なんという上から目線www
141 名前：NAME IS NULL mailto:sage [2008/11/26(水) 23:51:18 ID:???]: ＞本来の意味通りのテーブルならテーブル名の接頭辞にする意味ないからね。

テーブルなのかビューなのかファンクションなのか接頭語で分かるように
テーブル（オブジェクトとしてテーブルに分類されるもの）には全てT_を付ける、とか
珍しくも無いと思うけど。
142 名前：NAME IS NULL mailto:sage [2008/11/27(木) 00:38:24 ID:???]: >>137
コボラはDB屋の敵だ
143 名前：NAME IS NULL mailto:sage [2008/11/27(木) 01:29:46 ID:???]: >>141
それやるとDB側だけ変更でテーブル→ビューって置き換えた時にT_XXXってビューが出来る。
144 名前：NAME IS NULL mailto:sage [2008/11/27(木) 02:52:23 ID:???]: >>116
そんなアホサイトじゃなくて書籍を買って読んでみなよ。
お母さんにお小遣いもらってさ。
145 名前：NAME IS NULL mailto:sage [2008/11/27(木) 06:43:29 ID:???]: なんか実務経験とかがロクになさそうな厨房が
俺ルールを押し付けるスレって雰囲気だな。
146 名前：NAME IS NULL mailto:sage [2008/11/27(木) 19:36:08 ID:???]: どの辺が俺ルール？
147 名前：NAME IS NULL mailto:sage [2008/11/27(木) 20:23:03 ID:???]: コボラーのときは本当にテーブル単位でファイル弄ってただけ。
148 名前：NAME IS NULL mailto:sage [2008/11/29(土) 04:44:35 ID:???]: >>147
だからってRDBのテーブルを「ファイル」って呼ぶなよ
149 名前：NAME IS NULL mailto:sage [2008/11/29(土) 11:00:42 ID:???]: テーブル操作＝ファイル操作だから同じ事。
150 名前：NAME IS NULL mailto:sage [2008/11/29(土) 13:37:59 ID:???]: ファイルメーカー
151 名前：NAME IS NULL mailto:sage [2008/11/29(土) 14:38:32 ID:???]: >>149
同じ事なわけねーだろw
152 名前：NAME IS NULL mailto:sage [2008/11/29(土) 20:58:43 ID:???]: COBOLから見るとまったく同じに見える
ミドルウェアってえらいね
横に長いテーブルまんせー
153 名前：NAME IS NULL mailto:sage [2008/11/30(日) 02:02:41 ID:???]: 殺意が沸いた
154 名前：NAME IS NULL mailto:sage [2008/11/30(日) 02:14:29 ID:???]: ttp://homepage1.nifty.com/silabel/c_it.html
ここ作ってるやつもコボラっぽいな

ttp://homepage1.nifty.com/silabel/computer/cobol.html
> 1999年にはＹ２Ｋ対策としてＣＯＢＯＬを修正できるスキルが一時的に見直された。
って、コボラが問題をまき散らしてただけだろ。
もしかして将来の職のためにわざとやってたのか？
155 名前：NAME IS NULL mailto:sage [2008/11/30(日) 03:18:18 ID:???]: 実務の世界にいないのでどのような確執があるのか見当も
つかないのですが・・・

かつてDB屋さんとコボル屋さんの間で血で血を洗う闘争でも
あったのでせうか（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
156 名前：NAME IS NULL mailto:sage [2008/11/30(日) 05:29:09 ID:???]: 現在も戦いは続いている
157 名前：NAME IS NULL mailto:sage [2008/11/30(日) 06:02:15 ID:???]: >>155
メインフレームＤＢとUnix系ＲＤＢとだろ。
前者で使われている言語は主にＣＯＢＯＬ。
後者で使われている言語はかつてはＣ、現在ではスクリプト系言語などさまざま。

Unix系ＲＤＢの登場は1980年代で日本で普及しはじめたは1990年前後から。
メインフレームＤＢはもっと歴史が古くて1970年代から実用化されていた。
メインフレーム＝ＣＯＢＯＬのほうが20年以上先輩であるわけだ。

メインフレームＤＢで古くからあるものはＲＤＢ=リレーショナルデーターベースではない。
階層データーベースを使っているものが多い。ＤＢをアクセスするためにミドルウェア
が存在する。

まあ、歴史的にはこんなかな。とメインフレームを知らない俺が言ってみる。
階層データーベースにはテーブルというものがない。「ファイル」というのはそのせいか。
ものが
あって、
158 名前：NAME IS NULL mailto:sage [2008/11/30(日) 11:09:41 ID:???]: かゆ
うま
159 名前：NAME IS NULL mailto:sage [2008/11/30(日) 15:27:50 ID:???]: 別にCOBOLと言う言語が悪い訳でもないとは思うが、
コボルを扱う人間の設計には欠陥が多いのは事実ではあるな。
オマエラは一生２０年前のシステムのだけ見てれば文句はないのだが、
現代のRDBのシステムにクチを出してくると、ほぼプロジェクトは火を噴く結果になる。
160 名前：NAME IS NULL mailto:sage [2008/11/30(日) 18:43:39 ID:???]: 「俺たちの戦いはこれからだ」的な実情ですね。大変だなぁ。

先ほどの「横長のテーブル」もそういうCOBOL畑だった人が持ち込みがちな
「困った設計」なのでしょうか。
単に正規化に無頓着なのか、それともまた別の異なる設計論があるのか、
まるで異文化コミュニケーションですね。
161 名前：NAME IS NULL mailto:sage [2008/11/30(日) 19:59:12 ID:???]: ある程度、先入観が混じっている見方だけど、
メインフレームを使う金融系COBOL畑と言うのは、技術畑のエンジニアが
やった仕事ではなく、大昔のIBMのテンプレートを真似ただけの、
マニュアル仕事であって、競争とかそういうのは無い狭く閉じた世界の
物語と言う感触がある。

昔は昔なりの事情があるから全否定はしないけど、
老人から「俺は昔こんな事をしたんだぜ」と自慢げに話されても
「ふーん、大変でしたね」と言う感想しか沸いてこない。

JavaとかC#,Python,Rubyなんかは過去の反省と言うかそれなりの
理想を持って進化している言語であり、それらを選択するエンジニアは
「過去よりは少しはマシに」と言う未来に向かって試行錯誤するタイプなんだけど、
COBOL畑の人間は「俺はこう教えられた。俺は今までコレでやってきた。
これ以上俺は何も覚える気がない。俺は正しい」と人間的に
成長が止まっているタイプが圧倒的（ｗ）に多い。

さらにヤやこしいのが金融系と言う仕事が謎なステータスがあり、
そこでCOBOLがある程度ブイブイ言わせているので、COBOL畑の
人間が高給取りかつ増長している現実がある。
162 名前：NAME IS NULL mailto:sage [2008/11/30(日) 20:55:35 ID:???]: つかCOBOL馬鹿にするだけで、開発自体まともに理解出来てない奴がいるな。
163 名前：NAME IS NULL mailto:sage [2008/12/01(月) 00:48:22 ID:???]: 「俺は昔こんな事をしたんだぜ」
が自慢だけならいいが
「俺は昔こんな事をしたから、これからもこれでOK」
というおっさんが権力だけ持ってるのがうざい
164 名前：NAME IS NULL mailto:sage [2008/12/01(月) 01:46:40 ID:???]: 昔と今で技術に隔絶の差があるのになぜおまえらはおっさんにそれを伝えることができないの？
165 名前：NAME IS NULL mailto:sage [2008/12/01(月) 02:10:20 ID:???]: >>164
そこまで力がないからでしょ。
力があって理解せられてれば自慢じゃなくて添削依頼になる。
166 名前：NAME IS NULL mailto:sage [2008/12/01(月) 03:08:50 ID:???]: 添削依頼なんてならねえよ。社内上の立場ってもんがあらあ。
簡単にウン１０年の情報化の歴史を小僧っこに否定されてみろ。
167 名前：NAME IS NULL mailto:sage [2008/12/01(月) 14:17:25 ID:???]: >>166
話にならん
168 名前：NAME IS NULL mailto:sage [2008/12/01(月) 14:21:02 ID:???]: そんなこんなで日米の証券システムは、乳母車とスペースシャトルに例えられるくらいの差がついてしまったわけで
169 名前：NAME IS NULL mailto:sage [2008/12/01(月) 15:33:13 ID:???]: >>166
普通にされてるんだが・・・自分より10以上離れた年齢の人に。
そうでもないと思ってたがずいぶんとマシな所に勤めてたようだ。
170 名前：NAME IS NULL mailto:sage [2008/12/01(月) 21:25:43 ID:???]: ﾋﾟｺｰﾝ
171 名前：NAME IS NULL mailto:sage [2008/12/01(月) 23:26:52 ID:???]: 悲惨な前線での戦闘の話を聞き、自分の身の上が恵まれていることに
気が付いた>>169であった・・・。
172 名前：NAME IS NULL mailto:sage [2008/12/02(火) 17:56:54 ID:???]: >>161
残念だが、そういう人間はCOBOLやJava、C#にかかわらず非常に多い。

実際COBOLって方言が多くて、年代や機種によってさまざまに変化しているから
１つのシステムだけを延々やってた人以外は、毎回やり方を変えていたよ。
＃メインフレームだと新機能を使わないってルール付けしてたりもする。

システムそのものも、１００万件以上ならDBをキーをつけて並び替えて抽出するより
前件なめて、ソートして抽出したほうが早いという時代から、やっぱりちゃんと
抽出したほうが早いって切り替わる時期でもあったので、こちらでは常識でも
あちらでは非常識がまかり通っていた時代だよ。

＞さらにヤやこしいのが金融系と言う仕事が謎なステータスがあり
こんなの金融に限らずどこのシステムにもある。
JavaやC#で代替できないものはないし、そこだけJavaからCOBOLを
呼び出して実行してもいい。

どんな仕事の仕方をしてきたかで決まるのであって、どんな言語を使うかではない。

>>163
２０年前からそうだよ。そんなやつは今も昔も変わらず多い。

>>168
砂利を運ぶのに「カウンタックを作れ」と指示されて、カウンタックを作っちゃう日本と
ちゃんと目的にあったカスタマイズされたダンプを作るアメリカとの違いだよ。
173 名前：NAME IS NULL mailto:sage [2008/12/02(火) 20:18:19 ID:???]: JEFをUNICODEに完全に変換できないのが悩み。DB関係ねえ。
174 名前：NAME IS NULL mailto:sage [2008/12/02(火) 23:11:27 ID:???]: ２０年後「俺がやってたＣ＃ではな・・・」と自慢話をして、煙たがれる人もいるだろうな。

でもどうだろうな、技術というものはいつも同じスピードで進歩するものでなくて
ある時期に急激に進歩してその後停滞するものであるから
ＩＴ関連の技術は、今後２０年間あまり変わらないのではないかな
175 名前：NAME IS NULL mailto:sage [2008/12/03(水) 00:17:39 ID:???]: >>174
まだまだ変わる思うよ。
次の劇的な変化は、関数型言語が実用的なレベルになるくらいにハードが進化した時に来ると思う。
176 名前：NAME IS NULL mailto:sage [2008/12/03(水) 00:25:44 ID:???]: つか、今現在CやUNIXでそういうパターンの奴はいて、本人は気付いていない
というのがあるだろ。
COBOLerも、自分の技術は普遍的でメインストリームで、そこいらのPCのような
おもちゃとは違うと信じているし、それが時代遅れだとは露ほども考えていない
というのはおんなじだな。
177 名前：NAME IS NULL mailto:sage [2008/12/03(水) 00:26:52 ID:???]: DBはどうでしょうか。Relational database model自身はもうすぐ40周年
ですが、この次に別な何かは来るのでしょうか。
178 名前：NAME IS NULL mailto:sage [2008/12/03(水) 01:10:21 ID:???]: ＳＱＬを使わないデータベースが出てくるんでしょうかね
オブジェクトデータベースというのはどうなんでしょ
179 名前：NAME IS NULL mailto:sage [2008/12/03(水) 06:51:45 ID:???]: xmlを扱うデータベースは今までのRDBと毛色がやや違う程度で
チマチマ普及すると思うが、メインはRDBだと思われ。
180 名前：NAME IS NULL mailto:sage [2008/12/03(水) 22:54:59 ID:???]: 色々言われ続けながらも結局生き残ったもんなァ・・・
181 名前：NAME IS NULL mailto:sage [2008/12/03(水) 23:14:26 ID:???]: db4oもサンプル見るとすげぇって思うけどちょっと調べると・・・
182 名前：NAME IS NULL mailto:sage [2008/12/03(水) 23:48:06 ID:???]: 今扱っているDBスキーマには何十個もテーブルがありますが、
全てのテーブルでカラム数が2です。
スキーマ設計の欠陥でもネタスキーマでもなく、カラム数は
2で固定、という仕様のDBMSなのです。

このやり方でも大抵のデータを表現できる自信はありますが、
このやり方の時代が来ることも、また無いような気がします。
(内心は、あるかも、そんなときめきもちょっと感じています)
183 名前：NAME IS NULL mailto:sage [2008/12/04(木) 04:18:16 ID:???]: なにそれどういうDB？
184 名前：NAME IS NULL mailto:sage [2008/12/04(木) 23:53:14 ID:???]: >>182
そういう作りはちょっと考えてんだけど、実際にやってるとこあるんだなw
いまから趣味でつくろうとしてるOSSで試してみようかな・・・
185 名前：NAME IS NULL mailto:sage [2008/12/05(金) 00:05:17 ID:???]: MonetDBというDBMSです。

monetdb.cwi.nl/

RDB/SQLやXMLDB/XQueryを実装したパッケージとして配布されて
いますが、MonetDBのコアは二項関係だけをストアする最低限の
ストレージとそれを操作するアセンブリ言語で構成されています。
Javaアプリケーションに対するJavaVMのような、DBMSを実装して
実行するためのvirtual machineのように使えるソフトです。

大抵のデータ構造は二項関係の集合に分解して表現できるので、
目的のデータ構造を二項関係の集合に分解するルールを決めて、
後は使いたいクエリ言語をアセンブリ言語に書き下すコンパイラを
実装「出来れば」どんなデータ構造もクエリ言語もどんと来い、
そんな考えのDBMSです。
研究ではRDBやXMLDB以外にもGISやRDFDB/SparQLなんかも
実装しているみたいです。

実用向けではなく実験的なDBMSですが、SDSSという天文分野の
大きなDBをこれに乗せるプロジェクトも走っているようです。
更新系は弱いですが、参照系に関しては商用DBも上回ることも
あるようです。
186 名前：NAME IS NULL mailto:sage [2008/12/05(金) 03:51:53 ID:???]: バッチ処理に一晩コースだな。
リアルタイム更新のインターネット用途は不適っぽいな。
187 名前：NAME IS NULL mailto:sage [2008/12/05(金) 17:13:10 ID:???]: 仮に20カラムのリレーションが欲しければ代わりにテーブル20個
作っちゃえ、というやり方ですから行単位で参照したり更新したり
というOLTPアプリでは既存のRDBMSの実装の方が優れます。

基本は参照のみ、集約値の計算等のためにフルテーブルスキャン
を多用する、しかもどんなクエリが来るか事前に読めない(クエリを
決めうちしたIndexやMaterialized viewを使うことが出来ない）用途
を意図した設計のようです。

なのでOLAPやData mining、学術用のデータ解析など向けですね。
188 名前：NAME IS NULL mailto:sage [2008/12/05(金) 22:58:34 ID:???]: 設計の自由度は高いでしょうね。
性能は悪そう。
189 名前：NAME IS NULL mailto:sage [2008/12/06(土) 00:27:38 ID:???]: 設計の自由度は、あまり変わらないかな。
MonetDBのアセンブリ言語使って何かしようというのは相当変な事 orz
をしようという人だけであって、普通はSQLとかXQueryで使うはずです。

性能はDMやOLAPなどの用途に関しては相当に速いはずです。

実際のところ商用DBではSybase IQがよく似た設計を持っています。
(そもそもSybase IQは初期のMonetにインスパイアされたらしい）
なのでコラム単位のVertical fragmentationの用途と利点に関しては
次のSybase IQの記事が参考になります。

www.thinkit.co.jp/free/article/0707/8/1/

あとGoogle Tech Talkでの次期MonetDBの話も面白い。

jp.youtube.com/watch?v=yrLd-3lnZ58
190 名前：NAME IS NULL mailto:sage [2008/12/06(土) 02:26:08 ID:???]: つーかなんだな
OODBって結局一度もブームこなかったな
ポストRDB！！とか騒がれていたのに
191 名前：NAME IS NULL mailto:sage [2008/12/06(土) 13:57:59 ID:???]: だって遅いし。

実データをオブジェクト指向で扱うのって無理が有りすぎる。無限に要素を想定する事に成るし。
加工するにはオブジェクト指向で操作したほうが直感的では有るけど。
192 名前：NAME IS NULL mailto:sage [2008/12/06(土) 19:51:06 ID:???]: なんだかんだでSQLって良く出来てるよなぁ
ORでインピーダンスミスマッチとかよく言われるけど、
SQLからクラスとマッピングコード生成するスクリプトを書けば
いいだけだしな
何もＤＢ自体がOOである必要はねーよ
193 名前：NAME IS NULL mailto:sage [2008/12/06(土) 19:57:07 ID:???]: カラム数が２だとキーと値を持たせたら終わりじゃないの？
A りんご
A 100
A 青森産

B みかん
B 150
B 愛媛産

みたいに。
「このレコードは名称、このレコードは値段」とか判断付かなくない？
194 名前：NAME IS NULL mailto:sage [2008/12/06(土) 20:15:21 ID:???]: 「あれができない、これもできない」っていってたらキリがないだろw
195 名前：NAME IS NULL mailto:sage [2008/12/06(土) 20:17:37 ID:???]: そうだな。
判断付かなくて困るって程のことでもないし、いいのか。
196 名前：NAME IS NULL mailto:sage [2008/12/06(土) 20:37:18 ID:???]: >>192
無能は黙ってろ
197 名前：NAME IS NULL mailto:sage [2008/12/06(土) 20:53:52 ID:???]: >>193
カラム数は2で固定ですが、テーブル自体は沢山作る事ができるので、
この例だとキー:名称、キー:値段、キー:産地の三つのテーブルを作るのが
一つの解です。
各テーブルでキー->名称、キー->値段、キー->産地の関数従属性を表現
出来て、これらの三つからキー->(名称, 値段, 産地)の関数従属性を導出
出来ますから、この分解は無損失です。
198 名前：NAME IS NULL mailto:sage [2008/12/06(土) 20:58:29 ID:???]: 組織マスタ
組織
上位組織

社員マスタ
社員番号
役職

権限マスタ
権限

とあるときに、ある社員の役職が自分の所属する組織だけで通用する
権限を持たせるようにするにはどう関連を引けばいいの？
199 名前：NAME IS NULL mailto:sage [2008/12/06(土) 21:12:21 ID:???]: 外部キー無いじゃねぇかｗ
200 名前：193 mailto:sage [2008/12/06(土) 21:36:41 ID:???]: >>197
あー、そりゃそうだ。
名称と値段と産地が同じテーブルに入ってるという普通のDB的考え方がそもそも違うのか。
201 名前：NAME IS NULL mailto:sage [2008/12/07(日) 11:02:15 ID:???]: まあ総当たりで再利用考えなければｗｗｗ
202 名前：NAME IS NULL mailto:sage [2008/12/08(月) 01:00:44 ID:???]: >>200
MonetDBもSQLを使えば普通にnカラムのリレーションを作れますよ。
JDBCやODBCもあるので、ただRDBMSとして使う分にはMySQLとか
その辺のOSSのデータベースサーバと変わりません。

なんかMonetDBがとても普通でない変態DBみたいな誤解が生じても
アレなので、念のため。
2カラム限定なのは低水準のアセンブリ言語を直接使って変な事を
する時だけです。変態なのはDBMSではなく、私。
203 名前：NAME IS NULL [2008/12/09(火) 22:31:44 ID:8rN2YWi9]: すいませんトーナメント表を作りたいのですが
DBはどのように設計したらよろしいでしょうか？

こんな感じのドラゴンボールの天下一武道会みたいなトーナメント表です

　優勝
　　|
　|~~|
|~~~|~~~|
A 　B 　C
204 名前：NAME IS NULL mailto:sage [2008/12/10(水) 01:06:13 ID:???]: >>203

俺なら一試合一選手で1レコードにしてこうする

PK ID
対戦相手ID
X回戦（一回戦とか二回戦とか）
X試合（第一試合とか）
選手
勝敗フラグ
205 名前：NAME IS NULL mailto:sage [2008/12/10(水) 01:11:09 ID:???]: と思ったけど勝ち上がった後のキーもいるかな。
このやり方だとトーナメントの下から追うのはいいが上から追えないが。。。
206 名前：NAME IS NULL [2008/12/10(水) 19:07:05 ID:8RNJEsTT]: ちょっとみんなの意見をききたい

休日マスタのような、主キーを日付にしたいけど、時間はいらないってときに、
日付型でやる？数字か文字でやる？

日にちのみのと時間のみの型があるなら日にちのみの型でやるんだが、
日付型って時間とセットなんだよなぁ

日付型で時間入らないように制約つけるのがベスト？
207 名前：NAME IS NULL mailto:sage [2008/12/10(水) 22:25:29 ID:???]: レスしてもいいが貴様の態度が気に食わない
208 名前：NAME IS NULL mailto:sage [2008/12/10(水) 23:47:56 ID:???]: MSSQL2008なら日付単位でもてる
209 名前：NAME IS NULL mailto:sage [2008/12/11(木) 01:30:53 ID:???]: 日付型でやった方が型で制約つけれるし
日付関係の関数が使えるので日付でやる

変に文字列とか数値とかでやると後で型をキャストする必要がある時めんどいし。
210 名前：NAME IS NULL mailto:sage [2008/12/11(木) 06:36:02 ID:???]: ＞日付型って時間とセットなんだよなぁ

そうでないRDBMSもあるんだから、そういう環境依存な話されてﾓﾅｰ

漏れは日付は日付型を使う派。

そうしておかないと、あとでCOBOLerの様な人種が「9999-99-99」とかﾄﾝﾃﾞﾓ日付を入れて
アプリでﾄﾝﾃﾞﾓ実装をやりはじめそうだし。
211 名前：NAME IS NULL mailto:sage [2008/12/11(木) 19:06:44 ID:???]: >>210
むしろその制約のために日付を無理やり文字列管理ってDBがいかに多いか…
212 名前：206 mailto:sage [2008/12/11(木) 20:16:12 ID:???]: >>208
２００８はデータ型増えてるのか．．．

>>209
確かに日付関係の関数は便利だな。
自分で日数計算とかやってられんな

>>210
俺の中では、日付型は日にちと時間せっとなのがスタンダードで、
日にちだけとか時間だけとかの型があるほうが特殊だと思ってた
まあ、どっちにしろ環境依存といえばそうなんだが、
それ言いだすとまず環境を決めないと設計語れないしな

>>211
すまん、よく意味がわからん。
9999-99-99を入れたいがために、文字列で定義されているシステムが多いってことか？

まあ、やはり日付入れる項目には日付型使うほうがよさそうなんで、
やっぱりその方針でやるよう検討するわ。
213 名前：NAME IS NULL mailto:sage [2008/12/11(木) 20:48:31 ID:???]: >>212
>　9999-99-99を入れたいがために、文字列で定義されているシステムが多いってことか？
２０００年問題で有名になったYYMMDDというのがある。
214 名前：206 mailto:sage [2008/12/12(金) 00:19:34 ID:???]: >>213
いや、あるのは知ってる。YYnnnとかな
ＤＢ使わない、それこそコボラーな世界では普通だった。
その世界ではそれが間違ってるとは思ないが、
ＤＢ設計としてはどうなの？って話だ

いまどきメモリの１バイトは血の一滴ってわけじゃあるまいｗ
215 名前：NAME IS NULL mailto:sage [2008/12/12(金) 01:09:26 ID:???]: 日付で思い出した問題ですが、例えば

リレーション社員＜社員ID, 入社日, 退職日＞に対して、

(社員1, 1/1, 4/1)
(社員2, 2/1, 6/1)
(社員3, 4/2, 8/1)

(1) self joinして、在職期間が重なる社員のペアを抽出する

(社員1, 社員2)
(社員2, 社員1)
(社員2, 社員3)
(社員3, 社員2)

(2) 日付の期間でGROUP BYして社員をcountする事で、
　　リレーション在職者数(人数, 日付from, 日付to)を求める

(1人, 1/1, 1/31)
(2人, 2/1, 6/1)
(1人, 6/2, 8/1)

なんてクエリは、実務ではどのように実装しているのでしょうか？
こういうTemporalな演算を標準SQLで頑張る論文を読んだことがありますが、
結論は「出来ればこういう演算はDBMSで直接サポートしてくれぇ」でしたｗ
216 名前：NAME IS NULL mailto:sage [2008/12/12(金) 02:00:56 ID:???]: (1)はDATEDIFF関数で。（ORACLEとSQL Serverで若干書式が異なるが）

(2)は普通に入社日と退職日でGROUP BYしてCOUNT取れば出来ないか？
217 名前：NAME IS NULL mailto:sage [2008/12/12(金) 17:25:06 ID:???]: ＞俺の中では、日付型は日にちと時間せっとなのがスタンダードで、

ソレって主にOracleの事情だったっけ？
DB2,Postgre,MySQLは日付と時間を自由に出来たはずだが。
218 名前：NAME IS NULL mailto:sage [2008/12/12(金) 22:41:18 ID:???]: SQL Serverも2005までならそうだと思うが
219 名前：NAME IS NULL mailto:sage [2008/12/13(土) 15:20:28 ID:???]: 普通３２ビットだから、時間も一緒でしょ。
別に二つカラム持って、こっちは日時しか見ない、こっちは時間しか見ないでもいいと思うが。
どうせ日時の二倍データ量使うでしょ。

１バイトでも件数大量なら無視できないけどな。
オープンソースとかで安易に電網鯖構築してるとレスポンスめちゃめちゃ悪いサイトが出てくるのはそんな理由も大きい。
商品情報とか数万件じゃ済まないし。
220 名前：NAME IS NULL mailto:sage [2008/12/13(土) 18:13:10 ID:???]: ＞普通３２ビットだから、時間も一緒でしょ。

ナニを言っているのかよく解らんが、Oracleは間違っていないとか
そういう類の発言のつもりか？

DB2のDATE型は'2008-12-13'と10バイト使う(Verによりやや違うが)が'0000-01-01'～'9999-12-31'まで許す（紀元前は不可能)
MySQLのDATE型は'2008-12-13'で3バイト使うが'1000-01-01'～9999-12-31'しか許さない（のワリに'0000-00-00'を許すんだよな、意味は解るけど）
ナニが普通なのか知らんが、>>219の偏った知識の持ち主が「レスポンス云々」を
語るのは不思議な感じなんだが。

メモリの１バイトは血の一滴ではあるまいに、は賛同するが、
RDBMSを使う要件の多くは「数万件ですまない」ケースがほとんど」だしなー。
221 名前：NAME IS NULL mailto:sage [2008/12/13(土) 23:33:34 ID:???]: >>215
(2)は日付テーブルを持っておいて、1日ごとにジョインしたあとにgroup byして…
とかで出来そうだけど死ぬほどパフォーマンス悪そう。
プロシージャとかで必要に応じてデータ作るのが現実的な気がする。
222 名前：NAME IS NULL mailto:sage [2008/12/14(日) 06:39:14 ID:???]: timestampはデフォ３２ビットでおま。
223 名前：NAME IS NULL mailto:sage [2008/12/14(日) 07:16:32 ID:???]: >>221
(1) は社員AとBの在職期間のoverlapを判定するには合計4パターン
(A-B-B-A, A-B-A-B, B-A-B-A, B-A-A-B)を条件として書く必要が
あって、なので単純なDATEDIFF関数では力不足なんです。
Postgresにはその名もOVERLAPSという関数がありますが、こういった
関数を持たないRDBではどうしているのかなと。

(2)については、各社員の入社日・退職日を境界として全期間を細かく
ぶつ切りにして、個々の期間について各社員の在職期間とのOverlap
を判定して・・・と、さらに面倒な処理が必要になります。

いずれにしてもSQLで書くには結構大変なクエリで、でも実務の現場
では案外良くありそうなクエリなので、どうやって実現しているのか
興味がありました。やはりストアドプロシジャでゴリゴリでしょうか。
224 名前：206 mailto:sage [2008/12/14(日) 07:24:05 ID:???]: >>219
前半いわんとすることが全く理解できないんだが．．．
日付型が時間とセットでしか格納できな処理系で、時間を設定しない項目に
日付型を使うか否かというのが論点だったんだが．．．
>１バイトでも件数大量なら無視できないけどな。
これには同意
ただ、数万から数十万程度の件数でレスポンス悪化するようでは、
そもそもの設計がおかしいと思うぞ

>>220
ＲＤＢＭＳのオーバーヘッドを避けるためにＤＢをつかわないシステムを見たことがある
つまり、ＤＢつかう以上ある程度のオーバーヘッドは了承の上だと思う。
日付型が文字や数字より（ＤＢに格納する上で）ある程度のオーバーヘッドが生じるわけだが、
百万件オーダー程度ではあんまり考慮しなくていいかとおもってるんだが

>>222
それってどんなＤＢＭＳでもそうなのかね？
まあ、はじめに処理系依存な話をしだしたのは確かに俺だが、
特定のＤＢＭＳでしか通用しない話は、そのＤＢＭＳを明示してくれないか
ついでに聞くが、デフォで３２ビットってことは、変更も可能ってことかね？
225 名前：NAME IS NULL mailto:sage [2008/12/14(日) 07:52:35 ID:???]: >>223
在職期間の重なりを判定するならこれで十分だろ。

(A.入社日 < B.退社日 and B.入社日 < A.退社日)

(2)も、集計期間のリレーションが用意されているなら同じように可能。
226 名前：211 mailto:sage [2008/12/14(日) 08:13:55 ID:???]: >>212
すまん、遅レス。
俺が遭遇したのでは
「値が未設定の項目はHigh Valueをセットしましょう。日付のHigh Valueは99999999です」ってのとか
「99999999にしておきゃ日付範囲の検索時に有効だろうがJK」ってのとか
いずれにしろなんだその言い訳？みたいのばっかだったよ。

特殊パタンだと
「2008-12-32」を入れておきたいとか、「26:59:00」まで一日の範囲にしたいってのもあったな。
227 名前：NAME IS NULL mailto:sage [2008/12/14(日) 08:50:07 ID:???]: >>222
>>224

＞timestampはデフォ３２ビットでおま。
DB2のTIMESTAMP型は10バイトな。
Oracleは12バイト。（Verや使い方で9-11バイト）

日時関連の型は処理系や実装は各RDBMSでけっこう違う。
DB2だと'20081204'をINSERTすると例外出すが、MySQLはOKとかな。

>>226
まあ、日付は日付以上の意味はない罠。
判定したけりゃnullかどうかで判定汁。と言うのがDB屋としての回答ではある。

DB2だとINSERTの時に不正な日付は例外だすから、そこらは安心だ。
MySQLだとINSERTをスルーするから後の結果が怖いな。

＃違っていたらﾂｯｺﾐﾖﾛ
228 名前：206 mailto:sage [2008/12/14(日) 17:43:40 ID:???]: >>226
その手の話は、コボラーの時代には普通の設計だったな
まあ、未設定なら俺ならLow Value入れるがなｗ

特殊パターンは悩みどころだな
だが>>227 が言うように、
>まあ、日付は日付以上の意味はない罠。
>判定したけりゃnullかどうかで判定汁。と言うのがDB屋としての回答ではある。
というのが正しいスタンスなんだろうな

結局のところ、日付以上の意味合いを持つものを一つの項目に格納しようとするからそうなる
ＤＢ設計としてはそれはやめるべきだろうと理解した

ちなみに、たとえば、有効期限みたいな項目があったとして、
期限日が入ってる場合以外に、未設定と永久があって区別したい、とか言うと
未設定はNULLでいいとして、永久ってのは別途フラグかなんかで項目作るのが正しいＤＢ的設計？
229 名前：NAME IS NULL mailto:sage [2008/12/14(日) 20:22:51 ID:???]: 9999-99-99がでふぉ。
230 名前：NAME IS NULL mailto:sage [2008/12/14(日) 21:13:47 ID:???]: その日付型が持つHIVALでいいんじゃないのか？
'9999-12-31'と'9999-99-99'なんて現実的に同じ意味だし。
ただ単に9999-99-99を許すと今度は8888-88-88とか使いだすだろうし。
そんなつまらん理由の為、日付型の美味しいところを捨てるのはワリに合わんだけだし。

しかし、そういう実装はCOBOL等のバッチ屋はアタマ使わなくて済むかも知れんが、
UIを担当する部署(Webチームとか）から「ふざけんな」と言われるのがオチなので、
フラグで持つ方が親切だろうなぁ。

Web系のフレームワークと連動させるケースだと'9999-99-99'の実装は殺意しか
沸いてこない。

まあ、ここらも現代においてCOBOLerが嫌われる要因のひとつでもあるな･･･。
231 名前：211 mailto:sage [2008/12/14(日) 21:31:32 ID:???]: >>230
すげえ、あたりｗｗ
後から High Value ２って規格ができたよ。
もろ8888-88-88だった。
バッチ組の仕様でHigh Valueでも2タイプを判断しなくちゃいけなくて云々と説明されたけど、理解不能だったorz
UI側はただただ面倒臭くてたまんなかったわー。
他の項目の状態判断して、設定するHigh Value値を切り替えなきゃいけないんだから。
232 名前：NAME IS NULL mailto:sage [2008/12/15(月) 00:37:50 ID:???]: まあ、あいつらが'9999-99-99'や'8888-88-88'を好むのはメインフレームやらのホストの流派を組んでいる
からある意味仕方ないのはあるな。NULLと言う概念は存在しないし、データには
なんでもヘッダ(01)、データ(10)、トレーラー(88,99)とかつけたがるし。

COBOLerにはＳＱＬにある3値論理が理解できんのだろう。
コレもRDBを操作するSQLの基礎だと思うが、COBOLerはRDBを操作するのにSQLを使わないケースがあるし。

とは言え、RDBMSなんだからCOBOLerがSQLやらフレームワークを考慮してくれないと困るんだが
あいつらの上司はモノを知らんくせにやたら立場と態度がデカいのがウザいったらありゃしねぇ。
233 名前：206 mailto:sage [2008/12/16(火) 02:13:45 ID:???]: >>232
>データにはなんでもヘッダ(01)、データ(10)、トレーラー(88,99)とかつけたがるし。
さすがにそれはお前のとこだけだろうと思うが

>とは言え、RDBMSなんだからCOBOLerがSQLやらフレームワークを考慮してくれないと困るんだが
まあ、ＣＯＢＯＬとＲＤＢっていまいち相性悪いよな
そもそもＣＯＢＯＬ全盛のときはＤＢは実用的ではない場合がほとんどで、
ＤＢ導入するならＣＯＢＯＬもやめて作り直せば良いんだが．．．なかなかそういかない現実がある
234 名前：NAME IS NULL mailto:sage [2008/12/16(火) 19:16:08 ID:???]: 店舗ごとの品目売り上げ実績一覧テーブルがあるのですが、
品目一つに対して一列になっているため、
品目の調整がはいるたびに大変な状況です。
実績は金額、件数、率を含んでいるため
単純に列を行に移し替えることはできません。

こういった場合、実績の単位ごとにテーブルを分けて
管理するといった方法でよいでしょうか？
言い忘れてましたが、実績には対応するコードがあり
それで特定可能です。
（今はなぜか列名にそのコードが設定されていますが…）
235 名前：NAME IS NULL mailto:sage [2008/12/16(火) 20:34:23 ID:???]: >>232
COBOLerはCOBOLerで、「なんでCODASYL標準のDBMS使わないんだよ。」
と思っている希ガス。
236 名前：NAME IS NULL mailto:sage [2008/12/16(火) 22:48:38 ID:???]: 店舗マスタ(店舗コード、店舗名、住所・・・）
品名マスタ（品名コード、品名、値段・・・）
実績テーブル（実績コード、店舗コード、品名コード、実績、・・・）

こんな感じ？
237 名前：NAME IS NULL mailto:sage [2008/12/16(火) 23:02:45 ID:???]: 現状だと
実績一覧テーブル（みかん金額、みかん件数、みかん率、りんご金額、りんご件数、りんご率…）
になっている、という話？
238 名前：NAME IS NULL mailto:sage [2008/12/17(水) 00:52:18 ID:???]: >>236,237
今の構成としては
YYYYMM、店舗コード、実績001、実績002、実績016、実績003…
といった感じです。実績列の名前末尾三桁が実績コードです。
つまり、品目を特定するキーがないのが現状です。
前任者の意図としては、web側で出力するのに
SELECT一発で出せるようにということのようです。

>>236さんの方法ですと、実績の単位の型ごとに
列を持つことになるかと思います。
実績_金額、実績_件数、実績_率のように。
この場合、１レコードに対して、必ず２つのNULL列が出ますが
設計上良いものでしょうか。
他に案も浮かばないですが…。
239 名前：NAME IS NULL mailto:sage [2008/12/17(水) 08:18:50 ID:???]: 金額か件数か率かは実績コードから決まるんなら

実績テーブル（実績コード、店舗コード、YYYYMM、実績）

でいいんじゃない？
これをクロス集計すれば一発だと思うけど
240 名前：NAME IS NULL mailto:sage [2008/12/17(水) 18:41:13 ID:???]: >>239
はい、単位は品目コードで一意に識別できます。
今日ちょうどリーダーに同じ案を出したのですが、
違う単位の実績を同じ列に入れることに少し難色を示されました。
（実績単位ごとの列、テーブルを設けるという案でも同じような反応でしたが）
でも、>>239の方法が一番シンプルに
まとめられるやり方ですし、また話してみようと思います。

ありがとうございました。
241 名前：NAME IS NULL mailto:sage [2008/12/19(金) 10:35:49 ID:???]: どんなデータの集合体であればマスタとみなすのでしょうか？
イベントとリソースの分類で定型的な手法ってありますか？
242 名前：NAME IS NULL [2008/12/20(土) 05:53:23 ID:4lEGcef7]: 3つ以上のテーブルをjoinする場合、
一般的にどういう順番でjoinするのが速いですか？
243 名前：NAME IS NULL mailto:sage [2008/12/20(土) 06:25:23 ID:???]: >>242
大きいテーブルを先に持ってくる。
実データの入ったＤＢで計測するのが一番。
244 名前：NAME IS NULL [2008/12/21(日) 04:57:19 ID:Qp++Fn0M]: 過疎だメシウマ。

ところでテーブルに画面表示用のデータ入れたカラム容易したり、
アプリ依存の使いまわし効かないようなデータ入れたりって皆さんしてます？
DBの勉強は一通りしてみましたが、実務に当たってこのあたりの良し悪しに悩んでます。age
245 名前：NAME IS NULL mailto:sage [2008/12/21(日) 09:41:35 ID:???]: 普通はやるべきじゃない。
結果セットに直結する形のフォームや帳票のコントロールのせいで
そういう作りにしてしまってるものを見ることがあるが、
これは、ある種のバッドノウハウの類。
オンメモリで処理しにくいものだったらローカルDBを活用したらどうだろう。
246 名前：NAME IS NULL [2008/12/21(日) 15:34:35 ID:Qp++Fn0M]: >ローカルDB

成る程です。
例えば、DBサーバとAPPサーバが別々に存在したとする。
APP依存、固有のデータに関してはAPPサーバ側にローカルDBを構築して活用する感じですかね。

仮に予算や客都合でローカルDBを用意できない場合は、
せめてテーブルを切り分けて管理したいと考えてます。
しかしJOINが重なるとパフォーマンスや管理の面で劣る…
なかなか難しいですね。
247 名前：NAME IS NULL mailto:sage [2008/12/21(日) 18:55:34 ID:???]: SQL ServerのExpress Editionをその目的に使ったことがある。
他にもSQLiteとかSQL Server Compactがそういう目的に使える。
248 名前：NAME IS NULL mailto:sage [2008/12/21(日) 22:12:17 ID:???]: ローカルDBって、そんなのクライアントごとに固有の情報を保持するとかでもなきゃ
使わんだろ？サーバーサイドでわざわざ複数のDBに分ける理由はない。
>>246の別テーブルでというのが普通。その上で、アプリ固有の情報といっても
変更の可能性が低くて1:1あるいは1:0リレーションシップであれば1テーブルに
まとめてしまうくらい。
249 名前：NAME IS NULL mailto:sage [2008/12/21(日) 22:26:04 ID:???]: ＞ところでテーブルに画面表示用のデータ入れたカラム容易したり、
＞アプリ依存の使いまわし効かないようなデータ入れたりって皆さんしてます？

やらないし、やらせない。

それをやりだすと、アタマの悪い後任者が「ここにこのデータがあるから、コレ使えばいいじゃん。
オレ賢い！」と勘違いして、データベースの基本の「One Fact In One Place」の
理念がパーになる。そして黒歴史が始まる。
250 名前：NAME IS NULL mailto:sage [2008/12/22(月) 09:50:29 ID:???]: 一時表ならよくね？
251 名前：NAME IS NULL mailto:sage [2008/12/22(月) 13:24:18 ID:???]: 表示順とかどうすか
252 名前：NAME IS NULL [2008/12/22(月) 19:20:00 ID:7uJOOUG4]: 一覧ソート用とか
253 名前：NAME IS NULL mailto:sage [2008/12/22(月) 22:32:50 ID:???]: >>249
まともなドキュメントが作られてない or 作られていても後任の教育ができていない場合なら
そういうのも考えられるけれども、まぁ、設計の問題というより組織の問題だな。
254 名前：NAME IS NULL mailto:sage [2008/12/23(火) 08:06:38 ID:???]: 現実問題、組織の問題を言い出すと、外注丸投げや派遣ばっかなご時勢で
マトモなドキュメントやら教育云々なんて絵空事だよなぁ････。

そういうった組織を含めて「システム」と言うのだと思うが。

それにアタマの悪い管理者ほど「マニュアルがあれば誰でも出来るだろ」と
言い出す始末だしな。

「○○が出来ていれば」なんて絵に描いた餅なんて食べられないよ。
255 名前：NAME IS NULL mailto:sage [2008/12/23(火) 10:52:22 ID:???]: 手元にあるのはERDと現物のDBのみ、
カラムのコメントは歯抜けだらけ、
アプリの仕様書もない状態。

「このアプリの仕様を踏襲した新システムを作れ」
見えないルールを予測するエスパーたち。
誰かが言った。
「DBがシステムそのものだ」と。
そんな事判ってる。
ならせめて、そのDBの利用ルールを網羅した仕様書を用意しておいてくれ。
256 名前：NAME IS NULL mailto:sage [2008/12/23(火) 12:28:52 ID:???]: >>244の
＞画面表示用のデータ入れたカラム
＞アプリ依存の使いまわし効かないようなデータ
ってそれぞれ具体的にどんなの？
257 名前：NAME IS NULL mailto:sage [2008/12/23(火) 12:43:34 ID:???]: だから表示順なんかどうすか？と。
258 名前：NAME IS NULL mailto:sage [2008/12/23(火) 12:45:18 ID:???]: 表示順は無いとどうしようも無い場合も有るから
要・不要を語る意味が無いと思う
259 名前：NAME IS NULL mailto:sage [2008/12/23(火) 14:18:21 ID:???]: 要・不要の観点で誰も話してないと思うよ。

仮に同一DBを利用するアプリが増えた場合、
設けた表示順が利用できず、新たに用意する事もありえる話。
これってまさしくアプリ依存だよね。

で、この依存したデータたちをどう扱うべきかって流れかと。
260 名前：NAME IS NULL mailto:sage [2008/12/23(火) 14:19:04 ID:???]: じゃあ>>244への回答は
「してまーす」でいいわけね。

他にいい方法ないもんですかねー。
261 名前：NAME IS NULL mailto:sage [2008/12/23(火) 15:04:28 ID:???]: >>259
よくわからん。
マスタとかを別とすれば基本的にテーブル自体アプリ依存とかだと思うけど。
将来有るか無いかわからない他のアプリでの再利用とかまで考えるのがおかしな話だと思う。
262 名前：NAME IS NULL mailto:sage [2008/12/23(火) 19:32:27 ID:???]: ユーザーや端末依存の情報は他のテーブルと区別している。
他のテーブルと結合させないで、専用のクラスや関数でラップして読み書きさせてる。
たまたま、同じデータベースに同居しているというイメージ。
パラメータ系のテーブルもこれに倣っている。
263 名前：NAME IS NULL mailto:sage [2008/12/23(火) 22:58:50 ID:???]: >>261
特定アプリだけの専用DBなら、画面プログラマがO/Rマッパで生成するDBで充分だろう。

業務システムの場合、組織・人・商品のような共通データを一元化するべきだから、
きちんとDB設計することが重要になる。
264 名前：NAME IS NULL mailto:sage [2008/12/23(火) 23:05:50 ID:???]: >>263
＞マスタとかを別とすれば
265 名前：NAME IS NULL mailto:sage [2008/12/23(火) 23:37:10 ID:???]: >>264
マスタは不変の固定情報だけにしないと、時系列のデータを扱った時に矛盾してしまう。
例えば人の場合、生年月日はマスタ上の固定データで良いとして、
配属情報なんかは日々のトランザクションの中にあるわけで、
これを例えば、社員マスタに所属部署の列なんかを作って、常に最新の配属情報で
上書きしたら、そのテーブルは今日のデータとしてしか使えないし、兼務情報も得られない。
実際、いろんなアプリで共通に使うデータの多くがトランザクション上にあるから、
やはり特定アプリの表示用データなんかをDBに置くことには危険がともなう。
266 名前：NAME IS NULL mailto:sage [2008/12/23(火) 23:46:23 ID:???]: マスターテーブルにカラムを追加するのは問題だが
特定のアプリ用の独立したテーブルを作るのはいいんじゃないか
267 名前：NAME IS NULL mailto:sage [2008/12/23(火) 23:50:02 ID:???]: だね。
スキーマ分けて権限で制御とかなら分かるけど
DBに置いちゃダメってのは行きすぎだと思う。
268 名前：NAME IS NULL mailto:sage [2008/12/24(水) 00:32:17 ID:???]: ＞特定のアプリ用の独立したテーブルを作るのはいいんじゃないか

それこそDB上に保持する理由が解らんな。
テンポラリテーブルやＰＣのローカル上に落として好き勝手やるならともかく。
269 名前：NAME IS NULL mailto:sage [2008/12/24(水) 00:35:15 ID:???]: 思いつきなんだけど、hsqldbやfirebird,h2,oracle liteなんかの組込DBを、
今議題になってる各アプリ専用のDBとして、
基幹系DBと独立させる設計はどうだろう？
今、業務で扱ってるDBが監査用の設定が入ってて、
DDLとか大量検索が走ると警告メールが部署内に飛び交うんで、
あんま基幹系DBのスキーマを弄りたくない空気があるんだよね。
270 名前：NAME IS NULL mailto:sage [2008/12/24(水) 05:35:01 ID:???]: >>268
テンポラリテーブルやローカルDBじゃセッション間、クライアント間で共有できないだろ。
もしかして、そういう共有する必要のあるデータは全部「アプリ依存」じゃないと考えているとか？
271 名前：NAME IS NULL mailto:sage [2008/12/26(金) 07:15:53 ID:???]: >>270
クライアント間で共有と言う時点でその設計が糞だと言ういい証明なワケだが。
272 名前：NAME IS NULL mailto:sage [2008/12/26(金) 19:39:01 ID:???]: でもニーズとしてはクライアント間で共有したいって言われるのは自然。
そこでばっさり切り捨ててあいつ使えないなと思われるか、何か工夫してあげてあいつ神と必要な人間に評価されるかは、これからの正社員リストラで生き残れる分かれ目だったり。

組織の運営上は、きちんとマニュアル整備して、誰でもマニュアル通りに対応する体制にしてないと、監査も通らないし危機管理上もマズい。
情報やノウハウを属人化させてるから、退職だので、前任者居なく成ったとたんに困るんだよ。
273 名前：NAME IS NULL mailto:sage [2008/12/26(金) 23:15:51 ID:???]: 「特定のアプリ用のデータ＝共有の必要が無いデータ」で
「共有が必要だとすると設計がクソ」か。

またとんでもない決め付け厨が現れたもんだ。
274 名前：NAME IS NULL mailto:sage [2008/12/26(金) 23:33:33 ID:???]: 学生かなんかなのだろう
275 名前：NAME IS NULL mailto:sage [2008/12/27(土) 01:05:33 ID:???]: >>272
具体的にどんなニーズなんだろう。
なんかエンジニアが実力不足を言い訳で乗り切ろうとしているだけにしか見えんが。
276 名前：NAME IS NULL mailto:sage [2008/12/27(土) 01:09:34 ID:???]: 実力があれば、共有すべきデータをローカルのみに保持してても何とかなるらしいｗ
277 名前：NAME IS NULL mailto:sage [2008/12/27(土) 03:32:10 ID:???]: ちょっとわかった。
「特定のアプリ用のデータはローカルに置け」といってる人の言う「特定のアプリ」とは
「ローカルPC上からDBにアクセスして、個人的に何かをするツール」的なもののみを指してるに違いない。
それだと話が通る（というか噛み合わない理由がわかる）

そのツールだけで使うデータであり、ツールはその人以外誰も使わないのであれば
データをサーバーに置くべきでは無いわなｗ
278 名前：NAME IS NULL mailto:sage [2008/12/27(土) 03:41:57 ID:???]: 特定のアプリの位置づけ、それが扱うデータ

これがわからなければ議論はできない
279 名前：NAME IS NULL mailto:sage [2008/12/27(土) 09:14:51 ID:???]: なんかここの一部の人は具体例をださずに話をするのが好きだよなー。
会社の宿題をここで解決してるのがバレるのが嫌なんだろうか。

仮に前に話題に上った「特定アプリの表示用データ」なんか、
ほとんどの場合は共有するモンでもないと思うが、
「共用データをＤＢに置くオレカッコイイ、オレ神だぜ」と言うケースは
具体的になんなんだろう？と激しく疑問だったりする。
280 名前：NAME IS NULL mailto:sage [2008/12/27(土) 10:24:55 ID:???]: まあ特定アプリが何なのか詳細が分からないからなんとも。
281 名前：NAME IS NULL mailto:sage [2008/12/27(土) 10:46:01 ID:???]: ローカルって、端末PCのことを言ってたの？
オレはてっきり、Web/Appサーバに軽量DBMSかXMLか何かでUI層絡みの
データを置くのを、DBサーバに対して（Web/Appサーバの）ローカルと言ってると
思ってたんだが
282 名前：NAME IS NULL mailto:sage [2008/12/27(土) 15:59:13 ID:???]: >>279
逆に共用データをみんなが個別に端末に保存して
「オレカッコイイ、オレ神だぜ」って具体例を挙げてくれやｗ
283 名前：NAME IS NULL mailto:sage [2008/12/28(日) 02:28:30 ID:???]: >>281
それはローカルとはいわないと思う。
284 名前：NAME IS NULL mailto:sage [2008/12/28(日) 02:53:39 ID:???]: 毎日一回しか更新しなくていいけど量が膨大なデータとか？
業務アプリならその手のデータがほとんどかもしれない。過去１０年分ぐらいのデータなんてほとんど更新される事も無いし。
後はアイテム数膨大なアプリとか。１０万アイテムぐらいならいちいちオンラインでネット上をばんばんデ－タ流すよりも、ローカルにキャッシュして差分更新で扱ったほうが快適かもしれない。
285 名前：244 mailto:sage [2008/12/29(月) 00:57:50 ID:???]: 皆さんアバウトで申し訳ない。
ローカルというのはWebアプリ視点で物申しておりましたorz=3
つまりWebサーバー上にある軽量DBやXMLなどの事です。

一応、例を提示しておきます。

[DBサーバー]
　DB : Oracle
　　… 顧客情報、商品情報、販売情報、生産情報などが入っている。

[Webサーバー１]
　「販売管理システム」というWebアプリケーションが動いている。
　ローカルDB : Postgresql
　　… この「販売管理システム」依存のデータを管理。
　　　　例えば、「一覧表示用の順序データ」や「検索条件」、「ログ」など。

[Webサーバー2]
　「生産管理システム」というWebアプリケーションが動いている。
　ローカルDB : Mysql
　　… この「生産管理システム」依存のデータを管理。
　　　　例えば、「一覧表示用の順序データ」や「検索条件」、「ログ」など。

[端末にインストールされているシステム１]
　「商品開発支援システム」というVC++で作成されたWindowsアプリケーション。
286 名前：NAME IS NULL mailto:sage [2008/12/29(月) 03:02:11 ID:???]: 表現が悪い意味で「いい加減」「アバウト」なひとは気を付けてね
いくら良い設計しても、プログラマーに伝わらなければデスマの元だよ
287 名前：NAME IS NULL mailto:sage [2008/12/29(月) 03:05:44 ID:???]: >>285
そういうことは>>256-257辺りで早く言えｗ
288 名前：NAME IS NULL mailto:sage [2008/12/29(月) 17:10:41 ID:???]: 商品開発支援システムは直接オラクルにアクセスしてるのではなくて、販売管理システムか、生産管理システムにアクセスしてるとか？
統合して全部オラクルで共用データも含めて情報持っても良さそうだが。

システム付け足すのは簡単だっただろうけど、管理大変でしょ。あちこちにデータベース有って全部違うし。
そのうち経営情報システムとかで横断的に情報欲しい時にどこにデータが有るか探すの大変で嵌まると思うｗｗｗ
289 名前：NAME IS NULL mailto:sage [2008/12/29(月) 17:27:30 ID:???]: 業務ごとにDB立ててバラバラに情報持ち出して結びつけるキーも無くて
「なんとか統合してくれ」的なプロジェクトに参加したことがあるなー。
他社のDBの情報を利用するとか止むを得ない事情でも無ければ
分けたくないところ。
290 名前：NAME IS NULL mailto:sage [2008/12/29(月) 21:43:14 ID:???]: 285は一見きれいに作られてる風だけど、
>>288-289の言うとおりシステム統合とかで大変な感じ。
DB鯖にアプリ専用Tableが一番いいんじゃないかね。
291 名前：NAME IS NULL mailto:sage [2008/12/30(火) 05:43:43 ID:???]: teenage sex ってかんじ
292 名前：NAME IS NULL mailto:sage [2008/12/31(水) 11:18:09 ID:???]: そしてshotgun marriageに至と。
とりあえずシステムできちゃったから面倒見ろよと。
293 名前：NAME IS NULL mailto:sage [2009/01/05(月) 02:31:06 ID:???]: teenage sex って耳年増みたいな意味じゃなかったっけ？
理想論にかぶれて運用しにくい建付けにしたりってことかと。

でも最近のteenage sexは意味が違ってるよな確かに・・・
294 名前：NAME IS NULL mailto:sage [2009/01/07(水) 19:10:01 ID:???]: www.dotup.org/uploda/www.dotup.org4920.jpg

データーベースとはこのように設計するものなのか
295 名前：NAME IS NULL mailto:sage [2009/01/12(月) 16:24:21 ID:???]: 該当スレがわからないんですけどたぶんSQLスレじゃないと思うのでここで質問を。
例えで書籍のDBがあるとして書籍テーブルと著作者テーブルを著作者IDでつなげていたのですが
共著のものがでてきて今のままだと対処方法がわからなくなりました。
いちおう新たにテーブルを作って書籍IDと著作者IDを持たせ
本A＝著作者A、本A＝著作者Bの2レコードで表現できるようではあるのですが、
書籍テーブルとかぶって大半が無駄なように思えます。
他にうまいやりかたはあるのでしょうか。
296 名前：NAME IS NULL mailto:sage [2009/01/12(月) 16:41:45 ID:???]: 大概の場合は結果的にそれが一番無駄のない設計になる。
297 名前：NAME IS NULL mailto:sage [2009/01/12(月) 16:59:02 ID:???]: そういうものなんですか。
ではこのやりかたで進めようと思います。
ありがとうございました。
298 名前：NAME IS NULL mailto:sage [2009/01/12(月) 16:59:37 ID:???]: 一般的な多対多の解決法だね。
どうしてもっていうなら、追加するテーブルは「2人目以降のみを管理する」ことにすればレコード数は減るかもしれないけど
お勧めはしない
299 名前：NAME IS NULL mailto:sage [2009/01/12(月) 17:44:39 ID:???]: >>295
新たに作るっていうかそもそも「著作者テーブル」がそれじゃないの？
300 名前：NAME IS NULL mailto:sage [2009/01/12(月) 18:19:42 ID:???]: 著作者テーブルは書籍IDを含まないでしょう、多分。
301 名前：NAME IS NULL mailto:sage [2009/01/12(月) 18:36:34 ID:???]: >>295
言い忘れていたけど、仮に>>295の解決策をとるのであれば
書籍テーブルにあった著作者IDのカラムは削除した方が良い。
「書籍テーブルとかぶって大半が無駄なように」と書いてあった
ので一応補足します。
302 名前：NAME IS NULL mailto:sage [2009/01/12(月) 21:43:44 ID:???]: >>300
ああすまん、著作者じゃなくて295で作ったという関係テーブルのこと
>>301
それはないだろ
303 名前：NAME IS NULL [2009/01/16(金) 00:30:44 ID:aohFMQX5]: >>302
＞それはないだろ

いやあると思いますよ。下のようにするのが一般論だと思います。

[書籍テーブル]　キー：書籍コード
書籍コード、書籍名

[著作者テーブル]　キー：著作者コード
著作者コード、著作者名

[書籍・著作者リンクテーブル]キー：書籍コード、著作者コード
書籍コード、著作者コード
304 名前：NAME IS NULL mailto:sage [2009/01/16(金) 23:33:46 ID:???]: >>303
それが295だ。ちゃんと流れを読め。
305 名前：NAME IS NULL mailto:sage [2009/01/17(土) 00:26:21 ID:???]: >>303
フォローどうも
>>304
いや、301で書いたのは、単著の書籍だけの頃はきっと

[書籍テーブル(単著だけ)]　キー：書籍コード
書籍コード、書籍名、"著作者コード"

のようなスキーマだったろうから、この書籍テーブル(単著だけ)から
"著作者コード"のカラムは不要なので削除した方がよい、ということ
です。
306 名前：NAME IS NULL [2009/01/17(土) 01:59:35 ID:VBakR5WF]: >>304

お前がちゃんと読め
307 名前：NAME IS NULL mailto:sage [2009/01/17(土) 02:01:07 ID:???]: >>305-306
だめだこりゃ
308 名前：NAME IS NULL mailto:sage [2009/01/17(土) 02:10:59 ID:???]: どうだめか言ってもらえると
309 名前：NAME IS NULL mailto:sage [2009/01/17(土) 02:51:42 ID:???]: 14 ：すずめちゃん(四国地方) [] ：2009/01/17(土) 00:55:57.15 ID:fadPh4uo (2/17)

T_顧客マスタに【2008年度】のデータがあることが発覚！

日付のところ2008年になってるのがちらほらある
mj.dip.jp/jlab-beer/s/test1232112051347.jpg
310 名前：NAME IS NULL mailto:sage [2009/01/17(土) 02:52:15 ID:???]: >>309
この設計ってどうよ。
311 名前：NAME IS NULL mailto:sage [2009/01/17(土) 12:44:39 ID:???]: >>309
どういうことなん？これ
312 名前：NAME IS NULL mailto:sage [2009/01/17(土) 13:16:26 ID:???]: >309
登録年月日と変更年月日が同一のデータばっかりってな話？
313 名前：NAME IS NULL mailto:sage [2009/01/17(土) 13:18:50 ID:???]: あー判った。
「変更年月日 < 登録年月日」のデータが存在するって話か。
例えば、「顧客コード」が 000020 のレコード。
314 名前：NAME IS NULL mailto:sage [2009/01/17(土) 13:20:04 ID:???]: つーか、初っ端のレコードからそーなってるなw
315 名前：NAME IS NULL mailto:sage [2009/01/17(土) 16:43:09 ID:???]: で何のデータなの？これ
316 名前：NAME IS NULL mailto:sage [2009/01/17(土) 23:26:13 ID:???]: SQL（MySQL、PsotgreやMSなど特定RDBMSではなく標準的なSQL）と
DB構築に関する基礎を学ぶのにお勧めの書籍・サイトないでしょうか。
317 名前：NAME IS NULL mailto:sage [2009/01/18(日) 00:59:39 ID:???]: SQLはポケットリファレンスで十分だと思う。
DB構築はどこを指しているかによる。
318 名前：NAME IS NULL [2009/01/18(日) 01:00:56 ID:tHveqmjS]: 汚い設計だなあ
いいからしゃぶれよ
319 名前：NAME IS NULL mailto:sage [2009/01/19(月) 15:43:47 ID:???]: Dateの標準SQLガイドがDate先生の辛口も読めて勉強になるけど高いよね・・・
320 名前：NAME IS NULL mailto:sage [2009/01/30(金) 17:33:52 ID:???]: このチンカス設計クセーぞｗｗｗ
全部舐めとれよ。
321 名前：NAME IS NULL mailto:hage [2009/03/08(日) 18:49:29 ID:???]: スレチと言われたんでこっちで。

SQL質疑応答スレ 8問目
pc11.2ch.net/test/read.cgi/db/1236253554/46
>>46
正規形のなかで第1正規形だけは異質とされている通り、これだけは純粋に
モデリングと区別できる正規化とは言えないですね。第2正規形以上の「正規化」は
従属性を「保持」したままスキーマを操作するものであるのに対し、非正規形から
第1正規形にする操作は逆にリレーショナルモデルに落とし込む際に失われた
従属性を修復する操作であるとも言えるので。

いずれにせよ、第1正規形でないものは本来のリレーショナルモデルとは言えない
という意味において、それがモデリングの問題であることには違いはないということと、
スキーマだけ見てそれが正規形かそうでないか議論することはナンセンスであると
いう点では>>46に同意するけど。
322 名前：NAME IS NULL mailto:sage [2009/03/08(日) 18:54:43 ID:???]: で？
323 名前：NAME IS NULL mailto:sage [2009/03/08(日) 19:54:16 ID:???]: >>321
第一正規形が異質な点はその通りだと思います。
以下雑談なのでちょっとくだけた言い方になりますが、私は恩師の指導が
珍妙とくしゅだったせいか、リレーションがあまり好みではありません。
所詮は関数を実装したり表現したりする方法の一つだよね、その程度です。
なので入れ子リレーションも多値関数や高階関数ですね、そうですか、
良いんじゃない？ぐらいの認識です。

ただ非第一正規形から第一正規形を作るにはデータ構造中に含まれている
ヘンテコ関数全てにトドメを指さないといけないので2NF以下続く正規化とは
異なりデータ構造が当然大きく変化しますし、データモデリングとも絡んで
突っ込むと実は案外面白い問題だと考えています。

ただあのスレでがっかりだったのが、ただ「勉強しろ」「正規化しろ」という
コメントが続いた事です。
ちょっとひどいと思ったので>>13と>>15のスキーマを示して「データベース
理論的にどう異なりますか」と聞いてみたら「正規化について基礎から勉強
しなおそう」と返されました。おぉ～い、もう正規形だよｗ
他方で誰もデータ設計については言い出さなかったので、あのような流れに
なりました。
324 名前：NAME IS NULL mailto:sage [2009/03/08(日) 21:21:26 ID:???]: 向こうで言えない愚痴を言いたいだけならスレチ
325 名前：NAME IS NULL mailto:sage [2009/03/08(日) 22:16:22 ID:???]: >>324
愚痴の部分は申し訳ない。
326 名前：NAME IS NULL mailto:sage [2009/03/08(日) 23:05:05 ID:???]: >>321
Javaとかのオブジェクト指向な言語で、
dogクラスはanimalクラスを継承して、って学習のネタで言われるなんだろうけど、
実務で使うケースとかフレームワークが既に決まっている場合とかだと、
それらを考慮してＤＢ設計した方がみんなが幸せになれるので、
2chでああいった質問ってほとんど意味ないとｵﾓ。
327 名前：NAME IS NULL mailto:sage [2009/03/09(月) 02:17:57 ID:???]: >>324
向こうで設計の話を延々と続けたら確かにスレ違いだが、そこでの回答が
ひどかったと言うのにスレ違いもなにもないじゃん。
言ってることはむこうの「正規化勉強しろ」ってレスと変わらんわけだし。

それにしても、この板でCOBOLerを馬鹿にする人は多いけど、こういう
話題を振っても反応がそのCOBOLerと同じなんだから笑ってしまうよな。
328 名前：NAME IS NULL mailto:sage [2009/03/09(月) 22:27:26 ID:???]: とCOBOLerが申しております。
329 名前：NAME IS NULL mailto:sage [2009/03/11(水) 17:55:10 ID:???]: >>321
私には面白かったです。
2chでこんな話が読めるとは思いませんでした。
これからも時々、何か書いてくれるとうれしいです。
自分はまだよくわかってないので、勉強します。

それにしてもカリー化という言葉を、DB板で見るとは思いませんでした。
自分はHaskellとかの関数型言語で知りましたから。

関係ないけど、↓この連載は面白いです。

ベンチャー社長で技術者で
el.jibun.atmarkit.co.jp/g1sys/
330 名前：NAME IS NULL mailto:sage [2009/03/12(木) 01:41:39 ID:???]: >>329
>カリー化という言葉を、DB板で見るとは思いませんでした。

実際スキーマを理解する際に便利な考え方です。
上司の変な教育のたまものですね。いちいち数学の言葉に
ブレイクダウンしないと気がすまない人です。
彼にいわせると、GROUP BYは逆関数なんだそうです(笑)。

あとその連載、読んでます
DB畑の人間としては納得出来るところが多いです。
331 名前：NAME IS NULL mailto:sage [2009/03/15(日) 00:44:22 ID:???]: >>330
>あとその連載、読んでます
>DB畑の人間としては納得出来るところが多いです。

あぁ、それまだやってるんだ。
大規模システムを知らない人風だったから読むの止めてまった。
332 名前：NAME IS NULL mailto:sage [2009/03/19(木) 12:40:57 ID:???]: 中学の図書館で簡単な読書感想文DB作ることになったんだけど

学生名から著者→タイトル→感想文表示
著者からタイトル→学生名→感想文表示

この２つをできるようにしたいんだけど、みなさんならどんなテーブル用意します？
１テーブルでいいのかな・・・？学生数は300人程です
333 名前：NAME IS NULL mailto:sage [2009/03/19(木) 14:16:14 ID:???]: 何を管理したいかによるかな。

同姓同名のケースがあるが学生名で学生の判別してかまわないか？
　出来ないなら別途学生番号を振りキーとする。
タイトルと著者を独立して管理するか？
　しないなら
　　学生のレコードの属性として保持すればよい。
　するなら、
　さらに著者とタイトルの関連は管理するか？
　　著者に対してタイトルが複数
　　共著の扱い
　同名タイトルや同姓同名の著者の扱いは？
感想文は学生の属性としてよいか？
　学生に対して感想文は１つか？学生の共同作成はないか？

こういったところは >>332でないと分からん。
334 名前：NAME IS NULL mailto:sage [2009/03/19(木) 14:38:04 ID:???]: >>332
私ならとりあえず、こんな感じかな。

テーブル
本: (本ID), タイトル
本著者: (本ID, 著者名)
学生: (学生ID), 学生名
感想文: (感想文ID), 学生ID, 本ID, 提出日, 題名, 本文

リレーションシップ
本.本ID 1-* 本著者.本ID
学生.学生ID 1-* 感想文.学生ID
本.本ID 1-* 感想文.本ID

本のタイトルや学生名が重複しても見分ける必要がないなら1テーブルでも良いけどね。
>>333 の言うとおり、要件によるよ。
335 名前：NAME IS NULL mailto:sage [2009/03/19(木) 16:02:58 ID:???]: 著者テーブルと
本テーブル作って
両者の関連で本著者にしないのはなんで？
336 名前：NAME IS NULL mailto:sage [2009/03/19(木) 18:01:14 ID:???]: 実際作るとめんどくさだと思う。がんがれ。

この辺とかノウハウ持ってる気がする。
pc11.2ch.net/test/read.cgi/db/1137309494/
成績管理システムを作ろう！２【社会貢献】
337 名前：NAME IS NULL mailto:sage [2009/03/19(木) 18:36:40 ID:???]: >>334
横からですが、妥当なテーブル構造だと思います。
338 名前：NAME IS NULL mailto:sage [2009/03/19(木) 19:24:09 ID:???]: 横からですが、読書感想文DBというアプリケーション自体に
興味あります。

実際に学内で何のためにどう使うのかなかなか想像が
難しい。学生名から感想文引っ張るのは何となく用途が
想像出来ますが、著者から感想文の集合を引っ張るのは
はて？と。
同じ著者の本を読んだ学生間で感想文の読み比べでも
するのかな。
339 名前：334 mailto:sage [2009/03/19(木) 21:26:21 ID:???]: >>335
本のデータの入力時に著者が同一人物か同姓同名かどうかは分からない(調べないだろう)から。

>>337
ありがとうございます。
340 名前：NAME IS NULL mailto:sage [2009/03/19(木) 22:24:07 ID:???]: >>339
なんで著者に限って同姓同名を許容するの？
同名の本や同名の学生は区別してるのに。
ましてや>>332の要件で著者から検索することが挙げられてるんだから
全く違う人が書いた本を一緒くたに表示するより
○○△△という著者は2人見つかりましたとかして選択させる方が良いだろうに。
341 名前：334 mailto:sage [2009/03/19(木) 23:17:28 ID:???]: >>340
私の場合、基となるデータを感想文(本のタイトル、著者名、日付、題名、クラス、出席番号、学生名, 本文)だけと想定したためです。

本はタイトル・著者名、学生は学生名・クラス・出席番号で一意に区別できるが、
著者名は、本を探してきて著者履歴などを確かめないと同一人物かどうかを断定できないと考えました。
また、本が見つからず適当に同姓同名を同じ著者として登録されても困るので、あえてテーブルを分けませんでした。

参照する側としては、確かに区別してくれていた方がより便利ですよね。
342 名前：NAME IS NULL mailto:sage [2009/03/19(木) 23:40:26 ID:???]: 分けるコストもたいしたことがないので分けちゃって良いと思うけど。
343 名前：NAME IS NULL mailto:sage [2009/03/20(金) 22:56:04 ID:???]: DBの話とはズレるけど著者名かぶっちゃっていいのかな。
俺が「夏目漱石」名義で本を出したり。
344 名前：NAME IS NULL mailto:sage [2009/03/21(土) 03:02:54 ID:???]: 時期的にペンネーム変えたりとかも有るしねえ。
345 名前：NAME IS NULL mailto:sage [2009/03/22(日) 03:17:18 ID:???]: >>343,344
それは、著作者と中の人の関係をどう管理するかの問題だな

著作者が同姓同名の別人の可能性があるのか？
複数の人間が一つの著作者として扱われる必要があるのか？
一人の人間が複数の著作者となることがあり得るのか？

このへんの要件を確定させれば決まってくる
ほかの人も言ってるが、要件をもうすこし詰めないとこれ以上の論議はむずかしいんじゃ

まあ、今回のは著作者やその著作（本）を管理するのが目的じゃないし、
著作者に対してそこまでシビアに考える必要はないと思うが
346 名前：NAME IS NULL mailto:sage [2009/03/22(日) 04:20:01 ID:???]: 著者からタイトルの時に苦労すると思うが。
347 名前：NAME IS NULL mailto:sage [2009/03/22(日) 04:32:51 ID:???]: >>346
それがあるかどうかって事だろ
348 名前：NAME IS NULL mailto:sage [2009/03/22(日) 06:27:09 ID:???]: ペンネーム変えたら別著者だろ
著者単位で考えればいいのに変に人間単位で考えるなよ
349 名前：NAME IS NULL mailto:sage [2009/03/22(日) 19:20:58 ID:???]: 入力する人間が
「この本を書いた山田太郎さんとこの本を書いた山田太郎さんは同一なのか」
ってのをいちいち調査しなきゃならん、ってのもな。
300人の中学校の読書感想文管理でそんなのいらんだろ。
350 名前：NAME IS NULL mailto:sage [2009/03/22(日) 20:05:19 ID:???]: そこまで言うなら、DBなんていらんがなーw
351 名前：NAME IS NULL mailto:sage [2009/03/22(日) 20:15:43 ID:???]: かといって、同じ著者名がずらっと並んでるのもどうかと思うが。
352 名前：NAME IS NULL mailto:sage [2009/03/22(日) 20:16:57 ID:???]: うわ、極論厨…
353 名前：NAME IS NULL mailto:sage [2009/03/22(日) 20:28:06 ID:???]: 何か行ったり来たりだな。スレが無駄に伸びる
354 名前：NAME IS NULL mailto:sage [2009/03/22(日) 20:32:40 ID:???]: あー>>352は>>350あて
355 名前：NAME IS NULL mailto:sage [2009/03/22(日) 21:07:11 ID:???]: やはり仕様がないとしようがないよ
356 名前：NAME IS NULL mailto:sage [2009/03/22(日) 21:47:55 ID:???]: >>355
はいはい面白い面白い、と
357 名前：NAME IS NULL mailto:sage [2009/03/23(月) 03:52:28 ID:???]: >>351
同じ著者名がずらっと並んでるってのはどういう事態を想定してるんだ？

同姓同名の著者名があったとして、それを区別する必要がホントにあるのか？

たとえば夏目漱石という著者がいたとして、
夏目漱石の著作としてみとめられてる本があったとする
その本の著作者は「夏目漱石」として認識してるのだから
その本を実際に書いたのが、猫の人だろうが>343の人だろうがゴーストライターだろうが、
その本の著作者は「夏目漱石」で何の問題があるんだ？
358 名前：NAME IS NULL mailto:sage [2009/03/23(月) 05:57:45 ID:???]: 暑苦しいよ。
結局仕様次第でしょ。
359 名前：NAME IS NULL mailto:sage [2009/03/23(月) 08:17:40 ID:???]: >>357
著者名を真の著者ごとに区別するって話に誤解してないか？
同じ名前の別人を区別するかしないかって話だと思ってたけど
360 名前：NAME IS NULL mailto:sage [2009/03/23(月) 09:07:07 ID:???]: >>359
それはそれで余計ややこしくなりそうな…
361 名前：NAME IS NULL mailto:sage [2009/03/23(月) 12:30:07 ID:???]: 前者だと思ってたってこと？
後者は区別しないほうがややこしいと思うが
362 名前：NAME IS NULL mailto:sage [2009/03/23(月) 12:36:54 ID:???]: 中学の図書館での運用だから管理するのは大人だとしても運用するのは中学生だろ
複雑にしすぎても最後はグダグダになるからある程度シンプルにした方がトラブルの
原因が少なくなると思うんだけどね
363 名前：NAME IS NULL mailto:sage [2009/03/23(月) 12:40:57 ID:???]: つまりどの方法がいいと？
364 名前：NAME IS NULL mailto:sage [2009/03/23(月) 15:28:35 ID:???]: >>362
>中学の図書館での運用だから管理するのは大人だとしても運用するのは中学生だろ

いやだから仕様を勝手読みしても仕方がないかと。
そんなことは>>332には全く書いていないしそれ抜きにどっちが
良いも悪いもないというか>>332はどこいったんだこんちくしょう。
365 名前：NAME IS NULL mailto:sage [2009/03/23(月) 15:31:56 ID:???]: 与えられた仕様の断片を用いて議論するのが楽しいんじゃないか
366 名前：NAME IS NULL mailto:sage [2009/03/23(月) 19:42:27 ID:???]: >>359
後者の同じ名前の別人、てのは、同じ著作者名で別人がいるってことだろう
前者も後者も同じことで、区別する必要がないんじゃないか、と思うが

断片での議論は楽しいが結論は出せんのがなぁｗ
367 名前：NAME IS NULL mailto:sage [2009/03/23(月) 20:51:41 ID:???]: 区別する必要がないってなんで？
368 名前：NAME IS NULL mailto:sage [2009/03/23(月) 20:59:56 ID:???]: 区別出来るように作ったスキーマを使って運用としては区別しない
のは簡単だけど、一度区別しないことを前提としてスキーマ作って
あとから区別出来るようにして下さいと言われると面倒くさい。

なので区別することを前提に作る方が後々都合が良いと思う。
どうせ大した手間じゃないでしょう。
369 名前：NAME IS NULL mailto:sage [2009/03/23(月) 21:32:37 ID:???]: つっても夏目漱石Aと夏目漱石Bを区別するためには
「夏目漱石Aが書いた本一覧」と「夏目漱石Bが書いた本一覧」をデータとして持つ必要があって。
全書籍・全著者についてそういったデータを持つかっつーと絶対やらないだろ。
感想文にはISBNを必ず記入すること、とかの方が現実的か。
370 名前：NAME IS NULL mailto:sage [2009/03/23(月) 22:04:26 ID:???]: >>369
>「夏目漱石Aが書いた本一覧」と「夏目漱石Bが書いた本一覧」をデータとして持つ必要があって。
371 名前：NAME IS NULL mailto:sage [2009/03/23(月) 22:05:34 ID:???]: やるのが当然だろ
372 名前：NAME IS NULL mailto:sage [2009/03/23(月) 22:53:47 ID:???]: >>371
当然の意味が分からん
373 名前：NAME IS NULL mailto:sage [2009/03/23(月) 23:01:59 ID:???]: で、>>332氏は？
374 名前：NAME IS NULL mailto:sage [2009/03/23(月) 23:26:12 ID:???]: >>371
全書籍・全著者って、感想文が提出されたものに限った話じゃないよ。
（提出された分だけ持ってても登録時に識別の役に立たない）
375 名前：NAME IS NULL mailto:sage [2009/03/24(火) 03:46:27 ID:???]: ISBNが現実的だな。
ISBNで管理して、著者名とタイトルは、ISBNから紐付けるべき。
376 名前：NAME IS NULL mailto:sage [2009/03/24(火) 06:58:31 ID:???]: >>374
感想文が提出されたものだけでいいじゃん
377 名前：NAME IS NULL mailto:sage [2009/03/24(火) 07:39:41 ID:???]: >>376
提出の度に毎回調べて登録するんですね。分かります
378 名前：NAME IS NULL mailto:sage [2009/03/24(火) 09:21:51 ID:???]: 提出の度にデータ作成作業する気なのか？
379 名前：NAME IS NULL mailto:sage [2009/03/24(火) 09:41:17 ID:???]: だからそこまで手間をかけて識別しないと困るほど
同姓同名の著作者が同一著作者じゃまずいのか？

そもそも同姓同名の別人な著作物なんてそんなにあるのかね
380 名前：NAME IS NULL mailto:sage [2009/03/24(火) 11:44:54 ID:???]: 著作者はIDで管理すりゃいいべ
IDから名前がひけるけど同じ名前の人だっている。
普通にやればこうなる
381 名前：NAME IS NULL mailto:sage [2009/03/24(火) 15:03:11 ID:???]: 同姓同名だと同じと見なす訳だな。
382 名前：NAME IS NULL mailto:sage [2009/03/24(火) 15:56:12 ID:???]: amazonで「坂本千尋」の本を探すと明らかに2人いるのがわかる。
最初は「こんな本も出してるのか、この人」とか思ってしまったぜ
383 名前：NAME IS NULL mailto:sage [2009/03/24(火) 16:27:22 ID:???]: 思ったんだけど、学生の名前を主キーに使っていいと主張しているのは、実は
名前を隠した332当人だけなんじゃないか？

本職の人間がそんなことを主張するとは俺には考えられん。よほどの新人なら
ともかく。

No.1335 ／懼懼｀ヽ ... - コピペ運動会
copipe.cureblack.com/copipe/2008/03/17/1335
384 名前：NAME IS NULL mailto:sage [2009/03/24(火) 20:56:21 ID:???]: >>383帰れ
385 名前：NAME IS NULL mailto:sage [2009/03/24(火) 22:46:07 ID:???]: メルビル守衛乙
386 名前：NAME IS NULL mailto:sage [2009/03/25(水) 02:52:05 ID:???]: >>383
学生の名前を主キーにしていいと主張してるひとって誰だ？
学生は同姓同名でも区別する必要があるってのは共通認識だと思ってたんだが
387 名前：NAME IS NULL mailto:sage [2009/03/25(水) 05:02:04 ID:???]: 図書館なんだから図書館DBの著者マスタを使えばいいんじゃね？
388 名前：NAME IS NULL mailto:sage [2009/03/25(水) 19:32:39 ID:???]: そういうのが存在していて、かつ連携できるとなれば全く話が変わってくるな
389 名前：NAME IS NULL mailto:sage [2009/03/25(水) 21:25:51 ID:???]: 図書館で使うのはおkだか、授業や研究で使うなら別ライセンスだろう。
390 名前：NAME IS NULL mailto:sage [2009/03/25(水) 21:34:25 ID:???]: 図書館のサービスだろｊｋ
391 名前：NAME IS NULL mailto:sage [2009/03/26(木) 00:28:03 ID:???]: おまえら、質問してる（＝作る）人間のスキル考えろよｗ
この程度でテーブルレイアウト丸投げするるような初心者がつくるんだから、
なるべく単純な要件ですました方がいいだろう、と
だから著作者の同姓同名なんて無視しといたら良いんじゃないかと言ってるんだ
392 名前：NAME IS NULL mailto:sage [2009/03/26(木) 01:53:44 ID:???]: そんなことしたら余計仕様と機能と運用が混乱するだろ
393 名前：NAME IS NULL mailto:sage [2009/03/26(木) 02:15:45 ID:???]: 結局は使いにくいって、全部やり直しに成るのがヲチ。
おまいらが毎度デスマってるいつものパターンじゃないか。
394 名前：NAME IS NULL mailto:sage [2009/03/27(金) 00:12:25 ID:???]: もうExcelでいいよ
395 名前：名無し募集中。。。 [2009/03/27(金) 00:25:42 ID:ZRXm0Q5j]: ExcelでいいならせめてAccessだろ
Excelの方が逆に接続とかめんどいわ
396 名前：NAME IS NULL mailto:sage [2009/03/27(金) 08:10:03 ID:???]: Excelのテーブルってことだろw
397 名前：NAME IS NULL mailto:sage [2009/03/27(金) 08:50:24 ID:???]: だとしたらもはやDB設計すら語って無いじゃないか
398 名前：NAME IS NULL mailto:sage [2009/03/27(金) 11:41:15 ID:???]: 自転車置場の議論 - bkブログ
0xcc.net/blog/archives/000135.html
399 名前：NAME IS NULL mailto:sage [2009/04/01(水) 00:44:14 ID:???]: Webベースのアンケートシステムを考えています。
基本的にはラジオボタンでの3択なのですが、未選択も可な質問があります。
未選択の時、列に格納すべきはNULLでしょうか、0でしょうか。
(「どれにも当てはまらない」ボタン設置は無しとして)

テーブル構成は
学籍番号 int,
質問1 int,
質問2 int,
質問3 int...
という風に各質問ごとに列を分ける方よりも、やはり
学籍番号 int,
質問CD int,
回答CD int
とした方がよいのでしょうか。
30問程度あるので出来れば後者にしたいのですが、その場合、
「その他」選択時にテキストボックスへ任意の文字列入力を許可するのですが、
この文字列はどこへ格納すればよいでしょうか。NULL可な備考列を追加して、そこへ?
400 名前：NAME IS NULL mailto:sage [2009/04/01(水) 01:13:13 ID:???]: >>399
> 未選択の時、列に格納すべきはNULLでしょうか、0でしょうか
どちらでも。自分が後で集計するときに使いやすい方を選べばいい。
(IS NULL を使わなくて済むから)自分なら 0 を使う。

> テーブル構成は
後者で良い。楽できる方を選ぶ。

> NULL可な備考列を追加して、そこへ?
それが妥当
(どっちでも良いが自分ならNULL可じゃなくて既定値を空文字にするけど)。

単純なシステムの場合は、
入力時と出力時にどんな SQL を書かなきゃいけないかだけを考えて作れば良いよ。
少々間違えたって、すぐ直せるし。
401 名前：NAME IS NULL mailto:sage [2009/04/01(水) 01:17:22 ID:???]: 俺だったら未選択はレコード挿入しないな
回答はtextにして数字と文字列を区別せず扱えば？
402 名前：NAME IS NULL mailto:sage [2009/04/01(水) 04:41:09 ID:???]: >>401
意味が分からない…
403 名前：NAME IS NULL mailto:sage [2009/04/01(水) 05:46:34 ID:???]: >>399
アンケートの相手が事前に分かってるかとかにもよるんだが、俺なら
アンケートそのものに未回答のもの=NULL
アンケートに回答して、その設問に答えてないもの=0
かな

テーブル構成は、未来永劫絶対に質問内容が変わらないなら前者も有り
でも普通はそうじゃないだろうから後者が無難

その他の回答欄についても、NULL可能な項目（備考じゃなくて、その他回答とかのほうがいいが）作って
その他を選んで回答してない=空文字列
その他を選んでいない=NULL
にする

ただし、DBによっては空文字列とNULLを区別できなかったりするし、
NULLの扱いは結構はまりやすいので、なるべくNULLを使わないようにする、って考え方もありだと思う

>>401
未選択はレコード作らない、って考え方はありだとおもうが、
単一項目に複数の意味合いのデータを入れるのはDB設計としては間違ってるとおもうぞ
404 名前：NAME IS NULL mailto:sage [2009/04/01(水) 08:53:40 ID:???]: 同じ意味合いじゃん
405 名前：NAME IS NULL mailto:sage [2009/04/01(水) 10:57:37 ID:???]: ＞回答はtextにして数字と文字列を区別せず扱えば？
の話だろ。

未選択時レコード作らないのは参照時に面倒だと思うよ。
もし取得できなければ○○、取得できた場合1なら□□、とか。
406 名前：NAME IS NULL mailto:sage [2009/04/01(水) 13:12:46 ID:???]: 同意。
NULLは積極的に使うものではない。
407 名前：NAME IS NULL mailto:sage [2009/04/01(水) 13:25:52 ID:???]: >DBによっては

Oracleの批判はやめてください
408 名前：403 mailto:sage [2009/04/01(水) 13:58:23 ID:???]: >>404
すまん、何と何が同じ意味だと？

>>405
俺も面倒だと思うんで項目にNULLでレコード作る方がいいと思うんだが、
項目にNULL入れると、その項目使う時にNULL判定しないといけない場合があるから
結局面倒さは変わらないかもしれない
レコードなくても、マスタとつき合わせたりするなら、外部結合するって手もあるからな

>>407
別に批判しているつもりはない。あえてDBを名指ししていないし
ただ、OracleがNULLと空文字列の区別がつけれないのは事実で、
そうなるとその区別を必要としないよう設計する必要があるのも事実だ
それが良いとか悪いとか言ってないぞ

まあ、個人的には俺のOracleに対する、ほとんど唯一にして最大の不満点だがなｗ
409 名前：NAME IS NULL mailto:sage [2009/04/01(水) 14:29:10 ID:???]: 2chにおいての、”～の批判はやめてください”ってのは
特定しましたと同じ意味しかないだろうに。
410 名前：NAME IS NULL mailto:sage [2009/04/01(水) 15:27:12 ID:???]: >>408
>すまん、何と何が同じ意味だと？
一番最後の行
>俺も面倒だと思うんで項目にNULLでレコード作る方がいいと思うんだが
何が面倒なの？
未選択時に○○，とか場合わけする必要性が分からない
合計数や平均を取る際にそのまま集計すればいいのでは？
411 名前：403 mailto:sage [2009/04/01(水) 16:17:54 ID:???]: >>410
>単一項目に複数の意味合いの
ってところか
たしかに広い意味では回答という同じ意味なんだが
たとえば、”はい”、”いいえ”、””（無回答）とかならいいんだが
数字とその他の文字による回答になると、数字はコード化された回答、文字はコード化されてない回答、となる

単純に数字と文字を同一項目に入れるなってのもあるし、意味合いって言葉がまずかったか

レコードありなしで面倒なのは、このDBを使うアプリケーションを作る時に、
アプリ側の作りこみが面倒になるかもしれないな、ってこと

たとえばこの結果を表示するアプリを作るとして、未選択時は特別な表示を要求されるかもしれないだろ
SQLのみの世界で見ればあんまり大差はないとおもう
412 名前：NAME IS NULL mailto:sage [2009/04/02(木) 00:00:15 ID:???]: Oracle以外からRDBに入った人にとっては、Oracleのあの文字列の扱いには殺意が沸くわな。
413 名前：NAME IS NULL mailto:sage [2009/04/02(木) 00:30:43 ID:???]: まぁでもあれでいいんじゃね
MySQLやSQL ServerはDB側になんでも任せられるから
それによってクソ重い設計とかできちゃうけど
OracleやPostgreSQLはそういうのやりづらい感じになってる
414 名前：NAME IS NULL mailto:sage [2009/04/02(木) 06:26:34 ID:???]: >>413
DBに任せることができて、任せると設計が重くなる例ってのが想像つかん
たとえばどういうことをDBに任せるとどう重くなるのだ？
415 名前：NAME IS NULL mailto:sage [2009/04/02(木) 07:21:11 ID:???]: 「Oracleなら仕方ないか、アプリで実装するか」的な
ノリは漏れは嫌いなんだけどな。

あと、よくもわるくもOracleとPostgresを一緒にスナ（ｗ

「普通に設計」させれ。
416 名前：NAME IS NULL mailto:sage [2009/04/02(木) 07:52:28 ID:???]: >>414
クライアントよりサーバーに負担がかかるってことだろ
417 名前：NAME IS NULL mailto:sage [2009/04/02(木) 08:56:01 ID:???]: >>416
なるほど。つまり、DBで処理するかアプリで処理するか、って問題か
DB設計段階で、元来DBですべき処理をアプリでするってのは本末転倒な気はする
性能設計って話もあるんだが、負荷軽減は運用に入ってチューニングと合わせて検討すべき内容だと思うなぁ
418 名前：NAME IS NULL mailto:sage [2009/04/02(木) 12:23:34 ID:???]: 文字列加工とかの話だろ
Oracleとかそういうのショボいからアプリ側でやらんと駄目だしね
419 名前：NAME IS NULL mailto:sage [2009/04/02(木) 13:10:13 ID:???]: なんでそんなものをDBでやらなきゃいかんのだ。
420 名前：NAME IS NULL mailto:sage [2009/04/02(木) 16:08:53 ID:???]: DBあるのにデータ加工をなんでアプリでやらなきゃならんのだ？
421 名前：NAME IS NULL mailto:sage [2009/04/02(木) 16:50:50 ID:???]: データ絞り込みならともかく加工でその文句は・・・ｗ
422 名前：NAME IS NULL mailto:sage [2009/04/02(木) 17:13:37 ID:???]: 加工までDBなのかよ。
どんだけ言語使えないのｗｗｗ
423 名前：NAME IS NULL mailto:sage [2009/04/02(木) 19:13:11 ID:???]: ret = SELECT pref, city FROM address
って取り出して
プログラム側で
str = ret.pref + ret.city;
ってやんのか

ret = SELECT (pref || city) as addr FROM address
str = ret.addr;

かって話だよな

後者はかなりもっさり祭りになるぞ
アクセス少ないならともかく
424 名前：NAME IS NULL mailto:sage [2009/04/02(木) 19:39:21 ID:???]: 加工じゃねぇだろ、それw
425 名前：NAME IS NULL mailto:sage [2009/04/02(木) 19:45:40 ID:???]: まあ場合によるんじゃないの？

最近は負荷分散の意味で
サーバーサイドのcgiよりも
クライアントサイトのjavascriptを使うって動きが出てるけど

ソースは忘れた
426 名前：NAME IS NULL mailto:sage [2009/04/02(木) 23:46:00 ID:???]: ニコ動の開発者インタビューみたいなので、そんな話見たな。
まあ確かにAJAX系ではselect結果をxmlにしたら、
あとはクライアント側でどうぞという感じではある。
427 名前：NAME IS NULL mailto:sage [2009/04/04(土) 07:20:07 ID:???]: 時と場合によるがOracleの場合は文字列加工にケチつけてるヤツは少ないのでは？

判定(where～)がイカれているから、設計が歪んでいくって事だろ。

同じフォーマットでデータをinsertしても、selectするとOracleだけが判定結果がおかしいからな。
428 名前：NAME IS NULL mailto:sage [2009/04/04(土) 12:16:25 ID:???]: そんなんchar型だとどのDBでもあることだしなぁ。
そもそも必須だと言ってるのに空文字入れられちゃうのもどうかと。
429 名前：NAME IS NULL mailto:sage [2009/04/04(土) 16:11:42 ID:???]: 単にオラクル想定の設計をしてなかったってだけじゃないの？
スキル低いだけの様な。
430 名前：NAME IS NULL mailto:sage [2009/04/04(土) 18:16:23 ID:???]: たしかに「オラクルに対応するスキル」が低いといえるな
オラクルはRDBMSの世界ではかなりスタンダードかもしれないが
問題は、オラクルにだけ特別必要なスキルがあるってことなんだと気付けよ
431 名前：NAME IS NULL mailto:sage [2009/04/04(土) 18:49:08 ID:???]: オラクルには対応できませんって断る勇気も必要。
432 名前：NAME IS NULL mailto:sage [2009/04/05(日) 00:24:18 ID:???]: オラクルのゴールドとかプラチナとかの資格は
うんこ取扱師乙種とか甲種って名前に変更するべきだと思うんよ
433 名前：NAME IS NULL mailto:sage [2009/04/05(日) 00:26:33 ID:???]: お前は小学生か
434 名前：NAME IS NULL mailto:sage [2009/04/05(日) 00:39:54 ID:???]: だってあれもうDBの勉強じゃなくてうんこを安全に扱うための勉強じゃん・・・
435 名前：NAME IS NULL mailto:sage [2009/04/05(日) 03:47:24 ID:???]: 昔はOracle最高だったんだけど
レガシーな仕様を引きずりすぎて今に至ってる部分があるから
あれはあれで仕方ないんだよ
COBOLみたいなもんだ
436 名前：NAME IS NULL mailto:sage [2009/04/05(日) 07:13:05 ID:???]: レガシーを引き継いでいる分にはDB2はOracleに負けてない気がするが、
DB2は伝統的な記述しか許さない思想の性か、ちゃんとselectできるわけだが。

Oracleは資格士が必須な感があるにはあるな。

最新のバージョンは多少世間(?)に歩み寄っている感があるが昔のバージョンの
結合の構文から見てキモいんだが。普通にLEFT OUTER JOINとか書かせろと。
437 名前：NAME IS NULL mailto:sage [2009/04/05(日) 07:17:07 ID:???]: 9iから使えるだろ>LEFT OUTER JOIN
438 名前：NAME IS NULL mailto:sage [2009/04/05(日) 10:17:38 ID:???]: FULL OUTER JOINにバグがあって怖くて使わなかったな＜9i
439 名前：NAME IS NULL mailto:sage [2009/04/05(日) 10:20:12 ID:???]: スレ違いネタで無知をさらす
440 名前：NAME IS NULL mailto:sage [2009/04/05(日) 15:45:17 ID:???]: オラクル雑談スレが落ちてるからな。
441 名前：NAME IS NULL mailto:sage [2009/04/05(日) 19:58:52 ID:???]: こっちで代用すんなｗ
442 名前：NAME IS NULL mailto:sage [2009/04/05(日) 22:11:19 ID:???]: 漏れのとこはOracle8が動いていますが、なにも。ｗ
443 名前：NAME IS NULL mailto:sage [2009/04/06(月) 00:16:23 ID:???]: 8iじゃないのか。乙。
444 名前：NAME IS NULL mailto:sage [2009/04/06(月) 06:19:24 ID:???]: 8iってなにｗ
445 名前：NAME IS NULL mailto:sage [2009/04/06(月) 06:32:13 ID:???]: Linuxでまともに動くようになったOracleの最初のバージョン
Javaと融合してインターネットサイトで使いやすくなった
446 名前：NAME IS NULL mailto:sage [2009/04/06(月) 13:41:18 ID:???]: 具体的なバージョンは忘れたが、８のどっかのバージョン以降だな
とにかく８の初期のころと分けて8iと呼ばれた
iはインターネットのiだったらしい
447 名前：NAME IS NULL mailto:sage [2009/04/06(月) 13:56:07 ID:???]: 8.1.5以降がi
それまでWindows版しかGUIインストーラなかった
448 名前：NAME IS NULL mailto:sage [2009/04/07(火) 05:16:05 ID:???]: むしろCUIインスコがデフォ。
449 名前：NAME IS NULL mailto:sage [2009/04/09(木) 20:18:13 ID:???]: Accessを使ったWebベースのスケジュール管理システムを作ろうとしていて、100人程度の同時使用を考えています。
必要なテーブルは以下のとおりです。
1.マスタ関係のテーブル(複数)
2.スケジュールを入れるテーブルとその付属テーブル(複数)
3.アクセスログのテーブル
特にアクセスログはすぐに大きくなりそうなので別のファイルに保存しようと考えているのですが、
1,2,3のテーブルを1つのmdbファイルにするのと、
別のmdbファイルにしてリンクで結ぶのとでは処理速度が大きく違うものでしょうか？
また、同時openの負荷を考えるとユーザーごとにmdbファイルを用意して
その中にメインのテーブルに対するリンクを置くような形にすべきでしょうか？
450 名前：NAME IS NULL mailto:sage [2009/04/09(木) 21:52:29 ID:???]: accessスレで聞いたら？
って、この板には無くてビジネスsoft板の方なんだな。
451 名前：NAME IS NULL mailto:sage [2009/04/10(金) 00:02:55 ID:???]: Accessだと大勢で使うのは厳しいけど、MySQLを使えば数百人規模でも問題ない？
452 名前：NAME IS NULL mailto:sage [2009/04/10(金) 00:09:17 ID:???]: 数百人どころか超大手サイトでも問題ない
453 名前：NAME IS NULL mailto:sage [2009/04/10(金) 00:57:55 ID:???]: Access は。複数人（スレッド）で使うとすぐ壊れるよ。
せめて、SQL Server Express Edition にすべき。最大4Gの制限に
引っかからなければ、だけど。
454 名前：NAME IS NULL mailto:sage [2009/04/10(金) 06:38:27 ID:???]: ってかアクセスログはテキスト出力でいいと思うけど
DBに突っ込んでくとそれがネックになって主要機能部分の性能落ちるぞ
455 名前：NAME IS NULL mailto:sage [2009/04/10(金) 14:38:50 ID:???]: Accessの上限は２G
456 名前：NAME IS NULL mailto:sage [2009/04/10(金) 21:24:07 ID:???]: ウェブベースでアクセスの選択の時点で駄目だけどな。

監視系のシステムとかだと、ネックに成ろうが、ログをDBに突っ込むけどな。
そうしないと膨大なログを処理しきれない。毎回テキストから抜くのも大変だし。
457 名前：449 mailto:sage [2009/04/10(金) 23:02:49 ID:???]: MySQLなるものをはじめて知り、無料なようなのでこちらを勉強することにしました。
コマンドプロンプトっぽいところが慣れないです。
ダブルクリックですぐ中身表示みたいなのがあれば便利なのですが。
まあ使い方がわかれば余計な心配しなくてよさそうなのでひと安心です。
458 名前：NAME IS NULL mailto:sage [2009/04/10(金) 23:12:07 ID:???]: MySQL Admin入れれ
459 名前：NAME IS NULL mailto:sage [2009/04/10(金) 23:12:47 ID:???]: あとODBCでAccessと連携も出来る
460 名前：NAME IS NULL mailto:sage [2009/04/11(土) 00:10:53 ID:???]: >>458
なにそれ？
461 名前：NAME IS NULL mailto:sage [2009/04/11(土) 01:00:17 ID:???]: phpmyadmin入れれ
462 名前：NAME IS NULL mailto:sage [2009/04/11(土) 05:35:01 ID:???]: >>460
www.db.is.kyushu-u.ac.jp/rinkou/mysql/mysql.html
463 名前：NAME IS NULL mailto:sage [2009/04/11(土) 12:30:16 ID:???]: ほれ。

pc11.2ch.net/test/read.cgi/db/1227475230/
MySQL 総合 Part15
pc11.2ch.net/test/read.cgi/db/1056947097/
mysqlについて語ろう
pc11.2ch.net/test/read.cgi/db/1156557521/
PHP＋ODBC＋MDB
464 名前：NAME IS NULL [2009/04/28(火) 03:22:34 ID:aHnBfSXl]: 株価データをDBに入れて保持してるんですが、今は1つの大きなテーブルに入れてます。
(取引日付 DATE, 銘柄コード int, 取引市場 int, 始値 double, 終値 double, 高値 double, 安値 double, 出来高 double)
これ1個のテーブルで3000万件くらいになってます。このテーブルを使う処理が時間がかかるので、テーブルをわけてしまおうかと思っているのですが、
銘柄ごとにテーブルを分けるとテーブルが5000個とかになるし、
日にちごとにテーブルを分けると10000個近くになります。
銘柄ごとのテーブルと日にちごとのテーブルの両方を準備するとデータの冗長性ひどすぎという感じがします。

アプリからは、銘柄／日付／銘柄と日付の両方、を指定してデータ取得というのをよくやるのですが、
こういう場合どういう形でDBに入れておくのがよいでしょうか？
465 名前：NAME IS NULL mailto:sage [2009/04/28(火) 13:22:48 ID:???]: 3000万件か。
趣味のレベルを超えてるな。
時間ってどれくらいかかるの？
インデックスは適切に張ってるの？

分けるなら年度毎とかかな。
466 名前：NAME IS NULL mailto:sage [2009/04/28(火) 14:05:38 ID:???]: 3000万でもインデックスあればそんな困らないけど
すでにアクセスすることがめったにない昔のデータなら分けるかもなあ
467 名前：NAME IS NULL mailto:sage [2009/04/28(火) 14:47:32 ID:???]: どんなクエリを投げているのかな。
単に特定の日付の株価を検索しているのか、期間別の
平均値など集計を多用しているのか。
468 名前：NAME IS NULL mailto:sage [2009/04/28(火) 15:29:08 ID:???]: 1件→3000万件で
検索時間は7倍程度って認識でおｋ？
469 名前：NAME IS NULL mailto:sage [2009/04/28(火) 20:41:55 ID:???]: >>464
OLAP、DWH、スタースキーマあたりでググるといいと思うよ。
これはSQL Server に特化した話だけど参考になると思う。
sqlcat.com/whitepapers_japanese/archive/2008/10/18/450.aspx

とりあえず、こんな感じ？
取引日付順にデータが並んで保存されるように、取引日付でクラスタ化する。
これで取引日付による範囲検索が高速化される。

インデックスは以下の2つがあればいいかな。

1) 取引日付
2) 銘柄、取引日付

テーブルは月や年度でパーティショニング。
470 名前：NAME IS NULL mailto:sage [2009/04/29(水) 00:30:43 ID:???]: 土日祝日はザラバ立たないから年240日として5000銘柄の25年分くらいか
システムトレードなら出来高上位1000銘柄の直近5年分程度に絞ってもよさげのような気もするけど…
471 名前：NAME IS NULL mailto:sage [2009/04/30(木) 22:40:03 ID:???]: 338 北川憲治. 1:28:58. 17. 321 蟹谷保. 1:28:58. 18. 311 井上正志. 1:28:59. 19. 351 加藤弘恒. 1:29:18. 20. 335 高田英司 .... 627 北川憲治. 1:28:43. 12. 706 田賀純介. 1:31:29. 13. 740 日高寿美. 1:31:35. 14. 701 和田安男. 1:32:03
472 名前：NAME IS NULL mailto:sage [2009/05/02(土) 15:46:47 ID:???]: 移動平均線とかの計算でデータ引っ張ってくると、年度別に分けると面倒かもな。
漏れは、銘柄でテーブル分けかなあ。
為替のほうも取り込みたいから結構大変。
証券会社や取引業者に依存しない自分用のシステム作るのって結構大変だよな。
473 名前：NAME IS NULL [2009/05/25(月) 01:35:09 ID:rfk82z3I]: 教えてください。

チェックボックスが30個くらいあって、それぞれのON/OFF状態をDBに
保存しなければならないとき、

1)チェックボックスの数だけカラムを作る
2)可変長文字列のカラムを1個作り、チェックボックスの状態をカンマ区切りかなんかで放り込む

のどっちが正解でしょうか？
仕様変更などでチェックボックスの位置が入れ替わったり、数が変わったりする
可能性もあります。

SQL Server2005です。よろしくお願いします。
474 名前：NAME IS NULL mailto:sage [2009/05/25(月) 01:45:32 ID:???]: 一対多の関係テーブルを作る
475 名前：NAME IS NULL mailto:sage [2009/05/25(月) 02:12:56 ID:???]: 2やったら死ねるぞ
476 名前：NAME IS NULL mailto:sage [2009/05/25(月) 02:23:51 ID:???]: 一人で使って、永遠に自分でメンテするテーブルでない限り２は禁止な。
約束だ。

あとチェックボックスの数はともかく位置はDB設計とは無関係じゃないの。
dbから動的にチェックボックス作成するってこと？
477 名前：473 [2009/05/25(月) 03:00:14 ID:rfk82z3I]: 2)がまずい原因って何でしょう？

チェックリストボックスを読み込んだ順に1か0のカンマ区切りでDBに格納して、
チェックリストボックスを復元するときもDBを1カラム読むだけで楽かなぁと思ったのですが。。

>>476
上述の通り、読み込んだ順に処理してるので、位置が変わると過去データに矛盾が出るなと・・・

SQL Server上で配列定義ができればいいのですが。
478 名前：NAME IS NULL mailto:sage [2009/05/25(月) 03:44:28 ID:???]: ・チェックボックスは何を選択するために使うのか。
・チェックボックスの位置が変わる可能性はあるようだけど
　数に関してはどうか。「30個くらい」で不変か。
・チェックボックスの状態をDBに格納したとして、その情報を
　どのように利用するのか。単にチェックボックスの状態を
　復帰するのに使うだけなのか、「チェックボックス1がonの
　xxxを列挙」みたいな感じで検索にも使うのか。

このあたりが分からないとにんともかんとも。
479 名前：NAME IS NULL mailto:sage [2009/05/25(月) 04:48:15 ID:???]: ただのストレージとして使いたいだけなら別に(2)でもいいんじゃね？
480 名前：NAME IS NULL mailto:sage [2009/05/25(月) 05:10:47 ID:???]: 江戸時代のBIT型じゃねーんだからわざわざ2にする必要もないだろ
なんのための"R"DBMSなんだよと
481 名前：NAME IS NULL mailto:sage [2009/05/25(月) 09:06:30 ID:???]: FILLER X(30)をREDEFINESでOCCURS 30とか
なんだこのコボラー・・・
482 名前：NAME IS NULL mailto:sage [2009/05/25(月) 09:19:31 ID:???]: 月次データの日付毎の有無とかだろ
483 名前：NAME IS NULL mailto:sage [2009/05/25(月) 15:16:57 ID:???]: >>478
たとえば病院の診療科（内科、小児科、外科）みたいのがズラズラと並んだ
チェックボックスで、過去受診履歴がある科のチェックがONになります。

この過去受診診療科情報は特に重要では無く、参考情報程度の扱いです。
将来的には診療科の増減があったり、科が細分化（内科が内科1、内科2のように）したりする
可能性があります。

単純にテーブルが増えたり、カラムを作ったりするのが非常にめんどうなだけなんですが、
後々仕様変更があった場合、労力がかからないのは1)、2)どちらなのかと。。

診療科の全一覧は別テーブルに持っているため、受診科履歴は
当初チェックがONの科をカンマ区切りで1カラムに放り込んでおけばいいやと思っていました。

情報の後出し、申し訳ないです
484 名前：NAME IS NULL mailto:sage [2009/05/25(月) 15:18:58 ID:???]: なぜ>>474はスルー？
485 名前：NAME IS NULL mailto:sage [2009/05/25(月) 16:03:47 ID:???]: バカだから理解できないんだろ
486 名前：NAME IS NULL mailto:sage [2009/05/25(月) 16:42:55 ID:???]: >>483
それくらいだったら2でいいんじゃない？
わざわざテーブル作る必要ねぇよ
487 名前：NAME IS NULL mailto:sage [2009/05/25(月) 22:49:39 ID:???]: >>483
その仕様ならば尚更1）以外に選択肢が見当たらないけど・・・
2)はケースをよく考えてみろ、データ崩れる可能性がある。
488 名前：NAME IS NULL mailto:sage [2009/05/25(月) 23:10:02 ID:???]: >>477
＞2)がまずい原因って何でしょう

「チェックされた項目の名称をマスタから引っ張ってくるとか」
「○○科受信歴がある患者一覧」とか
「○○科受信歴があり△△科受信歴が無い患者の人数」とかいった、
DB的使い方に全く適さない格納方法だから。

>>483みたいな使い方であれば2でも大して問題ないんじゃないの。
489 名前：NAME IS NULL mailto:sage [2009/05/25(月) 23:31:46 ID:???]: >>483
いいんじゃね？2)で。
CLOBにしてXMLでデータ突っ込むようにしたら、もう一生このスレの世話になる必要はないぞ。
490 名前：NAME IS NULL mailto:sage [2009/05/25(月) 23:56:37 ID:???]: 一意番号(1,2,3...)のテーブルに対して、
一意番号＋科目マスタID(内科1,内科2,外科1,外科2...)みたいな明細テーブル持って、

1-内科1
1-内科2
2-内科1
2-外科1
みたいなレコードの持ち方すればいいんじゃね？
科目マスタをメンテナンスすれば動的にデータ追加できるぞ。
491 名前：NAME IS NULL mailto:sage [2009/05/26(火) 07:24:41 ID:???]: 別に２でも良いだろ。
作り直したら、２で格納したデータを更新すれば良い。

心療科の増減でごちゃ混ぜになるほうが医療事故で怖い気がするけどな。
小児科２消滅→内科２統合→小児科３新設→内科３統合→小児科２統合
とか増減有って、履歴追えるような仕様なら結構大変だ。
492 名前：NAME IS NULL mailto:sage [2009/05/26(火) 09:57:18 ID:???]: >>477

単にチェックの状態を押さえておきたいだけなら２でもいいと思うけど、情報が足りない。そのチェックの並び情報ももう１カラム追加して管理したらどう？

create table checks(
ID number(10)
,checkItems number(1) -- number of checks (max 9)
,checklabels varchar(100) -- example: 内科1,内科2,外科1,外科2,小児科
,checks varchar(9)　 -- '0':off '1':on
)

checklabelでチェックの順番を保存しておく。'内科1,内科2,外科1,外科2,小児科'みたいに。別に文字列でなくて診療科のコードでも構わない。
checksが '01010' だったら内科２と外科２がチェックされた、てな感じ。checks['内科1']='0'、checks['内科2']='1'、....の連想配列イメージ。
表示順なんかはアプリで制御せざるをえない。

でも後々を考えるなら >>474 の方法を検討した方が良いと思う。
493 名前：NAME IS NULL mailto:sage [2009/05/26(火) 11:33:34 ID:???]: 「診療科毎の患者数を知りたい」なんてのは普通に出てきそうな要件だと思うが。

素直に別テーブル
・患者ID
・受診科ID
・最終受信日

みたいなの作って管理すればいいんちゃう？
まぁ他の人が言ってるように、単なる一時保存なら2、後々統計情報に使いたいなら1かと・・

表示順を気にするなら診療科IDのつけ方のほうが重要だったりするけどね。。
増減があることを見越して、十分な隙間をとって採番してかないとアプリの工数が増える。
494 名前：NAME IS NULL mailto:sage [2009/05/26(火) 19:54:01 ID:???]: 変更の可能性がある表示順をそのデータに依存させるなんて怖いことはせず、
表示対象と表示順を持ったテーブルを準備して、目的のテーブルとJOINして使う。
order by 句で表示順をソートすればいいんだから。
495 名前：NAME IS NULL mailto:sage [2009/05/27(水) 07:38:26 ID:???]: 用途がなんであろうと2はないだろ。
2を推してる奴は>>477が自分の客だと想定しても同じことが言えるのか？
確実に将来に渡ってチェックだけを記録するだけの為に使うって保証なんてないぞ。
前提としてこれを抑えてる奴がいるが、こちらの設計思想を理解してもらえると思ってるのが甘い。
496 名前：NAME IS NULL mailto:sage [2009/05/27(水) 14:13:45 ID:???]: コボル前提なら有りな模様
497 名前：NAME IS NULL mailto:sage [2009/05/27(水) 18:01:13 ID:???]: そうやって無駄に工数増やして苦しくなるだけの様な。
簡単な事を難しく遣ろうとして、請求を水増ししようとしても客の理解は得られないぞ。
498 名前：NAME IS NULL mailto:sage [2009/05/27(水) 18:11:08 ID:???]: 2の方がよっぽど面倒だと思うが…
499 名前：NAME IS NULL mailto:sage [2009/05/27(水) 21:24:15 ID:???]: 何事も経験だ。
迷っているなら一度やってみるのがいいさ。
500 名前：NAME IS NULL mailto:sage [2009/05/27(水) 21:36:34 ID:???]: 遡ってスレ眺めれば、473 が技術的に >>474 を思いつけないレベルであるのを理解して２でもいいんじゃないかと言ってるのがわかると思うよ。

客もその情報をあまり重要視していないようだし、理解できない方法で下手打つよりは、ダサダサでも自身で理解できる方法で実装した方が安全、ってなところ。

客が納得いかないとか設計がどうとか言うなら、 473 に理解できるようお勧めの方法を説明してあげて。
その方が他の人もそれをネタに色々議論できるだろうし。
501 名前：NAME IS NULL mailto:sage [2009/05/28(木) 00:17:52 ID:???]: DB設計を語るスレにわざわざ相談しに来てるんだから
自分でもうすうす2の実装に疑問があるわけだろ
だったら正規化で解決する方法を学ぼうとする姿勢くらい見せてくれても
502 名前：NAME IS NULL mailto:sage [2009/05/28(木) 13:59:35 ID:???]: すいません、ここでいいのか判らないのですが教えてください。

MySQLに姓名、メールアドレスや誕生日などの個人情報を保存して
住所録を作りたいのですが、友人から個人情報保護法とやらで
ＷＥＢ上に個人情報を保存するのは禁止されてるって聞きました。

だとしたら、ネット通販とかで一度購入していたら個人情報が引っ張り出されますが
あれはどうやって作っているのでしょうか？

または、ある基準さえ満たせば保存してもいいのでしょうか？
503 名前：NAME IS NULL mailto:sage [2009/05/28(木) 14:09:59 ID:???]: >>502
スレ違い
必要であれば取り扱いに注意して管理すればいいんだよ。
ここでも見てくれば。
ttp://www.kantei.go.jp/jp/it/privacy/houseika/hourituan/index.html
504 名前：NAME IS NULL mailto:sage [2009/05/28(木) 14:11:55 ID:???]: >>502
お前程度の知識でそんな事やったら絶対に漏洩する。
悪いことは言わないからやめとけ。
505 名前：NAME IS NULL mailto:sage [2009/05/28(木) 14:47:57 ID:???]: >>503
すれ違いでしたか・・すみません。
なのに答えていただいてありがとうございます！

>>504
やっぱりそうでしょうか・・・orz
業者に頼むと高いのでお前がやれと言われたんですが、
ちょっと上司に掛け合ってみます。

有難う御座います。

すれ違いな質問をして、皆さんすみませんでした。
506 名前：NAME IS NULL mailto:sage [2009/05/29(金) 02:03:56 ID:???]: DBに直接アクセスするようなのはＮＧだろうな。
AP鯖経由ならいいんじゃねえの。
まあネット上で個人情報漏らしてるのはたまに見るけどな。
507 名前：NAME IS NULL mailto:sage [2009/05/29(金) 02:21:30 ID:???]: log.csvとかform.csvとかtoiawase.csvとかで検索するなよ
絶対だぞ
508 名前：NAME IS NULL mailto:sage [2009/05/29(金) 03:39:09 ID:???]: 高いからしっかり漏れないように仕事してくれるのにな。
馬鹿な上司の居る担当が作ったサイトは使いたくないねｗｗｗ
509 名前：NAME IS NULL mailto:sage [2009/06/09(火) 00:03:27 ID:???]: コボルのデータをそのままSQLにつっこんだような
DBはまずどこから直すべきでしょうかｗ

もうどうしていいかｗ
鬱に成りそう
510 名前：NAME IS NULL mailto:sage [2009/06/09(火) 00:46:18 ID:???]: とりあえずゼロベースで、1から作るとしたらどんなDB設計するか、から考えてみたら？
既存のものありきで考えると思考が硬直化するよ。
511 名前：NAME IS NULL mailto:sage [2009/06/09(火) 01:50:31 ID:???]: >>509
まず第一正規化します。次に第二正規化します。最後に第三正規化します。
512 名前：NAME IS NULL mailto:sage [2009/06/09(火) 05:25:12 ID:???]: あんまり正規化に、こだわる必要も無いけどな。
むしろ業務フローに合わせたほうが効率的。
どうせどんどん機能付け足しで正規化崩れてくるから。
513 名前：NAME IS NULL mailto:sage [2009/06/09(火) 11:22:25 ID:???]: 究極まで正規化すると実用的では無いけど
コボルベースの横長テーブルは正規化しないと実用的では無いよね
514 名前：NAME IS NULL mailto:sage [2009/06/09(火) 11:31:47 ID:???]: 業務にも明るくないとほとんどメモ的うにしか使わないフィールドを
一所懸命正規化してテーブル分けたり、
逆にメモだろと思ってコード化も正規かもやらなかったフィールドが
重要なキーになったり。
もう少しDB設計に時間かけさせてくれよぉ。
515 名前：NAME IS NULL mailto:sage [2009/06/09(火) 11:53:27 ID:???]: どうせ崩れるからと最初から正規化をしないととんでもないものが出来上がるが
作った本人はどこがわるいのかわからない、さいてー
516 名前：NAME IS NULL mailto:sage [2009/06/10(水) 23:51:32 ID:???]: テーブルが全部charで記述されてます
1テーブルカラムが100列超えてます

どうやって治せばいいの？
517 名前：NAME IS NULL mailto:sage [2009/06/11(木) 00:00:29 ID:???]: >>516
全テーブルがって訳じゃなかったが、テーブル名がtable1～tableN、更にカラム名がcol1～colNというDBを見た事がある。
業務とデータと現行アプリから地道にマッピングしていった。
現行アプリのソースが無かったら、作り直し以外受けれなかった。
518 名前：NAME IS NULL mailto:sage [2009/06/11(木) 00:59:32 ID:???]: >>516
今見てみたんだが4割ぐらいのテーブルで
IDとかいうcharのカラム1個に、最大までとったvcharカラム１つ
という構成になってた。ｗ

もう俺逃げる
519 名前：NAME IS NULL mailto:sage [2009/06/11(木) 19:57:32 ID:???]: >>518
べつにそれで良ければ問題はないと思うのだが。
520 名前：NAME IS NULL mailto:sage [2009/06/11(木) 19:59:42 ID:???]: いいのかよｗ
BLOBですらないんだぞｗ
521 名前：NAME IS NULL mailto:sage [2009/06/11(木) 21:34:32 ID:???]: IDとかいうcharのカラム1個に、最大までとったvcharカラム１つという構成。
これがなにに使われているかが問題。
>>518は「なにに使われているか」の説明が欠けている。

たとえばＩＤ＋テキスト文書だったら、これでかまわんだろ。
522 名前：NAME IS NULL mailto:sage [2009/06/11(木) 22:26:16 ID:???]: そんなことでは一々書き込まないだろう。
ここはもちろん、長さ100バイトに及ばんばかりのビットの羅列だな。
それぞれが別個のフラグになっている。
523 名前：NAME IS NULL mailto:sage [2009/06/11(木) 23:51:41 ID:???]: いちいちidは要らないだろ。ruby廚でも買ってるのか？
524 名前：NAME IS NULL mailto:sage [2009/06/11(木) 23:55:21 ID:???]: >>522
長さ50バイトぐらいのデータが4000個から32000個
詰め込んでるようです。とりあえず退職願出したけど
ダメって言われて危うく軟禁されそうになったけど
トイレから逃げてきた
525 名前：NAME IS NULL mailto:sage [2009/06/13(土) 15:02:36 ID:???]: どんだけブラックだよ
526 名前：NAME IS NULL mailto:sage [2009/06/13(土) 15:40:57 ID:???]: >>524
> 長さ50バイトぐらいのデータが4000個から32000個
なんのデータなんだろう。

社員マスターのデータ（社員番号、氏名、所属・・）などをCSV形式で格納したものなのだろうか？
なんらかの計測データなんだろうか？

前者なら言語道断だが、後者なら納得できるもの。
527 名前：NAME IS NULL mailto:sage [2009/06/13(土) 18:10:29 ID:???]: 質問があります。
各アカウントの権限の状態（アカウントAには公開、削除を、
アカウントBには公開、閲覧を許可するなど）を
保存するテーブルの作成を考えています。

はじめはカラムを

アカウント名公開フラグ削除フラグ閲覧フラグ
として、実際に格納するデータを

A 1 1 0
B 1 0 1

というように各フラグには有効/無効を1か0で格納しようと考えていたのですが、
「将来新たに権限が増えた場合、カラムを追加しないで済むテーブル構成を考えて欲しい。
今のままでは権限が増えるたびにカラムが増えてしまう」
と要望がありました。
この要望を満たすテーブル構成はどんなものがありますでしょうか。
528 名前：NAME IS NULL mailto:sage [2009/06/13(土) 18:26:55 ID:???]: >>527
アカウントごとのアクセス制限を設定するにはGRANT文を使うんじゃね
GRANT文で設定された権限の状況はSYSTABLEPERMSなどのシステムテーブルを見ればわかるし
ユーザテーブルで管理する意味がわからない

勘違いしていたらごめん
529 名前：NAME IS NULL mailto:sage [2009/06/13(土) 18:36:44 ID:???]: >>527　SYSTABLEPERMSを参照するとか
530 名前：NAME IS NULL mailto:sage [2009/06/13(土) 19:50:48 ID:???]: >>528
>>529

説明不足ですみません。
ここでいうアカウントや権限は、DBに関係する権限ではなく、
例えば、ビジネス文書の編集、公開、削除といった動作を許可するかどうか
といったものの権限を指します。
531 名前：NAME IS NULL mailto:sage [2009/06/13(土) 20:31:15 ID:???]: アカウントマスタ、権限マスタ、アカウント権限テーブル
532 名前：NAME IS NULL mailto:sage [2009/06/13(土) 21:26:40 ID:???]: >>531

アカウントマスタのカラム
アカウント名

権限マスタのカラム
権限名

アカウント権限テーブルのカラム
アカウント名許可したい権限名

として、
アカウントマスタ.アカウント名=アカウント権限テーブル.アカウント名
と
権限マスタ.権限名=アカウント権限テーブル.許可したい権限名
で3つのテーブルを結合する、という認識でいいのでしょうか。
533 名前：NAME IS NULL mailto:sage [2009/06/13(土) 21:31:39 ID:???]: 許可したい権限だけをテーブル（アカウント権限）に突っ込むのか、
基本的にすべて突っ込むようにして、許可・拒否フラグを用意するのか、
その辺は仕様次第かな。

あと、名称を直接、ではなくて、ID でリレーションを保持するように、
ってのは、RDBMS の基本。
534 名前：NAME IS NULL mailto:sage [2009/06/13(土) 21:53:06 ID:???]: 回答とアドバイスありがとうございました。
細かいところは自分でもう少し練ってみます。
535 名前：NAME IS NULL mailto:sage [2009/06/13(土) 23:09:32 ID:???]: >>533
どこの世界の基本だ？
あと「リレーション」って使い方間違えているような気がするな。
どっちの意味にしてもおかしいけど。
536 名前：NAME IS NULL mailto:sage [2009/06/14(日) 03:04:06 ID:???]: >>530
こういうのはいけないって事？

create table ユーザテーブル(
ユーザＩＤ varchar(4)
, 有効 char(1) -- 1 or 0
);

create table 権限テーブル(
ユーザＩＤ varchar(4)
, 権限ＩＤ varchar(3)
, 権限 char(1) -- 1 or 0
);

・ユーザＩＤ X001 さんの権限ＩＤ A01 を取得
SELECT A.ユーザＩＤ
,B.権限 as 権限A01
FROM ユーザテーブル A LEFT OUTER JOIN 権限テーブル B ON(A.ユーザＩＤ=B.ユーザＩＤ)
WHERE A.ユーザＩＤ='X001' AND A.有効='1' AND B.権限ＩＤ='A01' ;

・ユーザＩＤ X002 さんの権限ＩＤ A01、権限ＩＤ A02 を取得
SELECT A.ユーザＩＤ
B.権限 as 権限A01
,C.権限 as 権限A02
FROM ユーザテーブル A LEFT OUTER JOIN 権限テーブル B ON(A.ユーザＩＤ=B.ユーザＩＤ)
LEFT OUTER JOIN 権限テーブル C ON(A.ユーザＩＤ=C.ユーザＩＤ)
WHERE A.ユーザＩＤ='X002' AND A.有効='1' AND B.権限ＩＤ='A01' AND C.権限ＩＤ='A02' ;

全部の権限を1レコードに集約する必要が無いなら上記の権限テーブルの内容で充分だと思うけど。
せいぜい有効期間を設定するくらい。
使いもしない項目を全部横に並べないと気が済まないのはＣＯＢＯＬの人によくありがち。
レコード全部読み込んで自前ジョインやってたのを見て怖ぇと思った。
537 名前：NAME IS NULL mailto:sage [2009/06/14(日) 10:35:12 ID:???]: >>536
COBOLERはほんと害悪。
「1レコード読むだけで全部の情報が手に入って便利だろ」
「テーブル増やしたらパフォーマンス上不利」
「ちなみにNULLはオール9に置換してある」
538 名前：NAME IS NULL mailto:sage [2009/06/14(日) 13:28:40 ID:???]: COBOLERというよりは、ISAMERが害悪という意見を聞いたことがある。
まあどちらも滅んで欲しいには違いない。
539 名前：NAME IS NULL mailto:sage [2009/06/14(日) 14:05:23 ID:???]: 全部読み込みならRDBM要らないだろｗｗｗ
RDBM無しの太古のやり方のまま使い続けてるよな。

オンメモリDBとか提案すると渋々対応するけどな。
540 名前：NAME IS NULL [2009/06/14(日) 22:51:52 ID:dUBFuZEU]: >>533
「リレーションシップ」（エンティティ（テーブル）間の関連）
「リレーション」（関係＝テーブル）

DB設計されるみなさま、なるべく用語は正しく使いましょう
541 名前：NAME IS NULL mailto:sage [2009/06/14(日) 23:39:23 ID:???]: 540みたいなレスみるとまだまだコミュ力無しでいる奴らが多い事にびっくりする。
間違いは間違いだが、流れで把握してやりゃいいもんを・・・まぁ、それが出来ないからこんなレスするんだろうが
542 名前：NAME IS NULL mailto:sage [2009/06/14(日) 23:40:56 ID:???]: >関係＝テーブル

・・・
543 名前：NAME IS NULL mailto:sage [2009/06/15(月) 03:04:48 ID:???]: >>541
文脈から明らかな場合はいいいけど、>>533は意味不明だぞ。
544 名前：NAME IS NULL mailto:sage [2009/06/15(月) 03:11:59 ID:???]: そうか？「ID で関係を保持する」なら、普通に意味は通じると思うけどな。
545 名前：NAME IS NULL mailto:sage [2009/06/15(月) 05:25:05 ID:???]: みんなと仲良く出来ない香具師が多いのか？
仕事で嫌な事でもあったのか？
546 名前：NAME IS NULL mailto:sage [2009/06/15(月) 06:32:15 ID:???]: >>544
「てにをは」がおかしいだろ。それを無理に解釈するならば、
「IDでテーブルを保持する」でも意味が通じると思い込むことが
可能だ。
547 名前：NAME IS NULL mailto:sage [2009/06/15(月) 07:16:31 ID:???]: 関係＝テーブル、ってのがわからん。
548 名前：NAME IS NULL mailto:sage [2009/06/15(月) 07:37:51 ID:???]: 例えば上の例で、「アカウント名」と「権限名」には本来なんの関連もない。
この2つの値の間になんらかの対応関係があることを表現したものがリレーションであり
すなわちテーブルであるということ。
549 名前：NAME IS NULL mailto:sage [2009/06/15(月) 07:45:10 ID:???]: 2行目までは理解できるけど、3行目がわからん。
「すなわち」って言われてもなぁ・・・

テーブルとテーブルの関係＝リレーションだとしたら、
テーブル != リレーションだろ。
550 名前：NAME IS NULL mailto:sage [2009/06/15(月) 08:36:47 ID:???]: テーブルとテーブルの関係じゃなくて値と値の関係。
ここで言っているのは(アカウント名,権限名)という
テーブルのこと。
このように両方の値を含むテーブルがどこかに存在
しない限り、どうやってもその寛刑を表現することは
できない。
551 名前：NAME IS NULL mailto:sage [2009/06/15(月) 09:18:17 ID:???]: 正規化
552 名前：NAME IS NULL mailto:sage [2009/06/15(月) 11:38:11 ID:???]: 自分に正しい知識がないのを棚に上げて
相手に「コミュ力無し」と言ってしまう奴は
DB設計なんかに関わるな
553 名前：NAME IS NULL mailto:sage [2009/06/15(月) 12:16:53 ID:???]: >>550
関係データベースモデルにおける「関係」(relation)と、
その実装である表(table)は本来別物。
数学的にもそれぞれ異なる性質を持っている。

なので安直にテーブル=リレーションと括るのはどうも。
554 名前：NAME IS NULL mailto:sage [2009/06/15(月) 12:44:24 ID:???]: 確かにそうだけど、リレーショナルモデルとERモデルの区別すら
ついてなさそうな人にそこから説明してたらさらにわけわかになるような。
555 名前：NAME IS NULL mailto:sage [2009/06/15(月) 16:22:18 ID:???]: まあ職業がSEとかプログラマってやつでも
リレーションシップの意味でリレーションって言ってるのは耳にするよ

で、そういうヤツに限って、客に専門用語で喋って
理解されないのは客が無知だとか言い出す(笑)
556 名前：名無し募集中。。。 [2009/06/15(月) 16:56:16 ID:xNy+RduF]: リレーションってテーブル同士の関連以外の意味で使わないだろ
557 名前：NAME IS NULL mailto:sage [2009/06/15(月) 17:08:13 ID:???]: まぎらわしい用語が悪いんじゃない？
558 名前：NAME IS NULL mailto:sage [2009/06/15(月) 18:39:47 ID:???]: 用語の良し悪しはともかく
「IP？IPアドレスのことだろ」とか
「携帯って持ち運ぶって意味なんだけど。携帯電話って言えよ」とか
得意げに言い出すヤツはなー。
559 名前：NAME IS NULL mailto:sage [2009/06/15(月) 19:37:02 ID:???]: >>558
メールとかでIPって言う分にはスルーするが、テーブルのカラム名にXxxIpとか使い始めたときは
さすがにつっこんだわ。
560 名前：NAME IS NULL mailto:sage [2009/06/15(月) 20:33:50 ID:???]: まーでもテーブルがリレーションってのは有り得ないのは間違いないな
テーブルの関係性がリレーションだろ普通に
テーブルがリレーションなら
それの関係性はリレーションのリレーション
ってことにならないと辻妻合わない
561 名前：NAME IS NULL mailto:sage [2009/06/15(月) 20:50:38 ID:???]: リレーショナルデータベースの理論においては、「テーブルの関係性」に相当する
概念がそもそも存在しないんだよ。
あるとすれば、E-RモデルのRelationshipか、実装での FOREIGN KEY とか。
562 名前：NAME IS NULL mailto:sage [2009/06/15(月) 22:15:06 ID:???]: ウチの上司は最初に触ったWebアプリがCGIと呼ばれてたので、
以後、JavaServletでもPHPでも何でもWebアプリ＝CGIって呼んでるよ。
563 名前：NAME IS NULL mailto:sage [2009/06/15(月) 23:04:49 ID:???]: >>560
564 名前：NAME IS NULL mailto:sage [2009/06/16(火) 00:35:27 ID:???]: >>555
客に話す場合と「DB設計を語るスレ」とでは使い分けるよ
565 名前：NAME IS NULL mailto:sage [2009/06/16(火) 01:24:11 ID:???]: つまらん! おまえらの話はつまらん!
566 名前：NAME IS NULL mailto:sage [2009/06/16(火) 03:23:04 ID:???]: 昔はもうちょっと面白い話出てたのに揚げ足の取り合いレベルのスレになったか。
こんなので盛り上がれてうらやましいよ
567 名前：NAME IS NULL mailto:sage [2009/06/16(火) 03:29:00 ID:???]: 昔は今はとかじゃなくて
定期的におかしなのは出てきてた
568 名前：NAME IS NULL mailto:sage [2009/06/16(火) 20:50:30 ID:???]: 関係(relation) R とは，属性 A1,…,An が与えられ，それぞれのドメインを D1,…,Dn とすれば，
直積 D1×D2×…×Dn の有限部分集合である．

だから、関係(relation)はテーブルと考えていい。
569 名前：NAME IS NULL mailto:sage [2009/06/16(火) 20:53:26 ID:???]: テーブルとテーブルの「関係」は関係代数おける和，差，共通，直積などの集合演算と
射影，選択，結合，商などの関係モデルの基本操作をいう。
570 名前：NAME IS NULL mailto:sage [2009/06/16(火) 21:35:23 ID:???]: 実務でＤＢいじってる奴が　テーブル＝リレーション　とか言ってるのは今のところ見たこと無い。
リレーショナルモデルの学問では　テーブル＝リレーションなのかな。

だとすると、リレーショナルモデル視点とリレーショナルデータベース（の実装）視点では食い違いが出るはず。
571 名前：NAME IS NULL mailto:sage [2009/06/16(火) 21:56:07 ID:???]: 誰か理論を語るスレ立てろよ
572 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:14:45 ID:???]: >>570
クエリーの結果もビューもリレーション。
573 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:23:06 ID:???]: >>572

どっち視点で？
574 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:32:30 ID:???]: あっち支店で
575 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:34:16 ID:???]: >>573
リレーショナルモデルの視点で。
リレーショナルモデルでは表形式のデータはリレーションだから。
576 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:36:20 ID:???]: >>570
実務だとそうだねぇ。それだけ現場にはキチンと理論を学んだ人がいないってことだな。
で、そういう人に限って「コボラーwwww」なんて言ってんだよな。
自分より下の存在があることを確認してないと生きていけないみたいに。
577 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:40:39 ID:???]: そんなもんだろ。
プログラミングとはちょっと勝手が違うしな。
DB専任技術者なんていないプロジェクトの方が当たり前だし（いてもインフラ系で物理設計しかやらんとか）。
578 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:47:10 ID:???]: なんでインフラが物理設計やるんだ？
579 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:51:03 ID:???]: >>575

リレーショナルデータベース視点だと、クエリーの結果もビューも演算結果。
580 名前：NAME IS NULL mailto:sage [2009/06/16(火) 22:56:09 ID:???]: >>576

ＤＢを単なる順編成ファイル置き場としてしか見てないＣＯＢＯＬな人が多いですよ。
理解してる人はちゃんとクエリ出すし、必要に応じてカーソル使う処理書いたりしてる。

でも圧倒的に前者が多い。他所だと違うのかもしれんけど。
581 名前：NAME IS NULL mailto:sage [2009/06/17(水) 02:00:46 ID:???]: DB専任なんてコストのかかる状況自体が好まれないからな。
出来るだけ少人数に抑えれば、それだけ儲けるし。中途半端でも兼任出来る香具師のほうが好まれてしまう罠。

DB専任は、周りに理解されてない香具師が多いのかもな。
ちゃんとSEやプログラマや上司や客とも仲良く成れよ。
582 名前：NAME IS NULL mailto:sage [2009/06/17(水) 03:11:33 ID:???]: まさかとは思うが物理設計をハード側だと思ってる奴いないか？
583 名前：NAME IS NULL mailto:sage [2009/06/17(水) 04:20:32 ID:???]: >>568
釣り?
ちゃんと丁寧に書いてある教科書ならリレーションとテーブルの
似て異なる点が書いてあると思うけど・・・

>>570
>リレーショナルモデルの学問では　テーブル＝リレーションなのかな。
普通区別します。リレーションは数学上の抽象概念で、テーブルは
その視覚的表現だったりSQLで扱うテーブルのような実装を指します。

実際のテーブルには行に順序があったり重複があったりしますので、
「ドメインの直積の有限部分集合」という一般的なリレーションの
定義とは異なる部分も出てきます。
584 名前：NAME IS NULL mailto:sage [2009/06/17(水) 19:44:15 ID:???]: その学問上のリレーションを実装するときに、
関係を格納するテーブルを使うからリレーション＝テーブルとかいってるんじゃないのか？
585 名前：NAME IS NULL mailto:sage [2009/06/18(木) 09:37:55 ID:???]: 連関エンティティのことですか？
586 名前：NAME IS NULL mailto:sage [2009/06/18(木) 11:44:31 ID:???]: なんでやねん。
リレーションは、属性間での関係のこと。
587 名前：NAME IS NULL mailto:sage [2009/06/18(木) 15:09:19 ID:???]: 関係データベースの「関係」ってのはテーブル間の関係ではなくて、属性間の関係のこと
実装としてはテーブルがこれに該当する（差異はあるが）
588 名前：NAME IS NULL mailto:sage [2009/06/18(木) 21:43:18 ID:???]: >>585
エンティティとリレーションシップで考えるのはE-Rモデル。リレーショナルモデルと
イコールではない。
やっぱり混同している人は多いんだな。
589 名前：NAME IS NULL mailto:sage [2009/06/18(木) 22:52:11 ID:???]: MSのアクセスには「リレーションを設定する」とか「リレーションシップ」とかの機能があるんだよな。
アクセスのユーザーはリレーション＝テーブル間の関係＝JOINのキー設定というイメージが
ついてしまう。
590 名前：NAME IS NULL mailto:sage [2009/06/19(金) 00:48:43 ID:???]: つまりアクセス廚とそれ以外の間での話か。
591 名前：NAME IS NULL mailto:sage [2009/06/19(金) 00:53:31 ID:???]: レッテル貼り乙。
テーブルをリレーションと表記しているDBMSをいくつか挙げてくれ
592 名前：NAME IS NULL mailto:sage [2009/06/19(金) 06:03:55 ID:???]: postgresとか。
593 名前：NAME IS NULL mailto:sage [2009/06/19(金) 12:33:46 ID:???]: Accessも「リレーションシップ」であって「リレーション」じゃないんだよな。
594 名前：NAME IS NULL mailto:sage [2009/06/19(金) 23:33:59 ID:???]: www.microsoft.com/japan/office/previous/xp/suminaka/access/katuyo/katuyo2_1.htm
595 名前：NAME IS NULL mailto:sage [2009/06/20(土) 02:53:32 ID:???]: またAccessか!
596 名前：NAME IS NULL mailto:sage [2009/06/20(土) 03:20:53 ID:???]: というか、そのディレクトリ名やファイル名はもう少しなんとかならんかったのかと
597 名前：NAME IS NULL [2009/06/23(火) 10:42:38 ID:tL+3Dp5k]: 基本的なことかもしれないですが、教えてください。

ＤＢは PostgreSQL , Oracle ,MSSQL のいずれかを考えており、まだ決まっていないので
一般的に、ということで教えてください。

パフォーマンスを考慮すると、長い文字列を主キーとして使っていいものか、それとも１：１に
対応される数値型のコードを作成すべきか、悩んでいます。

　本来であれば１：１に対応できるコードであれば無駄、と思うのですが、　Indexの性能を
発揮できるのは　数値型なのかとも思います。

　製品コード（英数ＭＡＸ３０桁）
　データ量:　ＭＡＸ１０００万件
　リレーション貼られるテーブル数：約１０個

皆さんであればどのような設計しますか？
598 名前：NAME IS NULL mailto:sage [2009/06/23(火) 15:12:59 ID:???]: どっちでも変わらんよ
599 名前：NAME IS NULL mailto:sage [2009/06/23(火) 15:31:35 ID:???]: ハッシュ化して比較するから、かわらんわな。
600 名前：597 [2009/06/23(火) 17:26:51 ID:tL+3Dp5k]: ぁ、そうなんですか。

ググってみたところ、 MySQL の InnoDB では長いＰｒｉｍａｒｙＫｅｙを持つと遅くなる、
という記載があったので、　他のＤＢでも同じなのかな？と思っていました。
MySQL自体あまり知らないので何とも言えないのですが。

ソース：
dev.mysql.com/doc/refman/5.1/ja/innodb-tuning.html
> InnoDB 内では、長い PRIMARY KEY を持つと、その値が全てのセカンダリインデックス
> レコードを利用して格納される為、ディスク領域の無駄遣いになります。（詳しくは項13.5.13.
> 「InnoDB テーブルとインデックス構造」をご確認ください。）
> もし主キーが長かったら、AUTO_INCREMENT カラムを主キーとして作成してください。

ありがとうございました。気にせず　文字列を主キーとして使ってみます。
601 名前：597 [2009/06/23(火) 18:03:13 ID:tL+3Dp5k]: 597です。

　もう１つ教えてください。

　ＰｒｉｍａｒｙＫｅｙが複合キーだった場合でも同じですか？

　製品コード＋リビジョン　でユニークになる場合、とか。

　この場合は他テーブルとのリレーションシップも複合キーになってしまうので、
　製品コード＋リビジョン　と　１：１になるユニークなＩＤを付けたほうがいいのでしょうか。
602 名前：NAME IS NULL mailto:sage [2009/06/23(火) 18:12:35 ID:???]: >>601
変わらない変わらないといわれてもどうせ時間がたてば
「製品コードの桁数とかコード体系変更するから」とあっさり言われるのがオチなので
最初っから製品コードなんか主キーには使わないな俺は。
603 名前：NAME IS NULL mailto:sage [2009/06/23(火) 19:18:43 ID:???]: それはカネ取っていいレベル
604 名前：597 [2009/06/23(火) 19:21:59 ID:tL+3Dp5k]: 　>>602
それを踏まえて　主キーであっても　varchar() にしておき、桁数もちょっと余裕をみておく、
　というのと、　AutoNumber でＤＢ内独自コードを主キーとして追加する、というのでは
　主流は　ＡｕｔｏＮｕｍｂｅｒなんですかね。

　varchar を主キーに使わない理由、ってあるんでしょうか。
　それともいつ変わるかわからないものを主キーにはしたくない、という思想なのでしょうか。
605 名前：NAME IS NULL mailto:sage [2009/06/23(火) 19:38:29 ID:???]: varcharを主キーに使わない理由なんてないよ。
型に関係なく「なんちゃらコード」の類いはだいたい>602の理由で主キーにするのが避けるのがノウハウってだけ。
業務用件しだい(コード体系変更の場合でも古いコード体系も蓄積していく、とか)でコードをそのまま主キーにできる場合もあるし。
606 名前：NAME IS NULL mailto:sage [2009/06/23(火) 19:41:51 ID:???]: 主キーはNULL不可かつ重複不可でしょ。
客先は一意だと言ってても、それが将来的に保証されることはない。（実際に食らわされたことあり）
DB内独自コード（サロゲートキーといいます）をつければ、どんな理不尽なことがあっても主キーの条件は守られる。
varcharでもいいと思うよ。ただし、後に泣くことが1%もないとは言い切れない。ただそれだけ。
607 名前：NAME IS NULL mailto:sage [2009/06/23(火) 19:55:20 ID:???]: 後出しで「製品コードは後からあらためて付番するから、無い場合もある」って要件が出てきたこともあったな…
IDをプライマリにしていたからそれでも良かったんだけど、
「製品コードが無い分の納品書は製品コードで検索できない」って当たり前のことをいくら説明してもわかってくれなかったよ。
608 名前：NAME IS NULL mailto:sage [2009/06/23(火) 20:14:06 ID:???]: 主キーはNULL不可かつ重複不可かつ不変であること
609 名前：NAME IS NULL mailto:sage [2009/06/23(火) 20:44:40 ID:???]: >>600
MySQLはハッシュキーをサポートしてないからね。

サロゲートキーあたりの議論は相当古くから存在していて宗教問題みたいなものなのだけど、検索してみると双方の主張を見つけらるから興味があれば調べてみるといいよ。
610 名前：NAME IS NULL mailto:sage [2009/06/23(火) 20:51:15 ID:???]: すみません嘘つきました。InnoDBはハッシュインデックスサポートしてたんだ。出直して来ます…
611 名前：597 [2009/06/23(火) 21:42:17 ID:tL+3Dp5k]: 皆様、ご回答ありがとうございます。

ググってみても、やはりサロゲートキーをやっておけばあとあと何があっても対応できる、との
記事が目立ちました。

サロゲートキーを使うと、複数テーブルを見ないとわかんないので何か面倒くさいなぁ、と思っていたのですが
この部分は過去に痛い思いをした人しか実感できない重みのようなものがふつふつと見えてきましたので
皆さんの忠告どおり、サロゲートキーで作ることにします。

ありがとうございました。
612 名前：NAME IS NULL mailto:sage [2009/06/23(火) 23:07:34 ID:???]: >>606
ここまで極端だとサロゲート「厨」と言っていいレベルだな。
どうせ後で変更されるから業務分析も要件定義も意味ないと
言っているようなもん。
そもそもセマンティクスが変わってるのに「主キーの条件」だけ
守ることにどんな意味があるの。
613 名前：NAME IS NULL mailto:sage [2009/06/23(火) 23:18:10 ID:???]: 同意だな。
そこまで病的に主キーに拘る理由が解らん。
サロゲートを使うのは要件次第と思うが。

アフォな要求にムリに答える事はないと思うが。
顧客に対して「はい」しか言えないエンジニアは常に痛い思いしかしない。
614 名前：NAME IS NULL mailto:sage [2009/06/24(水) 00:12:30 ID:???]: まぁ、ちゃんと意味があるサロゲートキーももちろんあるんだろうけど、
2chに書かれてる実体験てのを見てると、検討が甘かったのをなんとか
辻褄合わせようとする一種のバッドノウハウにしか思えないもんね。
615 名前：NAME IS NULL mailto:sage [2009/06/24(水) 10:28:16 ID:???]: >>600
セカンダリインデックスって何？
616 名前：NAME IS NULL mailto:sage [2009/06/24(水) 10:47:22 ID:???]: 大して極端ではないと思うが。。。

「サロゲート」キーという名前が悪いかもな。
あくまで存在そのものに対する識別子は非常に有用なんだけども。
617 名前：NAME IS NULL mailto:sage [2009/06/24(水) 11:16:07 ID:???]: コンピュータだけでなく業務も含めて知識と権限があれば自然キーを主キーに出来るんだけどな。
多くの場合権限がなかったり、
業務系の深い知識が身に付くのがシステムが完成してからだったりする。
バットノウハウというより必要悪だろう。
権限も知識もないのにごり押しでキーを決めちゃって業務手順まで変えさせた挙句、
動かないシステムを作っちゃった人もいたなぁ。
618 名前：NAME IS NULL mailto:sage [2009/06/24(水) 13:02:25 ID:???]: >>616
キチンと意識して、本来のサロゲートキーとして使う分には問題ないんだけどね。
それを主キーの将来の変更が容易になるなどと考えて安易に使うのがおかしいだけで。
特に対応する自然キーが存在せず内部的な人工キーでしかレコードを特定できない
テーブルなどは、余計に注意しないとそれが何を表しているかわからないカオス
状態になりかねないからねぇ。
ID=1のレコードと2のレコードのどちらを選択すべきか、IDしか手掛かりがなければ
お手上げでしょ？
619 名前：NAME IS NULL mailto:sage [2009/06/24(水) 13:16:09 ID:???]: >>618
主キーをどうするかという全く実装上の話にすぎないで、自然キーを無くすわけじゃないよ。
620 名前：NAME IS NULL mailto:sage [2009/06/24(水) 13:25:11 ID:???]: 1か2のどちらを選択すべきかってそりゃ指定された方を選択するんだろう。何言ってんだお前
621 名前：NAME IS NULL mailto:sage [2009/06/24(水) 18:06:44 ID:???]: そもそも製品コードというのはユーザのビジネスの都合で決定されるものであって
システムの都合で決定されるものではない。

それをシステムの主キーにしていたからコード体系を変更することができませんとか、
改修費用がかかりますとかは論外だろｊｋ

ユーザをサポートするのがシステムの役割であって足をひぱってどうする。
622 名前：NAME IS NULL mailto:sage [2009/06/24(水) 18:23:11 ID:???]: そもそも論をぶつ人の言うことは聞かないようにしている。
623 名前：NAME IS NULL mailto:sage [2009/06/24(水) 19:04:13 ID:???]: >>621
業務のためにシステムを作ってんだったら、業務ルールが変更されたらシステム改修が
必要になるのは当たり前だと思うけどね。
改修が必要になっても費用を払ってくれないような困った顧客と付き合っているのなら
ともかく。
624 名前：NAME IS NULL mailto:sage [2009/06/24(水) 19:21:24 ID:???]: ビジネスにもシステムにも明るくにらみの効くお偉いさんがいるならいいのだけれど、
まずいないからねぇ。
外注SEに出来ることは限られる。
625 名前：NAME IS NULL mailto:sage [2009/06/24(水) 19:21:51 ID:???]: なんかすげーCOBOLちっくなのがいるなｗ
626 名前：NAME IS NULL mailto:sage [2009/06/24(水) 20:40:47 ID:???]: 確かに。
「後で必要になるかもしれないから」と言って予備のカラムをたくさん
作っちゃうんだろうな。こういう人達は。
627 名前：NAME IS NULL mailto:sage [2009/06/24(水) 20:56:01 ID:???]: >>621
事前に「変わらない」という合意を得ていたのに
後から「やっぱ変えます」じゃあ費用がかかりますと言われて当然

変えちゃいけないんじゃなくて
変える可能性があるものを「変わりません」なんて言うなって話。
628 名前：NAME IS NULL mailto:sage [2009/06/24(水) 21:18:06 ID:???]: >>627
お客さんが「変わらない」と言うからなんてのはアレだな。
629 名前：NAME IS NULL mailto:sage [2009/06/24(水) 21:39:33 ID:???]: 結局、顧客と上手くコミュニケがとれてない人の予防策がサロゲート信仰って気がするな。

普通にビジネスしろよ。
630 名前：NAME IS NULL mailto:sage [2009/06/24(水) 21:56:36 ID:???]: >>628
ちゃんとドキュメント書けよ、議事録残せよ。
何度か痛い目見れば、誰のためでもなく自分のためだとわかるはず。
631 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:07:42 ID:???]: >>630
話が食い違うな。
ドキュメントも書くし、議事録も残すし、顧客とコミュニケーションもとるよ。
その上で顧客の言う「製品コードは不変です」の上を行くようにしないとな。

議事録突きつけて「変わらないって言ったよね」って金を取るのもいいけどさ。
632 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:18:58 ID:???]: 「上」ねぇｗ
633 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:26:17 ID:???]: 主キーを自然キーにするメリットって何だろうか
634 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:27:57 ID:???]: 客と合意を得た事項を「ひょっとしたら客が間違ってるかもしれないからどっちに転んでもいい実装にしておく」なんてのは馬鹿だろ。
「ひょっとしたら客が間違ってるかもしれない」をクリアにするのがあるべき姿。

疑い出せばテーブルの主キーだけですむ話ではない。
例えば製品コードは一意です、という前提が無いと
製品コードを入力し決定ボタンを押したらその製品の画面に飛ぶ、ということすら出来ない。
不変であるという前提が無ければ画面で製品コードを変更できるようにしておかなければならない。
画面も全部何パターンも用意するか？

ちゃんと「ひょっとしたら客が間違ってるかもしれない」をクリアしとけよ。
635 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:29:47 ID:???]: なんかSIerって感じだな
636 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:33:01 ID:???]: ごめん話にならないや。
637 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:34:55 ID:???]: その部分の話を顧客にちゃんとすると、
合意の上で結局サロゲートキーを持つことになるんだけどな。
言質取った議事録書いたやったーなんて態度のエンジニアは少なからずいるけど、
やっぱり煙たがられているよ。本人は賢く立ち回ってるつもりらしいけど。
638 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:37:47 ID:???]: 合意の上で製品コードはキーになりません、画面はこうなります、工数はこれだけ増えますなら何の問題も無い。
勝手にいろんなケースをたくさん想像して「ああなってもこうなっても対応しとこう」みたいなヤツは出来ないヤツだよ。
本人は賢く立ち回ってるつもりらしいけど。
639 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:38:08 ID:???]: ＞やっぱり煙たがられているよ。本人は賢く立ち回ってるつもりらしいけど。

実際には>>637なサロゲート厨が「現場からは煙たがられてる」に１票。
640 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:42:00 ID:???]: それは変更の可能性をあらかじめ織り込んだ設計って事で
なんも問題ないじゃん。
きちんとそういう検討をした上での結果ならいいんだよ。
ただ、全部のテーブルでそんな手間かける気にはならんだろ？
641 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:46:42 ID:???]: 勝手に宇宙に存在するあらゆる可能性を考慮したテーブル設計しといてくれ
642 名前：NAME IS NULL mailto:sage [2009/06/24(水) 22:51:29 ID:???]: サロゲート信者の言っている事って、なんか変なんだよな。

コードが一意でなくなる可能性のある部分の設計は「話し合いの結果サロゲート」ではなく
「最初からサロゲート」で問題ないはずなのに、「ここでサロゲート使う俺SUGEEE」て自慢が
あるのはなんとも厨房臭い。

粗悪な設計をして工数とりたいだけと違うのか？と小一時間(ry
643 名前：NAME IS NULL mailto:sage [2009/06/25(木) 00:10:10 ID:???]: 単に業務を知ろうとしないエンジニアの戯れ言としか思えない。
業務知らないのに、業務に最適化された設計なんて無理なんじゃｗｗｗ

客先に伺ってもうちょっとヒアリング詰めてまともな要件策定しろよ。

ヲレの設計はすばらしいから、ユーザは従えだろう。
ユーザは、実際に業務で使ってみて、このシステム使えないなと評価して、作ってるエンジニアは信用を失っていく。

製品コードって顧客でどの程度不変なのかヒアリングすれば(ry
簿記とか業務知識有れば、納品書には連番振って会計上の抜けが出ないようにするべきとか思いつくのにな。製品コードでしか検索出来ない仕様の時点で糞システム認定。
現場の他にも、経理とかからも納品書についていろいろ突っ込まれてそうｗｗｗ

いざ納品してみて、業務に合ってないからシステム使えないのに、更に改修費用を請求するのも詐欺だろう。
最初の設計が甘いのが原因だし、その甘い設計で業務まで変更してユーザに迷惑かけてたら目も当てられない。最初の開発費には、業務のヒアリングや設計も含まれてるでしょ。
644 名前：NAME IS NULL mailto:sage [2009/06/25(木) 02:18:57 ID:???]: >>642
>「ここでサロゲート使う俺SUGEEE」て自慢があるのはなんとも厨房臭い。
パラノイア気味だね。だれもそんなこと言ってないよ
小一時間とか○○厨房とか2ch語の使い方、以前も見た気がする。

もちろん候補キーは制約を含めてしっかり洗い出す。
その上で人工キーを主キーにすることでシンプルな実装になる。

無駄な予備フィールドもつようなバカ設計とは次元が違う話をしてるんだが。

で、自然キーのメリットって何よ？
645 名前：NAME IS NULL mailto:sage [2009/06/25(木) 06:15:28 ID:???]: 無駄な予備フィールドは要らないが、ちゃんとヒアリングしてちゃんと拡張出来る様な設計をしておくのが大事。
646 名前：NAME IS NULL mailto:sage [2009/06/25(木) 06:18:22 ID:???]: >>643
業務を知ろうとしてないという以前にヒアリング段階でアサインされるレベルに立ってない人か作り投げなんだろう。
まぁ、うまく中間取れない性質っぽいから客先出したり、企画なんか無理だろうけどね。

しかし、ほんとお前らサロゲートネタ好きだよなｗ
647 名前：NAME IS NULL mailto:sage [2009/06/25(木) 06:27:03 ID:???]: サロゲート厨はいい餌まいているんだろ。

正直、サロゲートを使うべきってヤツは大抵レベル低くてﾂﾏﾝﾈ
648 名前：NAME IS NULL mailto:sage [2009/06/25(木) 06:39:51 ID:???]: いや正直、嫌サロゲート厨もうざい。
649 名前：NAME IS NULL mailto:sage [2009/06/25(木) 07:10:55 ID:???]: 本人光臨か。
自作自演が痛々しい。
650 名前：NAME IS NULL mailto:sage [2009/06/25(木) 07:38:19 ID:???]: >>644
分析も何もしないまま、サロゲートキーにしておけば後々の変更に強いから良い、
という>>606みたいなバカ設計の話をしているんだが？
651 名前：NAME IS NULL mailto:sage [2009/06/25(木) 10:15:39 ID:???]: 大佐、指向性サロゲート粒子を
652 名前：NAME IS NULL mailto:sage [2009/06/25(木) 11:02:28 ID:???]: ID表示したら面白そうな流れだねえ
朝っぱらからご苦労さん
653 名前：NAME IS NULL mailto:sage [2009/06/25(木) 20:45:13 ID:???]: >>643
>製品コードでしか検索出来ない仕様
反論できなくてよっぽど悔しかったんだろうが
人の発言を勝手に「反論しやすい形」に歪めるのは感心しないな。
客からも「人の話ちゃんと聞いてます？都合のいいように曲解するのはやめてください」ってよく言われるだろ。
654 名前：NAME IS NULL mailto:sage [2009/06/25(木) 20:48:54 ID:???]: ＞人の発言を勝手に「反論しやすい形」に歪めるのは感心しないな。
ここにいる連中全員だろ（笑
全体的にかみ合ってないし。
655 名前：NAME IS NULL mailto:sage [2009/06/25(木) 20:59:28 ID:???]: そういう「○○君もやりましたー」とか言う小学生みたいな逃げ方もあるのか
656 名前：NAME IS NULL mailto:sage [2009/06/25(木) 22:16:04 ID:???]: なに！？この盛り上がり方

ははーん、このスレを盛り上げたいときはサロゲートキーの話題を書き込めばいいんだ
657 名前：NAME IS NULL mailto:sage [2009/06/25(木) 22:18:03 ID:???]: 猫にかつぶし
マルチスレッドスレにvolatile
DBスレにサロゲート

そろそろ満足したかい？
658 名前：NAME IS NULL mailto:sage [2009/06/25(木) 22:36:49 ID:???]: 盛り上がっているのはサロゲート厨が自作自演とか頑張っているからじゃね？
659 名前：NAME IS NULL mailto:sage [2009/06/25(木) 22:38:40 ID:???]: 嫌サロゲートは設計したことないんだろうな。
頭でっかちになるのもいいが、世の中は理屈だけじゃ通らないこともあるんだぜ？
客の言質が取れて金が貰えればいいってのはガキの主張だ。
660 名前：NAME IS NULL mailto:sage [2009/06/25(木) 22:47:31 ID:???]: 反論できなくなると人格攻撃、って芸のない。
661 名前：NAME IS NULL mailto:sage [2009/06/25(木) 23:04:39 ID:???]: >>659
その理屈をどう通すかってのも仕事として大事だわな。
だいたい、客の言うことが信用できないというときに
それを正面から質すことができないで小手先の対応を
するような奴がそんなセリフ吐くのはおこがましいと
いうかなんというか。
662 名前：NAME IS NULL mailto:sage [2009/06/25(木) 23:09:42 ID:???]: ふつう、客はDBのテーブル構造なんかには興味はないだろ。
663 名前：NAME IS NULL mailto:sage [2009/06/25(木) 23:11:10 ID:???]: どうでもいいことならともかく
「製品コードが不変かどうか」を曖昧にしたまま設計はしないわな。
テーブル以外にも影響出まくりだし。

とかいうと
「製品コードでしか検索できない仕様がクソ」
とか見えない相手に反論始めるんだろうけど。
664 名前：NAME IS NULL mailto:sage [2009/06/25(木) 23:31:14 ID:???]: スレを見てるとこんな感じだ。

○サロゲート厨
客は仕様をコロコロ変えるからテーブル設計はサロゲートがベスト。
俺は大人。反論するヤツはガキ。

○その他
サロゲートを使うのは要件次第。要件をしっかりと顧客と検討し設計する。
665 名前：NAME IS NULL mailto:sage [2009/06/25(木) 23:38:32 ID:???]: >頭でっかちになるのもいいが、世の中は理屈だけじゃ通らないこともあるんだぜ？

底辺の人はヤクザと仕事しているからそういう考えに至るのですね。解ります。

>客の言質が取れて金が貰えればいいってのはガキの主張だ。

普通に職業プロの行動原理かと。

ボランティア精神溢れるアマチュア精神丸出しでナニ言ってんだが。
666 名前：NAME IS NULL mailto:sage [2009/06/25(木) 23:44:14 ID:???]: ところで、
こういうケースは自然キーがいい、こういうケースはサロゲートキーのほうがいい
というのはないの？
667 名前：NAME IS NULL mailto:sage [2009/06/26(金) 00:29:12 ID:???]: 「サロゲートキーに自然キーを使う」ということをやろうと思えばできる?
って、サロゲートキーって正確なところの意味は何。
正確には自然キーの対義語じゃないんじゃないの。
668 名前：NAME IS NULL mailto:sage [2009/06/26(金) 01:02:37 ID:???]: >こういうケースは自然キーがいい、こういうケースはサロゲートキーのほうがいい
>というのはないの？

業務知識とか欠如した人間が設計する時に下手にサロゲートを導入していくと、
システムが複雑になって工数がかかり、顧客からカネをブン取れて、
メンテも面倒なケースがあるので、維持コストも高くて保守費用が
高くなるから、そういう意味でメリットはあると思うが。
669 名前：NAME IS NULL mailto:sage [2009/06/26(金) 02:24:06 ID:???]: >>668
>業務知識とか欠如した人間が設計する時に下手に
であれば、サロゲートキーでも自然キーでもだめでしょ。ばかなの？

要件をしっかりと検討するのとは別の次元で、IDを主キーにするのは有用だと思うよ。
670 名前：NAME IS NULL mailto:sage [2009/06/26(金) 02:51:12 ID:???]: 自然キーを主キーにするメリットってあるのだろうか
671 名前：NAME IS NULL mailto:sage [2009/06/26(金) 04:46:20 ID:???]: 余分な列を減らせる、とか？
672 名前：NAME IS NULL mailto:sage [2009/06/26(金) 06:27:29 ID:???]: >>670
たいしてない。
設計者のエゴ。
673 名前：NAME IS NULL mailto:sage [2009/06/26(金) 07:34:32 ID:???]: 若造なのですがサロゲートキーの場合、JOINのON句で悩むような気がします。
コメントなりなんなりに「○○で一意になる」などと書いておくのが定石なのですか？
ご批判お願いします。
674 名前：NAME IS NULL mailto:sage [2009/06/26(金) 07:47:36 ID:???]: >>673
それ逆じゃないの？
サロゲートキーは自然キーが複合キーなど技術的な理由で扱いづらい場合に
使うもので、関連のあるテーブルは当然サロゲートキーで結合するものだよ。

これまでも出てるけど、
自然キーについての十分な検討をしないままID列をつけておけばいい
といった考え方をするのがおかしいといってるわけで、
そういった考え方をしている人は否定派の脳内にしかいないように思えるんだがね。
675 名前：NAME IS NULL mailto:sage [2009/06/26(金) 09:00:18 ID:???]: 顧客から提示された自然キーを無批判に主キーにしてしまうというのも
逆に肯定派の脳内にしかいないな。
676 名前：NAME IS NULL mailto:sage [2009/06/26(金) 10:15:47 ID:???]: >>675
そんなこと言っているやつは君の脳内にしかいないな
677 名前：NAME IS NULL mailto:sage [2009/06/26(金) 10:31:01 ID:???]: >>673
ON句は関係ないんじゃないかね？
SELECT * FROM foo JOIN bar ON foo.id = bar.foo_id

「○○で一意になる」というのは普通にユニークインデックスや制約をつければいい。

否定派（というか一人だけ？）は主キー以外のキーは存在しないと思っているのだろうか？
678 名前：NAME IS NULL mailto:sage [2009/06/26(金) 11:43:37 ID:???]: >>666
EJBやRoRといった近頃のフレームワークを使うなら人工キーが主流。
複合主キーはレガシーシステムを扱わざるを得ない場合のオプション的な扱い。

システムがシンプルになって工数が減り、メンテも容易なケースがあるので、維持コストも低くて保守費用が安くなるかもね

One fact in one placeの理念から言っても自然キーは分が悪い。
「○○コード２桁＋△△区分１桁＋・・・、で××の場合は最後２桁が９９」
のように識別子や外部キーとしては不要で、変なしがらみをもった情報が複数箇所に散らばってしまいやすい。
679 名前：NAME IS NULL mailto:sage [2009/06/26(金) 12:35:24 ID:???]: どちらでもイケる両刀遣いになってれば良い。実現手段にサロゲートの呪文しか唱えられないなら客は引く。
客の理解可能なキーの話をして理解してもらった上で、もしもの保険、サロゲートキーの話に持って行けば良い。
客は今問題になっている点を解消したい訳なんだから、あんまり未来の話(キーが変わるかも云々)をされたって嬉しくない。
フレームワークで勝手に作られる物に関してなら大して気にはしないけど。
680 名前：NAME IS NULL mailto:sage [2009/06/26(金) 12:50:11 ID:???]: あぁなるほど。オブジェクトモデルでしか考えたことがない人だったのか。
そりゃギャップがあるわ。
もしかして、「最近のフレームワーク」しか使ったことがなくて、そもそも
インピーダンスミスマッチすら意識したことがないのかもね。
681 名前：NAME IS NULL mailto:sage [2009/06/26(金) 13:01:41 ID:???]: で、自然キーを主キーにするメリットは？
682 名前：NAME IS NULL mailto:sage [2009/06/26(金) 13:39:46 ID:???]: 誰かまとめて
683 名前：NAME IS NULL mailto:sage [2009/06/26(金) 13:46:48 ID:???]: >>681に答えてもらわないと、まとめる価値のあるような議論にならないな
684 名前：NAME IS NULL mailto:sage [2009/06/26(金) 14:02:13 ID:???]: 主キーたる候補がある場合、それを主キーにする
自然な話だよな。だから普通にそうすればいい。それが自然キー

主キーたる候補がない場合、あるいはその主キーが使いにくい場合
代わりの項目をつかう。それがサロゲート

主キーが自然キーなのはメリットないよ。自然にそうなるだけで
自然キーを主キーにするのにデメリットが多ければサロゲート使うだけ

>>678
「○○コード２桁＋△△区分１桁＋・・・、で××の場合は最後２桁が９９」
あのな、コードの一部を抜き出してなんかしないといけない時点で、設計が間違ってるんだが

最近のフレームワークが代理キー推奨なのは、こういうアホな設計でもなんとかできるようにだな
代理キーつくった時点で、代理キーと本来の自然キーとのしがらみを増やしてることにも気づけよ
685 名前：NAME IS NULL mailto:sage [2009/06/26(金) 14:06:16 ID:???]: まずサロゲート（代替）キーという呼び方をやめた方が良い。
686 名前：NAME IS NULL mailto:sage [2009/06/26(金) 14:06:37 ID:???]: >>681
客も設計者も理解が早い。そのシステムの世界での共通語で構成されてるから。ほぼ妥当だろうしユーザレベルでの検証も可能だしアンドキュメンテッドな仕様による不都合の指摘も貰える可能性が高い。

…まとめが見てみたいからとりあえず書いてみた。
687 名前：NAME IS NULL mailto:sage [2009/06/26(金) 14:35:04 ID:???]: >>684
主キーたる候補って「○○コード２桁＋△△区分１桁＋・・・」が多数じゃね？
いくらユーザが「変わらない」と言ったって、主キーにするには弱いと思う。

>主キーたる候補がない場合、あるいはその主キーが使いにくい場合
>代わりの項目をつかう。それがサロゲート
ここで思考停止してるんだろうな
自然キーの代わりとしてではなく、積極的に情報を指すポインタとして主キーの実装は人工キーにしたら良いと主張しているのですよ。

>>686
ありがとう
仕様、外部設計と呼ばれるような部分は、もちろんそれで良いと思う。
688 名前：NAME IS NULL mailto:sage [2009/06/26(金) 14:48:02 ID:???]: 人工キーの導入は正規化の一種といえるのではないかと思った。

ユーザと打ち合わせるのは正規化前の状態。
正規化したテーブル構造をユーザは理解できないし必要もない。

情報の分散、重複をなくして変更に強くする。

そういえば正規化を理解していない人を相手にしているのと同じ感じを受ける。
689 名前：NAME IS NULL mailto:sage [2009/06/26(金) 15:50:00 ID:???]: その主キーと自然キーだけのテーブルを作るの？
690 名前：NAME IS NULL mailto:sage [2009/06/26(金) 15:57:25 ID:???]: >>689
その必要はないな。非NULLでユニークなキー（候補キー）がテーブルに２つあるでいい。
691 名前：NAME IS NULL mailto:sage [2009/06/26(金) 17:29:16 ID:???]: >>687
○○コード＋△△区分で主キー候補なら、人工キー作れば良いと思うよ
○○コードの下２桁＋△△区分の上１桁とか言い出したら設計が間違ってる

で、お前の言う
>自然キーの代わりとしてではなく、積極的に情報を指すポインタとして主キーの実装は人工キーに
ってのは、○○コードだけで主キー候補たる場合でも
○○コードを主キーにせずに人工キーを作れって主張だと理解してＯＫなのか？
692 名前：NAME IS NULL mailto:sage [2009/06/26(金) 18:27:34 ID:???]: >>691
>○○コードを主キーにせずに人工キーを作れって主張だと理解してＯＫなのか？
そうだよ。

○○コード＋△△区分って程度の複合キーでも人工キーにしちゃうの？
だったらかなりの部分が人工キーにならないかい？
いっそ全部人工キーに統一しちゃえばすっきりすると思わないかな。

それ以外で主キー候補たる自然キーって少ないよね。例えば何かあるかい？
693 名前：NAME IS NULL mailto:sage [2009/06/26(金) 18:45:02 ID:???]: 複合で主キーなら人工キーつくる場合が多いな、俺なら
たけど、>いっそ全部人工キーに統一しちゃえってのはそれこそ思考停止

全部に人工キー作れって主張があるのはしってるし
実際俺は全部のテーブルに人工キー作ってみたこともあるぞ
その結果で言えば、全部に人工キーつくるのは明らかに無駄な作業を増やすだけ

ＯＲマッピングとか前提なら話は違うのかもしれんがな
694 名前：NAME IS NULL mailto:sage [2009/06/26(金) 19:32:36 ID:???]: 業務で出てくる○○コードって
「分類区分１桁＋西暦２桁＋連番２桁＋サイズ＋色」
「入学年２桁＋学科区分２桁＋連番」
のような体系になっているんだよねえ
695 名前：NAME IS NULL mailto:sage [2009/06/26(金) 21:49:48 ID:???]: 厨房の宿題みたいな体系だな。

漏れの知っている保険関係のテーブルだと、加入者テーブルは
加入者コードが一意で主キーで、保険商品が４種類(A,B,C,D)あったとしたら

A+連番10桁
B+連番10桁
C+連番10桁
D+連番10桁

てなかんじでほどよい(?)いい加減さがあったぞ。
個人的には、こんなん連番12桁にしておいて、別カラムで保険商品コード持たせれば？
って思ったものだけど。

とは言えこれでサロゲートキー作って主キーにしようとは思わんな。

これらの関連として会員テーブル、送付先住所テーブル（愛人対策テーブルとも言うｗ）、家族テーブル、変更履歴テーブル
とかあるが、それらにサロゲートとか使っていたらウザくてしょうがない。むしろミスが増えそうだ。
696 名前：NAME IS NULL mailto:sage [2009/06/26(金) 22:44:40 ID:???]: >>695
人が扱うにはその方が都合が良いから、そのコード体系が悪いわけではない。
人かコンピュータかどちらが扱うのか、ドメインが違えば正しい解も違う。

> 連番12桁にしておいて、別カラムで保険商品コード持たせれば？
> って思ったものだけど。
それが人工キーだろw
697 名前：NAME IS NULL mailto:sage [2009/06/26(金) 22:54:42 ID:???]: 695のいうサロゲートは連番なんだろう。
698 名前：NAME IS NULL mailto:sage [2009/06/26(金) 22:57:32 ID:???]: >>687
それって古のネットワーク型DBや、その焼き直しであるオブジェクトDBの考え方。
主張するのは別に悪いとは言わんが、それが当然と考えているならアレだ。
699 名前：NAME IS NULL mailto:sage [2009/06/26(金) 23:02:17 ID:???]: 業務で扱っているコードなんて、担当者がコードだけみてある程度情報を判断できるように作るものだからな。

そうじゃなければただの連番になるだろうし、そうなるとコンピュータが採番するか人が採番するかの違いだけで、そりゃ人工キーだろって話よ。
700 名前：NAME IS NULL mailto:sage [2009/06/26(金) 23:06:06 ID:???]: まあDOA(笑)の人なんだね
701 名前：NAME IS NULL mailto:sage [2009/06/26(金) 23:23:41 ID:???]: かすみなんて知らないが。
702 名前：NAME IS NULL mailto:sage [2009/06/26(金) 23:39:02 ID:???]: 主キーで使っているコードに意味を持たせてしまうと主キーの変更が発生しやすくなる。
そうならないように管理されているなら問題ないが、
一意性と可読性を両立するのは難しいこともあるなぁ。
703 名前：NAME IS NULL mailto:sage [2009/06/27(土) 00:08:29 ID:???]: >>687

賑わってるｗｗ

>積極的に情報を指すポインタとして主キーの実装は人工キーにしたら良いと主張しているのですよ。

そういう考え方があるのも理解してる。DWHで使うようなスタースキーマ構造を作るんならそれだろうと思う。
理論というか、理想としてそういうのはあってもよいと思う。

でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。
「業務コードが変わったり｣する事は織り込み済み。定期的なコード洗い替え処理やるしね。
業務コードを変えて、ひも付けや関連情報を変更することを必要としてることも多いのよ。

サロゲートキーで｢業務コードが変更されてもだいじょうぶ｣にするのもやり方だけど、変更を許してそれによって円滑に進めるやり方もある。

だから
> 仕様、外部設計と呼ばれるような部分は、もちろんそれで良いと思う。

なんて聞くと、と正直｢大丈夫？｣とか思う。ヒアリングの結果どうすべきか（大好きなサロゲートキーを使うかどうか）判断するくらいの余裕を持とう。
704 名前：NAME IS NULL mailto:sage [2009/06/27(土) 00:38:08 ID:???]: >>703
>サロゲートキーで｢業務コードが変更されてもだいじょうぶ｣にするのもやり方だけど、変更を許してそれによって円滑に進めるやり方もある。
違いがわからん。

>業務コードを変えて、ひも付けや関連情報を変更することを必要としてることも多いのよ。
これは完全にズレてる。
705 名前：NAME IS NULL mailto:sage [2009/06/27(土) 00:52:22 ID:???]: >>703
>でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。

だから主キーにはしない方がいいんじゃないの？
むちゃくちゃだな。
706 名前：NAME IS NULL mailto:sage [2009/06/27(土) 01:59:25 ID:???]: >>703
>サロゲートキーで｢業務コードが変更されてもだいじょうぶ｣にするのも
>やり方だけど、変更を許してそれによって円滑に進めるやり方もある。

何が言いたいのかわからんw
707 名前：NAME IS NULL mailto:sage [2009/06/27(土) 04:38:44 ID:???]: >>でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。
>だから主キーにはしない方がいいんじゃないの？

別にさっきの流れの話で言うなら保険商品テーブルに保険商品コードがあって
今まで企業がA,B,C,Dの商品を持っていて、新たにE,Fと言う
商品を扱いだしたら、別にテーブルに内容追加するだけでは？

この場合保険商品コードがそのまんま主キーでも問題ない。

なんかサロゲート厨ってなんでRDBの利点を自ら否定しているノリがあるよな。
708 名前：NAME IS NULL mailto:sage [2009/06/27(土) 07:37:52 ID:???]: 議論が人工キーと意味のあるコードから構成されるキー（仮に有意キー）の選択という
のに変わってきたのかな。この話題なら興味はあるよ。

基本的に有意キーは一意性と不変性が保障できれば主キーとして使える。
構造もシンプルになる。
業務系のコードの場合はこの条件を満たすことが多い。

トランザクションや台帳系の場合は変更が多いから不変性が保てないことが多い。
一意性の確保ために枝番を付けたり、
逆に一意性のためには冗長なほど多くの意味のあるコードを含んでしまっているケースがある。
この場合は人工キーを主キーとしてその他必要な情報はタグとして別途付けるのがよい。

一意なキーが不要で存在しないレコードの場合は人工キーを付ける。
709 名前：NAME IS NULL mailto:sage [2009/06/27(土) 07:40:39 ID:???]: これはサロゲート圧勝な感じだぞ・・・アンチは意味がわからん。
頑張れアンチ！
710 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:07:30 ID:???]: RoRの意味無くなんでもid付ける主キー設定も馬鹿っぽくて嫌。ちゃんとした設計を放棄してるとしか思えない。
EJBのほうはシラネ。

サロゲート使えば解決出来るってことだと結局、設計が不味くても何とかなるってだけでうやむやになって、これまでと同様にこれからも変わらないと思うけどね。
サロゲート設定しなくても済む様なまともな設計をまず行うべきだと思う。

現場の業務で、製品コード無しで処理している以上、製品コード無しで検索出来ないのようなのは糞システムでしょ。現場の業務のヒアリングが足りない。
711 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:27:33 ID:???]: アンチからまともな意見がでてサロ厨が「あ、なるほど」となれば議論も深まるのだけど。

710が根源的に勘違いしているのだけど、「全部idを主キーにする」からって業務キーの洗い出しをしないわけではないんだよ。
ってか主キー以外では検索できないと思ってる？

> 現場の業務で、製品コード無しで処理している以上、製品コード無しで
> 検索出来ないのようなのは糞システムでしょ。
わけわからん。落ち着け。
712 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:36:27 ID:???]: >>707
>今まで企業がA,B,C,Dの商品を持っていて、新たにE,Fと言う
>商品を扱いだしたら、別にテーブルに内容追加するだけでは？

RDBの利点ってそんなとこにないよw

そして保険の例も下らなすぎ。
業務拡張や合併に合わせて既存の商品コードをA1,A0,B0,Xにします。
ときたらどうなる？
「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
業務コードの変更というのは起きるんだよ。
713 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:36:29 ID:???]: サロゲート厨ととオブジェクト厨は一応区別した方が良いと思うが、オブジェクト厨自身
それを混同しているところがやっぱり厨なんだよな。
オブジェクトモデリングの考え方では、オブジェクトは厳然と存在していて、それを
特定できるIDがあればよい。そもそもリレーショナルモデルと考え方が異なるから、
キーという概念やリレーションの正規化という考え方が存在しない。
問題は現実の問題領域との対応が正しいかどうか、例えば実際の商品は1つだけなのに
システム上のオブジェクトが2つになっていたりしないか、というところなんだけれども、
オブジェクト指向設計ではそれはデータモデルには表現されず、オブジェクトの
「ふるまい」によって保証されなければならない。
変更に強いと言っているのがおそらくこのためで、データモデルを大きく変えなくても
ふるまいを変えればいいジャン、と。プログラムよりデータの方が安定だとするところ
から出発するDOAとは逆の考え方になる。
これも最初に抽出したオブジェクトは安定だという前提なわけで、それがひっくりかえる
ような変更があったら同じことなんだけどね。
714 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:44:20 ID:???]: >>708
>基本的に有意キーは一意性と不変性が保障できれば主キーとして使える。
>構造もシンプルになる。
そして複合主キーにならなければ、でしょ？
なんだかなあ

>業務系のコードの場合はこの条件を満たすことが多い。
多くないでしょw
715 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:46:41 ID:???]: >>713
ユニークインデックスやユニーク制約ってしってる？
716 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:48:55 ID:???]: >>713
>変更に強いと言っているのがおそらくこのためで、データモデルを大きく変えなくても
>ふるまいを変えればいいジャン、と。プログラムよりデータの方が安定だとするところ
>から出発するDOAとは逆の考え方になる。

これだけなのに矛盾してるw
データモデルを大きく変えなくても振る舞いを変えればいいから、データの方が安定するんでしょ？
不安定な業務キーを主キーにしてしまえばデータが不安定になっちゃうのに.
717 名前：NAME IS NULL mailto:sage [2009/06/27(土) 09:51:57 ID:???]: といったところでお開きにする。くだらなかった。
718 名前：NAME IS NULL mailto:sage [2009/06/27(土) 10:57:46 ID:???]: なんか論理的な設計と物理的な設計を混同してないかな。
複合キーは避ける、ORMではID列が推奨、
とはいうのはDBMSやミドルウェアを使う上での要求や制限であるわけで、
本質的な設計が終わってから追加すればよい話なんだがね。
719 名前：NAME IS NULL mailto:sage [2009/06/27(土) 12:40:41 ID:???]: 主キーって実装よりの話じゃねーの？
720 名前：NAME IS NULL mailto:sage [2009/06/27(土) 12:49:54 ID:???]: アイデンティファイアの話ならともかく、キーと言ってる時点で実装寄りの話だな。
721 名前：NAME IS NULL mailto:sage [2009/06/27(土) 13:01:51 ID:???]: >>688
>人工キーの導入は正規化
なるほど
722 名前：NAME IS NULL mailto:sage [2009/06/27(土) 13:08:45 ID:???]: 主キー索引と主キー制約で違ってくるよ。前者が実装より。
723 名前：NAME IS NULL mailto:sage [2009/06/27(土) 17:16:51 ID:???]: アンチ　一人　vs　サロ厨＋その他
な構図？頑張れってアンチ！
724 名前：NAME IS NULL mailto:sage [2009/06/27(土) 17:40:56 ID:???]: >>716
「安定であるとする」というのは考えｋ他の前提であって、「安定させる」という
目的とは違うんだが。安定なコードを選択するのは分析段階の仕事であって、
仮にそれが実は安定じゃなかったといったら分析の失敗。

なぜか「業務キー」は後から変更されると決めてかかっているようだけれども、
そういう先入観に囚われていたりすると間違いやすいわけだな。逆もしかり。
というか、思い込みとしては確かに逆の方が多いと思うけど。
725 名前：NAME IS NULL mailto:sage [2009/06/27(土) 18:14:06 ID:???]: >業務拡張や合併に合わせて既存の商品コードをA1,A0,B0,Xにします。
>ときたらどうなる？

現実に起きないケースを言われてもな。
仕事したことあるの？
仮にそんな命令だす会社があるなら晒してみれば？

銀行が合併や統廃合しても旧支店名や旧支店コードが変わることはないんだが。

「既存の○○コードを■■にします」と言うのなら、新規にコード追加と
変換テーブル用意すればいいだけで、サロゲートなんて仕組みは必要ない。

>「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
>業務コードの変更というのは起きるんだよ。

単にシステム責任者が「はい」しか言わないヴァカだからじゃないのか？

システムでソレを実行したら、どれほどのリスクが発生しそれらに関する修正体力がどれほど必要か
説明すれば、いくら上がヴァカでも、システムに対する理不尽な要求を撤回してくれる。
726 名前：NAME IS NULL mailto:sage [2009/06/27(土) 18:53:23 ID:???]: ごめん、もうお開きなんだわ。くだらないし
727 名前：NAME IS NULL mailto:sage [2009/06/27(土) 18:57:42 ID:???]: おつかれ、もうこなくていいよ。
728 名前：NAME IS NULL mailto:sage [2009/06/27(土) 19:46:22 ID:???]: 結論
・主キーは自然キーでもサロゲートでも良い
・大事なコードが「可変か不変か」「一意か重複か」は主キー云々とは関係なく当然事前にキッチリつめておくべき
・「サロゲートキー使うから要件確認なんて適当でいいだろ」とはかありえない
729 名前：NAME IS NULL mailto:sage [2009/06/28(日) 00:05:44 ID:???]: ん？もうネタ切れか？
730 名前：NAME IS NULL mailto:sage [2009/06/28(日) 01:00:16 ID:???]: >>725
「製品コード　変更」でググってみなよ

>>703ではこんなふうに言ってるのにね
>でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。
>「業務コードが変わったり｣する事は織り込み済み。定期的なコード洗い替え処理やるしね。
>業務コードを変えて、ひも付けや関連情報を変更することを必要としてることも多いのよ。
731 名前：NAME IS NULL mailto:sage [2009/06/28(日) 03:00:02 ID:???]: 変更されないなんて言われて真に受けて主コードにしちゃって後で困るのが、そもそもの設計ミスなんじゃないの？
そんな設計ミスで後から改修費用取るのは詐欺。金貰って喰ってるプロなら最初からちゃんと設計ぐらいしないと。

急にボールが来たとかいい訳して仕事しなかったサッカーの素人並。
732 名前：NAME IS NULL mailto:sage [2009/06/28(日) 03:48:57 ID:???]: >>731
>>728
733 名前：NAME IS NULL mailto:sage [2009/06/28(日) 03:58:51 ID:???]: また「サロゲートキーがにしたから要件は適当に聞いておけば大丈夫」厨か。
そこをちゃんと確認しとかなきゃ仮にDBが無事でもプロジェクトはボロボロだっての。
734 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:13:17 ID:???]: 「製品コードは将来的に変更されませんか？」
とユーザーに尋ねたら、
「将来、変更がかかっても最小の修正ですむような設計にしてください。」
という返事が返ってくるんじゃないの？
「将来にわたって変更はありません」
とは言わないだろ。
735 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:19:06 ID:???]: キッチリと確認した結果「変更されるケースあり」と確定したんならそれでいいだろ。
曖昧なまま「どっちでもいいよ。なんせサロゲートキーを使ってるからな」がありえないって話だ。
736 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:23:20 ID:???]: >>735
それはOKなんだｗ
よくわかんねーやつだなｗｗｗ
737 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:27:36 ID:???]: >>736
いや何もおかしくないだろ。
「サロゲートキーか否か」がプロジェクトより大事な人にはわからんだろうけど。
別にこっちは「サロゲートキーを使わない」事に命をかけてるわけでもないんで。
738 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:39:49 ID:???]: またわけのわからないことを言い出したぞｗ
739 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:43:43 ID:???]: 反論できなくなって逃げ回り始めたか。
そうやってワザと馬鹿のフリをしてスレを盛り上げようとしてくれてるんだろ？
わかってる、愛してるよ。
740 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:44:22 ID:???]: >>735
>曖昧なまま「どっちでもいいよ。なんせサロゲートキーを使ってるからな」がありえないって話だ。

林:　まさかとは思いますが、この「どっちでもいいよ。なんせサロゲートキーを使ってるからな厨」とは、あなたの想像上の存在にすぎないのでは
ないでしょうか。もしそうだとすれば、あなた自身が統合失調症であることに
ほぼ間違いないと思います。
741 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:46:41 ID:???]: こっちは要件を確定しろ、と言ってるのに
それに対する反論が「サロゲートキーを使え」だからな。

そんなレッテル貼りやったりネタで逃げたりしなきゃならないんだろ。
742 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:51:37 ID:???]: こっちは要件を確定した上で人工キーを使え、と言ってるのに
それに対する反論が「要件を確定しろ」だからな
743 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:54:11 ID:???]: そんな反論はしてないが。
必要だと確定して使うんなら問題ないだろ、と言ったはずだが。

そんなウソをついてまで「まだ反論できてるフリ」しなくていいよ。
744 名前：NAME IS NULL mailto:sage [2009/06/28(日) 04:56:58 ID:???]: おはよ～、まだやってたのか。
人工キーを活用するという話とサロゲートキーの話が混ざってないかい？

製品コードは有意キー（人間から見て意味のあるキー）にしたいというニーズは強いんだが、
製造と販売で盛り込みたい情報が違ってたり、世代の管理をしたいとかいろいろあるんで、
主キーは人工キーにしてバーコード化している。
と同時に製造タグコードと販売タグコードを別にふって印刷している。
タグコードは両方ともユニークではない意味のあるコード。
ひとつの考え方でいかなる場合もそうであるわけではないのだが、
枝番をふって主キーにするよりも人工キーを活用したほうがよい場合もある。
745 名前：NAME IS NULL mailto:sage [2009/06/28(日) 05:05:18 ID:???]: >>744
そんな感じだと思うよ。

絡んでくる変なのがいるからかまってるだけで。

しかしみんな朝早いなw
746 名前：NAME IS NULL mailto:sage [2009/06/28(日) 05:06:59 ID:???]: >>745
おいおい>>744は「要件を確定させ、必要だとわかった上で」「人工キーを活用した方が良い場合もある」という話だぞ。
君が全否定されてんの。
747 名前：NAME IS NULL mailto:sage [2009/06/28(日) 05:07:49 ID:???]: つか>>743は見なかったことですかｗ
748 名前：NAME IS NULL mailto:sage [2009/06/28(日) 05:17:00 ID:???]: アンチの挙げる例がアレなんだよな
A＋連番１０桁とかそんなんだもんな
749 名前：NAME IS NULL mailto:sage [2009/06/28(日) 05:18:03 ID:???]: >>725
>銀行が合併や統廃合しても旧支店名や旧支店コードが変わることはないんだが。

合併するなら重複が発生するだろう
www.bk.mufg.jp/oshirase/tenban/furiwake.html
www.resona-gr.co.jp/group/group_0101.htm

ちなみに「製品コード　変更」で検索
https://ruo.mbl.co.jp/news/information/number_change-1.html
www.platonjapan.co.jp/pdf_platon/code.pdf

>>「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
>>業務コードの変更というのは起きるんだよ。
> 単にシステム責任者が「はい」しか言わないヴァカだからじゃないのか？
「業界でコード体系を統一しよう」という大きな動きを、システム責任者ごときが「NO」と言えるか？
「システムで主キーにしちゃってるんで」って。
750 名前：NAME IS NULL mailto:sage [2009/06/28(日) 05:55:33 ID:???]: 不変で一意で単一の自然キーか。。。
751 名前：NAME IS NULL mailto:sage [2009/06/28(日) 06:47:08 ID:???]: サロ厨もアンチも一部の馬鹿が極端な例とか使って変な方向に持って行ってる気がする。
アンチの方が変なの多い気もする。
752 名前：NAME IS NULL mailto:sage [2009/06/28(日) 09:34:28 ID:???]: 製品コードで検索出来なくて文句言われた。
サロゲート使えばおk
そもそもサロゲート使う設計が糞。
サロゲート使わない事に命掛けてる訳ではない。　＜今ここ
要件確定してるのでサロゲートなんて使ってませんが？
じゃあサロゲート要らないね。
終了。

銀行の支店コードが統廃合で実際変わってたね。まだ現金で給料貰ってる香具師なんだろうか。
753 名前：NAME IS NULL mailto:sage [2009/06/28(日) 10:53:09 ID:???]: なんでもいいが、お前ら名乗ってやってくれ
だれがどんな主張かわからんぞ
754 名前：NAME IS NULL mailto:sage [2009/06/28(日) 12:15:50 ID:???]: アンチは何人？ひとり？
755 名前：NAME IS NULL mailto:sage [2009/06/28(日) 15:41:31 ID:???]: アンチってのはいないだろ。
「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで
756 名前：703 [2009/06/28(日) 16:00:10 ID:3qHYmqKK]: もしかして私、アンチサロゲにされてる？

発生する企業コードの変更に、意味ある対応ができるならならサロゲートキー使えばいいと思いますよ。
だけど単純に｢変更が発生するから云々｣でサロゲートキー使う反射神経野郎はどうかしてる。と思ってる。
＃サロゲートキーを否定してる訳じゃないので。

企業コードなんてのはガンガン変わるもの。その変化するコードに後生大事に不変のキーをくっつけて持ちまわすことに意味があるのか？
洗い替え作業って、単にコードを直すだけじゃない。組織構造の変更や移管・移行に伴う関連性の張替え組換えだってやる。場合によっちゃ元の構造を壊して作り変える。
企業コードの他に、使いもしないような別キーについても面倒見なくちゃならないのは正直ろくでもない手間としか映らない。
もちろん、ろくでもない手間ではない、ちゃんとメリットの見える設計なら歓迎。

「～な理由で不変なキーが必要です｣とか言った企業活動に必要な、明確な理由があってのサロゲートキーやら何とかキーなら理解できる。
ただ｢将来の保険｣的なものや「コードが変わっても元の構造を維持できる｣とか、でしかないなら余計な工数が必要なお粗末設計なだけ。
757 名前：NAME IS NULL mailto:sage [2009/06/28(日) 16:08:43 ID:???]: 素朴な疑問
サロゲートキーをつける事で発生する「余計な工数」ってなんだ？
758 名前：NAME IS NULL mailto:sage [2009/06/28(日) 16:10:50 ID:???]: 付けただけじゃ大した工数じゃなくても
「キーが変わる・重複する」事を考慮して全体を作ると結構な工数。
そこは要件をきちんと詰めて「これだけかかりますが両対応にしますか」と合意を取らなければならない。
759 名前：NAME IS NULL mailto:sage [2009/06/28(日) 16:45:23 ID:???]: >>755
>「必要かどうかを判断すべき派（中立派）」
自分ではそう思ってるんだな。
すまんが、傍観者から言わせて貰うとまったくそうは見えないぞ。

>>756
君はアンチサロゲっつーか日本語でおｋっつーか・・・
760 名前：NAME IS NULL mailto:sage [2009/06/28(日) 16:50:24 ID:???]: 傍観者ｗ
761 名前：NAME IS NULL mailto:sage [2009/06/28(日) 16:51:59 ID:???]: 反論できなくなると
・話をそらす
・見えない敵と戦い始める
・バレバレのウソをつく
・自演を始める

もう飽きたよサロ厨
762 名前：NAME IS NULL mailto:sage [2009/06/28(日) 16:53:16 ID:???]: 「状況を判断して使うかどうか決めるべき」が中立でないとすると
「何が何でもサロゲートキーを使うべき」に同意しない人は全てアンチか。
怖いなｗ
763 名前：NAME IS NULL mailto:sage [2009/06/28(日) 17:28:11 ID:???]: サロゲート厨とはどんな人物か。

>>735->>736のやりとりを見れば
「何が何でもサロゲートキーを否定するアンチ」を脳内で作り出して
それと戦っているつもりになってるのは明白だろう。

相手が中立であってはならない。
764 名前：NAME IS NULL mailto:sage [2009/06/28(日) 17:48:38 ID:???]: 確かにサロ厨がかなり必死なスレですな。

反論っぽいのも的外れだしなぁ。
必死にググった結果もアレだったし。

中二病とおなじく「サロゲート」といいたいだけと違うのか？って希ガス。
765 名前：NAME IS NULL mailto:sage [2009/06/28(日) 18:13:58 ID:???]: >合併するなら重複が発生するだろう
>www.bk.mufg.jp/oshirase/tenban/furiwake.html

漏れ、ここの銀行の２世代前（倒壊銀行）の古い合併前の通帳やキャッシュカード使っても問題ないよ。

つかサロゲートの人ってシステム設計した事無いんじゃね？

とりあえず、漏れはちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
サロゲートキーとか使わずに実装している。合併したらそれは新しい銀行なので、旧銀行とは区別されている。

>「業界でコード体系を統一しよう」という大きな動きを、システム責任者ごときが「NO」と言えるか？

全銀の世界ではすでにコードが統一されているよ。銀行のシステム担当者はこれに合わせるだけ。
と言うかあわせないといけない。

基本的に旧コードをないがしろにしていない。古い手形・小切手を持っている人が泣くだろ。

手形には主キーと言う概念がないので例えとしてはアレだが。

とりあえず、そんなに自説に自信があるならMUFGにいって「オレに設計させれ」と言って来い。

サロゲートの人は本気で病気だと思うからここで現実逃避してないで、
マジで精神カウンセリングを受けたほうがいいと思うよ。
766 名前：NAME IS NULL mailto:sage [2009/06/28(日) 18:52:47 ID:???]: >>765
そりゃあできるだろう。
できるかできないかではなくて、改修にかかわるコストの論議をしているんだと思うんだが。

ちがうか？
767 名前：NAME IS NULL mailto:sage [2009/06/28(日) 19:07:04 ID:???]: 新しい展開がｗｗｗ

製品コードで検索出来なくて文句言われた。
サロゲート使えばおk
そもそもサロゲート使う設計が糞。
サロゲート使わない事に命掛けてる訳ではない。
サロゲート使えば改修費用が安く出来る。　＜今ここ
要件確定してるので実はサロゲートなんて使ってませんが？
じゃあサロゲート要らないね。
終了。

コストなんて末端のPGを低賃金で雇うなり、サビ残では足らせればいくらでも圧縮可能と、予算管理者や経営者は考えてる罠。
予算はサロゲートで決まるんじゃない。エクセルの上で決められている。
768 名前：NAME IS NULL mailto:sage [2009/06/28(日) 19:21:03 ID:???]: 文章ヘタクソだなあ。
君の書いた要件定義書をぜひ見てみたい。
769 名前：NAME IS NULL mailto:sage [2009/06/28(日) 19:22:50 ID:???]: >>767
>　コストなんて末端のPGを低賃金で雇うなり、サビ残では足らせればいくらでも圧縮可能
あはーん、だからよくダウンするんだ。MUFGのコンピューターシステムは。
770 名前：NAME IS NULL mailto:sage [2009/06/28(日) 19:30:38 ID:???]: >>767とサロ厨で別スレつくって出て行ってくれればスッキリする。
サロ厨が何の反論も出来なくなったところに、わざわざエサをまきに来るなよ
771 名前：NAME IS NULL mailto:sage [2009/06/28(日) 19:57:15 ID:???]: いや、隔離スレがここだから。
772 名前：NAME IS NULL mailto:sage [2009/06/28(日) 20:25:10 ID:???]: 本スレどこだよ。本スレはサロゲート廚来ないのか？
773 名前：NAME IS NULL mailto:sage [2009/06/28(日) 20:26:18 ID:???]: >とりあえず、漏れはちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
>サロゲートキーとか使わずに実装している。合併したらそれは新しい銀行なので、旧銀行とは区別されている。

実際の口座テーブルの主キーは何なのでしょうか。
774 名前：NAME IS NULL mailto:sage [2009/06/28(日) 22:52:35 ID:???]: >>755
>アンチってのはいないだろ。
>「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで

何が何でも使え派ってどれ？
あなたが総合失調症の人ですか？
775 名前：NAME IS NULL mailto:sage [2009/06/28(日) 23:00:02 ID:???]: >>774
ん？君も「状況を判断して使うかどうか決めるべき」って考え？
776 名前：NAME IS NULL mailto:sage [2009/06/28(日) 23:35:45 ID:???]: よせ、病気がうつるぞｗ
777 名前：NAME IS NULL mailto:sage [2009/06/28(日) 23:52:57 ID:???]: >>767
>製品コードで検索出来なくて文句言われた。
>サロゲート使えばおk
>そもそもサロゲート使う設計が糞。
>サロゲート使わない事に命掛けてる訳ではない。
>サロゲート使えば改修費用が安く出来る。　＜今ここ
>要件確定してるので実はサロゲートなんて使ってませんが？
>じゃあサロゲート要らないね。
>終了。

これがまるっきり意味分からんのだが。
誰か解読してください
778 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:01:46 ID:???]: >>765
本当にアレだな。

>ここの銀行の２世代前（倒壊銀行）の古い合併前の通帳やキャッシュカード使っても問題ないよ。
問題ないように苦労してシステム作るだろ、普通。
その時に自然キーよりも人工キー使ってたシステムの方が対応しやすいんじゃないかなって。

>ちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
「過去のコードをなかったことにする」なんて誰か主張したかい？

>全銀の世界ではすでにコードが統一されているよ。銀行のシステム担当者はこれに合わせるだけ。
>と言うかあわせないといけない。
もっと一般的な話をしたつもりなんだが。
779 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:04:55 ID:???]: 必至に話をそらし中ｗ
780 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:05:15 ID:???]: どのポジションの奴も自分は頭がいいと主張しているだけだなｗ
781 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:12:01 ID:???]: >>765
>漏れはちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
当たり前だバカ。そんな話してるんじゃないよ。

どうかこの人と仕事で関わりませんように
782 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:20:24 ID:???]: >>756
>企業コードなんてのはガンガン変わるもの。その変化するコードに後生大事に不変のキーをくっつけて持ちまわすことに意味があるのか？
過去との紐付け
783 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:26:31 ID:???]: サロ厨って反論できなくなったら唐突に遡って反論可能な書き込みに対してレス始めるのなｗ
784 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:32:19 ID:???]: 中立派の人に質問。
第一正規化、繰り返し項目の排除についてどう思う？
「必要かどうかを判断すべき」だったりする？
785 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:40:13 ID:???]: また露骨に話をそらして
完全に反論できなくなったのを「無かったこと」にしに来たなｗ
786 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:44:50 ID:???]: 思い出した。この前のとおんなじ奴だろ。文末ｗは
787 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:49:09 ID:???]: またそういう部分で争ってうやむやにしようとするｗ
788 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:53:28 ID:???]: >>787
専スレ立てようか？
正直、サロゲネタはお腹いっぱい。
789 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:56:29 ID:???]: >>733
>>737
>>739
>>741
>>744
>>761
>>770
>>776
>>779
>>783
>>785
>>787
790 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:56:56 ID:???]: >>785
>完全に反論できなくなった
は？
791 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:57:49 ID:???]: >>788
>正直、サロゲネタはお腹いっぱい。
同意
専用スレもいらんよ
792 名前：NAME IS NULL mailto:sage [2009/06/29(月) 00:57:55 ID:???]: あ、ごめ>>744じゃなく>>743
793 名前：NAME IS NULL mailto:sage [2009/06/29(月) 23:41:48 ID:???]: 結局サロゲート設定する必要無いだろ。
794 名前：NAME IS NULL mailto:sage [2009/06/29(月) 23:56:15 ID:???]: いやもうそこに触れないで
795 名前：NAME IS NULL [2009/06/30(火) 00:17:18 ID:cjciCkCN]: これだけ理屈の通じない人間がDB設計に関わってるんだものな
796 名前：NAME IS NULL mailto:sage [2009/06/30(火) 00:19:30 ID:???]: いや別に君を擁護してるわけでも無いから
797 名前：NAME IS NULL mailto:sage [2009/06/30(火) 01:20:43 ID:???]: 偏向性サロゲート厨
798 名前：NAME IS NULL mailto:sage [2009/06/30(火) 02:11:46 ID:???]: >>793
>>795
>>797
799 名前：NAME IS NULL mailto:sage [2009/06/30(火) 06:30:50 ID:???]: 結局は自称中立野郎が脳内敵を勝手に作り出して暴れていたってことでｗ
800 名前：NAME IS NULL mailto:sage [2009/06/30(火) 12:54:48 ID:???]: はい、そろそろまとめて。
サロゲートキーのメリット、デメリットと
どんな時に使うと良くて、どんな時は良くないのか。
801 名前：NAME IS NULL mailto:sage [2009/06/30(火) 13:50:35 ID:???]: 電話を使った会員サービス、世帯単位なので電話番号をそのままユーザー番号として使っている。
こういう業務を想定した上で、これをシステム化する。
A) 電話番号を主キーとして使用。
B) ユニークな連番（ID）を発行し、主キーとするが電話番号も候補キーである。
　　ユーザーは主に電話番号を使う。IDは管理番号としてバーコードなどに使用する。
C) ユニークな連番（ID）を発行しユーザーに通知、これを主キーとする。
　　電話番号は問い合わせに使用できるが基本的に一属性である。
D) ユニークな連番（ID）を付加するがユーザーには非通知。システムの内部だけで使用する。
　　電話番号は候補キー

Aは自然キー、Dはサロゲートキーで間違いないと思うが、BとCは解釈が分かれると思う。
ABCが自然キーでDが人工キー＝サロゲートキーが正しいらしいが、
Aが自然キー、BCDがサロゲートキーでないが人工キー、
Dがサロゲートキーというのが一般的だと思うけどどうだろう。
BCDがサロゲートキーと解釈してる人もいそうだけど、
この辺の意識あわせはしないとややこしくなりそうだ。
802 名前：NAME IS NULL mailto:sage [2009/06/30(火) 13:52:28 ID:???]: 一箇所訂正。
＞Aが自然キー、BCDがサロゲートキーでないが人工キー、
Aが自然キー、BCがサロゲートキーでないが人工キー、

私的にはABCが自然キー、Aは特に有意キーと呼んでる。
803 名前：NAME IS NULL mailto:sage [2009/06/30(火) 14:52:20 ID:???]: 電話番号は変更される事も有るから、契約番号を設定してユーザ番号として利用すればサロゲートは不要。

そもそもユーザ番号を一意にすれば良いじゃないか。やっぱり設計が大事。
サロゲート廚はまともな設計が出来ないだけじゃ。
804 名前：NAME IS NULL mailto:sage [2009/06/30(火) 14:58:37 ID:???]: その一意になるユーザ番号って人工キーじゃんw
805 名前：NAME IS NULL mailto:sage [2009/06/30(火) 15:00:59 ID:???]: ほんとその意味で言えば「サロゲート派」なんて一人も居ないのに
なにを騒いでるんだか。
806 名前：NAME IS NULL mailto:sage [2009/06/30(火) 15:04:09 ID:???]: >>803
「うちの業務は電話番号で検索できればいいから、変な契約番号なんてつくりたくないんですけど。弊社の業務分析はちゃんとできてます？」
「電話番号は変更されることもある？そんな事わかってますよ。とにかく電話番号で検索できることが重要なんです！」
807 名前：NAME IS NULL mailto:sage [2009/06/30(火) 15:09:09 ID:???]: そのケースだったらBパターンだな。
つうかBもサロゲートということにしないとサロゲート派の立つ瀬がないな（笑
808 名前：NAME IS NULL mailto:sage [2009/06/30(火) 15:16:35 ID:???]: 傍観してた初心者ですが、A以外はサロゲートなのかと思ってました。
809 名前：NAME IS NULL mailto:sage [2009/06/30(火) 15:19:14 ID:???]: 脳内で勝手に作った「サロゲート派」と戦ってたのか。
なるほどかみ合わないわけだ。
810 名前：NAME IS NULL mailto:sage [2009/06/30(火) 16:08:07 ID:???]: >>807
>つうかBもサロゲートということにしないと
普通にサロゲートキーじゃん
811 名前：808 mailto:sage [2009/06/30(火) 17:40:06 ID:???]: ？？誰がホントなんですか？
812 名前：NAME IS NULL mailto:sage [2009/06/30(火) 17:45:16 ID:???]: 初学者は自分で勉強しろ
813 名前：NAME IS NULL mailto:sage [2009/06/30(火) 18:24:30 ID:???]: おまえらは仕事しろ
814 名前：NAME IS NULL mailto:sage [2009/06/30(火) 20:40:18 ID:???]: >>801
サロゲートだなんだ言う前に、

>世帯単位なので電話番号をそのままユーザー番号として使っている。

これが適切なのかどうかはっきりさせてから設計に入るべきだね。
で、一旦これが適切だ=世帯と電話番号の関係性に変更はない、という
判断がされたのだったら、それ以降電話番号の変更の可能性を考える
必要はないわけだし。
815 名前：NAME IS NULL mailto:sage [2009/06/30(火) 22:16:46 ID:???]: >>814

> 電話を使った会員サービス、世帯単位なので電話番号をそのままユーザー番号として使っている。
> こういう業務を想定した上で、これをシステム化する。

はっきり｢想定した上で、これをシステム化する｣と書いてますから、ここでは既に｢はっきりさせて｣あると思うのですが...まだ足りないと言うことでしょうか？
816 名前：NAME IS NULL mailto:sage [2009/06/30(火) 22:55:12 ID:???]: それが適切でない合理的疑いがあるのなら、質しておくべきだね。
業務ルールとかも詳しく見てみると、人が判断してるからなんとか
回っているけどシステム的には全然つながらない、なんてのが
あったりするしね。
817 名前：NAME IS NULL mailto:sage [2009/06/30(火) 22:55:46 ID:???]: 俺はA以外はサロゲート扱いだなぁ。
んで、実装はB～Dのどれかに落ち着きそう。
電話番号が変わったときに過去履歴を見るのに別にキーがあると便利そう。
もちろん顧客に電話番号以外にキーを持たせることによるメリット等を説明した上でね。

ちなみにアンチサロゲの人から言わせると俺はサロゲ厨ｗ
818 名前：NAME IS NULL mailto:sage [2009/06/30(火) 23:00:52 ID:???]: サロゲ厨はこれに回答してから中立ぶってくれ

774 名前：NAME IS NULL[sage] 投稿日：2009/06/28(日) 22:52:35 ID:???
>>755
>アンチってのはいないだろ。
>「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで

何が何でも使え派ってどれ？
あなたが総合失調症の人ですか？

775 名前：NAME IS NULL[sage] 投稿日：2009/06/28(日) 23:00:02 ID:???
>>774
ん？君も「状況を判断して使うかどうか決めるべき」って考え？
819 名前：NAME IS NULL mailto:sage [2009/06/30(火) 23:05:02 ID:???]: >>818
？？？
820 名前：NAME IS NULL mailto:sage [2009/06/30(火) 23:06:37 ID:???]: そもそも電話番号は変わると確定している物。
それを前提に話すのがおかしい
821 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:11:48 ID:???]: >>818
今日も来たんですか。ご苦労様です。
822 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:14:48 ID:???]: >>821
君の「都合が悪いレスは見えないフリ」を隠そうともしない姿勢は凄いね。
823 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:22:25 ID:???]: >>818
おれは何が何でも使え派と言ってもいいかもな。
「何が何でも」というのは語弊があるが。

自然キーを主キーにしてOKといえるケースの少なさ。
人工キー導入コストと主キーの変更コストの比較
設計ルールの単純化のメリット

これらをしっかり理解できれば、作業としては人工キー一択で良いと思う。
824 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:23:11 ID:???]: >>822
もういいじゃん。
そいつマジ病気なんだから。
825 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:25:06 ID:???]: >>818
だからさ、専スレ立てるかって言ってんだろうがよ。
単なる煽りか？もっと賑やかなところでやれよ。
826 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:26:15 ID:???]: ぐだぐだ言ってないでさっさと立てろよ
827 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:27:39 ID:???]: 他に話題もないしいいんじゃね？

これか、「リレーションはテーブルのことだよ論争」しか話題がないじゃんw
828 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:33:31 ID:???]: まだやってたのかおまいらｗｗｗ
829 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:36:13 ID:???]: その話題になるとあの人がいついちゃうのがね…
スレが止まってもいいからその話題以外にしましょう。
830 名前：NAME IS NULL mailto:sage [2009/07/01(水) 00:43:32 ID:???]: もともと数日レス無しとかが普通なスレだしな。
レスがあるだけ今のほうがいいか、と聞かれると明らかにNo
831 名前：NAME IS NULL mailto:sage [2009/07/01(水) 05:27:29 ID:???]: なんかすっかり話題を変えられてるが、
製品番号で検索出来ないのは設計が悪いぞ。
832 名前：NAME IS NULL mailto:sage [2009/07/01(水) 05:40:06 ID:???]: 常識的に考えて
それはDB設計が悪いんじゃなくてアプリの設計が悪いんだろが

製品番号で検索したらパフォーマンスが出ないってなら別だが
833 名前：NAME IS NULL mailto:sage [2009/07/01(水) 07:44:06 ID:???]: >>801はここでのサロゲートキーの定義が曖昧だからはっきりしろ言ってるわけで
話題を変えるつもりはなかったのだと思うけど、
今を思えば>>685　が慧眼だったな。
で、製品番号のテーマではA対BCDということで行くの？
834 名前：NAME IS NULL mailto:sage [2009/07/01(水) 09:31:17 ID:???]: >>831
>製品番号で検索出来ないのは設計が悪いぞ。

これがずっと気になってたんだが
>>607の「製品コードが無い分の納品書は製品コードで検索できない」
を曲解してるのか...。
なんという読解力（どっかいりょく）のなさ。
主キー（しゅきー）がどうのこうの言（い）う遥（はる）か以前（いぜん）の段階（だんかい）ですね
835 名前：NAME IS NULL mailto:sage [2009/07/01(水) 10:19:27 ID:???]: ユーザが製品コードを付けないで入力するのを要件に盛り込んでなかっただけだろ。
設計ミスだな。
836 名前：NAME IS NULL mailto:sage [2009/07/01(水) 11:29:11 ID:???]: 後出し要件をどこまで避けられるかどうかだな。
キックオフまでにつぎ込めるリソースも限られた中で、全て洗い出すなんてのは前時代的な根性論か理想論か。
「全て盛り込め」という無責任な号令のもと、巨大な体を持て余して潰れていった数々のプロジェクトの屍を乗り越えて、銀の弾丸ではないものの、よりよい手法を模索していかなければならない。
837 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:07:28 ID:???]: 製品コードで複数ヒットするならいったん候補画面に飛ばさなきゃならない。
製品コードが変わるかどうかでマスタメンテ画面だって変わるし
マスタに紐づく諸テーブルは製品コードを表示するために（製品コードをキーとしないなら）親からとって来なければならない。
プロジェクト全体に関わる問題。

結局のところ、「製品コードは不変としてつくるか可変としてつくるか」の合意を得なきゃ前に進めない。
「変わるかもしれないからサロゲートキーにしました」は何の解決にもなっていない。
客に何を聞いても「全ての可能性を考慮してつくってください」しか言われずそれを受け入れ、
>>836が言うような対応をするのでなければね。
838 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:14:33 ID:???]: えーと…
制約というものを知らないのかな？
マスタメンテ画面で何の項目を保守可能にするのかってのは別問題だし
通常、リソース系のテーブルは名称やら金額やらを取得するためにリンクするものだし
なにがネックで騒いでるのかよくわからん
839 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:16:48 ID:???]: >>837
>結局のところ、「製品コードは不変としてつくるか可変としてつくるか」の合意を得なきゃ前に進めない。
これはまさにその通り。しかしその合意というのがどこまで有効か。
どうにもならない政治的なこともよくあるからな。
本当に合意を出来るなら「人工キーは無駄」というのに賛同できないわけではない。

あと、親から取ってこなくても製品コードが表示できる、というのは非正規化に過ぎない。
840 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:19:15 ID:???]: >>838
勝手に条件を限定して「何の問題も無し」てのは君の悪い癖だよ。
841 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:20:43 ID:???]: いや、なんとなく
こいつ要件定義やったことねーな
的な匂いがしてねｗ
842 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:22:44 ID:???]: また例によって露骨な逃げに入ったなｗ
843 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:26:22 ID:???]: そもそも業務でいちいち製品コード決めたりしないだろ。
何か適当に作って、後から製品名とコード付けるのが普通。
単に現場知らずに設計してるだけ。現場知らないのに現場のシステム設計出来る訳が無い。

サロゲート付ければ良いってのは、現場知らなくても何とかなるって良い訳。
844 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:33:44 ID:???]: >>843
>そもそも業務でいちいち製品コード決めたりしないだろ。
え？

>何か適当に作って、後から製品名とコード付けるのが普通。
じゃあDBの主キーは全部人工キーでいいじゃんw
845 名前：NAME IS NULL mailto:sage [2009/07/01(水) 14:37:01 ID:???]: 業務知らなくても云々とかいうミスリードはもうやめようぜ。
サロゲートをどうするか以前に、DB設計は業務を知らなきゃできっこないんだから。
846 名前：NAME IS NULL mailto:sage [2009/07/01(水) 18:53:22 ID:???]: >>801

サロゲートキーは、少なくともあるキーを代替していないとサロゲートキーと言えない。

Aは、電話番号が主キーということだけなので、何かを代替(サロゲート)するということは当然出てこない。

Bは、電話番号(候補キー)の代替(サロゲート)としてのユニークな連番(ID)をつける、と言えるから、
ユニークな連番(ID)はサロゲートキーと言える。ユーザーが使うとか管理番号に使うとかは関係ない。

Cは、電話番号はキーではないので、ユニークな連番(ID)が電話番号を代替しているとは言えないので、
ユニークな連番(ID)はサロゲートキーと言えない。

Dは、電話番号(候補キー)の代替(サロゲート)としてのユニークな連番(ID)をつける、と言えるから、
ユニークな連番(ID)はサロゲートキーと言える。(BとDは同じこと)

しかし、サロゲートキーが、必ずユニークな連番(ID)という人工キー
でなくてはならないかというと、そこまではサロゲートキーという意味に含まれていない。

こんなんで、どう。
847 名前：NAME IS NULL mailto:sage [2009/07/01(水) 19:06:24 ID:???]: 代替キーと代理キーが混ざってない？
848 名前：NAME IS NULL mailto:sage [2009/07/01(水) 19:57:29 ID:???]: 代替キーと代理キーの定義を教えてくれ
849 名前：NAME IS NULL mailto:sage [2009/07/01(水) 21:13:25 ID:???]: >>838
そういうのを本当に汎用的にやろうとすると結局、市販の「いわゆる『アプリケーション』」と
変わらないものになっちゃうんだよな。
普通の設計の感覚で見るとゲロ吐きそうな代物だ。
850 名前：NAME IS NULL mailto:sage [2009/07/01(水) 21:29:50 ID:???]: >>849
汎用的なんて後付け条件つけて勝手に批判した気になってんじゃねーよｗｗ
851 名前：NAME IS NULL mailto:sage [2009/07/01(水) 21:41:31 ID:???]: >>850
なんでオマエが批判された気になってんだw
SAPの中の人とかかい？
852 名前：NAME IS NULL mailto:sage [2009/07/01(水) 22:00:58 ID:???]: ググレ、カス
853 名前：NAME IS NULL mailto:sage [2009/07/01(水) 22:02:12 ID:???]: >>851
気づいてないのかもしれないが、君1人対全員だよ？ｗ
854 名前：NAME IS NULL mailto:sage [2009/07/01(水) 22:03:54 ID:???]: >>853
君何度もいわれてるけどホントに病気だから
855 名前：NAME IS NULL mailto:sage [2009/07/01(水) 22:10:07 ID:???]: サロゲ厨は要件定義しない厨攻撃のつぎは
SAPまで持ち出して、サロゲ厨は汎用厨攻撃ですかぁ。
大変ですねぇ。
856 名前：NAME IS NULL mailto:sage [2009/07/02(木) 00:40:37 ID:???]: サロゲ廚の言い訳が見苦しいスレだな。
857 名前：NAME IS NULL mailto:sage [2009/07/02(木) 00:50:44 ID:???]: >>848
代替キー（サロゲートキー）は主キーたる自然キーが存在しない、あるいは複合キーとなって扱いにくい場合に、別途人工的に作成するキー

代理キーは一意になる候補キーの内、主キーに選ばれなかったもの
ただし、サロゲートキーのことを代理キーと呼ぶこともある
858 名前：NAME IS NULL mailto:sage [2009/07/02(木) 01:04:01 ID:???]: 自分が都合の悪いレスを無視して逃げ回っておいて何を言うんだ？
859 名前：NAME IS NULL mailto:sage [2009/07/02(木) 06:24:43 ID:???]: アンチサロゲ廚の勝利に終わったのか？
860 名前：NAME IS NULL mailto:sage [2009/07/02(木) 06:33:08 ID:???]: どこを読んだらそういう結論になるんだろう。
本当におかしい人なのかな。
861 名前：NAME IS NULL mailto:sage [2009/07/02(木) 09:12:30 ID:???]: >>859
あんたの一人勝ちだよ
862 名前：NAME IS NULL mailto:sage [2009/07/02(木) 13:37:04 ID:???]: 廚って書く人は同一人物なのか
863 名前：NAME IS NULL mailto:sage [2009/07/02(木) 13:49:08 ID:???]: 女のようだな
864 名前：カウンセラー mailto:sage [2009/07/02(木) 13:50:51 ID:???]: >>862-863
続けてください
865 名前：NAME IS NULL mailto:sage [2009/07/02(木) 14:15:19 ID:???]: 漏れさん
866 名前：NAME IS NULL [2009/07/02(木) 16:05:31 ID:8NCxXA01]: くだらないこと聞きますが
例えば
・お店が一つの業種を選択できる
・一つ業種は色々なお店に選択される
このような時
お店：業種
は
一対多
というのか
多対一
どちらなのでしょうか？
867 名前：NAME IS NULL mailto:sage [2009/07/02(木) 16:10:49 ID:???]: 業種1つに対してたくさんのお店が紐付くわけだから
業種１：お店多
868 名前：NAME IS NULL mailto:sage [2009/07/02(木) 23:22:10 ID:???]: >>866
なごんだ
869 名前：NAME IS NULL mailto:sage [2009/07/02(木) 23:26:58 ID:???]: >>866　
「お店が一つの業種のみ選択できる」ならば多（店）対一（業種）
870 名前：NAME IS NULL mailto:sage [2009/07/03(金) 01:13:00 ID:???]: 普通はいろいろ遣ってるよね。販売もサービスも。
871 名前：NAME IS NULL mailto:sage [2009/07/03(金) 07:43:59 ID:???]: a. 運送業の会社が、陸運業・海運業を手がけている事
b. デパートが、無料梱包サービスと配送サービスを行う事
c. スーパーが、食料品と雑貨を販売している事

質問の「業種」が a の意ではなくて b や c のような意？
a だとすると、お店というよりは会社なのかな。

＃｢お店｣と「複数業種｣がなんかうまく釣り合いが取れなかっただけ
872 名前：NAME IS NULL mailto:sage [2009/07/03(金) 08:02:17 ID:???]: >>871
何を言っているんだ？
873 名前：866 mailto:sage [2009/07/03(金) 11:02:35 ID:???]: >>867　869
ありがとうございます。
ですよね。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef