DB設計を語るスレ２

1 ：NAME IS NULL：2008/10/08(水) 18:34:13 ID:PQV+Wmyc

引き続き語れ！！

前スレ
DB設計を語るスレ
http://pc11.2ch.net/test/read.cgi/db/1166540159/

2 ：NAME IS NULL：2008/10/08(水) 18:39:40 ID:???

ふむ

3 ：NAME IS NULL：2008/10/08(水) 18:41:25 ID:???

早速質問なのですが、
日付を「昭和60年2月3日」のように和暦で扱うアプリの場合、カラム型は
普通に日付型を使った方がいいでしょうか？

アプリは.NETで作っていて、
元号をコンボボックス、年月日をテキストボックスで選ばせるUIなので、
元号、年、月、日を別カラムで保持すれば楽かなーと思うのですが。
どうでしょう？

4 ：NAME IS NULL：2008/10/08(水) 19:52:25 ID:???

また落ちたのか。12までいってたから安心してたのに。
この板の即死判定って何レス？

しかしまぁ、はっきりいって需要ないのかも。

5 ：NAME IS NULL：2008/10/08(水) 20:08:27 ID:???

大坊設計

6 ：NAME IS NULL：2008/10/08(水) 23:14:26 ID:???

支援ついでに
>>3
日付型を使うべき

7 ：NAME IS NULL：2008/10/08(水) 23:48:08 ID:???

DB設計ってどうやって勉強してる？
よい書籍とかあったら教えて下さい。

8 ：NAME IS NULL：2008/10/10(金) 14:54:01 ID:???

文字列が全部固定長・・・
３文字くらいしか入力しないのに、
１００文字の固定長ｗ
理由をたずねたら、
ﾃﾞｰﾀﾍﾞｰｽの構造上、固定長のほうが処理が
パフォーマンスがいいんだよって

ＳＱＬみてみたら
全部のＳＱＬに毎回ＴＲＩＭかけてるしｗ
ＴＲＩＭするなら、最初から可変長にしてくれｗ

9 ：NAME IS NULL：2008/10/10(金) 23:11:15 ID:???

>>7
ERDレッスンかなあ。

業務ごとの濃い話になると別。

10 ：NAME IS NULL：2008/10/20(月) 14:21:28 ID:???

Webのシステムでキャッシュっぽいテーブルは固定長レコードになるようにしてる

11 ：NAME IS NULL：2008/10/20(月) 16:38:57 ID:???

＞ﾃﾞｰﾀﾍﾞｰｽの構造上、固定長のほうが処理が
＞パフォーマンスがいいんだよって

COBOLerの脳内妄想かと。
固定長しか知らん人種だし。

12 ：NAME IS NULL：2008/10/20(月) 19:34:57 ID:???

完全な固定長のレコードにアドバンテージを設けているRDBMSはMySQLのMyISAMくらいしか知らない。

13 ：NAME IS NULL：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：2008/10/22(水) 11:05:30 ID:???

>>14
>>9

16 ：NAME IS NULL：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：2008/10/25(土) 05:51:16 ID:???

>>17
DBMSによる。varchar2といってるからOracleなのだろうけど。

19 ：NAME IS NULL：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：2008/11/02(日) 10:48:06 ID:???

コボルの頃のじり貧ハードなら固定長で速度稼いでってテクも必要だろうけど。
今はハードの圧倒的進化とRACで、ほぼ限界無く欲しい処理能力得られるから可変長でも良いと思うけどね。

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

業務だといろいろ小手先の要求が有るから、表記用の文字列と処理用の日付の両方で持ってる。
３２日って入力して月末処理したいだとか。orz
伝票や帳簿には末日って書いてたからシステムでも同じようにやりたいとか。orz
締めのタイミングが、後藤日＋末日だったりするし。日付型で末日とか持てりゃ苦労は無いが。

22 ：NAME IS NULL：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：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：2008/11/07(金) 04:15:33 ID:???

パフォーマンスは別途検討するとして

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

価格がどの時点で確定するかというのが重要なので
売上テーブルに売価が必要なこともあるでしょう。
売ったあとに売価テーブルの内容が変わったら大変なことになってしまうし。

27 ：NAME IS NULL：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：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：2008/11/10(月) 08:39:10 ID:???

>>25
>いくら領域いるんじゃーって感じじゃない？
１年でたった365レコードでしょ？

31 ：NAME IS NULL：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：2008/11/16(日) 01:56:57 ID:???

データベース設計にも、デザパタみたいなものあるのかね？

34 ：NAME IS NULL：2008/11/16(日) 03:29:23 ID:???

こういう業務はこんな感じとかいう本はあるけど
デザパタというよりアナパタに近いよな。

35 ：NAME IS NULL：2008/11/16(日) 04:13:49 ID:???

>>34
是非、その本を教えてください
お願いします

36 ：NAME IS NULL：2008/11/16(日) 05:39:40 ID:???

アマゾンで「渡辺幸三」で検索すると何冊か出てくる。
生産管理のはかなりレベル高い。生産管理やった事ないけど
読み応えあって面白かった。

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

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

あとは本じゃないけど渡辺氏の公開してる
データモデルはいやーお世話になりました。
http://homepage2.nifty.com/dbc/

37 ：NAME IS NULL：2008/11/16(日) 14:29:38 ID:???

今ひどい自演を見た

38 ：NAME IS NULL：2008/11/16(日) 14:31:57 ID:???

このまえ『データベース・リファクタリング』て本買って読んでたけど
結局ケースバイケースで全然逆のこと書いてあったりして、途中で
読むの放棄した。結局ケースバイケースのバランスなんだよ！

39 ：NAME IS NULL：2008/11/16(日) 17:22:43 ID:???

>>37
ばれちゃーしょうがーねーな

でも本はいい本だから読んでね

40 ：NAME IS NULL：2008/11/16(日) 19:33:51 ID:???

まぁ、渡辺さんの本が良いってより他にあんまりないんだよな。
羽生さんは大規模システムもちゃんとやってきてる人なのかな？
ABDとか大きいレガシーシステムでどうせいっちゅーんじゃ、みたいな。

業務系は技術系と比べて情報少ないんで、
自分のやってることになかなか自信がもてない。
各社ごとではちゃんとノウハウたまってんのかね？

41 ：NAME IS NULL：2008/11/16(日) 22:20:46 ID:???

>>40
貯まってたら3Kとか最下層とか言われて無いだろｗ

42 ：NAME IS NULL：2008/11/17(月) 02:58:17 ID:???

>>40
そうですね・・・他にないってだけかw
だけっていっちゃ悪いか。

業務系、バッドノウハウは立派にたまってましたねぇ。
とくに大手製造業の子会社行った時は恐れ入った。

43 ：NAME IS NULL：2008/11/19(水) 00:11:57 ID:???

全てのテーブルは主キーをもつべきですか？

44 ：NAME IS NULL：2008/11/19(水) 00:23:52 ID:???

リレーションテーブルは要らないかも
複合インデックスさえあれば

45 ：NAME IS NULL：2008/11/19(水) 00:38:37 ID:???

あったほうが楽じゃね。

46 ：NAME IS NULL：2008/11/19(水) 02:49:26 ID:???

例えばペットショップのＤＢを作るとして
犬テーブルと猫テーブルとかってわける？
動物テーブルでまとめる？

47 ：46：2008/11/19(水) 02:53:38 ID:PDW1LNDk

別の言い方をすれば、
複数のテーブルで一意なIDが欲しくなった時どうする？

48 ：NAME IS NULL：2008/11/19(水) 03:04:51 ID:???

>>46
動物テーブルで分ける
ＩＤ＋種別（イヌ/ネコ/ハムスター・・）

49 ：NAME IS NULL：2008/11/19(水) 03:07:52 ID:???

その場合、犬専用フィールドとか猫専用フィールドがあるならどうする？
動物テーブルには犬猫以外にも数十種の動物が含まれる
それぞれが専用フィールドを持っていたら？

50 ：NAME IS NULL：2008/11/19(水) 03:09:43 ID:???

ヌルだらけの巨大なテーブルが１つなのと
データがみっちり詰まった普通サイズのテーブルが複数なのと
どっちが良いか

後者にした場合、動物全体での一意ＩＤが欲しい場合どうするか？が問題になる

51 ：NAME IS NULL：2008/11/19(水) 03:18:30 ID:???

テーブルを犬猫で分けて、一意ＩＤ用１対多リレーションテーブルを作る場合

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

これだと動物の種類の数だけフィールドが必要で、
新しく動物の種類が追加された時にテーブルの追加だけでなく
ここへのフィールド追加もやらなきゃいけない。
テーブル追加だけで済んだ方が良い。

52 ：NAME IS NULL：2008/11/19(水) 03:26:29 ID:???

色々書いたが
１つの巨大テーブルにするほうが
実用上の障害が思いつかない

誰か思いつく？

53 ：NAME IS NULL：2008/11/19(水) 04:42:21 ID:???

>>49
ＩＤ＋種別（イヌ/ネコ/ハムスター・・）＋属性

54 ：NAME IS NULL：2008/11/19(水) 10:40:33 ID:???

１つの巨大テーブルがいい人はExcelでもいいんじゃ？

55 ：46：2008/11/19(水) 16:21:28 ID:???

>>53
それは属性テーブルを動物別に作って外部キーはるってこと？
結局>>51だと思うけど

今のところの結論としては、
動物テーブルでまとめて、動物別にビューを作るのがいいかなと

56 ：NAME IS NULL：2008/11/19(水) 16:22:53 ID:???

一意ＩＤ用リレーションテーブル作っても同等の機能は達成できるんだけど
パフォーマンス的に不利だからね

かといってテーブル間の一意ＩＤが欲しいがために１つのテーブルにまとめるってのも
おかしいとは思うけどね

57 ：46：2008/11/19(水) 17:43:56 ID:???

一応、複数のテーブル間で一意ＩＤを得る方法はあるらしいんだが
単に一意ＩＤを振っても、あるＩＤがどのテーブルのどのレコードなのか
を特定できなきゃいけないからリレーションテーブルは必要なんだよね
そしてパフォーマンスの不利は避けられない

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

58 ：NAME IS NULL：2008/11/19(水) 17:52:22 ID:???

>>55
例えば明日からペットショップでマンモスハナアルキの扱いを
新たにはじめるとして、そんなマイナー動物一種類のために
巨大な動物テーブルのスキーマを変更するのもどうかと。

ID+共通データの動物リレーションと動物別リレーションに分けて
ある場合、ハナアルキ類のためのリレーション一つ作成して後は
幾つかビュー定義をちょこまか修正すれば完了。
既にストアされているデータへの影響は少なくて済むはずです。

59 ：NAME IS NULL：2008/11/19(水) 17:53:20 ID:???

>>57
下らなすぎてスルーしてたけど

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

最適かどうかは場合によるわな。
NULLだらけの横長テーブルなんて保守したくないし。
パフォーマンスの不利がどれほどのもんかとかな。

60 ：46：2008/11/19(水) 18:13:15 ID:???

>>58
そういえばテーブルへのフィールド追加って登録されてるレコード数に依存して負荷上がるのか。
でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？
WEBアプリフレームワークが自動認識してくれるような形で張るには、（つまりRDBの基本仕様上で張るには）
>>51みたいに動物の種類数だけフィールドを用意しないといけないと思うんだけど。

61 ：46：2008/11/19(水) 18:14:08 ID:???

>>59
明確な答えを持っているなら教えてください。
邪魔がしたいだけならお帰りください。

62 ：46：2008/11/19(水) 18:17:11 ID:???

動物別テーブル側に動物テーブル上のIDを持たせて
動物別テーブルと動物テーブルを結合したビューを作っておけば良いのかな

その結合処理って高速に出来るのかな？

63 ：NAME IS NULL：2008/11/19(水) 18:17:32 ID:???

ここはお前の専用スレじゃないんで、私物化するなら出てってくれない？

64 ：46：2008/11/19(水) 18:18:38 ID:???

>>63
スレに沿った話題であり問題はないと思います。

65 ：NAME IS NULL：2008/11/19(水) 18:29:09 ID:???

>>60
>でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？

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

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

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

あとこういう分割は普通に行われているので、実用的な速度で結合処理を実現
する方法についてはちゃんと解が存在しています。
インデックス等々に関して調べると良いのではないかと。

66 ：46：2008/11/19(水) 18:32:26 ID:???

それで良さそう。
ありがとう。

67 ：NAME IS NULL：2008/11/22(土) 03:29:20 ID:???

>>44
あれ、もしかしてリレーションテーブルには各外部キーにインデックス張っても
意味ないの？
>>62
DB構築者がビュー作って使う利点ってあるの？

68 ：NAME IS NULL：2008/11/23(日) 02:48:09 ID:???

>>44は、リレーションテーブルに行われる検索はほとんどの場合
他の２つのテーブルを繋ぐ処理だけだろうって事。

69 ：NAME IS NULL：2008/11/23(日) 02:50:12 ID:???

ＤＢ構築者がビュー使う利点無かったら誰にあるんだよ
ビューの利点＝プログラムでＳＱＬ書かなくて済む、なんて理解してるんだったら
そんなの定数定義しておけば良いだけだしＤＢにビューなんて機能持たせる意味ないだろ

70 ：NAME IS NULL：2008/11/23(日) 11:32:04 ID:???

設計レベルでビューは使わないだろうな
ビューは実装寄りの話だ

71 ：NAME IS NULL：2008/11/23(日) 12:07:03 ID:???

>>68
リレーションテーブルって複合インデックスのほうがいいんでしょうか

72 ：NAME IS NULL：2008/11/23(日) 17:46:01 ID:???

どんなインデックスもそうだけど、クエリによると思う。

73 ：NAME IS NULL：2008/11/23(日) 21:17:09 ID:???

ユーザーは複数の権限を持っている事がある
ユーザーは複数の組織に所属している事がある
ユーザーが特定の部門に属しているか、特定の権限を持っている場合ににのみ
特定のテーブルと1:1の関連を持たせる
しかし、権限や部門がが重複すると、そのたびにユーザーが抽出されるので
同じユーザーのデータなのに、複数データが出来てしまう。

こういうとき、どうするのが一般的なんでしょう？

74 ：NAME IS NULL：2008/11/23(日) 21:48:57 ID:???

とりあえず「組織」と「部門」の関連がよく分からないのですが・・・
DISTINCT一発で解決する問題のようにも見えます。

75 ：NAME IS NULL：2008/11/23(日) 22:12:47 ID:???

DISTINCT以前にもしかしてリレーションを理解してないんじゃないか
１つのユーザーテーブルに組織も権限も部門も全部つっこもうとしてるんだろ？

76 ：NAME IS NULL：2008/11/23(日) 22:15:37 ID:???

>>75
元のユーザーTBLがそういう感じなんよ
そこの部分はいじれない状況ということで許してくれ

やっぱり重複排除しかないのかねぇ

77 ：NAME IS NULL：2008/11/23(日) 22:27:58 ID:???

>>76
>元のユーザーTBLがそういう感じなんよ

もうテーブルが存在するなら、質問するときはそのスキーマの概略
程度でも示さないと。でないと答える方も>>74とか>>75みたいに無駄な
推理に頭を使う事になるでしょう？

78 ：NAME IS NULL：2008/11/23(日) 22:37:37 ID:???

>>77
すまん

79 ：NAME IS NULL：2008/11/23(日) 22:51:55 ID:???

リレーション理解してるならそんなの問題が既存のテーブル設計にあるの明らかだし
こういう糞テーブルの保守が必要なんですけど、って話すだろｗ

80 ：NAME IS NULL：2008/11/24(月) 01:31:03 ID:???

>>76
普通に再設計して既存アプリのインターフェース(元TBL型のVIEW)用意すればいんでね？

81 ：NAME IS NULL：2008/11/24(月) 02:03:02 ID:???

スレ違いかもしれんが、
郵便番号マスタ、市区町村マスタ、銀行マスタ、法定休日マスタ、和暦マスタ、消費税率マスタ
みたいなマスタテーブルを作ることに疑問を覚えるのは俺だけか？
何故、日本全国共通の情報を各々のDBに持ってちまちまメンテするんだろう？
疑問に思っちゃいけないことなのか？

82 ：NAME IS NULL：2008/11/24(月) 02:11:33 ID:???

・パフォーマンス
・完全参照系データでしかもそれほど動的に変わるものではないからWebAPIにする価値無し

83 ：NAME IS NULL：2008/11/24(月) 02:45:40 ID:???

セキュリティ

84 ：NAME IS NULL：2008/11/24(月) 02:59:24 ID:???

セキュリティが一番大きいね
WebAPIにしたらどこの誰が利用してるか分かる可能性がある

85 ：NAME IS NULL：2008/11/24(月) 09:37:58 ID:???

切り替えのタイミング

86 ：NAME IS NULL：2008/11/24(月) 10:21:38 ID:???

>>81
じゃあ、どうしろと？

87 ：NAME IS NULL：2008/11/24(月) 13:27:15 ID:???

>>81
その中でもファイルとして公開されてる物はある。
でも、提供先が国外だったりしてデータおかしかったりする物もある。

郵便番号なんかはバッチ処理でWebから落としてきて～ってどこでもやってるでしょ。
↑をメンテ処理って言ったらそれまでだけどｗ

88 ：NAME IS NULL：2008/11/24(月) 15:37:55 ID:???

NTPサービスみたいに、定期的に全自動的でデータが補正されるようにならんものかね。
この手のマスタを毎月（或いは毎年）メンテしてるやつらって、
ホントくだらない人生送ってるな思うよ。

89 ：NAME IS NULL：2008/11/24(月) 15:59:02 ID:???

つまり、>>88はそんな仕事をやらされている自分の人生にうんざりしているというわけだな。

90 ：NAME IS NULL：2008/11/24(月) 16:09:58 ID:???

いや、そんな仕事もまともにできない部下にうんざりしてる。

91 ：NAME IS NULL：2008/11/24(月) 16:21:56 ID:???

全自動でやるシステムを提案すればいいじゃねーか

92 ：NAME IS NULL：2008/11/24(月) 16:22:19 ID:???

>>85の切り替えのタイミングと、切り替える際の責任の所在かなぁ。
俺様に無断で祝日増やしやがって馬鹿政府のこんちくしょう。

将来なんちゃらクラウドの上にテータベースに乗っけて運用するよう
になると、この手のマスターデータは標準部品として提供されるように
なるのでしょうか。

93 ：NAME IS NULL：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：2008/11/24(月) 22:59:03 ID:???

>>94
ＳＩ企業にとっちゃ、仕事が増えるからいいんじゃない。

96 ：NAME IS NULL：2008/11/25(火) 01:12:59 ID:???

ピラミッド立てるのと一緒でみんな無駄だとわかってても
世の中がまわる為に必要だから止められないんだよ

97 ：NAME IS NULL：2008/11/25(火) 01:28:14 ID:???

自治体のは無駄だと思うが
住所データとかは各ベンダーが持たないなら国がWebAPI提供するしかないし
今の形が妥当

98 ：NAME IS NULL：2008/11/25(火) 03:17:40 ID:???

>>94
>　後期高齢者医療制度対応とかさ。
上手に作られたシステムなら、マスターの変更だけでＯｋ。
でも、テストは必要。
結局、ベンダーに発注するしかない。

99 ：NAME IS NULL：2008/11/25(火) 11:32:56 ID:rHJnodNO

全体最適化とかまったく考えず各々価格だけで競争入札するから結果的に無駄に税金がかかる。
道路や建物つくる感覚で発注してるんだろうね。

100 ：NAME IS NULL：2008/11/25(火) 15:22:35 ID:???

ＤＢ設計を語るスレが制度設計を語るスレになっている件。

101 ：NAME IS NULL：2008/11/25(火) 17:56:35 ID:???

このスレで聞いていいのかな
商品テーブルにジュース　ポテト　ハンバーガーって商品があって
この3つを組み合わせでバリューセットって商品を作りたいとすると
商品テーブルのバリューセットの主キーとジュースの主キーを組み合わせるテーブル作ればOKだよね？

102 ：NAME IS NULL：2008/11/25(火) 18:04:20 ID:???

バリューセットっていう１商品で別に他とつなげる必要があると思えんが

103 ：NAME IS NULL：2008/11/25(火) 18:08:08 ID:???

そもそも４行目の意味が分からん
お前は同じテーブル内のレコードを繋げるリレーションテーブルを作ろうとしてるのか
別にそれでも実装上の問題はないのか・・・

104 ：NAME IS NULL：2008/11/25(火) 18:18:18 ID:???

>>102
この商品はこの3つの商品の組み合わせですみたいな感じで
セットの値段とバラの値段を表示したいなと思いまして。
>>103
実装上は大丈夫なんですが、もっといい方法があるかなと思って質問させて貰いました

105 ：NAME IS NULL：2008/11/25(火) 18:58:29 ID:???

全てのバリューセットが主菜(ハンバーガ)・副菜(ポテト)・ドリンク(ジュース)の
三点セットなら、バリューセットのキーと主菜・副菜・ドリンクのキーの計4つの
キーを含むリレーションを作成。

セットによって副菜が2つになったりドリンク無しだったりと構成要素が大きく
異なる場合はバリューセットのキーと構成要素のキーを含むバイナリ
リレーションで表現。

106 ：NAME IS NULL：2008/11/25(火) 19:17:48 ID:???

商品テーブル（IDと名前とその他共通属性）

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

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

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

これでセットメニューがどんな構成だろうと対応出来るぞ
バイナリも使う必要ない

107 ：NAME IS NULL：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：2008/11/25(火) 23:18:29 ID:???

まさにこんな問題が、テクデの過去問にあったな。

110 ：NAME IS NULL：2008/11/26(水) 00:35:25 ID:???

バリューセットは難しいね。
原価とか利益をどう持つかで色々な設計のパターンが出てきそうだ

111 ：NAME IS NULL：2008/11/26(水) 15:15:15 ID:???

リレーションテーブル・・・・難しい言葉ですね・・・

112 ：NAME IS NULL：2008/11/26(水) 15:18:27 ID:???

正しい言葉だと思うけど、何か意見があるなら聞かせて欲しい。
具体的な指摘をして欲しい。

俺がリレーションテーブルと言う言葉を使うのは、
マスタもテーブルもテーブルなのにおかしいと思うから。
かといってリレーションと言うだけではＦＫなども含まれてしまう。

113 ：NAME IS NULL：2008/11/26(水) 16:16:47 ID:???

>>112
>>111はなんだか意地悪な感じだね。
「リレーション」というのは「テーブル」の事を指します。
なので「リレーションテーブル」っていうと「犬ドッグ」的な感じになっちゃいます。
RDBの基となる関係代数からの用語ですが。
テーブル：リレーション
レコード：タプル
フィールド：カラム

テーブルとテーブルの関連のことは「リレーションシップ」と呼びます。

114 ：NAME IS NULL：2008/11/26(水) 16:18:20 ID:???

>>112
>マスタもテーブルもテーブルなのにおかしいと思うから。
>かといってリレーションと言うだけではＦＫなども含まれてしまう。
ってか、この２行の意味が分かんない。

115 ：NAME IS NULL：2008/11/26(水) 16:29:01 ID:???

>>113
それは文脈によらない？
DBの実装上の用語ではおかしい事は言ってないよ。

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

リレーションとリレーションシップで言い分けるより通じる。

116 ：NAME IS NULL：2008/11/26(水) 16:46:11 ID:???

ついでに
http://homepage1.nifty.com/silabel/it/master_table.html

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

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

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

果たして、この世に存在し得るデータ一般を表現する一形式を議論する場合と
ある業務のＤＢ設計を議論する場合で
同じ用語体系が使われるべきだろうか？

117 ：NAME IS NULL：2008/11/26(水) 17:00:17 ID:???

>>115
>マスタなのかテーブルなのかを明示したい場合、どういい分ければいいの？

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

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

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

昨日もバイナリリレーションと書いてやばっ、と思ったらやはり誤解が。
言葉って難しいです。

118 ：NAME IS NULL：2008/11/26(水) 17:01:12 ID:???

と自分で出したページに「ディテール・テーブル」と言う用語がかかれてたから今後はこれを使うよ。
検索してもほとんど出てこないから通じない可能性が怖いけどね。

あとさらに言えば、リレーションがリレーションシップと同じ意味で使われる場合がかなり多い。
今検索して見つけた例
http://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：2008/11/26(水) 17:06:02 ID:???

他人と話す時は、自分勝手な用語はつつしんだ方がよいと思う。
意味は通じるけど111のようなツッコミが入るのは不思議じゃない。
>>112で「正しい言葉だと思うけど」と言ってたけど、正しい言葉ではないだろ。
通じるけど。

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

>リレーションとリレーションシップで言い分けるより通じる。
まともに勉強している人はリレーションとリレーションシップで通じる。

120 ：NAME IS NULL：2008/11/26(水) 17:14:56 ID:???

そもそもrelationとは米中関係のことらしいという件。

121 ：NAME IS NULL：2008/11/26(水) 17:21:30 ID:???

>リレーションがリレーションシップと同じ意味で使われる場合がかなり多い
誤用が広まっていても、正しいことにはならないよ。
日常会話ならともかく、開発のときは気をつけるべきだね。

そして
http://homepage1.nifty.com/silabel/it/master_table.html
は酷すぎ。信用しちゃいけない。

122 ：NAME IS NULL：2008/11/26(水) 17:44:34 ID:???

確かにリレーションとリレーションシップは実際扱いにくい言葉だな

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

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

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

>>121
>http://homepage1.nifty.com/silabel/it/master_table.html
>は酷すぎ。信用しちゃいけない。
ひどいね

123 ：NAME IS NULL：2008/11/26(水) 17:47:40 ID:???

>>119
＞自分勝手な用語は
一般的な用語しか使っていない。
リレーションテーブルと言う言葉はテーブルと言う言葉を含んでいてマスタと比較する文脈であれば問題は無いと思う。

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

>>121
酷すぎるという根拠は貴方の主観以外にあるの？
俺は検索と言う方法でそれが一般的な用語であると言う客観的な根拠を示したつもりなんだけど。

124 ：NAME IS NULL：2008/11/26(水) 17:55:56 ID:???

ディテールテーブルと言う言葉を上で使うべきかと書いたけど、
それは間違いだったね。
>>122の通りディテールテーブルと俺が言うマスタ文脈上のテーブルは意味が違う。
関連テーブルだと英訳すればリレーションテーブルになるけど、
もし英語で設計書かけと言われたらどう書くの？

125 ：NAME IS NULL：2008/11/26(水) 18:18:41 ID:???

さらに検索

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

http://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：2008/11/26(水) 18:30:04 ID:???

ちなみにマスタという言葉も曖昧で実際のシステムの保守においては多様な意味を知っている必要がある。
http://blog.goo.ne.jp/xmldtp/e/a416473823c05b2b24108981b3025bad

結局、関連テーブルに対し適当な名前が付けられていない。
関連テーブル以外には名前が付けられている事があって、
単にテーブルと呼べば関連テーブルを指すと言うケースがある。
関連テーブルは英訳すればリレーションテーブルになってしまい、これも適当な用語ではない。

127 ：NAME IS NULL：2008/11/26(水) 18:41:31 ID:???

突っ込みどころが多すぎてめんどくさい

128 ：NAME IS NULL：2008/11/26(水) 18:43:50 ID:???

>関連テーブルは英訳すればリレーションテーブル

バリューセットの例でいえばmany-to-manyの関連なので
「association table」かなぁ。

129 ：NAME IS NULL：2008/11/26(水) 19:11:52 ID:???

> http://q.hatena.ne.jp/1177173258
> これのtbl_は恐らく関連テーブルを指してるだろうね。
質問には「普通のテーブル」って書いてあるよw
普通のテーブルって何よ！！！
ってくらいの低レベルな質問者なので、こんなの引用されてもなあ

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

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

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

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

T字形だと「対照表」と呼ぶよな。
ネットで初心者が用語を混同して質問しているのをいくら挙げられても、なんにもならないよ。

130 ：NAME IS NULL：2008/11/26(水) 19:17:56 ID:???

ふと思ったけど
「マスタとテーブル」って汎用機時代のオッサン用語だったりするかも。

131 ：NAME IS NULL：2008/11/26(水) 20:12:46 ID:???

>>129
＞質問には「普通のテーブル」って書いてあるよw
その質問者が普通のテーブルが何を意味してるのかが分かってないから聞いてるんだよね？

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

カタカナ化せず関連テーブルと呼ぶなら、
mst_ trn_ とつけて kanren_ってつけるの？
それとも普段からの呼び方は「関連テーブル」で設計書上では「rel_」とするの？

132 ：NAME IS NULL：2008/11/26(水) 20:20:22 ID:???

>>123
> >>121
> 酷すぎるという根拠は貴方の主観以外にあるの？
正しい事が書いてある項目を見つけるのが難しいっす

133 ：NAME IS NULL：2008/11/26(水) 20:27:43 ID:???

>>132
そのサイトに書かれている項目のうち何割が間違っていますか？
偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。

俺の認識では、確かに誤用かもしれないが確実にこの用語で作られたシステムはかなりある。
かなりのエンジニアに通じる。
全く認知されていない「勝手な用語」であると思えてしまう人が居るのは、単に知らないだけ。
と言う認識。

134 ：NAME IS NULL：2008/11/26(水) 20:41:20 ID:???

>>131
"rel_"とか"r_"とか"kanren_"とかなんでもいいけど"tbl_"とはしないよな。

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

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

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

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

スクリプト言語 = 文法が簡単なプログラミング言語
シーケンシャルファイル =「1行1データ」で表されるデータ。
トランザクション・ファイル = プログラムの処理の過程で削除されてもよいファイル
オブジェクト指向 = 既にあるものを組合せ、短期間でよりよいプログラムを作ること。

135 ：NAME IS NULL：2008/11/26(水) 20:42:53 ID:???

追加。これももちろん違う
■テーブル
　マスター・データの関連データを格納したファイル
　またの名を「ディテール・テーブル」

136 ：NAME IS NULL：2008/11/26(水) 20:43:35 ID:???

>>135
というか汎用機時代はそうだったのかもしらん

137 ：NAME IS NULL：2008/11/26(水) 23:17:28 ID:???

>>130
汎用機出身のオッサンはテーブルのことを「ファイル」と呼んだりするからあなどれないw

138 ：NAME IS NULL：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：2008/11/26(水) 23:32:56 ID:???

>>133
>そのサイトに書かれている項目のうち何割が間違っていますか？
>偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
>それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。

なんという上から目線www

141 ：NAME IS NULL：2008/11/26(水) 23:51:18 ID:???

＞本来の意味通りのテーブルならテーブル名の接頭辞にする意味ないからね。

テーブルなのかビューなのかファンクションなのか接頭語で分かるように
テーブル（オブジェクトとしてテーブルに分類されるもの）には全てT_を付ける、とか
珍しくも無いと思うけど。

142 ：NAME IS NULL：2008/11/27(木) 00:38:24 ID:???

>>137
コボラはDB屋の敵だ

143 ：NAME IS NULL：2008/11/27(木) 01:29:46 ID:???

>>141
それやるとDB側だけ変更でテーブル→ビューって置き換えた時にT_XXXってビューが出来る。

144 ：NAME IS NULL：2008/11/27(木) 02:52:23 ID:???

>>116
そんなアホサイトじゃなくて書籍を買って読んでみなよ。
お母さんにお小遣いもらってさ。

145 ：NAME IS NULL：2008/11/27(木) 06:43:29 ID:???

なんか実務経験とかがロクになさそうな厨房が
俺ルールを押し付けるスレって雰囲気だな。

146 ：NAME IS NULL：2008/11/27(木) 19:36:08 ID:???

どの辺が俺ルール？

147 ：NAME IS NULL：2008/11/27(木) 20:23:03 ID:???

コボラーのときは本当にテーブル単位でファイル弄ってただけ。

148 ：NAME IS NULL：2008/11/29(土) 04:44:35 ID:???

>>147
だからってRDBのテーブルを「ファイル」って呼ぶなよ

149 ：NAME IS NULL：2008/11/29(土) 11:00:42 ID:???

テーブル操作＝ファイル操作だから同じ事。

150 ：NAME IS NULL：2008/11/29(土) 13:37:59 ID:???

ファイルメーカー

151 ：NAME IS NULL：2008/11/29(土) 14:38:32 ID:???

>>149
同じ事なわけねーだろw

152 ：NAME IS NULL：2008/11/29(土) 20:58:43 ID:???

COBOLから見るとまったく同じに見える
ミドルウェアってえらいね
横に長いテーブルまんせー

153 ：NAME IS NULL：2008/11/30(日) 02:02:41 ID:???

殺意が沸いた

154 ：NAME IS NULL：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：2008/11/30(日) 03:18:18 ID:???

実務の世界にいないのでどのような確執があるのか見当も
つかないのですが・・・

かつてDB屋さんとコボル屋さんの間で血で血を洗う闘争でも
あったのでせうか（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

156 ：NAME IS NULL：2008/11/30(日) 05:29:09 ID:???

現在も戦いは続いている

157 ：NAME IS NULL：2008/11/30(日) 06:02:15 ID:???

>>155
メインフレームＤＢとUnix系ＲＤＢとだろ。
前者で使われている言語は主にＣＯＢＯＬ。
後者で使われている言語はかつてはＣ、現在ではスクリプト系言語などさまざま。

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

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

まあ、歴史的にはこんなかな。とメインフレームを知らない俺が言ってみる。
階層データーベースにはテーブルというものがない。「ファイル」というのはそのせいか。
ものが
あって、

158 ：NAME IS NULL：2008/11/30(日) 11:09:41 ID:???

かゆ
うま

159 ：NAME IS NULL：2008/11/30(日) 15:27:50 ID:???

別にCOBOLと言う言語が悪い訳でもないとは思うが、
コボルを扱う人間の設計には欠陥が多いのは事実ではあるな。
オマエラは一生２０年前のシステムのだけ見てれば文句はないのだが、
現代のRDBのシステムにクチを出してくると、ほぼプロジェクトは火を噴く結果になる。

160 ：NAME IS NULL：2008/11/30(日) 18:43:39 ID:???

「俺たちの戦いはこれからだ」的な実情ですね。大変だなぁ。

先ほどの「横長のテーブル」もそういうCOBOL畑だった人が持ち込みがちな
「困った設計」なのでしょうか。
単に正規化に無頓着なのか、それともまた別の異なる設計論があるのか、
まるで異文化コミュニケーションですね。

161 ：NAME IS NULL：2008/11/30(日) 19:59:12 ID:???

ある程度、先入観が混じっている見方だけど、
メインフレームを使う金融系COBOL畑と言うのは、技術畑のエンジニアが
やった仕事ではなく、大昔のIBMのテンプレートを真似ただけの、
マニュアル仕事であって、競争とかそういうのは無い狭く閉じた世界の
物語と言う感触がある。

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

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

さらにヤやこしいのが金融系と言う仕事が謎なステータスがあり、
そこでCOBOLがある程度ブイブイ言わせているので、COBOL畑の
人間が高給取りかつ増長している現実がある。

162 ：NAME IS NULL：2008/11/30(日) 20:55:35 ID:???

つかCOBOL馬鹿にするだけで、開発自体まともに理解出来てない奴がいるな。

163 ：NAME IS NULL：2008/12/01(月) 00:48:22 ID:???

「俺は昔こんな事をしたんだぜ」
が自慢だけならいいが
「俺は昔こんな事をしたから、これからもこれでOK」
というおっさんが権力だけ持ってるのがうざい

164 ：NAME IS NULL：2008/12/01(月) 01:46:40 ID:???

昔と今で技術に隔絶の差があるのになぜおまえらはおっさんにそれを伝えることができないの？

165 ：NAME IS NULL：2008/12/01(月) 02:10:20 ID:???

>>164
そこまで力がないからでしょ。
力があって理解せられてれば自慢じゃなくて添削依頼になる。

166 ：NAME IS NULL：2008/12/01(月) 03:08:50 ID:???

添削依頼なんてならねえよ。社内上の立場ってもんがあらあ。
簡単にウン１０年の情報化の歴史を小僧っこに否定されてみろ。

167 ：NAME IS NULL：2008/12/01(月) 14:17:25 ID:???

>>166
話にならん

168 ：NAME IS NULL：2008/12/01(月) 14:21:02 ID:???

そんなこんなで日米の証券システムは、乳母車とスペースシャトルに例えられるくらいの差がついてしまったわけで

169 ：NAME IS NULL：2008/12/01(月) 15:33:13 ID:???

>>166
普通にされてるんだが・・・自分より10以上離れた年齢の人に。
そうでもないと思ってたがずいぶんとマシな所に勤めてたようだ。

170 ：NAME IS NULL：2008/12/01(月) 21:25:43 ID:???

ﾋﾟｺｰﾝ

171 ：NAME IS NULL：2008/12/01(月) 23:26:52 ID:???

悲惨な前線での戦闘の話を聞き、自分の身の上が恵まれていることに
気が付いた>>169であった・・・。

172 ：NAME IS NULL：2008/12/02(火) 17:56:54 ID:???

>>161
残念だが、そういう人間はCOBOLやJava、C#にかかわらず非常に多い。

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

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

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

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

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

>>168
砂利を運ぶのに「カウンタックを作れ」と指示されて、カウンタックを作っちゃう日本と
ちゃんと目的にあったカスタマイズされたダンプを作るアメリカとの違いだよ。

173 ：NAME IS NULL：2008/12/02(火) 20:18:19 ID:???

JEFをUNICODEに完全に変換できないのが悩み。DB関係ねえ。

174 ：NAME IS NULL：2008/12/02(火) 23:11:27 ID:???

２０年後「俺がやってたＣ＃ではな・・・」と自慢話をして、煙たがれる人もいるだろうな。

でもどうだろうな、技術というものはいつも同じスピードで進歩するものでなくて
ある時期に急激に進歩してその後停滞するものであるから
ＩＴ関連の技術は、今後２０年間あまり変わらないのではないかな

175 ：NAME IS NULL：2008/12/03(水) 00:17:39 ID:???

>>174
まだまだ変わる思うよ。
次の劇的な変化は、関数型言語が実用的なレベルになるくらいにハードが進化した時に来ると思う。

176 ：NAME IS NULL：2008/12/03(水) 00:25:44 ID:???

つか、今現在CやUNIXでそういうパターンの奴はいて、本人は気付いていない
というのがあるだろ。
COBOLerも、自分の技術は普遍的でメインストリームで、そこいらのPCのような
おもちゃとは違うと信じているし、それが時代遅れだとは露ほども考えていない
というのはおんなじだな。

177 ：NAME IS NULL：2008/12/03(水) 00:26:52 ID:???

DBはどうでしょうか。Relational database model自身はもうすぐ40周年
ですが、この次に別な何かは来るのでしょうか。

178 ：NAME IS NULL：2008/12/03(水) 01:10:21 ID:???

ＳＱＬを使わないデータベースが出てくるんでしょうかね
オブジェクトデータベースというのはどうなんでしょ

179 ：NAME IS NULL：2008/12/03(水) 06:51:45 ID:???

xmlを扱うデータベースは今までのRDBと毛色がやや違う程度で
チマチマ普及すると思うが、メインはRDBだと思われ。

180 ：NAME IS NULL：2008/12/03(水) 22:54:59 ID:???

色々言われ続けながらも結局生き残ったもんなァ・・・

181 ：NAME IS NULL：2008/12/03(水) 23:14:26 ID:???

db4oもサンプル見るとすげぇって思うけどちょっと調べると・・・

182 ：NAME IS NULL：2008/12/03(水) 23:48:06 ID:???

今扱っているDBスキーマには何十個もテーブルがありますが、
全てのテーブルでカラム数が2です。
スキーマ設計の欠陥でもネタスキーマでもなく、カラム数は
2で固定、という仕様のDBMSなのです。

このやり方でも大抵のデータを表現できる自信はありますが、
このやり方の時代が来ることも、また無いような気がします。
(内心は、あるかも、そんなときめきもちょっと感じています)

183 ：NAME IS NULL：2008/12/04(木) 04:18:16 ID:???

なにそれどういうDB？

184 ：NAME IS NULL：2008/12/04(木) 23:53:14 ID:???

>>182
そういう作りはちょっと考えてんだけど、実際にやってるとこあるんだなw
いまから趣味でつくろうとしてるOSSで試してみようかな・・・

185 ：NAME IS NULL：2008/12/05(金) 00:05:17 ID:???

MonetDBというDBMSです。

http://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：2008/12/05(金) 03:51:53 ID:???

バッチ処理に一晩コースだな。
リアルタイム更新のインターネット用途は不適っぽいな。

187 ：NAME IS NULL：2008/12/05(金) 17:13:10 ID:???

仮に20カラムのリレーションが欲しければ代わりにテーブル20個
作っちゃえ、というやり方ですから行単位で参照したり更新したり
というOLTPアプリでは既存のRDBMSの実装の方が優れます。

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

なのでOLAPやData mining、学術用のデータ解析など向けですね。

188 ：NAME IS NULL：2008/12/05(金) 22:58:34 ID:???

設計の自由度は高いでしょうね。
性能は悪そう。

189 ：NAME IS NULL：2008/12/06(土) 00:27:38 ID:???

設計の自由度は、あまり変わらないかな。
MonetDBのアセンブリ言語使って何かしようというのは相当変な事 orz
をしようという人だけであって、普通はSQLとかXQueryで使うはずです。

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

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

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

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

http://jp.youtube.com/watch?v=yrLd-3lnZ58

190 ：NAME IS NULL：2008/12/06(土) 02:26:08 ID:???

つーかなんだな
OODBって結局一度もブームこなかったな
ポストRDB！！とか騒がれていたのに

191 ：NAME IS NULL：2008/12/06(土) 13:57:59 ID:???

だって遅いし。

実データをオブジェクト指向で扱うのって無理が有りすぎる。無限に要素を想定する事に成るし。
加工するにはオブジェクト指向で操作したほうが直感的では有るけど。

192 ：NAME IS NULL：2008/12/06(土) 19:51:06 ID:???

なんだかんだでSQLって良く出来てるよなぁ
ORでインピーダンスミスマッチとかよく言われるけど、
SQLからクラスとマッピングコード生成するスクリプトを書けば
いいだけだしな
何もＤＢ自体がOOである必要はねーよ

193 ：NAME IS NULL：2008/12/06(土) 19:57:07 ID:???

カラム数が２だとキーと値を持たせたら終わりじゃないの？
A りんご
A 100
A 青森産

B みかん
B 150
B 愛媛産

みたいに。
「このレコードは名称、このレコードは値段」とか判断付かなくない？

194 ：NAME IS NULL：2008/12/06(土) 20:15:21 ID:???

「あれができない、これもできない」っていってたらキリがないだろw

195 ：NAME IS NULL：2008/12/06(土) 20:17:37 ID:???

そうだな。
判断付かなくて困るって程のことでもないし、いいのか。

196 ：NAME IS NULL：2008/12/06(土) 20:37:18 ID:???

>>192
無能は黙ってろ

197 ：NAME IS NULL：2008/12/06(土) 20:53:52 ID:???

>>193
カラム数は2で固定ですが、テーブル自体は沢山作る事ができるので、
この例だとキー:名称、キー:値段、キー:産地の三つのテーブルを作るのが
一つの解です。
各テーブルでキー->名称、キー->値段、キー->産地の関数従属性を表現
出来て、これらの三つからキー->(名称, 値段, 産地)の関数従属性を導出
出来ますから、この分解は無損失です。

198 ：NAME IS NULL：2008/12/06(土) 20:58:29 ID:???

組織マスタ
組織
上位組織

社員マスタ
社員番号
役職

権限マスタ
権限

とあるときに、ある社員の役職が自分の所属する組織だけで通用する
権限を持たせるようにするにはどう関連を引けばいいの？

199 ：NAME IS NULL：2008/12/06(土) 21:12:21 ID:???

外部キー無いじゃねぇかｗ

200 ：193：2008/12/06(土) 21:36:41 ID:???

>>197
あー、そりゃそうだ。
名称と値段と産地が同じテーブルに入ってるという普通のDB的考え方がそもそも違うのか。

201 ：NAME IS NULL：2008/12/07(日) 11:02:15 ID:???

まあ総当たりで再利用考えなければｗｗｗ

202 ：NAME IS NULL：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：2008/12/10(水) 01:06:13 ID:???

>>203

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

PK ID
対戦相手ID
X回戦（一回戦とか二回戦とか）
X試合（第一試合とか）
選手
勝敗フラグ

205 ：NAME IS NULL：2008/12/10(水) 01:11:09 ID:???

と思ったけど勝ち上がった後のキーもいるかな。
このやり方だとトーナメントの下から追うのはいいが上から追えないが。。。

206 ：NAME IS NULL：2008/12/10(水) 19:07:05 ID:8RNJEsTT

ちょっとみんなの意見をききたい

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

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

日付型で時間入らないように制約つけるのがベスト？

207 ：NAME IS NULL：2008/12/10(水) 22:25:29 ID:???

レスしてもいいが貴様の態度が気に食わない

208 ：NAME IS NULL：2008/12/10(水) 23:47:56 ID:???

MSSQL2008なら日付単位でもてる

209 ：NAME IS NULL：2008/12/11(木) 01:30:53 ID:???

日付型でやった方が型で制約つけれるし
日付関係の関数が使えるので日付でやる

変に文字列とか数値とかでやると後で型をキャストする必要がある時めんどいし。

210 ：NAME IS NULL：2008/12/11(木) 06:36:02 ID:???

＞日付型って時間とセットなんだよなぁ

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

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

そうしておかないと、あとでCOBOLerの様な人種が「9999-99-99」とかﾄﾝﾃﾞﾓ日付を入れて
アプリでﾄﾝﾃﾞﾓ実装をやりはじめそうだし。

211 ：NAME IS NULL：2008/12/11(木) 19:06:44 ID:???

>>210
むしろその制約のために日付を無理やり文字列管理ってDBがいかに多いか…

212 ：206：2008/12/11(木) 20:16:12 ID:???

>>208
２００８はデータ型増えてるのか．．．

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

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

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

まあ、やはり日付入れる項目には日付型使うほうがよさそうなんで、
やっぱりその方針でやるよう検討するわ。

213 ：NAME IS NULL：2008/12/11(木) 20:48:31 ID:???

>>212
>　9999-99-99を入れたいがために、文字列で定義されているシステムが多いってことか？
２０００年問題で有名になったYYMMDDというのがある。

214 ：206：2008/12/12(金) 00:19:34 ID:???

>>213
いや、あるのは知ってる。YYnnnとかな
ＤＢ使わない、それこそコボラーな世界では普通だった。
その世界ではそれが間違ってるとは思ないが、
ＤＢ設計としてはどうなの？って話だ

いまどきメモリの１バイトは血の一滴ってわけじゃあるまいｗ

215 ：NAME IS NULL：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：2008/12/12(金) 02:00:56 ID:???

(1)はDATEDIFF関数で。（ORACLEとSQL Serverで若干書式が異なるが）

(2)は普通に入社日と退職日でGROUP BYしてCOUNT取れば出来ないか？

217 ：NAME IS NULL：2008/12/12(金) 17:25:06 ID:???

＞俺の中では、日付型は日にちと時間せっとなのがスタンダードで、

ソレって主にOracleの事情だったっけ？
DB2,Postgre,MySQLは日付と時間を自由に出来たはずだが。

218 ：NAME IS NULL：2008/12/12(金) 22:41:18 ID:???

SQL Serverも2005までならそうだと思うが

219 ：NAME IS NULL：2008/12/13(土) 15:20:28 ID:???

普通３２ビットだから、時間も一緒でしょ。
別に二つカラム持って、こっちは日時しか見ない、こっちは時間しか見ないでもいいと思うが。
どうせ日時の二倍データ量使うでしょ。

１バイトでも件数大量なら無視できないけどな。
オープンソースとかで安易に電網鯖構築してるとレスポンスめちゃめちゃ悪いサイトが出てくるのはそんな理由も大きい。
商品情報とか数万件じゃ済まないし。

220 ：NAME IS NULL：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：2008/12/13(土) 23:33:34 ID:???

>>215
(2)は日付テーブルを持っておいて、1日ごとにジョインしたあとにgroup byして…
とかで出来そうだけど死ぬほどパフォーマンス悪そう。
プロシージャとかで必要に応じてデータ作るのが現実的な気がする。

222 ：NAME IS NULL：2008/12/14(日) 06:39:14 ID:???

timestampはデフォ３２ビットでおま。

223 ：NAME IS NULL：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：2008/12/14(日) 07:24:05 ID:???

>>219
前半いわんとすることが全く理解できないんだが．．．
日付型が時間とセットでしか格納できな処理系で、時間を設定しない項目に
日付型を使うか否かというのが論点だったんだが．．．
>１バイトでも件数大量なら無視できないけどな。
これには同意
ただ、数万から数十万程度の件数でレスポンス悪化するようでは、
そもそもの設計がおかしいと思うぞ

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

>>222
それってどんなＤＢＭＳでもそうなのかね？
まあ、はじめに処理系依存な話をしだしたのは確かに俺だが、
特定のＤＢＭＳでしか通用しない話は、そのＤＢＭＳを明示してくれないか
ついでに聞くが、デフォで３２ビットってことは、変更も可能ってことかね？

225 ：NAME IS NULL：2008/12/14(日) 07:52:35 ID:???

>>223
在職期間の重なりを判定するならこれで十分だろ。

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

(2)も、集計期間のリレーションが用意されているなら同じように可能。

226 ：211：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：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：2008/12/14(日) 17:43:40 ID:???

>>226
その手の話は、コボラーの時代には普通の設計だったな
まあ、未設定なら俺ならLow Value入れるがなｗ

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

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

ちなみに、たとえば、有効期限みたいな項目があったとして、
期限日が入ってる場合以外に、未設定と永久があって区別したい、とか言うと
未設定はNULLでいいとして、永久ってのは別途フラグかなんかで項目作るのが正しいＤＢ的設計？

229 ：NAME IS NULL：2008/12/14(日) 20:22:51 ID:???

9999-99-99がでふぉ。

230 ：NAME IS NULL：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：2008/12/14(日) 21:31:32 ID:???

>>230
すげえ、あたりｗｗ
後から High Value ２って規格ができたよ。
もろ8888-88-88だった。
バッチ組の仕様でHigh Valueでも2タイプを判断しなくちゃいけなくて云々と説明されたけど、理解不能だったorz
UI側はただただ面倒臭くてたまんなかったわー。
他の項目の状態判断して、設定するHigh Value値を切り替えなきゃいけないんだから。

232 ：NAME IS NULL：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：2008/12/16(火) 02:13:45 ID:???

>>232
>データにはなんでもヘッダ(01)、データ(10)、トレーラー(88,99)とかつけたがるし。
さすがにそれはお前のとこだけだろうと思うが

>とは言え、RDBMSなんだからCOBOLerがSQLやらフレームワークを考慮してくれないと困るんだが
まあ、ＣＯＢＯＬとＲＤＢっていまいち相性悪いよな
そもそもＣＯＢＯＬ全盛のときはＤＢは実用的ではない場合がほとんどで、
ＤＢ導入するならＣＯＢＯＬもやめて作り直せば良いんだが．．．なかなかそういかない現実がある

234 ：NAME IS NULL：2008/12/16(火) 19:16:08 ID:???

店舗ごとの品目売り上げ実績一覧テーブルがあるのですが、
品目一つに対して一列になっているため、
品目の調整がはいるたびに大変な状況です。
実績は金額、件数、率を含んでいるため
単純に列を行に移し替えることはできません。

こういった場合、実績の単位ごとにテーブルを分けて
管理するといった方法でよいでしょうか？
言い忘れてましたが、実績には対応するコードがあり
それで特定可能です。
（今はなぜか列名にそのコードが設定されていますが…）

235 ：NAME IS NULL：2008/12/16(火) 20:34:23 ID:???

>>232
COBOLerはCOBOLerで、「なんでCODASYL標準のDBMS使わないんだよ。」
と思っている希ガス。

236 ：NAME IS NULL：2008/12/16(火) 22:48:38 ID:???

店舗マスタ(店舗コード、店舗名、住所・・・）
品名マスタ（品名コード、品名、値段・・・）
実績テーブル（実績コード、店舗コード、品名コード、実績、・・・）

こんな感じ？

237 ：NAME IS NULL：2008/12/16(火) 23:02:45 ID:???

現状だと
実績一覧テーブル（みかん金額、みかん件数、みかん率、りんご金額、りんご件数、りんご率…）
になっている、という話？

238 ：NAME IS NULL：2008/12/17(水) 00:52:18 ID:???

>>236,237
今の構成としては
YYYYMM、店舗コード、実績001、実績002、実績016、実績003…
といった感じです。実績列の名前末尾三桁が実績コードです。
つまり、品目を特定するキーがないのが現状です。
前任者の意図としては、web側で出力するのに
SELECT一発で出せるようにということのようです。

>>236さんの方法ですと、実績の単位の型ごとに
列を持つことになるかと思います。
実績_金額、実績_件数、実績_率のように。
この場合、１レコードに対して、必ず２つのNULL列が出ますが
設計上良いものでしょうか。
他に案も浮かばないですが…。

239 ：NAME IS NULL：2008/12/17(水) 08:18:50 ID:???

金額か件数か率かは実績コードから決まるんなら

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

でいいんじゃない？
これをクロス集計すれば一発だと思うけど

240 ：NAME IS NULL：2008/12/17(水) 18:41:13 ID:???

>>239
はい、単位は品目コードで一意に識別できます。
今日ちょうどリーダーに同じ案を出したのですが、
違う単位の実績を同じ列に入れることに少し難色を示されました。
（実績単位ごとの列、テーブルを設けるという案でも同じような反応でしたが）
でも、>>239の方法が一番シンプルに
まとめられるやり方ですし、また話してみようと思います。

ありがとうございました。

241 ：NAME IS NULL：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：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：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：2008/12/21(日) 18:55:34 ID:???

SQL ServerのExpress Editionをその目的に使ったことがある。
他にもSQLiteとかSQL Server Compactがそういう目的に使える。

248 ：NAME IS NULL：2008/12/21(日) 22:12:17 ID:???

ローカルDBって、そんなのクライアントごとに固有の情報を保持するとかでもなきゃ
使わんだろ？サーバーサイドでわざわざ複数のDBに分ける理由はない。
>>246の別テーブルでというのが普通。その上で、アプリ固有の情報といっても
変更の可能性が低くて1:1あるいは1:0リレーションシップであれば1テーブルに
まとめてしまうくらい。

249 ：NAME IS NULL：2008/12/21(日) 22:26:04 ID:???

＞ところでテーブルに画面表示用のデータ入れたカラム容易したり、
＞アプリ依存の使いまわし効かないようなデータ入れたりって皆さんしてます？

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

それをやりだすと、アタマの悪い後任者が「ここにこのデータがあるから、コレ使えばいいじゃん。
オレ賢い！」と勘違いして、データベースの基本の「One Fact In One Place」の
理念がパーになる。そして黒歴史が始まる。

250 ：NAME IS NULL：2008/12/22(月) 09:50:29 ID:???

一時表ならよくね？

251 ：NAME IS NULL：2008/12/22(月) 13:24:18 ID:???

表示順とかどうすか

252 ：NAME IS NULL：2008/12/22(月) 19:20:00 ID:7uJOOUG4

一覧ソート用とか

253 ：NAME IS NULL：2008/12/22(月) 22:32:50 ID:???

>>249
まともなドキュメントが作られてない or 作られていても後任の教育ができていない場合なら
そういうのも考えられるけれども、まぁ、設計の問題というより組織の問題だな。

254 ：NAME IS NULL：2008/12/23(火) 08:06:38 ID:???

現実問題、組織の問題を言い出すと、外注丸投げや派遣ばっかなご時勢で
マトモなドキュメントやら教育云々なんて絵空事だよなぁ････。

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

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

「○○が出来ていれば」なんて絵に描いた餅なんて食べられないよ。

255 ：NAME IS NULL：2008/12/23(火) 10:52:22 ID:???

手元にあるのはERDと現物のDBのみ、
カラムのコメントは歯抜けだらけ、
アプリの仕様書もない状態。

「このアプリの仕様を踏襲した新システムを作れ」
見えないルールを予測するエスパーたち。
誰かが言った。
「DBがシステムそのものだ」と。
そんな事判ってる。
ならせめて、そのDBの利用ルールを網羅した仕様書を用意しておいてくれ。

256 ：NAME IS NULL：2008/12/23(火) 12:28:52 ID:???

>>244の
＞画面表示用のデータ入れたカラム
＞アプリ依存の使いまわし効かないようなデータ
ってそれぞれ具体的にどんなの？

257 ：NAME IS NULL：2008/12/23(火) 12:43:34 ID:???

だから表示順なんかどうすか？と。

258 ：NAME IS NULL：2008/12/23(火) 12:45:18 ID:???

表示順は無いとどうしようも無い場合も有るから
要・不要を語る意味が無いと思う

259 ：NAME IS NULL：2008/12/23(火) 14:18:21 ID:???

要・不要の観点で誰も話してないと思うよ。

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

で、この依存したデータたちをどう扱うべきかって流れかと。

260 ：NAME IS NULL：2008/12/23(火) 14:19:04 ID:???

じゃあ>>244への回答は
「してまーす」でいいわけね。

他にいい方法ないもんですかねー。

261 ：NAME IS NULL：2008/12/23(火) 15:04:28 ID:???

>>259
よくわからん。
マスタとかを別とすれば基本的にテーブル自体アプリ依存とかだと思うけど。
将来有るか無いかわからない他のアプリでの再利用とかまで考えるのがおかしな話だと思う。

262 ：NAME IS NULL：2008/12/23(火) 19:32:27 ID:???

ユーザーや端末依存の情報は他のテーブルと区別している。
他のテーブルと結合させないで、専用のクラスや関数でラップして読み書きさせてる。
たまたま、同じデータベースに同居しているというイメージ。
パラメータ系のテーブルもこれに倣っている。

263 ：NAME IS NULL：2008/12/23(火) 22:58:50 ID:???

>>261
特定アプリだけの専用DBなら、画面プログラマがO/Rマッパで生成するDBで充分だろう。

業務システムの場合、組織・人・商品のような共通データを一元化するべきだから、
きちんとDB設計することが重要になる。

264 ：NAME IS NULL：2008/12/23(火) 23:05:50 ID:???

>>263
＞マスタとかを別とすれば

265 ：NAME IS NULL：2008/12/23(火) 23:37:10 ID:???

>>264
マスタは不変の固定情報だけにしないと、時系列のデータを扱った時に矛盾してしまう。
例えば人の場合、生年月日はマスタ上の固定データで良いとして、
配属情報なんかは日々のトランザクションの中にあるわけで、
これを例えば、社員マスタに所属部署の列なんかを作って、常に最新の配属情報で
上書きしたら、そのテーブルは今日のデータとしてしか使えないし、兼務情報も得られない。
実際、いろんなアプリで共通に使うデータの多くがトランザクション上にあるから、
やはり特定アプリの表示用データなんかをDBに置くことには危険がともなう。

266 ：NAME IS NULL：2008/12/23(火) 23:46:23 ID:???

マスターテーブルにカラムを追加するのは問題だが
特定のアプリ用の独立したテーブルを作るのはいいんじゃないか

267 ：NAME IS NULL：2008/12/23(火) 23:50:02 ID:???

だね。
スキーマ分けて権限で制御とかなら分かるけど
DBに置いちゃダメってのは行きすぎだと思う。

268 ：NAME IS NULL：2008/12/24(水) 00:32:17 ID:???

＞特定のアプリ用の独立したテーブルを作るのはいいんじゃないか

それこそDB上に保持する理由が解らんな。
テンポラリテーブルやＰＣのローカル上に落として好き勝手やるならともかく。

269 ：NAME IS NULL：2008/12/24(水) 00:35:15 ID:???

思いつきなんだけど、hsqldbやfirebird,h2,oracle liteなんかの組込DBを、
今議題になってる各アプリ専用のDBとして、
基幹系DBと独立させる設計はどうだろう？
今、業務で扱ってるDBが監査用の設定が入ってて、
DDLとか大量検索が走ると警告メールが部署内に飛び交うんで、
あんま基幹系DBのスキーマを弄りたくない空気があるんだよね。

270 ：NAME IS NULL：2008/12/24(水) 05:35:01 ID:???

>>268
テンポラリテーブルやローカルDBじゃセッション間、クライアント間で共有できないだろ。
もしかして、そういう共有する必要のあるデータは全部「アプリ依存」じゃないと考えているとか？

271 ：NAME IS NULL：2008/12/26(金) 07:15:53 ID:???

>>270
クライアント間で共有と言う時点でその設計が糞だと言ういい証明なワケだが。

272 ：NAME IS NULL：2008/12/26(金) 19:39:01 ID:???

でもニーズとしてはクライアント間で共有したいって言われるのは自然。
そこでばっさり切り捨ててあいつ使えないなと思われるか、何か工夫してあげてあいつ神と必要な人間に評価されるかは、これからの正社員リストラで生き残れる分かれ目だったり。

組織の運営上は、きちんとマニュアル整備して、誰でもマニュアル通りに対応する体制にしてないと、監査も通らないし危機管理上もマズい。
情報やノウハウを属人化させてるから、退職だので、前任者居なく成ったとたんに困るんだよ。

273 ：NAME IS NULL：2008/12/26(金) 23:15:51 ID:???

「特定のアプリ用のデータ＝共有の必要が無いデータ」で
「共有が必要だとすると設計がクソ」か。

またとんでもない決め付け厨が現れたもんだ。

274 ：NAME IS NULL：2008/12/26(金) 23:33:33 ID:???

学生かなんかなのだろう

275 ：NAME IS NULL：2008/12/27(土) 01:05:33 ID:???

>>272
具体的にどんなニーズなんだろう。
なんかエンジニアが実力不足を言い訳で乗り切ろうとしているだけにしか見えんが。

276 ：NAME IS NULL：2008/12/27(土) 01:09:34 ID:???

実力があれば、共有すべきデータをローカルのみに保持してても何とかなるらしいｗ

277 ：NAME IS NULL：2008/12/27(土) 03:32:10 ID:???

ちょっとわかった。
「特定のアプリ用のデータはローカルに置け」といってる人の言う「特定のアプリ」とは
「ローカルPC上からDBにアクセスして、個人的に何かをするツール」的なもののみを指してるに違いない。
それだと話が通る（というか噛み合わない理由がわかる）

そのツールだけで使うデータであり、ツールはその人以外誰も使わないのであれば
データをサーバーに置くべきでは無いわなｗ

278 ：NAME IS NULL：2008/12/27(土) 03:41:57 ID:???

特定のアプリの位置づけ、それが扱うデータ

これがわからなければ議論はできない

279 ：NAME IS NULL：2008/12/27(土) 09:14:51 ID:???

なんかここの一部の人は具体例をださずに話をするのが好きだよなー。
会社の宿題をここで解決してるのがバレるのが嫌なんだろうか。

仮に前に話題に上った「特定アプリの表示用データ」なんか、
ほとんどの場合は共有するモンでもないと思うが、
「共用データをＤＢに置くオレカッコイイ、オレ神だぜ」と言うケースは
具体的になんなんだろう？と激しく疑問だったりする。

280 ：NAME IS NULL：2008/12/27(土) 10:24:55 ID:???

まあ特定アプリが何なのか詳細が分からないからなんとも。

281 ：NAME IS NULL：2008/12/27(土) 10:46:01 ID:???

ローカルって、端末PCのことを言ってたの？
オレはてっきり、Web/Appサーバに軽量DBMSかXMLか何かでUI層絡みの
データを置くのを、DBサーバに対して（Web/Appサーバの）ローカルと言ってると
思ってたんだが

282 ：NAME IS NULL：2008/12/27(土) 15:59:13 ID:???

>>279
逆に共用データをみんなが個別に端末に保存して
「オレカッコイイ、オレ神だぜ」って具体例を挙げてくれやｗ

283 ：NAME IS NULL：2008/12/28(日) 02:28:30 ID:???

>>281
それはローカルとはいわないと思う。

284 ：NAME IS NULL：2008/12/28(日) 02:53:39 ID:???

毎日一回しか更新しなくていいけど量が膨大なデータとか？
業務アプリならその手のデータがほとんどかもしれない。過去１０年分ぐらいのデータなんてほとんど更新される事も無いし。
後はアイテム数膨大なアプリとか。１０万アイテムぐらいならいちいちオンラインでネット上をばんばんデ－タ流すよりも、ローカルにキャッシュして差分更新で扱ったほうが快適かもしれない。

285 ：244：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：2008/12/29(月) 03:02:11 ID:???

表現が悪い意味で「いい加減」「アバウト」なひとは気を付けてね
いくら良い設計しても、プログラマーに伝わらなければデスマの元だよ

287 ：NAME IS NULL：2008/12/29(月) 03:05:44 ID:???

>>285
そういうことは>>256-257辺りで早く言えｗ

288 ：NAME IS NULL：2008/12/29(月) 17:10:41 ID:???

商品開発支援システムは直接オラクルにアクセスしてるのではなくて、販売管理システムか、生産管理システムにアクセスしてるとか？
統合して全部オラクルで共用データも含めて情報持っても良さそうだが。

システム付け足すのは簡単だっただろうけど、管理大変でしょ。あちこちにデータベース有って全部違うし。
そのうち経営情報システムとかで横断的に情報欲しい時にどこにデータが有るか探すの大変で嵌まると思うｗｗｗ

289 ：NAME IS NULL：2008/12/29(月) 17:27:30 ID:???

業務ごとにDB立ててバラバラに情報持ち出して結びつけるキーも無くて
「なんとか統合してくれ」的なプロジェクトに参加したことがあるなー。
他社のDBの情報を利用するとか止むを得ない事情でも無ければ
分けたくないところ。

290 ：NAME IS NULL：2008/12/29(月) 21:43:14 ID:???

285は一見きれいに作られてる風だけど、
>>288-289の言うとおりシステム統合とかで大変な感じ。
DB鯖にアプリ専用Tableが一番いいんじゃないかね。

291 ：NAME IS NULL：2008/12/30(火) 05:43:43 ID:???

teenage sex ってかんじ

292 ：NAME IS NULL：2008/12/31(水) 11:18:09 ID:???

そしてshotgun marriageに至と。
とりあえずシステムできちゃったから面倒見ろよと。

293 ：NAME IS NULL：2009/01/05(月) 02:31:06 ID:???

teenage sex って耳年増みたいな意味じゃなかったっけ？
理想論にかぶれて運用しにくい建付けにしたりってことかと。

でも最近のteenage sexは意味が違ってるよな確かに・・・

294 ：NAME IS NULL：2009/01/07(水) 19:10:01 ID:???

http://www.dotup.org/uploda/www.dotup.org4920.jpg

データーベースとはこのように設計するものなのか

295 ：NAME IS NULL：2009/01/12(月) 16:24:21 ID:???

該当スレがわからないんですけどたぶんSQLスレじゃないと思うのでここで質問を。
例えで書籍のDBがあるとして書籍テーブルと著作者テーブルを著作者IDでつなげていたのですが
共著のものがでてきて今のままだと対処方法がわからなくなりました。
いちおう新たにテーブルを作って書籍IDと著作者IDを持たせ
本A＝著作者A、本A＝著作者Bの2レコードで表現できるようではあるのですが、
書籍テーブルとかぶって大半が無駄なように思えます。
他にうまいやりかたはあるのでしょうか。

296 ：NAME IS NULL：2009/01/12(月) 16:41:45 ID:???

大概の場合は結果的にそれが一番無駄のない設計になる。

297 ：NAME IS NULL：2009/01/12(月) 16:59:02 ID:???

そういうものなんですか。
ではこのやりかたで進めようと思います。
ありがとうございました。

298 ：NAME IS NULL：2009/01/12(月) 16:59:37 ID:???

一般的な多対多の解決法だね。
どうしてもっていうなら、追加するテーブルは「2人目以降のみを管理する」ことにすればレコード数は減るかもしれないけど
お勧めはしない

299 ：NAME IS NULL：2009/01/12(月) 17:44:39 ID:???

>>295
新たに作るっていうかそもそも「著作者テーブル」がそれじゃないの？

300 ：NAME IS NULL：2009/01/12(月) 18:19:42 ID:???

著作者テーブルは書籍IDを含まないでしょう、多分。

301 ：NAME IS NULL：2009/01/12(月) 18:36:34 ID:???

>>295
言い忘れていたけど、仮に>>295の解決策をとるのであれば
書籍テーブルにあった著作者IDのカラムは削除した方が良い。
「書籍テーブルとかぶって大半が無駄なように」と書いてあった
ので一応補足します。

302 ：NAME IS NULL：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：2009/01/16(金) 23:33:46 ID:???

>>303
それが295だ。ちゃんと流れを読め。

305 ：NAME IS NULL：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：2009/01/17(土) 02:01:07 ID:???

>>305-306
だめだこりゃ

308 ：NAME IS NULL：2009/01/17(土) 02:10:59 ID:???

どうだめか言ってもらえると

309 ：NAME IS NULL：2009/01/17(土) 02:51:42 ID:???

14 ：すずめちゃん(四国地方) [] ：2009/01/17(土) 00:55:57.15 ID:fadPh4uo (2/17)

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

日付のところ2008年になってるのがちらほらある
http://mj.dip.jp/jlab-beer/s/test1232112051347.jpg

310 ：NAME IS NULL：2009/01/17(土) 02:52:15 ID:???

>>309
この設計ってどうよ。

311 ：NAME IS NULL：2009/01/17(土) 12:44:39 ID:???

>>309
どういうことなん？これ

312 ：NAME IS NULL：2009/01/17(土) 13:16:26 ID:???

>309
登録年月日と変更年月日が同一のデータばっかりってな話？

313 ：NAME IS NULL：2009/01/17(土) 13:18:50 ID:???

あー判った。
「変更年月日 < 登録年月日」のデータが存在するって話か。
例えば、「顧客コード」が 000020 のレコード。

314 ：NAME IS NULL：2009/01/17(土) 13:20:04 ID:???

つーか、初っ端のレコードからそーなってるなw

315 ：NAME IS NULL：2009/01/17(土) 16:43:09 ID:???

で何のデータなの？これ

316 ：NAME IS NULL：2009/01/17(土) 23:26:13 ID:???

SQL（MySQL、PsotgreやMSなど特定RDBMSではなく標準的なSQL）と
DB構築に関する基礎を学ぶのにお勧めの書籍・サイトないでしょうか。

317 ：NAME IS NULL：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：2009/01/19(月) 15:43:47 ID:???

Dateの標準SQLガイドがDate先生の辛口も読めて勉強になるけど高いよね・・・

320 ：NAME IS NULL：2009/01/30(金) 17:33:52 ID:???

このチンカス設計クセーぞｗｗｗ
全部舐めとれよ。

321 ：NAME IS NULL：2009/03/08(日) 18:49:29 ID:???

スレチと言われたんでこっちで。

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

いずれにせよ、第1正規形でないものは本来のリレーショナルモデルとは言えない
という意味において、それがモデリングの問題であることには違いはないということと、
スキーマだけ見てそれが正規形かそうでないか議論することはナンセンスであると
いう点では>>46に同意するけど。

322 ：NAME IS NULL：2009/03/08(日) 18:54:43 ID:???

で？

323 ：NAME IS NULL：2009/03/08(日) 19:54:16 ID:???

>>321
第一正規形が異質な点はその通りだと思います。
以下雑談なのでちょっとくだけた言い方になりますが、私は恩師の指導が
珍妙とくしゅだったせいか、リレーションがあまり好みではありません。
所詮は関数を実装したり表現したりする方法の一つだよね、その程度です。
なので入れ子リレーションも多値関数や高階関数ですね、そうですか、
良いんじゃない？ぐらいの認識です。

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

ただあのスレでがっかりだったのが、ただ「勉強しろ」「正規化しろ」という
コメントが続いた事です。
ちょっとひどいと思ったので>>13と>>15のスキーマを示して「データベース
理論的にどう異なりますか」と聞いてみたら「正規化について基礎から勉強
しなおそう」と返されました。おぉ～い、もう正規形だよｗ
他方で誰もデータ設計については言い出さなかったので、あのような流れに
なりました。

324 ：NAME IS NULL：2009/03/08(日) 21:21:26 ID:???

向こうで言えない愚痴を言いたいだけならスレチ

325 ：NAME IS NULL：2009/03/08(日) 22:16:22 ID:???

>>324
愚痴の部分は申し訳ない。

326 ：NAME IS NULL：2009/03/08(日) 23:05:05 ID:???

>>321
Javaとかのオブジェクト指向な言語で、
dogクラスはanimalクラスを継承して、って学習のネタで言われるなんだろうけど、
実務で使うケースとかフレームワークが既に決まっている場合とかだと、
それらを考慮してＤＢ設計した方がみんなが幸せになれるので、
2chでああいった質問ってほとんど意味ないとｵﾓ。

327 ：NAME IS NULL：2009/03/09(月) 02:17:57 ID:???

>>324
向こうで設計の話を延々と続けたら確かにスレ違いだが、そこでの回答が
ひどかったと言うのにスレ違いもなにもないじゃん。
言ってることはむこうの「正規化勉強しろ」ってレスと変わらんわけだし。

それにしても、この板でCOBOLerを馬鹿にする人は多いけど、こういう
話題を振っても反応がそのCOBOLerと同じなんだから笑ってしまうよな。

328 ：NAME IS NULL：2009/03/09(月) 22:27:26 ID:???

とCOBOLerが申しております。

329 ：NAME IS NULL：2009/03/11(水) 17:55:10 ID:???

>>321
私には面白かったです。
2chでこんな話が読めるとは思いませんでした。
これからも時々、何か書いてくれるとうれしいです。
自分はまだよくわかってないので、勉強します。

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

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

ベンチャー社長で技術者で
http://el.jibun.atmarkit.co.jp/g1sys/

330 ：NAME IS NULL：2009/03/12(木) 01:41:39 ID:???

>>329
>カリー化という言葉を、DB板で見るとは思いませんでした。

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

あとその連載、読んでます
DB畑の人間としては納得出来るところが多いです。

331 ：NAME IS NULL：2009/03/15(日) 00:44:22 ID:???

>>330
>あとその連載、読んでます
>DB畑の人間としては納得出来るところが多いです。

あぁ、それまだやってるんだ。
大規模システムを知らない人風だったから読むの止めてまった。

332 ：NAME IS NULL：2009/03/19(木) 12:40:57 ID:???

中学の図書館で簡単な読書感想文DB作ることになったんだけど

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

この２つをできるようにしたいんだけど、みなさんならどんなテーブル用意します？
１テーブルでいいのかな・・・？学生数は300人程です

333 ：NAME IS NULL：2009/03/19(木) 14:16:14 ID:???

何を管理したいかによるかな。

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

こういったところは >>332でないと分からん。

334 ：NAME IS NULL：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：2009/03/19(木) 16:02:58 ID:???

著者テーブルと
本テーブル作って
両者の関連で本著者にしないのはなんで？

336 ：NAME IS NULL：2009/03/19(木) 18:01:14 ID:???

実際作るとめんどくさだと思う。がんがれ。

この辺とかノウハウ持ってる気がする。
http://pc11.2ch.net/test/read.cgi/db/1137309494/
成績管理システムを作ろう！２【社会貢献】

337 ：NAME IS NULL：2009/03/19(木) 18:36:40 ID:???

>>334
横からですが、妥当なテーブル構造だと思います。

338 ：NAME IS NULL：2009/03/19(木) 19:24:09 ID:???

横からですが、読書感想文DBというアプリケーション自体に
興味あります。

実際に学内で何のためにどう使うのかなかなか想像が
難しい。学生名から感想文引っ張るのは何となく用途が
想像出来ますが、著者から感想文の集合を引っ張るのは
はて？と。
同じ著者の本を読んだ学生間で感想文の読み比べでも
するのかな。

339 ：334：2009/03/19(木) 21:26:21 ID:???

>>335
本のデータの入力時に著者が同一人物か同姓同名かどうかは分からない(調べないだろう)から。

>>337
ありがとうございます。

340 ：NAME IS NULL：2009/03/19(木) 22:24:07 ID:???

>>339
なんで著者に限って同姓同名を許容するの？
同名の本や同名の学生は区別してるのに。
ましてや>>332の要件で著者から検索することが挙げられてるんだから
全く違う人が書いた本を一緒くたに表示するより
○○△△という著者は2人見つかりましたとかして選択させる方が良いだろうに。

341 ：334：2009/03/19(木) 23:17:28 ID:???

>>340
私の場合、基となるデータを感想文(本のタイトル、著者名、日付、題名、クラス、出席番号、学生名, 本文)だけと想定したためです。

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

参照する側としては、確かに区別してくれていた方がより便利ですよね。

342 ：NAME IS NULL：2009/03/19(木) 23:40:26 ID:???

分けるコストもたいしたことがないので分けちゃって良いと思うけど。

343 ：NAME IS NULL：2009/03/20(金) 22:56:04 ID:???

DBの話とはズレるけど著者名かぶっちゃっていいのかな。
俺が「夏目漱石」名義で本を出したり。

344 ：NAME IS NULL：2009/03/21(土) 03:02:54 ID:???

時期的にペンネーム変えたりとかも有るしねえ。

345 ：NAME IS NULL：2009/03/22(日) 03:17:18 ID:???

>>343,344
それは、著作者と中の人の関係をどう管理するかの問題だな

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

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

まあ、今回のは著作者やその著作（本）を管理するのが目的じゃないし、
著作者に対してそこまでシビアに考える必要はないと思うが

346 ：NAME IS NULL：2009/03/22(日) 04:20:01 ID:???

著者からタイトルの時に苦労すると思うが。

347 ：NAME IS NULL：2009/03/22(日) 04:32:51 ID:???

>>346
それがあるかどうかって事だろ

348 ：NAME IS NULL：2009/03/22(日) 06:27:09 ID:???

ペンネーム変えたら別著者だろ
著者単位で考えればいいのに変に人間単位で考えるなよ

349 ：NAME IS NULL：2009/03/22(日) 19:20:58 ID:???

入力する人間が
「この本を書いた山田太郎さんとこの本を書いた山田太郎さんは同一なのか」
ってのをいちいち調査しなきゃならん、ってのもな。
300人の中学校の読書感想文管理でそんなのいらんだろ。

350 ：NAME IS NULL：2009/03/22(日) 20:05:19 ID:???

そこまで言うなら、DBなんていらんがなーw

351 ：NAME IS NULL：2009/03/22(日) 20:15:43 ID:???

かといって、同じ著者名がずらっと並んでるのもどうかと思うが。

352 ：NAME IS NULL：2009/03/22(日) 20:16:57 ID:???

うわ、極論厨…

353 ：NAME IS NULL：2009/03/22(日) 20:28:06 ID:???

何か行ったり来たりだな。スレが無駄に伸びる

354 ：NAME IS NULL：2009/03/22(日) 20:32:40 ID:???

あー>>352は>>350あて

355 ：NAME IS NULL：2009/03/22(日) 21:07:11 ID:???

やはり仕様がないとしようがないよ

356 ：NAME IS NULL：2009/03/22(日) 21:47:55 ID:???

>>355
はいはい面白い面白い、と

357 ：NAME IS NULL：2009/03/23(月) 03:52:28 ID:???

>>351
同じ著者名がずらっと並んでるってのはどういう事態を想定してるんだ？

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

たとえば夏目漱石という著者がいたとして、
夏目漱石の著作としてみとめられてる本があったとする
その本の著作者は「夏目漱石」として認識してるのだから
その本を実際に書いたのが、猫の人だろうが>343の人だろうがゴーストライターだろうが、
その本の著作者は「夏目漱石」で何の問題があるんだ？

358 ：NAME IS NULL：2009/03/23(月) 05:57:45 ID:???

暑苦しいよ。
結局仕様次第でしょ。

359 ：NAME IS NULL：2009/03/23(月) 08:17:40 ID:???

>>357
著者名を真の著者ごとに区別するって話に誤解してないか？
同じ名前の別人を区別するかしないかって話だと思ってたけど

360 ：NAME IS NULL：2009/03/23(月) 09:07:07 ID:???

>>359
それはそれで余計ややこしくなりそうな…

361 ：NAME IS NULL：2009/03/23(月) 12:30:07 ID:???

前者だと思ってたってこと？
後者は区別しないほうがややこしいと思うが

362 ：NAME IS NULL：2009/03/23(月) 12:36:54 ID:???

中学の図書館での運用だから管理するのは大人だとしても運用するのは中学生だろ
複雑にしすぎても最後はグダグダになるからある程度シンプルにした方がトラブルの
原因が少なくなると思うんだけどね

363 ：NAME IS NULL：2009/03/23(月) 12:40:57 ID:???

つまりどの方法がいいと？

364 ：NAME IS NULL：2009/03/23(月) 15:28:35 ID:???

>>362
>中学の図書館での運用だから管理するのは大人だとしても運用するのは中学生だろ

いやだから仕様を勝手読みしても仕方がないかと。
そんなことは>>332には全く書いていないしそれ抜きにどっちが
良いも悪いもないというか>>332はどこいったんだこんちくしょう。

365 ：NAME IS NULL：2009/03/23(月) 15:31:56 ID:???

与えられた仕様の断片を用いて議論するのが楽しいんじゃないか

366 ：NAME IS NULL：2009/03/23(月) 19:42:27 ID:???

>>359
後者の同じ名前の別人、てのは、同じ著作者名で別人がいるってことだろう
前者も後者も同じことで、区別する必要がないんじゃないか、と思うが

断片での議論は楽しいが結論は出せんのがなぁｗ

367 ：NAME IS NULL：2009/03/23(月) 20:51:41 ID:???

区別する必要がないってなんで？

368 ：NAME IS NULL：2009/03/23(月) 20:59:56 ID:???

区別出来るように作ったスキーマを使って運用としては区別しない
のは簡単だけど、一度区別しないことを前提としてスキーマ作って
あとから区別出来るようにして下さいと言われると面倒くさい。

なので区別することを前提に作る方が後々都合が良いと思う。
どうせ大した手間じゃないでしょう。

369 ：NAME IS NULL：2009/03/23(月) 21:32:37 ID:???

つっても夏目漱石Aと夏目漱石Bを区別するためには
「夏目漱石Aが書いた本一覧」と「夏目漱石Bが書いた本一覧」をデータとして持つ必要があって。
全書籍・全著者についてそういったデータを持つかっつーと絶対やらないだろ。
感想文にはISBNを必ず記入すること、とかの方が現実的か。

370 ：NAME IS NULL：2009/03/23(月) 22:04:26 ID:???

>>369
>「夏目漱石Aが書いた本一覧」と「夏目漱石Bが書いた本一覧」をデータとして持つ必要があって。

371 ：NAME IS NULL：2009/03/23(月) 22:05:34 ID:???

やるのが当然だろ

372 ：NAME IS NULL：2009/03/23(月) 22:53:47 ID:???

>>371
当然の意味が分からん

373 ：NAME IS NULL：2009/03/23(月) 23:01:59 ID:???

で、>>332氏は？

374 ：NAME IS NULL：2009/03/23(月) 23:26:12 ID:???

>>371
全書籍・全著者って、感想文が提出されたものに限った話じゃないよ。
（提出された分だけ持ってても登録時に識別の役に立たない）

375 ：NAME IS NULL：2009/03/24(火) 03:46:27 ID:???

ISBNが現実的だな。
ISBNで管理して、著者名とタイトルは、ISBNから紐付けるべき。

376 ：NAME IS NULL：2009/03/24(火) 06:58:31 ID:???

>>374
感想文が提出されたものだけでいいじゃん

377 ：NAME IS NULL：2009/03/24(火) 07:39:41 ID:???

>>376
提出の度に毎回調べて登録するんですね。分かります

378 ：NAME IS NULL：2009/03/24(火) 09:21:51 ID:???

提出の度にデータ作成作業する気なのか？

379 ：NAME IS NULL：2009/03/24(火) 09:41:17 ID:???

だからそこまで手間をかけて識別しないと困るほど
同姓同名の著作者が同一著作者じゃまずいのか？

そもそも同姓同名の別人な著作物なんてそんなにあるのかね

380 ：NAME IS NULL：2009/03/24(火) 11:44:54 ID:???

著作者はIDで管理すりゃいいべ
IDから名前がひけるけど同じ名前の人だっている。
普通にやればこうなる

381 ：NAME IS NULL：2009/03/24(火) 15:03:11 ID:???

同姓同名だと同じと見なす訳だな。

382 ：NAME IS NULL：2009/03/24(火) 15:56:12 ID:???

amazonで「坂本千尋」の本を探すと明らかに2人いるのがわかる。
最初は「こんな本も出してるのか、この人」とか思ってしまったぜ

383 ：NAME IS NULL：2009/03/24(火) 16:27:22 ID:???

思ったんだけど、学生の名前を主キーに使っていいと主張しているのは、実は
名前を隠した332当人だけなんじゃないか？

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

No.1335 ／懼懼｀ヽ ... - コピペ運動会
http://copipe.cureblack.com/copipe/2008/03/17/1335

384 ：NAME IS NULL：2009/03/24(火) 20:56:21 ID:???

>>383帰れ

385 ：NAME IS NULL：2009/03/24(火) 22:46:07 ID:???

メルビル守衛乙

386 ：NAME IS NULL：2009/03/25(水) 02:52:05 ID:???

>>383
学生の名前を主キーにしていいと主張してるひとって誰だ？
学生は同姓同名でも区別する必要があるってのは共通認識だと思ってたんだが

387 ：NAME IS NULL：2009/03/25(水) 05:02:04 ID:???

図書館なんだから図書館DBの著者マスタを使えばいいんじゃね？

388 ：NAME IS NULL：2009/03/25(水) 19:32:39 ID:???

そういうのが存在していて、かつ連携できるとなれば全く話が変わってくるな

389 ：NAME IS NULL：2009/03/25(水) 21:25:51 ID:???

図書館で使うのはおkだか、授業や研究で使うなら別ライセンスだろう。

390 ：NAME IS NULL：2009/03/25(水) 21:34:25 ID:???

図書館のサービスだろｊｋ

391 ：NAME IS NULL：2009/03/26(木) 00:28:03 ID:???

おまえら、質問してる（＝作る）人間のスキル考えろよｗ
この程度でテーブルレイアウト丸投げするるような初心者がつくるんだから、
なるべく単純な要件ですました方がいいだろう、と
だから著作者の同姓同名なんて無視しといたら良いんじゃないかと言ってるんだ

392 ：NAME IS NULL：2009/03/26(木) 01:53:44 ID:???

そんなことしたら余計仕様と機能と運用が混乱するだろ

393 ：NAME IS NULL：2009/03/26(木) 02:15:45 ID:???

結局は使いにくいって、全部やり直しに成るのがヲチ。
おまいらが毎度デスマってるいつものパターンじゃないか。

394 ：NAME IS NULL：2009/03/27(金) 00:12:25 ID:???

もうExcelでいいよ

395 ：名無し募集中。。。：2009/03/27(金) 00:25:42 ID:ZRXm0Q5j

ExcelでいいならせめてAccessだろ
Excelの方が逆に接続とかめんどいわ

396 ：NAME IS NULL：2009/03/27(金) 08:10:03 ID:???

Excelのテーブルってことだろw

397 ：NAME IS NULL：2009/03/27(金) 08:50:24 ID:???

だとしたらもはやDB設計すら語って無いじゃないか

398 ：NAME IS NULL：2009/03/27(金) 11:41:15 ID:???

自転車置場の議論 - bkブログ
http://0xcc.net/blog/archives/000135.html

399 ：NAME IS NULL：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：2009/04/01(水) 01:13:13 ID:???

>>399
> 未選択の時、列に格納すべきはNULLでしょうか、0でしょうか
どちらでも。自分が後で集計するときに使いやすい方を選べばいい。
(IS NULL を使わなくて済むから)自分なら 0 を使う。

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

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

単純なシステムの場合は、
入力時と出力時にどんな SQL を書かなきゃいけないかだけを考えて作れば良いよ。
少々間違えたって、すぐ直せるし。

401 ：NAME IS NULL：2009/04/01(水) 01:17:22 ID:???

俺だったら未選択はレコード挿入しないな
回答はtextにして数字と文字列を区別せず扱えば？

402 ：NAME IS NULL：2009/04/01(水) 04:41:09 ID:???

>>401
意味が分からない…

403 ：NAME IS NULL：2009/04/01(水) 05:46:34 ID:???

>>399
アンケートの相手が事前に分かってるかとかにもよるんだが、俺なら
アンケートそのものに未回答のもの=NULL
アンケートに回答して、その設問に答えてないもの=0
かな

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

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

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

>>401
未選択はレコード作らない、って考え方はありだとおもうが、
単一項目に複数の意味合いのデータを入れるのはDB設計としては間違ってるとおもうぞ

404 ：NAME IS NULL：2009/04/01(水) 08:53:40 ID:???

同じ意味合いじゃん

405 ：NAME IS NULL：2009/04/01(水) 10:57:37 ID:???

＞回答はtextにして数字と文字列を区別せず扱えば？
の話だろ。

未選択時レコード作らないのは参照時に面倒だと思うよ。
もし取得できなければ○○、取得できた場合1なら□□、とか。

406 ：NAME IS NULL：2009/04/01(水) 13:12:46 ID:???

同意。
NULLは積極的に使うものではない。

407 ：NAME IS NULL：2009/04/01(水) 13:25:52 ID:???

>DBによっては

Oracleの批判はやめてください

408 ：403：2009/04/01(水) 13:58:23 ID:???

>>404
すまん、何と何が同じ意味だと？

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

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

まあ、個人的には俺のOracleに対する、ほとんど唯一にして最大の不満点だがなｗ

409 ：NAME IS NULL：2009/04/01(水) 14:29:10 ID:???

2chにおいての、”～の批判はやめてください”ってのは
特定しましたと同じ意味しかないだろうに。

410 ：NAME IS NULL：2009/04/01(水) 15:27:12 ID:???

>>408
>すまん、何と何が同じ意味だと？
一番最後の行
>俺も面倒だと思うんで項目にNULLでレコード作る方がいいと思うんだが
何が面倒なの？
未選択時に○○，とか場合わけする必要性が分からない
合計数や平均を取る際にそのまま集計すればいいのでは？

411 ：403：2009/04/01(水) 16:17:54 ID:???

>>410
>単一項目に複数の意味合いの
ってところか
たしかに広い意味では回答という同じ意味なんだが
たとえば、”はい”、”いいえ”、””（無回答）とかならいいんだが
数字とその他の文字による回答になると、数字はコード化された回答、文字はコード化されてない回答、となる

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

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

たとえばこの結果を表示するアプリを作るとして、未選択時は特別な表示を要求されるかもしれないだろ
SQLのみの世界で見ればあんまり大差はないとおもう

412 ：NAME IS NULL：2009/04/02(木) 00:00:15 ID:???

Oracle以外からRDBに入った人にとっては、Oracleのあの文字列の扱いには殺意が沸くわな。

413 ：NAME IS NULL：2009/04/02(木) 00:30:43 ID:???

まぁでもあれでいいんじゃね
MySQLやSQL ServerはDB側になんでも任せられるから
それによってクソ重い設計とかできちゃうけど
OracleやPostgreSQLはそういうのやりづらい感じになってる

414 ：NAME IS NULL：2009/04/02(木) 06:26:34 ID:???

>>413
DBに任せることができて、任せると設計が重くなる例ってのが想像つかん
たとえばどういうことをDBに任せるとどう重くなるのだ？

415 ：NAME IS NULL：2009/04/02(木) 07:21:11 ID:???

「Oracleなら仕方ないか、アプリで実装するか」的な
ノリは漏れは嫌いなんだけどな。

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

「普通に設計」させれ。

416 ：NAME IS NULL：2009/04/02(木) 07:52:28 ID:???

>>414
クライアントよりサーバーに負担がかかるってことだろ

417 ：NAME IS NULL：2009/04/02(木) 08:56:01 ID:???

>>416
なるほど。つまり、DBで処理するかアプリで処理するか、って問題か
DB設計段階で、元来DBですべき処理をアプリでするってのは本末転倒な気はする
性能設計って話もあるんだが、負荷軽減は運用に入ってチューニングと合わせて検討すべき内容だと思うなぁ

418 ：NAME IS NULL：2009/04/02(木) 12:23:34 ID:???

文字列加工とかの話だろ
Oracleとかそういうのショボいからアプリ側でやらんと駄目だしね

419 ：NAME IS NULL：2009/04/02(木) 13:10:13 ID:???

なんでそんなものをDBでやらなきゃいかんのだ。

420 ：NAME IS NULL：2009/04/02(木) 16:08:53 ID:???

DBあるのにデータ加工をなんでアプリでやらなきゃならんのだ？

421 ：NAME IS NULL：2009/04/02(木) 16:50:50 ID:???

データ絞り込みならともかく加工でその文句は・・・ｗ

422 ：NAME IS NULL：2009/04/02(木) 17:13:37 ID:???

加工までDBなのかよ。
どんだけ言語使えないのｗｗｗ

423 ：NAME IS NULL：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：2009/04/02(木) 19:39:21 ID:???

加工じゃねぇだろ、それw

425 ：NAME IS NULL：2009/04/02(木) 19:45:40 ID:???

まあ場合によるんじゃないの？

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

ソースは忘れた

426 ：NAME IS NULL：2009/04/02(木) 23:46:00 ID:???

ニコ動の開発者インタビューみたいなので、そんな話見たな。
まあ確かにAJAX系ではselect結果をxmlにしたら、
あとはクライアント側でどうぞという感じではある。

427 ：NAME IS NULL：2009/04/04(土) 07:20:07 ID:???

時と場合によるがOracleの場合は文字列加工にケチつけてるヤツは少ないのでは？

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

同じフォーマットでデータをinsertしても、selectするとOracleだけが判定結果がおかしいからな。

428 ：NAME IS NULL：2009/04/04(土) 12:16:25 ID:???

そんなんchar型だとどのDBでもあることだしなぁ。
そもそも必須だと言ってるのに空文字入れられちゃうのもどうかと。

429 ：NAME IS NULL：2009/04/04(土) 16:11:42 ID:???

単にオラクル想定の設計をしてなかったってだけじゃないの？
スキル低いだけの様な。

430 ：NAME IS NULL：2009/04/04(土) 18:16:23 ID:???

たしかに「オラクルに対応するスキル」が低いといえるな
オラクルはRDBMSの世界ではかなりスタンダードかもしれないが
問題は、オラクルにだけ特別必要なスキルがあるってことなんだと気付けよ

431 ：NAME IS NULL：2009/04/04(土) 18:49:08 ID:???

オラクルには対応できませんって断る勇気も必要。

432 ：NAME IS NULL：2009/04/05(日) 00:24:18 ID:???

オラクルのゴールドとかプラチナとかの資格は
うんこ取扱師乙種とか甲種って名前に変更するべきだと思うんよ

433 ：NAME IS NULL：2009/04/05(日) 00:26:33 ID:???

お前は小学生か

434 ：NAME IS NULL：2009/04/05(日) 00:39:54 ID:???

だってあれもうDBの勉強じゃなくてうんこを安全に扱うための勉強じゃん・・・

435 ：NAME IS NULL：2009/04/05(日) 03:47:24 ID:???

昔はOracle最高だったんだけど
レガシーな仕様を引きずりすぎて今に至ってる部分があるから
あれはあれで仕方ないんだよ
COBOLみたいなもんだ

436 ：NAME IS NULL：2009/04/05(日) 07:13:05 ID:???

レガシーを引き継いでいる分にはDB2はOracleに負けてない気がするが、
DB2は伝統的な記述しか許さない思想の性か、ちゃんとselectできるわけだが。

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

最新のバージョンは多少世間(?)に歩み寄っている感があるが昔のバージョンの
結合の構文から見てキモいんだが。普通にLEFT OUTER JOINとか書かせろと。

437 ：NAME IS NULL：2009/04/05(日) 07:17:07 ID:???

9iから使えるだろ>LEFT OUTER JOIN

438 ：NAME IS NULL：2009/04/05(日) 10:17:38 ID:???

FULL OUTER JOINにバグがあって怖くて使わなかったな＜9i

439 ：NAME IS NULL：2009/04/05(日) 10:20:12 ID:???

スレ違いネタで無知をさらす

440 ：NAME IS NULL：2009/04/05(日) 15:45:17 ID:???

オラクル雑談スレが落ちてるからな。

441 ：NAME IS NULL：2009/04/05(日) 19:58:52 ID:???

こっちで代用すんなｗ

442 ：NAME IS NULL：2009/04/05(日) 22:11:19 ID:???

漏れのとこはOracle8が動いていますが、なにも。ｗ

443 ：NAME IS NULL：2009/04/06(月) 00:16:23 ID:???

8iじゃないのか。乙。

444 ：NAME IS NULL：2009/04/06(月) 06:19:24 ID:???

8iってなにｗ

445 ：NAME IS NULL：2009/04/06(月) 06:32:13 ID:???

Linuxでまともに動くようになったOracleの最初のバージョン
Javaと融合してインターネットサイトで使いやすくなった

446 ：NAME IS NULL：2009/04/06(月) 13:41:18 ID:???

具体的なバージョンは忘れたが、８のどっかのバージョン以降だな
とにかく８の初期のころと分けて8iと呼ばれた
iはインターネットのiだったらしい

447 ：NAME IS NULL：2009/04/06(月) 13:56:07 ID:???

8.1.5以降がi
それまでWindows版しかGUIインストーラなかった

448 ：NAME IS NULL：2009/04/07(火) 05:16:05 ID:???

むしろCUIインスコがデフォ。

449 ：NAME IS NULL：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：2009/04/09(木) 21:52:29 ID:???

accessスレで聞いたら？
って、この板には無くてビジネスsoft板の方なんだな。

451 ：NAME IS NULL：2009/04/10(金) 00:02:55 ID:???

Accessだと大勢で使うのは厳しいけど、MySQLを使えば数百人規模でも問題ない？

452 ：NAME IS NULL：2009/04/10(金) 00:09:17 ID:???

数百人どころか超大手サイトでも問題ない

453 ：NAME IS NULL：2009/04/10(金) 00:57:55 ID:???

Access は。複数人（スレッド）で使うとすぐ壊れるよ。
せめて、SQL Server Express Edition にすべき。最大4Gの制限に
引っかからなければ、だけど。

454 ：NAME IS NULL：2009/04/10(金) 06:38:27 ID:???

ってかアクセスログはテキスト出力でいいと思うけど
DBに突っ込んでくとそれがネックになって主要機能部分の性能落ちるぞ

455 ：NAME IS NULL：2009/04/10(金) 14:38:50 ID:???

Accessの上限は２G

456 ：NAME IS NULL：2009/04/10(金) 21:24:07 ID:???

ウェブベースでアクセスの選択の時点で駄目だけどな。

監視系のシステムとかだと、ネックに成ろうが、ログをDBに突っ込むけどな。
そうしないと膨大なログを処理しきれない。毎回テキストから抜くのも大変だし。

457 ：449：2009/04/10(金) 23:02:49 ID:???

MySQLなるものをはじめて知り、無料なようなのでこちらを勉強することにしました。
コマンドプロンプトっぽいところが慣れないです。
ダブルクリックですぐ中身表示みたいなのがあれば便利なのですが。
まあ使い方がわかれば余計な心配しなくてよさそうなのでひと安心です。

458 ：NAME IS NULL：2009/04/10(金) 23:12:07 ID:???

MySQL Admin入れれ

459 ：NAME IS NULL：2009/04/10(金) 23:12:47 ID:???

あとODBCでAccessと連携も出来る

460 ：NAME IS NULL：2009/04/11(土) 00:10:53 ID:???

>>458
なにそれ？

461 ：NAME IS NULL：2009/04/11(土) 01:00:17 ID:???

phpmyadmin入れれ

462 ：NAME IS NULL：2009/04/11(土) 05:35:01 ID:???

>>460
http://www.db.is.kyushu-u.ac.jp/rinkou/mysql/mysql.html

463 ：NAME IS NULL：2009/04/11(土) 12:30:16 ID:???

ほれ。

http://pc11.2ch.net/test/read.cgi/db/1227475230/
MySQL 総合 Part15
http://pc11.2ch.net/test/read.cgi/db/1056947097/
mysqlについて語ろう
http://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：2009/04/28(火) 13:22:48 ID:???

3000万件か。
趣味のレベルを超えてるな。
時間ってどれくらいかかるの？
インデックスは適切に張ってるの？

分けるなら年度毎とかかな。

466 ：NAME IS NULL：2009/04/28(火) 14:05:38 ID:???

3000万でもインデックスあればそんな困らないけど
すでにアクセスすることがめったにない昔のデータなら分けるかもなあ

467 ：NAME IS NULL：2009/04/28(火) 14:47:32 ID:???

どんなクエリを投げているのかな。
単に特定の日付の株価を検索しているのか、期間別の
平均値など集計を多用しているのか。

468 ：NAME IS NULL：2009/04/28(火) 15:29:08 ID:???

1件→3000万件で
検索時間は7倍程度って認識でおｋ？

469 ：NAME IS NULL：2009/04/28(火) 20:41:55 ID:???

>>464
OLAP、DWH、スタースキーマあたりでググるといいと思うよ。
これはSQL Server に特化した話だけど参考になると思う。
http://sqlcat.com/whitepapers_japanese/archive/2008/10/18/450.aspx

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

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

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

テーブルは月や年度でパーティショニング。

470 ：NAME IS NULL：2009/04/29(水) 00:30:43 ID:???

土日祝日はザラバ立たないから年240日として5000銘柄の25年分くらいか
システムトレードなら出来高上位1000銘柄の直近5年分程度に絞ってもよさげのような気もするけど…

471 ：NAME IS NULL：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：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：2009/05/25(月) 01:45:32 ID:???

一対多の関係テーブルを作る

475 ：NAME IS NULL：2009/05/25(月) 02:12:56 ID:???

2やったら死ねるぞ

476 ：NAME IS NULL：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：2009/05/25(月) 03:44:28 ID:???

・チェックボックスは何を選択するために使うのか。
・チェックボックスの位置が変わる可能性はあるようだけど
　数に関してはどうか。「30個くらい」で不変か。
・チェックボックスの状態をDBに格納したとして、その情報を
　どのように利用するのか。単にチェックボックスの状態を
　復帰するのに使うだけなのか、「チェックボックス1がonの
　xxxを列挙」みたいな感じで検索にも使うのか。

このあたりが分からないとにんともかんとも。

479 ：NAME IS NULL：2009/05/25(月) 04:48:15 ID:???

ただのストレージとして使いたいだけなら別に(2)でもいいんじゃね？

480 ：NAME IS NULL：2009/05/25(月) 05:10:47 ID:???

江戸時代のBIT型じゃねーんだからわざわざ2にする必要もないだろ
なんのための"R"DBMSなんだよと

481 ：NAME IS NULL：2009/05/25(月) 09:06:30 ID:???

FILLER X(30)をREDEFINESでOCCURS 30とか
なんだこのコボラー・・・

482 ：NAME IS NULL：2009/05/25(月) 09:19:31 ID:???

月次データの日付毎の有無とかだろ

483 ：NAME IS NULL：2009/05/25(月) 15:16:57 ID:???

>>478
たとえば病院の診療科（内科、小児科、外科）みたいのがズラズラと並んだ
チェックボックスで、過去受診履歴がある科のチェックがONになります。

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

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

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

情報の後出し、申し訳ないです

484 ：NAME IS NULL：2009/05/25(月) 15:18:58 ID:???

なぜ>>474はスルー？

485 ：NAME IS NULL：2009/05/25(月) 16:03:47 ID:???

バカだから理解できないんだろ

486 ：NAME IS NULL：2009/05/25(月) 16:42:55 ID:???

>>483
それくらいだったら2でいいんじゃない？
わざわざテーブル作る必要ねぇよ

487 ：NAME IS NULL：2009/05/25(月) 22:49:39 ID:???

>>483
その仕様ならば尚更1）以外に選択肢が見当たらないけど・・・
2)はケースをよく考えてみろ、データ崩れる可能性がある。

488 ：NAME IS NULL：2009/05/25(月) 23:10:02 ID:???

>>477
＞2)がまずい原因って何でしょう

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

>>483みたいな使い方であれば2でも大して問題ないんじゃないの。

489 ：NAME IS NULL：2009/05/25(月) 23:31:46 ID:???

>>483
いいんじゃね？2)で。
CLOBにしてXMLでデータ突っ込むようにしたら、もう一生このスレの世話になる必要はないぞ。

490 ：NAME IS NULL：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：2009/05/26(火) 07:24:41 ID:???

別に２でも良いだろ。
作り直したら、２で格納したデータを更新すれば良い。

心療科の増減でごちゃ混ぜになるほうが医療事故で怖い気がするけどな。
小児科２消滅→内科２統合→小児科３新設→内科３統合→小児科２統合
とか増減有って、履歴追えるような仕様なら結構大変だ。

492 ：NAME IS NULL：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：2009/05/26(火) 11:33:34 ID:???

「診療科毎の患者数を知りたい」なんてのは普通に出てきそうな要件だと思うが。

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

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

表示順を気にするなら診療科IDのつけ方のほうが重要だったりするけどね。。
増減があることを見越して、十分な隙間をとって採番してかないとアプリの工数が増える。

494 ：NAME IS NULL：2009/05/26(火) 19:54:01 ID:???

変更の可能性がある表示順をそのデータに依存させるなんて怖いことはせず、
表示対象と表示順を持ったテーブルを準備して、目的のテーブルとJOINして使う。
order by 句で表示順をソートすればいいんだから。

495 ：NAME IS NULL：2009/05/27(水) 07:38:26 ID:???

用途がなんであろうと2はないだろ。
2を推してる奴は>>477が自分の客だと想定しても同じことが言えるのか？
確実に将来に渡ってチェックだけを記録するだけの為に使うって保証なんてないぞ。
前提としてこれを抑えてる奴がいるが、こちらの設計思想を理解してもらえると思ってるのが甘い。

496 ：NAME IS NULL：2009/05/27(水) 14:13:45 ID:???

コボル前提なら有りな模様

497 ：NAME IS NULL：2009/05/27(水) 18:01:13 ID:???

そうやって無駄に工数増やして苦しくなるだけの様な。
簡単な事を難しく遣ろうとして、請求を水増ししようとしても客の理解は得られないぞ。

498 ：NAME IS NULL：2009/05/27(水) 18:11:08 ID:???

2の方がよっぽど面倒だと思うが…

499 ：NAME IS NULL：2009/05/27(水) 21:24:15 ID:???

何事も経験だ。
迷っているなら一度やってみるのがいいさ。

500 ：NAME IS NULL：2009/05/27(水) 21:36:34 ID:???

遡ってスレ眺めれば、473 が技術的に >>474 を思いつけないレベルであるのを理解して２でもいいんじゃないかと言ってるのがわかると思うよ。

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

客が納得いかないとか設計がどうとか言うなら、 473 に理解できるようお勧めの方法を説明してあげて。
その方が他の人もそれをネタに色々議論できるだろうし。

501 ：NAME IS NULL：2009/05/28(木) 00:17:52 ID:???

DB設計を語るスレにわざわざ相談しに来てるんだから
自分でもうすうす2の実装に疑問があるわけだろ
だったら正規化で解決する方法を学ぼうとする姿勢くらい見せてくれても

502 ：NAME IS NULL：2009/05/28(木) 13:59:35 ID:???

すいません、ここでいいのか判らないのですが教えてください。

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

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

または、ある基準さえ満たせば保存してもいいのでしょうか？

503 ：NAME IS NULL：2009/05/28(木) 14:09:59 ID:???

>>502
スレ違い
必要であれば取り扱いに注意して管理すればいいんだよ。
ここでも見てくれば。
ttp://www.kantei.go.jp/jp/it/privacy/houseika/hourituan/index.html

504 ：NAME IS NULL：2009/05/28(木) 14:11:55 ID:???

>>502
お前程度の知識でそんな事やったら絶対に漏洩する。
悪いことは言わないからやめとけ。

505 ：NAME IS NULL：2009/05/28(木) 14:47:57 ID:???

>>503
すれ違いでしたか・・すみません。
なのに答えていただいてありがとうございます！

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

有難う御座います。

すれ違いな質問をして、皆さんすみませんでした。

506 ：NAME IS NULL：2009/05/29(金) 02:03:56 ID:???

DBに直接アクセスするようなのはＮＧだろうな。
AP鯖経由ならいいんじゃねえの。
まあネット上で個人情報漏らしてるのはたまに見るけどな。

507 ：NAME IS NULL：2009/05/29(金) 02:21:30 ID:???

log.csvとかform.csvとかtoiawase.csvとかで検索するなよ
絶対だぞ

508 ：NAME IS NULL：2009/05/29(金) 03:39:09 ID:???

高いからしっかり漏れないように仕事してくれるのにな。
馬鹿な上司の居る担当が作ったサイトは使いたくないねｗｗｗ

509 ：NAME IS NULL：2009/06/09(火) 00:03:27 ID:???

コボルのデータをそのままSQLにつっこんだような
DBはまずどこから直すべきでしょうかｗ

もうどうしていいかｗ
鬱に成りそう

510 ：NAME IS NULL：2009/06/09(火) 00:46:18 ID:???

とりあえずゼロベースで、1から作るとしたらどんなDB設計するか、から考えてみたら？
既存のものありきで考えると思考が硬直化するよ。

511 ：NAME IS NULL：2009/06/09(火) 01:50:31 ID:???

>>509
まず第一正規化します。次に第二正規化します。最後に第三正規化します。

512 ：NAME IS NULL：2009/06/09(火) 05:25:12 ID:???

あんまり正規化に、こだわる必要も無いけどな。
むしろ業務フローに合わせたほうが効率的。
どうせどんどん機能付け足しで正規化崩れてくるから。

513 ：NAME IS NULL：2009/06/09(火) 11:22:25 ID:???

究極まで正規化すると実用的では無いけど
コボルベースの横長テーブルは正規化しないと実用的では無いよね

514 ：NAME IS NULL：2009/06/09(火) 11:31:47 ID:???

業務にも明るくないとほとんどメモ的うにしか使わないフィールドを
一所懸命正規化してテーブル分けたり、
逆にメモだろと思ってコード化も正規かもやらなかったフィールドが
重要なキーになったり。
もう少しDB設計に時間かけさせてくれよぉ。

515 ：NAME IS NULL：2009/06/09(火) 11:53:27 ID:???

どうせ崩れるからと最初から正規化をしないととんでもないものが出来上がるが
作った本人はどこがわるいのかわからない、さいてー

516 ：NAME IS NULL：2009/06/10(水) 23:51:32 ID:???

テーブルが全部charで記述されてます
1テーブルカラムが100列超えてます

どうやって治せばいいの？

517 ：NAME IS NULL：2009/06/11(木) 00:00:29 ID:???

>>516
全テーブルがって訳じゃなかったが、テーブル名がtable1～tableN、更にカラム名がcol1～colNというDBを見た事がある。
業務とデータと現行アプリから地道にマッピングしていった。
現行アプリのソースが無かったら、作り直し以外受けれなかった。

518 ：NAME IS NULL：2009/06/11(木) 00:59:32 ID:???

>>516
今見てみたんだが4割ぐらいのテーブルで
IDとかいうcharのカラム1個に、最大までとったvcharカラム１つ
という構成になってた。ｗ

もう俺逃げる

519 ：NAME IS NULL：2009/06/11(木) 19:57:32 ID:???

>>518
べつにそれで良ければ問題はないと思うのだが。

520 ：NAME IS NULL：2009/06/11(木) 19:59:42 ID:???

いいのかよｗ
BLOBですらないんだぞｗ

521 ：NAME IS NULL：2009/06/11(木) 21:34:32 ID:???

IDとかいうcharのカラム1個に、最大までとったvcharカラム１つという構成。
これがなにに使われているかが問題。
>>518は「なにに使われているか」の説明が欠けている。

たとえばＩＤ＋テキスト文書だったら、これでかまわんだろ。

522 ：NAME IS NULL：2009/06/11(木) 22:26:16 ID:???

そんなことでは一々書き込まないだろう。
ここはもちろん、長さ100バイトに及ばんばかりのビットの羅列だな。
それぞれが別個のフラグになっている。

523 ：NAME IS NULL：2009/06/11(木) 23:51:41 ID:???

いちいちidは要らないだろ。ruby廚でも買ってるのか？

524 ：NAME IS NULL：2009/06/11(木) 23:55:21 ID:???

>>522
長さ50バイトぐらいのデータが4000個から32000個
詰め込んでるようです。とりあえず退職願出したけど
ダメって言われて危うく軟禁されそうになったけど
トイレから逃げてきた

525 ：NAME IS NULL：2009/06/13(土) 15:02:36 ID:???

どんだけブラックだよ

526 ：NAME IS NULL：2009/06/13(土) 15:40:57 ID:???

>>524
> 長さ50バイトぐらいのデータが4000個から32000個
なんのデータなんだろう。

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

前者なら言語道断だが、後者なら納得できるもの。

527 ：NAME IS NULL：2009/06/13(土) 18:10:29 ID:???

質問があります。
各アカウントの権限の状態（アカウントAには公開、削除を、
アカウントBには公開、閲覧を許可するなど）を
保存するテーブルの作成を考えています。

はじめはカラムを

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

A 1 1 0
B 1 0 1

というように各フラグには有効/無効を1か0で格納しようと考えていたのですが、
「将来新たに権限が増えた場合、カラムを追加しないで済むテーブル構成を考えて欲しい。
今のままでは権限が増えるたびにカラムが増えてしまう」
と要望がありました。
この要望を満たすテーブル構成はどんなものがありますでしょうか。

528 ：NAME IS NULL：2009/06/13(土) 18:26:55 ID:???

>>527
アカウントごとのアクセス制限を設定するにはGRANT文を使うんじゃね
GRANT文で設定された権限の状況はSYSTABLEPERMSなどのシステムテーブルを見ればわかるし
ユーザテーブルで管理する意味がわからない

勘違いしていたらごめん

529 ：NAME IS NULL：2009/06/13(土) 18:36:44 ID:???

>>527　SYSTABLEPERMSを参照するとか

530 ：NAME IS NULL：2009/06/13(土) 19:50:48 ID:???

>>528
>>529

説明不足ですみません。
ここでいうアカウントや権限は、DBに関係する権限ではなく、
例えば、ビジネス文書の編集、公開、削除といった動作を許可するかどうか
といったものの権限を指します。

531 ：NAME IS NULL：2009/06/13(土) 20:31:15 ID:???

アカウントマスタ、権限マスタ、アカウント権限テーブル

532 ：NAME IS NULL：2009/06/13(土) 21:26:40 ID:???

>>531

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

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

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

として、
アカウントマスタ.アカウント名=アカウント権限テーブル.アカウント名
と
権限マスタ.権限名=アカウント権限テーブル.許可したい権限名
で3つのテーブルを結合する、という認識でいいのでしょうか。

533 ：NAME IS NULL：2009/06/13(土) 21:31:39 ID:???

許可したい権限だけをテーブル（アカウント権限）に突っ込むのか、
基本的にすべて突っ込むようにして、許可・拒否フラグを用意するのか、
その辺は仕様次第かな。

あと、名称を直接、ではなくて、ID でリレーションを保持するように、
ってのは、RDBMS の基本。

534 ：NAME IS NULL：2009/06/13(土) 21:53:06 ID:???

回答とアドバイスありがとうございました。
細かいところは自分でもう少し練ってみます。

535 ：NAME IS NULL：2009/06/13(土) 23:09:32 ID:???

>>533
どこの世界の基本だ？
あと「リレーション」って使い方間違えているような気がするな。
どっちの意味にしてもおかしいけど。

536 ：NAME IS NULL：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：2009/06/14(日) 10:35:12 ID:???

>>536
COBOLERはほんと害悪。
「1レコード読むだけで全部の情報が手に入って便利だろ」
「テーブル増やしたらパフォーマンス上不利」
「ちなみにNULLはオール9に置換してある」

538 ：NAME IS NULL：2009/06/14(日) 13:28:40 ID:???

COBOLERというよりは、ISAMERが害悪という意見を聞いたことがある。
まあどちらも滅んで欲しいには違いない。

539 ：NAME IS NULL：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：2009/06/14(日) 23:39:23 ID:???

540みたいなレスみるとまだまだコミュ力無しでいる奴らが多い事にびっくりする。
間違いは間違いだが、流れで把握してやりゃいいもんを・・・まぁ、それが出来ないからこんなレスするんだろうが

542 ：NAME IS NULL：2009/06/14(日) 23:40:56 ID:???

>関係＝テーブル

・・・

543 ：NAME IS NULL：2009/06/15(月) 03:04:48 ID:???

>>541
文脈から明らかな場合はいいいけど、>>533は意味不明だぞ。

544 ：NAME IS NULL：2009/06/15(月) 03:11:59 ID:???

そうか？「ID で関係を保持する」なら、普通に意味は通じると思うけどな。

545 ：NAME IS NULL：2009/06/15(月) 05:25:05 ID:???

みんなと仲良く出来ない香具師が多いのか？
仕事で嫌な事でもあったのか？

546 ：NAME IS NULL：2009/06/15(月) 06:32:15 ID:???

>>544
「てにをは」がおかしいだろ。それを無理に解釈するならば、
「IDでテーブルを保持する」でも意味が通じると思い込むことが
可能だ。

547 ：NAME IS NULL：2009/06/15(月) 07:16:31 ID:???

関係＝テーブル、ってのがわからん。

548 ：NAME IS NULL：2009/06/15(月) 07:37:51 ID:???

例えば上の例で、「アカウント名」と「権限名」には本来なんの関連もない。
この2つの値の間になんらかの対応関係があることを表現したものがリレーションであり
すなわちテーブルであるということ。

549 ：NAME IS NULL：2009/06/15(月) 07:45:10 ID:???

2行目までは理解できるけど、3行目がわからん。
「すなわち」って言われてもなぁ・・・

テーブルとテーブルの関係＝リレーションだとしたら、
テーブル != リレーションだろ。

550 ：NAME IS NULL：2009/06/15(月) 08:36:47 ID:???

テーブルとテーブルの関係じゃなくて値と値の関係。
ここで言っているのは(アカウント名,権限名)という
テーブルのこと。
このように両方の値を含むテーブルがどこかに存在
しない限り、どうやってもその寛刑を表現することは
できない。

551 ：NAME IS NULL：2009/06/15(月) 09:18:17 ID:???

正規化

552 ：NAME IS NULL：2009/06/15(月) 11:38:11 ID:???

自分に正しい知識がないのを棚に上げて
相手に「コミュ力無し」と言ってしまう奴は
DB設計なんかに関わるな

553 ：NAME IS NULL：2009/06/15(月) 12:16:53 ID:???

>>550
関係データベースモデルにおける「関係」(relation)と、
その実装である表(table)は本来別物。
数学的にもそれぞれ異なる性質を持っている。

なので安直にテーブル=リレーションと括るのはどうも。

554 ：NAME IS NULL：2009/06/15(月) 12:44:24 ID:???

確かにそうだけど、リレーショナルモデルとERモデルの区別すら
ついてなさそうな人にそこから説明してたらさらにわけわかになるような。

555 ：NAME IS NULL：2009/06/15(月) 16:22:18 ID:???

まあ職業がSEとかプログラマってやつでも
リレーションシップの意味でリレーションって言ってるのは耳にするよ

で、そういうヤツに限って、客に専門用語で喋って
理解されないのは客が無知だとか言い出す(笑)

556 ：名無し募集中。。。：2009/06/15(月) 16:56:16 ID:xNy+RduF

リレーションってテーブル同士の関連以外の意味で使わないだろ

557 ：NAME IS NULL：2009/06/15(月) 17:08:13 ID:???

まぎらわしい用語が悪いんじゃない？

558 ：NAME IS NULL：2009/06/15(月) 18:39:47 ID:???

用語の良し悪しはともかく
「IP？IPアドレスのことだろ」とか
「携帯って持ち運ぶって意味なんだけど。携帯電話って言えよ」とか
得意げに言い出すヤツはなー。

559 ：NAME IS NULL：2009/06/15(月) 19:37:02 ID:???

>>558
メールとかでIPって言う分にはスルーするが、テーブルのカラム名にXxxIpとか使い始めたときは
さすがにつっこんだわ。

560 ：NAME IS NULL：2009/06/15(月) 20:33:50 ID:???

まーでもテーブルがリレーションってのは有り得ないのは間違いないな
テーブルの関係性がリレーションだろ普通に
テーブルがリレーションなら
それの関係性はリレーションのリレーション
ってことにならないと辻妻合わない

561 ：NAME IS NULL：2009/06/15(月) 20:50:38 ID:???

リレーショナルデータベースの理論においては、「テーブルの関係性」に相当する
概念がそもそも存在しないんだよ。
あるとすれば、E-RモデルのRelationshipか、実装での FOREIGN KEY とか。

562 ：NAME IS NULL：2009/06/15(月) 22:15:06 ID:???

ウチの上司は最初に触ったWebアプリがCGIと呼ばれてたので、
以後、JavaServletでもPHPでも何でもWebアプリ＝CGIって呼んでるよ。

563 ：NAME IS NULL：2009/06/15(月) 23:04:49 ID:???

>>560

564 ：NAME IS NULL：2009/06/16(火) 00:35:27 ID:???

>>555
客に話す場合と「DB設計を語るスレ」とでは使い分けるよ

565 ：NAME IS NULL：2009/06/16(火) 01:24:11 ID:???

つまらん! おまえらの話はつまらん!

566 ：NAME IS NULL：2009/06/16(火) 03:23:04 ID:???

昔はもうちょっと面白い話出てたのに揚げ足の取り合いレベルのスレになったか。
こんなので盛り上がれてうらやましいよ

567 ：NAME IS NULL：2009/06/16(火) 03:29:00 ID:???

昔は今はとかじゃなくて
定期的におかしなのは出てきてた

568 ：NAME IS NULL：2009/06/16(火) 20:50:30 ID:???

関係(relation) R とは，属性 A1,…,An が与えられ，それぞれのドメインを D1,…,Dn とすれば，
直積 D1×D2×…×Dn の有限部分集合である．

だから、関係(relation)はテーブルと考えていい。

569 ：NAME IS NULL：2009/06/16(火) 20:53:26 ID:???

テーブルとテーブルの「関係」は関係代数おける和，差，共通，直積などの集合演算と
射影，選択，結合，商などの関係モデルの基本操作をいう。

570 ：NAME IS NULL：2009/06/16(火) 21:35:23 ID:???

実務でＤＢいじってる奴が　テーブル＝リレーション　とか言ってるのは今のところ見たこと無い。
リレーショナルモデルの学問では　テーブル＝リレーションなのかな。

だとすると、リレーショナルモデル視点とリレーショナルデータベース（の実装）視点では食い違いが出るはず。

571 ：NAME IS NULL：2009/06/16(火) 21:56:07 ID:???

誰か理論を語るスレ立てろよ

572 ：NAME IS NULL：2009/06/16(火) 22:14:45 ID:???

>>570
クエリーの結果もビューもリレーション。

573 ：NAME IS NULL：2009/06/16(火) 22:23:06 ID:???

>>572

どっち視点で？

574 ：NAME IS NULL：2009/06/16(火) 22:32:30 ID:???

あっち支店で

575 ：NAME IS NULL：2009/06/16(火) 22:34:16 ID:???

>>573
リレーショナルモデルの視点で。
リレーショナルモデルでは表形式のデータはリレーションだから。

576 ：NAME IS NULL：2009/06/16(火) 22:36:20 ID:???

>>570
実務だとそうだねぇ。それだけ現場にはキチンと理論を学んだ人がいないってことだな。
で、そういう人に限って「コボラーwwww」なんて言ってんだよな。
自分より下の存在があることを確認してないと生きていけないみたいに。

577 ：NAME IS NULL：2009/06/16(火) 22:40:39 ID:???

そんなもんだろ。
プログラミングとはちょっと勝手が違うしな。
DB専任技術者なんていないプロジェクトの方が当たり前だし（いてもインフラ系で物理設計しかやらんとか）。

578 ：NAME IS NULL：2009/06/16(火) 22:47:10 ID:???

なんでインフラが物理設計やるんだ？

579 ：NAME IS NULL：2009/06/16(火) 22:51:03 ID:???

>>575

リレーショナルデータベース視点だと、クエリーの結果もビューも演算結果。

580 ：NAME IS NULL：2009/06/16(火) 22:56:09 ID:???

>>576

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

でも圧倒的に前者が多い。他所だと違うのかもしれんけど。

581 ：NAME IS NULL：2009/06/17(水) 02:00:46 ID:???

DB専任なんてコストのかかる状況自体が好まれないからな。
出来るだけ少人数に抑えれば、それだけ儲けるし。中途半端でも兼任出来る香具師のほうが好まれてしまう罠。

DB専任は、周りに理解されてない香具師が多いのかもな。
ちゃんとSEやプログラマや上司や客とも仲良く成れよ。

582 ：NAME IS NULL：2009/06/17(水) 03:11:33 ID:???

まさかとは思うが物理設計をハード側だと思ってる奴いないか？

583 ：NAME IS NULL：2009/06/17(水) 04:20:32 ID:???

>>568
釣り?
ちゃんと丁寧に書いてある教科書ならリレーションとテーブルの
似て異なる点が書いてあると思うけど・・・

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

実際のテーブルには行に順序があったり重複があったりしますので、
「ドメインの直積の有限部分集合」という一般的なリレーションの
定義とは異なる部分も出てきます。

584 ：NAME IS NULL：2009/06/17(水) 19:44:15 ID:???

その学問上のリレーションを実装するときに、
関係を格納するテーブルを使うからリレーション＝テーブルとかいってるんじゃないのか？

585 ：NAME IS NULL：2009/06/18(木) 09:37:55 ID:???

連関エンティティのことですか？

586 ：NAME IS NULL：2009/06/18(木) 11:44:31 ID:???

なんでやねん。
リレーションは、属性間での関係のこと。

587 ：NAME IS NULL：2009/06/18(木) 15:09:19 ID:???

関係データベースの「関係」ってのはテーブル間の関係ではなくて、属性間の関係のこと
実装としてはテーブルがこれに該当する（差異はあるが）

588 ：NAME IS NULL：2009/06/18(木) 21:43:18 ID:???

>>585
エンティティとリレーションシップで考えるのはE-Rモデル。リレーショナルモデルと
イコールではない。
やっぱり混同している人は多いんだな。

589 ：NAME IS NULL：2009/06/18(木) 22:52:11 ID:???

MSのアクセスには「リレーションを設定する」とか「リレーションシップ」とかの機能があるんだよな。
アクセスのユーザーはリレーション＝テーブル間の関係＝JOINのキー設定というイメージが
ついてしまう。

590 ：NAME IS NULL：2009/06/19(金) 00:48:43 ID:???

つまりアクセス廚とそれ以外の間での話か。

591 ：NAME IS NULL：2009/06/19(金) 00:53:31 ID:???

レッテル貼り乙。
テーブルをリレーションと表記しているDBMSをいくつか挙げてくれ

592 ：NAME IS NULL：2009/06/19(金) 06:03:55 ID:???

postgresとか。

593 ：NAME IS NULL：2009/06/19(金) 12:33:46 ID:???

Accessも「リレーションシップ」であって「リレーション」じゃないんだよな。

594 ：NAME IS NULL：2009/06/19(金) 23:33:59 ID:???

http://www.microsoft.com/japan/office/previous/xp/suminaka/access/katuyo/katuyo2_1.htm

595 ：NAME IS NULL：2009/06/20(土) 02:53:32 ID:???

またAccessか!

596 ：NAME IS NULL：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：2009/06/23(火) 15:12:59 ID:???

どっちでも変わらんよ

599 ：NAME IS NULL：2009/06/23(火) 15:31:35 ID:???

ハッシュ化して比較するから、かわらんわな。

600 ：597：2009/06/23(火) 17:26:51 ID:tL+3Dp5k

ぁ、そうなんですか。

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

ソース：
http://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：2009/06/23(火) 18:12:35 ID:???

>>601
変わらない変わらないといわれてもどうせ時間がたてば
「製品コードの桁数とかコード体系変更するから」とあっさり言われるのがオチなので
最初っから製品コードなんか主キーには使わないな俺は。

603 ：NAME IS NULL：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：2009/06/23(火) 19:38:29 ID:???

varcharを主キーに使わない理由なんてないよ。
型に関係なく「なんちゃらコード」の類いはだいたい>602の理由で主キーにするのが避けるのがノウハウってだけ。
業務用件しだい(コード体系変更の場合でも古いコード体系も蓄積していく、とか)でコードをそのまま主キーにできる場合もあるし。

606 ：NAME IS NULL：2009/06/23(火) 19:41:51 ID:???

主キーはNULL不可かつ重複不可でしょ。
客先は一意だと言ってても、それが将来的に保証されることはない。（実際に食らわされたことあり）
DB内独自コード（サロゲートキーといいます）をつければ、どんな理不尽なことがあっても主キーの条件は守られる。
varcharでもいいと思うよ。ただし、後に泣くことが1%もないとは言い切れない。ただそれだけ。

607 ：NAME IS NULL：2009/06/23(火) 19:55:20 ID:???

後出しで「製品コードは後からあらためて付番するから、無い場合もある」って要件が出てきたこともあったな…
IDをプライマリにしていたからそれでも良かったんだけど、
「製品コードが無い分の納品書は製品コードで検索できない」って当たり前のことをいくら説明してもわかってくれなかったよ。

608 ：NAME IS NULL：2009/06/23(火) 20:14:06 ID:???

主キーはNULL不可かつ重複不可かつ不変であること

609 ：NAME IS NULL：2009/06/23(火) 20:44:40 ID:???

>>600
MySQLはハッシュキーをサポートしてないからね。

サロゲートキーあたりの議論は相当古くから存在していて宗教問題みたいなものなのだけど、検索してみると双方の主張を見つけらるから興味があれば調べてみるといいよ。

610 ：NAME IS NULL：2009/06/23(火) 20:51:15 ID:???

すみません嘘つきました。InnoDBはハッシュインデックスサポートしてたんだ。出直して来ます…

611 ：597：2009/06/23(火) 21:42:17 ID:tL+3Dp5k

皆様、ご回答ありがとうございます。

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

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

ありがとうございました。

612 ：NAME IS NULL：2009/06/23(火) 23:07:34 ID:???

>>606
ここまで極端だとサロゲート「厨」と言っていいレベルだな。
どうせ後で変更されるから業務分析も要件定義も意味ないと
言っているようなもん。
そもそもセマンティクスが変わってるのに「主キーの条件」だけ
守ることにどんな意味があるの。

613 ：NAME IS NULL：2009/06/23(火) 23:18:10 ID:???

同意だな。
そこまで病的に主キーに拘る理由が解らん。
サロゲートを使うのは要件次第と思うが。

アフォな要求にムリに答える事はないと思うが。
顧客に対して「はい」しか言えないエンジニアは常に痛い思いしかしない。

614 ：NAME IS NULL：2009/06/24(水) 00:12:30 ID:???

まぁ、ちゃんと意味があるサロゲートキーももちろんあるんだろうけど、
2chに書かれてる実体験てのを見てると、検討が甘かったのをなんとか
辻褄合わせようとする一種のバッドノウハウにしか思えないもんね。

615 ：NAME IS NULL：2009/06/24(水) 10:28:16 ID:???

>>600
セカンダリインデックスって何？

616 ：NAME IS NULL：2009/06/24(水) 10:47:22 ID:???

大して極端ではないと思うが。。。

「サロゲート」キーという名前が悪いかもな。
あくまで存在そのものに対する識別子は非常に有用なんだけども。

617 ：NAME IS NULL：2009/06/24(水) 11:16:07 ID:???

コンピュータだけでなく業務も含めて知識と権限があれば自然キーを主キーに出来るんだけどな。
多くの場合権限がなかったり、
業務系の深い知識が身に付くのがシステムが完成してからだったりする。
バットノウハウというより必要悪だろう。
権限も知識もないのにごり押しでキーを決めちゃって業務手順まで変えさせた挙句、
動かないシステムを作っちゃった人もいたなぁ。

618 ：NAME IS NULL：2009/06/24(水) 13:02:25 ID:???

>>616
キチンと意識して、本来のサロゲートキーとして使う分には問題ないんだけどね。
それを主キーの将来の変更が容易になるなどと考えて安易に使うのがおかしいだけで。
特に対応する自然キーが存在せず内部的な人工キーでしかレコードを特定できない
テーブルなどは、余計に注意しないとそれが何を表しているかわからないカオス
状態になりかねないからねぇ。
ID=1のレコードと2のレコードのどちらを選択すべきか、IDしか手掛かりがなければ
お手上げでしょ？

619 ：NAME IS NULL：2009/06/24(水) 13:16:09 ID:???

>>618
主キーをどうするかという全く実装上の話にすぎないで、自然キーを無くすわけじゃないよ。

620 ：NAME IS NULL：2009/06/24(水) 13:25:11 ID:???

1か2のどちらを選択すべきかってそりゃ指定された方を選択するんだろう。何言ってんだお前

621 ：NAME IS NULL：2009/06/24(水) 18:06:44 ID:???

そもそも製品コードというのはユーザのビジネスの都合で決定されるものであって
システムの都合で決定されるものではない。

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

ユーザをサポートするのがシステムの役割であって足をひぱってどうする。

622 ：NAME IS NULL：2009/06/24(水) 18:23:11 ID:???

そもそも論をぶつ人の言うことは聞かないようにしている。

623 ：NAME IS NULL：2009/06/24(水) 19:04:13 ID:???

>>621
業務のためにシステムを作ってんだったら、業務ルールが変更されたらシステム改修が
必要になるのは当たり前だと思うけどね。
改修が必要になっても費用を払ってくれないような困った顧客と付き合っているのなら
ともかく。

624 ：NAME IS NULL：2009/06/24(水) 19:21:24 ID:???

ビジネスにもシステムにも明るくにらみの効くお偉いさんがいるならいいのだけれど、
まずいないからねぇ。
外注SEに出来ることは限られる。

625 ：NAME IS NULL：2009/06/24(水) 19:21:51 ID:???

なんかすげーCOBOLちっくなのがいるなｗ

626 ：NAME IS NULL：2009/06/24(水) 20:40:47 ID:???

確かに。
「後で必要になるかもしれないから」と言って予備のカラムをたくさん
作っちゃうんだろうな。こういう人達は。

627 ：NAME IS NULL：2009/06/24(水) 20:56:01 ID:???

>>621
事前に「変わらない」という合意を得ていたのに
後から「やっぱ変えます」じゃあ費用がかかりますと言われて当然

変えちゃいけないんじゃなくて
変える可能性があるものを「変わりません」なんて言うなって話。

628 ：NAME IS NULL：2009/06/24(水) 21:18:06 ID:???

>>627
お客さんが「変わらない」と言うからなんてのはアレだな。

629 ：NAME IS NULL：2009/06/24(水) 21:39:33 ID:???

結局、顧客と上手くコミュニケがとれてない人の予防策がサロゲート信仰って気がするな。

普通にビジネスしろよ。

630 ：NAME IS NULL：2009/06/24(水) 21:56:36 ID:???

>>628
ちゃんとドキュメント書けよ、議事録残せよ。
何度か痛い目見れば、誰のためでもなく自分のためだとわかるはず。

631 ：NAME IS NULL：2009/06/24(水) 22:07:42 ID:???

>>630
話が食い違うな。
ドキュメントも書くし、議事録も残すし、顧客とコミュニケーションもとるよ。
その上で顧客の言う「製品コードは不変です」の上を行くようにしないとな。

議事録突きつけて「変わらないって言ったよね」って金を取るのもいいけどさ。

632 ：NAME IS NULL：2009/06/24(水) 22:18:58 ID:???

「上」ねぇｗ

633 ：NAME IS NULL：2009/06/24(水) 22:26:17 ID:???

主キーを自然キーにするメリットって何だろうか

634 ：NAME IS NULL：2009/06/24(水) 22:27:57 ID:???

客と合意を得た事項を「ひょっとしたら客が間違ってるかもしれないからどっちに転んでもいい実装にしておく」なんてのは馬鹿だろ。
「ひょっとしたら客が間違ってるかもしれない」をクリアにするのがあるべき姿。

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

ちゃんと「ひょっとしたら客が間違ってるかもしれない」をクリアしとけよ。

635 ：NAME IS NULL：2009/06/24(水) 22:29:47 ID:???

なんかSIerって感じだな

636 ：NAME IS NULL：2009/06/24(水) 22:33:01 ID:???

ごめん話にならないや。

637 ：NAME IS NULL：2009/06/24(水) 22:34:55 ID:???

その部分の話を顧客にちゃんとすると、
合意の上で結局サロゲートキーを持つことになるんだけどな。
言質取った議事録書いたやったーなんて態度のエンジニアは少なからずいるけど、
やっぱり煙たがられているよ。本人は賢く立ち回ってるつもりらしいけど。

638 ：NAME IS NULL：2009/06/24(水) 22:37:47 ID:???

合意の上で製品コードはキーになりません、画面はこうなります、工数はこれだけ増えますなら何の問題も無い。
勝手にいろんなケースをたくさん想像して「ああなってもこうなっても対応しとこう」みたいなヤツは出来ないヤツだよ。
本人は賢く立ち回ってるつもりらしいけど。

639 ：NAME IS NULL：2009/06/24(水) 22:38:08 ID:???

＞やっぱり煙たがられているよ。本人は賢く立ち回ってるつもりらしいけど。

実際には>>637なサロゲート厨が「現場からは煙たがられてる」に１票。

640 ：NAME IS NULL：2009/06/24(水) 22:42:00 ID:???

それは変更の可能性をあらかじめ織り込んだ設計って事で
なんも問題ないじゃん。
きちんとそういう検討をした上での結果ならいいんだよ。
ただ、全部のテーブルでそんな手間かける気にはならんだろ？

641 ：NAME IS NULL：2009/06/24(水) 22:46:42 ID:???

勝手に宇宙に存在するあらゆる可能性を考慮したテーブル設計しといてくれ

642 ：NAME IS NULL：2009/06/24(水) 22:51:29 ID:???

サロゲート信者の言っている事って、なんか変なんだよな。

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

粗悪な設計をして工数とりたいだけと違うのか？と小一時間(ry

643 ：NAME IS NULL：2009/06/25(木) 00:10:10 ID:???

単に業務を知ろうとしないエンジニアの戯れ言としか思えない。
業務知らないのに、業務に最適化された設計なんて無理なんじゃｗｗｗ

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

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

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

いざ納品してみて、業務に合ってないからシステム使えないのに、更に改修費用を請求するのも詐欺だろう。
最初の設計が甘いのが原因だし、その甘い設計で業務まで変更してユーザに迷惑かけてたら目も当てられない。最初の開発費には、業務のヒアリングや設計も含まれてるでしょ。

644 ：NAME IS NULL：2009/06/25(木) 02:18:57 ID:???

>>642
>「ここでサロゲート使う俺SUGEEE」て自慢があるのはなんとも厨房臭い。
パラノイア気味だね。だれもそんなこと言ってないよ
小一時間とか○○厨房とか2ch語の使い方、以前も見た気がする。

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

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

で、自然キーのメリットって何よ？

645 ：NAME IS NULL：2009/06/25(木) 06:15:28 ID:???

無駄な予備フィールドは要らないが、ちゃんとヒアリングしてちゃんと拡張出来る様な設計をしておくのが大事。

646 ：NAME IS NULL：2009/06/25(木) 06:18:22 ID:???

>>643
業務を知ろうとしてないという以前にヒアリング段階でアサインされるレベルに立ってない人か作り投げなんだろう。
まぁ、うまく中間取れない性質っぽいから客先出したり、企画なんか無理だろうけどね。

しかし、ほんとお前らサロゲートネタ好きだよなｗ

647 ：NAME IS NULL：2009/06/25(木) 06:27:03 ID:???

サロゲート厨はいい餌まいているんだろ。

正直、サロゲートを使うべきってヤツは大抵レベル低くてﾂﾏﾝﾈ

648 ：NAME IS NULL：2009/06/25(木) 06:39:51 ID:???

いや正直、嫌サロゲート厨もうざい。

649 ：NAME IS NULL：2009/06/25(木) 07:10:55 ID:???

本人光臨か。
自作自演が痛々しい。

650 ：NAME IS NULL：2009/06/25(木) 07:38:19 ID:???

>>644
分析も何もしないまま、サロゲートキーにしておけば後々の変更に強いから良い、
という>>606みたいなバカ設計の話をしているんだが？

651 ：NAME IS NULL：2009/06/25(木) 10:15:39 ID:???

大佐、指向性サロゲート粒子を

652 ：NAME IS NULL：2009/06/25(木) 11:02:28 ID:???

ID表示したら面白そうな流れだねえ
朝っぱらからご苦労さん

653 ：NAME IS NULL：2009/06/25(木) 20:45:13 ID:???

>>643
>製品コードでしか検索出来ない仕様
反論できなくてよっぽど悔しかったんだろうが
人の発言を勝手に「反論しやすい形」に歪めるのは感心しないな。
客からも「人の話ちゃんと聞いてます？都合のいいように曲解するのはやめてください」ってよく言われるだろ。

654 ：NAME IS NULL：2009/06/25(木) 20:48:54 ID:???

＞人の発言を勝手に「反論しやすい形」に歪めるのは感心しないな。
ここにいる連中全員だろ（笑
全体的にかみ合ってないし。

655 ：NAME IS NULL：2009/06/25(木) 20:59:28 ID:???

そういう「○○君もやりましたー」とか言う小学生みたいな逃げ方もあるのか

656 ：NAME IS NULL：2009/06/25(木) 22:16:04 ID:???

なに！？この盛り上がり方

ははーん、このスレを盛り上げたいときはサロゲートキーの話題を書き込めばいいんだ

657 ：NAME IS NULL：2009/06/25(木) 22:18:03 ID:???

猫にかつぶし
マルチスレッドスレにvolatile
DBスレにサロゲート

そろそろ満足したかい？

658 ：NAME IS NULL：2009/06/25(木) 22:36:49 ID:???

盛り上がっているのはサロゲート厨が自作自演とか頑張っているからじゃね？

659 ：NAME IS NULL：2009/06/25(木) 22:38:40 ID:???

嫌サロゲートは設計したことないんだろうな。
頭でっかちになるのもいいが、世の中は理屈だけじゃ通らないこともあるんだぜ？
客の言質が取れて金が貰えればいいってのはガキの主張だ。

660 ：NAME IS NULL：2009/06/25(木) 22:47:31 ID:???

反論できなくなると人格攻撃、って芸のない。

661 ：NAME IS NULL：2009/06/25(木) 23:04:39 ID:???

>>659
その理屈をどう通すかってのも仕事として大事だわな。
だいたい、客の言うことが信用できないというときに
それを正面から質すことができないで小手先の対応を
するような奴がそんなセリフ吐くのはおこがましいと
いうかなんというか。

662 ：NAME IS NULL：2009/06/25(木) 23:09:42 ID:???

ふつう、客はDBのテーブル構造なんかには興味はないだろ。

663 ：NAME IS NULL：2009/06/25(木) 23:11:10 ID:???

どうでもいいことならともかく
「製品コードが不変かどうか」を曖昧にしたまま設計はしないわな。
テーブル以外にも影響出まくりだし。

とかいうと
「製品コードでしか検索できない仕様がクソ」
とか見えない相手に反論始めるんだろうけど。

664 ：NAME IS NULL：2009/06/25(木) 23:31:14 ID:???

スレを見てるとこんな感じだ。

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

○その他
サロゲートを使うのは要件次第。要件をしっかりと顧客と検討し設計する。

665 ：NAME IS NULL：2009/06/25(木) 23:38:32 ID:???

>頭でっかちになるのもいいが、世の中は理屈だけじゃ通らないこともあるんだぜ？

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

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

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

ボランティア精神溢れるアマチュア精神丸出しでナニ言ってんだが。

666 ：NAME IS NULL：2009/06/25(木) 23:44:14 ID:???

ところで、
こういうケースは自然キーがいい、こういうケースはサロゲートキーのほうがいい
というのはないの？

667 ：NAME IS NULL：2009/06/26(金) 00:29:12 ID:???

「サロゲートキーに自然キーを使う」ということをやろうと思えばできる?
って、サロゲートキーって正確なところの意味は何。
正確には自然キーの対義語じゃないんじゃないの。

668 ：NAME IS NULL：2009/06/26(金) 01:02:37 ID:???

>こういうケースは自然キーがいい、こういうケースはサロゲートキーのほうがいい
>というのはないの？

業務知識とか欠如した人間が設計する時に下手にサロゲートを導入していくと、
システムが複雑になって工数がかかり、顧客からカネをブン取れて、
メンテも面倒なケースがあるので、維持コストも高くて保守費用が
高くなるから、そういう意味でメリットはあると思うが。

669 ：NAME IS NULL：2009/06/26(金) 02:24:06 ID:???

>>668
>業務知識とか欠如した人間が設計する時に下手に
であれば、サロゲートキーでも自然キーでもだめでしょ。ばかなの？

要件をしっかりと検討するのとは別の次元で、IDを主キーにするのは有用だと思うよ。

670 ：NAME IS NULL：2009/06/26(金) 02:51:12 ID:???

自然キーを主キーにするメリットってあるのだろうか

671 ：NAME IS NULL：2009/06/26(金) 04:46:20 ID:???

余分な列を減らせる、とか？

672 ：NAME IS NULL：2009/06/26(金) 06:27:29 ID:???

>>670
たいしてない。
設計者のエゴ。

673 ：NAME IS NULL：2009/06/26(金) 07:34:32 ID:???

若造なのですがサロゲートキーの場合、JOINのON句で悩むような気がします。
コメントなりなんなりに「○○で一意になる」などと書いておくのが定石なのですか？
ご批判お願いします。

674 ：NAME IS NULL：2009/06/26(金) 07:47:36 ID:???

>>673
それ逆じゃないの？
サロゲートキーは自然キーが複合キーなど技術的な理由で扱いづらい場合に
使うもので、関連のあるテーブルは当然サロゲートキーで結合するものだよ。

これまでも出てるけど、
自然キーについての十分な検討をしないままID列をつけておけばいい
といった考え方をするのがおかしいといってるわけで、
そういった考え方をしている人は否定派の脳内にしかいないように思えるんだがね。

675 ：NAME IS NULL：2009/06/26(金) 09:00:18 ID:???

顧客から提示された自然キーを無批判に主キーにしてしまうというのも
逆に肯定派の脳内にしかいないな。

676 ：NAME IS NULL：2009/06/26(金) 10:15:47 ID:???

>>675
そんなこと言っているやつは君の脳内にしかいないな

677 ：NAME IS NULL：2009/06/26(金) 10:31:01 ID:???

>>673
ON句は関係ないんじゃないかね？
SELECT * FROM foo JOIN bar ON foo.id = bar.foo_id

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

否定派（というか一人だけ？）は主キー以外のキーは存在しないと思っているのだろうか？

678 ：NAME IS NULL：2009/06/26(金) 11:43:37 ID:???

>>666
EJBやRoRといった近頃のフレームワークを使うなら人工キーが主流。
複合主キーはレガシーシステムを扱わざるを得ない場合のオプション的な扱い。

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

One fact in one placeの理念から言っても自然キーは分が悪い。
「○○コード２桁＋△△区分１桁＋・・・、で××の場合は最後２桁が９９」
のように識別子や外部キーとしては不要で、変なしがらみをもった情報が複数箇所に散らばってしまいやすい。

679 ：NAME IS NULL：2009/06/26(金) 12:35:24 ID:???

どちらでもイケる両刀遣いになってれば良い。実現手段にサロゲートの呪文しか唱えられないなら客は引く。
客の理解可能なキーの話をして理解してもらった上で、もしもの保険、サロゲートキーの話に持って行けば良い。
客は今問題になっている点を解消したい訳なんだから、あんまり未来の話(キーが変わるかも云々)をされたって嬉しくない。
フレームワークで勝手に作られる物に関してなら大して気にはしないけど。

680 ：NAME IS NULL：2009/06/26(金) 12:50:11 ID:???

あぁなるほど。オブジェクトモデルでしか考えたことがない人だったのか。
そりゃギャップがあるわ。
もしかして、「最近のフレームワーク」しか使ったことがなくて、そもそも
インピーダンスミスマッチすら意識したことがないのかもね。

681 ：NAME IS NULL：2009/06/26(金) 13:01:41 ID:???

で、自然キーを主キーにするメリットは？

682 ：NAME IS NULL：2009/06/26(金) 13:39:46 ID:???

誰かまとめて

683 ：NAME IS NULL：2009/06/26(金) 13:46:48 ID:???

>>681に答えてもらわないと、まとめる価値のあるような議論にならないな

684 ：NAME IS NULL：2009/06/26(金) 14:02:13 ID:???

主キーたる候補がある場合、それを主キーにする
自然な話だよな。だから普通にそうすればいい。それが自然キー

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

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

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

最近のフレームワークが代理キー推奨なのは、こういうアホな設計でもなんとかできるようにだな
代理キーつくった時点で、代理キーと本来の自然キーとのしがらみを増やしてることにも気づけよ

685 ：NAME IS NULL：2009/06/26(金) 14:06:16 ID:???

まずサロゲート（代替）キーという呼び方をやめた方が良い。

686 ：NAME IS NULL：2009/06/26(金) 14:06:37 ID:???

>>681
客も設計者も理解が早い。そのシステムの世界での共通語で構成されてるから。ほぼ妥当だろうしユーザレベルでの検証も可能だしアンドキュメンテッドな仕様による不都合の指摘も貰える可能性が高い。

…まとめが見てみたいからとりあえず書いてみた。

687 ：NAME IS NULL：2009/06/26(金) 14:35:04 ID:???

>>684
主キーたる候補って「○○コード２桁＋△△区分１桁＋・・・」が多数じゃね？
いくらユーザが「変わらない」と言ったって、主キーにするには弱いと思う。

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

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

688 ：NAME IS NULL：2009/06/26(金) 14:48:02 ID:???

人工キーの導入は正規化の一種といえるのではないかと思った。

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

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

そういえば正規化を理解していない人を相手にしているのと同じ感じを受ける。

689 ：NAME IS NULL：2009/06/26(金) 15:50:00 ID:???

その主キーと自然キーだけのテーブルを作るの？

690 ：NAME IS NULL：2009/06/26(金) 15:57:25 ID:???

>>689
その必要はないな。非NULLでユニークなキー（候補キー）がテーブルに２つあるでいい。

691 ：NAME IS NULL：2009/06/26(金) 17:29:16 ID:???

>>687
○○コード＋△△区分で主キー候補なら、人工キー作れば良いと思うよ
○○コードの下２桁＋△△区分の上１桁とか言い出したら設計が間違ってる

で、お前の言う
>自然キーの代わりとしてではなく、積極的に情報を指すポインタとして主キーの実装は人工キーに
ってのは、○○コードだけで主キー候補たる場合でも
○○コードを主キーにせずに人工キーを作れって主張だと理解してＯＫなのか？

692 ：NAME IS NULL：2009/06/26(金) 18:27:34 ID:???

>>691
>○○コードを主キーにせずに人工キーを作れって主張だと理解してＯＫなのか？
そうだよ。

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

それ以外で主キー候補たる自然キーって少ないよね。例えば何かあるかい？

693 ：NAME IS NULL：2009/06/26(金) 18:45:02 ID:???

複合で主キーなら人工キーつくる場合が多いな、俺なら
たけど、>いっそ全部人工キーに統一しちゃえってのはそれこそ思考停止

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

ＯＲマッピングとか前提なら話は違うのかもしれんがな

694 ：NAME IS NULL：2009/06/26(金) 19:32:36 ID:???

業務で出てくる○○コードって
「分類区分１桁＋西暦２桁＋連番２桁＋サイズ＋色」
「入学年２桁＋学科区分２桁＋連番」
のような体系になっているんだよねえ

695 ：NAME IS NULL：2009/06/26(金) 21:49:48 ID:???

厨房の宿題みたいな体系だな。

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

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

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

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

これらの関連として会員テーブル、送付先住所テーブル（愛人対策テーブルとも言うｗ）、家族テーブル、変更履歴テーブル
とかあるが、それらにサロゲートとか使っていたらウザくてしょうがない。むしろミスが増えそうだ。

696 ：NAME IS NULL：2009/06/26(金) 22:44:40 ID:???

>>695
人が扱うにはその方が都合が良いから、そのコード体系が悪いわけではない。
人かコンピュータかどちらが扱うのか、ドメインが違えば正しい解も違う。

> 連番12桁にしておいて、別カラムで保険商品コード持たせれば？
> って思ったものだけど。
それが人工キーだろw

697 ：NAME IS NULL：2009/06/26(金) 22:54:42 ID:???

695のいうサロゲートは連番なんだろう。

698 ：NAME IS NULL：2009/06/26(金) 22:57:32 ID:???

>>687
それって古のネットワーク型DBや、その焼き直しであるオブジェクトDBの考え方。
主張するのは別に悪いとは言わんが、それが当然と考えているならアレだ。

699 ：NAME IS NULL：2009/06/26(金) 23:02:17 ID:???

業務で扱っているコードなんて、担当者がコードだけみてある程度情報を判断できるように作るものだからな。

そうじゃなければただの連番になるだろうし、そうなるとコンピュータが採番するか人が採番するかの違いだけで、そりゃ人工キーだろって話よ。

700 ：NAME IS NULL：2009/06/26(金) 23:06:06 ID:???

まあDOA(笑)の人なんだね

701 ：NAME IS NULL：2009/06/26(金) 23:23:41 ID:???

かすみなんて知らないが。

702 ：NAME IS NULL：2009/06/26(金) 23:39:02 ID:???

主キーで使っているコードに意味を持たせてしまうと主キーの変更が発生しやすくなる。
そうならないように管理されているなら問題ないが、
一意性と可読性を両立するのは難しいこともあるなぁ。

703 ：NAME IS NULL：2009/06/27(土) 00:08:29 ID:???

>>687

賑わってるｗｗ

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

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

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

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

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

なんて聞くと、と正直｢大丈夫？｣とか思う。ヒアリングの結果どうすべきか（大好きなサロゲートキーを使うかどうか）判断するくらいの余裕を持とう。

704 ：NAME IS NULL：2009/06/27(土) 00:38:08 ID:???

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

>業務コードを変えて、ひも付けや関連情報を変更することを必要としてることも多いのよ。
これは完全にズレてる。

705 ：NAME IS NULL：2009/06/27(土) 00:52:22 ID:???

>>703
>でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。

だから主キーにはしない方がいいんじゃないの？
むちゃくちゃだな。

706 ：NAME IS NULL：2009/06/27(土) 01:59:25 ID:???

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

何が言いたいのかわからんw

707 ：NAME IS NULL：2009/06/27(土) 04:38:44 ID:???

>>でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。
>だから主キーにはしない方がいいんじゃないの？

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

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

なんかサロゲート厨ってなんでRDBの利点を自ら否定しているノリがあるよな。

708 ：NAME IS NULL：2009/06/27(土) 07:37:52 ID:???

議論が人工キーと意味のあるコードから構成されるキー（仮に有意キー）の選択という
のに変わってきたのかな。この話題なら興味はあるよ。

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

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

一意なキーが不要で存在しないレコードの場合は人工キーを付ける。

709 ：NAME IS NULL：2009/06/27(土) 07:40:39 ID:???

これはサロゲート圧勝な感じだぞ・・・アンチは意味がわからん。
頑張れアンチ！

710 ：NAME IS NULL：2009/06/27(土) 09:07:30 ID:???

RoRの意味無くなんでもid付ける主キー設定も馬鹿っぽくて嫌。ちゃんとした設計を放棄してるとしか思えない。
EJBのほうはシラネ。

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

現場の業務で、製品コード無しで処理している以上、製品コード無しで検索出来ないのようなのは糞システムでしょ。現場の業務のヒアリングが足りない。

711 ：NAME IS NULL：2009/06/27(土) 09:27:33 ID:???

アンチからまともな意見がでてサロ厨が「あ、なるほど」となれば議論も深まるのだけど。

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

> 現場の業務で、製品コード無しで処理している以上、製品コード無しで
> 検索出来ないのようなのは糞システムでしょ。
わけわからん。落ち着け。

712 ：NAME IS NULL：2009/06/27(土) 09:36:27 ID:???

>>707
>今まで企業がA,B,C,Dの商品を持っていて、新たにE,Fと言う
>商品を扱いだしたら、別にテーブルに内容追加するだけでは？

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

そして保険の例も下らなすぎ。
業務拡張や合併に合わせて既存の商品コードをA1,A0,B0,Xにします。
ときたらどうなる？
「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
業務コードの変更というのは起きるんだよ。

713 ：NAME IS NULL：2009/06/27(土) 09:36:29 ID:???

サロゲート厨ととオブジェクト厨は一応区別した方が良いと思うが、オブジェクト厨自身
それを混同しているところがやっぱり厨なんだよな。
オブジェクトモデリングの考え方では、オブジェクトは厳然と存在していて、それを
特定できるIDがあればよい。そもそもリレーショナルモデルと考え方が異なるから、
キーという概念やリレーションの正規化という考え方が存在しない。
問題は現実の問題領域との対応が正しいかどうか、例えば実際の商品は1つだけなのに
システム上のオブジェクトが2つになっていたりしないか、というところなんだけれども、
オブジェクト指向設計ではそれはデータモデルには表現されず、オブジェクトの
「ふるまい」によって保証されなければならない。
変更に強いと言っているのがおそらくこのためで、データモデルを大きく変えなくても
ふるまいを変えればいいジャン、と。プログラムよりデータの方が安定だとするところ
から出発するDOAとは逆の考え方になる。
これも最初に抽出したオブジェクトは安定だという前提なわけで、それがひっくりかえる
ような変更があったら同じことなんだけどね。

714 ：NAME IS NULL：2009/06/27(土) 09:44:20 ID:???

>>708
>基本的に有意キーは一意性と不変性が保障できれば主キーとして使える。
>構造もシンプルになる。
そして複合主キーにならなければ、でしょ？
なんだかなあ

>業務系のコードの場合はこの条件を満たすことが多い。
多くないでしょw

715 ：NAME IS NULL：2009/06/27(土) 09:46:41 ID:???

>>713
ユニークインデックスやユニーク制約ってしってる？

716 ：NAME IS NULL：2009/06/27(土) 09:48:55 ID:???

>>713
>変更に強いと言っているのがおそらくこのためで、データモデルを大きく変えなくても
>ふるまいを変えればいいジャン、と。プログラムよりデータの方が安定だとするところ
>から出発するDOAとは逆の考え方になる。

これだけなのに矛盾してるw
データモデルを大きく変えなくても振る舞いを変えればいいから、データの方が安定するんでしょ？
不安定な業務キーを主キーにしてしまえばデータが不安定になっちゃうのに.

717 ：NAME IS NULL：2009/06/27(土) 09:51:57 ID:???

といったところでお開きにする。くだらなかった。

718 ：NAME IS NULL：2009/06/27(土) 10:57:46 ID:???

なんか論理的な設計と物理的な設計を混同してないかな。
複合キーは避ける、ORMではID列が推奨、
とはいうのはDBMSやミドルウェアを使う上での要求や制限であるわけで、
本質的な設計が終わってから追加すればよい話なんだがね。

719 ：NAME IS NULL：2009/06/27(土) 12:40:41 ID:???

主キーって実装よりの話じゃねーの？

720 ：NAME IS NULL：2009/06/27(土) 12:49:54 ID:???

アイデンティファイアの話ならともかく、キーと言ってる時点で実装寄りの話だな。

721 ：NAME IS NULL：2009/06/27(土) 13:01:51 ID:???

>>688
>人工キーの導入は正規化
なるほど

722 ：NAME IS NULL：2009/06/27(土) 13:08:45 ID:???

主キー索引と主キー制約で違ってくるよ。前者が実装より。

723 ：NAME IS NULL：2009/06/27(土) 17:16:51 ID:???

アンチ　一人　vs　サロ厨＋その他
な構図？頑張れってアンチ！

724 ：NAME IS NULL：2009/06/27(土) 17:40:56 ID:???

>>716
「安定であるとする」というのは考えｋ他の前提であって、「安定させる」という
目的とは違うんだが。安定なコードを選択するのは分析段階の仕事であって、
仮にそれが実は安定じゃなかったといったら分析の失敗。

なぜか「業務キー」は後から変更されると決めてかかっているようだけれども、
そういう先入観に囚われていたりすると間違いやすいわけだな。逆もしかり。
というか、思い込みとしては確かに逆の方が多いと思うけど。

725 ：NAME IS NULL：2009/06/27(土) 18:14:06 ID:???

>業務拡張や合併に合わせて既存の商品コードをA1,A0,B0,Xにします。
>ときたらどうなる？

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

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

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

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

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

システムでソレを実行したら、どれほどのリスクが発生しそれらに関する修正体力がどれほど必要か
説明すれば、いくら上がヴァカでも、システムに対する理不尽な要求を撤回してくれる。

726 ：NAME IS NULL：2009/06/27(土) 18:53:23 ID:???

ごめん、もうお開きなんだわ。くだらないし

727 ：NAME IS NULL：2009/06/27(土) 18:57:42 ID:???

おつかれ、もうこなくていいよ。

728 ：NAME IS NULL：2009/06/27(土) 19:46:22 ID:???

結論
・主キーは自然キーでもサロゲートでも良い
・大事なコードが「可変か不変か」「一意か重複か」は主キー云々とは関係なく当然事前にキッチリつめておくべき
・「サロゲートキー使うから要件確認なんて適当でいいだろ」とはかありえない

729 ：NAME IS NULL：2009/06/28(日) 00:05:44 ID:???

ん？もうネタ切れか？

730 ：NAME IS NULL：2009/06/28(日) 01:00:16 ID:???

>>725
「製品コード　変更」でググってみなよ

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

731 ：NAME IS NULL：2009/06/28(日) 03:00:02 ID:???

変更されないなんて言われて真に受けて主コードにしちゃって後で困るのが、そもそもの設計ミスなんじゃないの？
そんな設計ミスで後から改修費用取るのは詐欺。金貰って喰ってるプロなら最初からちゃんと設計ぐらいしないと。

急にボールが来たとかいい訳して仕事しなかったサッカーの素人並。

732 ：NAME IS NULL：2009/06/28(日) 03:48:57 ID:???

>>731
>>728

733 ：NAME IS NULL：2009/06/28(日) 03:58:51 ID:???

また「サロゲートキーがにしたから要件は適当に聞いておけば大丈夫」厨か。
そこをちゃんと確認しとかなきゃ仮にDBが無事でもプロジェクトはボロボロだっての。

734 ：NAME IS NULL：2009/06/28(日) 04:13:17 ID:???

「製品コードは将来的に変更されませんか？」
とユーザーに尋ねたら、
「将来、変更がかかっても最小の修正ですむような設計にしてください。」
という返事が返ってくるんじゃないの？
「将来にわたって変更はありません」
とは言わないだろ。

735 ：NAME IS NULL：2009/06/28(日) 04:19:06 ID:???

キッチリと確認した結果「変更されるケースあり」と確定したんならそれでいいだろ。
曖昧なまま「どっちでもいいよ。なんせサロゲートキーを使ってるからな」がありえないって話だ。

736 ：NAME IS NULL：2009/06/28(日) 04:23:20 ID:???

>>735
それはOKなんだｗ
よくわかんねーやつだなｗｗｗ

737 ：NAME IS NULL：2009/06/28(日) 04:27:36 ID:???

>>736
いや何もおかしくないだろ。
「サロゲートキーか否か」がプロジェクトより大事な人にはわからんだろうけど。
別にこっちは「サロゲートキーを使わない」事に命をかけてるわけでもないんで。

738 ：NAME IS NULL：2009/06/28(日) 04:39:49 ID:???

またわけのわからないことを言い出したぞｗ

739 ：NAME IS NULL：2009/06/28(日) 04:43:43 ID:???

反論できなくなって逃げ回り始めたか。
そうやってワザと馬鹿のフリをしてスレを盛り上げようとしてくれてるんだろ？
わかってる、愛してるよ。

740 ：NAME IS NULL：2009/06/28(日) 04:44:22 ID:???

>>735
>曖昧なまま「どっちでもいいよ。なんせサロゲートキーを使ってるからな」がありえないって話だ。

林:　まさかとは思いますが、この「どっちでもいいよ。なんせサロゲートキーを使ってるからな厨」とは、あなたの想像上の存在にすぎないのでは
ないでしょうか。もしそうだとすれば、あなた自身が統合失調症であることに
ほぼ間違いないと思います。

741 ：NAME IS NULL：2009/06/28(日) 04:46:41 ID:???

こっちは要件を確定しろ、と言ってるのに
それに対する反論が「サロゲートキーを使え」だからな。

そんなレッテル貼りやったりネタで逃げたりしなきゃならないんだろ。

742 ：NAME IS NULL：2009/06/28(日) 04:51:37 ID:???

こっちは要件を確定した上で人工キーを使え、と言ってるのに
それに対する反論が「要件を確定しろ」だからな

743 ：NAME IS NULL：2009/06/28(日) 04:54:11 ID:???

そんな反論はしてないが。
必要だと確定して使うんなら問題ないだろ、と言ったはずだが。

そんなウソをついてまで「まだ反論できてるフリ」しなくていいよ。

744 ：NAME IS NULL：2009/06/28(日) 04:56:58 ID:???

おはよ～、まだやってたのか。
人工キーを活用するという話とサロゲートキーの話が混ざってないかい？

製品コードは有意キー（人間から見て意味のあるキー）にしたいというニーズは強いんだが、
製造と販売で盛り込みたい情報が違ってたり、世代の管理をしたいとかいろいろあるんで、
主キーは人工キーにしてバーコード化している。
と同時に製造タグコードと販売タグコードを別にふって印刷している。
タグコードは両方ともユニークではない意味のあるコード。
ひとつの考え方でいかなる場合もそうであるわけではないのだが、
枝番をふって主キーにするよりも人工キーを活用したほうがよい場合もある。

745 ：NAME IS NULL：2009/06/28(日) 05:05:18 ID:???

>>744
そんな感じだと思うよ。

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

しかしみんな朝早いなw

746 ：NAME IS NULL：2009/06/28(日) 05:06:59 ID:???

>>745
おいおい>>744は「要件を確定させ、必要だとわかった上で」「人工キーを活用した方が良い場合もある」という話だぞ。
君が全否定されてんの。

747 ：NAME IS NULL：2009/06/28(日) 05:07:49 ID:???

つか>>743は見なかったことですかｗ

748 ：NAME IS NULL：2009/06/28(日) 05:17:00 ID:???

アンチの挙げる例がアレなんだよな
A＋連番１０桁とかそんなんだもんな

749 ：NAME IS NULL：2009/06/28(日) 05:18:03 ID:???

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

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

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

>>「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
>>業務コードの変更というのは起きるんだよ。
> 単にシステム責任者が「はい」しか言わないヴァカだからじゃないのか？
「業界でコード体系を統一しよう」という大きな動きを、システム責任者ごときが「NO」と言えるか？
「システムで主キーにしちゃってるんで」って。

750 ：NAME IS NULL：2009/06/28(日) 05:55:33 ID:???

不変で一意で単一の自然キーか。。。

751 ：NAME IS NULL：2009/06/28(日) 06:47:08 ID:???

サロ厨もアンチも一部の馬鹿が極端な例とか使って変な方向に持って行ってる気がする。
アンチの方が変なの多い気もする。

752 ：NAME IS NULL：2009/06/28(日) 09:34:28 ID:???

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

銀行の支店コードが統廃合で実際変わってたね。まだ現金で給料貰ってる香具師なんだろうか。

753 ：NAME IS NULL：2009/06/28(日) 10:53:09 ID:???

なんでもいいが、お前ら名乗ってやってくれ
だれがどんな主張かわからんぞ

754 ：NAME IS NULL：2009/06/28(日) 12:15:50 ID:???

アンチは何人？ひとり？

755 ：NAME IS NULL：2009/06/28(日) 15:41:31 ID:???

アンチってのはいないだろ。
「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで

756 ：703：2009/06/28(日) 16:00:10 ID:3qHYmqKK

もしかして私、アンチサロゲにされてる？

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

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

「～な理由で不変なキーが必要です｣とか言った企業活動に必要な、明確な理由があってのサロゲートキーやら何とかキーなら理解できる。
ただ｢将来の保険｣的なものや「コードが変わっても元の構造を維持できる｣とか、でしかないなら余計な工数が必要なお粗末設計なだけ。

757 ：NAME IS NULL：2009/06/28(日) 16:08:43 ID:???

素朴な疑問
サロゲートキーをつける事で発生する「余計な工数」ってなんだ？

758 ：NAME IS NULL：2009/06/28(日) 16:10:50 ID:???

付けただけじゃ大した工数じゃなくても
「キーが変わる・重複する」事を考慮して全体を作ると結構な工数。
そこは要件をきちんと詰めて「これだけかかりますが両対応にしますか」と合意を取らなければならない。

759 ：NAME IS NULL：2009/06/28(日) 16:45:23 ID:???

>>755
>「必要かどうかを判断すべき派（中立派）」
自分ではそう思ってるんだな。
すまんが、傍観者から言わせて貰うとまったくそうは見えないぞ。

>>756
君はアンチサロゲっつーか日本語でおｋっつーか・・・

760 ：NAME IS NULL：2009/06/28(日) 16:50:24 ID:???

傍観者ｗ

761 ：NAME IS NULL：2009/06/28(日) 16:51:59 ID:???

反論できなくなると
・話をそらす
・見えない敵と戦い始める
・バレバレのウソをつく
・自演を始める

もう飽きたよサロ厨

762 ：NAME IS NULL：2009/06/28(日) 16:53:16 ID:???

「状況を判断して使うかどうか決めるべき」が中立でないとすると
「何が何でもサロゲートキーを使うべき」に同意しない人は全てアンチか。
怖いなｗ

763 ：NAME IS NULL：2009/06/28(日) 17:28:11 ID:???

サロゲート厨とはどんな人物か。

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

相手が中立であってはならない。

764 ：NAME IS NULL：2009/06/28(日) 17:48:38 ID:???

確かにサロ厨がかなり必死なスレですな。

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

中二病とおなじく「サロゲート」といいたいだけと違うのか？って希ガス。

765 ：NAME IS NULL：2009/06/28(日) 18:13:58 ID:???

>合併するなら重複が発生するだろう
>http://www.bk.mufg.jp/oshirase/tenban/furiwake.html

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

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

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

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

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

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

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

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

サロゲートの人は本気で病気だと思うからここで現実逃避してないで、
マジで精神カウンセリングを受けたほうがいいと思うよ。

766 ：NAME IS NULL：2009/06/28(日) 18:52:47 ID:???

>>765
そりゃあできるだろう。
できるかできないかではなくて、改修にかかわるコストの論議をしているんだと思うんだが。

ちがうか？

767 ：NAME IS NULL：2009/06/28(日) 19:07:04 ID:???

新しい展開がｗｗｗ

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

コストなんて末端のPGを低賃金で雇うなり、サビ残では足らせればいくらでも圧縮可能と、予算管理者や経営者は考えてる罠。
予算はサロゲートで決まるんじゃない。エクセルの上で決められている。

768 ：NAME IS NULL：2009/06/28(日) 19:21:03 ID:???

文章ヘタクソだなあ。
君の書いた要件定義書をぜひ見てみたい。

769 ：NAME IS NULL：2009/06/28(日) 19:22:50 ID:???

>>767
>　コストなんて末端のPGを低賃金で雇うなり、サビ残では足らせればいくらでも圧縮可能
あはーん、だからよくダウンするんだ。MUFGのコンピューターシステムは。

770 ：NAME IS NULL：2009/06/28(日) 19:30:38 ID:???

>>767とサロ厨で別スレつくって出て行ってくれればスッキリする。
サロ厨が何の反論も出来なくなったところに、わざわざエサをまきに来るなよ

771 ：NAME IS NULL：2009/06/28(日) 19:57:15 ID:???

いや、隔離スレがここだから。

772 ：NAME IS NULL：2009/06/28(日) 20:25:10 ID:???

本スレどこだよ。本スレはサロゲート廚来ないのか？

773 ：NAME IS NULL：2009/06/28(日) 20:26:18 ID:???

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

実際の口座テーブルの主キーは何なのでしょうか。

774 ：NAME IS NULL：2009/06/28(日) 22:52:35 ID:???

>>755
>アンチってのはいないだろ。
>「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで

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

775 ：NAME IS NULL：2009/06/28(日) 23:00:02 ID:???

>>774
ん？君も「状況を判断して使うかどうか決めるべき」って考え？

776 ：NAME IS NULL：2009/06/28(日) 23:35:45 ID:???

よせ、病気がうつるぞｗ

777 ：NAME IS NULL：2009/06/28(日) 23:52:57 ID:???

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

これがまるっきり意味分からんのだが。
誰か解読してください

778 ：NAME IS NULL：2009/06/29(月) 00:01:46 ID:???

>>765
本当にアレだな。

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

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

>全銀の世界ではすでにコードが統一されているよ。銀行のシステム担当者はこれに合わせるだけ。
>と言うかあわせないといけない。
もっと一般的な話をしたつもりなんだが。

779 ：NAME IS NULL：2009/06/29(月) 00:04:55 ID:???

必至に話をそらし中ｗ

780 ：NAME IS NULL：2009/06/29(月) 00:05:15 ID:???

どのポジションの奴も自分は頭がいいと主張しているだけだなｗ

781 ：NAME IS NULL：2009/06/29(月) 00:12:01 ID:???

>>765
>漏れはちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
当たり前だバカ。そんな話してるんじゃないよ。

どうかこの人と仕事で関わりませんように

782 ：NAME IS NULL：2009/06/29(月) 00:20:24 ID:???

>>756
>企業コードなんてのはガンガン変わるもの。その変化するコードに後生大事に不変のキーをくっつけて持ちまわすことに意味があるのか？
過去との紐付け

783 ：NAME IS NULL：2009/06/29(月) 00:26:31 ID:???

サロ厨って反論できなくなったら唐突に遡って反論可能な書き込みに対してレス始めるのなｗ

784 ：NAME IS NULL：2009/06/29(月) 00:32:19 ID:???

中立派の人に質問。
第一正規化、繰り返し項目の排除についてどう思う？
「必要かどうかを判断すべき」だったりする？

785 ：NAME IS NULL：2009/06/29(月) 00:40:13 ID:???

また露骨に話をそらして
完全に反論できなくなったのを「無かったこと」にしに来たなｗ

786 ：NAME IS NULL：2009/06/29(月) 00:44:50 ID:???

思い出した。この前のとおんなじ奴だろ。文末ｗは

787 ：NAME IS NULL：2009/06/29(月) 00:49:09 ID:???

またそういう部分で争ってうやむやにしようとするｗ

788 ：NAME IS NULL：2009/06/29(月) 00:53:28 ID:???

>>787
専スレ立てようか？
正直、サロゲネタはお腹いっぱい。

789 ：NAME IS NULL：2009/06/29(月) 00:56:29 ID:???

>>733
>>737
>>739
>>741
>>744
>>761
>>770
>>776
>>779
>>783
>>785
>>787

790 ：NAME IS NULL：2009/06/29(月) 00:56:56 ID:???

>>785
>完全に反論できなくなった
は？

791 ：NAME IS NULL：2009/06/29(月) 00:57:49 ID:???

>>788
>正直、サロゲネタはお腹いっぱい。
同意
専用スレもいらんよ

792 ：NAME IS NULL：2009/06/29(月) 00:57:55 ID:???

あ、ごめ>>744じゃなく>>743

793 ：NAME IS NULL：2009/06/29(月) 23:41:48 ID:???

結局サロゲート設定する必要無いだろ。

794 ：NAME IS NULL：2009/06/29(月) 23:56:15 ID:???

いやもうそこに触れないで

795 ：NAME IS NULL：2009/06/30(火) 00:17:18 ID:cjciCkCN

これだけ理屈の通じない人間がDB設計に関わってるんだものな

796 ：NAME IS NULL：2009/06/30(火) 00:19:30 ID:???

いや別に君を擁護してるわけでも無いから

797 ：NAME IS NULL：2009/06/30(火) 01:20:43 ID:???

偏向性サロゲート厨

798 ：NAME IS NULL：2009/06/30(火) 02:11:46 ID:???

>>793
>>795
>>797

799 ：NAME IS NULL：2009/06/30(火) 06:30:50 ID:???

結局は自称中立野郎が脳内敵を勝手に作り出して暴れていたってことでｗ

800 ：NAME IS NULL：2009/06/30(火) 12:54:48 ID:???

はい、そろそろまとめて。
サロゲートキーのメリット、デメリットと
どんな時に使うと良くて、どんな時は良くないのか。

801 ：NAME IS NULL：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：2009/06/30(火) 13:52:28 ID:???

一箇所訂正。
＞Aが自然キー、BCDがサロゲートキーでないが人工キー、
Aが自然キー、BCがサロゲートキーでないが人工キー、

私的にはABCが自然キー、Aは特に有意キーと呼んでる。

803 ：NAME IS NULL：2009/06/30(火) 14:52:20 ID:???

電話番号は変更される事も有るから、契約番号を設定してユーザ番号として利用すればサロゲートは不要。

そもそもユーザ番号を一意にすれば良いじゃないか。やっぱり設計が大事。
サロゲート廚はまともな設計が出来ないだけじゃ。

804 ：NAME IS NULL：2009/06/30(火) 14:58:37 ID:???

その一意になるユーザ番号って人工キーじゃんw

805 ：NAME IS NULL：2009/06/30(火) 15:00:59 ID:???

ほんとその意味で言えば「サロゲート派」なんて一人も居ないのに
なにを騒いでるんだか。

806 ：NAME IS NULL：2009/06/30(火) 15:04:09 ID:???

>>803
「うちの業務は電話番号で検索できればいいから、変な契約番号なんてつくりたくないんですけど。弊社の業務分析はちゃんとできてます？」
「電話番号は変更されることもある？そんな事わかってますよ。とにかく電話番号で検索できることが重要なんです！」

807 ：NAME IS NULL：2009/06/30(火) 15:09:09 ID:???

そのケースだったらBパターンだな。
つうかBもサロゲートということにしないとサロゲート派の立つ瀬がないな（笑

808 ：NAME IS NULL：2009/06/30(火) 15:16:35 ID:???

傍観してた初心者ですが、A以外はサロゲートなのかと思ってました。

809 ：NAME IS NULL：2009/06/30(火) 15:19:14 ID:???

脳内で勝手に作った「サロゲート派」と戦ってたのか。
なるほどかみ合わないわけだ。

810 ：NAME IS NULL：2009/06/30(火) 16:08:07 ID:???

>>807
>つうかBもサロゲートということにしないと
普通にサロゲートキーじゃん

811 ：808：2009/06/30(火) 17:40:06 ID:???

？？誰がホントなんですか？

812 ：NAME IS NULL：2009/06/30(火) 17:45:16 ID:???

初学者は自分で勉強しろ

813 ：NAME IS NULL：2009/06/30(火) 18:24:30 ID:???

おまえらは仕事しろ

814 ：NAME IS NULL：2009/06/30(火) 20:40:18 ID:???

>>801
サロゲートだなんだ言う前に、

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

これが適切なのかどうかはっきりさせてから設計に入るべきだね。
で、一旦これが適切だ=世帯と電話番号の関係性に変更はない、という
判断がされたのだったら、それ以降電話番号の変更の可能性を考える
必要はないわけだし。

815 ：NAME IS NULL：2009/06/30(火) 22:16:46 ID:???

>>814

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

はっきり｢想定した上で、これをシステム化する｣と書いてますから、ここでは既に｢はっきりさせて｣あると思うのですが...まだ足りないと言うことでしょうか？

816 ：NAME IS NULL：2009/06/30(火) 22:55:12 ID:???

それが適切でない合理的疑いがあるのなら、質しておくべきだね。
業務ルールとかも詳しく見てみると、人が判断してるからなんとか
回っているけどシステム的には全然つながらない、なんてのが
あったりするしね。

817 ：NAME IS NULL：2009/06/30(火) 22:55:46 ID:???

俺はA以外はサロゲート扱いだなぁ。
んで、実装はB～Dのどれかに落ち着きそう。
電話番号が変わったときに過去履歴を見るのに別にキーがあると便利そう。
もちろん顧客に電話番号以外にキーを持たせることによるメリット等を説明した上でね。

ちなみにアンチサロゲの人から言わせると俺はサロゲ厨ｗ

818 ：NAME IS NULL：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：2009/06/30(火) 23:05:02 ID:???

>>818
？？？

820 ：NAME IS NULL：2009/06/30(火) 23:06:37 ID:???

そもそも電話番号は変わると確定している物。
それを前提に話すのがおかしい

821 ：NAME IS NULL：2009/07/01(水) 00:11:48 ID:???

>>818
今日も来たんですか。ご苦労様です。

822 ：NAME IS NULL：2009/07/01(水) 00:14:48 ID:???

>>821
君の「都合が悪いレスは見えないフリ」を隠そうともしない姿勢は凄いね。

823 ：NAME IS NULL：2009/07/01(水) 00:22:25 ID:???

>>818
おれは何が何でも使え派と言ってもいいかもな。
「何が何でも」というのは語弊があるが。

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

これらをしっかり理解できれば、作業としては人工キー一択で良いと思う。

824 ：NAME IS NULL：2009/07/01(水) 00:23:11 ID:???

>>822
もういいじゃん。
そいつマジ病気なんだから。

825 ：NAME IS NULL：2009/07/01(水) 00:25:06 ID:???

>>818
だからさ、専スレ立てるかって言ってんだろうがよ。
単なる煽りか？もっと賑やかなところでやれよ。

826 ：NAME IS NULL：2009/07/01(水) 00:26:15 ID:???

ぐだぐだ言ってないでさっさと立てろよ

827 ：NAME IS NULL：2009/07/01(水) 00:27:39 ID:???

他に話題もないしいいんじゃね？

これか、「リレーションはテーブルのことだよ論争」しか話題がないじゃんw

828 ：NAME IS NULL：2009/07/01(水) 00:33:31 ID:???

まだやってたのかおまいらｗｗｗ

829 ：NAME IS NULL：2009/07/01(水) 00:36:13 ID:???

その話題になるとあの人がいついちゃうのがね…
スレが止まってもいいからその話題以外にしましょう。

830 ：NAME IS NULL：2009/07/01(水) 00:43:32 ID:???

もともと数日レス無しとかが普通なスレだしな。
レスがあるだけ今のほうがいいか、と聞かれると明らかにNo

831 ：NAME IS NULL：2009/07/01(水) 05:27:29 ID:???

なんかすっかり話題を変えられてるが、
製品番号で検索出来ないのは設計が悪いぞ。

832 ：NAME IS NULL：2009/07/01(水) 05:40:06 ID:???

常識的に考えて
それはDB設計が悪いんじゃなくてアプリの設計が悪いんだろが

製品番号で検索したらパフォーマンスが出ないってなら別だが

833 ：NAME IS NULL：2009/07/01(水) 07:44:06 ID:???

>>801はここでのサロゲートキーの定義が曖昧だからはっきりしろ言ってるわけで
話題を変えるつもりはなかったのだと思うけど、
今を思えば>>685　が慧眼だったな。
で、製品番号のテーマではA対BCDということで行くの？

834 ：NAME IS NULL：2009/07/01(水) 09:31:17 ID:???

>>831
>製品番号で検索出来ないのは設計が悪いぞ。

これがずっと気になってたんだが
>>607の「製品コードが無い分の納品書は製品コードで検索できない」
を曲解してるのか...。
なんという読解力（どっかいりょく）のなさ。
主キー（しゅきー）がどうのこうの言（い）う遥（はる）か以前（いぜん）の段階（だんかい）ですね

835 ：NAME IS NULL：2009/07/01(水) 10:19:27 ID:???

ユーザが製品コードを付けないで入力するのを要件に盛り込んでなかっただけだろ。
設計ミスだな。

836 ：NAME IS NULL：2009/07/01(水) 11:29:11 ID:???

後出し要件をどこまで避けられるかどうかだな。
キックオフまでにつぎ込めるリソースも限られた中で、全て洗い出すなんてのは前時代的な根性論か理想論か。
「全て盛り込め」という無責任な号令のもと、巨大な体を持て余して潰れていった数々のプロジェクトの屍を乗り越えて、銀の弾丸ではないものの、よりよい手法を模索していかなければならない。

837 ：NAME IS NULL：2009/07/01(水) 14:07:28 ID:???

製品コードで複数ヒットするならいったん候補画面に飛ばさなきゃならない。
製品コードが変わるかどうかでマスタメンテ画面だって変わるし
マスタに紐づく諸テーブルは製品コードを表示するために（製品コードをキーとしないなら）親からとって来なければならない。
プロジェクト全体に関わる問題。

結局のところ、「製品コードは不変としてつくるか可変としてつくるか」の合意を得なきゃ前に進めない。
「変わるかもしれないからサロゲートキーにしました」は何の解決にもなっていない。
客に何を聞いても「全ての可能性を考慮してつくってください」しか言われずそれを受け入れ、
>>836が言うような対応をするのでなければね。

838 ：NAME IS NULL：2009/07/01(水) 14:14:33 ID:???

えーと…
制約というものを知らないのかな？
マスタメンテ画面で何の項目を保守可能にするのかってのは別問題だし
通常、リソース系のテーブルは名称やら金額やらを取得するためにリンクするものだし
なにがネックで騒いでるのかよくわからん

839 ：NAME IS NULL：2009/07/01(水) 14:16:48 ID:???

>>837
>結局のところ、「製品コードは不変としてつくるか可変としてつくるか」の合意を得なきゃ前に進めない。
これはまさにその通り。しかしその合意というのがどこまで有効か。
どうにもならない政治的なこともよくあるからな。
本当に合意を出来るなら「人工キーは無駄」というのに賛同できないわけではない。

あと、親から取ってこなくても製品コードが表示できる、というのは非正規化に過ぎない。

840 ：NAME IS NULL：2009/07/01(水) 14:19:15 ID:???

>>838
勝手に条件を限定して「何の問題も無し」てのは君の悪い癖だよ。

841 ：NAME IS NULL：2009/07/01(水) 14:20:43 ID:???

いや、なんとなく
こいつ要件定義やったことねーな
的な匂いがしてねｗ

842 ：NAME IS NULL：2009/07/01(水) 14:22:44 ID:???

また例によって露骨な逃げに入ったなｗ

843 ：NAME IS NULL：2009/07/01(水) 14:26:22 ID:???

そもそも業務でいちいち製品コード決めたりしないだろ。
何か適当に作って、後から製品名とコード付けるのが普通。
単に現場知らずに設計してるだけ。現場知らないのに現場のシステム設計出来る訳が無い。

サロゲート付ければ良いってのは、現場知らなくても何とかなるって良い訳。

844 ：NAME IS NULL：2009/07/01(水) 14:33:44 ID:???

>>843
>そもそも業務でいちいち製品コード決めたりしないだろ。
え？

>何か適当に作って、後から製品名とコード付けるのが普通。
じゃあDBの主キーは全部人工キーでいいじゃんw

845 ：NAME IS NULL：2009/07/01(水) 14:37:01 ID:???

業務知らなくても云々とかいうミスリードはもうやめようぜ。
サロゲートをどうするか以前に、DB設計は業務を知らなきゃできっこないんだから。

846 ：NAME IS NULL：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：2009/07/01(水) 19:06:24 ID:???

代替キーと代理キーが混ざってない？

848 ：NAME IS NULL：2009/07/01(水) 19:57:29 ID:???

代替キーと代理キーの定義を教えてくれ

849 ：NAME IS NULL：2009/07/01(水) 21:13:25 ID:???

>>838
そういうのを本当に汎用的にやろうとすると結局、市販の「いわゆる『アプリケーション』」と
変わらないものになっちゃうんだよな。
普通の設計の感覚で見るとゲロ吐きそうな代物だ。

850 ：NAME IS NULL：2009/07/01(水) 21:29:50 ID:???

>>849
汎用的なんて後付け条件つけて勝手に批判した気になってんじゃねーよｗｗ

851 ：NAME IS NULL：2009/07/01(水) 21:41:31 ID:???

>>850
なんでオマエが批判された気になってんだw
SAPの中の人とかかい？

852 ：NAME IS NULL：2009/07/01(水) 22:00:58 ID:???

ググレ、カス

853 ：NAME IS NULL：2009/07/01(水) 22:02:12 ID:???

>>851
気づいてないのかもしれないが、君1人対全員だよ？ｗ

854 ：NAME IS NULL：2009/07/01(水) 22:03:54 ID:???

>>853
君何度もいわれてるけどホントに病気だから

855 ：NAME IS NULL：2009/07/01(水) 22:10:07 ID:???

サロゲ厨は要件定義しない厨攻撃のつぎは
SAPまで持ち出して、サロゲ厨は汎用厨攻撃ですかぁ。
大変ですねぇ。

856 ：NAME IS NULL：2009/07/02(木) 00:40:37 ID:???

サロゲ廚の言い訳が見苦しいスレだな。

857 ：NAME IS NULL：2009/07/02(木) 00:50:44 ID:???

>>848
代替キー（サロゲートキー）は主キーたる自然キーが存在しない、あるいは複合キーとなって扱いにくい場合に、別途人工的に作成するキー

代理キーは一意になる候補キーの内、主キーに選ばれなかったもの
ただし、サロゲートキーのことを代理キーと呼ぶこともある

858 ：NAME IS NULL：2009/07/02(木) 01:04:01 ID:???

自分が都合の悪いレスを無視して逃げ回っておいて何を言うんだ？

859 ：NAME IS NULL：2009/07/02(木) 06:24:43 ID:???

アンチサロゲ廚の勝利に終わったのか？

860 ：NAME IS NULL：2009/07/02(木) 06:33:08 ID:???

どこを読んだらそういう結論になるんだろう。
本当におかしい人なのかな。

861 ：NAME IS NULL：2009/07/02(木) 09:12:30 ID:???

>>859
あんたの一人勝ちだよ

862 ：NAME IS NULL：2009/07/02(木) 13:37:04 ID:???

廚って書く人は同一人物なのか

863 ：NAME IS NULL：2009/07/02(木) 13:49:08 ID:???

女のようだな

864 ：カウンセラー：2009/07/02(木) 13:50:51 ID:???

>>862-863
続けてください

865 ：NAME IS NULL：2009/07/02(木) 14:15:19 ID:???

漏れさん

866 ：NAME IS NULL：2009/07/02(木) 16:05:31 ID:8NCxXA01

くだらないこと聞きますが
例えば
・お店が一つの業種を選択できる
・一つ業種は色々なお店に選択される
このような時
お店：業種
は
一対多
というのか
多対一
どちらなのでしょうか？

867 ：NAME IS NULL：2009/07/02(木) 16:10:49 ID:???

業種1つに対してたくさんのお店が紐付くわけだから
業種１：お店多

868 ：NAME IS NULL：2009/07/02(木) 23:22:10 ID:???

>>866
なごんだ

869 ：NAME IS NULL：2009/07/02(木) 23:26:58 ID:???

>>866　
「お店が一つの業種のみ選択できる」ならば多（店）対一（業種）

870 ：NAME IS NULL：2009/07/03(金) 01:13:00 ID:???

普通はいろいろ遣ってるよね。販売もサービスも。

871 ：NAME IS NULL：2009/07/03(金) 07:43:59 ID:???

a. 運送業の会社が、陸運業・海運業を手がけている事
b. デパートが、無料梱包サービスと配送サービスを行う事
c. スーパーが、食料品と雑貨を販売している事

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

＃｢お店｣と「複数業種｣がなんかうまく釣り合いが取れなかっただけ

872 ：NAME IS NULL：2009/07/03(金) 08:02:17 ID:???

>>871
何を言っているんだ？

873 ：866：2009/07/03(金) 11:02:35 ID:???

>>867　869
ありがとうございます。
ですよね。

874 ：俺も質問の意図を把握するのに時間かかった……：2009/07/04(土) 20:58:57 ID:???

>>871
たぶん >>866 が言いたかったことは、a, b, c のどれでもないと思う。
そんな難しく考えなくても、普通に“お店テーブル”と“業種マスタ”の関係を
どう言い表せばいいのー？みたいな話かと。

「“お店テーブル” のデータ１件（つまり１つの店舗）につき、そのお店の業種を表す情報を１つだけ持つ
（つまり、１つのお店が複数業種を掛け持ちするようなケースは設計上想定していない）」ような場合、
なんて言えばいいの？って質問では？

答えは >>867、>>869 だよね。

875 ：NAME IS NULL：2009/07/04(土) 21:08:44 ID:???

あくまでも「例えば」と言ってる訳だし
聞きたかったのは概念的な話だろう。
例え話の前提条件に異を唱えてもしょうがない。

876 ：NAME IS NULL：2009/07/04(土) 22:06:11 ID:???

いやだから、お店や業種ってのは例えなんでどうでもいいんじゃないのかね

１対多や多対１の結合っていったときに
どっちが多でどっちが１か聞きたかっただけだろ

877 ：NAME IS NULL：2009/07/04(土) 22:09:02 ID:???

>>872-875のみんながそう言っていると思うが
「いやだから」とか言われても

878 ：874：2009/07/04(土) 22:48:47 ID:???

あ、えーと、なんか >>871 が >>866 の質問の文意を
理解しあぐねてるように見えたから、差し出がましく
「こういう質問がしたかったんでは？」って >>866宛に解説してみただけっス。

もうクローズした話題なんで、適当に流してくだしあ。すんません。

879 ：NAME IS NULL：2009/07/05(日) 19:29:44 ID:???

そもそも実際と違う要件で作ってしまうのが問題。
要件定義で漏れが有ると、現場で使えないシステムが出来上がるぞ。

880 ：NAME IS NULL：2009/07/05(日) 19:33:07 ID:???

無理やり荒らそうとするヤツが出てくるな

881 ：NAME IS NULL：2009/07/05(日) 20:51:14 ID:???

要件定義厨ｗ

882 ：NAME IS NULL：2009/07/05(日) 20:55:12 ID:???

それ言いたかっただけだろ。
露骨杉

883 ：871：2009/07/05(日) 22:55:19 ID:???

>>878

なんか、つまらない思いさせてしまった様で申し訳ないです。

＃おかげで｢例えば｣のかかる範囲がわかりました。

この｢例えば○○の様に｣と言われた場合、「○○」は質問する方・される方で既存の共通する認識がある実例が来る場合と、
今回の様な場合があるので...

私の読解力が足りないんです。本当に申し訳ない。

884 ：NAME IS NULL：2009/07/06(月) 09:22:33 ID:???

>>879
>要件定義で漏れが有ると、現場で使えないシステムが出来上がるぞ。
うわぁ・・・まだそんなところに居る人居るんだ

885 ：NAME IS NULL：2009/07/08(水) 00:18:17 ID:???

要件は出来あがってから真面目に聞く

886 ：NAME IS NULL：2009/07/08(水) 16:33:43 ID:???

開発部・製作部・経理部やＡコース・Ｂコース・Ｂコース(特)等
１０個以下程度の項目で、かつ項目が追加・編集される可能性のある
種別が沢山ある場合の設計は、どのようにすれば良いのでしょうか？
そのまま、下記のように記録するのは良くないとは思いますが

　名前部署コース
　------------------------
　鈴木開発部Ａコース
　佐藤開発部Ｂコース(特)
　田中製作部Ｂコース(特)

それぞれ別テーブルを作るべきなのでしょうか？

　名前部署ID コースID
　-----------
　鈴木 1 1
　佐藤 1 3
　田中 2 3

　ID 部署
　-------
　1 開発部
　2 製作部
　3 経理部

　ID コース
　-------
　1 Ａコース
　2 Ｂコース
　3 Ｂコース(特)

それとも、項目テーブルとして１つにまとめても良いものなのでしょうか？

　名前部署ID コースID
　-----------
　鈴木 1 4
　佐藤 1 6
　田中 2 6

　ID 項目
　-------
　1 開発部
　2 製作部
　3 経理部
　4 Ａコース
　5 Ｂコース
　6 Ｂコース(特)

上記のような項目が３０個位あるので、項目毎にテーブルを作るべきか迷っています。
DB設計初心者で、プロ(仕事)では無いので、聞く人がいなくて困っています。
どなたか助言をよろしくおねがいします。

887 ：NAME IS NULL：2009/07/08(水) 16:44:11 ID:???

一冊ちゃんとデータベース構築の本読めとしか。

888 ：NAME IS NULL：2009/07/08(水) 17:16:34 ID:???

部署とコースの関係がわからんから何とも

889 ：NAME IS NULL：2009/07/08(水) 20:01:38 ID:???

>>886
どんな用途で使おうと思ってる？
それでテーブルの設計は大きく変わると思う。

890 ：NAME IS NULL：2009/07/08(水) 21:29:18 ID:???

「まとめる」っていう選択肢はあまりないように思うけど。

891 ：NAME IS NULL：2009/07/08(水) 21:49:13 ID:???

>>885
そういうのありますよね。
客も実物に触れて運用してみないとわからないというのがある。

892 ：NAME IS NULL：2009/07/09(木) 01:24:51 ID:???

>>887
データベース構築の本は数冊読みましたが、大体が>>886の場合だと
部署やコース毎に項目テーブルを作るようになっています。

>>888
項目と項目の関連性はありません。

>>889
例えば、windowsの画面設定では以下のような項目がありますが
　テーマ:テーマ
　デスクトップ:背景/表示位置
　スクリーンセーバー:スクリーンセーバー
　デザイン:ウィンドウとボタン/配色/フォントサイズ
　設定:ディスプレイ/画面の色
これをユーザ毎のデータをテーブルに格納する場合
　ユーザID テーマ背景 … 画面の色
　-------------------------------------
　suzuki WindowsXP さざなみ … 32ビット
　tanaka Windowsｸﾗｯｼｯｸなし … 16ビット
となると思いますが、この時に項目毎にテーブルを作るべきか
項目テーブルみたいなのを作って、まとめるか迷っています。

>>890
そうですか。では、windowsの画面設定等ではテーマならテーマの
項目テーブル。デスクトップ背景であれば背景の項目テーブルを
作った方が良いという事ですか？

893 ：NAME IS NULL：2009/07/09(木) 08:34:42 ID:???

具体的な要件が示せないみたいだが、宿題か何かってヲチか？

894 ：NAME IS NULL：2009/07/09(木) 08:51:15 ID:???

宿題ではないです。趣味で作っているプログラムです。
具体的な要件は、かなり特殊なので、ここに書くと
かなり長くなってしまいそうです。
>>892に例えたWindowsの画面設定にかなり近いです。

895 ：NAME IS NULL：2009/07/09(木) 09:42:20 ID:???

>>886
　名前項目ID
　-----------
　鈴木 1
　鈴木 4
　佐藤 1
　佐藤 6
　田中 2
　田中 6

こういう手もあるかと。
でも、このテーブルを使ってどういう検索をかけるか判らないと何とも言えない。

896 ：NAME IS NULL：2009/07/10(金) 01:59:32 ID:???

ちゃんと要件示すか、自分で考えるかだな。

897 ：NAME IS NULL：2009/07/10(金) 22:29:18 ID:???

最初から綺麗な設計と運用方針でスタートできるなら問題ないけど
業務を理解してなかったコボラーのファイル設計がつぎはぎだらけで
グダグダなデータベースをリプレースしろって言われた俺結構
がんばって再構築してるけど、サロゲートキーは救いの神。

898 ：NAME IS NULL：2009/07/10(金) 22:30:14 ID:???

>>897
アンチが沸くからそこでストップな。

899 ：NAME IS NULL：2009/07/10(金) 22:34:07 ID:???

句読点もまともに打てない奴が

900 ：NAME IS NULL：2009/07/11(土) 04:25:10 ID:???

そいつがアンチ本人じゃん。サロゲ厨を揶揄してんのに釣られんなよw

901 ：NAME IS NULL：2009/07/11(土) 04:28:10 ID:???

>>892みたいなことがやりたいんだったら
テーブルをどうするとかよりXMLとか使った方がいい気がする

902 ：NAME IS NULL：2009/07/11(土) 05:10:01 ID:???

そういやXMLDBってどうなった？

903 ：NAME IS NULL：2009/07/11(土) 09:50:07 ID:???

つか、892のWindowsの設定云々はデータベースを使う例としては不適切に感じるが。

なんかデータベース覚えたての厨房がムリにRDBMS使いたい病にかかっている様に感じるが。

904 ：NAME IS NULL：2009/07/11(土) 10:18:29 ID:???

コボラーのためにサロゲで回避するのは本末転倒。
結局サロゲ前提の設計から抜けれない罠。

いきなりRDBじゃないと出来ない様な案件に取り組んでも失敗確実とは思う。
エクセルやアクセスで十分な程度もRDBで設計してみて、徐々にステップアップしていくのが基本かと。

905 ：NAME IS NULL：2009/07/11(土) 10:48:44 ID:???

設計とはちょっとハズれた話題になってしまうが、職場で学習を兼ねて「こういうのを作れ」とか
言われたら、Excelで作ってみて無理を感じたらAccessで作り、
Accessで無理を感じたら、SQLite3(+Python)でいいんじゃね。

そういうので要件を上手く設計に落とし込めるようになってから、
Derbyとかに手を出せばいいと思うけど。

時々、目的や規模を含めてそういのを判断できずに盲目的に
「この案件Oracle使います」とかヌカすヤツがいるからなぁ。

って漏れの組織のログ収集システムがそんな感じだ。
なぜにこんな要件でOracleと言うかRDBMSを使う必要があるのかサッパリ理解不能だ。ｗ

906 ：NAME IS NULL：2009/07/11(土) 21:38:21 ID:???

>>905
Log Perserでいいだろｗ

907 ：NAME IS NULL：2009/07/11(土) 23:09:25 ID:???

Access挟むならSQLite要らないわ

908 ：NAME IS NULL：2009/07/11(土) 23:56:21 ID:???

最初が Excel ってのはないわ。

909 ：NAME IS NULL：2009/07/12(日) 06:44:16 ID:???

全てのデータが65535以内ならExcelでもいいんじゃね？
漏れはやらないけど。ｗ

AccessとSQLiteとどっちがマシか？って話だと後者かな。
Accessだとそれこそ病気の様なリレーション組んだりしている素人見るし。

910 ：NAME IS NULL：2009/07/12(日) 09:49:03 ID:???

>>906
たしか、そのログのテーブル設計がこんなカンジだった希ガス。

日付：number
ログテキスト：vahchar(256)

で、カンマの無いcsvファイル(?)をちょい加工してインポートすると言う仕組みだった。

CLOBでいいんじゃないか？とかログの読み出し順が保障されてないとか
ツッコミどころ満載だったなぁ。

まあ一度も過去ログを見た事ないので問題になっていないだろうし、
それで多くの人が満足しているなら、それはそれでいい設計なのだろう。

911 ：NAME IS NULL：2009/07/12(日) 13:50:46 ID:???

tsvか。
なおさらoracle使う必要がねえな。
vbsで十分。

912 ：NAME IS NULL：2009/07/12(日) 15:33:29 ID:???

エクセルとかアクセスとか面倒だからオラクルで良いよ。
どうせ行き着く所はオラクル。

スキル評価でも、エクセルやアクセス使えますよりも、オラクル使えますのほうが待遇よかったり。
がんばれば簡単に出来る事でも、評価されない事は自分の評価を下げるだけ。

913 ：NAME IS NULL：2009/07/12(日) 15:39:02 ID:???

どういう現場をどさ回りしてるか目に浮かぶ

914 ：NAME IS NULL：2009/07/12(日) 17:41:31 ID:???

910を実現するためにoracleなんていれたら無能の証明だろｗ
あんな重いもんこんな用途に使うには適してない。

915 ：NAME IS NULL：2009/07/12(日) 20:48:40 ID:???

そりゃまあ、営業の数字的にはOracle使う方が客から金搾り取れるから、
ベンダーとしては評価があがるのかもしれんけどな・・・。

Oracleみたいなソフトを一度導入してしまうとサポートやらの保守とかで
かなり美味しい商売が展開できるし、「Oracle入れているなら次はコレも」
とか営業が夢語りやすいからなぁ。

社員として優秀と、エンジニアとして優秀は違うよな。

社内SEの人はベンダーがOracleって単語使い出したら気をつけろよ。ｗ

916 ：NAME IS NULL：2009/07/12(日) 20:51:39 ID:???

ベンダーって言葉、俺の中じゃOracle社とかのことなんだけど。

917 ：NAME IS NULL：2009/07/12(日) 21:07:52 ID:???

DBはなんでもできる夢の道具じゃねえぞ。
馬鹿いうのもいい加減にしろ。
システムを構築する上でひとつの要素でしかない。
oracleでしかできないことなんてほとんどない。
サポート？保守？そんな金のかかるシステムしか構築できんのか？

って言ってくれる客がいてもいいはずだ。

918 ：NAME IS NULL：2009/07/12(日) 21:42:19 ID:???

んならテメエの会社で開発汁。

と言ってみたいテストｗ

919 ：NAME IS NULL：2009/07/13(月) 23:05:32 ID:???

わかってないなあ君たちは・・・オラクルでもMSでもいいけど、
「○×のバグです。」「△□の機能では無理です。」
これで逃げられることがどれだけありがたいことか・・・

920 ：NAME IS NULL：2009/07/13(月) 23:31:20 ID:???

本質的に無理な事と逃げ口上は別モノだが。

逃げ口上で使っているならそれこそ無能の証明だろうに。

921 ：NAME IS NULL：2009/07/13(月) 23:35:30 ID:???

本当にムリだったとしても代案を出さなきゃだしな。

922 ：NAME IS NULL：2009/07/13(月) 23:43:07 ID:???

そこんところ、結果責任を追及される可能性はフリーDBMSの方が高い
ような気はするけどね。「なんでそんなもの選んだ」と。

923 ：NAME IS NULL：2009/07/14(火) 00:15:21 ID:???

そういうケースは現実にあるのか胡散臭いんだが。

むしろ、高機能なOracleとかにシフトして障害発生とかあったりするし。

たとえば、Oracleやジャーナルログの辺りの設定ミスして
トランザクションの途中でコケたりリカバリ失敗するのと、
最初からそういう概念のないシンプルなフリーDBMSやらDB2の方が
マトモに動いていた、とか。

924 ：NAME IS NULL：2009/07/14(火) 00:22:18 ID:???

>>923
まだまだあるよ。
不採用の理由は？「タダだから」
真顔で言うんだぜ？

つーかさ、2行目以降は馬鹿なだけだろ、そういう奴は逆でもやらかす。

925 ：NAME IS NULL：2009/07/14(火) 06:32:38 ID:???

＞不採用の理由は？「タダだから」

Javaが全否定ですか。
そーですか。

#別に金はらいたければ払えるけどな。

926 ：NAME IS NULL：2009/07/14(火) 07:04:58 ID:???

>>925
apacheやbindも

927 ：NAME IS NULL：2009/07/14(火) 07:08:28 ID:???

LAMP涙目ｗ

928 ：NAME IS NULL：2009/07/14(火) 07:12:31 ID:???

>>923
そういう個別の問題はまた別の話だと思うが、もしそのトラブルが責任問題に
発展するとしたら、今度は「なんでちゃんとしたところに頼まなかった」とくる
可能性はありそうやね。

929 ：NAME IS NULL：2009/07/14(火) 14:03:13 ID:???

個人情報を管理するテーブルを作ろうと思っています。

個人情報を入れるテーブル名は personal。

学校は中学、高校、大学、大学院を格納するのに
テーブルに personal.school1 ～ personal.school4 を作るのではなく、
school テーブルを用意したほうがいいですよね？
school.personal_id と personal.school_id で JOIN させるような。

住所や電話番号、メールアドレスも複数、といっても最大 2 か 3 ですが、
これも正規化してテーブルを作るべきでしょうか？

930 ：NAME IS NULL：2009/07/14(火) 15:45:05 ID:???

要件次第なのだがｗ
個人的には両方無駄だと思う。

schoolテーブルにしていいのか、collegeとかhighschoolとかいうテーブルまで作るのか、
そこまでやっても、school側の管理が単に「出てくるだけ」なら意味がほとんどない。

メールアドレスも電話番号もたくさん持っている人に対応するためには必要な話かもしれないけど、
上限が概ね見えているならちょっとの予備だけでいいように思う。

と、思った。

931 ：NAME IS NULL：2009/07/14(火) 16:06:06 ID:???

>>930
なるほど。ありがとうございます。
単に書いて読んで、くらいですｗ

一つのテーブルに

email1
email2
tel1
tel2
address1
address2
school_name1
school_name2
school_name3
school_name4

という末尾に数字の付くカラムが多いので、
正規化するべきなのかな、と疑問に思ったのです。

現在は「中学、高校、大学、大学院」ですが、
そのうち大学院後の MBA や、大学院を複数回る人がいると
school_name5, school_name6 と増える可能性とか。
でも、school_name10 までいくことはないし、
とりあえず末尾に数字でやりたいと思います。
( プログラム側の CRUD 処理は一番楽ですし )

いやいや、こうだろ、というのがありましたら大歓迎ですｗ

932 ：NAME IS NULL：2009/07/14(火) 19:24:44 ID:???

schoolテーブルがあったほうがいいと思うけどな。

933 ：NAME IS NULL：2009/07/14(火) 20:08:52 ID:???

これ何？　俺俺詐欺用のデータベースでも作るのか？

オープンソース使うと、無料で作れば良いだろうで無茶な仕様になりやすいけどな。ジャーナル機能みたいなの作ってとか、トランザクション機能も付けてとか。
オラクルとか商用ソフト使ってる分には、カスタマイズに成るのでお金が掛かりますで解決出来る。

javaはjavaそのものにはお金払ってる意識は無い。
Cやbasicやcobolに金払ってないのと同じ。有用なライブラリやフレームワークにお金出して、ちゃんと機能が使える担保を取ってるイメージ。
金無いなら、自分で全部ヤルしか無いけど、それは大変だろ。DBソフトを作るスキルは無くても、DBを作れて使いこなせれば十分。

934 ：NAME IS NULL：2009/07/14(火) 21:11:37 ID:???

どこまで正規化すべきか、なんて
テーブルの具体的な使用方法やら想定件数やら求められるパフォーマンスやらがわからないと。
聞かれてもこちらには何も判断基準が無い。

935 ：NAME IS NULL：2009/07/14(火) 21:11:45 ID:???

普通のデータベースと言うか多くのRDBMSははフリーだろうとトランザクションやジャーナルは
まずサポートしているが･･･。

と言うかそれがなきゃデータベースは名乗れないだろう。

つか本当にOracleやらPostgresやらDB2とか使ったことあるのか？

あとzやiだとCやCOBOLは普通に金かかる。
iで金がかからんのはSQLくらいだ。

936 ：NAME IS NULL：2009/07/14(火) 21:17:40 ID:???

あと、同じ大学出身の人が100人いたら100回入力させてかまわないのか、
その際ある人は「ICU」ある人は「国際基督教大学」とか表記がバラバラでかまわないのか、とか。

937 ：NAME IS NULL：2009/07/14(火) 22:50:48 ID:???

>>936
学校名の変更があったときにどうすんの？とかね。
過去の卒業生も今の校名で出ちゃだめなら、マスタには日付が必要になるし。

だから「要件次第」としかｗ

938 ：NAME IS NULL：2009/07/15(水) 08:58:02 ID:???

oracleなんだが、前任者の残したDBがやべぇ。
テーブル数大小300以上、プライマリキーは全部ナンバリング。列名は英語の略語なのかローマ字の略なのか…何を示してるのかサッパリわからん。
テキストのメモ書き程度の説明書わたされたが既に実DBと合わない。

このDBをとりあえず自分が把握して、次の担当者にも優しい仕様にするにはどうしたらいい？
途方に暮れてる…

939 ：NAME IS NULL：2009/07/15(水) 09:36:49 ID:???

>>938
>　次の担当者にも優しい仕様にするにはどうしたらいい？
逃げ出そうってのかい？ｗ

940 ：NAME IS NULL：2009/07/15(水) 09:41:49 ID:???

>>938
きちんとした引継ぎを行わなかったのがいけない。

前任者を捕まえてきて、まっとうな仕様書を書いてもらう。Q&Aも行う。

前任者を捕まえることができなかったら、引き継いだ人間と上司に事情を説明して、
DB解析のための十分な工数をもらう。

941 ：NAME IS NULL：2009/07/15(水) 13:37:39 ID:???

自分で再設計して、まともな設計のテーブルに移行だな。オラクル導入済みなのは幸い。
上司／決裁者に、現状を報告しておくのは悪くない。つーかにちゃんで相談よりもまずそっちだな。
指示が有ればその通りに動けば良いし、指示が無ければ、自分の遣りたいように提案して承認貰って動けば良い。

これから汗水垂らして綺麗にするdbをむざむざ次の担当者に譲ってやる事も無いと思うが。
前任者に習って、自分で仕様を抱え込んで飯にありついておくのが吉。多分そういうのが許される組織だろうし。

942 ：NAME IS NULL：2009/07/15(水) 20:18:19 ID:???

>>941
汗水垂らすのが嫌

943 ：NAME IS NULL：2009/07/16(木) 04:08:24 ID:???

oracleはGUIが好きになれん。
なんでjavaなんて糞重いの使うの？

944 ：NAME IS NULL：2009/07/16(木) 06:38:49 ID:???

OracleはJavaにかなり貢いでいるから。

後はWindowsプラットフォームに動かす事にそんなに拘りないからじゃね。

945 ：NAME IS NULL：2009/07/16(木) 07:16:10 ID:???

VMWareにoracleぶちこむと重くて仕事にならない。

946 ：NAME IS NULL：2009/07/16(木) 08:29:27 ID:???

今どきあの程度のGUIが糞重いって、どんだけ極貧開発環境なんだ？

947 ：NAME IS NULL：2009/07/16(木) 10:00:19 ID:???

まだPIIIとか使ってるってだけでは。
時代はクアッド3GHzなのに。

エクリプスもJデベロパも殺人的に重いけどみんな使ってる。

948 ：938：2009/07/16(木) 19:01:45 ID:???

データベースがデータベースで管理されてないなんて皮肉にもほどがある…
日付データ全部8桁のナンバで管理してる上に…20070735ってなんじゃこりゃあああ？！

949 ：NAME IS NULL：2009/07/16(木) 20:37:33 ID:???

>>947
起動時間は掛かるけど、起動してしまえばどうってことないな。
メモリは2Gはないと苦しいけど、CPUは1.5GHz～（Pen4なら3GHz）あれば十分では？

950 ：NAME IS NULL：2009/07/16(木) 20:54:52 ID:???

>>948
2007年7月35日だ。わからんのかたわけが。

951 ：NAME IS NULL：2009/07/17(金) 10:07:40 ID:???

32以上は全部月末処理仕様

952 ：NAME IS NULL：2009/07/17(金) 19:18:13 ID:???

99999999で再起動するから入力しちゃらめぇ。

953 ：NAME IS NULL：2009/07/20(月) 21:28:05 ID:???

>>938
自分ならまずどのテーブルが活きてるのか見極めるかなあ…。
前任者一人で面倒見てたDBのテーブルが大小300って、それ絶対に半分は使ってないよ。

954 ：NAME IS NULL：2009/07/20(月) 21:48:52 ID:???

>>953のレス見て思い出した。
Hoge、testHoge、testHoge2、testHoge3　ってテーブルがあってtestHoge2のみが生きてた所があった。

955 ：NAME IS NULL：2009/07/21(火) 02:14:07 ID:???

前任者「テーブル名の末尾Dは日次、Wは週次、Mは月次更新です」
俺「ふんふん。…あ、Tってのがあるんですけど」
前「溜め込みのTです。」
俺「(…終わった) そうですか…」

他にもRやNやJなんてのがあった。
Rは履歴、つまりバックアップらしい。
Nはノーマル。ただしノーマルでないものは存在しない。
Jは次期。いつの次期かは知らない。

956 ：NAME IS NULL：2009/07/21(火) 06:11:33 ID:???

別にいいんじゃね？
センスはどうあれ一貫したルールが存在するなら。

957 ：NAME IS NULL：2009/07/21(火) 22:11:36 ID:???

よくねーだろｗ
カオスすぎるだろｗ
溜め込みのTでくそわろたわ

958 ：NAME IS NULL：2009/07/22(水) 09:35:49 ID:???

これから綺麗にしていけば良い話。
コボラーとかまともな教育受けてない香具師がまともな設計出来る訳無いじゃん。

959 ：NAME IS NULL：2009/07/22(水) 13:41:37 ID:???

実際のところ、引き継ぎあるだけマシだよ

960 ：NAME IS NULL：2009/07/23(木) 03:13:05 ID:???

引き継ぎ無くても新しい自分の管理しやすい設計に変更していけば良いだけ。

961 ：NAME IS NULL：2009/07/23(木) 07:03:06 ID:???

>>960
仕様書も設計書もなく、複数の人間が複数回触り続けて全容が誰にもわからない、そんな糞システムを引継ぎもなく渡されたことないだろ？お気楽なコメントしてんなよｗ

962 ：NAME IS NULL：2009/07/23(木) 07:12:49 ID:???

1人プロジェクトしかやったことないんだろ

963 ：NAME IS NULL：2009/07/23(木) 09:03:13 ID:???

>>948
ﾜﾛﾀ

964 ：NAME IS NULL：2009/07/23(木) 13:13:32 ID:???

デスマ耐性無い香具師が多いな。自分で切り開けないと終わるよ。

965 ：NAME IS NULL：2009/07/23(木) 13:42:29 ID:???

>>964
病気自慢？

966 ：NAME IS NULL：2009/07/23(木) 13:43:42 ID:???

なんで唐突にデスマの話になるんだろうな。

967 ：NAME IS NULL：2009/07/23(木) 17:27:05 ID:9uVZvB/4

例えば修理現場などで工程別に何を作業したか？というデータを収集したいとします。
そこでテーブル設計で悩んでいます。
追加/登録は、各マスタのデータ(工程等)をコンボボックス等で選択します。
案1より案2の方が優れていると思うんですが、如何でしょうか？
また案2で重大な欠点がある場合は指摘していただけたらと思います。

■案1
[データテーブル]
・ID(PK),工程ID(数値),作業ID(数値),担当ID(数値),作業日時(文字列),作業時間(文字列)
[マスタ]
・工程ID(PK),工程名,順番,削除FG
･･･その他のマスタ

■案2
[データテーブル]
・ID(PK),工程名(文字列),作業名(文字列),担当名(文字列),作業日時(文字列),作業時間(文字列)
[マスタ]
・工程名(PK),順番
･･･その他のマスタ

===自分が思う利点欠点===
■案1の利点
・重複した名称のマスターデータが持てる。<=意味あるか？
・過去データを含めた名称の変更は、マスターを修正するだけでOK。
・なんとなく連結される部分は文字列型よりも数値型の方がよさそう。
■案1の欠点
・データの表示には全てのマスターと連結したクエリーが必要<=フィールドが多いとめんどい上に遅くなる？
・マスターデータを完全に削除する事は出来ない。
　また、過去データを変えずに名称を変える場合は新規にIDを追加する必要がある。
・登録には必ず、マスタにデータを追加する必要がある。
・登録したデータを修正したい場合、既に削除されたマスタがあった場合
　コンボボックスにはどのように表示/登録させる？

■案2の利点
・テーブルだけでデータの表示が可能。
・マスタデータを削除する事が出来る。修正時も過去のデータを考慮する必要が無い。
・IDを考慮する必要が無くなる。
・登録するデータに汎用性がある(マスタに無いイレギュラーな登録も可能)。
■案2の欠点
・マスタに同名の項目が作れない。
・データベースの基本としてなんとなくIDを利用したい。なんとなく見栄えが悪い。
・工程名、作業名に利用できる文字が限定される。|\'# とか無理そう。

968 ：NAME IS NULL：2009/07/23(木) 20:56:31 ID:???

工程や作業をどうやってどこまで管理したいかによるだろう

たとえば「組立て」と「組み立て」が別工程と判定されたら
重大な欠陥といえるかもしれないしそうでないかもしれない

まず要件をしっかり見極めることが大事なんじゃないかね
利点欠点はその要件に対してメリットデメリットを判定しないと意味ないぞ
まああげてる利点欠点も突っ込みどころ満載なんだがｗ

969 ：NAME IS NULL：2009/07/23(木) 21:20:52 ID:???

＞登録するデータに汎用性がある(マスタに無いイレギュラーな登録も可能)
とか言っても「順番」はマスタが持ってるんだけど、マスタに無い登録が可能でいいのか、とか。

外野には見えない「重大な欠陥」は有るかも知れない。

970 ：NAME IS NULL：2009/07/23(木) 21:33:24 ID:???

画像って今まではファイルパスだけ格納していたけど、
BLOB型使ってバイナリデータも格納しようかどうか迷ってる。

971 ：967：2009/07/23(木) 21:46:25 ID:???

>>968
>工程や作業をどうやってどこまで管理したいかによるだろう
例えば１0人の担当者が、20工程ある中から1つの工程で、30作業ある中から1つの作業をする。
作業をしたら、担当者(選択)、工程(選択)、作業(選択)、日時、時間を1台のPCへ入力する。
このデータは、後に修正、削除される可能性あり。
また、担当者、工程、作業のマスタの修正は1-3ヶ月に数回程度の頻度で発生する。
後に簡単に集計をしたいので「組立て」と「組み立て」などと同内容の
項目が別の文字で入力されるのは避けたい。

>まああげてる利点欠点も突っ込みどころ満載なんだがｗ
その満載な突っ込みどころを知りたいのだが。

>>969
マスタに無い登録が可能で良いのかどうか。は、確かに悩みどころです。
ただ頻度が極端に低く、担当者、工程、作業の中には期間限定の項目なども考えられるので、
あった方が良いかな？と思っています。

ちなみにマスタの順番は、工程の順番とかではなく、登録時にコンボボックスやリストで表示される順番に
なりますのでデータテーブルには関与しません。分かりづらくて申し訳ないです。
(コンボボックス等では選択しづらいとかは、論点ではないので無視してください。）

972 ：NAME IS NULL：2009/07/23(木) 22:19:05 ID:???

1-3カ月程度で工程や作業がコロコロ変わって
かつマスタ側で管理したい項目は1つもない（単にコンボボックスの表示用）てことであれば
案２でいいんじゃないの。

973 ：NAME IS NULL：2009/07/24(金) 00:28:49 ID:???

>>971
似たような工程が別工程として登録されるのを防ぐなら、工程はマスタ化すべき

突っ込みどころは

>・重複した名称のマスターデータが持てる。<=意味あるか？
案２でも重複した名称で登録はできるが、なぜこれが利点なのだ？

>・なんとなく連結される部分は文字列型よりも数値型の方がよさそう。
なんとなくで利点だって言われても正しいかどうか判断つかんぞ
これにどうメリットがあると考えたんだ？パフォーマンスか？
そもそも示されてる範囲ではこれを文字で連結する要素は見当たらないが

>・マスタデータを削除する事が出来る。修正時も過去のデータを考慮する必要が無い。
そもそもマスタが存在してないが、修正時に過去データを考慮する必要があるかどうかは
要件によるだろ。今まで「組み立て」で登録してたのに、今後「組立て」で登録します
だけどこれは同一の工程です、となったら、過去に「組み立て」で登録してあるデータどうするのさ？

>・マスタに同名の項目が作れない。
そもそもマスタが存在してないが、同名の項目は入力できるだろ
同名だけど別工程だっていうなら、どっちにしろその違いを判定する項目が必要なことには変わらない

>・データベースの基本としてなんとなくIDを利用したい。なんとなく見栄えが悪い。
なんとなくでID使うとか言いだすともめるぞｗ

>・工程名、作業名に利用できる文字が限定される。|\'# とか無理そう。
そんなことはない。つか無理そうってだけで、無理かどうか確認もせずに欠点だって言われてもな

このぐらいでいいか？

974 ：NAME IS NULL：2009/07/24(金) 02:05:55 ID:???

あんまり再利用する事も無さそうだなあ。
かんばん方式的に作業時間短縮を狙うなら、そういうテーブルで管理したほうが素直な気がする。

975 ：NAME IS NULL：2009/07/24(金) 11:24:30 ID:???

皆さんどうもです。

>>972
マスタ側で、どういう管理が必要になったら案2では駄目になるか
もしポイントがあれば教えていただけますか？

>>973
>>・重複した名称のマスターデータが持てる。<=意味あるか？
>案２でも重複した名称で登録はできるが、なぜこれが利点なのだ？
案2では名称がPKになっている以上、マスタ側では重複した名称では
登録できないと思うのですが･･･。

>今まで「組み立て」で登録してたのに、今後「組立て」で登録します
>だけどこれは同一の工程です、となったら、過去に「組み立て」で登録してあ
>るデータどうするのさ？
その場合は過去の名称に意味を成さないと思いますので
データテーブルを一括置換します。

以下、そもそもマスタが存在していないとは･･･？
工程、作業、担当者は各テーブルを作成してマスタ化している(と思っている)
のですが･･･。？？

>>974
案2で再利用して困る場合はどんな時がありますかね。

976 ：NAME IS NULL：2009/07/24(金) 18:13:28 ID:???

>案2では名称がPKになっている以上、マスタ側では重複した名称では
>登録できないと思うのですが･･･。

案２で工程名に対して制約つける気なのか？
もしそうなら、案１と案２は、キーがIDか名称かの違いしかないぞ
登録できるってのは、あくまでデータに対しての話だ

>以下、そもそもマスタが存在していないとは･･･？
存在してないってのはちょっとあれか
マスタが存在しても、マスタに関係なくデータ登録できるなら
マスタとしての意味はなしてないってことだ

977 ：NAME IS NULL：2009/07/25(土) 03:47:08 ID:DT7TRz8B

以下案２の欠点な。
・VIEW上の工程名を一括で変えたいときに面倒。
　SQL一撃だがunique indexのカラムが変わるので、multi versioning系でないDMBS
　だとほぼテーブルロック的挙動になるぞ。
・工程名があんまり長いとindex leafに乗ってくるのがhash値になったりして
　実表アクセスが増えて処理性能的に不利。
・DBMS依存かもしれんが、左表NULL可だとNested Loopで結合できないから
　結合時に性能的に不利になる。まあ、トランザクション少なそうではあるが。

978 ：NAME IS NULL：2009/07/25(土) 07:41:07 ID:???

イメージがまるでエクセルだ。
おそらくその程度のデータ数なんだろうな。
担当者がシートを開いて見渡せる程度。

979 ：NAME IS NULL：2009/07/25(土) 14:56:52 ID:???

>>967
工程名を変更した時点で工程マスタを参照しているテーブルのデータを修正しなければ行けない。
案2を捨てる理由はそれだけで十二分。

PKに意味を持たせるのは百害あって一理無し、初心者のうちはそういう太古からの慣習には黙って
従っておいたほうがいいよ。
「意味コード」という物の欠点を、ググルか先輩諸氏に聞いてみて。

980 ：NAME IS NULL：2009/07/25(土) 14:58:50 ID:???

もう一つ

テーブル設計において「SQLでこう書くことになるから…」とか「こういうGUIの実装だから…」
などという事は考慮するべきじゃないよ。

981 ：NAME IS NULL：2009/07/25(土) 19:31:19 ID:???

性能面でSQLは考慮すべきだとは思うけどなあ。データベースエンジン依存だが。
GUIはユーザ依存なので要件きちんと把握しろとしか。

982 ：NAME IS NULL：2009/07/25(土) 22:42:32 ID:???

性能を考慮して元来は一つのテーブルにすべきところを分割したり、
正規化して分割すべきテーブルを一つにしたりってのは実際よくあるが
DB設計って本来は性能を考慮するべきじゃないと思うんだがな

それはSQLでもそうであって、性能を考慮してトリッキーなSQL書くべきではないと

まあ、実際はある程度の性能は出さないと使い物にならないんだが
最近のマシンは早いし、オプティマイザも結構賢いので、よっぽど大規模じゃないと
あんまり気にする必要ないかもしれん

983 ：NAME IS NULL：2009/07/25(土) 22:57:55 ID:???

O/Rマッパー使ってパフォーマンスが出ないからって正規化くずしを
やってるとしたら本末転倒もいい所

でも意外にそんな開発現場が多い気がする。

984 ：NAME IS NULL：2009/07/26(日) 18:00:08 ID:???

>>981
「テーブル設計」なら正しいんじゃね？
「DB設計」の場合アクセスポイント(≒SQL)を意識する必要はあると思うけど。

>>983
んなとこあんのか？
正規化くずしなんぞせんでもインターフェース用意すれば済むだろ。