頼むから正規化しろよ

1 ：パフォチュー：03/08/12 21:13 ID:uJybnGok

｢パフォーマンス悪いからSQL見直せ｣ってあんた。。。
まるっきりDBが正規化されてねーじゃんか！
｢冗長化したほうがパフォーマンスがいい｣だと？
ハッシュ・ジョインくらい勉強しろ！
論理設計からやり直せ！その前に自腹でベンダーの講習受けて来い！

だからPJに途中参加するのは嫌なんだよ(鬱

2 ：名無しさん＠お腹いっぱい。：03/08/12 21:22 ID:uJybnGok

2げっと

3 ：禿道：03/08/12 21:40 ID:ClWPxTzt

>>1
よくわからんが取り敢えず同意

4 ：名無しさん＠お腹いっぱい。：03/08/12 21:59 ID:???

素人さんが設計したＤＢなんて使えません。
システムの中枢部分をな～んでいい加減に設計するの？
プログラマは苦労する罠

5 ：禿道：03/08/12 22:25 ID:ClWPxTzt

>>｢冗長化したほうがパフォーマンスがいい｣
嘘じゃ無い。
否定できないお前もDQN。
更新の頻度にもよるが書き込み時間を気にしないなら、データの冗長化は
データアクセス時間を短縮することができる。

冗長データが手入力じゃ無いなら、許せ。
俺は手入力を相手に毎日格闘している。

6 ：名無しさん＠お腹いっぱい。：03/08/12 22:52 ID:uJybnGok

>>5
はぁ？冗長化なんか今時、推奨するところなんてあるの？
PGは複雑になるし、保守性悪いわ、柔軟性はないわ、
テーブルは無駄に巨大化してくわ。。。メリットなんざ思いつかんね。
だいたい何の為のハッシュ・ジョインなんだよ。
つーか、まず正規化してから冗長化など検討すべきだろ。
ロクでもない設計して言い訳的に
｢冗長化したほうがパフォーマンスがいい｣
なんて言われたら、そりゃキレるよ。

7 ：名無しさん＠お腹いっぱい。：03/08/12 23:09 ID:FNgPW25+

そんなこといったら、漏れのとこなんて救いようがないぞ。
かなり複雑怪奇なSQL発行しまくり。
副照会か6階層くらいあってたり、仮想領域を3つくらい使ってたり、
もうめちゃくちゃでわけわからん。

作った本人の漏れでさえ、何やってるかわかんなくなる。
まじこんなDB腐ってる。

8 ：名無しさん＠お腹いっぱい。：03/08/12 23:23 ID:???

また糞スレか・・・・

9 ：名無しさん＠お腹いっぱい。：03/08/12 23:36 ID:???

俺のところのアプリ部隊はVIEWしかアクセス出来ない。
しかもHINTも使えないからチューニングのしようがない。
んで、制御部隊（設計者）にパフォーマンス悪いと報告すると
逆ギレされる。
一度CREATE VIEWのDDLを拝見したいもんだ。

10 ：名無しさん＠お腹いっぱい。：03/08/13 00:05 ID:???

DBの設計不良で苦労しているところはよくあるんですね。

チューニングの基本はSQLの見直しだとは思いますけど、
やはり正規化してないと整合性がとれなくなったりして
思わぬバグを誘発する恐れもありますし。

以前、｢正規化できないんだよ。このシステムは｣なんて平然と
言ってのけるSEがいました。
それでよくBIG ITとかよく宣伝してるなぁと感心しました。

11 ：名無しさん＠お腹いっぱい。：03/08/13 00:10 ID:???

書き込みのトランザクションがバンバン発生するようなシステム→正規化
でっかくって非定形処理の多いデータウェアハウス→冗長化

どっちにしても、色々チューニングして一番ｳﾏｰな状態に
するのはめんどうなのれすよ。

12 ：あぼーん：あぼーん

あぼーん

13 ：クラッシャー堺：03/08/13 15:00 ID:JkUi5yos

あ

14 ：名無しさん＠お腹いっぱい。：03/08/13 18:34 ID:F+w598Ig

データモデリングが大切っちゅーことやね。

15 ：あぼーん：あぼーん

あぼーん

16 ：名無しさん＠お腹いっぱい。：03/08/13 19:46 ID:???

完璧に正規化してくれとは言わない。
冗長化もまだ許せる。
だけど、だけど・・・

横　に　長　い　テ　ー　ブ　ル　を　作　る　の　だ　け　は　勘　弁　を・・・

数量1,2,3・・・10ってなんだよ・・・

17 ：名無しさん＠お腹いっぱい。：03/08/14 02:01 ID:???

俺、２５５カラムあるテーブル、３０個のDBあつかったことある。
さらに結合いっぱい、書き込みいっぱい、I/Oもメモリもいっぱいいっぱい。
帰りたかった。

18 ：名無しさん＠お腹いっぱい。：03/08/14 09:05 ID:???

>>16
その系統で数量128とか見て眩暈を起こしました。
数量じゃないけどさ・・・。

19 ：山崎渉：03/08/15 21:58 ID:???

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

20 ：山崎渉：03/08/15 22:49 ID:???

21 ：名無しさん＠お腹いっぱい。：03/08/16 03:15 ID:Nt2klYxE

正規化するのはシステム設計上、当然ですわな。
それを知らずに堂々とコンサルタントするF通の馬鹿さ加減には
うんざ～り。
一生、SQLは外だしして、クライアント・カーソルを用いて
DBサーバーを苦労させてね！

22 ：名無しさん＠お腹いっぱい。：03/08/16 03:43 ID:???

F通・N電気・H立...
日本のベンダーは開発（設計）能力無いねぇ。
ちっとは頑張って画期的なDBMSでも作ってね（無理でも）

ゲイツより茂雄が好きな日本人より。

23 ：名無しさん＠お腹いっぱい。：03/08/16 03:50 ID:???

>>22
>ゲイツより茂雄が好きな日本人より。

それ、わかりづらい！

24 ：あぼーん：あぼーん

あぼーん

25 ：名無しさん＠お腹いっぱい。：03/08/16 13:17 ID:t/5MsxPF

　正規化できない場合があるよ。
　客が主キー制約をどうしても認めない場合。
　あと、テーブル数で料金が決まってる場合とか。
　客はいろんな可能性を後へ残しておきたいんだろうけどな。

　技術的にも論理削除がやりやすいとか言う、逃げもある。

　元々の設計が悪いとか、レビューが悪いとかいうのもあるだろうけど、
　俺が思うには、経験を持った人間がポリシーを持って対処するしかない。
　そうして初めて正規化のメリットがデメリットを上回る。
　この損益分岐点は実は結構高いところにあるのだ。

　

26 ：名無しさん＠お腹いっぱい。：03/08/16 13:20 ID:???

>>25
あと、下手なＤＢにしといたほうが、メンテとか仕様変更で金を取れるというのも
あるかもしれんな。　人月で金払ってるんだからこうなるわけだ。

27 ：名無しさん＠お腹いっぱい。：03/08/16 17:33 ID:???

>>9
select * from viewをexplainで見てみたらいいよ。
DQNな実行プランが出てくるんじゃねぇか？

28 ：名無しさん＠お腹いっぱい。：03/08/17 20:45 ID:+oqRYfoP

>>27
実行計画採取のGRANTさえ無いユーザじゃない？
うちはそうだよ。

29 ：名無しさん＠お腹いっぱい。：03/08/23 01:36 ID:???

・大量で変化しにくいデータの検索の高速性が求められる
・ビジネスルールを正確に立てられない
場合は冗長化もアリかと。

30 ：名無しさん＠お腹いっぱい。：03/08/23 02:24 ID:1yygtNzF

頼むから性器化しろよ！

。。。。すまん

31 ：名無しさん＠お腹いっぱい。：03/08/23 17:00 ID:???

>>16
もっとすごいの見たことがあるぞ。
３次元配列になっているテーブルをメンテしたことがある。
といってもDB側が３次元になっているわけではなく、COBOLのCOPY句が
３次元展開してあってそこで処理するという罠。（一応、DBの項目とCOPY句の項目
定義の並び順は一致していたけど、数えるのが大変）
何のためのRDBなんだか・・・・。

あと、別のところではもっとすごいことやってて、キーと4096桁のでっかい固定長がいくつか
あるテーブルを見たことがある。
これもCOBOLのCOPY句で分解するというもの。（要はDB上では項目は連結していて、
プログラム上で初めて分解される。）
INIT VALUE に X'40404040F0F0F0F0F0F0F040404040・・・・'なんてのがつづいて
いたのを見た時には、正直絶句。はやく撤退してよかった。

ちなみに、両方ともメーカー主導のデスマーチプロジェクトだったがな。

32 ：名無しさん＠お腹いっぱい。：03/08/24 12:17 ID:???

JOIN禁止令を出しているプロジェクトもあったな。
わざわざCOBOLでOracle使ってマッチング処理をCOBOLで書いたそうだ。
正規化以前にSELECTを身に付けろと小(ry

33 ：名無しさん＠お腹いっぱい。：03/08/24 16:38 ID:???

冗長化ってDB用語?
スレの流れで何を冗長化してるのかは分かったけど。

34 ：31：03/08/24 20:30 ID:???

>>32
ホスト系でCOBOLで処理してまーす、てなところはそういう所多いね。
あと多いのが自前でアクセスルーチン作ってるとこ。
昔はDBの性能が悪かったのと、リバインドに結構時間がかかっていたからだと
おもうんだけど、直にSQL発行できないんですごいいらつく。

どちらも遥か昔のSQLのアクセスプランがメタクソだったころの名残だろう。
パフォーマンス稼ぎに主表にカーソル作ってループさせ、主表のfetchのところで
さらに副表のカーソル作ってカーソルENDになるまでループさせたことはあるよ。
（当時JOINはむちゃくちゃ遅かった。）

と　は　い　っ　て　も　１　０　年　く　ら　い　前　の　話　だ　け　ど　な　。

そういや、今でも汎用機のRDBってバインドとかするの？

>>33
たぶん一般用語だとおもう。漏れは使ったことがない。
（漏れは説明資料とかでは項目の二重持ちとか書いたな）

普通は非正規化とか非正規形かいってかっこつける。

ほ　ん　と　は　か　こ　わ　る　い　け　ど　な。

35 ：名無しさん＠お腹いっぱい。：03/08/24 22:08 ID:netEchZj

>>ホスト系でCOBOLで処理してまーす、てなところはそういう所多いね。

あっ！それ知ってるかも。SQLをまったく知らないCOBOLer集団が
Pro*COBOLで作ったデイリーバッチが４日かかったとか。
○○証券の勘定系ですけど。。

36 ：名無しさん＠お腹いっぱい。：03/08/24 22:27 ID:???

SQL Server では冗長化テクニックとして、
カヴァリングインデックスと、それが適用されるカヴァードクエリがある。

普通、売上データには商品名を入れずに商品コードだけを格納するでしょ？
商品コードだけでなく、商品名も格納してしまえば、商品マスタを
参照しなくて済むようになる。まぁ、これは誰でも分かるね。

さらに、この商品名にインデックスを張るとパフォーマンスが良くなる。
抽出条件として使用しない商品名にインデックス張って意味があるのかって？
あるんですよ。インデックスを貼っているとその内容はインデックス領域に
格納されるから、実データノードを参照せずに値が取り出せるようになる。

つまり、テーブル定義の冗長化とあわせて、インデックス作成でも
抽出条件だけでなく参照頻度の高い項目にもインデックス張ると
パフォーマンスが上がります。たとえば、売上データをもとに
商品コード、商品名の一覧を表示して、選択した商品の詳細な履歴を
表示するような場合、最初の一覧表示は売上データの
インデックス領域だけで処理を完了できるようになるわけね。

抽出条件だけにこだわらず、高頻度参照項目にもインデックスを張る。
これがカヴァリングインデックス。Select句の項目すべてにインデックスが
張ってありインデックス領域だけで処理完了できるクエリを
カヴァードクエリと言う。基幹系システムに情報系システムを追加するような
案件も増えてきているし、正規化ばかりにこだわってちゃだめだよ。
基幹系ならともかく、情報系のパフォーマンスを維持するためには
冗長化なんて常識ですね。

37 ：名無しさん＠お腹いっぱい。：03/08/24 22:42 ID:???

>>36
独り言はこちらへどうぞ。
http://life.2ch.net/yume/

38 ：31：03/08/24 22:43 ID:???

>>36
それって冗長化っていうのか？ただのパフォチューだとおもうんだが。

あと、SQLServerはくわしくないけど、パッと見、商品コードの検索のパフォーマンスと
更新系のパフォーマンスが落ちないないかい？（あっ、インデックスは別々にとるのか）
おちなきゃたいしたもんだな。いや、知らないんで聞いているだけなんだけど。

それと、SQLServer限定でかまわないんで、非正規化してパフォーマンスあがるってどんなの？
実はつぎの仕事でこいつ使うんだが、いままでつかってたイビム様のDBと結構勝手が違うんで
困っています。

39 ：名無しさん＠お腹いっぱい。：03/08/25 01:20 ID:???

>36
言わんとしてる事は分かるけど、>35以前で出てる例をそれと同列に語るのはどうかと。

40 ：名無しさん＠お腹いっぱい。：03/08/25 02:56 ID:a7wMPlxr

命名

　インデックス厨

41 ：名無しさん＠お腹いっぱい。：03/08/25 19:47 ID:cO3nWzqK

正規表現で置換しる

42 ：：03/08/25 20:24 ID:bIGup91d

>>41
すげぇ。
俺もその発想にはいたらなかった。

43 ：名無しさん＠お腹いっぱい。：03/08/25 22:42 ID:cW9F7TKX

>SQLServer限定でかまわないんで、非正規化してパフォーマンス
>あがるってどんなの?

【メリット】
どのRDBでもそうだが、一般的に結合する必要が無いからその分の
オーバヘッドがかからない。

でも個人的に一昔前ならいざ知らず、最近ではハードスペックも
ずいぶん上がっているし、OLTPではそれほど大差無いっすよ。

【以下デメリット】
ましてや保守性まで捨ててまで冗長化設計する必要はないと思う。
冗長化するとOLTPでは小さなメリットはあるかもしれんけど、
重複データを多数保持するから、整合性を保つ為にアプリケーションで
コントロールするには限界あるからTRIGGERで泣く泣く対応したり。

結局バッチなどでSQL-LoaderやらOSQLやらに頼って、
24時間サービスも出来なくなるし、バッチに時間がかかりすぎて、
サーバーメンテナンスなど時間が制限されたり。

最近はイテレート型開発などがメジャーだし、
正規化しとかないと後で項目追加とかになったらそれのコストも
かかるよね。

（まだまだ思いつく。。。。）

とりあえず第三正規化ぐらいまでやってみて、
｢どうしても｣となったとき冗長化を検討してみては？

44 ：名無しさん＠お腹いっぱい。：03/08/26 00:03 ID:JjcaBwgp

がんばれ

45 ：ヶ ◆/iQf.Br2tM ：03/08/26 00:34 ID:/cqp0IvR

【非正規化のメリット】
データ自体正規化されていない場合余計な労力を使って
正規化しようとしても無理。

データが云々じゃなくてデータの入力出力他取り扱いに正規化の概念が
そもそもない場合どうしようもない。
ＳＥがどうこうじゃなくってこういうのを納得させるのが不可能な場合も
かなりあるんだよね。

46 ：名無しさん＠お腹いっぱい。：03/08/26 02:24 ID:???

>>45
そういうことを「メリット」って言うようでは
もまいは、ハッキリいってレベル低い。
それはメリットでも何でもない。
単にあきらめているだけだろう。

47 ：名無しさん＠お腹いっぱい。：03/08/26 07:17 ID:YHYrBqtj

非正規化のメリットって言葉はなんかアホくさいな。
なんでもかんでも正規化すればいいってもんじゃないってのは
わかりきってるわけだが、メリットというまとめ方をするとこれまた
なんか実情に合わない気がするわけだ。

48 ：名無しさん＠お腹いっぱい。：03/08/26 07:36 ID:???

パフォーマンスというより、
確定させることが必要な
（マスタデータ変更で、過去の確定データも変更されたらマズイ場合に）
トランザクション系のテーブルに対して正規化崩しを使う。

それ以外は、もちろん正規化が基本。
パフォーマンスというが、開発、保守（リカバリ）、拡張を含めた
トータル的な視点からは、きちんと正規化されたモデルの方が低コストである。

49 ：名無しさん＠お腹いっぱい。：03/08/26 08:00 ID:???

>>48
そりは非正規化じゃなくて、まっとうな設計だとおもう。
マスタと実績はそもそも意味が違うからね。

50 ：名無しさん＠お腹いっぱい。：03/08/26 10:00 ID:YHYrBqtj

>>48
すべからく正解。

51 ：名無しさん＠お腹いっぱい。：03/08/26 11:23 ID:n0gKu5D6

>>48
そうね、実行時の速さだけでなく、>>48で言っているように、
開発、保守、拡張時のパフォーマンスも考慮にいれないとイケナイ。

52 ：1：03/08/26 23:05 ID:pJNYwhmR

>>46
人の意見に反論するのは結構ですが、同時に持論も書いてくれると
ありがたい。

53 ：名無しさん＠お腹いっぱい。：03/08/27 00:12 ID:???

>>48 それは正規化崩しとは言わないよ。

たとえば担当者コード 10番の山田さんがりんごを販売した売上データに
担当者コード 10 だけでなく、担当者名も格納するということだよね。
あとで、担当者マスタの 10番を佐藤さんにされちゃった場合、
佐藤さんがりんごを販売したことになっちゃうから。

上記のことが問題になるようなシステムでは、販売時のスナップショットを
とるのが必要要件なのだから、(事後参照保証がない)担当者名を格納するのは
あたりまえで、それを格納したとしても正規化を崩しているとは言わない。
(「そのときの情報を落としておきたい」というのが要件なんだからさ。)

54 ：あぼーん：あぼーん

あぼーん

55 ：名無しさん＠お腹いっぱい。：03/08/27 01:44 ID:???

>>53
そういう要件の情報がなく、いきなりDBモデルを
みたら正規化崩しに見えるんじゃない？

逆にいうと、そういう要件（確定データ保存）
でもないのに上記と同じモデルを設計すると、
正規化崩しとなってしまうわけかな？

煽りじゃないよ。

56 ：ヶ ◆/iQf.Br2tM ：03/08/27 18:03 ID:jm41G9Nm

メリットというほどではないのだが。

なんというか，既にデータが沢山あって正規化されていないシステムで
運用されていた場合には
・正規化のためにデータを解析して整理する
・運用側の教育（とりわけデータの入出力について）
がきわめて困難であり運用の停止期間・更新期間内に完了できない
ことも多々ありますです。
こういうケースで無理に正規化を推進すると結局のところデータ処理担当者
がデータ入力の『やり易さ』が低下するので『使いにくい』システムになってしまう
のです。

いくつか実例があるのですが　一番簡単な一例として某社の
給与計算システムの社員テーブル。
社員番号,氏名,郵便番号,市町村コード,住所,社宅区分…
　社宅区分＝１：社宅居住者なので給与から家賃を差し引く
　社宅区分＝０：社宅居住者ではない
さて完全に正規化するとすれば　住所で社宅区分は一意になるので
(特定の住所が社宅である＝社宅区分は住所で一意になる)住所マスタ
か何か作ればそれは達成できる。

社員マスタ
社員番号,氏名,住所コード…
住所マスタ
住所コード　郵便番号,市町村コード,住所,社宅区分…
とまあそうすることは可能だが面倒なためそこまではしないことが多い。

さらに夫婦両方とも社員で社宅に住んでいる場合どちらか片方からだけ
家賃を引くようにしないといけないので旦那の方を　社宅区分１
奥さんを０に設定。などデータだけでは予測がつかない処理もあるので
注意だ。

57 ：46：03/08/27 19:58 ID:???

>>52
あのな、「無理」とか「どうしようもない」なんていうのが「メリット」か？
普通「非正規化のメリット」を書くなら「非正規化をすると、こういう良いことがある」ってなことを
書くもんじゃないのか？>>45はメリットでも何でもなく、努力の放棄っていうわけだ。
だから「レベルが低い」って書いたんだよ。俺のカキコは反論でも何でもない。
言葉の誤用を指摘しているだけだ。メリットって言葉の定義域から考え直せ。

ついでにお望みのようだから俺の持論も書いてやる。
・徹底的に正規化しろ！
・わざわざ非正規形に戻さなければならないような後戻り工程を作るな！
・ハードが貧弱だったときの常識を今更持ち出すな！
だ。10年以上DOAやってるがこれで困ったことは一度もない。
むしろ非正規形にしてしまった結果、数年後に足を引っ張る方が多い。
レコード件数も数100万件は普通だ。億単位も何度もやってる。
ありがたがってくれ。

ついでにな、「使いやすいデータアクセス」と「正規化されたデータ構造」は両立できるぞ。
正規化されていないコード体系をどう扱うのかなんてのは、普通に出てくる話だ。
ちゃんと正規化できるよ。ユーザインターフェースとしてのデータ構造をそのまま
DBに入れようとするから駄目なんだ。

＞　社宅区分＝１：社宅居住者なので給与から家賃を差し引く

・社宅居住者である
・給与から家賃を差し引く

既にふたつの内容が混ざっているわけだが？
しかも、「社宅居住者である」はドメインの定義域に入るかどうかというデータ構造の
話だが、「給与から家賃を差し引く」は、ビジネスルールであって、既に変動要因だし
アプリケーションの仕様だぞ。

こういう混同をしているから、「メリット」と「あきらめ」を混ぜてしまうんだ。
もっと、がんがれ！

58 ：ヶ ◆/iQf.Br2tM ：03/08/28 12:05 ID:Q75JHJjh

努力の放棄といわれればそれまで。
まあただ実際のところ1から全て自分で設計できるような恵まれた条件でないことも
ありますから。
数十年前のアプリケーションの更新をする。アプリケーションの仕様書と
実際に動いている状態がなんだか違う。どうやら使い勝手がよいように改造
をしてあるらしい。
そういうときは実際に動いているデータを観察して運用担当者に改造個所を
聞き出しながら作っていく。ただちょこちょこと改造を加えた結果聞き取り調査
の際には出てこなかった改造がテスト時のエラーで見つかることもある。
まあなんというか教科書通りでないということも多々あるわけであって
こういうときどうするかといえば，ソレは仕様にないから金輪際対応しませんとか
仕様変更だから納期を延ばせとかそういう風に突っぱねるわけにもいかないわけで
納期と作業の両を勘案して妥協しないとならないということもあるということを
一応考慮に入れておいてください。

59 ：31：03/08/28 21:42 ID:???

>>58
57はまっとうな正論を言っていると思うよ。
漏れもずいぶんひどい設計のシステム見てきたんで、同一項目
があちらこちらにあったり、繰り返し項目がDBの中にはいって
いて泣きを見たのは１度だけじゃない。

ただ、すべての案件がDBを１から設計するものばかりじゃないし、
期間と工数が限られてて、後から考えると変な設計したなぁ、という
こともあったのも事実。まぁ、漏れの腕が悪いといえば悪いのだけど、
状況と開発期間によっては>>58の状況もいたしかないと思うけどね。

で、>>56の命題だけど、社宅<->世帯主社員と社宅<->社宅居住社員
の関連表でなんとかならないか？

60 ：名無しさん＠お腹いっぱい。：03/08/29 00:32 ID:???

単純に「居住者」と「借主」を混同しているだけにも見えるが。

61 ：名無しさん＠お腹いっぱい。：03/08/29 21:42 ID:???

設計が悪いって具体的にどういうことなんだろう。項目の選び方が悪いとか？

62 ：名無しさん＠お腹いっぱい。：03/08/29 22:49 ID:wuV7R3ne

>>61
トータルコストに視点を置いてしまえばその場の環境もあり、
単純な正論は無いと思いますけどね。

でもデータベース設計では正規化をまず念頭に置いて間違えでは
ないと思いますが。

63 ：名無しさん＠お腹いっぱい。：03/08/30 01:44 ID:???

>61
求める結果を得るために遠回りな処理をしなければならないような作り、じゃないかなぁ。

上でも出ていた横に長いテーブルなんかその典型例かも。
例えば入金伝票を扱うとする。
ちゃんと正規化されて、伝票の1明細につき1レコードを持つようなテーブル構造になって
いればSQL一発で合計金額が取得できる。
だが、金額1、金額2・・・なんつー持ち方をされたらそう簡単にはいかない、と。

64 ：名無しさん＠お腹いっぱい。：03/08/30 02:04 ID:???

なんか使用人プログラマの愚痴ページになってるな。

65 ：名無しさん＠お腹いっぱい。：03/08/31 00:04 ID:O2kVRfN3

いまやってる仕事が売上分析系で、夜中にあらかじめデータを作って画面表示のレスポンスを
あげる設計なんだけど、やっぱダサい組み方なのかなあ。
ちなみに在庫データ20億件（過去分含む）、商品データ10万件くらい。
（実際には他のデータもある）

きちんと設計すればSQLだけでも対応できるのかな。
これだけ大規模なのは初めてなので教えて君でスマン。

66 ：名無しさん＠お腹いっぱい。：03/08/31 00:11 ID:2xEdmdQc

そこまでデカイと表パーティションとか入れないとキツイでしょうね。

インデックス作るのもアナライズするのもえれぇ時間かかりそう。。

67 ：名無しさん＠お腹いっぱい。：03/08/31 00:17 ID:???

>>65
それって夜バッチで20億件のデータを作ってるの？
OS/DBMSを教えて。

68 ：名無しさん＠お腹いっぱい。：03/08/31 01:14 ID:O2kVRfN3

>>67
Solaris＋某社のマイナーDB。
ちなみに20億は過去分含んでる。1週分は2000万件くらい。
これをもとに「この店/この営業地区ではこの商品がこう推移してる」とかを見るわけ。
夜間は毎日8hくらいかけていろんな切り口のデータを事前作成してる。

さすがにこれだけあると事前にデータ作らないと厳しいかな？
他にこのくらいの規模で仕事した人の体験談きぼん。
（大手スーパーとかコンビニはどうしてるんだろう）

69 ：名無しさん＠お腹いっぱい。：03/08/31 01:35 ID:???

データウェアハウスの分野ですな

70 ：名無しさん＠お腹いっぱい。：03/09/01 23:56 ID:OWqCRzNG

>>68
その元データ20億件のテーブル構造は？
そんだけデカイとCBOだと思うがANALYZE5%でも
3時間以上かかりそう。

20億件のDWHで8時間ならコストに優れていると思ったりした。

71 ：名無しさん＠お腹いっぱい。：03/09/02 00:04 ID:Rwx77e/J

>>68

もしかして
Symfoware？？？？
不治痛とかそういう設計しそう・・・・。

ていうかやってるんだけどね。
漏れのところも。

72 ：名無しさん＠お腹いっぱい。：03/09/02 00:30 ID:???

マイナーDB、とかいってRedBrickとかTeradataだったりして。
あ、SybaseIQならﾏｼﾞマイナーだな。

73 ：名無しさん＠お腹いっぱい。：03/09/02 00:30 ID:GPdlZK1U

長瀬愛ちゃんがセーラー服姿で大奮闘！ちいちゃな身体にルーズソックスがよく似合います。
当然ながらお得意の騎上位での腰振りもやってくれてますのでファン必見です!!その他有名女優が
セーラー服であんな恥ずかしことを．．．！

http://66.40.59.77/index.html

74 ：名無しさん＠お腹いっぱい。：03/09/03 01:49 ID:???

「徹底的に正規化」ってのもいかんと思います。
徹底的に正規化されたため劇遅くなったシステムを多く見てきました
（設計が悪いと言われればそれまでですが）。

いま僕が開発してるシステムは速度優先なので、
正規化しなかった部分が多いです（データの整合性を取らなくてもいい部分が多かった性でもありますが）。

結局ケースバイケースだし、重要なのは正規化することではなく開発者のセンスだし、

正規化バカにはなりたくないものです。

75 ：雑言スマソ：03/09/03 07:01 ID:???

>>74
センスと言い換えてしまうのもちょっと抵抗があるなぁ。
技術だったり、工学だったりするのをマジックに戻してしまう。

単純に速度だけの問題ならば、とりあえず最初にダミーデータ
つくって負荷かければ損益分岐点が客観的にでる気がするし。
それで正規化の度合いと折り合いつけるのもよいし、
マシンおねだりするのもよいし。

76 ：名無しさん＠お腹いっぱい。：03/09/03 16:16 ID:???

>74
言いたい事はわかるけど、ケースバイケースや開発者のセンスに任せた結果
酷い事になってるDBが多いような気がするなぁ。
あくまでも正規化を基本とするのは間違いじゃないと思うけど。

ちなみに私は、正規化されたが為に遅くなったシステムってのは見た事ない。
どんな場合にそうなるの？

77 ：名無しさん＠お腹いっぱい。：03/09/03 16:45 ID:???

>>76 極単純な例で、会員制掲示板システムで、

CREATE TABLE users (
serial_id serial NOT NULL,
sex integer,
age integer,
nickname character varying(32)
)

CREATE TABLE bbs (
bbs_id serial NOT NULL,
subject character varying(256),
body character varying(1024)
)

だとして、掲示板に書いた人の性別、年齢、ニックネームを表示させたいときとか。
これが百万のオーダーになると、

CREATE TABLE bbs (
bbs_id serial NOT NULL,
sex integer,
age integer,
nickname character varying(32)
subject character varying(256),
body character varying(1024)
)

とした方が早いと思うんです。が。

78 ：名無しさん＠お腹いっぱい。：03/09/03 16:51 ID:???

ﾊｧ?

79 ：名無しさん＠お腹いっぱい。：03/09/03 22:53 ID:Pl2K2BAD

77が掲示板と呼ぶものは個別の記事をさしてるの？
だとしてなんでbbsテーブルにusersのserial_idの列がないの？

80 ：名無しさん＠お腹いっぱい。：03/09/04 00:33 ID:???

頼むから正規化しろよ

81 ：名無しさん＠お腹いっぱい。：03/09/04 01:07 ID:???

>>77
単純すぎるよ。
DBを単なるレコードストレージとして使っているようなものだからね。

ただ、誤解しているようなので言っておくが、いまはJOINはそんなに
パフォーマンスは悪くない。

逆に１：Nのリレーションで全件引っ張って１つの表(VIEW)にする場合、
DBのチューニングがうまくいっていれば
１のほうはディスクアクセスは最初の１回だけで２回目以降は
キャッシュメモリから持ってくるのでパフォーマンスがあがる。

>>77の例でも件数によるが、たいていの場合ユーザー情報はユーザー数
分しか読み出されないので、結局正規化したほうがパフォーマンスがよく
なる。

82 ：名無しさん＠お腹いっぱい。：03/09/04 01:15 ID:???

あとBBSの場合、作ってみるとわかるけど書き込んだ当時の情報は残したい場合が多い
たとえ会員制でも。
例えがよくなかったね

83 ：名無しさん＠お腹いっぱい。：03/09/04 14:54 ID:???

> 77
もう１個前提に無理がある
１００万のオーダーに対して全件抽出の
可能性はきわめて低いはず。
最新のN件とかになると、明らかに正規化されていた方が早いはず。

84 ：名無しさん＠お腹いっぱい。：03/09/04 16:27 ID:???

>>79 忘れてました。。

>>81 現状は1Gのメモリをキャッシュで食い尽くしてスワッピングしまくりなんですね。
今はx86ベースなので、次はSPARCかAMD64かってのも考えてます。

>>82 そうですね、僕の開発してる分野では正規化の恩恵はあんまり受けないかも知れないけど、
物流とか金融の開発のことを想像したら、正規かも必要だって思いました。

>>83 いや、管理側で集計取るので全抽出は頻繁にあるのです。

85 ：名無しさん＠お腹いっぱい。：03/09/04 22:29 ID:???

>>84
DBシステムでスラッシング発生させるなんて言語道断。
しょっちゅう発生してるなら、共有ヒープやソート領域のサイズを小さくしろ。

それから、AMD64はともかく、SPARCなんてIA32と比べてそんなに速いもん
じゃないよ。特にひゃくまんにひゃくまんくらいの安いクラスは勝負にならない。
それ以前に、CPUにボトルネックがあるってのをちゃんと検証したのかな？って
疑問もあるが。よっぽど速いディスクなのか遅いCPUなのか...
＃あぁ、なぜかPostgresはOracleと比べてCPUの負荷が高くなりがちだったな。

86 ：名無しさん＠お腹いっぱい。：03/09/04 23:35 ID:???

>>84 いや、linux 2.4.20-20.9 なのですが、空きメモリをがんがんファイルキャッシュに
使って開放してないみたいなんです。

現状足引っ張ってるのはHDDなので、メモリたくさん積みたいな。って。
なのでSPARCかAMD64。久しぶりに Solaris いじってみたいな。

87 ：名無しさん＠お腹いっぱい。：03/09/05 00:15 ID:???

どこに問題があるのか分析できていないまま、とにかく性能の良いマシンに
置き換えて解決しようというパターンだな。

88 ：名無しさん＠お腹いっぱい。：03/09/05 00:20 ID:???

まあ性能のいいマシンに置き換えつつ問題点をなおすのが一番いいし

89 ：名無しさん＠お腹いっぱい。：03/09/05 01:47 ID:???

マシンはお金で買えるしね。

90 ：名無しさん＠お腹いっぱい。：03/09/05 21:50 ID:fFJD8s2p

マスタ(A_TABLE)にコード(PrimaryKey)と名称を保有。
トランザクション系のテーブルにA_TABLEの名称を保有。

．．．．何？この設計。

91 ：名無しさん＠お腹いっぱい。：03/09/05 22:02 ID:???

何ともうされましても・・

92 ：名無しさん＠お腹いっぱい。：03/09/07 02:40 ID:???

>>89
全然関係ないが「超マシン誕生」の一節を思い出した

「アナライザは1万ドルもする。それにくらべて連中の超過勤務手当てはタダだ」

93 ：名無しさん＠お腹いっぱい。：03/09/07 20:08 ID:qGFLzh9Q

>>90
何かの履歴テーブル?

94 ：名無しさん＠お腹いっぱい。：03/09/08 12:06 ID:???

>>74
使ってるRDBのアーキテクチャをちゃんと理解していない奴にSQLを書かせているから性能が出てないだけちゃうんかと。
性能が出ていないのは本当に正規形が理由なのか？
データの整合性が不要ならそもそもDBなんていらんのでは？

ケースバイケースの指針が明解になってない状態では開発者のセンスとか言われても当てにならんだろう。
正規化バカというがこういうことを書く奴に限って、レコード少なくて項目の少ないシステムだと、こんな単純なシステムなら正規化を
する必要もないですよ、とかいうんだろうな。

ものは試しに、きっちりと正規化を行うべきケースとやらをちゃんと書いてみて欲しいものだ。
それを明示できないやつのセンスなど信じてシステムの重大要素であるDB設計など任せる方が怖いよ。

>>82
書き込んだ時点でsexがコロコロ変わるか？それってネカマ管理か（ｗ
ageはbirthdayの導出じゃないのか？age列がドメインとして全く正規化されていないことに気付け。

bbsなら全文検索をしたいとかいうニーズを考える方が先だろう。そうすると、余計な列がないほうがIO上有利に決まっている。
あと管理側で云々というが、それだったらbodyは別テーブルに分けるほうが普通だろ？
管理の為に必要な情報ってのがどういうものかわからんが、user別発言回数なんてのを
countしたいなら、本文は不要だからな。アクセスパターンの分析もせずに物理設計
するなよ。論理設計で手抜きしてるんだからせめてそれくらいはちゃんとやれ。

もまいは正規化やりすぎを語る前に、正規化そのものを勉強しる！精進が足らんだけだ。もっともっとがんがれ！

95 ：名無しさん＠お腹いっぱい。：03/09/08 13:03 ID:???

sexやageなんて例、見てなかったし気にしてもいなかったな
実際にシステム組んだ時に思った事書いただけだ

96 ：74：03/09/08 22:45 ID:???

>>94 僕はあなたの日本語がわかりません。

97 ：名無しさん＠お腹いっぱい。：03/09/09 08:17 ID:RHS5R/v2

>>94
あなたの言いたい事は理解出来るが、煽り口調ですな。
もうちょっと紳士的にお願いします。
確かに｢整合性を無視した設計｣は論外ですがね。

98 ：名無しさん＠お腹いっぱい。：03/09/10 20:02 ID:YlwmCvt9

｢正規化する｣ってことは外部キーを定義することまで含まれますかね？

現在あるシステムのカスタマイズを行っているんですけど、
現行のＤＢ設計者はいないし、テーブルの制約が多すぎて
にっちもさっちもいきません。

ディクショナリをいろいろ調べてＥＲ図興して。。。
あぁ。。制約を設定しすぎるのも後々ツラかったりしませんか？

99 ：名無しさん＠お腹いっぱい。：03/09/10 21:57 ID:tGVyPlm+

そんな状態で制約がなかったら、あり得ないデータがいっぱい出て来て手に負えなくな
っちゃうよ。

100 ：名無しさん＠お腹いっぱい。：03/09/11 00:13 ID:o1HVsw0d

>>34
もしかしたら、それ漏れのプロジェクト？
某クレジットのシステム？

ＪＯＩＮ禁止ってのになんか見覚えが・・・。

101 ：名無しさん＠お腹いっぱい。：03/09/17 21:17 ID:tJ3tjEnR

>>100
不治痛にて...
JOIN禁止
SELECTは*で
SQLは外出
...あっほーーー

102 ：名無しさん＠お腹いっぱい。：03/09/17 22:43 ID:sZz9Ze2C

つっかっもうぜ！データーベーエス！！

103 ：名無しさん＠お腹いっぱい。：03/09/18 22:10 ID:LMoUfHJC

MySQLなんでサブクエリー使えないんで、下手に正規化するとにっちもさっちもいかなくなります。ぐすん

104 ：名無しさん＠お腹いっぱい。：03/09/19 08:51 ID:???

4.1に期待.

105 ：名無しさん＠お腹いっぱい。：03/09/24 14:27 ID:HDcPR1MU

正規化されていないデータベースで開発やるとき、
単体テストなどで、テストデータ作るのがめんどいよ。
列が１００以上あってさ、１０レコードぐらい作るのにも
ホネだよ。

以上２年目のプログラマの愚痴でした。

106 ：あぼーん：あぼーん

あぼーん

107 ：名無しさん＠お腹いっぱい。：03/09/24 23:28 ID:kgwakjbU

>>105
あ～わかるそれ！俺OracleでSQL*PlusしかDBﾂｰﾙ知らんからね。
INSERT INTO HOGE VALUES('111',222,'333',444,'555',,,,,,,,,,,,
あ～あ。。めんどくせ。

108 ：名無しさん＠お腹いっぱい。：03/09/27 02:38 ID:???

>>107
shでもPerlでもいいから何かしらそういう系の
スクリプト言語を覚えることをお勧めする。
捏造データ作るためのSQL文生成なんぞ容易い。

109 ：名無しさん＠お腹いっぱい。：03/09/29 00:04 ID:ULtVDCM9

不治痛にて
ホストからRDBに移行するための条件が、
「テーブル定義はホストを同じで」
何のためにRDBにするの？
金の無駄。だから赤になるんだな。

110 ：名無しさん＠お腹いっぱい。：03/09/29 22:47 ID:/Lm4/xCe

今、C/SからWeb化する仕事を不治痛でやってる。
やはり「テーブル定義は前と同じで」

糞みたいなＤＢ設計をそのまま継承するとは。。。

111 ：名無しさん＠お腹いっぱい。：03/09/29 22:54 ID:???

>>94 みたいな勉強になる書き込み、もっと出てこないかな…
突っ込みどころのある課題がないとダメか。。

112 ：名無しさん＠お腹いっぱい。：03/09/29 22:55 ID:???

>>110
DB設計がそのままなら、せめて最適化に命をかけてください。

113 ：名無しさん＠お腹いっぱい。：03/09/29 23:13 ID:???

汎用機が全盛の頃は、DB構築は期間と個工数のかかる結構面倒な作業でした。
だからDBを一度構築した後でDB構造を変更するのは、極力避けなければなりません。
そのため、まず紙と鉛筆の世界で正規化手法に従ってDB設計をキッチリ行ってから、
構築作業をはじめたものです。
最近は、ACCESS/ORACLE/SQL鯖等、パソコン系のRDBが発達し、DB構築に
データ構造の変更が容易になったせいか、正規化手法を理解していない
若いSEが増えてきたように思えます。
プログラム開発中にデータ構造を変更すると、プログラムの変更を
余儀なくされ、結果、余計なコストもかかります。

XPなど新しい開発手法がもてはやされている現在でも、
DB設計などはウォータフォール的なやり方も必要だと考えます。

以上、おっさんの愚痴でした。

114 ：名無しさん＠お腹いっぱい。：03/09/30 00:01 ID:???

半年くらい前から組んで仕事をしてる上司は、正規化という言葉をしりません。
「リレーションにする」とか「テーブルを分ける」とか、そういう言葉で表現してます。
SQLも自力ではかけなくて、AccessにSQLを生成させて、それをコピペしてます。

今度の仕事はMSDEでやりましょう。と提案すると、少し動揺したような顔をしたの
で、Accessからも接続できますよと説明すると、上機嫌になりました。

ハッカージャパンのような厨房雑誌ばっかり読んでないで、普通のDBの入門書
でも読めばいいのにと思うのですが。
(ハッカージャパンにしても、よくPerlのスクリプトとか載ってるようだけど、
上司はPerlもCも使えないようだし、なにを読んでるのだろうかと思う)

115 ：名無しさん＠お腹いっぱい。：03/09/30 00:54 ID:???

>115
危険だな。
Accessからリンクはって全てを解決した（つもり)のプロジェクトになりそう。

116 ：名無しさん＠お腹いっぱい。：03/10/01 16:25 ID:1gbbeq+m

PrimaryKeyの項目が多い表についての正規化をどのようにすべきか検討しています。

例) TABLE_A:TABLE_B = 1:n

TABLE_A(PrimaryKey:a,b,c,d,e)
a,b,c,d,e,fffff

TABLE_B(PrimaryKey:a,b,c,d,e,g)
a,b,c,d,e,g,hhhhh

上記のTABLE_Aは500万件程度、TABLE_Bはおそらく5000万件程度の大規模な
DBになると思われます。

で、上記のような構成だとINDEX領域にかなりの無駄があると思います。
ほかにうまく関連付け出来る方法はありますか？

117 ：名無しさん＠お腹いっぱい。：03/10/01 21:06 ID:???

TABLE_A(a_id, a,b,c,d,e, fffff, PK(a_id), UNIQUE(a,b,c,d,e))
TABLE_B(a_id, g, hhhhh, PK(a_id,g))

118 ：名無しさん＠お腹いっぱい。：03/10/01 22:26 ID:R3mBVKRL

a_idは、TBLE_Aの挿入時にアプリケーションで採番するような
イメージですか？

119 ：名無しさん＠お腹いっぱい。：03/10/01 22:34 ID:???

>>114
その上司はSE?PM?
データベースの論理設計をやったことない人なら正規化という言葉を
知らなくても無理ないかもね。

ちなみに業務要件は知りませんが、MSDEはやめたほうがいいと
思ったりしてみました。

120 ：名無しさん＠お腹いっぱい。：03/10/01 22:38 ID:???

>>118
イメージ的には多分そうでしょう。
でも採番はDBEにやらせたほうがいいと思いますよ。

OracleならSEQUENCE
SQLServerならIDENTITY
その他のDBMSでも同様の機能はあるでしょう。

121 ：名無しさん＠お腹いっぱい。：03/10/01 23:37 ID:???

>>117
not null 忘れないようにな。

122 ：名無しさん＠お腹いっぱい。：03/10/03 23:38 ID:ZPfMotMT

なんでもかんでもDBAのせいにするのは良くないと思う。
だってDBAではある程度｢正規化｣ってのは当たり前だしょ。

アプリ開発部隊が｢これエラーになっちゃうんですけど？｣
っていわれると、だいたいＳＱＬの書き方が悪い。

123 ：名無しさん＠お腹いっぱい。：03/10/04 14:55 ID:???

>>122
> アプリ開発部隊が｢これエラーになっちゃう(ry
それはDB設計の話とは関係ないだろ。

124 ：名無しさん＠お腹いっぱい。：03/10/04 16:07 ID:???

>>123
スマソ。表現間違った。
例えば、不必要にサブクエリを大量に発行していたり、
わざわざテーブルスキャンするようなSQLだったりね。

125 ：名無しさん＠お腹いっぱい。：03/10/06 23:09 ID:8DA89W7m

>>124
サブクエリはストアドにしますか？そのまま書きますか？

どうしてもな場合、ストアドにして提供したら？

126 ：名無しさん＠お腹いっぱい。：03/10/08 20:36 ID:???

ある客先で仕様書の雛形見せられたんだけど、これがすごく香ばしい。

正規化なんか「第一正規化」「第二正規化」「第三正規化」の順にやりなさい
とか、（第一正規系はこうなって・・・というのを書く欄がある）処理時間見積り
を仕様書に書くようになっているし（マシンが変わったらどうするつもりだ？）
そのくせ、項目一覧にキー（PKとか外部キーとか）を識別する欄がない。
ER図も書かなくていいらしい。

＃別に処理見積もりをするなとか、正規化するなとか行っているんじゃなくて
＃んなもん、仕様書に書くなということをいいたかった。

なんか、去年くらいからやったプロジェクトの成果だとか自慢してたけど
どうもシスアドとってすぐに配属されたような人間ばっかがやったようなもの
としか思えなかった。

127 ：名無しさん＠お腹いっぱい。：03/10/08 23:13 ID:???

仕様書って・・・
プログラマにそれをやらせるのか・・・
香ばしいというより・・・

128 ：名無しさん＠お腹いっぱい。：03/10/09 00:15 ID:???

ある程度までは、正規形ってさ、マトモな人間なら最低限持っている
合理的思考をちょいと体系的な知恵にしたようなもんだし、
特に意識しなくても第三くらいまでは普通に出来てしまうもの。

なんでわざわざ第一からやらせるんだろうか・・・
試験勉強の弊害か？

通した上の人間もかなりヤバいと思う。

129 ：名無しさん＠お腹いっぱい。：03/10/09 00:42 ID:???

>>128
世の中には常軌を逸した人がいるからだよ。

130 ：名無しさん＠お腹いっぱい。：03/10/10 20:54 ID:GiDrGrOC

>>126
昔、UNI○YSでそんなDB設計書見たことある。
結局そんなドキュメントはWrite Only。

開発者は項目定義とER図さえあれば、事足りると思うんですがね。

131 ：名無しさん＠お腹いっぱい。：03/10/10 21:25 ID:???

な～んか遅せぇな。と思いクエリを調べたら
冗長化されたテーブルを無条件でSELECT *してた。
（しかもクライアント・カーソルで）
キャッシュヒット率30%だって。

もう今週でPRJ外れるから関係ねぇけど、使いモンになんねぇよな。　

132 ：130：03/10/10 21:48 ID:???

すまん。無意味にageしてしまった。

133 ：120：03/10/12 00:23 ID:???

>>131
そんなこと言わず、ガムバッテ下さい。SGA2GBにして
キャッシュヒット率100%目指すべし！

134 ：名無しさん＠お腹いっぱい。：03/10/13 10:18 ID:???

>>133
絶対に100にはならんだろ
せめて99%って書こうよ

135 ：NAME IS NULL：03/10/13 12:27 ID:???

>>134
>>133ではないが100%に絶対ならないの？
例えば、データブロックサイズ１個がSGAより小さくて、PrimaryKeyで
SELECTしたら、100にならない？

136 ：NAME IS NULL：03/10/13 23:01 ID:???

>>135
たぶんそれでも100は無いと思います。
インデックスやディクショナリを読みにいきますから。
（嘘かもしれんけどね）

137 ：NAME IS NULL：03/10/14 17:14 ID:Ji699eh5

正規化とは関係ないけど、テーブル設計で質問。

区分ってあるじゃない。性別区分とか処理区分とか売上区分とかいろいろいろ…
そういう「区分」ってアプリケーション内部で
if(sex == 1){ printdata = 男 } elseif(sex == 2) { printdata = 女}
みたいに処理してしまうんだけど、本来は区分毎に一つのテーブルもたせるべきなのかな?

138 ：NAME IS NULL：03/10/14 17:27 ID:???

>>137
男テーブルとか女テーブルとか作るってこと?

139 ：NAME IS NULL：03/10/14 18:06 ID:???

商品名と商品IDみたいに種類が多くて更新も多いなら当然別ﾃｰﾌﾞﾙだろうけど。
性別は2種類って決まってるから、いっその事"男"、"女"で入れてしまうとか。。

140 ：NAME IS NULL：03/10/14 18:10 ID:???

処理区分みたいなのは途中で増えたりする可能性もあるけど、
ﾌﾗｸﾞ的な意味しか持ってないと別ﾃｰﾌﾞﾙにしようが無いような。
DBには数値で入れといて、ﾌﾟﾛｸﾞﾗﾑ側で定数に置き換えてｺｰﾃﾞｨﾝｸﾞ
する人間が分かりやすい形にして終了かと。

141 ：NAME IS NULL：03/10/14 18:24 ID:???

たとえば>>137の例では、1というDB内の数字と男性という現実の
属性を結びつける理屈はDB内には存在しない。

そうするとプログラム内にルールを作らなければならないけど、
ルールがプログラム全体に正しく周知されているかどうか
チェックするのは非常にめんどい。
何かしらの都合でルール変更があったりしたら更に大変。

だから、個人的には>>137みたいな実装はお勧めしたくないなぁ。

また、別の話題として、性別にyes/no型（boolean型）を使うかどうかも
本来ちゃんと検討しなくちゃならない。
「性別は2種類」は現実としてはその通りだとしても、DBでの取り扱い上
本当に2値しか取らないのか？ということ。
たとえば、性別不明でも登録可能な設計にする可能性があれば、
やはり2値はまずいだろう。nullで逃げるのも好ましくない。

142 ：137：03/10/14 20:56 ID:hj6tt/FH

あ、例を性別にしたのはまずかったかな。
2値にとらわれないでください。

で、思いついたのがこんな↓テーブル

<T_KUBUN>
NAME, ID, VALUE
"性別", 1, "男"
"性別", 2, "女"
"売上", 1, "売上"
"売上", 2, "返品"
"関係会社", 1, "得意先"
"関係会社", 2, "仕入先"
"関係会社", 3, "その他"

とまあこんな感じでシステムで使用する区分をひとまとめにした
テーブル(区分マスタ)を用意したら便利なのかどうなのか??

select t_syain.simei, t_kubun.value
from t_syain join t_kubun on t_syain.sex = t_kubun.id
and t_kubun.name = '性別'

こんな風につかうです。やっぱヘン?

143 ：NAME IS NULL：03/10/14 22:08 ID:???

>>142
それはちょっと・・・
完璧に正規化から外れるし、使いやすいとも思えない。

144 ：137：03/10/14 23:02 ID:hj6tt/FH

そっか。やっぱヘンかあ。
でも「SQL書いて貼り付ければ画面も帳票もできちゃうよ」ってフレームワーク
使ってたりすると、SQLレベルで全ての項目が揃うのが便利なのだよね。
よくOracleなんかでDECODEだらけになってるSQL見てて、なんとかならないのかと
思ったけど。結局アプリに使う言語レベルで纏めるのが一番いいのかな。

ところで。
全くこれ以上増えも減りもしないよ。という区分でも、値が20こくらいあったら
きっと多くの人はアプリに埋め込まずにテーブルにすると思う。
区分のテーブル化とアプリに埋め込む判断基準は何で線引きするべきなんだろう?
徹底的に正規化すべし!! と言うのに乗っ取ると、区分の値がいくつであれ区分毎に
「なんちゃら区分マスタ」を作るのが正しいのかな?

145 ：NAME IS NULL：03/10/14 23:05 ID:???

＞区分のテーブル化とアプリに埋め込む判断基準は何で線引きするべきなんだろう?
僕は一桁(9個まで)位でわけてますね。

146 ：NAME IS NULL：03/10/15 00:46 ID:???

DBMSによっても変わってくるね。
独自の方をユーザ定義できるならそれを使う、と。

147 ：NAME IS NULL：03/10/15 11:29 ID:MmiJnUGS

>>138
てかさ、何で男/女を1/2とかにマッピングするの？性別テーブルとか性別配列とかがあって、マッピング値と実値との関連がはっきりしているならまだしも、そんなもん無いんでしょ？どうせやるならM/Fの方がまともだと思うがなあ。

148 ：NAME IS NULL：03/10/15 11:56 ID:???

M/Fって何？

149 ：NAME IS NULL：03/10/15 14:58 ID:???

male/female　では？

150 ：NAME IS NULL：03/10/15 16:11 ID:???

何万件もある品目コードとか正規化してなくってさ。
どこがＤＢなのかと問い詰めたい。

151 ：NAME IS NULL：03/10/15 16:30 ID:???

>>144
たとえば、DECODE(SEX,1,'男','女')みたいなものは
Viewで提供しちゃうとか。
まぁそれも管理し辛くなるかも。

152 ：NAME IS NULL：03/10/15 16:33 ID:???

どちらにせよ、アプリでハードコーディングするような処置は避けたいですね。
if ( db.fileds("SEX") == 1 ) {
printf("男");
} else `
printf("女");
}
とかね。

153 ：NAME IS NULL：03/10/15 16:39 ID:???

これからの時代を考えると最低でも
1　男
2　男(タマ無しサオ有り)
3　男(タマ有りサオ無し)
4　男(両方無いが遺伝子はXY)
くらいは視野に入れておかないとね。

154 ：NAME IS NULL：03/10/16 11:18 ID:???

>>152
そうすると残された選択肢は何？

155 ：NAME IS NULL：03/10/17 00:02 ID:???

>>153
それなら逆も考えないと

あ、タマは無いよな(w

156 ：NAME IS NULL：03/10/17 04:24 ID:???

>>154
私は普段、iniファイルとかに定数として書いてますよ。

157 ：NAME IS NULL：03/10/21 03:15 ID:???

コンスタントはテーブルで持て

158 ：NAME IS NULL：03/10/21 17:55 ID:???

>>157
そのココロは？

159 ：NAME IS NULL：03/10/21 18:55 ID:RC3MFIe1

>>158
なんか有る時にSQL使いたいから。

160 ：NAME IS NULL：03/10/23 17:46 ID:fNG7AZNH

>>154

１）全てをマスタデータとしてDBに定義し、
　　そのデータをアプリケーション側でキャッシュする。
　　男女の区分など変わらないものはキャッシュ期間を無期限にする。
２）コードと人間の見た目の対応を、
　　外部のプロパティーファイルとして定義する。

前者はマスタとして
　　<SEX>
　　1: 男
　　2: 女
が定義され、このオブジェクト構造をアプリケーションが保持する。
多くの場合アプリケーション起動時に一度DBに問い合わせるだけになる。
変更はテーブルにアップデートをかける。

後者は
　　<SEX>
　　1: MAN
　　2: FEMALE
を固定的に定義し、プロパティファイルとして
　　MAN=>"男"
　　FEMALE=>"女"
とか
　　MAN=>"殿"
　　FEMALE=>"姫"
を配付する。

この手の変わらないと思われるコードは、国際化仕様を考えると
合理的な解法が見えてくる場合もあるかと。

161 ：NAME IS NULL：03/10/24 09:16 ID:???

>>160
なんでMAN,FEMALE？
MALE,FEMALEだろ？
DBの勉強する前にEnglish勉強して下さい．．．

162 ：NAME IS NULL：03/10/25 15:26 ID:???

(･Θ･) < トライアル逝ってきますた

163 ：NAME IS NULL：03/10/29 06:05 ID:???

>153
男、女、その他で、実態とずれてきたら増やせばいいだろ。

164 ：NAME IS NULL：03/10/31 01:26 ID:???

すいません、根本的なことで恐縮なんですが、
ユーザの都道府県情報なんかも、
都道府県マスタみたいのつくって、正規化するべきなんでしょうか？

165 ：NAME IS NULL：03/10/31 02:32 ID:???

>>164
するかどうかはデータにもよると思うけど～
県コードはJISとかから持ってくよろし

166 ：NAME IS NULL：03/10/31 20:53 ID:3MZ7Eppj

>>164
それは第３正規化のカテゴリーですな。

167 ：NAME IS NULL：03/11/01 01:06 ID:hqmy3kq3

県コードって正規化というよりも、
何でも数字で打ちたいキーボードの鬼向けの入力支援のために
わざわざソースや演算経路を複雑にする行為であって、
別の必要な情報で間接的に得られるので正規化というわけでもあるまい。

168 ：NAME IS NULL：03/11/01 01:11 ID:???

> 何でも数字で打ちたいキーボードの鬼向けの入力支援のために
> わざわざソースや演算経路を複雑にする行為であって、

そりゃ偏見入りすぎ。
見た目はともかく、内部的に日本語の文字列を
識別子として扱うこと自体に少なからずリスクがあろうに。

169 ：NAME IS NULL：03/11/01 04:40 ID:???

郵便番号

170 ：NAME IS NULL：03/11/02 04:16 ID:???

〒？

171 ：NAME IS NULL：03/11/05 23:30 ID:Lx8TiKNF

オレのスキルを正規化したら第一正規化で終っちゃいますた。

種別　| 内容
------+------
言語　| COBOL

....以上

172 ：NAME IS NULL：03/11/06 11:37 ID:???

>>171
それって第一正規化とゆーんだっけ？

173 ：NAME IS NULL：03/11/06 12:03 ID:???

174 ：NAME IS NULL：03/11/06 17:24 ID:???

>>173
右詰になってよくわかりまへん。
言語：F-BASIC?/ASM/PLi/COBOL/C/VB/C++/Java/C#

175 ：NAME IS NULL：03/11/06 22:09 ID:???

>173
>174
左詰に見えるんだが......

176 ：NAME IS NULL：03/11/06 22:12 ID:???

>173
少なくともこんな表を書いているうちはデータベースの設計は任せたくないな。

177 ：NAME IS NULL：03/11/06 23:00 ID:???

あるフィールドの値に、隣のフィールドの意味を設定する人いるよね。
それで１０００フィールドぐらいあって、
同じ意味のものの位置が行によってどんどんずれるという設計。
ああいうのと連携する仕事が来たらどうしよう。

178 ：NAME IS NULL：03/11/07 01:47 ID:???

>>177 いるよね・・っていねーよ。
そういうのがきたら、パーサー書いて
スクリプトとして処理するしかないな。

179 ：NAME IS NULL：03/11/07 18:07 ID:/RTzaVIz

artist | title
モーニング娘。 | LOVEレボリューション
モーニング娘。 | Peace!

みたいな感じにテーブルを作りたくて、
こうしたら
select * from table where artist='モーニング娘。'
とかで検索できるけど
select * from table where artist='モー娘。'
みたいに別名でも検索できるようにしたいっていう場合って
テーブルはどんな風に設計すれば良いの？

180 ：NAME IS NULL：03/11/07 19:28 ID:???

181 ：NAME IS NULL：03/11/07 19:43 ID:???

>>180
別名ぐらいは極力明細にせず、上限１０個とかで入れちゃった方がいいと思う。
やり過ぎるとシステムが重くなる。

artist
id | name | nickname1 | nickname2
1 | モーニング娘。 | モー娘。 |
2 | つんく | |

music
id | name
1 | LOVEレボリューション
2 | Peace!

artist_music
artist_id | music_id
1 | 1
1 | 2
2 | 1
2 | 2

182 ：NAME IS NULL：03/11/08 00:32 ID:9gnAoqkR

>>181
このテーブル構成で
artist=松浦あや/music=桃色の片思い
を挿入するとき効率がいいSQLってどんなかんじ？

183 ：NAME IS NULL：03/11/08 01:16 ID:???

>>181
痛いぞ

184 ：NAME IS NULL：03/11/08 01:21 ID:???

>>182
artistあややある？(select)
　ある＞あややのartist.id(σ･∀･)σｹﾞｯﾂ
　ない＞あやや登録(insert)
music桃色の片思いある？(select)
　ある＞桃色の片思いmusic.id(σ･∀･)σｹﾞｯﾂ
　ない＞桃色の片思い登録(insert)
artist_musicあややの桃色の片思い登録されてる？(select)
　ある＞がいしゅつ
　ない＞artist.id/music.id登録(insert)

SQLてゆうかロジックだ（ｗ
最後だけいきなりinsertするのもありかな？（僕はしないけど

185 ：NAME IS NULL：03/11/08 01:45 ID:6qfeikX1

>>182-184
林檎殺人事件を郷ひろみでも樹木希林でもヒットさせたい時どうするの？
林檎殺人事件を２重登録するの？林檎殺人事件に関するもっと多くの付随情報があったら？

186 ：180=184：03/11/08 02:16 ID:???

>>185
artist
id | name　　　　　　 | nickname1 | nickname2
1 | モーニング娘。　| モー娘。　 |
2 | つんく　　　　　　|　　　　　　　 |
3 | 松浦あや　　　　| あやや　　 |
4 | 郷ひろみ　　　　|　　　　　　　 |
5 | 樹木希林　　　　|　　　　　　　 |

music
id | name
1 | LOVEレボリューション
2 | Peace!
3 | 桃色の片思い
4 | 林檎殺人事件

artist_music
artist_id | music_id
1 | 1
1 | 2
2 | 1
2 | 2
3 | 3
4 | 4
5 | 4

これじゃだめ？
＞林檎殺人事件に関するもっと多くの付随情報があったら？
当初の話(>>179)に入ってないから入れてないだけじゃ・・・。

187 ：NAME IS NULL：03/11/08 02:31 ID:6qfeikX1

>>186
だめじゃないけど>>181と同じじゃん。ｗ
もっといい方法があるのかと思った。

188 ：180=184：03/11/08 03:04 ID:???

ありゃ、>>181を使って>>185するにはどうするのかって意味と勘違いした。
＞もっといい方法があるのかと思った。
データはこんなもんでいかに登録・検索しやすいPGを書くか。だと思う。。。

189 ：NAME IS NULL：03/11/08 04:01 ID:6qfeikX1

>>188
>>181はＳＥの癖で、要件自体に見落としがある可能性を示唆するためのものだったので。
テーブルが駄目だとＰＧで工夫しても駄目システムになってしまうので。
項目（フィールド）については客も気付きやすし後から追加しやすいんだけど、
構造については客は気付かないことが多いし後から変更しにくいので。

190 ：NAME IS NULL：03/11/08 12:05 ID:???

>>184
それってMAX６回SQLコールするんでしょ？なんか効率悪いんじゃ。

ロジック組まなくてもINSERT FROM SELECT～みたいな
SQLで一発でいかないかい？

今、テスト環境が無いんで検証は出来ませんが。

191 ：NAME IS NULL：03/11/08 16:37 ID:6qfeikX1

>>190
>>184じゃないけど、
全部まとめて１個のストアドにすればいいんじゃん？
つーか書き込みアクセスでそれほど効率を気にする必要はないと思うが。

ｍｄｂだかどうか忘れたけど、クエリに書き込める場合もあるよね。そのことかな。
だけど構造によっては拒否されたり誤動作する場合もあるし、
ＳＱＬＳｅｒｖｅｒとかＯｒａｃｌｅとかだともともと無理だったような。
ＯＤＢＣを介するとできる場合があるんだっけ？
でも怪しいので、素直な直書きロジックで、速度が気になるならストアドっていうのでいいと思う。

192 ：180=184：03/11/08 17:07 ID:???

>>189
検証は大事だよねー。
>>190
え、どんなのか知りたい。。。
>>191
ま、DBが特定されればそうだろうねー。
むしろ、質問者179さんが「何を作ろう」としているのか分からないので
これ以上の話が出来ないんだとおもうんだよなー。
自分用の所有リスト作りたいだけなのか、
何かしらのシステムなのかも分からんのじゃ。。。

193 ：NAME IS NULL：03/11/08 20:01 ID:???

トランザクションということを考えると出来る限り、
1発でUPDATE/INSERTというのは基本だと思います。
ですから、複数のテーブルにINSERTする場合にSQL１発で行かないとき
などは、僕はストアド推奨派ですね。
1発で書いておけば、フォワードリカバリとかする場合にも問題が
少ないしスマートです。

もちろんシステム全体のトレードオフが最優先検討事項ですが。

194 ：NAME IS NULL：03/11/08 20:52 ID:???

>>181
＞別名ぐらいは極力明細にせず、上限１０個とかで入れちゃった方がいいと思う。
頼むから正規化しろよ

195 ：NAME IS NULL：03/11/08 21:52 ID:???

>>193
トランザクション切ってやってる限り一発にこだわらんでええっしょ。
何のためのトランザクション？
それと、今例に挙がってるくらいのものならともかく、もっと複雑な条件を
要するジョブを大量に発行するときのことを考えると、闇雲に
長いSQL文で実現するのはお勧めできない。

というのも、文自体が長くなってくると、perserやoptimizerの負担が
馬鹿にならなくなってくるからだ。
SELECT部自体の実行時間もどんどん長くなる。
SQL文一発っつーのは、見た目は美しいけどDBにとってはたまったもんじゃない
というのもままあること。

ま、データ規模や要件によって事情は変わってくるけどね。

196 ：NAME IS NULL：03/11/08 23:48 ID:???

明日は衆院選挙じゃ。みんな行くのか？

自民党が政権握ったら、俺ら弱小ソフトウェアハウスの
未来は更なる悲惨な運命を辿るだろうな。

197 ：NAME IS NULL：03/11/09 00:10 ID:???

民主党なら助かるのかといえばそれも怪しい・・・
政権取るなら取るで本格的に長期のビジョンがなきゃならんけど、
どうも民主党上層部はその辺甘い。ワイドショー政治に満足している。

なんにせよ、この板から首吊りが出ないことを祈るよ。

198 ：NAME IS NULL：03/11/09 00:21 ID:???

俺が政権獲ったら、システム開発に限り完全に鎖国化するけどね。

今、日本のソフトウェア産業は９割以上、俺ら弱小ソフトウェアハウスが
担ってる事実を政治家の先生方は認識しているのか？

199 ：NAME IS NULL：03/11/09 03:17 ID:???

当然共産党に入れます。入れないとサービス残業が放置されます。

200 ：NAME IS NULL：03/11/09 09:57 ID:???

200ゲット！

201 ：NAME IS NULL：03/11/10 01:09 ID:???

>185
RDBつーよりは全文検索とかの世界じゃやないかなー。

202 ：NAME IS NULL：03/11/10 01:15 ID:???

>>201
Namazuですか

203 ：NAME IS NULL：03/11/10 05:06 ID:???

>>201
それだと検索が遅いだけでなく区切り文字、引用符の処理でかえって複雑化するし、
同名アーティストへの対応もできないし、入力の手間も増え、入力ミスにも対応できない。
また、様々な集計等への再利用もできない。

204 ：NAME IS NULL：03/11/11 13:16 ID:OlXELN3R

一つのフィールドが二つ以上のテーブルの主キーに依存するようなテーブル
設計は×でしょうか?

例えば
<受注情報テーブル>
受注ID, 受注年月, … 顧客区分, 顧客ID

というテーブルがあるとして
顧客区分が1の場合は顧客IDは<個人情報テーブル>の個人ID
顧客区分が2の場合は顧客IDは<法人情報テーブル>の法人ID
という場合、正規化にのっとって正しく設計した場合はどのようになるのでしょうか?

(そもそも個人と法人をわけたまま扱うことが云々…というところは無視して下さい)

205 ：NAME IS NULL：03/11/11 18:09 ID:rgxeXVwa

>>204
ケースバイケースですね。重くなるとか、他の再利用の仕方にとって簡単かどうかとか。
例えば、受注情報テーブルの顧客IDをやめて個人IDと法人IDの２フィールドにした方が
DBサーバにとっては負担が軽いですかね。やってみないと分からないですけど。
それぞれ普通に１本線のリレーションになるので。
それで、同じ列に表示したい帳票があればISNULL(個人ID,法人ID) AS 顧客IDとか。
この場合だと顧客区分は個人IDと法人IDのどっちがヌルかで計算値として出せますね。
でも処理速度に影響があるなら顧客区分をあえて冗長性保存した方がいい場合もあるだろうし。

206 ：NAME IS NULL：03/11/11 22:11 ID:???

>>204
俺なら、顧客IDマスターを置いておいて、3テーブルともその
マスターを参照するようにするかな。

207 ：NAME IS NULL：03/11/11 23:35 ID:rcetuSKt

>>204
顧客マスタ:顧客区分+顧客ID+その他属性情報
受注テーブル:受注ID+受注年月+顧客区分+顧客ID+その他受注情報

結局、顧客区分+顧客IDでユニークになるわけですよね？
顧客IDの頭1バイトを顧客区分として保有させるよりは
いいと思いますよ。

受注情報のDWHを意識するなら受注情報テーブルの顧客区分+顧客IDに
インデックスを張りましょう。

208 ：204：03/11/12 09:05 ID:ExumycNy

ありがとうございます。とても参考になります。
特に正規化の手法から逸脱しているというわけではないのですね。

パフォーマンスはおいといて、設計の美しさのみを求めた場合、>>204に挙げた
三つのテーブルはどのように設計し直すべきでしょうか?
やはり>>206さんがいわれるように、間に一つテーブルをかませて抽象化(?)する
のが理想的でしょうか?

209 ：NAME IS NULL：03/11/12 23:17 ID:e45CXKa/

正規化云々の前にキーをどんどん追加して
とりあえず整合性を保とうとするのはやめてくれ・・・

今なら間に合う。ちゃんと設計しようぜ。
つうか、俺にやらせてくれ頼むから。

210 ：NAME IS NULL：03/11/12 23:36 ID:Q3Q0AoRx

キーをどんどん追加して整合性を保つって、どんなことするんだろう？
とりあえずでもなんでもいいから、実例ｷﾎﾞﾝ

211 ：NAME IS NULL：03/11/14 18:40 ID:GDfRaqTR

>>185

作品テーブル

作品ID｜作品名
-------------------
00001｜林檎殺人事件
-------------------
00002｜夏色の片思い
-------------------
00003｜ダンディライオン

アーティストテーブル

アーティストID｜アーティスト名｜種別ID
--------------------------------
00000000001｜郷ひろみ　　　｜000001
--------------------------------
00000000002｜樹木希林　　　｜000001
--------------------------------
00000000003｜松浦あや　　　｜000001
--------------------------------
00000000004｜松任屋由美　｜000001

212 ：NAME IS NULL：03/11/14 18:41 ID:GDfRaqTR

（続き）

ニックネームテーブル(ネームIDはいらないと思う)

アーティストID｜ネームID｜別名　　　
--------------------------------
00000000001｜0000001｜ひろみ　　　
--------------------------------
00000000001｜0000002｜Go　　
--------------------------------
00000000002｜0000001｜きききりん　　　
--------------------------------
00000000003｜0000001｜あやや　　　
--------------------------------
00000000003｜0000002｜ayayaya　　　
--------------------------------
00000000003｜0000003｜ぱぱや　　　
--------------------------------
00000000003｜0000004｜ままや　　　
--------------------------------
00000000004｜0000001｜荒井由美　　　
--------------------------------

アーティスト種別テーブル
種別ID｜種別名称
---------------------------------
0000１｜ボーカル
---------------------------------
00002｜作詞
---------------------------------
00003｜作曲
---------------------------------
00004｜ギター
---------------------------------
00005｜ボーカル

213 ：NAME IS NULL：03/11/14 18:43 ID:GDfRaqTR

更に続き

作品参加アーティストテーブル

作品ID｜アーティストID
---------------------------------
000001｜00000000001
---------------------------------
000001｜00000000002
---------------------------------
000002｜00000000003
---------------------------------
000003｜00000000004

214 ：NAME IS NULL：03/11/14 18:45 ID:GDfRaqTR

フリーハンドで書いたからいっぱい変なところが有る。
面白いから、貶せ。

215 ：NAME IS NULL：03/11/15 02:51 ID:???

ｵﾓﾛｲ

216 ：NAME IS NULL：03/11/15 03:25 ID:WX6Q4llT

何がおもろいのか分からんが、
種別ＩＤは”正しくは”アーティストテーブルじゃなかんべ。
「その曲への関わり方」だから。
しかし、場合によってはその違いを別人として扱いたいという
要望もあるので、なんとも言えん。
あと、検索支援でしかない別名のためにリレーション負荷かけて
レコード数数倍にして返させる意味はあまりない。

217 ：NAME IS NULL：03/11/15 21:38 ID:???

ダンディなライオンって…。
どんなライオンだろう…。

218 ：NAME IS NULL：03/11/17 05:57 ID:???

ダンディなライオンです

219 ：NAME IS NULL：03/11/17 10:37 ID:???

dandelion タンポポだよ

220 ：辞書よりコピペ：03/11/17 13:05 ID:???

>>219
【フランス語「ライオンの歯」の意】

221 ：NAME IS NULL：03/11/17 14:48 ID:???

カタカナ表記ならダンディじゃなくダンデだろ。

222 ：NAME IS NULL：03/11/23 01:43 ID:???

頭いいのはわかったからとっとと氏ねよ

223 ：NAME IS NULL：03/11/23 02:28 ID:???

タンポポスタッフか・・・

224 ：NAME IS NULL：03/11/23 18:27 ID:EdE78rfq

もうお願いだから中途半端な知識でデータを書き換えるのは
辞めてくれよ。ただでさえ正規化されてないのに、
AccessでOracleにAttachしてデータ書き換えまくり。
もうなにがなんだか。やっぱ正規化と外部キー設定は必須だよね。
今ごろ気付いても遅いけど。

225 ：NAME IS NULL：03/11/23 19:36 ID:???

>>224
DBA権限を別に作って、そいつがやったことをトランザクションログで突きつけてやれ

226 ：NAME IS NULL：03/11/23 21:23 ID:23LWUWCu

てすてす

227 ：NAME IS NULL：03/11/23 22:50 ID:???

>>224
正規化とか設計以前にセキュリティの問題だろ。

228 ：NAME IS NULL：03/11/23 22:57 ID:oOMkgLbE

あややにinsertしたいでつ

229 ：NAME IS NULL：03/11/23 23:08 ID:+jlhXyEp

俺も今やってる仕事に途中参加したが、DB見せてもらったら
複数のテーブルにデータが重複しまくり。
俺は下っ端だからなんも言わないけど、ひどい設計だったよ…

230 ：NAME IS NULL：03/11/23 23:16 ID:???

>>229
最近は高速で大容量のHDが安価で手に入るから、
設計がショボーンでも、ユーザサイドからの視点では
それほど不満も無く動くのです。
苦労するのは、それを基に設計開発するSE/PGなのです。
ましてや、2次3次開発と、カスタマイズするに従い
見るも無残なDBに。他社にアウトソーシングも出来なくなり
無駄な月額費用だけ浪費していき、運用する期間が延びれば
それだけ赤字になる。。

231 ：NAME IS NULL：03/11/24 01:32 ID:???

っつーかさ、ちゃんとした「設計」を知っている人間が少ない・・・
DOAでもOOでも何でもいいから、とにかく一度は勉強しろと。

232 ：NAME IS NULL：03/11/24 04:52 ID:???

情報があれば間違いなく設計するんだけどね。
お客さん方には、間違いなく全部の伝票や、全部の例外を見せて欲しい。
「これで全部ですか？例外はありませんか？」
「全部です」って全然全部じゃないんだよな。査察じゃないんで家宅捜索するわけにいかんし。
「あ、この場合はこうなんです」のたった一言で根本の設計が変わる場合があるからね。
残念だけど根本からやり直す予算はないので無理矢理押し込むけど。

233 ：NAME IS NULL：03/11/24 07:53 ID:???

インタビュー技術ってのもSEのスキルなんだろうけどね。

234 ：NAME IS NULL：03/11/24 11:32 ID:???

>>232
客のいう「全部」を鵜呑みにする時点で藻舞は人が良すぎる。
全部であるわけがないと想定しておくのが要件分析の第一歩。

235 ：NAME IS NULL：03/11/24 12:39 ID:???

>>231
まぁね。ただ馬鹿高い金を払ってセミナーとか行くより、
自分で書籍を買って勉強したほうがいいと思う。
ただDOAとかERDなどの開発方法論は、個人ではなかなか導入
出来ないでしょう。結局PMとかが勉強して開発プロジェクトに
導入してくれなきゃね。
どちらにせよ、机上の空論にならないようにしましょう。

236 ：NAME IS NULL：03/11/24 15:26 ID:???

>>234
しかし、何度も嘘付かれたら信じるよ。
さんざん資料作って何度も確認した結果、全体的にはMRPだった。
それに対し例外ケースを組み込むような設計になった。
しかし後で出た一言で、本当は製番管理システムから例外を作った方が早いことが分かった。
その一言は、既に何度もそれはないと確認してきたことだ。
こちらも当然あらゆるケースを想定して確認を取ってる。
それでもこっちのせいだと言うなら家宅捜索するしかない。

237 ：NAME IS NULL：03/11/24 15:31 ID:???

漏れメインフレームで階層型データベース扱ってるから、
SQLもRDBも知らないしあんまり正規化と縁がない。
でも考え方はRDBも階層型もNetwork型も一緒なのかな？

238 ：236：03/11/24 15:35 ID:???

あとお客さん方は、自分に説明能力があると思わないで欲しい。
素人が説明するぐらいなら、こっちで実際の伝票見た方が早い。
だから全帳票出してくれと言ったら素直に全部出してくれ。

239 ：NAME IS NULL：03/11/24 16:14 ID:2Ilkee+y

>>236
どんなインタビューしてたんだ？
お前「全的にはMRPでしょうか？」
客「はいそうです。」
そんなインタビューしてなかったか？

240 ：236：03/11/24 17:39 ID:???

>>239
どうしても馬鹿にしたいみたいだね。意味不明な人だな。
「MRP」なんて言って分かる客ならそもそも問題も起きないよ。
どういう形態で受注し、どういう形態で在庫管理し、
最後にどういう形態で売上げるか、その形態がケースによって違うので、
こんなケースはないか、あんなケースはないか、具体的に１つ１つ確認したよ。
いっとくけど>>189は俺だよ。必ず先読みして具体例を見せて質問する。
最初の要求説明では抜け落ちがあり得ることを示唆したのは、ここではなぜか俺だけだよ。
その上で、自分で全部説明しないで今までの業務で使った伝票・帳票を全部見せろと言ってる。
そのことに何か問題が？

241 ：NAME IS NULL：03/11/24 18:17 ID:F6eXBuoi

>>240
普通なら「見せろ」とは言わない。
こころのどこかに「見せろ」という気持があれば、
良好なコミュニケーションが取れなくなる。

人間って不思議。

242 ：236：03/11/24 18:34 ID:???

>>241
実際にそんな言い方するわけないでしょう。
承認印欄は作ってあるけど、実際には押すように要求しないし。
でも誠意ある資料と説明で、相手は承認印を押したかのような
気持ちになってくれる。そういうやり方してるよ。
もちろん、やっかいな客がいることを知ってて疑いを持ってるからそうするんだけど。
でも情報がないのに勝手に馬鹿にできる可能性を探ったりするほど歪んでないよ。

243 ：NAME IS NULL：03/11/24 18:52 ID:F6eXBuoi

>>242
君が良い人で、仕事熱心なのも優秀なのもわかった。
(嫌みじゃないよ)
まだ、30代まえ？
雑談から業務を引きだせる、インタビューテクニックを
手にしたら人生楽になると思う。あと、承認印はもらうように。
承認印は自分とお客様双方を守るために押印していただくものだ。

244 ：NAME IS NULL：03/11/24 21:11 ID:???

まぁ、顧客から漏れなく情報を引き出すのは意外と難しいんでしょうね。
俺は本業じゃないけど、知り合いの人にDB設計を頼まれて
先週やっと立ち上げた所だけど、一番苦労したのは情報収集だった。
最大文字数が20文字と聞いて、30文字まで打てるようにしてても
さらにその上を行ったからなぁ。
「この情報を集めといて下さい」と言っても
「イヤです」とハッキリ言われた事もあるし。
どうしろと？
って感じだった。
みなさんの言うコミュニケーションが絶対的に不足してたのが原因だろうけど。

245 ：NAME IS NULL：03/11/24 23:08 ID:???

俺のところは要件定義などユーザと打ち合わせでは、必ず議事録を
執り、ユーザに承認印を捺印してもらう。
どこでもそうだと思うがユーザさんは基本的にわがままでしょ？
後でああだこうだ言われたら議事録を提示し、お互いの落しどころを
模索する。どうしてもここは変えたいと言われればそれは仕様変更として
もちろん別途お金は請求する。
やっぱユーザとの打ち合わせは営業＋ＳＥで臨んだほうが合理的だと思う。

246 ：NAME IS NULL：03/11/25 00:30 ID:???

インタビューというかヒヤリングとかには
技術的なこととは全然異なるスキルが
必要だということに気付けば自ずとグチの
方向も変わるよ。過程がどうであれ出来上がりに
自分で不満を感じる時点で、それは負けなんだ。
その負けを認めて次にどう生かすかという事が
大切だ。>>236はもっともっとがんがれ。応援するぞ。

247 ：NAME IS NULL：03/11/25 01:17 ID:???

うちは議事録は義務だよ。
すぐに作って部内とお客さんの両方に回覧する。
ってそれが普通かもしれないけど。
言った言わないの争いってあまりに不毛だからねぇ。

仕様として固まったらちゃんと線引いて、こっから先は
仕変ですよお金と時間下さいねって念を押すのも大事
・・・と先輩に言われた。

248 ：NAME IS NULL：03/11/25 01:21 ID:???

追加

自分が与えられた情報の中で最大限効率的に動いてるという
自負があればあるほど、大元の情報を狂わせる事態は
嫌で嫌で仕方ないと感じると思う。

でもそれに腹を立てても仕方ないんだよね。
自分の情報収集法を見直す方がずっと建設的。
なかなか難しいことだけど。

249 ：NAME IS NULL：03/11/25 17:21 ID:vK4PmOEt

正規化の範疇には入らないと思いますが、スレの流れ的に実務のあるべき姿
みたいなものを論じているようなので書き込みます。
分かりやすい項目名といったものはどう標準化していけばいいのでしょう?

計算条件テーブル内の
「商品を返品した(された)場合の請求合計金額の端数処理方法の区分」
なる項目の名前が
henpingoukeihasuukbn

などと付けられてしまって「う～～ん」という状態です…
他にも henpinmeisaihasuukbn 等があってSQLに書き起こすと長いわ
読みづらいわで何がなにやらといった状態です。

こういう場合、みなさんならどういう項目名にしますか?

250 ：NAME IS NULL：03/11/25 17:53 ID:???

命名規則か～、僕ならこんな感じかな。。。
h_ghasukbn
h_mhasukbn

返品関連のものをh_にして、後はgoukeiをg、meisaiをm
くらいかな。
他に紛らわしいのあったらその時考える。

251 ：NAME IS NULL：03/11/25 18:51 ID:MwVO9JgK

>>1
塩梅が結構難しいんだよね
アナログ的な要素が凄く多いから嫌。
これで正解とかいうんじゃなくて、このくらいが正解みたいなところが嫌

自意識過剰な奴とか独りよがりな奴が幅を利かせられる（幾らでも他人を批判できる）分野でもある。
とにかく嫌い。

252 ：NAME IS NULL：03/11/25 21:07 ID:???

>>249
はは。ありますね。そーゆーケース。
まぁでも日本語の項目名自体が長いからある程度は仕方ないような気もします。

253 ：NAME IS NULL：03/11/25 21:48 ID:???

>>251
塩梅とは？
正規化と性能のバランスのことを指していますか？

以下ORACLE限定のはなしですが、
テーブルを結合するにあたり、きちんと正規化されたデータベースであれば、
インデックスがお互いに張られているわけですから、ハッシュ結合どころか
ネステッドループ結合でも充分な性能が得られると思います。
仮にインデックスが張られていなくても駆動表・比駆動表でその他の抽出条件を
指定し、データの絞り混みを行うことにより満足いく性能が得られると思います。
以上は他のDBでも基本的な考え方は同じだと思います。

最近｢性能｣を盾に正規化をしない（出来ない）設計者が多いですよね。

254 ：NAME IS NULL：03/11/25 22:29 ID:6ScGRtXl

>>249
条件テーブルなら俺はどんなに長くなってもそうする。無駄だけど
条件名って言う項目を作って日本語名を入力する場合すらある。

255 ：NAME IS NULL：03/11/27 01:34 ID:???

金払ってるんだからインタビュー技術駆使しろｺﾞﾙｧ!
と言ったところで、結局工数に上乗せされるだけなんだけどね。
素直に全部全てすりっと出せばその分安く上がるのに。

256 ：NAME IS NULL：03/11/27 21:07 ID:???

マジレスですが、客の口が臭くて話すのがツライ。

257 ：NAME IS NULL：03/11/29 01:18 ID:PxZlqEGC

今現在WEBメールを作っているのですが、テーブルの仕様について迷ってます。
受信したメールなどの履歴を保存するのに１ユーザー１テーブルとするのか、
それとも　１つのテーブルにユーザーIDと一緒に保存して検索して取り出すべきな
のか・・・
データ件数が増えてきたときのことを考えると１ユーザー１テーブルの方が良さそ
うな気がしますが一つのＤＢで１０００とか１００００ものテーブルがあった場合、
著しくパフォーマンスの低下などするのでしょうか？
また、１テーブルにすべて保存する場合でもユーザーIDにインデックスつけれてや
れば１ユーザー１テーブルと変わらない気もするし・・・
今までたかだか１００テーブルぐらいのシステムしか作ったことがないのでわかり
ません。ご意見お願いします。

258 ：NAME IS NULL：03/11/29 11:29 ID:???

1ユーザ1テーブルなんて無様な設計はやめれ.
以上

259 ：NAME IS NULL：03/11/29 13:39 ID:???

>>258
はげどう

どう考えたら「1ユーザー1テーブル」なんていう仕様を思いつくのか。

260 ：NAME IS NULL：03/11/29 15:45 ID:???

釣りじゃねーの？。。。

261 ：NAME IS NULL：03/11/29 16:47 ID:???

>>258
1つのスキーマにテーブルが1000とか10000て。。
テーブル名を考えるのもめんどう。
テーブル構造が変わったらメンテも大変そう。
HotMailとかのテーブル構造とかが参考になりそうですけど、
私はしりません。

262 ：NAME IS NULL：03/11/29 17:33 ID:???

>>259
1ユーザ1DBホストにすればよろし

263 ：NAME IS NULL：03/11/29 23:41 ID:???

RDBMSは動的にテーブル数を増減させるような運用想定してねえだろ。
10件10万テーブルと10万件10テーブルなら後者の方が遥かに
DBMSにとって「楽な仕事」。

264 ：NAME IS NULL：03/11/30 01:00 ID:???

しかしまぁ、世の中にはかなり勘違いした奴もいるもんで

正規化したと言い張る奴の設計を見たら、同一のコードで参照できるテーブルが18あって
これが全て一対一でリンクできるという唖然としたシロモノだったりする。

んで、出来ちゃったから構造変更不可なんだそうな。
一つの情報系のプロジェクトでテーブル数140ってのは多すぎるだろ！
カラム数2ってのが45もあるし。。。。キー以外はデータの重複は無いけど。
マスターメンテはマジで死にます。

定時前だけど見て直ぐ帰りたくなったよ（ｗ

265 ：NAME IS NULL：03/11/30 01:57 ID:PbWn2vje

通りすがりですが、どんな大きなシステム構築もテーブル数30以下と
決めています。（30で、マスター・運用・ME・売上・は構築可能です。（ダイタイ））
マスター＝テーブルと考えているお客様もいますもので困り者です。）

無茶を言うお客様は、テーブル上のフラグで対応可能とご説明します。
[テーブルと・実行体は違うので、テクニックしだいでどうにでも・・・]
テーブルが少ないほど実行体も簡略化出来、サービス残業が減ってよいです。
　　「くされクライアント４ネ・・・・・・・・」

266 ：NAME IS NULL：03/11/30 01:59 ID:???

仕様変更の無理難題を言い続けるクライアントの所為で
いちいちテーブル定義とか拡張とかマイグレートとかしてられなくなったので

CREATE TABLE xxxxx
(
id INTEGER,
key VARCHAR(16),
val INTEGER, (DATETIME とか TEXT もあり)

PRIMARY KEY(id,key)
)

のよーなテーブルを作って済ませたいと思うようになったんだが、甘いか?

# id で CLUSTERED INDEX 作るので許せ(w

267 ：NAME IS NULL：03/11/30 08:14 ID:???

>>266
MSSQLのシステムテーブルにはそんなのが大量にあります。
が、やるとやった本人が死ぬと思います。

268 ：NAME IS NULL：03/11/30 13:57 ID:???

>>266
ってことは逆にゆーと仕様がまったく決まらんってことですか？
危険な匂いがしますな。

269 ：266：03/11/30 14:42 ID:???

あとで墓標立てに戻ってくるので待ってれ。

危険なまま2年間放置されたシステムだけんのう。

270 ：NAME IS NULL：03/11/30 17:26 ID:???

>>264
>正規化したと言い張る奴の設計を見たら、同一のコードで参照できるテーブルが18あって
拡張性、汎用性、仕様変更に対する柔軟性を考えたシステムはそうなるんじゃない？

>んで、出来ちゃったから構造変更不可なんだそうな。
このへんの発言から考えるとただの腐った設計かもしれないけど

271 ：NAME IS NULL：03/11/30 22:34 ID:???

>>270
仮に、拡張性・汎用性・仕様変更に対する柔軟性を考えてシステムを組んだとすれば
「敢えて正規化していない」
と、言うと思う。

272 ：NAME IS NULL：03/12/01 03:53 ID:???

>>270
たとえるとこんな感じかな。
従業員マスタが有ったとして、従業員コードと氏名だけでテーブルを作り、
従業員コードとフリガナだけでテーブル、従業員コードと住所だけでテーブル
従業員コードと電話番号だけでテーブル、従業員コードと部署コードだけでテーブル
とまぁこんな状況。しかもどのテーブルもレコード数は一致する。

しかも、検索パターンに合わせて設計するとテーブルは5つもあれば十分（変更される要素が薄い）

今、その関連の打ち合わせから帰ってきた（ｗ
会議が始まったのは昨日の午後一時だよ。。。。。

273 ：NAME IS NULL：03/12/01 04:00 ID:???

>>272
そんなとこだろうと思ったよｗ

274 ：NAME IS NULL：03/12/01 04:06 ID:???

>>272
それをunionすると>>266の希望のものになるのかな。
何聞いても「分からない」ばっかりで、
「フリガナはもちろん1つですよね」って何の気なしに聞いたら
「分からない。分からない。全部後から変更できるようにして」
と言われてブチ切れたとか。

275 ：NAME IS NULL：03/12/01 10:16 ID:???

要求～聞いてもわからない～
フリガナ～聞いてもわからない～
にゃんにゃんにゃにゃ～んにゃんにゃんにゃにゃ～ん
も～んくばかりいうお客さん～
犬の～SEさん困ってしまって、

・・・の続きを歌ってください

276 ：NAME IS NULL：03/12/01 11:07 ID:oXx8656X

>>274
無理って言え。もしくはまっさらのDBとコンパイラーを納品して。
後から好きなように変えれます。

といって逃げろ（ｗ

277 ：NAME IS NULL：03/12/01 17:09 ID:???

「やる気ありますか?」
「分からない・・・

278 ：NAME IS NULL：03/12/01 19:57 ID:???

>>もしくはまっさらのDBとコンパイラーを納品して。
↑
コレ使えるｗ

279 ：NAME IS NULL：03/12/01 21:27 ID:???

>>272
なんかオブジェクト指向？みたいな感じでテーブルをそれぞれ分けて、
VIEWでバーチャルなテーブルとして提供してあげるみたいなのが有効な
気がしてきますた。
ダメかな？

280 ：NAME IS NULL：03/12/01 21:56 ID:???

教えて下さい。
第３正規化までされている下記テーブルがあったとします。

受注No|商品CD|単価|数量
------+------+----+----
AAAAAA|BBBBBB| 50|100

上記の状態で合計金額(単価＊数量）を求めるとき、
1.　SQLで求めるのが普通ですか？
SELECT 単価*数量 AS 合計 FROM HOGE WHERE～

2. それともアプリケーションで単価列と数量列を取得して
計算しますか？
SELECT 単価,数量 FROM HOGE WHERE～
合計 = xxx.Fields("単価") * xxx.Fields("単価")

どちらがいいか？理由も教えて下さるとありがたいです。
その他にやり方もあれば、ご意見願います。

281 ：NAME IS NULL：03/12/02 02:31 ID:???

>>280
帳票なら1。ただしストアド。速度が全く違うから。
入力画面なら読込時でなく変更イベントで2。

ちなみに単価が端数になることはよくあるので、
金額を保存しない基幹業務はまず考えられない。
逆に単価を保存せず、そっちを計算値で表示するということはある。

282 ：NAME IS NULL：03/12/02 03:05 ID:MlG23vfJ

280>
受注ﾅﾝﾊﾞｰ＝受付日＆（店舗番号）＆整理番号
単価＝顧客コード（商品区分SELECT料率区分S＊料率）（特定区分は言い値）
＜商品区分：０～99＞：１００ありゃ十分。＞
TRANSACTION⇒SQL（SYBASE）
請求系⇒実行体⇒SYBASE：ではいかが？
（請求系はマスター総なめなので、1.5億円ぐらいなら（実例）２時間）
（TRANSACTION系なら問いあわせ（実例）10秒）
＜＜クライアントSUN：ULTRA　ENTERPRRISE450：ｸﾗｲｱﾝﾄ：ULTRA5：5～6＞＞
顧客マスターにより：売上地区：営業マンID：DE　URIAGE＿RANK系の（日報＆月報が可能）

283 ：NAME IS NULL：03/12/02 17:59 ID:???

>>272
従業員コードと部署コードのような関係と、
従業員コードと(担当する)取引先コードのような関係を、どのようにして分別
をつけるかってのは意外と難しい問題になることがあるのかもね。
何を持って一対多の関係を考慮するべきなのか。
あんまり想像力豊かなのも困るしねぇ。

284 ：NAME IS NULL：03/12/02 21:58 ID:8caVKpbN

>>280
一昔前のC/Sなら負荷分散を考慮してクライアント側（アプリケーション）で
やったかもしれない。
WebならDBサーバにやらせる（SQLでやっちゃう）

285 ：NAME IS NULL：03/12/02 22:32 ID:6WLRo4dX

>>284
それならWebの場合DBの付加分散のためにアプリケーションサーバで
処理するってアイディアにはならない？
DBよりアプリサバの方が負荷分散簡単だし。

286 ：284：03/12/02 23:04 ID:8caVKpbN

>>285
うん。。。？
一概にはいえんけど、サーバ性能やネットワークトラフィックなど
インフラまで考慮するとアプリケーションサーバでやるかもしれん。
でもそこまで考えてプログラム設計するPGもいないんじゃない？
結局テーブルのジョインとかはDBサーバでやるでしょ？
サーバカーソルのほうが断然早いし。
ならSQLで対応出来るところはDBサーバでやりましょう的なノリになると思う。
（あくまで通例の場合ですよ）

逆にアプリケーションサーバで処理するときのメリットがあれば教えてほしいです。

287 ：NAME IS NULL：03/12/02 23:42 ID:ZOCXS2qY

>>280
一般的にはまず>>281 で問題ないかと（よほど特別な理由がなければ）

>>286
同意です

288 ：285：03/12/02 23:45 ID:???

>>286
スレ違い風味なのでsage。
SQLで対応できるならDBサバでってのは全く同意なんだけど、
負荷が気になる場合はアプリサバをブレードとかにしたら楽かなと
ちょっと思ったので。あんまし深い意味はないです。

＊強いて＊アプリサバで処理するべきだと主張するなら、
よりオブジェクティブで単機能のAPIを整備可能な設計になるってことかな。
DBへはデータを取りにいくだけってことにしちゃえば、
機能(合計金額を求めるとか)は基本APIとして作った方が使い回しが効く。
# >>280 の例示にあるように、受注取り出しに常に合計金額の算出が
# 付随するような場合は分ける必要はないけど。

289 ：NAME IS NULL：03/12/03 00:46 ID:???

>>280
まったくどーでもいいことだが
×　合計 = xxx.Fields("単価") * xxx.Fields("単価")
○　合計 = xxx.Fields("単価") * xxx.Fields("数量")
ですね。

290 ：1：03/12/06 01:21 ID:pWhb2iV/

久しぶりにこの板を拝見させて頂きました。
こんなにレスが伸びてるとは思わなかった（本音）

正規化・データモデリング・パフォチュー・リカバリ・・・
データベース管理者で喰っていく限り常時悩まさせるテーマかも
しれませんね。

291 ：NAME IS NULL：03/12/07 02:03 ID:???

日々勉強だよ…
体系立てられた勉強もせずに2000秋からPostgresで運用始め
かれこれエセDB屋3年。今はSybaseメイン。

教科書通りのセオリーが通用しない場面なんて腐るほど出てくるし
どんなに用心して設計してもある夜突然テーブル切り直してマイグレーション大会。

それでも教科書の知識は役に立つ。
ちうわけでROMに戻りまつが時々カキコしまっす。

292 ：NAME IS NULL：03/12/23 14:52 ID:xxg1g8Ix

結局この業界を支配しているのは基本も知らない素人なんだよね。
テーブル設計の基礎の基礎である正規化すらできていないテーブル設計をして
いっぱしの技術者のつもりかよ。
第一正規型すら満たさずに何が冗長性だ。

293 ：NAME IS NULL：03/12/23 17:54 ID:dkEzvndk

>>283
人事系の業務だと部署と社員はN:Nだと思うべし。
N:Nを前提に、如何に関連表を作るかが勝負。

294 ：NAME IS NULL：03/12/23 21:30 ID:???

>>293
だったら「部署」と「社員」の間に「所属」を入れろ。
そうすれば1:Nになる。

基本も知らずに何が勝負だ。
ER図くらいかけトーシロが。

295 ：NAME IS NULL：03/12/23 22:41 ID:???

進行中のプロジェクトに手伝いで呼ばれて、
じゃあER図見せろと言うとそんなものは無いといわれる。
せめてテーブル定義見せろと言うとなんかExcelで作った
ﾃｷﾄｰな表が出てくる。
コード体系表は無いのかと言うとやはり無いといわれる。

どーせいっちゅーねん

296 ：NAME IS NULL：03/12/23 22:57 ID:???

その有用性を認識させるために>295が作るしかないな。

297 ：NAME IS NULL：03/12/23 23:21 ID:???

>>294
すみません、とーしろ何ですが、間に「所属」を入れると
なんで1:Nになるんですか？

298 ：NAME IS NULL：03/12/24 03:35 ID:1bK7NfoF

>>294
だから、所属だけで済む場合も有るし、ERPレベルになると
顧客と社員が繋がったり、関連表（所属も含む）から勝負だと
言ってる。馬鹿。

299 ：294：03/12/24 12:14 ID:9pkx9jnx

>>298
馬鹿って言ったか、この馬鹿。
カーディナリティの話をしてるんだろうが、この馬鹿。
お前は恥ずかしげもなくN:Nが前提だとか偉そうに語ったろうが、この馬鹿。
お前は基礎すら身につけていないことがバレバレなんだよ、この馬鹿。
自分の無知に気づきもせずいっぱしの仕事をしているつもりか？、この馬鹿。
「顧客と社員が繋がったり、関連表（所属も含む）から勝負」だと？、この馬鹿。
そんなのは外部スキーマの話だ、この馬鹿。
実のない言い訳をする時間があるなら入門書でも買ってこい、この馬鹿。

300 ：294：03/12/24 12:19 ID:???

>>297
一人の社員は複数の部署に所属する。
ひとつの部署は複数の社員が所属する。
ひとつの所属は１人の社員と１つの部署を関連付ける。
よって、社員：所属：部署は1:N:1になる。

表に落とすとこんな感じ↓
”所属”の主キーは｛社員コード、部署コード｝になるから、
異なる部署コードをもてば、重複して同じ社員コードを持つことが許される。
↓
ひとつの社員タプルは複数の所属タプルから参照される。
ひとつの所属タプルはひとつの社員タプルを参照する。
だから”社員”:”所属”は1:N
”部署”と”所属”も同じ。

301 ：NAME IS NULL：03/12/24 13:18 ID:???

>>294が噛みつくのがおかしい。>>293は「N:Nを前提にいかに関連表を作るか」って
言ってるから、そこには当然>>294の言う「所属」を含めてのことだと取れる。

なんかさ、>>293を無知扱いして偉そうなこと言いたいだけでしょ?
物知りを誇示したがるのは、知識や技術はあるけれど、技術者としての経験や自信のない
人間がする振るまいの典型だよね。頭でっかち。

302 ：294：03/12/24 20:54 ID:???

>>301
初歩的なことを言ったつもりなんだが、物知りに見えますか。
おれに知識や技術があると言ってくれるのか。
頭でっかちは本物の技術者への第一歩だ。
おれを責めてるんだと思うが、しかし同時に褒めてるぞ。

303 ：NAME IS NULL：03/12/25 00:03 ID:???

技術じゃなくて、日本語能力の問題だな。

304 ：NAME IS NULL：03/12/25 00:05 ID:???

>>300

社員テーブル(PK:社員CD) 部署テーブル(PK:部署CD)
=======+======== =======+========
社員CD | 社員名部署CD | 部署名
=======+======== =======+========
1001 | 佐藤 1001 | 総務
1002 | 鈴木 1002 | 経理
1003 | 田中 =======+========
1004 | 木村
=======+========

(A) 社員部署テーブル(PK:社員CD,部署CD)
=======+========
社員CD | 部署CD
========+========
1001 | 1001
1002 | 1001
1003 | 1002
1004 | 1002
: | :
1001 | 1002
1003 | 1001
=======+========　※社員:部署はN:N

(B) 所属テーブル(PK:社員CD,部署CD)
=======+========+========
社員CD | 部署CD | 所属ID
=======+========+========
1001 | 1001 | 01
1002 | 1001 | 01
1003 | 1002 | 01
1004 | 1002 | 01
: | : | :
1001 | 1002 | 02
1003 | 1001 | 02
=======+========+========　※社員:部署:所属は1:N:1

「所属」は受注とかで登場する枝番やラインナンバと同じ???

部署や社員にそれぞれ顧客がつくとなると、めちゃ複雑ですね。
私は複雑になるなら単純にN:Nの状態(A)で管理した方がいいと思うのだけど、
やっぱ豆四郎だからかなぁ。

305 ：NAME IS NULL：03/12/25 00:25 ID:???

社員：部署がN:Mで、社員：所属：部署がN:1:Mだろ？
んで、社員テーブルと部署テーブルが別にあって、
(A)の形の所属テーブルをつくるわけ。

306 ：NAME IS NULL：03/12/25 00:29 ID:Y2e8eXh4

>>304
俺も(A)でいいと思うけどな。
『社員部署テーブル』を主キーの要素だけにしてるってことは
第４正規化まで出来てると思うし。

307 ：NAME IS NULL：03/12/25 00:32 ID:???

>>305
そもそも『所属』ってどこから出てきたんだっけ？
社員CD+部署CDの複合KEYでユニークになるなら
所属なんていらねーじゃん。

308 ：294：03/12/25 00:59 ID:???

寝る前にちょっとのぞきに来たんだが、X'masだってのに盛り上がってるな。

>>304
なんか変なこといってるな。
(A)でいいんだよ、(A)の社員部署テーブルがおれの言う所属テーブル。
ER図を書くとこうなる。
社員→所属←部署

(B)はどっから出てきたんだ？

>>305はわかってくれてるようだ。

309 ：304：03/12/25 01:16 ID:???

>>305,308
> (B)はどっから出てきたんだ？
所属を無理矢理理解しようと思ったらああなりました。
でも、勘違いしてたみたい。
てか難しと思ってたからちょっと変に考えすぎてたかも。
やっと話がわかったっす。

310 ：294：03/12/25 01:21 ID:???

あ、>>305ちょっと違った。
社員：所属：部署はN:1:Mじゃないよ。

社員：所属と所属：部署を別にして書いたほうがよかったな。
１：Nと、M：１ね。

じゃ、あとはよろしく。

311 ：NAME IS NULL：03/12/25 03:21 ID:S9tI5Cer

>>310
症状と原因とを分けて分析する訓練してるか？

312 ：NAME IS NULL：03/12/25 17:27 ID:???

正規化？ああヴィザードでやってるよ。

313 ：NAME IS NULL：03/12/26 00:22 ID:5ul9Dsx2

>>312
氏ねボケ

314 ：NAME IS NULL：03/12/26 01:32 ID:???

>>313
馬鹿はシカトしませう。

315 ：NAME IS NULL：03/12/26 07:59 ID:???

正規化は机上で初心者がやるもの。

316 ：NAME IS NULL：03/12/26 15:26 ID:nQsH/ozH

久しぶりに、一行釣り師が出てきてなぁ。

317 ：NAME IS NULL：03/12/26 23:20 ID:???

>>315
釣りか

318 ：NAME IS NULL：03/12/26 23:45 ID:???

正規化は遠くにありて思うもの

319 ：NAME IS NULL：03/12/27 00:30 ID:???

Webの仕事って開発期間が短いよね。
で、とりあえず稼動させて２次３次案件と発注される。
そんな時ＤＢがキッチリ正規化されていると開発コストが
かなり抑えられる。

320 ：NAME IS NULL：03/12/28 00:53 ID:???

技術系の板って殺伐としてるね。

321 ：NAME IS NULL：04/01/09 17:53 ID:???

ばかなクライアントにイライラしてる状況が良く伝わってﾜﾗﾀ
・・・つーか泣けた

322 ：教えて下さい：04/01/24 18:23 ID:7mE+Fkrm

リレーショナルデータベースにおいて、正規化を進めることによって得られる効果とはどれか？

１．テーブルの数を減らせる
２．データベースの冗長性と矛盾を避けることができる。
３．データベースの検索性能をより向上させることができる。
４．データベースのセキュリティを高めることができる。
５．テーブルの列をまとめることができる。

どれが正しいのか教えて下さい。。

323 ：NAME IS NULL：04/01/24 20:15 ID:UtaNFL+t

情報処理試験の問題か何かか。

１->むしろ増える
２->その通り
３->更新速度は上がるが検索性能はあがらない
４->セキュリティと関係無し
５->なにそれ

324 ：教えて下さい：04/01/24 21:16 ID:7mE+Fkrm

詳しい解答教えてくれて助かりました。ありがとうございます。。

ついでによければ、「現代社会における理想的なデータベースとはどのようなものか」
教えていただけませんか・・

325 ：NAME IS NULL：04/01/24 21:52 ID:???

Google

326 ：NAME IS NULL：04/01/24 22:20 ID:???

RDB設計の基礎知識であり必須作業である正規化すらできずに
人並みの仕事をしているつもりか？マヌケな野郎だ。
そうやって無駄に複雑なSQLでしかデータを取り出せない冗長性だらけで
現実のモデルとかけ離れたテーブル作って
周りに迷惑かけてろや。
どうせお前は現場でオラクルの使い方をかじっただけでデータベースの設計ができると
勘違いしちゃったクチだろ？
金槌の使い方を覚えただけで自分が建築技術者だと
言ってるようなものだ、恥ずかしい奴だな。
お前のような見込みのないシロートに業界に居座られると迷惑だ。

どうせソフ開すらもてないような奴なんだろ？資格は必要ないとかいってな。
そんな調子だからいつまでたっても自分の無知に気づかないんだよ。

327 ：孫悟羽愚 ◆9B5ELldDBw ：04/01/25 16:31 ID:a+lnz2Fb

正規化を解りやすく絵図で説明してる参考書はないですか？

328 ：NAME IS NULL：04/01/25 17:23 ID:???

>>327
いくらでもある。まず本屋へいけ。

329 ：NAME IS NULL：04/01/26 11:50 ID:???

>>328
ﾋｷｺﾓﾘには家から出ることから教えないとダメだぞ

330 ：NAME IS NULL：04/01/26 21:50 ID:???

>>327
Amazonとかで手当たり次第買えば、外に出なくてもいいぞ。

331 ：NAME IS NULL：04/01/27 03:26 ID:???

つか、グーグルでもひっかかるわけだが。
（画像がほしけりゃイメージ検索つかえ）

332 ：NAME IS NULL：04/01/29 10:24 ID:29eGoArD

ハッシュジョインとスタークエリーについて、実際のＳＱＬが書いてある
わかりやすいおすすめサイトがあったら、教えてください。

333 ：NAME IS NULL：04/01/29 10:47 ID:???

>>327
ここらへんなんか、いいかも
ttp://www.pursue.ne.jp/jouhousyo/sysad/sysad012.htm
ttp://www.pursue.ne.jp/jouhousyo/sysadSeikika/sysadSeikika_A.htm
ttp://www.wakhok.ac.jp/DB/chapter2.7.html

334 ：NAME IS NULL：04/01/29 11:47 ID:???

>>333
> ttp://www.wakhok.ac.jp/DB/chapter2.7.html

これの問7がなぜウになるのかわからない
表A:商品コード商品名単価仕入先コード
表B:仕入先コード仕入先名仕入先住所
の二つのテーブルじゃダメなんだろう?

誰か解説きぼんぬ

335 ：NAME IS NULL：04/01/30 09:10 ID:BMBTFGtD

http://www.pursue.ne.jp/jouhousyo/sysad/sysad012.htm
http://www.pursue.ne.jp/jouhousyo/sysadSeikika/sysadSeikika_A.htm
http://www.wakhok.ac.jp/DB/chapter2.7.html

336 ：NAME IS NULL：04/01/30 10:00 ID:???

>>335
直リンかよｗ

337 ：NAME IS NULL：04/01/30 10:13 ID:6RXzcdIN

>>334
表Aの主キーは｛商品コード、仕入先コード｝だ。
それはわかるな？
で、非キー項目である｛商品名、単価｝は商品コードに
関数従属している項目だから、主キーに部分関数従属することになる。
つまり、表Aは第１正規形なので正規化が不十分だ。

338 ：334：04/01/30 10:47 ID:???

ごめんさい、全く違うものをリンクしてました
ttp://www.pursue.ne.jp/jouhousyo/sysadSeikika/sysadSeikika_Q.htm#問07
↑正しくはこっち。

>>337
もう一回質問を整理します。

商品コード商品名単価仕入先コード仕入先名仕入先住所

を正規化すると

表A:商品コード商品名単価仕入先コード
表B:仕入先コード仕入先名仕入先住所

ではなくて

表A:商品コード商品名単価
表B:仕入先コード仕入先名仕入先住所
表C:商品コード仕入先コード

となぜ表Cが必要なのかが分かりません。
一つの商品が複数の仕入先から購入されるのなら話は分かるのですが
問いには「一つの仕入先から複数の商品を仕入れている。」としか
書かれていません。

339 ：暇人：04/01/30 11:40 ID:???

一つの商品の仕入先は一つだと明示されていればそれでもいいと思うが
明示されてないからな。
主キーについては｛商品コード、仕入先コード｝が主キーだと明示されている。
だから、普通に｛商品コード、仕入先コード｝を主キーとした正規化をするのが確実だよ。

340 ：334：04/01/30 11:57 ID:???

>>339
あ、わかりました。

そうか、商品コードと仕入先コードで一意に決まるとなると
{商品コード仕入先コード} 商品名単価
では商品名と単価が繰り返し項目になってしまうのですね。
そうかそうか。

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

341 ：暇人：04/01/30 12:35 ID:6RXzcdIN

こまかいことですまんが繰り返し項目ではなくて、重複項目。

342 ：NAME IS NULL：04/01/30 13:06 ID:???

>>334はアフォ

343 ：NAME IS NULL：04/01/30 15:27 ID:???

一瞬、こんな風に考えてしまった

表A:商品コード仕入先コード単価
表B:商品コード商品名
表C:仕入先コード仕入先名仕入先住所

ダメだな、漏れ（ｗ

344 ：NAME IS NULL：04/02/02 11:24 ID:4Ms/z/8y

>>343
ダメじゃないよ。商品が仕入先ごとに単価が異なりえる
だろうと考えたのはいい着眼点。
もともとの問題で、正規化以前のテーブルが

商品コード商品名販売単価仕入単価　仕入先コード仕入先名仕入先住所

となっていたのなら、求められる答えは

表A:商品コード仕入先コード仕入単価
表B:商品コード商品名　販売単価
表C:仕入先コード仕入先名仕入先住所

になるだろう。ところが、問題の単価はたんに「単価」
とだけなっているから、表Ａに置いたとしても間違いとは
いえないな。まあどっちにしても、この問題は選択肢から
選ぶようになっているから、答えはウになるわけだけど。
もし選択肢がなければ、漏れも343のように考えただろうな。

345 ：NAME IS NULL：04/02/02 23:54 ID:???

現実的には同一の仕入先でも、時期によって単価が違う事も多々ある。
時制DBじゃないと使い物にならん。

346 ：NAME IS NULL：04/02/02 23:56 ID:???

試験には試験の解き方があるって事で。
・・・そういう事を勉強するのﾏﾝﾄﾞｸｾ

347 ：NAME IS NULL：04/02/04 11:18 ID:???

>>344
>>343はそこまで考えてないだろう(w

348 ：343：04/02/05 02:56 ID:???

>>347
考えてるよ（ｗ
というより、345の考え方に近い。
マスタに単価を入れる事自体が間違い。

途中で単価が変わった場合、金額計算は出来なくなるし
運用で逃げる（調整項目を設ける）では、実態を表した帳簿とは言えないから
間違い無くシステム監査に引っかかる（帳簿の体裁をなしていない）
それに、そんな処理を入れて、かえって複雑にする必要は無いだろう。

と、考えた次第。
このような帳簿の場合、会計基準に乗っ取って作らなければ
単に補助簿が出来るだけになるんだけどね。

349 ：NAME IS NULL：04/02/10 10:10 ID:???

よく判ったYO

NDB>>>>>>>RDB

ということなんだね

350 ：NAME IS NULL：04/02/25 19:03 ID:???

ちょっとしたwebショップ作るとして、下の項目を必要とする場合、
テーブルひとつで済ましました方がかえって楽？
データの入力は顧客自身がするので、マスタの入力はめんどくさがりそうで・・・。

商品番号、メーカー、商品名、型番、定価、売価、在庫数、
入荷予定日、商品解説、商品写真、登録日、更新日

351 ：NAME IS NULL：04/02/25 21:45 ID:???

テーブルの列名（文字列）を管理するテーブルを作って、
プログラムでそこから取得した列名を使ってSQLを生成しようとしています。

例えば、select A B C from T　というSQLを、
select A C D from T　というSQLに変更したいとき、
列名を管理するテーブルに
A,B,C　と登録されているのを
A,C,D　と変更することにより行いたいのです。
(BをdeleteしてDをinsert）

こんなふうに、列名を管理するやり方を見たことありますか？
何か問題があればご指摘ください。

352 ：NAME IS NULL：04/02/25 23:00 ID:???

>>350
わしならちゃんとテーブルを正規化してしまって
メンテ画面を使いやすいようにつくる。
テーブル構造をそのままむきだしでメンテ画面に
するからおかしくなる。

>>351
好きにすればよかろう。何か問題を感じているのか？

353 ：350：04/02/25 23:44 ID:???

>>352
なるほど・・・メンテ画面をしっかり作りさえすれば
顧客もこうゆうものかと思って納得するもんね・・・

354 ：NAME IS NULL：04/02/26 01:36 ID:???

>>351
見たことあるっていえばあるけど。
参考までに何でそんなことしたいのか教えてくれるかな。

355 ：NAME IS NULL：04/02/26 09:10 ID:???

>351
メリットが無いとはいえないけど、自前でやろうとするとそれなりに時間もかかるし効率が良いとは思えない。
DBをリバースエンジニアリングしてクラスにマッピングしてくれるようなツールを使う方が吉かと。

356 ：351：04/02/27 02:07 ID:???

>>352
特に問題は感じていません。何となく気になっただけです。
理由も無く聞いてすみません。

>>354
あるテーブルのデータのうち、使いたいもの（列）の組み合わせが
提供したいサービスの種類によって数パターンあって、
例えば、サービス１の処理をしたいときは列A,B,Cのデータを、
サービス２の処理をしたいときは列B,D,Eのデータを操作したいのですが、
その組み合わせ時々変わる可能性があるので（サービス２でB,D,Zを使うようになる、など）
できるだけプログラムを変えずに対応できるようにしたいのです。
そこで、サービスｎと列ｘとの対応を管理するテーブルを作ろうということになりました。

>>355
管理したいテーブルは１つなので（500くらい列がありますが）、
今回は自前でやることになると思いますが、
何か便利なツールをご存知でしたら教えて下さい。

それから、質問スレッドと間違えてこっちに書いてしまいました。
失礼しました。
回答下さった方、ありがとうございました。

357 ：354：04/02/27 22:22 ID:???

>>356
そんな理由ならまあいいか。
自分だったらテーブルにするより定義ファイル作っておしまいにしちゃいそうだけど。
そのほうが楽だし。

聞いた話だけど、同じようなことを業務システムの全テーブルについて行ったものがあったそうです。
詳細はよくわかりませんが、関係者曰く「二度と関わりたくない」ものだったそうです。

358 ：NAME IS NULL：04/02/28 11:03 ID:???

>356
>あるテーブルのデータのうち、使いたいもの（列）の組み合わせが
>提供したいサービスの種類によって数パターンあって、

ビューを使うのじゃダメなの？
それがダメなら、3階層C/S的にそのサービスとDBの間にもう1段噛ますべきでしょう。

359 ：NAME IS NULL：04/02/28 11:33 ID:QTIAAY4r

ストアドに汁。

360 ：NAME IS NULL：04/04/21 23:37 ID:???

DBMSを管理する能力とDBを管理する能力は別だからな
DBMSは異常なほど知ってはいたが、正規化？はにゃ～ん？
っていう人は結構見た

開発やっててもレコードセットやデータ構造程度にしか
見てない人ばかりだったね。

あっはは。

361 ：NAME IS NULL：04/04/28 00:11 ID:yGaCVK3l

>>360
ある意味ベンダーの研修に洗脳されている人種かもしれん。
データベースの物理設計のカテゴリがいかに重要だとゆーことを
SIerは再認識すべき課題かとも思う。

362 ：NAME IS NULL：04/04/29 01:51 ID:???

このスレはいい人ばかりですね

363 ：NAME IS NULL：04/04/29 23:52 ID:Cd2p5FCF

よくインデックス張ると更新が遅くなるというが、
おら！オラ！オラクルっつー本を読んだら
インデックスの更新はさほどコストがかからなくて、
インデックスがデフラグ状態になったときに
インデックス検索よりフルスキャンの方が速くなるということが
書いてあった。
実際インデックスのせいで更新系が遅くなったこと
ある人いますか？

364 ：224：04/04/30 00:00 ID:EQyECvc4

>>よくインデックス張ると更新が遅くなるというが
すいません。オレの周りにそういうことをよく言う奴がいた、
っちゅうことです。

365 ：NAME IS NULL：04/04/30 00:52 ID:T27hzrmo

>>363
インデックスにしている列を更新すれば遅くはなるでしょうね。
データとインデックスの双方更新するわけですから。
ビットマップインデックスに対する更新は特に遅いと風の噂で
聞いたことがあります。

366 ：NAME IS NULL：04/04/30 02:11 ID:???

>>365
ただ、更新の為に更新する行を探し出す必要があるわけだから、
インデックスがあった方が(それが有効に働く場合)速いわな。
単純に新規挿入されるのならインデックスなしの方が速いだろうけど。

インデックスの更新にさほどコストがかからないということは、その分
手を抜いた更新になっているわけで、デフラグ状態陥りやすい。
インデックスを基にした統計情報も逐次更新されるわけではないので、
的便お掃除&整頓しなきゃ、ダメっすね。
で、これって更新系だけじゃなくて、SELECTやDELETEもWHERE句が
あれば遅くなってしまうのだが。

と、PostgreSQLのインデックス更新の話をちょこっと聞いただけなので、
詳しくは知らんし、Oracleならもうちょっとマシな更新をしてそうだけど、
さほど変わらんのかな?

367 ：NAME IS NULL：04/04/30 11:09 ID:Z9jvLrWB

デフラグ状態って何ですか？

368 ：366：04/04/30 12:37 ID:???

いちいち突っ込むのもなんなのでスルーしたんだけど、
フラグメンテーションを直すのがデフラグだから全然意味が違うな。

369 ：224：04/04/30 23:02 ID:vP3ucElk

>>229
そう。フラグメント状態です。ボケてました。つっこみありがと！

インデックスの更新という余計な手間をかける場合
なにもしないより遅くなるのは当たり前ですが、
それが体感できるくらい遅くなるものなのか？という疑問なわけです。
ってわかってくれていると思うけど。
ビットマップインデックスの更新が遅いという話は、なるほどと思いました。

370 ：NAME IS NULL：04/05/01 01:51 ID:???

>>363
テーブルの全レコード数に対して検索の結果行数がある割合を
超える場合はインデックススキャンよりシーケンシャルスキャンの
方がコストが低いというのはわかるな？
インデックス順に対してレコードが多くのデータブロックに分散
している状態ではその閾値が低くなるということだ。

371 ：NAME IS NULL：04/05/02 23:44 ID:wRvFO8Bl

>>370
アホな質問だが
シーケンシャルスキャンて初めて聞いた単語だけど、
テーブルのフルスキャンをORDER BYを指定して検索すること？

372 ：NAME IS NULL：04/05/05 17:09 ID:???

すみませんが、
　第4正規化、第5正規化
とかいうやつをやった人っていらっひゃいます?

373 ：NAME IS NULL：04/05/06 01:48 ID:???

>>372
第４正規化までやるとしたら、それはリソースとパフォーマンスなどを
トレードオフした結果論でしょうね。
ある意味ここまでエンドユーザに提示してあとは査定して下さい（ｗ
みたいな。
私が最近面白いと思うのは結果論（ある意味極論）を提示したとき
素直なお客さんはお金払い良いけどね。

374 ：NAME IS NULL：04/05/07 16:48 ID:???

正規化＝最適化ではないからなぁ。

375 ：NAME IS NULL：04/05/22 18:27 ID:???

>>373

DBの技術的な話を理解してくれるお客さんあったことがない。
うらやましぃ

376 ：NAME IS NULL：04/05/24 00:43 ID:79+dFvzW

マスターテーブルなのに主キーがねぇよorz
もうダメポ・・・

377 ：NAME IS NULL：04/05/24 15:55 ID:wmDKM+ij

ER 図くれと言って見たら仰天した。
東京の地下鉄路線図よりからまりまくりのスパゲティ状態よ。
ER 図を見やすく再配置するのに 1 日かかったよ。

で、これも正規化ですかね？

378 ： ◆sybase.d.c ：04/05/25 19:47 ID:???

さいきん n次正規化に固執しなくなってきた俺…
このへんってパフォーマンスとの兼ね合い、
フロントエンドの負担もあるんだよなー

379 ：NAME IS NULL：04/05/28 16:44 ID:???

漏れは今、>>16と同じ被害に遭っておる。
テーブル開くだけで、2, 3分固まりますが、何か? :-P
はっきり言って、無能すぎ（ｗ
やはり、プログラミングできねー香具師には仕様云々は（略
というより、どんな作業してもヴァカなことをやるんでしょうねぇ :)

380 ：379：04/05/28 16:50 ID:???

普通のが12つ → 12フィールド
1～10になってるのが4つ → 4 * 10 = 40フィールド
1～10の中にさらに1～10と入れ子になってるのが1列。→ 1 * 10 * 10 = 100フィールド

12 + 40 + 100 = 152フィールド。
そりゃ、Pen4でも2, 3分固まるっつーの。

381 ：NAME IS NULL：04/05/28 19:11 ID:Zb+elczz

来週から逝く会社に顔出ししてきたんだけど、
どうもRDBMSの概念を理解している香具師がおらん。

最大値を拾って、webページのカウンタやってみたり、
同じデータが入った項目が多数存在したり・・・

これを見て採用辞退したといって通るモノだろうか？

382 ：NAME IS NULL：04/05/28 19:59 ID:???

>>381
ちみが流れを変えるしかないでしょう。

しかし、その程度の技術しか持たない香具師らに対して啓蒙と教育活動を
していくのに対して異常に神経を使い、自分が磨り減ってしまうのもまた事実。

383 ：NAME IS NULL：04/05/29 02:35 ID:Eu/3LWqK

COBOLのSEが設計したテーブル見てびっくりした。
12ヶ月*20項目=240+αのカラム数って・・・。
全部横持ちすんなよな。
insert文がえらいことになってしまった。

こんなSEの下で働きたくねーよ。

384 ：NAME IS NULL：04/05/29 10:37 ID:and4JLX3

>>381
その会社の営業力は正直すごいな。技術が無くても仕事がとれる。
ある意味よい会社ではないか？
そこに 381 の技術力が加わればオニカナ　　　かもね。

385 ：NAME IS NULL：04/05/29 11:15 ID:EYTKUjAs

ボイスコッド正規形の定義として、
今眺めている本にはこう書いてあります。

「ボイスコッド正規形とは、表内の行を一意に決定できるのは
　候補キーだけの状態。」

納得できないなぁ…

だって、表内の行を一意に決定できる属性の集合
（のうち、余分な属性を持たないもの）が候補キーでしょ？

386 ：NAME IS NULL：04/05/29 11:19 ID:EYTKUjAs

ちなみに漏れの理解は

「ボイスコッド正規形とは、すべての属性が
　主キーにのみ完全関数従属する表」

です。

387 ：381：04/05/31 17:55 ID:???

帰ってきますた。もうね（ｒｙ
DBM云々かんぬん以前の問題。
今時オープン系鯖にtelnetかよ。よく今の今まで動かしていたなと関心させられた。

388 ：NAME IS NULL：04/06/01 01:21 ID:???

それで動いてたならたいしたもんだぬ

389 ：NAME IS NULL：04/06/01 16:09 ID:???

みんな人生を正規化しよう。

390 ：NAME IS NULL：04/06/01 16:24 ID:???

このご時世、完璧に正規化すると首が飛びそうだなぁ。
やっぱ適度な正規化崩しが必要だな。

391 ：NAME IS NULL：04/06/01 18:27 ID:???

げげ

ていうか、なんで首が飛ぶ？

392 ：NAME IS NULL：04/06/03 03:50 ID:???

>>391 一事実一箇所
冗長性の排除。

おまえは更新異常起こす原因だから、
消えてなくなれ、とか。

393 ：NAME IS NULL：04/06/03 22:24 ID:???

>>387
今時、それぐらいの酷さはふつうだと覚悟した方がいいかもしれない。

5年ぐらい(自称)DBAとしていろいろなプロジェクトの後始末をしているが、
年々DBの設計がひどくなっていく傾向にあると感じる。
あなたのようなよくわかっている人は後始末係として重宝される。

客からすれば、将来を見越した実装や、データは興味の対象じゃないからねぇ。
今この瞬間動けさえすれば問題なしぐらいの意識だよ。

394 ：NAME IS NULL：04/06/04 23:06 ID:???

>>393
>年々DBの設計がひどくなっていく傾向にあると感じる。

これ、もう少し詳しく知りたい。なんで年々ひどくなるんだろ。
覚えることが多すぎてＤＢの比重が相対的に減ってんのかな。

395 ：NAME IS NULL：04/06/04 23:35 ID:???

GUIやRADツールの進歩で誰でも(表面上)DBA的な作業が出来るようになった。
が、技術の流行を追いかけるばかりできちんとした設計理論を知らないﾔｼが増えた。

低予算で短納期なプロジェクトも増えてきた。
そんな中集められたのは
理論は知っててもオープン系での実践ができない汎用系出身者と
実践ばかりで理論をしらないWin登場以降の若手技術者。

396 ：NAME IS NULL：04/06/05 00:35 ID:???

>>395
それと文句だけ言って動かない奴。

397 ：NAME IS NULL：04/06/05 14:09 ID:???

日本では、エンジニアの地位・報酬が低いからねえ。
家族を食わせていこうと思ったら、もうマネージャになるしかない。

398 ：NAME IS NULL：04/06/08 22:41 ID:???

>>家族を食わせていこうと思ったら、もうマネージャになるしかない。
クライアントになるという手もある。

399 ：NAME IS NULL：04/06/08 23:23 ID:kyMCR0Gr

>>398
それいいよなぁ。俺もエンドユーザに憧れるよ。
一度でいいからプレゼンされる側になってみたい。

400 ：NAME IS NULL：04/06/09 08:54 ID:???

>>398
うちの会社にもいたな。
クライアントが外資系の有名企業で、
そこにヘッドハンティングされたらやっぱ行くよな。

401 ：NAME IS NULL：04/06/11 00:44 ID:???

>>398
> クライアントになるという手もある。
技術や上がりのエンドユーザか、いい加減なことがいえなくなるけど、
きちんと説明すればわかってくれるいいお客さんになるな。

402 ：NAME IS NULL：04/06/11 09:44 ID:???

ウチの会社のシステム、テーブル設計滅茶苦茶。

全部外注にやらせてて、そのサブシステム作るよう言われたんだけど、
フィールド名のローマ字表記の形式は統一されていないし、正規化は
されていない部分が多い。

受注～だけでJUCHU～,JUTYU～,JYUCYU～の種類がありやがる… orz

403 ：NAME IS NULL：04/06/12 00:18 ID:???

>>401
きちんと説明できるほどまともな仕事してるか？
うちは全然駄目だ。
まともな客ほどごまかしが効かなくてボロボロになってる。

404 ：NAME IS NULL：04/06/12 01:00 ID:???

>>402
そんな現場にCORBAをお奨めします。

405 ：NAME IS NULL：04/06/12 05:44 ID:Sn0QQyxZ

　　　　フ　　　　ー　　　　ン　　　　　　（（　
　　　　　　　　　　　　　　（（　　））　　　））
　　　　　　　　　　　　））　））　（（　,.-､,.-､_,.-､_
　　　　　　））（（　　（（　　　.,.-､,.-､_,.-､ ´_ゝ`）ヽ
　　　　　（（　　））　　 ,.-､,.-､_,.-､ ´_ゝ`）ヽ:.:.:.:..:.::.）
　　　　　　　　 ,.-､,.-､_,.-､ ´_ゝ`）ヽ:.:.:.:..:.::.）￣￣
　　　　 ,.-､,.-､_,.-､ ´_ゝ`）ヽ:.:.:.:..:.::.）￣￣
　　　／　（　´_ゝ`）ヽ:.:.:.:..:.::.）￣￣
　　（　.:.:.:..:.　:　.:.:.:..:.::.）￣

406 ：NAME IS NULL：04/06/12 06:14 ID:???

>>404 CORBAって…
うちWindowsベースなんだけど。
DCOMじゃダメなのか？

407 ：NAME IS NULL：04/06/12 10:38 ID:YoJrTPLB

>>406
最近DCOMに粘着したワームウイルスがはやってるからねぇ。

408 ：NAME IS NULL：04/06/13 13:45 ID:rgRT/Ze1

すまんおしえてくれ。
　マスターを変える場合、それ以前のデータは全て確定にしたい。
　たとえば年間の集計や月間の集計をとる場合、その途中でマスターが変更されている
　　正規化されている場合はどうするのかなー。
　１）マスターの変更履歴を保存
　２）抽出した日時をチェックして更新を反映する。
　みたいなことをするのか？
　それともマスターは追加だけで削除や変更はさせないようにするのか？

　それとも確定データはマスター更新前にマスターもろとも全部保存？
　ん？、これだと集計なんかできねーな。

409 ：NAME IS NULL：04/06/13 19:00 ID:RUWtE+Jr

>>408
データのほうに集計に必要なマスタの項目はすべてコピーして
持たせるのが一般的かなあ。集計処理も簡単になるしね。

個人的に一番きれいな方法は（1）の変更履歴保存だと思う。

410 ：kk ◆r0p/Rg8RZU ：04/06/13 19:35 ID:dw0IFS93

411 ：NAME IS NULL：04/06/13 21:55 ID:???

>>409
んだね。マスタに変更が発生したらトリガーで
トランザクションにログを書き出すってのでどーでしょ？

412 ：NAME IS NULL：04/06/14 14:52 ID:Z5RHMZcy

>409
＞データのほうに集計に必要なマスタの項目はすべてコピーして
　それだと正規化にならんでしょう？　実は、やり方がわからなくて、
　そういうやり方でやっちまったのだが。

＞４１１
>んだね。マスタに変更が発生したらトリガーで
>トランザクションにログを書き出すってのでどーでしょ？
そこんとこ詳しくおせえて。
　トランザクションてのは、一連の処理を保障するため途中でエラー
した場合それまでやった処理をキャンセルする機構でしょ。
　集計は更新時に一回だけじゃないよ。
ちょっと違うようなきがする。

413 ：NAME IS NULL：04/06/14 20:55 ID:???

>>412
>　それだと正規化にならんでしょう？

馬鹿正直に正規化するなら、マスターの項目のうち、
マスターの主キーのほかに日時にも従属する項目は
（マスターの主キー＋日時）を主キーとする別テーブルに分けるべきだ。
あまりお勧めしないが。

414 ：NAME IS NULL：04/06/14 21:33 ID:???

>>412
マスタと同じ項目を持っていたらどんな場合でも非正規化になるわけじゃないよ。
例えば、製品マスタの単価はあくまで現在の単価だけど、売上テーブルの単価は
製品を売ったときの単価。同じ単価でも意味が違えばそれは違う項目。

415 ：NAME IS NULL：04/06/15 13:00 ID:JP7MgTZ9

>414
　なんとなくわかるような。価格の場合そうだろうね。
顧客ID　名称　住所
の場合に住所が変わるケースはたまにあるよね。
住所を全部埋め込むのは勿体ないきがするし。
こんな場合は住所はこのマスターからは分けるべきか？

416 ： ◆sybase.d.c ：04/06/15 18:53 ID:???

>>412
ここでいうトランザクションとは、いわゆる
RDBMS機構のトランザクションのことではなく

「一連のやりとりを日時・セッション別に記録したログ」

のことと思われ。けっこうあちこちの現場で聞くので方言ではないだろう。

マスタ以外にログ作っとくと、なにかと便利よ。

417 ：411：04/06/17 13:44 ID:T4SLT8iK

>>412
遅レスすまん。あと、言葉が足りひんかった。
業務仕様はよく分からんけど、
マスターのテーブルにINSERT/UPDATE(DELETE)のデータベーストリガーを
作っておいて、データベーストリガーではトランザクションテーブルに
INSERTしていくってな仕組みを作る。
そうすればDWH的に何でも対応できそうな気がした。

418 ：NAME IS NULL：04/06/17 23:27 ID:???

ウィザードリの個人情報を正規化するとどーなる？

名前、種族、職業、年齢、経験値（レベル）、お金、状態（死とか灰とか）
腕力、知力、精神力、すばやさ、体力、運
アイテム８こまで。（アイテムの状態＝不明・装備・のろい）

419 ：NAME IS NULL：04/06/17 23:49 ID:???

キャラクタtbl
-----------+-----+-----+----+-------+-----+-----+------+--------+-----+---+-------
キャラクタCD | 名前 | 年齢 | お金 | 経験値 | 腕力 | 知力 | 精神力 | すばやさ | 体力 | 運 | 職業CD

状態Tbl
-------+-----
状態CD | 状態名

キャラクタ状態Tbl
-----------+--------
キャラクタCD | 状態CD

アイテムTbl
----------+-----------
アイテムCD | アイテム名

アイテム状態Tbl
--------------+-------------
アイテム状態CD | アイテム状態

アイテム-アイテム状態Tbl
----------+---------------
アイテムCD | アイテム状態CD

キャラクタアイテムTbl
-----------+-----------------------+-----------
キャラクタCD | アイテムスロット番号(<=8) | アイテムCD

420 ：NAME IS NULL：04/06/18 00:43 ID:???

>>419
それだと同じアイテムは全部同じ状態になるけどそういうものなの？
ウィザードリィをよく知らないんだけど。

421 ：WIZ大好き：04/06/18 22:17 ID:Fot6gVKU

こんなんは？

職業マスタ
-----------------------------------------------------------------
職業CD｜職業名｜転職可能能力（腕力|知力|精神力|すばやさ|体力|運）

アイテムCDマスタ
-----------------------------------------------------------------
アイテムCD｜アイテム名｜価格|装備可能部位｜装備可能職業
｜特性値（攻撃力など）｜特殊効果CD

422 ：NAME IS NULL：04/06/18 22:34 ID:???

>>421
ぱっとみて思いついたこと。穴がありそう。
（１）１つのアイテムに特殊効果は１つしか持てないけどいいのか？
（２）１つのアイテムに装備可能職業は１つでいいのか？
（３）例えば攻撃できないアイテムの攻撃力はNull？
（４）装備できないアイテムの立場は？
（５）職業に特徴はないのか？

ともあれマスタ２つだけでは何とも評価できない。
全部書き出してほしい。

423 ：419：04/06/18 22:39 ID:???

>420
；TДT)ｱﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞほんとだ。じゃこれでどうだ

アイテムTbl
----------+-----------
アイテムCD | アイテム名

アイテム基本状態Tbl
----------+----------------
アイテムCD | アイテム状態CD

アイテムインスタンスTbl
--------------------+------------
アイテムインスタンスCD | アイテムCD

アイテムインスタンス-状態Tbl
--------------------+---------------
アイテムインスタンスCD | アイテム状態CD

キャラクタアイテムTbl
-----------+-----------------------+--------------------
キャラクタCD | アイテムスロット番号(<=8) | アイテムインスタンスCD

　アイテムインスタンスは敵からもらうとか宝箱を開けるとかのイベントで
生成されて、アイテム使用などで破棄される。アイテムインスタンスは
アイテム基本状態Tblから"装備部位"などの基本状態を受け継いで、
追加の属性があれば何らかの規則にしたがって追加される。

　同種のアイテムはまとめてもてる仕様だったらスマソ。これじゃ対応できんねぇ。

424 ：NAME IS NULL：04/06/19 07:50 ID:OHujBfWT

第３正規化までやると以下のよーになる。

1. キャラクタマスタ
(ID・名前・種族CD・職業CD・年齢・経験値・金・状態・腕力・知力・精神力・すばやさ・体力・運)
2.種族マスタ
(種族CD・種族名)
3.職業マスタ
(職業CD・職業名)
4.アイテムマスタ
(アイテムCD・アイテム名)
5.状態マスタ
(状態CD・状態名)
6.アイテムテーブル
(ID・アイテムCD・状態CD）

425 ：NAME IS NULL：04/06/20 16:03 ID:po3I7fVk

CDって何？　Codeのことかい？
IDとCDって区別してるかい？

426 ：NAME IS NULL：04/06/20 19:45 ID:???

>>424
同じアイテムを２個以上持てないのが気になる。

427 ：NAME IS NULL：04/06/22 09:22 ID:???

>>426
アイテムCDとは別にIDをふって、そっちを主キーにしてるってことなんだろ。

アイテムテーブル
----------------
ID アイテムCD
1　100
2　100

428 ：NAME IS NULL：04/06/22 19:26 ID:???

>>427
IDってキャラクタマスタの主キーになってるフィールドだとおもう。
でないと、キャラクタとアイテムを関連づけるテーブルがないことになる。

429 ：NAME IS NULL：04/06/23 14:29 ID:???

>>428
あ、本当だ。キャラクタマスタにも「ID」がある。
てっきりキャラクタマスタの主キーに「キャラCD」でもあるのかと思ってたよ。

とすると、確かにCDとIDの使い分けが謎だな。

430 ：NAME IS NULL：04/06/24 01:03 ID:???

この程度の正規化もまともにできないなら、
正規化しないテーブルの方がましかもしれない。
格納できない情報が出るようではどうしようもない。

431 ：NAME IS NULL：04/06/24 06:26 ID:???

キャラクタテーブル：
キャラ名, 年齢, お金, 経験値, 所持アイテム, ...
もょもと, 20, 500, 16777216, 001040080, ...

アイテムテーブル：
アイテムID, アイテム名
001, やくそう
002, たいまつ
040, どくけしそう
080, はかいのつるぎ
120, くさりかたびら

このもょもとは、いま「やくそう」と「どくけしそう」と「はかいのつるぎ」を持っています。
キャラクタテーブルの所持アイテムの桁数を所持限界アイテム数 * 3 、
例えば8個までなら24桁にすればOK。所持限界数を増やしたいときは
桁数を増やすだけで済むから拡張性もバッチリです。

432 ：NAME IS NULL：04/06/24 08:25 ID:???

>>431
すごい!!
目から鱗って感じ。

433 ： ◆sybase.d.c ：04/06/24 09:12 ID:???

各アイテムはひとつづつしか所有できないなら、それでも格納できるが
まともなSQL書くとやってられなくなるだろう、きっと。

ﾈﾀにﾏｼﾞﾚｽ（・∀・）ｶｺﾜﾙｲ(´・ω・`)

434 ：431：04/06/24 18:57 ID:???

>433
DAO の Recordset でキャラテーブルを開いて所持アイテムの列を 3文字ごとに切り出し、
アイテムテーブルを seek メソッドで検索すれば非常に高速に所持アイテムを一覧できます。

435 ：NAME IS NULL：04/06/24 19:52 ID:???

>>431
そんなまねするくらいなら3桁の項目を8つ持った方がまし。

436 ：424：04/06/24 22:05 ID:2XzNgdAE

アイテムに個数とゆー要件は当初無かったからこーなった。
個数を保有するなら６（アイテムテーブル）でしょう。
ほら、第３正規化までやっとくと、後から項目追加になっても
楽になるでしょう。

ちなみにIDはキャラクタIDのこと。
（すまん、CDとIDの使い分けは特に意味なし）

437 ：NAME IS NULL：04/06/24 22:14 ID:???

>>436
同じアイテムは1つしか持てないって前提は普通しないと思ったんだな。
でもそれは正規化以前の問題だから、ここでは関係ないやね。了解。

それはそうと、アイテムテーブルに個数ってフィールドを足すんだね。
そうすると同じアイテムを２個もってるときに、1個だけ装備できないよ。

438 ：424：04/06/24 22:34 ID:2XzNgdAE

とゆーか要件定義をキッチリ決めてください。
ただ、437さんの『同じアイテムを２個もってるときに、1個だけ装備できない』て
ことは無いでしょう。

例えば、
状態マスタ
(状態CD・個数）
01・装備

で、
アイテムテーブル
(ID・アイテムCD・状態CD・個数）
001・002・01・2
にすれば、
アイテムCDが002であるアイテムを２個装備していることになりますね。

439 ：NAME IS NULL：04/06/24 22:43 ID:???

>>483
アイテムCD 002を2個持ってるときに、1個装備して1個装備しないってのができないかと思った。
（ID・アイテムCD）が主キーだと思ってたけど、もしかして（ID・アイテムCD・状態CD）が主キー？　
それならできるね。
でも主キーがそれだとするとアイテムが複数の状態を持てないね（呪われたアイテムを装備とか）。

仰せの通り、要件定義をはっきりしろってところに落ち着くけど。

440 ：424：04/06/24 22:57 ID:???

ちょっとこれから出かけるんで今日は最後になりますけど。

『主キーがそれだとするとアイテムが複数の状態を持てない』

であれば、状態マスタに装備を持たずにアイテムテーブルに装備のOFF/ONの列を
追加すれば対応できますね。

状態マスタ
(状態CD・個数）
00・正常
01・呪い
02・故障

アイテムテーブル
(ID・アイテムCD・状態CD・個数・装備）
001・002・00・1・1
001・002・01・1・1
（装備の列は1:装備中 0:未装備）

てなかんじですかね。勿論装備品以外のアイテムは0

まぁでも正規化すれば後からどんどん仕様変更（追加）が発生しても
ある程度は柔軟に対応できますよね。

441 ：NAME IS NULL：04/06/24 23:22 ID:???

>>440
それはダメだと思う。
主キーに変更がないとすると、同じ状態のアイテムを2個持ってるときに、
片方だけ装備ってのができない。主キーの値が重複するから。
だからって主キーを(ID・アイテムCD・状態CD・装備)にするか？というとどうなんだろう。

仕様変更にはある程度柔軟に対応できると思うけど、そのＤＢを使う既存のアプリケーション込みで考えると、
主キーを変更するような変更には弱いと思う。

あと、状態ってのがよく分からない。状態マスタに格納する値の例がもう少しほしいな。
>>440の例だと、状態マスタに格納するのはアイテム単体で成立する状態みたいだけど、
装備ってのはキャラクタとアイテムがそろって初めて成立する状態だから、
装備を状態テーブルから分けるのは正しそうだけど。

442 ：NAME IS NULL：04/06/25 00:45 ID:???

このスレ見ててシロートなりに疑問に思ったのだが、
実際ドラクエとかＦＦってC++とかで作られてるんだよね？
まさかあのソフトの中に簡易的なＤＢエンジンも含まれてるのかね？
でも保有情報のアクセスで並列処理は無いだろーからＤＢエンジンは
必要ないか。。
てことはHashTableやVectorを上手く使いまわしてるのかなぁ？

443 ：NAME IS NULL：04/06/25 09:52 ID:???

>>442

アドレス　データ
--------------
00　　　　10 ← HP
01　　　　08 ← MP
　　　：
20　　　　01 ← アイテムコード1
21　　　　01 ← アイテムコード2
22　　　　03 ← アイテムコード3
　　　：
36　　　　40 ← アイテムコード15
37　　　　00 ← アイテムコード16
38　　　　00 ← アイテムコード17
　　　：

大まかに言えば、こんな感じでデータがメモリに格納されてるはず。

444 ：NAME IS NULL：04/06/26 14:15 ID:???

>>442

>>431

445 ：NAME IS NULL：04/06/27 17:16 ID:???

うちの会社で一昔前のPC98ノートに、ナイルというデータベースが
インストールされていた。

数年前、さすがのPC98ノートも液晶の寿命で引退を余儀なくされ、
その際、ナイル上で作った数々のデータをインポートする為に
解析する仕事が私の元に飛び込んできた。

データベースを空けてびっくり、どのテーブルも正規化なんてされて
ませんw

でも、正規化を知らなかった前任者のおかげで
テーブルの解析はとっても楽でした。

446 ：NAME IS NULL：04/06/28 00:16 ID:???

ウィザードリィのキャラには性格もあるよ
悪・中立・善

性格によって装備できないアイテムとかあったり
対立する性格の場合、パーティが組めなかったりするよ

447 ：NAME IS NULL：04/06/29 00:05 ID:pMfaeGQy

>>性格によって装備できないアイテムとかあったり
それはアイテムテーブルとキャラクタテーブルに属性を保有する

>>対立する性格の場合、パーティが組めなかったりするよ
それはデータベースに保有する必要はない。
アプリケーションでパーティを組むときに判断するべき。

448 ：NAME IS NULL：04/06/29 00:11 ID:???

>>447
この流れでいけば、パーティテーブルがあるんだろう。

449 ：NAME IS NULL：04/06/29 00:26 ID:???

>>448
それは流れ重視？
最近なんでもDBサーバにやらせようとする風潮に
ウンザリしてるからさ。

450 ：NAME IS NULL：04/06/29 09:41 ID:???

キャラテーブルにパーティID埋めとくだけでいいだろ。

451 ：NAME IS NULL：04/07/01 16:04 ID:???

キャバクラのテーブルで、おねーちゃんたちとパーティしたい

452 ：NAME IS NULL：04/07/02 00:13 ID:???

>>451
selectも出来んくせによく言うよ。

453 ：NAME IS NULL：04/07/03 08:48 ID:t1hRtxZ6

>>446
悪(善)のキャラを善(悪)のパーティで回収すりゃ、
善悪混成パーティになるだろうが。

454 ：NAME IS NULL：04/07/04 02:02 ID:???

>>453
そんなビジネスロジックの話じゃなくて、エンティティとリレーションの話だから。

455 ：NAME IS NULL：04/07/10 14:12 ID:???

項目　　　内容
果物　　　オレンジ<>ミカン<>リンゴ
飲料　　　コーヒー<>紅茶<>ココア

こんな風に区切り文字を入れて、複数の内容を突っ込むのは間違ってます？
項目の部分を検索するだけなら、早くなるかなとか思ったんですけど。

456 ：NAME IS NULL：04/07/10 15:44 ID:???

「紅茶とコーヒーの表示順を入れ替えてほしいなあ。」
という仕様変更に対する作業工数を考えてみたらどうかな。

457 ：NAME IS NULL：04/07/10 16:39 ID:???

直接順番を書き換えるとか、表示する時に個別に対応するとか…。
なるほど、あまり変則的なやり方はするものではないですね。
ありがとうございます。

ttp://www.stackasterisk.jp/tech/dataBase/postgresTuning03_02.jsp;jsessionid=aaZXoAg1vq1h
上記のような記事を読んで、
あまりテーブルを分けたりしない方向でいった方が良いのかなと考えてました。
こう言うのを考えるのはきちんと正規化出来てからですね。

458 ：NAME IS NULL：04/07/11 01:14 ID:???

>457
んだ。
検索を高速に行いたいというなら、実データとは別に検索専用のテーブル
かなんかを作るほうがいいんでないかな。

459 ：NAME IS NULL：04/07/13 00:19 ID:???

oracleマスタの教科書には、
「リレーショナルデータベースでは、基本的には第３正規化と呼ばれる重複した値を
最小限になるようデータをグループ化して表を設計します。
しかし、検索がメインのDSSシステムでは、正規化したままだとパフォーマンスが出せない事があり、
冗長化と呼ばれる正規化したものを崩す設計をします」
と書かれている。

ちなみに作者はあのカリスマインストラクタ、マダム代田佳子タンです。

460 ：NAME IS NULL：04/07/13 00:35 ID:???

ごく当たり前のことを言っているようだが...？

461 ：NAME IS NULL：04/07/13 11:43 ID:???

Oracle マスタを持っていても
この正規化と正規化を崩すバランス感覚を持っているとは限らないのが
資格の問題点やね。理論で分かっていても実践で役立たない Oracle マスタ多すぎ。

462 ：NAME IS NULL：04/07/13 15:31 ID:???

Oracleマスタってデータモデリングとは関係ないような。

463 ：NAME IS NULL：04/07/13 20:00 ID:3unH/A06

トランザクションもしらないアホが作った
主キー以外全NULLがOKなマスタに主キーがないマスタがちらほらという
糞DBの開発なんてできるかよ・・・orz
案の定重複カラムだらけ・・・・・・・・・・・・

たぶん人生の中で一番ひどいやつだな

誰か助けてくれ、まじで

464 ：NAME IS NULL：04/07/13 20:54 ID:???

>463
TRUNCATE TABLE ますた;

465 ：NAME IS NULL：04/07/13 23:28 ID:???

>>463
お前は二番目に不幸な奴だ。
主キーがあったことを感謝すること。

466 ：NAME IS NULL：04/07/14 00:12 ID:???

>>465
俺なんかな、主キーは一応あるけどリレーションシップなんか当然なくて、
しかも結合に使うフィールドのデータ型が２つのテーブルで違ってるんだぞ。
普通に結合するだけなのに型変換。時々異常データがあって変換に失敗したりとか。
もういやん。

467 ：NAME IS NULL：04/07/14 06:58 ID:???

>466
漏れなんか、主キー・リレーションシップほとんど無しは当然として、
参照元の列 w(bool) が True なら列 x(int)&y(text) を、False なら x&z(int) を
参照先の主キー(相当)の列 a(text) に代入するというファンタスティックなブツを見たことがある。
アプリケーション側で a の値を分離して、w の値によって結合(?)する列を決定するのだ。
((((ﾟДﾟ；))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

いちおう y と z の桁数が違ったので重複は無いようだけど、y は 00123 みたいな
0付き数値が入ってるからz の桁数が y に追いついたらトンでもないことに
なるだろうなと思った。

＃塚これ、表示で 00000123 とか見せたいところは全て TEXT 型で律儀に 0 入れてるよ…

468 ：NAME IS NULL：04/07/14 23:08 ID:???

お前らここは不幸自慢スレじゃねーだろ

…あ、いいのか。ゴメン

469 ：NAME IS NULL：04/07/19 21:36 ID:???

こういうテーブルって、非正規形？それとも第3正規形？

create table 売上 (
年 number(4) primary key,
売上_01月 number,
売上_02月 number,
...
売上_11月 number,
売上_12月 number
);

本によって書いてあることが違うんで困ってます。

470 ：NAME IS NULL：04/07/19 22:36 ID:???

>469
どう違うことが書いてあるのか詳細に知りたいな。
とりあえず[売上]が繰り返し項目になっているから非正規形だろう。

CREATE TABLE 売上(
年月 datetime,
売上 long,
CONSTRAINT pkey PRIMARY KEY (年月)
);

こうすれば主キー属性[年月]に全ての属性が従属する第3正規形になるかと。

471 ：NAME IS NULL：04/07/19 22:42 ID:???

>>469
形式的には第五正規形。
でもそんな使い勝手最悪なテーブルは設計しない。

>>470
[売上]は繰り返しじゃない。
たとえば[売上_01月]と[売上_02月]は交換不可能。
繰り返し項目なら交換しても問題ないはず。

472 ：470：04/07/20 00:09 ID:???

>471
Σ(ﾟДﾟ；ﾊｯ確ｶﾆ!!

　∧||∧
（　 ⌒ ヽ　>469
　∪　　ﾉ　　ｽﾏﾝｶｯﾀ
　　∪∪

473 ：470：04/07/20 23:47 ID:???

>471
お手元の資料(TEDB3週間)でちょいと調べてみたけど、第5世紀系は結合従属性
～「正規化して分割された3つ以上の表(仮に x,y,z)を結合するとき、全ての表を
　結合しないと元の表(a)には無かったタプルが現れる状態」～
に分割した3つ以上の表のことの様だから、第5正規形ではない様な?

　といふことで >469 の表は「主キー項目(年)に全ての属性が完全関数従属する」第3正規形
が正しいのではないだらうか。

474 ：NAME IS NULL：04/07/22 00:07 ID:???

3週間本は、あまりにも間違いが多過ぎることで有名

475 ：NAME IS NULL：04/07/23 22:08 ID:???

>>473
んなあほな。
じゃあ第三正規形ってのは第二正規形から分割された２つの表の事？

「分割した3つ以上の表のこと」というのがどこから出てきたのか気になる。
引用ではなさそうに見えるが。

476 ：470：04/07/27 00:02 ID:???

>475
　∧||∧
（　 ⌒ ヽ　例となる表を用意しようとしたら、再結合したら影像だらけになる表になってしまった…。
　∪　　ﾉ
　　∪∪
「分割した3つ以上の表のこと」は、『ある関係 R を分割してできる関係 R1,R2,R3... の間に
結合従属性が成立するとき,この R1,R2,R3... を第五正規形と言う』見たいなことが
3週間本に書いてあったはず。

ｊ３、明日3週間本をもう一回熟読して出直して参る。

477 ：470：04/07/27 00:04 ID:???

しかし、Web 上を探してみても第四正規形以降を解説したわかりやすい資料がなかなか
見つからなくて難儀する。文書ベースだけでなく例となる表も載ってると尚良いのだけれど…。

478 ：NAME IS NULL：04/07/30 00:24 ID:???

同僚の持ってた死すアドの参考書を見てみたら,
「第二正規形は第三正規形に分割する途中経過なので、あまり重要ではありません」
と言う旨の解説が…それでいいのか。

479 ：NAME IS NULL：04/07/30 22:19 ID:???

非正規化など飾りですよ！

480 ：NAME IS NULL：04/07/31 16:35 ID:wijBGoRO

>>478
その参考書で勉強したヤシは秋のシスアド試験受けるんか？
合格したらその論理は正しいかもな（ｗ

481 ：478：04/08/09 21:58 ID:???

>480
うちの同僚誰も初級死すアドすら取ってないよ。みんな1-2度ほど落ちてるし。所詮運用屋は
その程度のものか…。一番死すアド向きなポジションだと思うのだがね。ちなみに今回は
見送るらしい。多分このまま取らないつもりだろう。

482 ：NAME IS NULL：04/08/17 13:15 ID:???

シスアドは営業の道具だろうに、見送るなんて会社の利益に反してる。

と言ってあげなさい。

483 ：NAME IS NULL：04/08/26 19:39 ID:???

会社の取締役も正規化しないとだめですな。

484 ：NAME IS NULL：04/08/26 22:26 ID:???

>>483
取締役の最適化だけで済むとは恵まれた環境ですな。

485 ：NAME IS NULL：04/08/27 14:16 ID:fXaaZ0AL

これからDBからみのチューニング作業をやらなきゃいけないんだけど、
とりあえずDBのオブジェクトを調べていたらViewの多さに唖然。。
Table30くらいなのにViewが100くらいある。。
しかもViewの中でViewを参照してるわ、集合関数とか
バリバリ使っていて。
TableのER図を興してみたらとりあえず第３正規化までは
されているようだが。
SQLの見直しがチューニングの基本だとは思うけど、
こんだけViewを使いまわすと人間も混乱するし
オプティマイザも混乱するだろーな（ｗ

486 ：NAME IS NULL：04/08/27 16:04 ID:???

>>485
規模にもよるだろうが、アプリケーション組むときに作られるSQLは
100や200じゃないだろう?
Viewとしてアプリケーション外にSQLを出しているだけの話で、唖然と
するようなことでもないと思われ。

いくらViewがViewを参照してようが、DBMSの方に格納してあるのだから
依存関係の把握もたやすいだろ。

487 ：NAME IS NULL：04/08/27 21:25 ID:???

>>486
あんたDBのパフォチューやったことないでしょ。
viewの階層が深くなるほど保守性は悪くなることは
容易に想像つかない？

488 ：NAME IS NULL：04/08/27 21:58 ID:???

プログラム側の負担を減らしたり、DBアクセスの正規化を図る目的なんかで
VIEWやストアドでDB側にロジックを置くのもひとつの手法だし、
>>485だけの説明では一概になんともいえん。

もちろんVIEWを利用するとその分遅くなるけど、
VIEWを使わずに複雑怪奇なSQL(もちろんその場面で最適化された結果)
がコードに散乱するのはもっとイヤ。

489 ：NAME IS NULL：04/08/27 22:51 ID:???

>>487
保守性を意識しないViewの設計をするといたずらに階層が深くなることはあっても
Viewの階層の深さと保守性の悪さが比例するわけではない。
むしろ保守性を意識するなら積極的にView(もしくはストアド)を使っていくべき。
性能面から見ても、DBMSの実装やアプリケーションの仕様によっては、Prepareの
必要のないViewを積極的に使った方が性能が出せる場合も多々ある。

大体、想像でパフォーマンスチューニングするような奴に噛みつかれるのは甚だ
不本意きわまりない。寝言は寝てから言え。

490 ：NAME IS NULL：04/08/28 20:44 ID:???

>>489

今ごろviewを推進する人がいるとは。。
保守性を意識するなら積極的に導入すべき？嘘でしょ。

セキュリティを意識してViewを導入するならまだしも
複雑なSQLを別ファイルに置いとくだけの目的なら私は消極派ですね。

prepareの必要が無いと仰るがその動的SQL分Viewを作成するの？
管理が煩雑になるだけ。大体ヒント文も使えないことが多いし。
それで性能が出せることが多々ある？嘘としか思えない。

#誤解の無いように書くけどストアドは必要であれば導入することには
#賛同できますね。

491 ：NAME IS NULL：04/08/28 23:10 ID:???

アプリサーバとDBサーバを混在して考える風潮があるな。
もしOLTPでストアドを使うならそれはDB設計かアプリケーションが
ショボーンかのどちらかが多数だと思います。
大量の件数をこなす時（バッチ処理とか）くらいじゃない？
ストアドなんて。

492 ：NAME IS NULL：04/08/29 07:03 ID:???

ttp://jibun.atmarkit.co.jp/fengineer/rensai/omgdb02/omgdb01.html
>PL/SQLは、SQLと違って一文ずつではなく、ブロック単位でサーバに送信
>できるので、ネットワークを通る通信量（トラフィック）を少なくすることができます。
>ネットワークへの通信量を少なくできるということは、パフォーマンスの向上にも
>つながりますし、そのほかにもさまざまなメリットがあります。

493 ：NAME IS NULL：04/08/29 11:54 ID:???

>>490
> prepareの必要が無いと仰るがその動的SQL分Viewを作成するの？

( ﾟДﾟ)ﾎﾟｶｰﾝ
釣りだよね?

494 ：NAME IS NULL：04/08/29 13:05 ID:???

今日一つの言語でシステムが組まれることなんてありえないし
積極的にVIEWを使うことは保守性を高めることに繋がるというのは間違ってないと思う

> prepareの必要が無いと仰るがその動的SQL分Viewを作成するの？
動的SQL内でVIEWを使用するとVIEW内部までPrepare対象になるDBMSなんてあるの?
動的SQLの中にあり、他のSQLでも共有することの出来る静的な部分をVIEWにするから
保守性があがるのであって、常識で考えて全てのSQLをVIEWにするなんてありえないよ

VIEWだと管理が煩雑になる、プログラムソースなら管理できるなんてことがあるのかなあ
多人数が好き勝手にVIEWを作ったら作りっぱなしでロクにドキュメント管理か出来ていない
組織なだけなのでは?

495 ：NAME IS NULL：04/08/30 11:39 ID:???

他アプリとのインタフェースはCSVファイル経由でｗ

496 ：NAME IS NULL：04/08/30 21:26 ID:???

>495
それだとユーザがカンマ打ったときにバグるのでタブ区切りにしてください。

497 ：NAME IS NULL：04/08/30 21:28 ID:???

バグらねーだろ

498 ：NAME IS NULL：04/09/01 08:09 ID:nSVJnFyR

このスレ生きてたか

499 ：NAME IS NULL：04/09/07 19:58 ID:???

>>459
それ正しいな。
いくら保守性などを上げたとしても、まともに動かなきゃ本末転倒だし。
数千件ぐらいならいいだろうけど、数十万以上の規模になると
体感で分かるぐらい差が出る。

500 ：NAME IS NULL：04/09/08 11:14 ID:???

とあるテーブルにメールアドレスとかあったんだけど
このまえメールアドレスの個数をひとつ増やせって言われて
mail,mail2 という感じでひとつ増やしたんですけど
これっていやな予感とか感じる前に
メールだけテーブル分けた方がいいんですかね

501 ：NAME IS NULL：04/09/08 13:16 ID:???

>>500
設計の視点からのみの正論ならば、分割して保持すべき。

実務との総合判断になると、現状ソースに対する影響・将来的な拡張可能性を考えて・・・。

502 ：NAME IS NULL：04/09/11 19:57:42 ID:???

>>500
1個人(法人)につきメールアドレスを複数保持するなんて
当たり前。であればテーブルを分割することが第２正規化では？

503 ：NAME IS NULL：04/09/12 06:38:20 ID:???

保持しているメールアドレスすべてを登録する必要がないことも多い。
お前は、メールアドレス記入欄がひとつしかないときに「ふたつ書けない！」と
文句を付けるのか？大抵はだまって主要なメールアドレスひとつを記入するだろ？

システムにもよるが、電話番号やメールアドレスなどの連絡項目のようなものは
高々1つか 2つと制限しても問題ないことが多い。2つや 3つであれば正規化せずに
別の列として持たせたほうが取り扱いが楽なこともある。

入力原票の記入欄だって大抵、ひとつかふたつなんだから割り切りも大事。
なんでもかんでも拡張性を意識しすぎると、かえって分かりづらくなる。

504 ：NAME IS NULL：04/09/17 22:15:22 ID:???

>>503
お前とは何ですか？お前とは。

だいたいあんたが主張していることなんか当たり前すぎる話だろ。
それを力んで何を偉そうに語ってんだか。。

505 ：NAME IS NULL：04/09/18 16:52:53 ID:???

お前と呼ばれることに慣れていない奴は2ch見ないほうがいいよ。

506 ：NAME IS NULL：04/09/19 00:21:36 ID:???

>505
繰り返し項目を別テーブルとして分割すべきかどうかすら
自力で決定できない奴が何言ってるんだか・・・

507 ：NAME IS NULL：04/09/19 12:47:51 ID:???

502=504=506 みじめだからやめとけ。

508 ：502：04/09/19 22:47:42 ID:???

すまん、今扱ってる仕事が某ISP会社のサービス支援システムだからさ。
結構あるんだよ。責任者メアド・連絡先メアド・携帯メアド・対外非通知メアド
とかその他もろもろ。
なんでもかんでも正規化しろとは言わないけど、俺の現場では顧客マスタからは
分離してるよ。まぁ扱ってる業種によるってことだわな。

509 ：NAME IS NULL：04/09/20 01:19:35 ID:???

このへんの微妙な点については、何が正解かなんて現場で
顧客の業務見てる奴にしかわかんないよ。

510 ：NAME IS NULL：04/09/21 09:54:48 ID:k44kR/kH

＞508
おまえは502で業務も考えず正規化するのは当たり前といってる訳でとってもDQNなんだな
いまさら自分の業務ではとかいってもね

511 ：NAME IS NULL：04/09/21 12:24:35 ID:???

>>510
ずいぶんねじ曲げたな。
どこにも「業務も考えず正規化するのが当たり前」等とは書いてないが
馬鹿にしか見えない文字で書いてあるのか?

>>502は
「個人に複数のメアドが存在するのが当たり前」
であれば
「正規化理論的には分割することが正しいといえるのではないか」
と言ってるだけだろ。何も間違っていない。

512 ：NAME IS NULL：04/09/21 23:11:25 ID:???

けんかすんなよう
過疎板なんだからさー
ﾏﾀｰﾘしようよー

513 ：NAME IS NULL：04/09/24 14:50:28 ID:???

>>510
何か嫌なコトでもあったのかな？
俺はあったぞ！！
12月まで契約延長だぁ！？あんなデスマプロジェクトに
あと3ヶ月も骨身を削ると思うとノイローゼになるぜ！！
あ～ヤダヤダ。。。。

514 ：NAME IS NULL：04/09/30 02:32:59 ID:hg1v0eRR

こう言うのはどっちが良いと思います？
例えば内職でやった仕事と報酬を記録してくような場合簡単なものを仮定して

記録テーブル：作業者,作業日,仕事ID
仕事テーブル：仕事ID,仕事内容,報酬

な感じでテーブル作成し記録テーブルにどんどん記録して行くわけですね。
そして、最終的に作業者の報酬を
select sum(報酬) from 記録,仕事 where 記録.仕事ID=仕事.仕事ID and 作業者=誰某
なんて出すわけです。

しかし此処で仕事テーブルの報酬が会社の状況により上がったり下がったりする事が有るとなると上記の奴じゃ不味い。
さてそこで取るべきのはどちらか。

記録テーブル：作業者,作業日,仕事ID,報酬
仕事テーブル：仕事ID,仕事内容,報酬
として記録テーブルにデータを突っ込む際にその時の報酬も書き込むパターン。
非正規化だが報酬を計算するのは物凄く楽チン。

記録テーブル：作業者,作業日,仕事ID
仕事テーブル：仕事ID,仕事内容,報酬,報酬設定日
と報酬を変えた日時を記録し作業日と報酬設定日時を比較しその時の報酬を弾き出すパターン。
正規化だがSQLが長くなるしコストも掛かる。

どっちが良いと思います？
それとももっと別の良い方法を使うならその方法を。

515 ：NAME IS NULL：04/09/30 02:54:03 ID:???

>>514
仕事記録テーブル：作業者,作業日,仕事内容ID
仕事内容テーブル：仕事内容ID,仕事内容
報酬テーブル：仕事内容ID,報酬,適用開始日,適用終了日

516 ：NAME IS NULL：04/09/30 03:04:44 ID:???

>>515
あ、そうか、報酬テーブルに分けるべきでした。
でもそれでも同じように計算コスト掛かりますね。

517 ：NAME IS NULL：04/09/30 03:14:51 ID:???

>>516
掛かるね。
仕事記録テーブルに書き込んだ後で報酬が変動しないなら、
一つのテーブルにまとめてもいいと思う。

518 ：NAME IS NULL：04/09/30 09:49:13 ID:???

>>514
非正規化だが～の例だけど、そういうのを非正規化とは言わない。
仕事.報酬 → 現在の報酬
記録.報酬 → 作業者が仕事をした時点での報酬
論理的に双方に設定されてなければいけないフィールドだからね。

519 ：NAME IS NULL：04/09/30 09:57:58 ID:???

で、本当に別テーブルに分けるべきかどうかはもう少し要件を詰める
必要があると思う。

例えば、作業者が納品した製品に不良・欠陥・ノルマ未達成があった
場合でも一律の報酬を支払うのかどうか? とか…

おそらく例だからだろうけど、内職で日給?普通は実績*単価じゃないかな?
というのもちょっと疑問に思った。

520 ：514：04/10/01 01:28:13 ID:???

こういうの考えた。
記録テーブル：作業者,作業日,仕事ID
仕事テーブル：仕事ID,仕事内容,報酬
仕事グループテーブル：グループID,仕事ID
これで報酬が変わった場合、新たに仕事テーブルに別の仕事IDで報酬が違うデータを突っ込む。
さらに仕事グループテーブルに報酬が変わる前の仕事IDと同じグループに設定しておく。
そして今後はそちらを記録テーブルへ記録して行くと。
これなら報酬を取得するのも速いし、ある仕事に関しての総報酬額もグループでselect出来るので速いでしょ。
どうでしょうか。

>>519
はい、例ですのであまり細かな突っ込みはご勘弁を。
内職なんてやった事無いので想像で書きました。

521 ：514：04/10/01 01:33:29 ID:???

書いた後、良く見てみたら仕事.仕事内容がグループIDの変わりになりますね。
うーん、例が悪かったか。

522 ：NAME IS NULL：04/10/01 23:28:00 ID:???

>>514 は正規化のことをまったくわかっていない厨房ですか。
記録テーブルに実績として実際に受け取った報酬を記録すればいいの。
そして、それは非正規化とは言わないの。わかった？

523 ：NAME IS NULL：04/10/02 01:52:20 ID:???

>514
センスないね。

524 ：NAME IS NULL：04/10/02 11:22:19 ID:???

>>522
身の回りでもそうだけど
たいして技術も無かったり、単に情報武装してるだけのオタクほど他人の
無知を嘲笑うような物言いで指摘するよな。

525 ：NAME IS NULL：04/10/02 15:28:44 ID:???

>>514 = 524 そんなに悔しかったの？

526 ：＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／：04/10/02 15:43:23 ID:???

　　　　　　Ｖ　　　
　　　　　　　　＿＿＿　　　　　　　　　　　　　　　　＿
　　　　　　　／　＿＿＿＿ヽ　　　　　　　　　／￣　　￣＼
　　　　　　　|　 | /, －､, -､ｌ　　　　　　　　 /､　　　　　　　　ヽ　君の半笑い、ものすごく気持ち悪いよ。
　　　　　　　| _| -|○　|　○||　　　　　　　　|･ |―-､　　　　　　 |
　　 , ―-､　(6　＿ｰっ-´､}　　　　　　　ｑ -´　二ヽ　　　　　 |
　　 |　-⊂)　＼ヽ_ ￣￣ﾉﾉ　　　　　　　　ﾉ＿　ー　 |　　　　　|
　　 |￣￣|／（_ ∪￣ / ､　＼　　　　　　　＼.￣｀　 |　　　　/
　　ヽ　　｀　,.|　　　￣　　|　　|　　　　　　　　O＝＝＝＝＝ |
　　　｀－ ´ |　　　　　　　| ＿|　　　　　　　　/　　　　　　　　 |
　　　　　　　　|　　　　　　（t 　）　　　　　/　　 / 　　　　|

527 ：NAME IS NULL：04/10/03 01:03:11 ID:???

まずは認めることからはじめてみたらどうかと思うよ。

528 ：NAME IS NULL：04/10/04 11:10:18 ID:nlQQ7qe6

すかさずage

529 ：NAME IS NULL：04/10/05 21:51:08 ID:???

テーブルの項目数はどれぐらいが最適なのでしょうか。
いま、設計しているテーブルの項目数が１００を超えているのですが。
やはり、テーブルを分けたほうがよいのでしょうか？

初心者なもので初歩的なことを聞いてスミマセンがよろしくお願いします。

530 ：NAME IS NULL：04/10/05 22:00:39 ID:???

>>529
テーブルを分割する基準は『項目数』ではないと思いますよ。
今設計されているテーブルが業務的にどのような使い方を
されるのでしょう？
マスタ系？トランザクション系？
ただ項目数が100を超えているのは正規化の余地はありそうですね。

531 ：NAME IS NULL：04/10/06 22:50:55 ID:zhL3f+vY

>>529
第3正規化までやってみてそこからですな。

532 ：NAME IS NULL：04/10/07 02:40:29 ID:???

月毎の数値が必要な時、１～１２まで項目をならべるのやめてください
お願いします。

533 ：NAME IS NULL：04/10/07 02:48:35 ID:???

ただのオタクです
データベース一から組めっていわれたら組めます
正規化は理論じゃなくて実測値なんです
スピードとプログラムからの扱いやすさのバランスです
資格だけじゃそこまでわからないでしょうね

534 ：NAME IS NULL：04/10/07 03:55:10 ID:???

掲示板作れって言われたら○○秒で作れます。
って人がいたなあ。

535 ：NAME IS NULL：04/10/07 08:44:08 ID:???

>>533
> 正規化は理論じゃなくて実測値なんです

DBMSが変わるたびに実測取り直して設計し直すのか?
馬鹿だなあお前は。

こういう事言ってる奴に任せると、各種制約を完全無視した頭の悪い
データベースが出来上がるんだろうなあ…

536 ：NAME IS NULL：04/10/07 16:03:18 ID:???

533 は職人
535 は公務員

職人は難しい事は分からないが自分の理論で唯一無二の物をつくる
公務員は決められた仕事を手順に従って行う

性能が必要なら職人に、保守が重要なら公務員に

537 ：NAME IS NULL：04/10/07 16:12:33 ID:???

>>533
それは「正規化」ではなく「最適化」
「正規化」はきちんと定義された用語なの。

538 ：NAME IS NULL：04/10/07 16:55:21 ID:???

>>536
基礎のなってない自称職人ほど始末が悪い物はない。
オタクと職人は違う。

真の職人は基礎をきちんと身につけた上で独自のやり方を確立する(守破離)
その為の徒弟制度であり暖簾分け制度。昔から何も変わらない。

539 ：NAME IS NULL：04/10/07 17:38:35 ID:???

>536
あくまで普遍的な正規化の手法に従って設計しつつパフォーマンスが
問題になる個所で職人的能力を発揮してくれるならいいのだが。
パフォーマンスとのバランスだという点については間違いではないが、
最初からカンと経験だけでDB設計するのはどうかと思うよ。

つーか正規化程度の事を「難しい」とか言うﾔｼは職人とは呼べない。
資格は不要とか不毛な事言わずに、一度体系的に勉強するべき。

540 ：ただのオタク：04/10/07 17:45:27 ID:???

ちがいます、正規化の知識はもちろんもってます。
資格だってもってます。
その上でデータベースの動作原理も理解すれば正規化の本当の
目的がわかります。
そしてどんな場合でも最適な正規化をすることができます。

541 ：NAME IS NULL：04/10/07 17:52:17 ID:???

正規化とパフォーマンスを同列に比較している時点でど素人。

542 ：ただのオタク：04/10/07 17:54:07 ID:???

というか原理がわかってると自然に正規化しなくちゃいけなくなります。

543 ：NAME IS NULL：04/10/07 17:55:41 ID:???

正規化だけ追求する人はいったい何の為にきれいな（だと思える）テーブル達を作るんですか？

544 ：NAME IS NULL：04/10/07 18:04:43 ID:???

>543が作ってるような非正規形オンリーのDBで、プログラマさんを苦しめてプロジェクトを破綻
させたりする事がないようにする為です。

545 ：NAME IS NULL：04/10/07 18:07:36 ID:???

プログラムがわからない人にそれができるんですか？

546 ：NAME IS NULL：04/10/07 18:24:01 ID:???

資格って何だ、初級シスアドか?(笑
知識があって資格持ってる奴が

> 正規化は理論じゃなくて実測値なんです
> スピードとプログラムからの扱いやすさのバランスです

こんな素人臭いことを言うわけがない。

正規化の目的はデータの保守性と整合性を高めること。
「実測値」などと言う単語の入る余地はない。

547 ：NAME IS NULL：04/10/07 18:40:02 ID:???

そういうのを車の免許でいうペーパードライバーっていうんですよ
免許を持ってればブレーキ、アクセルなんて用語はわかるでしょうね
でもどうやって使うかわからない
保守性と整合性を高めることによって結果的に何が得られるか
まで考えたことありますか？

548 ：NAME IS NULL：04/10/07 18:53:04 ID:???

(´-`).｡oO(ブレーキとアクセルの使い方が分からない奴が免許持ってるのか…)

549 ：NAME IS NULL：04/10/07 18:57:22 ID:???

>>547
自分に自身があるなら妙な例え話や後出しじゃんけん狙いのレスはいいから
とっとと自分の意見を書いてみろ

550 ：NAME IS NULL：04/10/07 19:13:04 ID:???

>>549
自分がよく目にする腐った設計をあげて見ますね

プログラム的に３行で処理できるものを項目数のジョチョウによって何十行にもしてくれてる
メンテしやすいとかいって分類名をそのままテーブルに格納しまくってる
呼び出し頻度の高いテーブルのキーに文字を使っている
同じコード体系のテーブルを何個も用意して分けている
バックアップテーブルなのになぜか項目が違う

551 ：NAME IS NULL：04/10/07 19:27:03 ID:???

>545
その、「プログラムがわからない」という前提はどっから出てきたんだ？
おまいさんの職場ではプログラムがわからない奴が設計してるのか？

>550
1番目と4番目なんか、それこそ正しく正規化が行われていない為に発生してる問題だろ？

552 ：NAME IS NULL：04/10/07 19:32:24 ID:???

>>550
へ?
お前の挙げた例と正規化が何の関係があるわけ?

何で唐突に「腐った設計の例」が出てくるんだ?
何が言いたいのかさっぱりわからん。誰か通訳してくれ。

( ジョチョウ(なぜか変換できない)はネタなんだろうか、マジなんだろうか…

553 ：NAME IS NULL：04/10/07 19:32:58 ID:???

資格が一番的発想　=　プログラムないがしろ
資格持ってても正規化できない人が多いってこと言ってるのです。
ＡＣＣＥＳＳでざっとテーブル見て意味不明でもオブジェクト指向
なんかで内包しちゃえばプログラム的には扱いやすいし、手間も少ない
資格だけで偉そうにしてる人はそこまで考えずに自己満足してるだけだって
言ってるだけです。
設計する人がオブジェクト指向を熟知してる場面には出くわしたことないです。
自分自身で設計からやったことはありますけどね

554 ：NAME IS NULL：04/10/07 19:39:23 ID:???

お前の職場が腐ってる事はわかった。
設計と実装を分けて考える事が出来ない事もわかった。
とりあえず話の大筋くらい読めるようになってからまた来い。

次ドゾー

555 ：NAME IS NULL：04/10/07 19:43:16 ID:???

勝手に設計を分けるなって、一連の流れで工数が決定するんだから

556 ：NAME IS NULL：04/10/07 19:46:47 ID:???

以後知障は放置で。

557 ：NAME IS NULL：04/10/07 19:54:50 ID:jKpaIrzT

すげえな
OOで包むからテーブルは意味不明でもいいってかｗ
Accessの名前が出てくるあたり1人で全部やる小規模案件しか経験ねえんだろうなｗ
晒しage

558 ：NAME IS NULL：04/10/07 19:57:06 ID:???

あのなＡＣＣＥＳＳってのはデバッグに使うんだよ
ＯＤＢＣでつないだらOracleのテーブルだって丸見えなんだよ
作り逃げしてるやつはそんなことも知らないのかｗ

559 ：NAME IS NULL：04/10/07 20:11:06 ID:???

スキーマとデータ見る為だけに使ってるならAccessの名前をそこに出す必要無ぇだろ
つぅかそんなくだらない所じゃなくて
>OOで包むからテーブルは意味不明でもいいってかｗ
に対して反論するのが普通だろうが

560 ：NAME IS NULL：04/10/07 20:14:02 ID:???

じゃあ反論しよう
ＡＣＥＳＳで内容見る時に自分がわかりやすいからって
記号やら分類名やら入れるのは間違ってるっていってるんだよ
意味不明っていうのはテーブル設計書を見てない人間にとっては意味不明という意味
開発する人間は設計者より頭がいいので、日本語ばっかりのテーブル内容じゃなくて大丈夫ですよｗ

561 ：NAME IS NULL：04/10/07 20:23:58 ID:???

>OOで包むからテーブルは意味不明でもいいってかｗ
の反論が
>記号やら分類名やら入れるのは間違ってるっていってるんだよ
テーブル設計書を見てない人間にとっては意味不明
なのか？
頼むから日本語を話してくれ。

それに、一体それが正規化と何の関係があるんだ？
お前が>550を書き込む前にそんな低レベルな話をしている人間は一人もいないのだが。

562 ：NAME IS NULL：04/10/07 20:27:14 ID:jKpaIrzT

　知　障　は　放　置　で　。

嵐　に　反　応　す　る　奴　も　嵐

563 ：NAME IS NULL：04/10/07 20:59:35 ID:???

SQLって何？正規化ってどんな考え？というレベルのど素人ですが、
私はこういう時文字の全角/半角でどちらが概ね正しいのかを判断しています&herats;

564 ：NAME IS NULL：04/10/07 21:20:12 ID:???

あー、つまりＡＣＥＳＳとか書いてる方がバカだといいたいわけね♥

565 ：NAME IS NULL：04/10/07 21:41:40 ID:m2OWTAKC

完成された正規形を崩して得られる美しさこそ非正規形の極み。
それは醜さと紙一重の優美さよ。

分かるか？
俺はつい最近その境地に至った。

566 ：NAME IS NULL：04/10/07 22:49:03 ID:???

最低限の正規化にすらもっていけない奴には何を語っても無駄さね

567 ：NAME IS NULL：04/10/07 22:51:00 ID:???

>555の会社の見積書を見てみたいものだ。

568 ：NAME IS NULL：04/10/08 09:55:40 ID:???

>>567
システム開発一式 xx万円(珠に3桁、4桁って必要？)

569 ：NAME IS NULL：04/10/08 10:27:15 ID:???

>568
そういう所あるよな・・・
某大手もそれだった。

570 ：NAME IS NULL：04/10/08 11:06:58 ID:???

>553
　まともにオブジェクト指向ができる人間なら、正規化する事のメリットも同時に分かるはずなんだがな。
　オブジェクトに分割するって、正規化とやってることはあまり変わらんぞ。
（というか、正規化って構造化と同じという気がするがね）

>550
　ツッコミどころ満載だな。

>プログラム的に３行で処理できるものを項目数のジョチョウによって何十行にもしてくれてる
　本質的に正しく正規化できてるなら、項目数が増えてようが基本的にはプログラムでどうこう、
ってのはないはずだがね。SQL が複雑にはなるけど。

>メンテしやすいとかいって分類名をそのままテーブルに格納しまくってる
　分類名がそれほど変化せず、付け替えなどをしないという「実務的な理由」があるなら、
それでも全然問題なし。
　分類名マスタを作るのは確かに正規化だが、必要がないならその正規化を崩すのは
おかしなことじゃない。正規化「しない、できない」と、正規化「した後で崩す」では天地ほど
違う。

>呼び出し頻度の高いテーブルのキーに文字を使っている
　検索条件が文字で、テーブルのキーなら全然普通だろ。
　文字列をキーに使ってようがインデックスと条件さえ真っ当なら関係ないし。

>同じコード体系のテーブルを何個も用意して分けている
　正規化してないのか崩したのかで違うが、これはそれこそ実運用での話になるからな。
確かにそういう腐った設計も多いが。

>バックアップテーブルなのになぜか項目が違う
　あえて項目を変えてるバックアップってこともある。
　状況によって違うのでこれだけでは腐ってるかどうか判別不可。

571 ：NAME IS NULL：04/10/08 13:02:20 ID:???

　知　障　は　放　置　で　。

嵐　に　反　応　す　る　奴　も　嵐

572 ：NAME IS NULL：04/10/08 15:45:15 ID:???

>>まともにオブジェクト指向ができる人間なら、正規化する事のメリットも同時に分かるはずなんだがな。
>>正規化を崩すのはおかしなことじゃない。

ハァ？

573 ：ただのオタク：04/10/08 15:57:13 ID:???

勘違いされてるようだが、正規化は必要ですよ。
ただ＋α的な考えも必要です。
正規化の段階ですでに間違ってるものが多いですがね

574 ：NAME IS NULL：04/10/08 16:02:06 ID:???

流れを変えるために…

うちの会社のシステムはほとんど自分ひとりで作っていたのだが、さすがに
手が足りなくなってきたのでいくつかのシステムを外注することにした。
出来上がってきたシステムというのが、コレが…また…なんていうか…

・宛名マスタなどの共有可能なマスタをそれぞれに持っている。
・さらにその宛名マスタにシステム固有の情報が追加されている。
・バグを１つ直させたらバグが増えた。
・請求金額や売上金額に小数点以下があっても無視。

などなど、おまえらそれでもプロか！！というような内容。
自分で作ったほうがましだったかも…orz

575 ：NAME IS NULL：04/10/08 16:32:59 ID:???

まさに↓だな。
IT技術者の2人に1人は“プロ未満”
「2万人調査」から人材像とスキル実態が判明
ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20041006/150921/

576 ：576：04/10/08 16:44:16 ID:???

別システムの開発に絡んで、この腐れDBを参照しなければならないのだが…
どっからどう手をつけたらよいもんだか…('A`)ﾏﾝﾄﾞｸｾ

577 ：NAME IS NULL：04/10/08 16:47:03 ID:???

あんたが５７６なのはわかったから

578 ：574=576：04/10/08 16:50:05 ID:???

しまった…

579 ：ただのオタク：04/10/08 16:54:12 ID:???

>>574
それは正規化の問題というより業務知識の問題
プログラムできりゃいいわけじゃないのだよ

580 ：NAME IS NULL：04/10/08 17:04:47 ID:???

>>574
DB設計まで丸投げしたの？
つか、どんな仕様書書いて依頼したの？

581 ：574：04/10/08 17:59:51 ID:???

>>580

> DB設計まで丸投げしたの？
> つか、どんな仕様書書いて依頼したの？

それを言われるとつらい。はい、○投げしました。
まぁそれでも処理の流れや必要と思われるファイル定義なんかは
ある程度作って説明したんだけどね。

まぁ、こっちの依頼の仕方も悪かったのであまり強いことはいえないのだが
さすがにデバックもろくにしてないシステムを納品されたら相手の能力を疑うよ。

582 ：ただのオタク：04/10/08 18:09:55 ID:???

つーかプロだったら進歩状況　確認、報告　はするだろう普通

583 ：NAME IS NULL：04/10/08 18:44:50 ID:PPCgsGSW

>>582
いや別に>>581の肩を持つわけでもないが結構そーゆーところ多いんじゃないかな。

うちは今ユーザから○投げされている状態。
今回初めて契約したユーザさんなので、過去に実績があるわけでもない。

確かにユーザレビューなるものはあるのだが、こちらがレビュー対象の
ドキュメントに基づきシステムの内容を説明しても全く理解していない
（とゆーか理解しようとしない）。

単に使う側だからシステムの中身には全く興味が無いのでしょう。
そのかわりユーザーマニュアルとか画面デザインとかは逐一ツッコミが
入るけどね。

584 ：574：04/10/08 18:47:11 ID:???

一応、進捗の確認・動作テスト・デバッグなどは納品までに一通りはやったけどね。
それでも、実務に入っての動作をすべて再現できるわけでもないし。
ましてやDBの中身までは見れなかったんだよね。忙しくて。

ウチは零細でシステム組めるの俺だけだし、その俺も独学だからプロから見れば
何もわかっとらんといわれても仕方ない。

言い訳だとは自分でもわかってるが、外注先も正規化ぐらいしろよと。
まぁ単なる愚痴にしか過ぎないけどね。

585 ：NAME IS NULL：04/10/08 18:53:07 ID:???

>>582
進捗の読みはしんちょく

586 ：NAME IS NULL：04/10/08 18:56:22 ID:???

>>585
ﾜﾛﾀ

587 ：NAME IS NULL：04/10/08 18:56:57 ID:???

ひょっとして>550じゃねーだろーなｗ

588 ：574：04/10/08 18:59:15 ID:???

>>587
いや、さすがにあそこまで自分に自信は持ってませんｗ

589 ：550：04/10/08 19:08:56 ID:???

>>583
あるねそういうの
システム会社でもないのにシステム案件に手だして○投げして利益だけもってこうとするとこ
がーーーって感じになる

590 ：NAME IS NULL：04/10/08 19:19:31 ID:???

>>583
そーだよなぁ。
見た目と使い方重視。バックグラウンド処理なんてさっぱり興味なし。

591 ：NAME IS NULL：04/10/08 19:22:44 ID:???

とゆーか>>550さんって何か視点がずれてない？

592 ：550：04/10/08 19:23:49 ID:???

普通の顧客のことを言ってるの？
それならそれで普通だし、納品終わってから文句いいだすのが普通

593 ：NAME IS NULL：04/10/08 19:24:07 ID:???

ずれてる

594 ：NAME IS NULL：04/10/08 23:10:55 ID:???

>590
バックグラウンド処理まで細かく指摘できるような相手なら、自社のシステム部門に
設計/製造させると思われ。

595 ：NAME IS NULL：04/10/09 13:33:20 ID:???

>>594
いやいや自社のシステム部門に設計/製造は出来ないから外注に○投げするわけで。
自社の人間だけで30人月以上のシステムを開発するユーザなんて皆無でしょう。
そんなに大量の人間を常時所属させておく会社なんてトータルリスク管理に
無関心なユーザだね。

596 ：NAME IS NULL：04/10/09 17:22:07 ID:???

( ﾟДﾟ)ﾎﾟｶｰﾝ
なんでそこでリスク管理が出てくるんだ?
「30人月のシステム開発 = 大量の人間を常時所属」と言うのもわけがわからん。

ひょっとしてこの人は、30人月のシステムというのは1人で30ヶ月、2人で15ヶ月
30人でかかれば1ヶ月で完成する物だと本気で思ってるのだろうか?

597 ：NAME IS NULL：04/10/09 18:16:25 ID:???

常時所属させておかない会社ってなによ
>>595さんの関連会社はいつまでたってもノウハウが蓄積されないのか
設計製造できないなら仕事とんなって
外注が直接とったほうが安上がりだし効率がいいんだよ
さっさと消えてくれ中間搾取企業は

598 ：NAME IS NULL：04/10/10 01:15:40 ID:???

ちょっと前に設計と実装を分離できない奴がいたが、
今度は設計と製造を分離できない会社の登場か・・・

599 ：NAME IS NULL：04/10/10 10:53:41 ID:???

>>596
> ひょっとしてこの人は、30人月のシステムというのは1人で30ヶ月、2人で15ヶ月
> 30人でかかれば1ヶ月で完成する物だと本気で思ってるのだろうか?

まさに人月の神話だな。

600 ：NAME IS NULL：04/10/10 11:19:00 ID:???

>>597
何が言いたいのかサッパリわからん…

誰か通訳してくれ

601 ：NAME IS NULL：04/10/10 13:07:59 ID:???

>>600
一言で訳すと、

「丸投げ(・A ・)ｲｸﾅｲ!」

602 ：NAME IS NULL：04/10/11 07:53:23 ID:???

話はいつのまにか、性器化から害虫論へ…

603 ：NAME IS NULL：04/10/12 13:16:04 ID:???

>>602の寒いレスで当スレは凍結へ…

604 ：NAME IS NULL：04/10/12 15:49:49 ID:???

寒いスレッドストッパの居るスレはここでつか？

605 ：NAME IS NULL：04/10/14 17:37:09 ID:???

新規プロジェクトのＥＲ図を見ました。
あるテーブルにcol_1～col_20なんて項目を見つけた
瞬間、やる気なくなりました。

606 ：NAME IS NULL：04/10/14 23:05:32 ID:NUSts3Hd

テーブル設計で
r0001_uriage　（　uriage_no , tokuisaki_code , sales_code , syouhin_code , suryou , tanka )
てな感じで作るか
r0001 ( r0001_01 , r0001_02 , r0001_03 , r0001_04 , r0001_05 , r0001_06 )
これとどっちがいいと思います？
設計というか命名規則ですが

下のやり方だと
１　r0001のr0001_01とr0002_05をjoinとかする事になってSQL見たときどう結合してるのかよくわからん
２　select分書くときもｶﾗﾑ対応の資料みながらでないと作成できない
３　その代わりSQL分はすっきるする？
４　でも全部のクエリが slect r0001.r0001_01, r0002.r0002_04 , r0003_r0003_05 from ......となって
　　ぱっと見ただけでは何してるか理解不能
うーんやっぱり駄目駄目そうですね、すいません

607 ：NAME IS NULL：04/10/14 23:14:23 ID:???

1つも良いこと無さそうに見えるのだが。

608 ：NAME IS NULL：04/10/14 23:27:16 ID:???

ＳＱＬは全然すっきりしねーだろ。
ＪＯＩＮの数が減るとかなら別だが。

609 ：NAME IS NULL：04/10/14 23:32:35 ID:XV6ljV5x

>>606
型のプリフィックスを付けた方が良いと思う。

【例】
　number型 num～　　「num_uriage_no」
　varchar型 var～　　「var_tokuisaki_code」

あとなるべくカラム名を短くする。

tokuisaki_code　→　tokuisaki_cd

610 ：NAME IS NULL：04/10/14 23:33:12 ID:???

ここでえらいひとが出てきて
r0001_売上　（　売上番号 , 得意先コード , 販売コード , 商品コード , 数量 , 単価 )
にしたら分かりやすいだろ。と得意げに言い出す。。。
確かに定義は可能だが、どっかで日本語がらみの不具合出たらあんた責任取るのかと問いたい、問い詰めたい。

611 ：NAME IS NULL：04/10/14 23:50:56 ID:???

某大手企業の巨大システムはテーブル名・カラム名共に日本語でした。
「なんで日本語なん？」って聞いたら「わかりやすいやん。」だって。

612 ：NAME IS NULL：04/10/15 00:20:47 ID:???

連番カラムは、仮テーブルでいくつかやったことがある。
横方向に配列一撃処理したいとき便利

日付何時から出勤職員ID
10/15 10:00 6
10/15 11:00 9
10/15 11:00 3
10/15 12:00 5
10/15 12:00 7

な感じでたまってるデータを

10:00～ 11:00～ 12:00～ 13:00～

10/15 山田　　佐藤　　田中　　太田
　　　　鈴木　　渡辺　　中村

10/16 。。。。。。。

な感じで表示したい、とか

613 ：NAME IS NULL：04/10/15 02:33:29 ID:Q1bgJl9b

日付分のサイズを節約したいのですが、int型にしてUNIXタイムスタンプを入れておく
というのは一般的なやり方なのでしょうか？

どうせ、2038年には自分は現場にいないハズなので指摘されなきゃ大丈夫かと思うのですが・・・

614 ：NAME IS NULL：04/10/15 02:45:18 ID:???

実装によるけど日付型ってdoubleとかlongだから、
インデックス含めたメタデータの分も考えると節約になるとは思えない。

それに扱う全データに対する日付分の割合はどれくらいなの？

615 ：NAME IS NULL：04/10/15 02:49:43 ID:???

>>609
カラム名は8文字におさえろよ。

616 ：NAME IS NULL：04/10/15 03:09:26 ID:???

>>615
なんかいいことあるん？

617 ：NAME IS NULL：04/10/15 03:15:54 ID:???

メモリの節約。

618 ：NAME IS NULL：04/10/15 03:16:16 ID:???

あと、COBOLに移植するときに便利。

619 ：NAME IS NULL：04/10/15 03:42:47 ID:???

カラム名がどの程度メモリ喰うっていうのさ
つーか、COBOLに移植って・・・何w

620 ：NAME IS NULL：04/10/15 03:46:54 ID:???

日付は基本的に文字列格納
そのほうが、別DBへの移植も容易にできる、メンテも楽、西暦問題とも無縁

621 ：NAME IS NULL：04/10/15 04:57:38 ID:???

固定長レコードのファイルベースにするときにも楽だね。
っつうか、変にリレーションとか使ったら、ファイルに移植できんやろうが。

622 ：NAME IS NULL：04/10/15 08:16:31 ID:???

あ～あのプロジェクトの方達か

623 ：NAME IS NULL：04/10/15 08:27:47 ID:???

>>621
リレーションは論理概念。
物理的にどう格納するかはあなたの自由。

624 ：NAME IS NULL：04/10/15 09:06:08 ID:???

最近のﾚｽを見てるとそういう切り分けができなﾔｼが増えてるようだぬ

625 ：NAME IS NULL：04/10/15 09:27:05 ID:???

論理畑と技術畑じゃ言葉のさす意味も違うのだろうよ

626 ：NAME IS NULL：04/10/15 09:58:41 ID:???

>>609
最近ではハンガリアン記法は推奨しないというのが大勢。
カラムの型が変わった時の手間を考えてもやるべきじゃない。

>>611
当然DBMSとその周辺で日本語カラム名での動作確認が取れている上での
事だろうから無問題。
個人的にはタイプが面倒になるから嫌。

>>613
日付は日付型で扱うべき。
大抵のDBMSは日付型用に豊富な関数群を用意している。
(単純な日付計算から月初や週初めを求める関数まで)
それらを全部捨ててまで日付を数値型や文字列型で格納するメリットが
あるとは到底思えない。

627 ：NAME IS NULL：04/10/15 11:04:05 ID:???

> >>609
> 最近ではハンガリアン記法は推奨しないというのが大勢。
> カラムの型が変わった時の手間を考えてもやるべきじゃない。

型が変わったときのプログラム修正ミスを防げるので意味有ると思う、
全部手間掛けて修正するのは大変だけど逆にもう一度チェックする機会になる。

> >>611
> 当然DBMSとその周辺で日本語カラム名での動作確認が取れている上での
> 事だろうから無問題。
> 個人的にはタイプが面倒になるから嫌。
おれも日本語名は有効だと思う、
タイプミスや項目名を間違える様なアホなプログラマを沢山使ってると
日本語カラム名はミスが出にくいし発見するのも容易、

上記のハンガリアンもアホプログラマのミスを見つけるのが容易になる。

一度やってみれば分かる。

628 ：NAME IS NULL：04/10/15 11:13:23 ID:???

日本語はミスが出にくいかもしれんが、プログラム打ってる流れでは打ちにくく
時間をロスするし、マルチOS環境などを考えると日本語はあまりソース中に
入れるべきじゃない、コメントは化けても問題ないから日本語でいい

フィールドの形を表記に含めるのではなく、３種類程度に限定する
移植するさいに支障のないものにするほうがいい
型が限定されていればフィールド名のニュアンスでたいていの場合は
型を特定できる

629 ：NAME IS NULL：04/10/15 11:31:33 ID:???

ローマ字は表記法さえ決めてしまえば混乱することはないが
日本語は送りがながあるからな。
売上なのか売り上げなのか売上げなのか…

> タイプミスや項目名を間違える様なアホなプログラマを沢山使ってると
> 日本語カラム名はミスが出にくいし発見するのも容易、

これは意味が分からない…
ミスが出にくいも何も、項目名が間違っていたらSQLも通らないだろ?

630 ：NAME IS NULL：04/10/15 11:37:25 ID:???

>>627は設計者にしては、ちょっとレベルが低いな

631 ：NAME IS NULL：04/10/15 12:17:25 ID:???

> 日本語は送りがながあるからな。
> 売上なのか売り上げなのか売上げなのか…

あと、「雰囲気」というカラム名がふいんきで変換できないとか
「売り上げデ－タ」なんつーのも曲者だ

632 ：NAME IS NULL：04/10/15 12:24:50 ID:???

>>631
> あと、「雰囲気」というカラム名が

中身がメチャメチャ気になる…(´Д`;)

633 ：NAME IS NULL：04/10/15 12:35:04 ID:???

コボラー必死だな！！

634 ：NAME IS NULL：04/10/15 13:06:39 ID:???

コボラーって>>627のこと？

635 ：NAME IS NULL：04/10/15 14:50:13 ID:???

何を言うか。コボラーではなくコボレストだ。
最上級なのだから、敬え。

636 ：NAME IS NULL：04/10/15 14:54:04 ID:???

なあ？
結局、正規化はすべきだよな？

637 ：NAME IS NULL：04/10/15 14:55:29 ID:???

>>627は能無し。

638 ：NAME IS NULL：04/10/15 15:05:18 ID:???

>日本語はミスが出にくいかもしれんが、プログラム打ってる流れでは打ちにくく
>時間をロスするし、マルチOS環境などを考えると日本語はあまりソース中に
>入れるべきじゃない、コメントは化けても問題ないから日本語でいい
日本語使用に問題有るOSならやる必要なないけど
問題ないなら使えばメリットが有るって話だ。

それにソース打つ時間なんてプロジェクト全体の中ではほんの僅かだぞ
全体の効率で考えれば後の保守性やミスが起こらない方法をとるべきだ

打つ時間なんて気にしてるのは単価の安いプログラマの戯言だろ。

639 ：NAME IS NULL：04/10/15 15:23:04 ID:???

メリットがあるなら使えばいいしデメリットがあるなら使わなければいい。

640 ：NAME IS NULL：04/10/15 15:35:27 ID:???

ならばやはり正規化すべき。

641 ：NAME IS NULL：04/10/15 15:46:03 ID:???

>>638
> 全体の効率で考えれば後の保守性やミスが起こらない方法をとるべきだ

そりゃ至極もっともな話だが、日本語のカラム名を使うと保守性が上がって
ミスも起こらないとは誰も思ってないから噛みつかれるんだよ。

日本語カラム名使うメリットがあるとすれば、エンドユーザーがExcelあたりを
介して直接DBMSからデータを引っ張るような環境だけだな。

> 打つ時間なんて気にしてるのは単価の安いプログラマの戯言だろ。

余計な煽り文句を入れるな

642 ：NAME IS NULL：04/10/15 16:03:28 ID:???

>そりゃ至極もっともな話だが、日本語のカラム名を使うと保守性が上がって
>ミスも起こらないとは誰も思ってないから噛みつかれるんだよ。

じゃあ逆に聞くが日本語使用に問題ない環境で日本語のカラム名をつかわないことのメリットってなんだ？

それがパンチ時間だけなんだろ？

日本語にすれば項目名等短くなる事多いし項目名をへんな省略しなくて住む場合も多い、
そうすると見通よくなってミスが減る事もある
馬鹿なプログラマを沢山使ってれば実感出来るとおもうけどな。

実際には日本語名はお前みたいな香具師に意味なく敬遠されるので使える場合が少ないのは事実だけどね。

643 ：NAME IS NULL：04/10/15 16:37:17 ID:???

日本語カラム名を使うデメリット
・SQLが打ちづらい
・表記法が統一しづらい
・拡張性に乏しくなる(問題がないのはあくまで現在の運用及び開発環境に限られる)
・システム拡張の際、開発を海外の外注先に投げるという選択が取れなくなる
・(ほとんどのDBMSで)パフォーマンスが悪くなる

644 ：NAME IS NULL：04/10/15 16:39:37 ID:???

パフォーマンスが悪くなるってのは初めて聞いた。
計測データってあるの？
Oracleとかはベンチマーク公開禁止だっけか。

645 ：NAME IS NULL：04/10/15 16:58:53 ID:???

>>644
文字コードの変換が入るからでは?

646 ：NAME IS NULL：04/10/15 18:18:22 ID:???

>・SQLが打ちづらい
これはコーディング時の一時的な物だろ
その後のメリットに相殺される

>・表記法が統一しづらい
そんな事は無い、きちんと規則を決めればアルファベットより簡単
だいたい日本語の項目名なんて現実社会に置いて既に有る程度標準化されている。

>・拡張性に乏しくなる(問題がないのはあくまで現在の運用及び開発環境に限られる)
>・システム拡張の際、開発を海外の外注先に投げるという選択が取れなくなる
前提として日本語が使える環境での日本語名だから、この項目自体意味無し！

>・(ほとんどのDBMSで)パフォーマンスが悪くなる
データは？
内部的には漢字も半角も同じ扱いだろ？

文字コードの変換が入るのはフィールドへの代入とか、表示とかじゃないか？

647 ：NAME IS NULL：04/10/15 18:32:07 ID:???

>・SQLが打ちづらい
これはコーディング時の一時的な物だろ
その後のメリットに相殺される
ほんとつっこみ所満載なやつだな
＞＞そんな事は無い、きちんと規則を決めればアルファベットより簡単
＞＞だいたい日本語の項目名なんて現実社会に置いて既に有る程度標準化されている。
いつ誰が標準化したんだ、もまえか？
俺は見たこともないな、チンピラグラマが意味もわからず日本語使ってるのは見たことあるが

＞＞前提として日本語が使える環境での日本語名だから、この項目自体意味無し！
linuxでも日本語が使える環境なわけだが、ぜんぜんコード体系が違うぞ
もっと勉強しれ、どうせWindowsしかさわったことがないへっぽこだろうが

＞＞データは？
＞＞内部的には漢字も半角も同じ扱いだろ？
＞＞文字コードの変換が入るのはフィールドへの代入とか、表示とかじゃないか？
文字コード変換はなODBCドライバで発生するんだよ
漢字があろうがなかろうが変換は行われる
文字コードが最初から一致してても行われる
なにが違うかっていったら実際に変換した文字数分の処理時間なんだよ
わかったか

648 ：NAME IS NULL：04/10/15 19:33:48 ID:???

647 は 646 以上のアホ

649 ：NAME IS NULL：04/10/15 20:40:03 ID:???

>643

> ・表記法が統一しづらい

英語でも単語の省略の仕方がまちまちだったりで統一し易い訳では
ありません。省略しないと長くなってしまいますし。

> ・拡張性に乏しくなる(問題がないのはあくまで現在の運用及び開発環境に限られる)

将来的に海外で使う事が想定される様なシステムであればそういう
配慮も必要でしょうが、そんな事は考えていないシステムもたくさ
んあります。海外展開を想定している場合は最初からそういう要求
があるでしょう。

> ・(ほとんどのDBMSで)パフォーマンスが悪くなる

ここで問題になっているのはカラム名やテーブル名ですからコード
変換が発生するとしてもSQL文をパースする時だけです。扱うレコー
ド数には依存しませんからパフォーマンスに与える影響は小さいと
判断出来ます。またSQL文の構文解析し実行計画を立てる事に比べ
れば文字コード変換は負荷の小さい処理ですし、その点でもあまり
大きな影響があるとは思えません。

具体的にどの程度影響があるのかというデータはありますか。

650 ：NAME IS NULL：04/10/15 23:48:15 ID:???

別にパフォーマンスがボトルネックになるとは誰も書いてないと思うのだが
そこしかつっこみどころがないからつっこんでるのか？
> ・(ほとんどのDBMSで)パフォーマンスが悪くなる
この言葉自体になんら間違いはないだろう
空気嫁

651 ：NAME IS NULL：04/10/15 23:49:21 ID:???

> ・(ほとんどのDBMSで)パフォーマンスが悪くなる
基本的に悪くなりません。某DBベンダで働いている私が言うのだから間違いありません。
まだベンチマークしてませんが、そういうアーキテクチャです。
もっとも他社の製品については何とも言えませんが、今時根本的な処理ならどこでもほぼ同じレベルです。

ただし、日本語名を使った場合、ミドルウェアや開発言語、ODBCドライバなどで
特定の文字だけ問題が起きるといった可能性を否定できないので絶対に使わないでくれとお客さんには言ってます。

652 ：NAME IS NULL：04/10/15 23:59:54 ID:???

>>646 >>649がいってるのは
Windowsでしか使わないのだから、Windowsに依存した作り方でいいじゃないか
Oracleでしか使わないのだから、Oracleに依存した作り方でいいじゃないか
と同レベル

誰がそれを保障できるの？
アルファベットだろうと日本語だろうと保守性は、それことパフォーマンスの差異
位に微々たるものだろう
だったら将来SQL Serverでの運用とかPostgreSQLでの運用とかも考慮した
やりかたを取るのが保守性が高い作り方と言えるだろう

言語的な話で環境依存ってのはありえるが、DBみたいに基盤になるものは
環境依存下に置くのは、あまり良い選択じゃない

そういうのを作りっぱなしと言う

653 ：NAME IS NULL：04/10/16 00:49:22 ID:???

ユーザーの要求なんてころころ変わるんだし、
将来どうなるかわからんだろ？
だったらやはり極力変化に強い設計にしておくのが無難。

654 ：NAME IS NULL：04/10/16 16:31:14 ID:???

つまるところお前らが言いたいことは↓だろ？

ロ　ー　マ　字　表　記　最　高　

655 ：NAME IS NULL：04/10/16 19:02:44 ID:???

ﾁｶﾞｳﾝﾃﾞｽﾖｰ

656 ：NAME IS NULL：04/10/16 19:55:01 ID:???

ヘボン式マンセー

657 ：NAME IS NULL：04/10/18 08:52:29 ID:PhkblcBS

SQLの項目名が日本語の何がメリットがあるのだろう?

プログラム内部の変数に落とすにしても、オブジェクトにマッピングするにしても
最終的にはアルファベットになるじゃないか。
プログラム内部で改めてアルファベットの項目名を定義し直すなんて馬鹿馬鹿しいし
テーブルの項目名と異なる変数名なんて分かりづらい事この上ない。
ミスが出にくくなるなんて、寝言は寝てから言って欲しい。

658 ：NAME IS NULL：04/10/18 09:30:29 ID:???

VBなら日本語使えるとか言い出しそうだな

659 ：NAME IS NULL：04/10/18 09:38:53 ID:???

やっぱ基礎のないやつはなにやってもだめだな

660 ：NAME IS NULL：04/10/18 10:07:27 ID:???

>654
違うだろ。
項目名はアルファベット+連番。
別紙の項目名対応表と関連付ける。
古来より行われてきたこの手法こそ最強。

661 ：NAME IS NULL：04/10/18 12:33:49 ID:???

例えば、取引先ID　をプログラム内で表記する場合、

【例】
ローマ字表記：torihikisaki_ID
日本語字表記：取引先ID

となる。

日本語表記を示すメリットは、
・プログラムのコードを追う場合は、日本語字表記の方が解り易い。
・論理設計から物理設計に落とす時、そのままの表記で列名を落とせる。

かな？

日本も英語圏の言語だったら、こんな問題に陥らなくて良かったのにな・・・・

662 ：NAME IS NULL：04/10/18 15:59:47 ID:???

torihikisaki shift + _ shift + I + shift + D

全角 torihikisaki
while(変換成功){
変換やり直し
}
shift + I shift + D
全角

わかりやすいってなにが？

663 ：NAME IS NULL：04/10/18 16:14:46 ID:???

>>662
馬鹿かお前は

664 ：NAME IS NULL：04/10/18 16:27:42 ID:???

だから英語が必須なんだろうに
× torihikisaki_ID
○ client_ID
設計の段階で日本語使う時点で間違い

665 ：NAME IS NULL：04/10/18 16:43:11 ID:???

>>664
項目名にマルチバイト文字を使うのは論外として
いちいち辞書引かないと分からない単語を使うのは非生産的だと思われ

副資材引き当て区分

こんなのどうすりゃいいのよ?

666 ：NAME IS NULL：04/10/18 16:54:35 ID:???

資材はmaterial

自分なら submat_flg
といった短い名前にする
flgという修飾子自体も他の項目名と関連性をもたせておけば意味も表現できる

material とか mat 自体は他のテーブル名や項目でたびたび出てくるので
辞書いっかいひけばすべてわかる

副資材引き当て区分
なんてのはたとえ日本語で表記されててもはじめてみる人には意味不明なので同じ

667 ：NAME IS NULL：04/10/18 17:04:25 ID:???

副資材引き当て区分　と　その用途については
設計の段階であくまで備考欄に記入すべきものだろう

668 ：NAME IS NULL：04/10/18 17:11:37 ID:???

>>667
結局 660のような項目対応表は必要ってこと？

669 ：NAME IS NULL：04/10/18 17:12:32 ID:???

>>666
なんか矛盾してる気がするぞ…
言ってることが日本語カラム名派と同じじゃないのか?

670 ：NAME IS NULL：04/10/18 17:14:17 ID:???

対応票ではないよ
テーブル定義書がすでに一定の命名規約によって作成されて英語項目名
をメインに置くということ
ＥＲ図もすべて英語項目名で作成する
そうすれば仕様を理解するころには対応票は頭の中に出来上がっている

671 ：NAME IS NULL：04/10/18 17:16:46 ID:???

全角英字使ってる人が英語項目名を支持しても、どうにも信憑性に欠ける気がする…

672 ：NAME IS NULL：04/10/18 17:21:35 ID:???

よく考えたら頭の中にあるのは対応票でなないな
英語項目名ですでに意味に直結してるといった感じかな

673 ：NAME IS NULL：04/10/18 20:24:27 ID:???

>666

突っ込みどころ満載ですね。とりあえず「引き当て」がどこへ行っ
たのですか。

資材区分と素材区分があったらどうします？。materialに対応する
日本語だと後者の方が最初に思い付きますが。

matで始まる単語は他にもいくらでもありますしmaterialの略し方
にしても>666の様に単語の頭を使う流儀もあればmtrlの様に子音を
抜き出す流儀がありますから表記の揺れに繋がります。

日本語に対応する英語を考えるというのは思っているほど簡単な事
ではないし馬鹿にならない労力がかかるというのは経験した事のあ
る人間なら分りそうなものですけどね。

そういえば「区分」と「フラグ」を区別して使い分けているところ
もありましたね。こういう場合は>666ならどうしますか。

674 ：NAME IS NULL：04/10/18 20:33:50 ID:qDNRF/Gp

>652

SQLに関してはDBMSに依存する部分はかなりありますからね。
OracleとMS SQL serverの両方で使えるSQL文というのはかなり厳し
い制約になります。

例えば日付処理関数なんかは処理系によって違っていますが、どう
するのですか。日付型を使わずに日付は文字列で扱う事にしてクラ
イアント側で自前の日付処理ライブラリを用意するのですか。

別の例で言えば、ある条件にマッチする検索結果の内201番目から
300番目の行を取り出す場合移植性の高いSQLを書くにはどんな方法
が考えられますか。

SQLを使っている場合、他の処理系への移植性はよっぽどの事がな
い限り考えても無意味でしょう。

675 ：NAME IS NULL：04/10/18 20:58:09 ID:???

>>674
>ある条件にマッチする検索結果の内201番目から
300番目の行を取り出す場合移植性の高いSQLを書くにはどんな方法
が考えられますか。

SQL鯖の場合だとこんな感じであってます？

SELECT TOP 100 * FROM Table1 A
WHERE NOT EXISTS
(SELECT * FROM (SELECT TOP 200 * FROM Table1) AS B
WHERE A.Field1 = B.Field1)
ORDER BY A.Field1

ｵﾗｸﾙでは通らないのかな？

676 ：NAME IS NULL：04/10/18 21:31:47 ID:???

>>673
この場合matでもmtlでも実は問題ないんですよ。
ようするに識別、連想の容易なものであればいいんです。
その辺の命名規約は固定化するか仕様書にもりこむ必要がありますがね
仕様理解の段階で日本語項目名で論理的に構成していくと
後々対応票が必要になってくるんですよ
なので仕様理解の段階ですでにある種の記号と目的の関連付けをしてしまう
ということです。
そうすることで
日本語項目名ー＞動作目的　と同じように　英語項目名ー＞動作目的
という自然の流れが作れます。
そんなに難しいことではありませんよ、日本語項目名でやったとしても結果は同じです。

>>674
私の場合は、そういったことが現実問題として多々ありましたからね
以下のことに注意しています。
共通して利用できるデータ型しか使わない。
日付は文字列として格納する
固有の関数などは使わず、自前の共通関数を用意する

スピードの制約とかシビアな場合は、ストアドに依存するのはしかたないですが、
たいていの場合は無視できるレベルです。

677 ：NAME IS NULL：04/10/18 22:14:55 ID:???

>676

前半部分。

それは出てくる用語数が少なければ問題にはならないでしょうけど
数が多いと馬鹿にならないと思いますよ。まぁ、この辺が個人の感
覚ですが。途中で仕様変更やなんかで新しい用語が出てきた場合に
既存の命名規約にハマらなかったりする場合もよくあります。

日本語に反対する理由として拡張性を挙げられていますが、>676
の方法でも機能拡張を求められた時点に命名規約が破綻する可能性
は低くはありません。

後半部分。

日付型を使わないというのはこれはこれでよく議論になりますねぇ。
大抵は使うべきという結論になるものと認識しています。

例えば古いPostgreSQLだとunionが使えなかったり、MySQLではサブ
クエリーが使えなかったりとかあります。日本語を使えない環境を
考慮するというのならそこまで考慮する必要があるでしょうが、あ
まり現実的な話とは思えません。

ちなみに>674の2番目の例に対する解はありますか。>675の例はSQL
サーバーに依存していますし、PostgreSQLでは確かlimitとoffsetだっ
たか固有の構文があったはずです。

Oracleであればrownumを使う事になりますが古いOracleだとサブク
エリーにorder byを使えないのでこの方法が使えません。

一般的は解としては、>675の例を使うとField1が自分より少ないレ
コードの件数を数えて、それが200から301の間のものを取得すると
いう方法が考えられますが、SQLの例は面倒なのでパスします。常
識的には素直に処理系に依存した方法を使うでしょう。

678 ：NAME IS NULL：04/10/18 22:29:24 ID:???

> 一般的は解としては、>675の例を使うとField1が自分より少ないレ
> コードの件数を数えて、それが200から301の間のものを取得すると
> いう方法が考えられますが、

突っ込まれる前に書いておきますが、Field1の値に重複がある場合
にはこの方法は使えません。そういう場合で移植性が必要なら300
件fetchして200件分捨てる位しか思いつきません。

処理系に用意されている方法よりは遅くなるでしょうし、件数が増
えれば増える程問題は大きくなります。そしてこういう要求という
のは件数が多いからこそ出てくる要求です。>676でも他の人でも移
植性のある解を持っているのであれば興味はあります。

679 ：NAME IS NULL：04/10/19 01:41:19 ID:???

たしかに命名規約は完璧には出来ません。
それは日本語項目名を使った場合も同じです。
同じ結果ならより有利な方を選択するものです。

あきらかに依存度の高い
EXISTS
TOP
*=
なんかは使いません
代用できるものは
IN
JOIN
などです。
ＳＱＬ構文が長くなりますが、移植性には勝てません。
ロジックで工夫する場合もあります。
たすかにパフォーマンスは落ちます。
それは前文でも書いた通り、必要ない場合が多いです。

680 ：NAME IS NULL：04/10/19 03:11:58 ID:???

EXISTSの使いようによってはパフォーマンスに結構差が出るから安易に避けちゃダメだ

681 ：NAME IS NULL：04/10/19 04:29:58 ID:???

EXISTSってSQL99標準じゃん。

682 ：NAME IS NULL：04/10/19 05:55:23 ID:???

英語で書け派の人は、領収書とレシートを扱うシステムではどうするつもりだろう？
日本語→英語→カタカナが別の言葉になることは結構あるのだけど。

683 ：NAME IS NULL：04/10/19 06:37:49 ID:???

ODBCで繋いで SELECT * FROM foo, bar; してから手元で演算すればDBMSに
依存せず操作できます。マジお勧め。

684 ：NAME IS NULL：04/10/19 07:16:13 ID:???

項目名が変化する領収書システムってのはいったい？

685 ：NAME IS NULL：04/10/19 07:18:28 ID:???

>>684
いや、だから、領収書を英語にすると、receiptだろ？
じゃあ、レシートはどうするんだ？と。

686 ：NAME IS NULL：04/10/19 07:22:54 ID:???

receiptとpaperでもいい
識別できればなんでもいい

687 ：NAME IS NULL：04/10/19 07:31:25 ID:???

ローマ字日本語と英語ごたまぜですよ

688 ：NAME IS NULL：04/10/19 08:25:17 ID:???

>>686

> 識別できればなんでもいい

それなら>660が最強ですね。

>679

DBMSによってはSQL文の長さに制限がある場合もありますがそっち
の配慮は大丈夫ですか。

例えば現在時刻を取得するのに移植性の高い方法はどんなのがあり
ますか。DBMS依存の方法は使えないとなるとクライアント側で取得
する事になりますが、そっちはそっちで環境に依存します。また複
数のクライアントで時刻を同期する配慮も必要になります。

>683はネタで書いたのでしょうが実際、本気で移植性を追求するな
らそうなりますよ。

本当に移植性が必要ですか。

移植性を追求するならDBMSの機能はほとんど使えなくなりますし、
それならそもそもRDBMSを使う必要が本当にあるのかという話にも
なります。それでもパフォーマンスを犠牲にして移植性を追求する
システムをRDBMSで実現するメリットが顧客にあるのですか。

689 ：NAME IS NULL：04/10/19 08:35:36 ID:???

今までDBMSの置き換えなんて聞いたことがない。
あるとしてもそんなのはDBMSの選定ミスでしょ。

移植性を考えなければならないシステムなんて、最初から移植することが
決まってるはずじゃん。そうでないシステムと同列に語るのはおかしい。

あと、日本語の項目名を使っても結局はプログラム内でアルファベットの
項目名に置き換える必要があるって話はどこ行ったの?

690 ：NAME IS NULL：04/10/19 10:23:48 ID:???

＞今までDBMSの置き換えなんて聞いたことがない。
＞あるとしてもそんなのはDBMSの選定ミスでしょ。
おれもこれに同意

結局日本語NG廚や正規化必死廚や移植性重要廚は実務経験が少ない仮想SEなんじゃない？
実務経験が有れば一旦決めたシステムが移植される確率なんて非常に低い事は
わかってるし、
何年かたって他のシステム屋が更新するかもしれないけどそんな事は関係ない
現実的には今後の為の標準化に金を使うなんてことは無駄だしクライアントには歓迎されないぞ

それに移植が必要な場合はアクセス用のモジュールに包括させて固有部分が外に出ない様にするだろう

移植性を本気で考える奴がこの程度の工夫をしないはずないんで
移植性の為に日本語NGなんていってんのはそもそもつじつまが合わないだろ

691 ：NAME IS NULL：04/10/19 10:30:17 ID:???

まぁ、実務経験があるＳＥがいいＳＥとは限らないけどね。

692 ：NAME IS NULL：04/10/19 11:54:59 ID:???

複数のDBMSへの対応をうたってるCASEなんかだとあっさりDBMSの切り替えできたりするな。
どっちにしろテストは必要だからそれだけ金出して移行するメリットがあるかどうか疑問だけど。

693 ：NAME IS NULL：04/10/19 12:25:40 ID:???

しかしOracleでさえ日本語カラム名の動作は保証しないし、PostgreSQLやMySQLでも
問題が出るから使用は推奨されていないはず。Firebirdでは使用すら出来ない。

一体彼らは普段どのDBMSで開発しているんだろう? SQL鯖?

694 ：NAME IS NULL：04/10/19 12:47:34 ID:???

Windows + SQLSever というベタベタな素人構成しかさわったことないんだろうな
日本語とか言ってる時点で、ろくにプログラムも組めない、素人SEなんだろう
移植性にでくわす場面なんていくらでもある
別の場所で既存のコンピュータ構成を利用して同じシステムと使いたい
別の会社の作成したシステムと連携をはかりたい
別の機器のシステムと連携をはかりたい
こんなユーザの要求なんて日常的にあると思うが、それは切り分けて
ぼうだいな金かけてるのかねこういう人たちは
モジュールに包括なんてのは先でも書いてると思うが、ただのしったかか

695 ：NAME IS NULL：04/10/19 13:08:06 ID:???

>>694
言わんとしていることには同意だけど。

> 別の場所で既存のコンピュータ構成を利用して同じシステムと使いたい
> 別の会社の作成したシステムと連携をはかりたい
> 別の機器のシステムと連携をはかりたい

いずれの場合もDBMSを操作するミドルウェアは同じ物だろうし、特に日本語
カラム名を使うことで問題が発生するとも思えない。
こじつけは良くない。

素人SEだの知ったかだのという煽り文句付きでないと技術的な議論が出来ない
というのが果たしてプロなのかどうか…。

696 ：NAME IS NULL：04/10/19 13:10:53 ID:???

最近はよくあるんじゃない？
会社統合に伴うシステム統合だったり、
ＤＷＨを構築して連携したり。

最近、データモデリングや標準化の書籍等が
多く出回ってきたのも、今までそのような事が
がないがしろにされてきた事の弊害が多く出て
きているからだと俺は思ってるんだけど。

697 ：NAME IS NULL：04/10/19 14:03:53 ID:???

>>693
>しかしOracleでさえ日本語カラム名の動作は保証しないし
まだそうなの？

698 ：NAME IS NULL：04/10/19 14:15:55 ID:???

> 別の場所で既存のコンピュータ構成を利用して同じシステムと使いたい
> 別の会社の作成したシステムと連携をはかりたい
> 別の機器のシステムと連携をはかりたい
これは日本語カラムではなく移植性のことに対するレス
その前に日本語カラムだと移植性が落ちるという前提があるけど

移植性を考慮して設計されていると、この辺の作業ってのは
フォーマット変換するにしても楽だし、うまくいけば抽出するだけですんだりする
こういったことが発生するたびに開発費と時間をついやさずにすむんだよ
> 別の会社の作成したシステムと連携をはかりたい
得にこれについては、移植性まったく無視して設計されたシステムだと
こっちまで迷惑こうむるからね

699 ：NAME IS NULL：04/10/19 14:20:25 ID:???

>>696

2002年3月時点の記事だが・・・。

http://www.oracle.co.jp/2shin/2002/ora54/15_16.html

ここにカラム名じゃなくてテーブル名だが記述してある。
やっぱ保証はしていないみたい。

700 ：６９９：04/10/19 14:21:20 ID:???

間違えた＞＞６９６じゃなくて＞＞６９７

701 ：697：04/10/19 14:33:27 ID:???

>>699
ありがとう。
回答もOracle7でnif辺りでやっていた頃と全く変わっていなくてびっくり。

702 ：NAME IS NULL：04/10/19 16:42:57 ID:???

Hibernate使えば移植性は問題なし。
SQLをプログラムに書くのが悪い。

703 ：NAME IS NULL：04/10/19 17:17:00 ID:???

また妙なのが沸いたな…

O/Rマッピングで泣きを見てる連中があまりに多ので信用ならん。
第一、Hibernateで縛られる方が特定DBMS依存より余程危険な気がするぞ。

704 ：NAME IS NULL：04/10/19 17:34:44 ID:???

アプリケーションがちゃんと組みきれれば、その後は楽だと思うけど。
対応しきらなければ素のSQL書くしくみもある/できるわけだし。

705 ：NAME IS NULL：04/10/19 19:55:13 ID:???

>694

一般的な開発に関する話としては同意ですが、SQLについては移植
性というのは幻想にすぎないというのが実感ですね。Cの移植性に
ついても大外幻想だと思っていますが。

やるとしたら使う機能を極端に制限するかSQL自体を隠蔽してDBに
対する操作を抽象化するようなインターフェースを使うか。

最初から対象プラットフォームが決まっていてその範囲内で仕様を
決めていくというのなら容易ではあるでしょうが、一般的な移植性
を考慮するのであれば使う機能を相当限定するか>702の奴みたいに
徹底的に作るかしかないでしょう。それでも素のSQLを記述する仕
組みを残さざるを得ない訳ですから限界はあります。

> 別の機器のシステムと連携をはかりたい
> 別の会社の作成したシステムと連携をはかりたい

これはインターフェースに関する問題であってプロムラムの移植性
とは独立した問題です。

706 ：NAME IS NULL：04/10/19 19:58:48 ID:???

いやー、あなたたち日本語使うかどうかでここまで白熱できるなんてシアワセですわね。
ふつー、そんなことレビューで議題にあげてたらぶっとばされますわよ。

707 ：NAME IS NULL：04/10/19 20:05:30 ID:???

そこまで日本語にこだわるやつもめずらしいからね

708 ：NAME IS NULL：04/10/19 20:27:00 ID:???

つーか、会社でこんな話マジでしてたらぶっとばされるからここでしてるんだろうが！

709 ：NAME IS NULL：04/10/19 20:29:56 ID:???

　　　　　　　　　　　　　　￣￣￣￣-----________ ＼　|　/　　--￣
　　　　　　---------------------------------　　。 >>708

　　　　　　　　　　　_______-----------￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　∧ ∧　　　　／　/　|　　＼　　　イ
　　　　　　　　　　　　ハイハイ　　　（　　　）　　／　 ./　 |　　　＼　／
　　　　　　　　　　　　　　　　　＿／　　　　）／　　/　　|　　　　／|
　　　　　　　　　　　　　　　　ぅ／ /　　　//　　　　/　　 |　　　　／ ,|
　　　　　　　　　　　　　　　　ノ　 ,/　　　/'　　　　/　　　 |│　／|
　＿＿＿＿＿　　　　　 ,.／／/　　　 |　　　　 /　　　.─┼─　|
（＿＿＿＿＿二二二二)　ﾉ（　（.　　|　　　　/　┼┐─┼─
　　　　　　　　　　　　　 ^^^'　　ヽ, |　　|　　　/.　 ││　 .│ │

710 ：708：04/10/19 20:46:47 ID:???

本当はこんな話を結構してますw

711 ：ぜんぜん関係ないところに：04/10/19 20:56:55 ID:???

「悔しがってまたコピペする」

712 ：NAME IS NULL：04/10/19 21:03:13 ID:???

>>706
途中からちゃんと「SQLの移植性」というより一般的な話になってるんだけどね。

713 ：NAME IS NULL：04/10/19 21:35:26 ID:???

そりゃ盛り上がるよ。
前提条件無しだから結論は絶対出ない訳だし。

714 ：NAME IS NULL：04/10/19 21:48:35 ID:???

ＤＢマガジンはＪＡＶＡの話題が多すぎないか？

715 ：714：04/10/19 21:49:28 ID:???

ありゃ、間違った。書籍のスレッドに投稿するつもりだったんだ。
スミマセン。

716 ：NAME IS NULL：04/10/19 22:56:05 ID:???

>>702
んでそいつはJava以外のプロジェクトでも一般的に使っているの？

717 ：NAME IS NULL：04/10/19 23:00:58 ID:oGonGEC6

正規形を崩して、あるSQL文のパフォーマンスが上がったと喜んでる奴は
その他のVIEWのパフォーマンスや、そもそもVIEWを作れなくなる可能性
についてどう考えているんだ？

718 ：NAME IS NULL：04/10/19 23:09:40 ID:???

そのSQLのパフォーマンスが低くて納品できない、運用できない、ということを考えれば、問題なし。

719 ：NAME IS NULL：04/10/19 23:30:02 ID:???

ぜんぜん運用に影響ない部分のパフォーマンス改善するために正規化崩して悦に入るのはアホだけどな。

720 ：NAME IS NULL：04/10/20 00:03:03 ID:???

とりあえず正規化を崩した事が理由でVIEWを作れなくなる例は
思い付きませんが…

>717,719

それは別に非正規化以外の理由でそうなっても同じ事ですね。

721 ：NAME IS NULL：04/10/20 00:41:48 ID:???

言うまでもないが正規化は手段であって目的じゃないし

722 ：NAME IS NULL：04/10/20 02:12:49 ID:???

日本語カラムとか言うやつが正規化を語るのはナンセンス

723 ：NAME IS NULL：04/10/20 02:17:35 ID:???

UTF-8で日本語カラムでええやん。

724 ：NAME IS NULL：04/10/20 03:28:13 ID:???

UTF-8とMS932の相性が悪いのを知らんのか

725 ：NAME IS NULL：04/10/20 08:59:19 ID:???

もう日本語カラムはええって

726 ：NAME IS NULL：04/10/20 09:02:38 ID:???

「ひまわり」から使える日本語SQL・・・とかあったらうれしい。
ネタとして。

727 ：NAME IS NULL：04/10/20 09:42:52 ID:???

えらべ＊から売上テーブル場所（顧客一意番号と６３５が等しい）。

…かえって分りづらい気がする。

728 ：NAME IS NULL：04/10/20 09:46:47 ID:???

さすがにそんな、ぴゅう太的じゃないだろ。

729 ：NAME IS NULL：04/10/20 09:57:15 ID:???

今のご時世、正規化を崩さないとパフォーマンスが出せないなんて事例が普通の案件で
あるのだろうか?

大抵の場合
・モデリングがおかしい
・そもそも正規化が出来ていない
　(正規化を理論として押さえていない奴ほど「正規化崩し」という言葉を使う)
・アプリケーションの構造がおかしい
　(全件取得して条件に合う行を処理する、一件毎の処理に毎度SELECTを投げるなど)
・ミドルウェアべったりでSQLを知らない
　(JAVAグラマ、VBグラマに多そう)
のどれかだと思われ。

730 ：NAME IS NULL：04/10/20 10:50:44 ID:???

ちょっと前の話ですが、第一正規系にもなってない
テーブルがあったんです。
何故正規化していないのか設計者に質問したら、
場合により正規化崩しする場合がある。
という答えが。
その他、保守性や整合性の問題からもいろいろ質問
しても、特に問題ない。という答えばかり。

729さんの言うとおりかも知れない。

731 ：NAME IS NULL：04/10/20 11:13:02 ID:???

>>729
日次集計・月次集計なんて正規化崩しの最たるものだと思うのだが。

732 ：NAME IS NULL：04/10/20 11:29:10 ID:???

どういうやり方してんの？

733 ：NAME IS NULL：04/10/20 11:50:08 ID:???

集計用テーブルを作る。

734 ：NAME IS NULL：04/10/20 11:52:15 ID:???

あと、変更したときの古いデータを残す必要があるものは、トランザクションデータにマスタデータ埋め込んだりするね。

735 ：NAME IS NULL：04/10/20 11:56:26 ID:???

そういうのって正規化崩しって言うのですかね？
保持しているデータの意味は違うし。

736 ：NAME IS NULL：04/10/20 12:07:56 ID:???

>734
それは正規化崩しじゃない

737 ：NAME IS NULL：04/10/20 15:42:04 ID:???

バックアップテーブルをよっぼと元のマスタと違う形式にしてない限りは
正規化にのっとってると言えるよ
日次ー月次　の関係は　会社ー従業員　の関係と同じ

738 ：NAME IS NULL：04/10/20 17:45:17 ID:???

DBの設計の勉強できるサイト無いの？
いい所あるなら教えて。

739 ：NAME IS NULL：04/10/20 17:59:44 ID:???

日次ー月次を分離するのは
同期を取る必要がない場合だな
日本の業務形態はたいていこの場合なんだけどね
同期を取る必要があるのに分離したら正規化くずしになる

740 ：NAME IS NULL：04/10/20 18:13:21 ID:???

>>738
http://pc5.2ch.net/db/

741 ：NAME IS NULL：04/10/20 19:19:26 ID:???

「年月日」を持つデータを月次集計で「年月」に集約するのは、正規化崩しとは言わない。
データ粒度を荒くしているだけで、そのテーブルひとつに着目すれば正規化されているわけだからね。
ただ、データベース全体で見ると、日別の計として得られるデータを別に
保持しているので冗長データである、という言い方はできる。

正規化崩しが敬遠される原因のひとつに「データ整合性を維持するのが困難になる」
というものがあるけど、集計テーブルも同じように整合性維持問題を抱えることになる。
通常は月次更新で、過去データを変更できないようにシステムで制御する。

ほかには、推移表などのリスト出力をサポートするために、1月, 2月, 3月と列を分けて
正規化を崩したテーブルを作成することがある。データベース管理者は、この形式のテーブルを
もっとも嫌うようだけど…。アプリケーションフロントエンドで推移表を作成するのは
ものすごく計算コストがかかる。できれば月次更新で、推移表および累計データを作ってしまいたい、
というのがアプリケーション側を担当しているエンジニアの言い分。

742 ：NAME IS NULL：04/10/20 19:34:49 ID:???

業務アプリを作る際、一般的にテーブルにリレーションってはるもん？
契約テーブルの顧客コードっつー項目と顧客マスタの顧客コードをリレーションはって
契約テーブルの顧客コードに顧客マスタにある顧客コード以外入らないようにするっての。

俺が今まで関わったプロジェクトって全部、テーブル間のリレーションをはらないのばっかだったから
はらないのが普通なのかなと思っていたが、実際どうですか？

743 ：NAME IS NULL：04/10/20 19:57:18 ID:???

>>742
はる。

744 ：NAME IS NULL：04/10/20 20:06:06 ID:???

>>742
はる。
カスケードも本当に必要なところだけだが設定する。

745 ：NAME IS NULL：04/10/20 20:36:08 ID:???

はらない
張ってもデバッグ所要時間に違いがないから余計な手間

746 ：NAME IS NULL：04/10/20 20:37:54 ID:???

>742
それで整合性が保たれているならたいしたもんだ。
プログラムで全部チェックしてたり？

747 ：NAME IS NULL：04/10/20 20:39:29 ID:???

顧客コードを取得、生成する部分はライブラリに内包しちゃうので
プログラム的にバグが入り込むことはまずない部分

748 ：NAME IS NULL：04/10/20 20:48:02 ID:???

>>741

> ほかには、推移表などのリスト出力をサポートするために、1月, 2月, 3月と列を分けて
> 正規化を崩したテーブルを作成することがある。

自分も非正規形だと思っていたのですが、>469以下の議論ではこれは正規形で
あるという事になっているみたいですねぇ。

749 ：NAME IS NULL：04/10/20 21:52:57 ID:???

>>745
そりゃ、バグがみつかってから修正するための時間には影響しないだろ。
それよりもサポートツールが関連をひらってくれない方がめんどう。

750 ：742：04/10/20 22:01:18 ID:???

やっぱりはるよなぁ。
「顧客マスタに該当データが無い時はどうしましょう？」って質問すると
「無い場合は無いから考えなくても良いよ」とか言われる。
無い場合が無いんだったらリレーションはれば良いのに……。

751 ：NAME IS NULL：04/10/20 22:05:18 ID:???

「無い場合は無い」のではなくて、「あってはいけない」のであって、なんの保証もなしに断言できるものじゃないのにね。

752 ：NAME IS NULL：04/10/20 22:07:58 ID:???

リレーション機能がない場合はどうすれば？

753 ：NAME IS NULL：04/10/20 22:13:05 ID:???

それはRDBじゃないよね

754 ：NAME IS NULL：04/10/20 22:13:31 ID:???

リレーションとして表示できなければリレーショナルデータベースでは無いよ。

755 ：NAME IS NULL：04/10/20 22:15:39 ID:???

リレーション機能のないRDBってあるの？

756 ：NAME IS NULL：04/10/20 22:18:24 ID:???

リレーション＝関係変数≒テーブル名＝表
と
リレーションシップ＝参照整合性

を混同するなよ。

757 ：753：04/10/20 22:19:56 ID:???

(いまさら釣りだなんて言いにくいな・・・orz)

758 ：NAME IS NULL：04/10/20 22:35:29 ID:???

752=753？
オマエは台風の中、防波堤の上に立ってろ。

759 ：753：04/10/20 22:39:48 ID:???

>>758
別人
ただ、>>752を見た瞬間「ﾁｬｰﾝｽ!」とか詰まらんことを思ってしまっただけさ orz

760 ：NAME IS NULL：04/10/20 23:16:25 ID:???

>>759
そうか。

台風には気をつけてな。
雨戸しめてねろよ。植木鉢は家に退避しろ。
寝る前に水分取りすぎるとおねしょするぞ。

761 ：NAME IS NULL：04/10/20 23:28:34 ID:???

了解
今から防波堤でファイヤーダンスしてきます。
全裸で。
一人で。

762 ：753：04/10/20 23:33:37 ID:???

>>760
ぐっすん、オヤスミナサイ。

763 ：NAME IS NULL：04/10/20 23:34:59 ID:???

>>755
そもそも関係変数なんて言葉使わないんだが。

764 ：NAME IS NULL：04/10/23 01:20:15 ID:88UFjYBG

今日疲れた一言。

『トリガーって何処で流すんですか？』

その一言を水に流してください。

765 ：NAME IS NULL：04/10/23 02:06:40 ID:???

相手が新人なら水に流してやれyo

漏れの会社じゃ新人でもない奴が新規開発でイマサラRDO使って開発中だよ・・・会社に転がってたテキスト見ながら作っちゃったらしい orz

766 ：NAME IS NULL：04/10/23 05:19:51 ID:???

RDOってなんだっけ？

767 ：NAME IS NULL：04/10/23 07:31:17 ID:???

ADOのママンです

768 ：NAME IS NULL：04/10/23 08:13:49 ID:???

RDOなつかし～

769 ：NAME IS NULL：04/10/23 14:21:36 ID:???

>>764
質問さえまともに出来ない人間て最近多い。
自分が今何をどうしたいのかといった質問能力については
IT関連の業務に限らず社会人として必要不可欠な能力だよね。
馬鹿な質問者の意思を汲み取って推測して回答するのは
ホント疲れるよな。

770 ：NAME IS NULL：04/10/23 15:14:50 ID:???

馬鹿な質問者の意思を汲み取って推測して回答するのは
IT関連の業務に限らず社会人として必要不可欠な能力だよね。
ホント疲れるよな。

771 ：NAME IS NULL：04/10/23 15:33:35 ID:???

>>770
最後の一行が無ければいい感じだったのにねぇ
質問はちゃんとしようねw

772 ：NAME IS NULL：04/10/23 15:34:07 ID:???

>>770
はげどう

773 ：NAME IS NULL：04/10/23 17:44:35 ID:???

>>764
『DBサーバ』と一言ですませませう。

774 ：NAME IS NULL：04/10/27 12:39:17 ID:???

お昼時にコンビニ「法子」でカップラーメンを買ったんだよ。
そしたら、「お湯を入れていかれますか？」って聞くから、
「はい」って答えたさ。
そしたら、カップラーメンを袋に入れず剥き出しで、
割り箸添えて笑顔で手渡されますた。

775 ：NAME IS NULL：04/10/27 13:32:53 ID:???

いいじゃねぇか、どうせすぐ袋から出すんだろ。
お湯はセルフサービスだよ。
イケメンさんにはついでやるけどな。

776 ：NAME IS NULL：04/10/27 14:02:12 ID:???

>>774
笑顔が嬉しかったの？

777 ：NAME IS NULL：04/10/27 14:36:37 ID:???

>>776
いいや、手渡しが嬉しかったんだろう。

778 ：NAME IS NULL：04/10/27 15:25:47 ID:???

>>774がうらやましいと思ったのは俺だけ？

779 ：NAME IS NULL：04/10/27 15:31:15 ID:???

コンビニ法子を正規化するスレはここですか？

780 ：NAME IS NULL：04/10/27 16:50:14 ID:???

袋を節約したのはいいが、カップラーメンの中に、
・崩れたチャーシューがちょこっとしかはいっていないのに分厚いアルミのレトルト袋
・麺にまで袋
・ちっこい海苔1枚が個包装
という、なんともやるせない現状を正規化してみてください。

781 ：NAME IS NULL：04/10/27 17:11:16 ID:???

>>780
いや、そもそも774が最も期待するソリューションを提案すべきだろ。
774はラーメンが食べたかったのか、それともたまたまラーメン、
しかもカップラーメンなどという選択を好んでいたのかどうか？
先ずはそのへんから分析すべき。

782 ：NAME IS NULL：04/10/27 17:57:52 ID:???

>>780
それはカップラーメン的にかなり正規化できてるのでは？
パフォーマンスはものすごく悪いとは思うがｗ

783 ：NAME IS NULL：04/10/27 23:20:07 ID:RspvWNu9

チャーシューは正規化せず，繰り返しがあるのがいいのだが・・・・

784 ：NAME IS NULL：04/10/27 23:21:58 ID:???

いやいや正規化していくつでも入れれるようにしないと。

785 ：NAME IS NULL：04/10/28 00:40:54 ID:???

Excelにすればどんなチャーシューでも入れ放題ですよ?

786 ：NAME IS NULL：04/10/28 10:54:05 ID:???

ｵ､ODBの出番ﾃﾞｽｶ？

787 ：NAME IS NULL：04/10/28 12:08:35 ID:???

呼んでませんよ。
ORマッピングがあれば必要なし

788 ：NAME IS NULL：04/10/28 21:58:11 ID:???

>785
でも行数に制限がｗ

789 ：NAME IS NULL：04/10/29 00:12:12 ID:???

>788
そんなあなたにRAW区画

790 ：NAME IS NULL：04/10/29 13:42:30 ID:8AWB59Zs

正規化しまくると検索処理速度が落ちると聞きましたが
折衷案はどこですか？

791 ：NAME IS NULL：04/10/29 13:44:31 ID:8AWB59Zs

>>770
その能力マジで欲しい
どうやって強化できますか？

792 ：NAME IS NULL：04/10/29 14:35:58 ID:???

まず自分の知識レベルがかなりないと予測するのは難しいよね
知識レベルがあがってくると自分が初期のころにしていた発想が失われて
初心者の質問見てなんでそんな発想するんだって感じてしまう
でも大体みな同じような発想してることに気づけたらそれでわかるよ
質問者が会社の後輩とか決まった人間ならその人それぞれの知識レベル
を考慮してその立場で考えてやれば言いたいこともわかる
なんにしても質問者を否定しないことが一番大事だと思うけどね

793 ：NAME IS NULL：04/10/29 15:13:52 ID:???

トランザクションデータについて教えてください
売上伝票データの扱い方が正しい正しいでしょうか？

基幹業務で売上レコードを溜め込む売上テーブルがあるんですが
その売上レコードを確定（変更不可）させるために
売上確定＋日付テーブルに売上テーブルを移動させています

794 ：NAME IS NULL：04/10/29 19:24:12 ID:???

>>792
さっそく出番だ。>>793に答えてやれ。

795 ：NAME IS NULL：04/10/29 23:06:46 ID:???

テーブル数がむちゃくちゃ多くなりそうだけど問題ないの？
単純に確定フラグって項目作って管理したほうが楽だと思うけど
正規化としてはフラグにするのが正しい

796 ：NAME IS NULL：04/10/30 02:19:25 ID:???

>>794の後半と>>795の内容をJOINさせるのに数分かかった。
正規化されたレスとはこういうレスのことなのかもしれんと思った。（笑）

797 ：NAME IS NULL：04/10/30 03:39:05 ID:???

うちでは、売上テーブル＋日付カラム　という形の確定売上テーブルを
作って、毎日売上テーブルから select *,now() をinsertしてる。

798 ：NAME IS NULL：04/10/30 06:24:32 ID:???

>>793
「売上確定+日付テーブル」が「売上確定20041030」というテーブルのことなら、萎える。

799 ：NAME IS NULL：04/10/30 10:11:43 ID:???

>>795 に同意。確定区分でも付けとけば問題なし。うちでは請求書出すまでは
変更可能なので、「請求済み」という項目にして請求締め処理でフラグ立ててる。

800 ：NAME IS NULL：04/10/30 16:05:42 ID:???

過疎板のくせに800

801 ：NAME IS NULL：04/10/31 15:10:59 ID:???

>798
・・・マジでやってそうだな。
基幹業務とかぬかしてるし。

802 ：NAME IS NULL：04/11/02 16:13:18 ID:???

製品ID, 更新日, 工程Ａ所要時間, 工程Ｂ処理速度, …, 最終工程所要時間

こんな感じのテーブルがある。主キーは製品IDと更新日。
各工程の所要時間/処理速度を、製品ごとに履歴をとって保存する。
（実際には、各工程の所要人数など諸々を含めて項目数が30を超える）

各工程でどのような作業を行うかは全製品で固定。
ロット数に関係なく一定の時間（所要時間）のみかかる工程と、ロット数に
正比例した時間（処理速度×ロット数）がかかる工程がある。

製品によってはいくつか工程を飛ばすものもあるが、基本的に同じ工程を
同じ順番で経て、完成品が出来上がる。
このテーブルを基に、ある日の製造ロット数から各工程に必要な時間など
を一括して求めて、そのままアプリケーションに渡す。

…こういう場合、項目が30超えてても正規化しなくていいよな？

803 ：NAME IS NULL：04/11/02 17:15:05 ID:???

補足すれば、
・特定の工程に必要な時間だけを渡す
・ある製品の第一工程～最終工程までの必要時間の合計を渡す
ということは、ない。

804 ：NAME IS NULL：04/11/02 17:15:40 ID:???

で？
工程が変わったらテーブル構成もかわるの？
製品と工程が多対多で、関連テーブルに所要時間・所要人数

805 ：NAME IS NULL：04/11/02 18:05:21 ID:???

>>804
使用する場所が限定されてて、工程の変更・追加はほぼないわけよ。

あと、例は簡略化してるけど、実際には原材料が同じ複数の製品はある
工程で一緒に処理するとか、そういう煩雑なルーチンが必要となる。
ので、工程が変更・追加されたら結局アプリケーションを書き直す必要が。

ちなみに>>804の言うとおり

製品ID, 更新日, 工程番号, 所要時間, 処理速度

てな感じの設計も考えたが、このような条件の時に、可読性以外に正規化
するメリットってあるのかな、と。そこが気になるわけだ。

806 ：NAME IS NULL：04/11/02 18:42:41 ID:???

逆に、正規化しないメリットもあまりない気がする。
それなりのシステムだとするとね。
マッピングの方法がちょっとかわるくらいで。
SQLを手書きする必要がある部分が多ければ別だけど。

807 ：NAME IS NULL：04/11/02 20:17:52 ID:???

そこでExcelの登場ですよ

808 ：NAME IS NULL：04/11/03 03:05:28 ID:???

>>807
WinXPからExcel落ちることがやたら多い!!
Win2000Serverではほとんど経験無いのに!!
(勿論Win95/98は論外だが)

809 ：NAME IS NULL：04/11/03 03:18:46 ID:???

そこでMeですよ。

810 ：NAME IS NULL：04/11/03 09:19:44 ID:???

そこでPC-DOS2000ですよ。

811 ：NAME IS NULL：04/11/03 11:57:53 ID:???

>>802
なんでそこまでして一つのテーブルに収めたいの?
よほどSQLを知らないか、妙なトラウマでもあるのか…

> あと、例は簡略化してるけど、実際には原材料が同じ複数の製品はある
> 工程で一緒に処理するとか、そういう煩雑なルーチンが必要となる。

よくある話じゃん。
いちいち工程変更でアプリケーションを書き直す必要はない。
ちゃんとモデリングすればキレイに解決出来る問題だよ。

何か一冊、業務別のデータモデリング本でも読んだ方がいい。
やろうとしてることが自分の知識の範疇を超えてると思われ。

812 ：NAME IS NULL：04/11/03 23:47:15 ID:ZjrGkFHF

ｵﾏｲﾗって参照整合性制約って使ってますか？
あれってDML文を発行する度にマスタテーブルを見に行くから、パフォーマンスが悪いと聞いたのだがどうなんだろ？

漏れは参照整合性制約を使用していないけど、データを抽出する時には外部結合で対応してる。

813 ：NAME IS NULL：04/11/03 23:57:36 ID:???

そのパフォーマンスの悪さが問題にならなければおけ。
システムとしてパフォーマンスが悪いのが問題になってはじめて、改善策のひとつとして制約やトリガを外したりする。

814 ：NAME IS NULL：04/11/04 20:03:17 ID:???

>>812
それってデータを更新する(DELETE/UPDATE/INSERT)ときは
ある程度関係あるかもしれんけど、SELECTでは
どうなんでしょ？
Oracleが手元に無いんでわからんが暇な方、実行計画を採取して
報告してくんないかな。

815 ：NAME IS NULL：04/11/07 00:36:23 ID:???

スタークエリだかスタースキーマだかをENABLEにするパラメータが関係するとか聞いた

816 ：NAME IS NULL：04/11/09 01:26:06 ID:???

横方向に月数（１２か月分）、縦方向に科目コード（２０科目）の帳票があるとしよう。
この帳票の為のワークテーブルの構造が

科目０１月数０１金額
科目０１月数０２金額
　　　：
科目２０月数１２金額

と１レコードにひたすら横に項目が並んでるんだが、誰か（というか設計者）この設計の理由を教えて
くれ・・・ orz

１帳票１レコードになるから便利・・・位しか漏れには思いつかないんだが・・・
パフォーマンスを突き詰めるとこの構造の方が有利なのか？

ちなみにテーブルを設計したのはシステム構築で飯を食ってるシステム屋だ・・・・

817 ：NAME IS NULL：04/11/09 01:42:53 ID:???

ワークテーブルだからどうでもいいんじゃね？

818 ：NAME IS NULL：04/11/09 20:26:59 ID:???

>>817
んだんだ

819 ：NAME IS NULL：04/11/10 00:49:43 ID:???

>>816
パフォーマンスを突き詰めなくても科目+月数で
PrimaryKeyになるんでしょ？
20*12=240行
あらら。。パフォーマンスを突き詰めなくてもホーケー。

820 ：NAME IS NULL：04/11/10 01:22:00 ID:???

>>819
240行じゃなく240列？

821 ：NAME IS NULL：04/11/10 10:55:41 ID:???

>>816
レポート作成ソフトに項目を落とし込むときに便利なのでは。

パフォーマンスは関係ないよね。
ワークテーブルって事はどこかのタイミングで正規化されたテーブルから
ワークテーブルを作成してるわけだから。

822 ：NAME IS NULL：04/11/10 11:49:56 ID:8aD21xS6

ＤＢ初心者です。パフォーマンスと正規化の兼ね合いについて
ご教授ください。

例えばユーザーテーブルと本テーブルがあったとします。
ユーザーがどんな本をもっているかを表したいので、
ユーザーテーブルと本テーブルのキーをもったユーザー＆本テーブルも
あるとします。

ここでユーザーがいくつ本をもっているかを一覧で表示するとしたら、
ユーザー＆本テーブルと結合して人数を取得できると思うんですが、
もし本テーブルが１００万くらいの数だとしたら、パフォーマンスは
あまりよくない気がするんですがどうでしょうか？

ユーザーテーブルに本をいくつもっているかを表すnum_bookなどを持たせて、
関係が変わった時に、インクメント、デクリメントする方が早いと思うのですが、
どっちのほうがいいのでしょうか？

わかりにくくて申し訳ないですがよろしくお願いします。

823 ：NAME IS NULL：04/11/10 12:20:03 ID:???

>>822
あなたの前者の考えは至極普通な考えだと思います。
ユーザー＆本テーブルからネステットジョインすれば
一覧も簡単に取り出せるだろうし。

逆に後者の考えがよくわかりません。

824 ：821：04/11/10 13:08:57 ID:8aD21xS6

>>823

なぜ後者のようにユーザーテーブルにnum_bookを持たせた方がいいのかなぁ
と思ったかと言いますと、
ユーザーが1万レコード、本が１００万レコードあり、
ユーザー一覧画面でＡさんはＸ冊、ＢさんはＹ冊という風に３０件ほど
表示するのですが、本をたくさんもっている人から並べるなどの
ソートがあり、結合するよりも、order by num_bookで表示したほうが
明らかに早いと思ったからです。

結合すると一人一人何冊もっているかを確認しないといけないと思うので、
結合するより早いのかなと思ったわけです。

普通はこんなやり方はやっぱりしないですか？？

825 ：NAME IS NULL：04/11/10 13:28:33 ID:???

その整合性を保つのがめんどうなのと、追加削除のたびに増減させないといけないのとで、めったにやらない。
ほんとにそこで問題が出た場合は、そういう対策するかもしれんけど。

826 ：NAME IS NULL：04/11/10 22:43:10 ID:???

「高次」正規化しない場合の幾つかの欠点
・本を何冊持っているかわからないユーザの情報（氏名とか）は追加できない。(nullは論外)
・本を追加するには複数のテーブルを更新しなければならない。（トランザクション）
・num_bookの数とユーザー＆本テーブルの整合を直接RDBMSで保証できない。

827 ：NAME IS NULL：04/11/10 23:33:41 ID:???

>>822 やってみりゃわかりますが、パフォーマンスは気にするほど落ちないですよ。
保守性とか考えると正規化したほうが圧倒的に便利です。

828 ：NAME IS NULL：04/11/11 08:35:26 ID:???

こういう考えかた（本の冊数を更新する）って
どこから出てくるんだろう？
揶揄してるんじゃなくて、前にこういう仕事をこういうプラットフォームでこういう言語でやってた
とか傾向があるのかな。

DATE型が嫌いとかVARCHAR2しか使わせないとかは
みかか系の人に多いとかそういうの。

829 ：822：04/11/11 09:00:41 ID:???

>>825-827
やはり保守や整合性を考慮すると普通に結合した方が良いのですね。
ありがとうございます。

>>828
このシステムはＷＥＢでユーザー一覧のアクセス頻度も
結構多いのでパフォーマンスを考慮した上でそう考えました。
今までにこういう数を持たせるなんてことはやったことはないですし、
何かに依存したシステムでの開発もありませんよ。
ただパフォーマンスを追及したかっただけです。

830 ：NAME IS NULL：04/11/11 09:04:15 ID:???

パフォーマンスの追及は、パフォーマンスに問題があってから。
結構多いっ１分で100件とか集中したりするの？

831 ：822：04/11/11 09:19:29 ID:???

>>830
問題がありそうなところを先に考慮しとくのはよくないということでしょうか？

多い時だと１分で１００件以上になる可能性もあります。

832 ：NAME IS NULL：04/11/11 10:38:41 ID:???

まともなDBMSなら、本テーブルがン百万件あっても結合によるパフォーマンス低下なんて
問題にならないレベルであるはずだし、仮にそれが問題になるならメモリをどーんと増やせば
一発で解決しそう。
まっとうな方法やってりゃ、問題が出たときもまっとうな方法で解決できるから楽。

833 ：NAME IS NULL：04/11/11 10:55:00 ID:???

>>829
正規化を崩してパフォーマンスを上げても、どこかで必ず頭打ちになる。
そのうち、行き当たりばったりでなし崩し的に正規化崩しが行われるようになって
誰も保守出来ないぐちゃぐちゃなデータベースが出来る。

パフォーマンスを考慮するというのは
・単位時間当たり最大いくつのトランザクションを処理する必要があるか。
・そのためにはどれだけのマシンスペックと回線が必要か。
・処理しきれない物についてはどうするか。
↑こういうことを見積もる事であって、いきなりテーブル構造を云々するのは間違い。
正規化を崩すなんて話は、これらすべてを考慮してもなおパフォーマンスが出ない場合の
苦肉の策ぐらいに思った方がいいよ。

834 ：822：04/11/11 11:41:49 ID:???

>>833
パフォーマンスを考慮＝正規化崩しに直結するっていう考えが
まずかったんですね。そのまえに他にやることを何も考えずにいました。

まずは正規化した上でやれるだけやってみようと思います。
（個人的にどれくらいのパフォーマンスの違いがあるかみてみたいので
　num_bookと比較してみたいです）

わかりやすい説明ありがとうございました。

835 ：NAME IS NULL：04/11/11 15:38:20 ID:???

>>831
> 問題がありそうなところを先に考慮しとくのはよくないということでしょうか？

デメリットがある方策を想像で考慮するのはよくない。

836 ：NAME IS NULL：04/11/11 20:25:44 ID:???

まさに、num_book と同じことをやろうとしていたんだが…。

伝票テーブル (伝票番号, 売上先コード, 合計売上金額)
伝票明細テーブル (伝票番号, 行番号, 商品コード, 売上金額)

こんなふうに、伝票テーブルに(num_bookのように)合計売上金額を持たせるのってダメ？
(明細が必要になるのって伝票発行とか限られた処理だけなので) 伝票テーブルだけで
売上集計などがすばやくできるようになってるといいかなー、と思っていたんですが。

邪道？

837 ：NAME IS NULL：04/11/11 21:49:50 ID:???

邪道ではないけど。
それに、合計売上金額は一度確定したら変更されることはないから、デメリットもないし。

838 ：NAME IS NULL：04/11/11 23:30:40 ID:???

>>836
伝票明細テーブルに追加するたびに伝票テーブルを更新するのかぁ。。
俺なら邪道(とゆーか変)だと思う。
PrimaryKey（伝票番号, 行番号）でGROUP BY+SUMで合計売上金額出せるんだから。

839 ：NAME IS NULL：04/11/11 23:44:16 ID:???

伝票合計金額が必ず明細の合計と一致する業務であるなら、あえて持つ必要無し。
というか持つべきではない。理由は>838。要は正規化ね。
集計が素早くなる？その為だけに正規化を崩し複雑さを増すのは愚かな気が。

逆に、値引や税、端数その他諸々の理由でその辺が一致しないケースも扱うなら、
当然伝票と明細に金額を持たなければならない。これも同じく正規化。
販売管理業務ではこっちを採用する例のほうが多いね。

全ては要件次第。
要件を元に順当に正規化して、パフォーマンスの問題が出たらその時初めて
考えれば良い事じゃねーの？なんか考慮の順序がおかしくないか？
便利だからとか早そうだからっていう理由でDB設計してるのか？

840 ：NAME IS NULL：04/11/11 23:45:08 ID:???

>>836
> まさに、num_book と同じことをやろうとしていたんだが…。

同じ事なのになぜあえて聞くのか…
このスレを>>822から読んでみたなら自ずと答えは出るだろう?

841 ：NAME IS NULL：04/11/12 00:06:38 ID:???

合計売上金額は、num_bookとはちょっと問題が違うと思うんだけどね。

842 ：NAME IS NULL：04/11/12 00:09:53 ID:???

この場合は伝票テーブルと伝票明細テーブルで一枚の伝票エンティティを表すわけだから、num_bookの場合とは少し違うと思われ。
紙の伝票に「合計金額」という項目があるなら、その写像である伝票テーブルに「合計金額」があっても問題ない。

843 ：NAME IS NULL：04/11/12 00:22:47 ID:???

正規化の初歩の初歩の初歩だな。

正規化合計金額で google先生にでも聞いてみろ。

844 ：NAME IS NULL：04/11/13 00:21:14 ID:???

DB設計ってやっぱどっかできちんと勉強せんといかんな。
おまいらは何で勉強しますたか？

845 ：NAME IS NULL：04/11/13 03:20:44 ID:???

>>844
この板

846 ：NAME IS NULL：04/11/13 05:01:32 ID:???

>>844
Coddって人から教わった。

847 ：NAME IS NULL：04/11/13 05:09:43 ID:???

>>846
あの人、酒くさくね？

848 ：NAME IS NULL：04/11/13 05:29:58 ID:???

>>847
死んだ人のことを悪く言うのはイクない

849 ：NAME IS NULL：04/11/16 21:52:49 ID:vxJjNxbr

顧客ID　商品A　商品B　商品C ・・・・商品Z
　　　　買った　NULL　買った　　　　NULL

なんてテーブルはやっぱりダメですか・・・
商品Aを買ったか調べる場合、SELECT 商品A from 購入テーブル WHERE 商品A
IS NOT NULL; なんてやってるのですが。正規化したいけどわかんないです。

850 ：NAME IS NULL：04/11/16 22:44:23 ID:???

商品数は固定で増えないのか？

851 ：NAME IS NULL：04/11/16 22:46:00 ID:???

>849
ダメ。許さない。Access で作ったら商品254個までしか増やせない。切腹。
＞商品Aを買ったか調べる場合、SELECT 商品A from 購入テーブル WHERE 商品A
＞ IS NOT NULL; なんてやってるのですが。正規化したいけどわかんないです。
それじゃ買ってないかを調べてるのではないかに。

商品を商品Tbl にまとめて、新たに購入履歴Tbl を設ける。

顧客Tbl PRIMARY KEY: 顧客ID
-顧客ID
-顧客名

商品Tbl PRIMARY KEY: 商品ID
-商品ID
-商品名

購入履歴Tbl
-顧客ID
-商品ID

商品Aを買ったか調べる場合、
SELECT 顧客名 FROM 顧客tbl, 購入履歴Tbl, 商品Tbl
WHERE 顧客tbl.顧客ID=購入履歴Tbl.顧客ID AND
購入履歴Tbl.商品ID=商品Tbl.商品ID AND
商品名='商品A';
で各顧客が買ったかどうかわかる。買った数だけ名前が出る。
集計取りたきゃ GROUP BY でまとめて顧客名を COUNT すればいいし、
一回以上買ったかどうかを調べるなら SELECT DISTINCT に変えればいい。
まだ買ってない顧客なら IS NULL で。

852 ：NAME IS NULL：04/11/17 01:23:24 ID:???

初心者だったら、迷わず全ての属性にNOT NULL制約を付けましょう。
テーブルの設計はそれから。

853 ：NAME IS NULL：04/11/30 19:10:06 ID:???

ん～今日初めてこのスレ読んで、正規化についてちゃんと勉強したくなってきた～みんなありあと～

854 ：NAME IS NULL：04/12/05 15:37:00 ID:cMDeyAad

いいシステムはいいネットワークといいデータベースから。

855 ：NAME IS NULL：04/12/05 15:50:31 ID:???

>>854
そしていい運用管理者といいユーザーが揃えばｶﾝﾍﾟｷﾀﾞ!!

856 ：NAME IS NULL：04/12/05 18:13:43 ID:???

>>854
ちがうぞ。
いいシステムはいい予算からだ。

857 ：NAME IS NULL：04/12/05 23:56:49 ID:???

いいクライアントからじゃないの？（笑）

858 ：NAME IS NULL：04/12/06 00:42:37 ID:???

予算さえ出してくれれば、いいクライアント。

859 ：NAME IS NULL：04/12/06 16:09:16 ID:/YmiWcVS

販売管理とかの売上データでまったく同じテーブルレイアウトで
日次データと確定データとあって、売上入力を行うと日次データに
書き込まれ、日次更新処理を行うと日次データから確定データに
移動するって感じになってるんだけど、
これって邪道？

売上データにフラグをもってた方がいいのかな？

860 ：NAME IS NULL：04/12/06 22:04:00 ID:???

>>859
日次データに更新時間とかタイムスタンプ持ってるんでしょ？
ならレコード毎にフラグ持つ必要ないじゃない。
日次処理時刻とかを管理テーブルに持たせれば、
それ以前のタイムスタンプを保有する日次データは
おのずと確定データになるんじゃないの？

861 ：NAME IS NULL：04/12/06 22:12:06 ID:???

一般論で言えば、仕様が「日次更新処理を行うと日次データから確定データになる」であって「日次更新処理を行うとそれ以前のデータが確定データになる」ではないならば、フラグをもつ方が良い。
日次更新処理が途中でおちたらどうするか、とかね。

862 ：NAME IS NULL：04/12/06 22:14:29 ID:???

とりあえず、こういった「同じ動きができるけどモデルとしては正しくない」設計にしたとき、いろんな問題があとから出てきてどうしようもなくなることが多い。

863 ：NAME IS NULL：04/12/06 22:21:14 ID:???

NOT NULL制約付けるとなんか言い事有るの？
createの時not null付けるのﾒﾝﾄﾞｲから主キーだけしか付けんと言うか勝手に付く。

864 ：NAME IS NULL：04/12/06 22:27:37 ID:???

NULLが入っちゃいけないところにNULLが入らないことが保証できる

865 ：NAME IS NULL：04/12/06 22:33:36 ID:???

そこで FORCE NULL 制約ですよ。

866 ：NAME IS NULL：04/12/07 00:51:53 ID:???

>>864
それって利点って言うよりただの仕様じゃん。

867 ：NAME IS NULL：04/12/07 01:09:22 ID:???

>>866
仕様が保証できることに利点がないとでも？

868 ：NAME IS NULL：04/12/07 01:32:17 ID:???

>>867
いや、仕様としてそれは良いんだよ。
使うべき所に使うのは当然。
でもnot nullって考え無しに全部付けとけとか言うじゃない。
必要の無いところに付ける意味が有るのかと。

869 ：NAME IS NULL：04/12/07 02:30:32 ID:???

>>868
> 考え無しに全部付けとけとか言うじゃない。

NOT NULLとは別の問題かと。

870 ：859：04/12/07 09:47:13 ID:g+FFS1ec

>>860
コボラーが作った仕様なのでよくわかりませんが、
更新時間はもってないです。

>>861
「日次更新処理を行うとそれ以前のデータが確定データになる」
ではないのでフラグでOKですかね

設計者がいうには日々200件程度の日次データがあって
そこから日報を出力することになっているのですが、
フラグよりも日次データから確定データに移動した方が
日報出力の抽出が早いとか、データが分かれてた方が
わかりやすいとか、プログラムが楽とか言ってた。
なんか納得できない。

871 ：NAME IS NULL：04/12/07 10:59:00 ID:???

＞870
俺は昔コボラーだったけど
日次、月次のファイル（DB）を別にするのは昔ながらのバッチ処理の手法だろうね
今時の考えでは無いけど、状況や運用によっては有用な場合も有ると思う
現在でもメインフレーム使ってる銀行などではこういった手法も残ってるし
その人って４０代以上の他の言語をあまりやってないコボラーなのかな。

ただRDB使って日々200件程度ならフラグとかでわけるのが現実的だわな

872 ：NAME IS NULL：04/12/07 12:13:31 ID:???

>>852
NOT NULL 制約はキチンとつけたいと思うけど、DBMSで長さゼロの文字列の
扱いが違うからvarchar型だと厄介ですね。
脱線するけどANSI SQLだとどれが正式なんでしょうね。
長さゼロ文字列＝NULL
長さゼロ文字列＜＞NULL
何も決まってないか玉虫色の表現（笑）

873 ：NAME IS NULL：04/12/07 12:41:34 ID:???

>>870
完全に日次で締めてしまえるデータなら良いけど、たいてい日次くらいだと
遡っての修正とか検索とか発生するから同じテーブルのほうがいい気がしますね。
年締め単位くらいで別テーブルに移動ってシステムなら割とありますけどね。
日報を出したいなら別にジャーナル用のテーブルを準備して変更情報を放り
込んでだほうが実用的だと思いますよ。

874 ：859：04/12/07 12:42:19 ID:???

>>871
40後半の生粋のコボラーです。
まあうちの会社のSEはほとんどが、生粋のコボラーしか
おりませんが。
日次、月次のファイル（DB）を別にするのとRDBの機能を
使いにくそうなんですけどねえ。

875 ：NAME IS NULL：04/12/07 13:20:03 ID:???

>>874
MTがくるくる回るってソートとマッチングを繰り返すCOBOLのバッチ処理は
新興のRDBやらとは歴史が違います（笑）。伝票処理などはバッチのほうが
合理的と思えるケースもあります。
データの流れを追ってゆく形の設計をするとバッチ的な処理にマッチします。
DBだとデータは流れなくて状態が遷移してゆくって設計になります。その
ため逆に流れを記録したいときには別の仕掛けが必要になってしまいます。
世の中一般の業務的な手順や制度や法制自体がCOBOL的処理と概念に基づい
て作られてるんじゃないかと疑っています（笑）。

876 ：NAME IS NULL：04/12/07 13:34:49 ID:???

>日次、月次のファイル（DB）を別にするのとRDBの機能を
>使いにくそうなんですけどねえ。
コボラーが設計してるって事は集計に本来RDBが必要なシステムなんじゃないかな？

例えば売り上げ集計や銀行業務等のシステムでは
日時データを集計＝＞日報作成＝＞日時集計ファイルへ追加
で、月次は日時集計ファイルを集計＝＞月報作成＝＞月次集計ファイルへ追加って感じで
バックエンドの処理には殆どRDB機能を使う事は無いと思う
実際問題として未だに１０年前のシステムを使ってる所なんかだと
MT（リールの磁気テープ）の架け替えで集計処理を行ってるとこも有るよ
こんな所ではシーケンシャルリードしか出来ないのでバッチ処理的な思想になる。
で現実問題として勘定系ってこれでも十分なんだよね。

877 ：NAME IS NULL：04/12/07 16:54:38 ID:???

>872
　空文字列と NULL は違う。だから ''<>NULL。
……なんだが、そもそも NULL は何と比較しても（NULL 自身とでも）一致しない。
　TRUE/FALSE の二値じゃなくて、TRUE/FALSE/UNKNOWN の三値比較だからなー。

878 ：NAME IS NULL：04/12/07 19:13:24 ID:???

>>877
>>872 はOracleが空文字列とNULLを区別してないってことを言いたいんだと
思うぞ。MSSQLやDB2は区別してるらしい。どっちがANSI準拠なのかってこと
かな。俺にもわからんが、ANSI SQL準拠ってRDBはたくさんあるのにこの
不統一ぶりってなんだろうな。

879 ：859：04/12/07 19:55:33 ID:???

>>873
ジャーナル用のテーブルっていうのはまったく思いつきませんでした。
そういう手もありますね。

>>875
COBOLの時代が長かったから世の中一般の業務的な手順は
COBOL的処理中心に回ってると思いますね。

>>876
>日時データを集計＝＞日報作成＝＞日時集計ファイルへ追加
>で、月次は日時集計ファイルを集計＝＞月報作成＝＞月次集計ファイルへ追加って感じで

まさしくこういう流れです。ISAM的な考えだなあと思います。
さすがにMT使ってるシステムはありません（ｗ

880 ：860：04/12/09 21:52:34 ID:???

>>859
いや、フラグ持つとか以前に行（レコード）に挿入日とか更新日を
保有してないほうが変だと思うなぁ。

それこそ障害時にはどこまで更新されたか解らなくなりません？
データウェアハウスもまったく考慮されてないんだろうな。。
(あっでもDaily200件くらいのトランザクション的なテーブルでしたっけ？)

881 ：859：04/12/10 18:55:45 ID:???

>>880
データウェアハウス何それって？いうぐらいの勢い（ｗ
障害対応は考えてないと思います。

日付の項目も数値8桁で定義されてた・・・

882 ：NAME IS NULL：04/12/10 22:01:20 ID:???

>881
mmddyyyy形式で保存されてたら神

883 ：NAME IS NULL：04/12/11 08:00:23 ID:???

日付時刻（datetime）型しかなくて、年月日だけ格納したい場合は
普通にvarcharやdecimal８桁でとったりしません？

884 ：NAME IS NULL：04/12/11 08:08:05 ID:???

(前略)
受付日 datetime,
受付時刻 datetime,
(後略)

ってなってるテーブルならみたことあるけど。

885 ：NAME IS NULL：04/12/11 19:12:42 ID:N/clY0Mo

>>883
あまり普通ではないと思う。
でもテーブルの項目にdatetime型って使えるようになったのは
ここ10年かそこらじゃなかったかな。
だって俺Oracleで初めて知ったもん。datetime型（ｗ

886 ：NAME IS NULL：04/12/12 19:10:27 ID:esrA43Kc

http://live14.2ch.net/test/read.cgi/liveplus/1102752410/
狂言の挙句、自ら削除依頼を出す。
しかし削除人から怒られ、本スレで個人情報を晒される。

現在高校生の1がスレ埋め立て目論見中

887 ：NAME IS NULL：04/12/12 22:12:14 ID:???

>>885
そういえば昔IBMのメインフレームでDB2使ってたけど
datetime型って無かった気がする。

888 ：NAME IS NULL：04/12/13 10:37:58 ID:???

日付や時刻を表す型はdbmsごとに違いが大きいから比較が難しいが
ansi sqlの分類だとdate, time, timestamp じゃなかったかな。
sybaseやmssqlだとtimestampの名称を別の意味で使っるからdatetimeを
日付時刻をあらわす型として使ってる。
oracleのdate型は日付と時刻の両方を格納できるからtimestamp相当。
date（日付だけ）とtime（時刻および時間）をサポートしてるのは
mysqlとpostgreぐらいじゃないかな。db2は知らないけど。

889 ：NAME IS NULL：04/12/13 23:00:52 ID:???

>>887
datetime型は無いけどdate型はあったよね。
NULLの扱いが面倒なので 0001-01-01 をNULL代わりに使ってたよ。

890 ：NAME IS NULL：04/12/14 10:24:43 ID:???

まあ不要とか言う奴の９９％は、単に自分がきちんとした知識がなく出来ないだけ。

891 ：NAME IS NULL：04/12/14 21:24:43 ID:???

まあ、いきなり不要とか言われても、なんのことかさっぱり。

892 ：NAME IS NULL：04/12/16 22:39:23 ID:MlL2k9FZ

オラクル系のSEは日付項目をDATE型でDB設計するが、
VB/ACCESS系?のSEは、日付項目をCHAR(文字型)でDB設計するヤシが多い。
両者を比較した場合の利点・欠点は？

893 ：名無しさん＠Linuxザウルス：04/12/16 22:53:29 ID:???

＞＞８９２
そんなことしないよ　from Access系

894 ：NAME IS NULL：04/12/16 23:13:13 ID:MlL2k9FZ

>>893　ですよね。。
漏れの逝ってる契約先だけかな・・

895 ：NAME IS NULL：04/12/17 04:08:57 ID:???

OracleもAccess(JET)も日付時刻型しかないから、データに時刻が入ってたせいで
トラぶった経験のあるヤシは文字型使う場合がある。
どういうわけかDATE型に時刻が入ることを知らないおめでたいOracle使いがいる
んだよ。それで >>892 みたいな違いが出るのではないかな。

896 ：NAME IS NULL：04/12/17 04:52:39 ID:???

日付型を長整数型に突っ込めばモウマンタイ

897 ：NAME IS NULL：04/12/17 10:47:41 ID:???

日付を文字型で扱うのはコボラーだと思う。
コボラー系SEが設計するとそういう事は良く有るよね。

898 ：NAME IS NULL：04/12/17 11:03:23 ID:???

日付は演算が無ければ文字列でもいいかなって思うときはある。
演算があったら文字列は論外。

899 ：NAME IS NULL：04/12/17 16:58:17 ID:mRzc/gpV

日付型を扱う関数ってDBMSによってまちまちだからなぁ。
仕事でOracleとSQLServer使うことがおおいけど
CONVERTやらTO_DATEやら。。。。何回使っても覚えられん。
その都度マニュアル参照したり。面倒臭い。
まぁ覚えられない自分が悪いのだが。

900 ：NAME IS NULL：04/12/17 17:04:52 ID:???

CONVERTは確かにめんどい。

901 ：NAME IS NULL：04/12/17 19:40:53 ID:???

大きな会社のしょぼいプロジェクトでno、data1、data2～data50のような感じの
テーブルを作ったことがある。
update,insert,deleteぐらいしか使えない私にはこれが精一杯だった。
むしゃくしゃしてやった。今では反省している。

プロジェクトの規模や工数によってプログラマーがDB設計を兼ねて開発する
といった事は結構あるのではと思いますがDBと偏に言っても奥が深く、簡単にマスター
出来る物ではありません（SQLの文法キモいし構造が基本的に2次元でしっくりこない）。

ここにいる皆さんって次のうちどれに当てはまるのでしょうか？
１，生粋のプログラマー正規化？俺には関係ねえ
２，DB設計者美しいDB設計は俺に任せろ
３，プログラマー兼DB設計者俺を使うと高いぜっ
４，通りすがり

902 ：NAME IS NULL：04/12/17 23:29:17 ID:???

>>898
日付の演算なんて殆どは稼働日ベースなので組み込み関数は使えない罠。

903 ：NAME IS NULL：04/12/18 16:06:52 ID:???

>>901
昔は1つの技術に秀でた技術者（Ｔ字型技術者）が求められてたけど、
今は複数のコトがそこそこ出来る技術者（V字型技術者）の需要が
増えてるんじゃないかな。
低予算で発注されるとおのずとそうなる。
俺はいろいろやってるけど全部中途半端な技術だね。

904 ：NAME IS NULL：04/12/18 17:14:19 ID:???

漏れはW字型技術者

905 ：NAME IS NULL：04/12/18 23:39:41 ID:gz9/hjHm

2点間の距離を管理したいです。。
A点からB点から距離が5kmだった場合、
AとBのレコードに距離５という冗長したデータができますが、問題ないでしょうか？

先輩から言われたのはA点からB点までの距離を管理したい場合、
それぞれの点に座標値を入れて計算で求めるのがスマートらしいのですが
実際の業務ですと座標値のデータ（距離はわかってます）がなく、どうするのがいいのかよくわかりません。
アドバイスおねがいします。

906 ：NAME IS NULL：04/12/19 00:10:58 ID:???

座標データがあるのに距離を保持するなら冗長項目になるけど、それが無いなら冗長じゃないし。
元になる情報が無いならどうしようも無いっしょ。

907 ：NAME IS NULL：04/12/19 00:22:11 ID:???

でも、なんでAとBの２レコード必要なのかと。

908 ：NAME IS NULL：04/12/19 00:29:06 ID:jkkDi30u

もしくは、点テーブルと距離テーブルつくるとか。

909 ：NAME IS NULL：04/12/19 00:34:21 ID:???

その後、顧客の下には、AとBの座標データを新たに入力しなければまともに
稼動しないならないシステムが納品されましたとさ。
めでたしめでたし。

910 ：905：04/12/19 21:02:07 ID:???

回答ありがとうございます。
具体的にいいますと電柱を管理してまして、現在、電柱1本1レコードで設置住所や強度、装着バンドなどを管理してます。
それに今回隣の電柱の距離も追加することになりました。
で、隣の電柱は左右だけでなく３つも４つも関連する電柱がある場合があるので、新たに５つぐらい項目追加すれば
OKなのではと思いました。
ただこの方法だと対象したレコードに追加した場合、関連柱のレコードも更新しないと整合性とれないのでこの方法は
はたしていいのかと疑問に思いました。
で、先輩のアドバイスで座標値いれて計算で距離をだぜばよいといわれたけど、座標値のデータはありません。
てな具合です。

>>908
距離テーブルは例えばAB間の場合
キー１　キー２　　距離
A　　　　　B　　　　５

みたない感じでよろしいでしょうか？

911 ：NAME IS NULL：04/12/19 21:11:58 ID:???

>910
キー１　キー２　　距離
A　　　　　B　　　　５

だと、

B　　　　　A　　　　３

とかいう矛盾するデータを許すことになっちゃうね。
でも、CHECK 制約でキー１＜キー２になるように、常にキー1のほうに小さなIDの電柱が
来るようにするといいかも?

912 ：NAME IS NULL：04/12/19 22:04:44 ID:???

たぶん908が言ってるのは
線分テーブル（IDと距離）と点テーブル(ID)を作って、
繋がりは関連テーブル(線分IDと点ID)で表現するって事じゃないかと

913 ：912：04/12/19 22:23:48 ID:???

ごめん912は忘れて下さい…orz

914 ：NAME IS NULL：04/12/19 23:27:31 ID:???

>910
座標うんちゃらって事はGIS絡み？

>新たに５つぐらい項目追加すれば
5つより多く追加するとテーブルレイアウト変更しなきゃならん。

915 ：NAME IS NULL：04/12/20 01:49:36 ID:???

東京○力かよ

916 ：NAME IS NULL：04/12/20 04:40:17 ID:???

関●工じゃね？

917 ：NAME IS NULL：04/12/20 07:02:18 ID:???

Ｎ○Ｔだろ

918 ：NAME IS NULL：04/12/20 12:22:52 ID:???

仮に座標があったとしても「計算で求める」がスマートかどうかは要件しだいです。
距離１０ｍ以上を一覧せよといった処理を頻繁に実行するようなら距離をそのまま持っ
ておくべきで、距離と座標の整合性はアプリ側で管理すべきものでしょう。
キー１＞キー２のようなルールを作れば１件ですみますけど単純に結合できなくなる
ので、頻繁に距離情報を使うなら２件のままでいいと思います。
電線に関する情報が距離以外にもいろいろあるようなら、電柱テーブル、電線テーブル、
電柱電線関連テーブルと３種類持つことになりますが、この場合も電柱電線関連テー
ブルのレコードは方向ごとに重複して持つのが一般的です。

919 ：NAME IS NULL：04/12/21 01:40:56 ID:t+L2RHKl

VIEWをつかったらどう？

920 ：NAME IS NULL：04/12/21 08:08:40 ID:???

VIEWは記述を簡素化するだけで解決にはならない。

921 ：NAME IS NULL：04/12/21 08:17:10 ID:???

CREATE VIEW V_DISTANCE AS (キー１,キー2,距離)
SELECT キー１,キー2,距離 FROM DISTANCE
UNION
SELECT キー2,キー1,距離 FROM DISTANCE

922 ：NAME IS NULL：04/12/21 11:09:41 ID:???

電柱マスタ：
電柱ID,座標(null許可)

距離テーブル：
電柱1ID,電柱2ID,距離

更新時あるいは随時、電柱1ID,電柱2IDの座標をチェックし、
双方に座標があった場合に距離を計算し、
距離テーブルと大きく矛盾したら警告フラグを出す。

でよさそうな。

923 ：NAME IS NULL：04/12/21 11:13:06 ID:???

単純に、２点によって必ず距離が計算として出るならば、もたない。
そうじゃなく、人系が入力しないと距離ってのが決まらないのであれば、もつ。

924 ：NAME IS NULL：04/12/21 11:16:30 ID:???

>910 名前：905[sage] 投稿日：04/12/19(日) 21:02:07 ID:???
>
>で、先輩のアドバイスで座標値いれて計算で距離をだぜばよいといわれたけど、座標値のデータはありません。
>てな具合です。

てことだから距離よりも座標のほうが決まらないっぽいよ？

925 ：NAME IS NULL：04/12/21 12:59:21 ID:???

テーブル的には>>922さんのでよさそう。
座標っていうか、電柱ＩＤと、それぞれのリレーション表現だけでＯＫそうですね。

距離っていうのが単純な直線距離のみなのか、それとも電線を張る上での実質距離なのかわからないけど、
計算項目じゃなく、人が入力する項目っぽいですね。

926 ：NAME IS NULL：04/12/21 18:08:26 ID:mbUoXkUJ

>>925
現状の業務で距離を入力（記録）させてるんじゃないかな。
座標ってのは経度とか緯度になるのか？
あんま詳しくないけど今のＧＰＳって精度どんぐらいなんだろうか。
誤差が大きくて実用にならねぇような気がするです。

927 ：NAME IS NULL：04/12/21 18:09:30 ID:???

あげてもうた、、、

928 ：美香 ◆RQ0Spv3q06 ：04/12/21 18:11:29 ID:kPbEUVj4

☆ヽ(o_ _)oﾎﾟﾃｯ

929 ：NAME IS NULL：04/12/21 19:35:49 ID:???

>926
製品にもよるけど10m以下くらいだったはず。
普通の電波状態なら道路1本外れる事はないくらいだよ。
カーナビみたいに補正がかかるともっと正確。
電柱みたいなものを管理する時は、正確な図面データを使ってれば問題無いっす。

930 ：NAME IS NULL：04/12/26 01:50:49 ID:???

このスレはすげーためになるぜ

931 ：NAME IS NULL：04/12/26 02:10:48 ID:???

このオレはすげーだめになるぜ

932 ：NAME IS NULL：04/12/26 23:50:50 ID:???

この乙女はすげータマになるぜ

933 ：NAME IS NULL：04/12/27 01:40:44 ID:???

>>932
残念！
ttp://220.111.244.199/otakara/1223idol02.jpg

934 ：NAME IS NULL：04/12/27 07:34:21 ID:???

ぽんぽ痛い

935 ：NAME IS NULL：04/12/28 23:29:41 ID:???

おう！ＤＢＡ諸君。年末年始は出勤かい？それはソレで乙カレー。

936 ：【ぴょん吉】【59円】 !：05/01/01 15:50:53 ID:???

testtest

937 ：NAME IS NULL：05/01/11 12:54:17 ID:???

中華：哈…　哈…
鍛冶屋：なに？　その炭くれるのか？
中華：哈…　哈…
鍛冶屋：その炭くれるのか？

ごっくん。

938 ：NAME IS NULL：05/01/11 12:55:38 ID:???

激しく誤爆っｗ

939 ：NAME IS NULL：05/01/13 00:08:40 ID:???

>>937
なんかのネトゲかなぁ。あっちの世界もオフショア市場が広がってるもんね。

940 ：NAME IS NULL：05/01/13 16:14:49 ID:q8L8KnWz

曜日とか数が普遍的なものはどうすべき？
たとえば、ある会員の曜日毎の来店回数とか

1.会員No、日、月、・・・、土
2.会員No.、曜日区分、来店回数

1.で問題なさそうだけど、あとから祝日は別に集計して
といわれたら、2.じゃないとテーブル構造変わってしまうし．．．

941 ：NAME IS NULL：05/01/13 16:18:40 ID:???

来店テーブルの曜日カラム(来店日カラムから導出か？）つかってVIEWつくれば？

942 ：NAME IS NULL：05/01/13 21:00:20 ID:???

3.会員No.、2005年1月1日土曜日、2005年1月2日日曜日、2005年1月3日月曜日、...

これでおｋ

943 ：NAME IS NULL：05/01/14 10:05:00 ID:???

曜日ってのは計算結果になるから、持つ必要ないんじゃないの？
ＯＲＡＣＬＥならＴＯ＿ＣＨＡＲで出せるし、他のＤＢＭＳでも大体はある。
ないなら自作しても十分だし。（基準日からの通算日数を割った余りで曜日は出せる）

944 ：NAME IS NULL：05/01/15 08:43:48 ID:???

>>940とは別人ですが

　年月日さえあれば曜日は後から計算できますが、祝日はどうするのが定石
なんでしょうか？
　春分の日、秋分の日、ハッピーマンデー適用のものなど、毎年、日付が
変わるものについてですが。

　過去の祝日を記録し続けるテーブルを用意するのが、良いのでしょうか。

945 ：NAME IS NULL：05/01/15 11:18:57 ID:???

>>944
俺が以前にかかわったシステムはそうだった。
過去も未来もテーブルに持ってた。

946 ：NAME IS NULL：05/01/15 13:35:37 ID:???

祝日のルール自体がコロコロかわるからどうにもならんね

947 ：944：05/01/15 20:53:09 ID:???

>>945, >>946
やはり、そんなところでしょうか。
ありがとうございます。

948 ：NAME IS NULL：05/01/15 21:31:23 ID:???

正規化以前の話だな。

949 ：NAME IS NULL：05/01/16 14:11:20 ID:???

カレンダーテーブル持ってるねうちは

950 ：NAME IS NULL：05/01/17 09:20:23 ID:???

941に便乗

来場集計のようなサマリデータなら曜日は計算結果になるけど
マスタデータならどうします？
例えば、曜日別の担当者とか．．．

951 ：NAME IS NULL：05/01/17 09:33:36 ID:???

・・・便乗にもなってないし、正規化の話にもなってなくて、ただマスターテーブル作れば？としかいいようが。

952 ：NAME IS NULL：05/02/05 00:39:53 ID:???

今のPJがまさに
ttp://www.atmarkit.co.jp/farc/rensai/heaven03/heaven03a.html
このアットマークITの状態

上の話よりもっとヒドイ状態、
お客もCOBOLを何十年としてきた人だから
収集つかず。
Oracleなのにテーブル結合できないで
Listを使って、プログラム内で結合してます。

(#゜Д゜) ＜「定義書に書いてなくてもデフォルト値はNULLに決まってるでしょ！」

953 ：NAME IS NULL：05/02/07 14:26:08 ID:???

>952
951はテーブル構造を
「hogeコード,日曜日担当者名,月曜日担当者名．．．．」にするか、
「hogeコード,曜日区分、担当者名」にするか聞いているのではないのか？

954 ：NAME IS NULL：05/02/07 20:47:32 ID:???

>>933
漏れ：「お兄さんはゾウさんの方が好きだよ！」
漏れ：「もちろん、股間についてるゾウさんの方がね！　(･∀･)ｹﾞﾍﾗﾍﾗ」

955 ：954：05/02/07 20:48:16 ID:???

漏れがゾウさんを好きでどうするんだよ・・・・
orz

956 ：NAME IS NULL：05/02/16 08:43:42 ID:???

部分関数従属と推移関数従属の意味と違いがワカランのでつが、
だれか分かりやすく解説して頂けませんでしょか？

957 ：NAME IS NULL：05/02/16 12:20:03 ID:???

http://66.102.7.104/search?q=cache:C9kyKoPF7KgJ:www.techscore.com/tech/sql/16_02.html+%E9%83%A8%E5%88%86%E9%96%A2%E6%95%B0%E5%BE%93%E5%B1%9E+%E6%8E%A8%E7%A7%BB%E9%96%A2%E6%95%B0%E5%BE%93%E5%B1%9E&hl=ja&start=3&lr=lang_ja

958 ：NAME IS NULL：05/02/17 08:58:09 ID:???

なるほど…
このサイトいいね

959 ：NAME IS NULL：05/03/08 15:32:12 ID:7EzAYhEF

どんなモデルであっても，第5正規形まではキッチリやるべき？

960 ：NAME IS NULL：05/03/08 16:45:23 ID:???

キッチリやった後、実用レベルまで崩すのが理想。
普通は実用レベルでやめちゃうけどキッチリやりたいね。
設計にもっと工数と予算を。

961 ：NAME IS NULL：05/03/08 23:58:07 ID:???

４と５のケースにであったことがないYO

962 ：NAME IS NULL：05/03/09 00:46:03 ID:???

顧客コードとか、その手の項目って文字列と数値と
どっちで持つ?

963 ：NAME IS NULL：05/03/09 07:51:07 ID:???

>>962
文字だな。
理由は文字なら数字も入るが逆はできないから。

964 ：NAME IS NULL：05/03/09 09:43:06 ID:???

工夫次第じゃないか？
最終的なキーは文字列でよいと思う。

ただ、それの構成要素が　固定文字＋日付＋連番　みたいな場合は、
キーとは別にそれらのフィールドも持ってたほうが、あとの検索のつくりが楽になる場合はある。

965 ：NAME IS NULL：05/03/09 15:27:10 ID:???

>>962
利用者の目に触れるコードや直接使わせるコードは文字で、
システムの中だけで使うコードは数値を使ってる。
>>964
COBOLからそのまま移植したテーブルだとそういうのの山になってるよ。

966 ：NAME IS NULL：05/03/09 15:59:25 ID:???

>>965
別にコボルなわけじゃ無いんだが。
キーの構成要素事態もデータの属性ならば、キーとは別に当然持つべきと書いただけ。
キーにあるから端折って持たない場合、キーを分解して日とか出さないといけないから。

967 ：NAME IS NULL：05/03/20 21:18:17 ID:???

>>952
＞「定義書に書いてなくてもデフォルト値はNULLに決まってるでしょ！」

それ主キーなんですが、ということが過去に

968 ：NAME IS NULL：2005/03/27(日) 12:13:02 ID:yy2hD2dw

最近静かですね。ちょっと質問させてください。

例えば、

伝票マスタ「出荷元、伝票番号、項目1、項目2、…」
主キー：出荷元、伝票番号

伝票データ「出荷元、伝票番号、商品、項目A、項目B、…」
主キー：出荷元、伝票番号、商品

伝票マスタ (1)-(n)伝票データ
「出荷元、伝票番号」で紐付け

と表現できるテーブルがあったときに、

伝票マスタ「CODE1、出荷元、伝票番号、項目1、項目2、…」
主キー：CODE1(システムで自動採番)
ユニーク制約：出荷元、伝票番号

伝票データ「CODE2、CODE1、商品、項目A、項目B、…」
主キー：CODE2(システムで自動採番)
ユニーク制約：CODE1、商品

伝票マスタ (1)-(n)伝票データ
「CODE1」で紐付け

というような実装にするのって普通にOKですか? JavaからHibernate使って
読み書きしようとすると、キーが複合キーだと扱いにくいので、下のように
したいのですが、このDBを別システムからも読み書きする場合に、別システム
担当者から、「なんでこんなバカなことしてんだ、ゴルァ」って思われますかね?

969 ：NAME IS NULL：2005/03/27(日) 14:01:59 ID:???

むしろそうしないと(ﾟДﾟ)ｺﾞﾙｧ!!

970 ：NAME IS NULL：2005/03/27(日) 19:12:33 ID:???

Hibernate別にしても代理キー使うほうが何かと利点は多い

971 ：968：2005/03/27(日) 20:54:01 ID:???

>>969 >>970 レスありがとうございます。別にHibernate
だからとかでなく、こうするのは普通のことなんですね。

今まで関わったプロジェクトは、全部複合キーなテーブル。
今回、初めて小規模ながらDB設計から何から任されたので、
Hibernateの使用を検討していたところでした。試しに小物の
サンプルをいくつか書いてみて、複合キーよりも単独のキーの
方が扱いやすいというところまでは分かりました。多分この方針で
いいのだろうとは思ったのですが、実戦を経験している先輩方の
意見を聞けてさらに安心しました。これで安心して理論武装できます（`・ω・´)

あ、もちろん「だって２ちゃんでもこれでいいって言われたもーん」
などイタいことを言うという意味ではないです(w

972 ：NAME IS NULL：2005/03/27(日) 21:13:32 ID:???

出荷データに出荷元がないから一覧とか出したいときに毎回結合せにゃいかんね。
関係ないけど「同一商品が入力できんぞ、ｺﾞﾙｧ」ってクレームがきそう。

973 ：NAME IS NULL：2005/03/27(日) 21:39:08 ID:???

自然キーなんぞシステムから見りゃ「いま現在たまたまユニークである」程度のモノだから、
いつ何時（下手すると今のシステム作ってる最中）「再注文は既存伝票番号＋枝番で～」とか言われるか分かったもんじゃないし

974 ：968：2005/03/27(日) 21:49:49 ID:???

>>972 ご意見ありがとうございます。
確かに、一覧出すときは必ず結合です。かといって、CODE1で
外部キーを張っておきながら伝票データに出荷元を持つってのも
なんか冗長だし、マスタの出荷元を変更した時に全データの出荷元を
書き換えたりってのもイヤだし、万が一CODE1で結合したマスタの
出荷元とデータの出荷元が一致しないなんて事態が発生したときの
こと考えると、この方がいいかなと考えました。

ちなみに、同一伝票内の同一商品については、必ず集約して1レコードに
するというルールなので、そこはアプリでカバーするです。

975 ：NAME IS NULL：皇紀2665/04/01(金) 00:29:16 ID:???

ばかやろー、RDBMS使ってるのにテーブル丸ごと持ってきてクライアントの味噌で
マッチングするロジックやカラム内にカンマ区切りの値があるとかの索引順編成ファイルでも
扱うような珍妙なテーブル構造でできてるんだ!!SQLでサーバサイドで処理できるよう
書き直してやろうにも非正規形のテーブルがちらほらあって修正出来ねぇよ!!

976 ：NAME IS NULL：2005/04/08(金) 18:52:20 ID:???

警察官僚！パチンコ業界へ天下り！恥を知れ！
http://society3.2ch.net/test/read.cgi/police/1109699316/