何故データベース設計は軽視されるのか？

**NAME IS NULL** · 2008/12/01(月) 01:07:27

何故データベース設計は軽視されるのか？

ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。

業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？

にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。

みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。

**NAME IS NULL** · 2008/12/01(月) 01:09:40

ここでいうデータベース設計とは、テーブルレイアウトを決める作業を指し、
データベースとは、リレーショナルデータベースを指しています。

**NAME IS NULL** · 2008/12/02(火) 01:24:11

プログラムのデザインも、正規化も知らない奴がSEを名乗ってるからだろ。
驚くぐらい何も知らない。

**NAME IS NULL** · 2008/12/04(木) 15:02:51

むしろDBの設計でPGが大きく変わって組みやすくなる可能性もあるというのに・・・・
確かに>>3の言う通りだと思う

**NAME IS NULL** · 2008/12/04(木) 21:48:53

ERDのこと？

**NAME IS NULL** · 2008/12/04(木) 22:10:28

とりあえず今保守してるシステムのテーブル名とカラム名に
日本語を使ってるのやめさせたい。それからコボラーの薫陶を
受けたVBA使いの作ったシステムを全て作り直したい。

**NAME IS NULL** · 2008/12/05(金) 08:38:19

動きゃいい、と思ってるからですかね。

**NAME IS NULL** · 2008/12/05(金) 23:36:44

>>7
動けばいいとすら思ってない。

作って納品しちまえばおｋと思ってるw

**NAME IS NULL** · 2008/12/08(月) 09:10:39

納品時のテストデータでかろうじて動作はするものの
本運用に入ったら誤作動しまくり落ちまくりってのはもう
狙ってそう組んでるとしか思えなくなってきた・・・

**NAME IS NULL** · 2008/12/09(火) 09:24:10

いまだに綱渡り的な設計とかが存在してるのな(；´∀｀)

**NAME IS NULL** · 2008/12/09(火) 20:00:03

いまだに「テーブル名・カラム名は全てID制です！」ってとこもあるからな。
IDが何なのかってのを記憶してる人間が技術力高いつて重宝されとる……

**NAME IS NULL** · 2008/12/10(水) 04:46:06

そろそろ今のPJが終わるので今度入る予定のPJチームに挨拶行った。
若手のSEがDB設計中だったので覗いたら、テーブル名・カラム名を日本語で書いてる・・・
んで、それはやめようよと言ったら、マニュアルのどこにダメって書いてあるんですか！日本語は使えるはずですよね！
と言われたので、その場でPJから外してもらうよう上司に頼みに行った。

送り仮名で嵌るんだよ・・・

**NAME IS NULL** · 2008/12/10(水) 09:36:26

SYOHIN
SHOHIN
SHOUHIN

前任のアフォが設計したDBでこれらが混在してたから
全部「商品」で統一して新規で作り直す仕事何べんもやってるw

**NAME IS NULL** · 2008/12/10(水) 20:38:31

ど素人でＤＢに興味あるものですが、
このスレ読んでおれもＤＢ設計してみようかなと思った

**NAME IS NULL** · 2008/12/11(木) 01:23:12

つうかね会社の方針が変わったり条例が変わったり法律が変わったりするたびに変更しなきゃならないシステムもたくさんあるわけよ
そのたびに一から作ってたら間に合わんし客も予算出せないでしょ
実稼働中の物を今日まではこれ、でも明日からはこのシステムで
なんて無茶な用件はたくさんある
だからある程度の遊びフィールド作ったり妙な拡張して過去の残骸が残ってたりする物が出来てくるわけ
それを最初見た奴にとっては謎いシステムかもしれないけどさ
簡単に言うとガチガチに設計すると馬鹿を見る事も多いんだよ

**NAME IS NULL** · 2008/12/11(木) 01:34:09

>>15
コボラ？

**NAME IS NULL** · 2008/12/11(木) 05:04:21

>>1
データベース屋がまともな仕事をしないからだろ。
>>3のような技術力の不足、利用シーンを考えない独り善がりな設計など。
むやみに正規化してりゃいいってもんじゃないし。

**NAME IS NULL** · 2008/12/11(木) 14:30:58

とりあえず
2008/11/12

を画面上でH.20.11.12
とかで表現するのはいいけど
DBにまで
H.20.11.12
として保存する仕様は勘弁してください。

**NAME IS NULL** · 2008/12/11(木) 22:15:44

>>18
そんなのまだまし。
3601112←これ昭和60年な
3201112←これ平成20年な
4011112←これ西暦2001年な

和暦は3で西暦は4な。

**NAME IS NULL** · 2008/12/12(金) 00:02:36

>>19
平成22年とベビーブームが始まる昭和22年はバッティングしないのでせうか( ﾟдﾟ)

**NAME IS NULL** · 2008/12/12(金) 09:51:04

>>20
生年月日とかでなければバッティングしないんじゃない？
それにしても、その仕様は無いなw

**NAME IS NULL** · 2008/12/12(金) 09:58:47

そういえば、社会保険庁が提供している申請用ソフトも
データが和暦格納で使いにくいな。

スレとは関係ないけど、そいつが吐き出すCSVはクォーテーションが付いてないので
うっかりExcelなんかで開くと、コードの頭のゼロが取れていたりする糞仕様。(0001→1)

**NAME IS NULL** · 2008/12/12(金) 12:18:20

>>22
心配するな。「"」付きでもExcelはゼロサプレスしてくれるよ。
んで、うっかりExcelで開いて保存しちゃったCSVを本番に突っ込んじゃった
アホがいたもんだから、マスタが一切引けなくなってえらい目にあった。
…DB設計の問題じゃないけど。

**NAME IS NULL** · 2008/12/12(金) 22:23:04

>>20
バッティングする。しかし詳細はばれるので明かせないが、３０年の期限が
管理できればいいので、生きてるデータは最古でも1978年。
死んでるデータはもうグダグダ。ゴミ。

**NAME IS NULL** · 2008/12/13(土) 13:01:20

>>22
可能です。
以上。
↓次どうぞ

**NAME IS NULL** · 2008/12/13(土) 13:45:18

>>1
経営者や管理職や客は、目に見えるものしか評価できないから、
DB屋よりもJava屋の意見を聞く。
↓
Java屋は、O/Rマッパを使いまくって、DBをオブジェクトの永続化ストレージ
としか考えない。DB設計？なにそれ？おいしいの？
↓
それでも動く。
↓
Java屋
「ほら見ろ、俺のやり方が正しい」
「DB屋の言うことなんか聞いてたら開発おわんねw」
↓
数年後： DBあぼ(ry
↓
開発当時の人間いない。だれのせいか分からない。
DBがダメになったから、DB屋が悪かったに違いないという判断。
↓
DB屋、ますます発言力低下。
↓
以下、ループ。

**NAME IS NULL** · 2008/12/14(日) 12:59:31

DB屋が論理設計途中でトンズラされたPJ。
既に実装スタートしてたから皆でオンデマンドでDB設計やってたぜw

**NAME IS NULL** · 2008/12/15(月) 09:48:21

>>19
明治は１，大正は２，昭和は３，西暦は４，
てなのを大昔にコボルさんが組んでて、
昭和天皇の崩御で困った困ったって話？

**NAME IS NULL** · 2008/12/15(月) 10:16:58

>>19
つっか、マジな話、
今の天皇が幾久しく健康でありますようにと、お祈りする必要があるね。

**NAME IS NULL** · 2008/12/17(水) 10:16:13

>>28
まさに文系乙の、非論理的な設計ですね。
文系の声がでかいのも、論理的な正しい設計が軽視される原因と見た。

**NAME IS NULL** · 2008/12/17(水) 19:46:04

>>30
文系とか関係ないだろ。見通しの甘さが全ての原因だ。
ようするにバカなんだよ。

**NAME IS NULL** · 2008/12/17(水) 20:52:39

ＳＥの机にデーターベース入門とか並んでて吹いた

**NAME IS NULL** · 2008/12/18(木) 00:42:35

まあ、たしかにＤＢ屋の地位とかは低いよな。。

俺は運用側なので、開発側が主催する
システムリリースの打ち合わせに呼ばれる。

開発側の説明を受けた後で、運用上、設計上の問題をあげ、
改定を提案すると、いつも返答はこれだ。

「リリースしないと業務に支障がでる！」

だったら、システム設計のころから打ち合わせに呼べよ。
割を食うのはいつもこっちだ。

すまん、愚痴った。

1 · 2008/12/18(木) 00:42:43

年月日を和暦で格納するとか、
カラム名が日本語や日本語をローマ字にしたものであるとか、
運用を続けていくうえで仕様変更が続き過去の残骸データが残っているとか、
このあたりはもうしょうがないというか、諦めています。
我慢できます。

問題にしたいのは、論理性（純粋な意味での設計）です。
例えば1対nの関係にある情報を2テーブルに格納すべきところを
1側の情報を多側にn個格納したり、
候補キーが不十分で対象のレコードを特定できないケースがあるテーブルがあったり、
日々追加削除が発生するテーブルが第3正規形になっていなかったり、
（ケースバイケースがあることは承知しています）
こういった問題のほうがデスマーチに陥りやすいと思います。

で、デスマーチに陥ったら陥ったで何故かプログラムで対応しようとする。
設計に立ち戻らないんですね。ここが問題だと思っています。

**NAME IS NULL** · 2008/12/18(木) 14:25:33

建築に例えれば、DBとかネットワークは土台、地盤にあたる部分だよね。
それが緩い、いい加減なところの上でシステムを構築することが、
いかにリスクが高いか、判らないのかねぇ。
判らないんだろうなぁ。
システムは目に見えないからねぇ。

**NAME IS NULL** · 2008/12/19(金) 07:52:58

この板には最近来るようになった新参者ですが
このスレは書き込み少ないけど非常に参考になります。

**NAME IS NULL** · 2008/12/25(木) 09:38:42

稼働システムでDB設計がおかしくてPGで何とかしようとするのはいい
もう稼働してしまっているから大きな改造などは怖いので出来るだけやりたくないという理由

でも・・・なんであいつ等それを教訓にして次の土台の硬め方を変えようとしないのか
同じような設計して同じようなトラブル産んで・・・・

追伸
正規化とかもやりすぎは使いにくさにつながるかもしれないけど、適度な正規化くらいかけてください。

**NAME IS NULL** · 2008/12/25(木) 18:39:06

今は昔よりサクサク作れるんでしょ？
ＤＢも使い捨ての時代じゃないの？

**NAME IS NULL** · 2008/12/25(木) 21:37:48

アプリケーションはサクサクと使い捨てられることも多いけど、
DBは後々、受け継がれて残っていくからなぁ。
アプリケーションの進化に比べると、SQLやRDBの進化は遅いしね。

っていうか全角でＤＢ www

**NAME IS NULL** · 2008/12/27(土) 00:32:30

遅いかねえ
最新のDBの機能なんて誰も使いこなしてねーじゃねーか

**NAME IS NULL** · 2008/12/27(土) 01:02:18

昔IBMの博士がRDBの基礎理論を発表してから、常に進歩・進化していると思うが。
OracleやDB2なんかは使いこなしている奴の方が極レアだろうに。

**NAME IS NULL** · 2008/12/27(土) 02:11:29

RDBMSの実装自体は猛烈な勢いで進化していますが、
スキーマ設計手法やクエリ言語に関しては案外ゆっくりと
しているのではないかと。

SQL92以降の拡張って実際どの程度使われていますか？

**NAME IS NULL** · 2008/12/27(土) 03:50:52

LINQがどうなるのかってところか。＞クエリ拡張

あとは、ORマッピングの活用とかそっちも全然進んでなくね？＞特に日本

**NAME IS NULL** · 2008/12/27(土) 08:06:29

xml関係の拡張(?)も凄いと思うし、モバイル対応とか、組み込みとか
あれこれ頑張っていると感じる。

**NAME IS NULL** · 2008/12/27(土) 08:52:24

>>43
O/Rマッピングにそんなに価値を感じてるのですか？
流行に踊らされていませんか？

**NAME IS NULL** · 2008/12/27(土) 09:23:03

そりゃまあ、COBOLerには縁がないから、価値を感じないだろうなぁ。

**NAME IS NULL** · 2008/12/27(土) 10:59:58

COBOLは全然分からないが、DB設計の立場で見ると、
O/Rマッパには、
DB「設計」不要の簡易システムなら画面プログラマだけで作れる、
という以上の価値は感じられない。

**NAME IS NULL** · 2008/12/27(土) 13:56:21

ポトペタな画面アプリ作る時には実際、O/Rマッパって必須だと思うけど。
簡単なものが簡単に作れるのは実際ありがたいし。

ちなみにDB設計不要ってくだりはｲﾐﾌﾒｲだな。

そりゃＤＢ設計者と思い込んでいる運用チームの人間が言っているなら
なんとなくわかるが。ｗ

**NAME IS NULL** · 2008/12/28(日) 04:56:16

不要ってことは無いけど、重要視されてないのは事実。
糞なテーブル設計でも、一応動くし、速度も糞高い鯖でも買えば力技で何とかなるのも事実。

PGの学習能力は、そもそも糞なPGなのか、予算的問題で優秀なPGが確保できてないのか、営業的問題で長期運用を前提として無いとかだろう。
営業的には４年程度なんとか動いて、定期的に新しいシステムに更新してもらうのが儲かる。データ移行という名目でぼろ儲けしているのをわざわざ無くす必要は無いし。

運用ならもうちょっと強く逝ってもいいと思うぞ。開発の尻拭いも大変だろうし。
そのままリリースしてしまうと業務に支障がでる！
と強く逝ってやれ。実際、業務に支障が出るのは毎度の事だし。

ある程度汎用的に使おうとすると、結局は最新機能は使わずに終わってしまう事が多い。
このアプリケーションでは対応して無いとかで最大公約数的に使える機能が絞られて行く。

**NAME IS NULL** · 2008/12/28(日) 07:46:38

むしろテーブル設計よりも、糞クエリを書く奴をなんとかして欲しい
SELECT一文で数KBとか馬鹿もいいとこ
このマシン遅いとか、冗談きついわ
アプリで処理すべきことをDBにやらせて遅くしてるのはお前だ

**NAME IS NULL** · 2008/12/29(月) 02:43:23

俺の経験だとSQLで出来ることを
アプリにやらせて遅くしてるやつの方が多い。
とても遅くなって困る。

**NAME IS NULL** · 2008/12/29(月) 17:57:30

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

**NAME IS NULL** · 2008/12/30(火) 04:17:20

>>52
なつかしいなそれ。割引金額をアプリで持ってるから
割引率変更になった時点で過去売り上げの改ざんになるのな。

揚げ足取りはさておき、ドメインロジックはまだいいんだけど
クロス集計とか頑張ってやってたのを見てびっくりした事ありますよ。

**NAME IS NULL** · 2008/12/30(火) 18:59:03

クロス集計って、アプリ側、DB側、どちらで頑張っていたのでしょうか？
今はSQL/OLAPが使えるようになってきて随分楽ですね。

**NAME IS NULL** · 2009/01/02(金) 13:44:40

>>51
テーブル設計がよろしくなくて、アプリ側でエラい苦労させられたことがある。
SQL書けねえやつに設計させるなと。

1 · 2009/01/04(日) 02:15:37

テーブル設計が問題なのか、
SQLが問題なのか、
アプリが問題なのか…についてですが、

結論からいって、全てにおいてまずテーブル設計の問題だと思います。
理由はそれが土台だからです。

テーブル設計がおかしいという理由で、
おかしなSQLを書かざるを得ない状況に陥ることは多々あるし、
テーブル設計がおかしいから、
アプリでおかしな制御をせざるを得なくなったりするんです。

それと、「正規化もやりすぎると使いづらくなる」などという意見がありましたが、
自分は何があっても、どんなシステムあっても、どんな利用用途であっても
RDBでデータを管理する以上、必ず全てを第三正規形まで落とす必要があると思います。
正しくはその正規系を業務や仕様にあわせて（敢えて）「崩す」のです。
だから「正規化はしないほうがいい場合もある」というのは語弊があります。
正しくは「正規化は必ずしなければならない。その上で（状況に応じて）崩すことは構わない」
ということです。

**NAME IS NULL** · 2009/01/04(日) 08:45:00

モバオクみたいに１人のスーパーエンジニアに全部ヤらせればいいんだよ。
要件定義から設計～実装～テストまで自前でやればドコがおかしいか
自分で気がつくだろうに。

時々、老害が自分の立場を守るためにくだらねぇ自己主張
しまくるから、設計がグダグダになっていくケースがあるしなぁ。

**NAME IS NULL** · 2009/01/05(月) 21:02:37

一人はそいつが飛んだら終わりだけどな。
二人一組ぐらいにはするべき。

**NAME IS NULL** · 2009/01/06(火) 03:30:29

さらっと「飛んだら」と書かれてちょっとビクっとした。
「意識が途切れる」「遠いところに逃げる」「宙を舞う」。含意は色々ですが。

**NAME IS NULL** · 2009/01/07(水) 01:26:04

「レコード数が少ないから主キーはいらない」
と真顔でのたまう、うちのSE。。。

**NAME IS NULL** · 2009/01/07(水) 21:14:01

>>59
飛ぶっていうのは逃げるとか逃亡するとか辞めるとかの意味。

**NAME IS NULL** · 2009/01/07(水) 22:49:47

まず、Tか島平団地で飛ぶとか、そっちを考えたわｗ

**NAME IS NULL** · 2009/01/11(日) 12:18:16

全てのテーブルが外部結合を必要なく設計されてるシステムってある？
あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
で判定するのはRDBとしては誤っていると思うんだけど。

RDB設計をまともにやればシステムの便利さは格段に向上するのは間違いない
システムへの要求も高度化するだろう。RDB設計をまともにしない人には
低度な要求を解決する仕事を続けるためにRDB設計を軽視し続ける
べきだ、保身のために。

日本は現場の国だ。現場以外は糞。そしてシステムに関する決定権は
現場には無い。使う側の現場力と開発する側の現場力が糞によって
互いに相反する方向へ注力させられている。まったく無駄なことよ。

**NAME IS NULL** · 2009/01/12(月) 02:57:32

http://www.google.co.jp/search?q=result+site%3Acerema.co.jp

設計を軽視するとこうなる

**NAME IS NULL** · 2009/01/12(月) 10:22:11

>全てのテーブルが外部結合を必要なく設計されてるシステムってある？
>あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
>で判定するのはRDBとしては誤っていると思うんだけど。

RDBでないDBはそうするしかないと思うが。
RDBでそうしているオマエの現場が糞と言うなら「そうだろうな」としかいい様がないわけだが。

「システムに関する決定権は現場には無い」ってオマエがオペレーターみたいな
現場といっても最底辺だとないだろうとは思うが、普通の開発現場なら
あからさまにイカれている設計なんかはレビューや評価で却下すればいいんじゃねーか？

**NAME IS NULL** · 2009/01/12(月) 11:47:45

>>65
そのレビューとやらに呼ばれないｗ

**NAME IS NULL** · 2009/01/12(月) 17:55:09

Oracleで対象非対象をレコードが有るか無いかで設計してあるのはやっぱ間違いだよね。
Oracleやってる奴も汎用機COBOLで経験つんだエンジニアばっか。COBOL流のシステム
設計をむりやりOracleに載せてる。それが常識で考えた標準らしいですよ。何も言えねえ。

**NAME IS NULL** · 2009/01/12(月) 18:43:00

>対象非対象をレコードが有るか無いかで設計してある
こいつはどういう状態のことだ？
つうか、>67はどんな対案が正論だと言いたいんだ？

**NAME IS NULL** · 2009/01/12(月) 19:02:10

ジョインされる２つのテーブルのキーが1:nになっているべきか1,0:nを前提に設計するかって話だよ

**NAME IS NULL** · 2009/01/12(月) 20:12:57

んーっと
1:n設計は間違いだっていう主張？

**NAME IS NULL** · 2009/01/13(火) 00:00:54

>>64
ひどいｗ
これは損害請求レベルじゃないのか

**NAME IS NULL** · 2009/01/15(木) 03:02:24

ちがう、1:nを守るためにマスタにレコード追加しようとしたら引かれたの。意味無いとか言われて。

**NAME IS NULL** · 2009/01/15(木) 07:27:58

**NAME IS NULL** · 2009/01/15(木) 07:30:37

あー頭死んでた。

レコード番号 | 対象フラグ
---------------------------
1　　　　　　　　| 対象
2　　　　　　　　| 非対象
3　　　　　　　　| 対象
※フラグ見て対象かどうか判断

or

レコード番号
-----------
1　　　　　　　　
3　　　　　　　　
※レコードの存在の有無で対象かどうか判断

の違いって事？

**NAME IS NULL** · 2009/01/15(木) 08:30:46

>>72
どういう状況でどんなテーブルに何をしようとしたのか端的に説明してくれ。
とにかく状況が小出しじゃ何も判断できん。

**NAME IS NULL** · 2009/01/16(金) 00:24:21

>>72
あと、「引く」という言葉の意味が分かりません。

**NAME IS NULL** · 2009/01/16(金) 03:48:45

はぁ？
ひくわ

**NAME IS NULL** · 2009/01/16(金) 06:15:57

>>63
なにか、ＲＤＢがあるからデータ入れよう的な考え方に聞こえるぞ
まったく結合するものがないなら、「Ｒ」ＤＢである必要はないわな

レコードがあるかないかで判断するか、（結合された）レコードに書かれてる内容で判断するかは、
それがどういった情報を格納してるかで決定するべきで、ＲＤＢなのだから
必要ない結合先のレコード（や、もしかするとそのテーブルそのものも）を作らないといけないということはないだろう

>そしてシステムに関する決定権は現場には無い
現場は必要もないＲＤＢを使いたくなく使ってるのかもしれないな
そして必要もないのに、ＲＤＢだからどうのこうのという、
現場の空気を読まない原理主義者みたいなやつがさらに話をややこしくするんだ

>>67
口調が違うが同一人物じゃないのか？
ちなみに、ＲＤＢ使った開発でＳＱＬを書いてるやつでも、
exists使ったことないってやつは結構いるだろう
ＲＤＢだから、ＯＲＡＣＬＥだから、レコードのあるなしで判断するのは間違ってるだろうとか
その判断基準がおかしいとしか思えん

まあ、現実的なＤＢの選択としてはＲＤＢＭＳしかない現状もあるがな

**NAME IS NULL** · 2009/01/17(土) 12:17:11

１さんの言うことはまったくもって正しいんだけど、
実際にこういうことを口に出しちゃうと
「頭でっかちで現場じゃ使えない」って評価になるんだよね
おれがそうだからよく分かるwww

**NAME IS NULL** · 2009/01/17(土) 13:23:40

制約を強くするとデータを入れにくいじゃない？とか平気で言うPLがいるとやる気0だよね～

それで親の無い子レコードや、不正なデータが山のようにあるんじゃ世話ねーよ

**NAME IS NULL** · 2009/01/18(日) 01:12:13

そうそう、そんな感じｗｗ

設計と製造の現場はまさに自分はDB設計を軽視してませんって顔して
キーマンの顔色を伺って程度をあわせる世界だよね。アホすぎｗｗ

ここもそんなもんだね。あ～あ

**NAME IS NULL** · 2009/01/18(日) 01:57:28

>>81
ここもそんなもんだねとか達観した気になる前にここで吐き出せよ。>80みたいに。
それすらできないくせに嘆くな。

**NAME IS NULL** · 2009/01/18(日) 13:16:55

お前何言ってんの？

**NAME IS NULL** · 2009/01/18(日) 14:47:36

俺？俺は何も言ってないよ。

**NAME IS NULL** · 2009/01/18(日) 15:08:45

オレも何も言ってない。
>>86はどう？

**NAME IS NULL** · 2009/01/18(日) 23:18:56

俺も。

**NAME IS NULL** · 2009/01/20(火) 01:39:08

39+3 ：すずめちゃん(catv?) [] ：2009/01/20(火) 00:55:46.00 ID:5lC2DwfT (2/2)

市況２のスレを読んだら、どうも
データベースがぶっこわれたみたいで、金曜の取引データが飛んだみたい
で、約定メールから復旧させようとしてるとか

**NAME IS NULL** · 2009/01/23(金) 23:30:34

取引先の「偉い上司」デター！
ぼくの考えたデータベース持ってキター！
さて、どうすっかな・・・

**NAME IS NULL** · 2009/01/24(土) 11:34:33

データベース設計が軽視されているのではなく、
データベース設計に携わる人間が軽視されているのだ。

という命題をたててみる。

**NAME IS NULL** · 2009/01/28(水) 20:45:41

>>89
それは、その人間の行う作業が軽視されてるから、
その人間が軽視されてるじゃないか

そうでないなら、別の人間が代わりにその作業をすることになるだろう

**NAME IS NULL** · 2009/01/30(金) 17:19:32

そもそもちゃんと仕事できてないから人間的に信頼されて無いとか？
データベース以前の問題だな。

結局、現場の意見のほうが採用されて、ボンクラDBA涙目。

組織で仕事するという条件で目標を達成するためのスキームをちゃんと考えたほうがいいよ。

**NAME IS NULL** · 2009/01/31(土) 16:21:56

ここ読んでて恐ろしいのは自分の関わったシステムではDB設計軽視して無いって
本気で思ってそうな人がいることだ。RDB的な不備が出るのは現実的に
仕方の無いことだが、あくまでも例外であって、あるシステムの中で数個の
数少ない心残りとして記憶されてしかるべきもの。

こんなバカだらけではキーマンの顔色を伺ってISAMバカ基準でシステムを組んだほうが
計画は立てやすいだろう。RDBMSを使ったPK、ソート、VSAMユーティリティと考える。

だいたいRDBMSをPK、ソート、VSAMユーティリティとしてシステム組んだ経験がある
人だとそれで正解だと誤解しちゃうんだろうな。それで動くから。

底辺会社の底辺システムの目標としてはそれでもいいだろう。動けば底辺客も
文句言わないから。しかし、そんな設計してRDBの特徴を活かさなかったら
RBD以前の非生産性を引きずったシステムが出来上がるわけだよ。しかし、
その非生産性は1円入札して保守で儲けるビジネスモデルでは工数が稼げる
かもしれんよ。いつか関わりたいなRDBのシステム。。。

そういえば某メガバン統合でCOBOLアホシステムで統合決定してるのが象徴的だねえ。
COBOLアホシステム準拠が日本では巻かれるべき長いものと決定したようなもんだ。

**NAME IS NULL** · 2009/01/31(土) 20:03:29

メガバンのＭ菱サイドの方がオープン系とかにシフトする勇気がないんだろうし。
ああいうのは変に金があるから、コスト度外視の設計しても疑問に思わずに、
「こういうもんだ」と納得してんだろう。

**NAME IS NULL** · 2009/02/01(日) 04:06:38

Mでは実績が無いだけでしょ。いわゆる前例がないってやつだ。
提案してるベンダもリスク回避として、今のシステム踏襲路線てのも悪く無い決断だと思うけどな。
まずは確実に統合して不具合を出さない事が第一目標だろう。一気に欲張って失敗するくらいなら、落ち着いてじっくり今後を考えればいい。

RDB的に正しい正規化した設計と、現場が把握し易い伝票ベースの設計のどちらがいいかは力関係も大きいし。

**NAME IS NULL** · 2009/02/01(日) 04:31:52

>>92
お前の考え方は、道具に合わせてものを作れって考え方だ。
それはそれで否定しないが、その考え方だけが唯一の正解のごとく、
他の考え方を貶めるのはやめたほうがいいぞ

**NAME IS NULL** · 2009/02/01(日) 06:47:01

DBAが満足する、実績の無い新しいシステムで、銀行ATM止めて大迷惑かけてしまうのと、
DBAは不満だけど、実績のある既存のシステムで、銀行ATM止めずに問題なく使えるのと、
どちらを決断するって話だろ。

DBA様の首斬って損害賠償請求逝ってもよければ、勝負もあり。

**NAME IS NULL** · 2009/02/01(日) 09:20:00

しかしあのメガバンってアフォみたいにATMを停止させてる現実があるんだが。

単に突然使えないのが事前に「メンテナンス」と言う言葉で停止させるかの
違いなんだろうけど、その「メンテナンス」が予定時間オーバーも珍しくないワケで、
利用者としては「アレ？朝には使えるって言っていたのに･･･」ってクレームも
たくさんあるんだが。

結果論からすると「COBOLでも十分に失敗する」と言う前例は今回の合併だけでなく
以前から繰り返されている予定調和な感があるけどな。

U○Jの以前の倒壊＆惨羽の合併ではそんなに混乱は起きていないけど、
ＭとU○Jではこんなにゴタゴタしているのは、両者の技術レベルのギャップが
凄いんだろうなぁ。Ｍは特に悪評高いパッケージだし。

**NAME IS NULL** · 2009/02/01(日) 14:01:11

それでもまだ復旧の見込みがあるぶんだけ優位だろ。
DBAの提案聞いてオープソ系とか導入して何日も復旧できなかったら終わる。

**NAME IS NULL** · 2009/02/01(日) 17:25:49

あれくらいの仕事する案件では「失敗した時の復旧プラン」もちゃんと計画に入っているんだがな･･･。
「○時時点でこのチェックポイントをクリアできない場合は戻す」と言う具合に。

そこまでしておいて、それでも予定時間オーバーってのは、
COBOLを前提とするシステムと言うのは性善説に成り立っている仕組みが多いという事だな。
逆にオープン系なんかは性悪説(?)に成り立っている感があるので、
JOBの再投入もやりやすいように設計する人おおいからなぁ。

そして何日も復旧できない事態なんて存在しない。

オープン系が優位とは言わんが、COBOLが実績があって安定性云々なんて
寝言を言う人間は間違いなく現場の金融系の実体を知らん厨房だと思う。

**NAME IS NULL** · 2009/02/01(日) 22:31:46

>>95
君は知識的にコンプレックスがあるだけだと思うよ。勉強不足だからホントの事いわれると
貶められたような誤解をするんだと思う。スコップをちりとり代わりに使用しても不便だ、
三角より平型スコップならちりとり性もupするよね。実際、いくつかのOracleのバージョン
アップはISAMシステム実装のしやすさも機能強化されていってると思う。

おれはDBAらしい仕事は一度もしたこと無いが、SEのRDBコンプレックスは見苦しい。
もっと使いこなさないと関係モデルは組めん。半端な知識だから破綻してISAMに
逃げることになんだよ。そんなISAMやりたいんならRDBMSを開発する側に回るべき
だね。そこに食い込めないなら引退すべきだよ。老害なのかなと思う。

**NAME IS NULL** · 2009/02/01(日) 23:10:46

ISAMシステムに逃げるってどういうこと？

**NAME IS NULL** · 2009/02/02(月) 00:45:23

いつも自分の意見が取り入れなくてストレス溜め込んでるのだろうな。
だれもオープン系のシステムにしてくれないｗｗｗ

Mが従来通りの路線で行くのを理解できないほうが、現場の金融系の実体を知らん厨房でしょ。
だからオープン系のシステムにこだわり続ける。
実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。

オープン系って何日も復旧できない事態って本当に存在しないの？
全部のオープン系システムの事態を把握してるのも怪しいが。

**NAME IS NULL** · 2009/02/02(月) 06:44:35

>>101
1つの長大なテーブルをいくつものPGでいくつもいくつも作るシステムといえば伝わるかな？

**NAME IS NULL** · 2009/02/02(月) 21:13:41

>実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。

現に動いてないと言う実態を知らんのか？
あのメガバンのメンテナンスと言う名の停止っぷりは半端ないが。
当初のスケジュールがどんどん遅延して何年かけて統合するつもりなのか知らんが、
現場はいい迷惑だ。

**NAME IS NULL** · 2009/02/02(月) 21:55:10

噂によく聞くコボラーってやつか。
本当にそんな人種いるの？
それならExcelでいいじゃんよｗ

95 · 2009/02/02(月) 22:46:33

>>100
俺は別にコンプレックスをもって言ってる気はないんだがな
お前のいうホントのことって何だ？

まあ、お前がＲＤＢ使ってないのはバカ基準で底辺のアホシステムだと
考えてるというのはよくわかった

まあ、思っててもあんまり簡単に他人をバカだアホだ底辺だといわんほうが良いよ

**NAME IS NULL** · 2009/02/03(火) 01:53:50

>>104
オープンだろうが大型汎用機だろうが関係なく、あんな大規模なシステム統合を本気で丁寧に障害なく
進めるならあれくらいは当然だと思うよ。

見切り発車のＭとみっちり石橋たたきのＭ。どちらがいいか経営者には良い判断サンプルになったんじゃないか？
石橋を叩くのを選べるほど金が使えるのはＭくらいだろうけど。システム部長は石橋を叩けるだけ叩くのが仕事だわな

**NAME IS NULL** · 2009/02/03(火) 23:24:57

プロセス中心で考えるエンジニアとデータ中心で考えるエンジニアが
理解し合うのははっきり言って無理

**NAME IS NULL** · 2009/02/04(水) 06:37:55

お互いに相手の領域を理解すれば効率が何倍もあがるというのに。

**NAME IS NULL** · 2009/02/04(水) 23:06:33

>>109
いや相容れないだろ。このスレ読んでもわかるように
それぞれの優先順位が違いすぎるもの。
プログラム言語の違い以上に深い隔たりがあると思う。

新人の時からデータ中心アプローチをたたきこまれた俺としては、
９２さんの文章は少し挑発的だけど、内容はけっこう共感できるよ。

**NAME IS NULL** · 2009/02/04(水) 23:09:25

自演乙

**NAME IS NULL** · 2009/02/05(木) 00:48:16

というか、
>>1によると、ここでは「業務システム」についての設計の話だそうだから、
データ中心で考えるのが正解ではないのか？

**NAME IS NULL** · 2009/02/06(金) 15:01:56

>>109
理解するだけではだめだな。妥協が必要
ただ、その妥協点は、かなりどっちかよりでないと成立しない
実際は設計するときにどっちの考え方でやるか統一しとかないとだめだな

>>112
業務システムの設計だから、データ中心が正解だという理由を説明してほしいもんだが
プロセス中心の設計は間違いなのか？

データーベース設計の話だから、データ中心の方が良いというのなら理解できるんだがな

**NAME IS NULL** · 2009/02/07(土) 02:03:06

業務システムをプロセス中心で開発するってのは
たいがいにおいて業務プロセス中心に開発するんじゃなくて
システムプロセス中心に開発するの意だからな

**NAME IS NULL** · 2009/02/11(水) 13:36:01

かくしてエンジニアのオナニー状態の使えないシステムが作られて行く訳だな。
そして次の契約が取れず淘汰されて行く。

**NAME IS NULL** · 2009/02/11(水) 15:45:17

>>115
いや、逆でエンジニアにオナニーさせたほうがいいものができるぜ。
マネージャのオナニーの結果、よくないものができてるのが現状でしょ？
マネージャとエンジニアのセックスなんてありえないでしょ？

**NAME IS NULL** · 2009/02/11(水) 16:50:55

>>115
DB設計は家を建てるのに例えれば基礎工事みたいなもんでしょ
外観や内装に注文つける客はいても、基礎工事に注文つける客はいないでしょ

**NAME IS NULL** · 2009/02/11(水) 17:54:21

見えにくい部分だけあって理解も無いから。
ここは地盤が緩いから事前にこれだけアンカー打ち込んでおけと
指示しても施工出来る人がいないとか後での設計変更が云々とか。

DB設計軽視はシステム開発の耐震偽装みたいなものかな。

**NAME IS NULL** · 2009/02/11(水) 18:26:50

>>116
一番怖いのは、営業と客のオナニー
日本ではマネージメント専門の人はプロジェクトにいないのが普通
そういう意味では真のマネージャーなぞ存在しない

**NAME IS NULL** · 2009/02/14(土) 02:52:52

>>1
情報系の人間がただでさえ軽んじられてててさ、
当社では工学部おっけ～、文系でもおっけ～、だれでもおっけ～みたいな会社ばっかで
まともに学校でDBについて勉強したことないやつが多すぎるからだろ

情報系はもっとも理解されてない学科

**NAME IS NULL** · 2009/02/14(土) 03:20:54

会社で昼休みにテクデの勉強してたら資格オタク扱いされたなぁ

1 · 2009/02/15(日) 13:28:47

>>120
文系、理系の問題ではないと思います。
私は文系ですし。

**NAME IS NULL** · 2009/02/19(木) 23:58:36

>>120

ふむ。

今の情報系の学科がどのようなカリキュラムか知らないが、
大学出の者を戦力と考える会社はいまどき居ないだろ。

会社としては2,3年掛けてようやく戦力として使えるかな？
という人間を探しとているということではないかなぁ。

それには出身の大学、学部、学科はあまり考慮されないと思う。

**NAME IS NULL** · 2009/02/20(金) 15:11:09

でも地頭は大事。新卒の場合、出身大学のランクを元に、見込みで採用してるだけ。
中途なら、出身大学のランク高くても、経験や実績無ければゴミだろ。

IT系は専門知識不要で採用してしまうからな。そして現場で不良施工状態のデスマ。
ちゃんとIT理解してる理系が、人嫌いでPCにばっかり向かっていて、客との対話を営業任せで放棄してるのも、低コストで短納期で突貫工事的な変な仕様で迷走する理由の一つだと思う。

客は住み易さとか快適性能に重点置いてるのに、施工してる側は基礎工事だけに専念していいものが出来たってオナニーを満足してちゃ意味無いだろ。
家は３回建て直さないとまともなものが出来ないように、システムも１回で使えるものが出てこないのは、理系のオナニーのため。

**NAME IS NULL** · 2009/02/20(金) 19:30:18

釣りか？！データモデル設計とテストデータ実装、本番データの実装、ACCESSのクエリーなりでＵＩ概要とすれば
ＰＧ無しで開発できる。プロトタイピングからスパイラルモデルで進めれる

２サイクル目でＰＧの帳尻合わせなんかしないリモデルリトライだ

だいたい物理的組み立て積み上げで作る家なんかと比較してるなんて現実にあるシステムの機能を
知らな過ぎ

**NAME IS NULL** · 2009/02/21(土) 01:48:51

まあ
二人ともモノ知らなさ過ぎな事はわかるがｗ

**NAME IS NULL** · 2009/02/21(土) 10:45:09

>>125
突っ込みどころ満載だなwww

**NAME IS NULL** · 2009/02/22(日) 21:31:56

できるのに大学行かないやつも迷惑だよな

**NAME IS NULL** · 2009/02/26(木) 09:29:54

底辺大卒の悲壮ですか？

**NAME IS NULL** · 2009/02/28(土) 16:59:28

正規化も3層スキーマの考え方も身についていないような奴が
DB技術者を名乗っちゃうから嫌になる。

自称DB技術者のおっさんが主キーがどれかすらはっきりしない
テーブルもどきの何かを作ってきたんで正規化してくれと頼んだら
しばらくネットで何かを調べた後にテーブル数が増えてわかりにくくなるから
正規化しなかったと言い訳してきた。

よくネットでテーブル数が増えるから正規化はしなくていいなんていう
無茶苦茶なことを書いてる似非DB入門サイトがあるが、それに騙されちゃったんだろうな。

**NAME IS NULL** · 2009/02/28(土) 18:29:31

問題を指摘されたらググって言い訳を探す医者や自動車設計者が
いたら結構イヤン。

**NAME IS NULL** · 2009/03/01(日) 00:06:37

でも使ってるうちに正規化が崩れていくのも事実。
データベースがどのような事に使われていくかはシステム稼働後にしか分からないし。
　
呼び出してるDBアプリほど、柔軟には、DB側は組み直しとか出来ないし。
簡単に正規化組み直しとか出来る機能が付けばいいけどね。

**NAME IS NULL** · 2009/03/01(日) 09:56:25

DBの組みなおしは簡単に出来るよ。それこそ制約に従ったSQL書ければ簡単だよ。
組み直しが難しいのはPG

**NAME IS NULL** · 2009/03/01(日) 11:37:45

>>132
使う、っていうのが、システムの変更も含めているのならまあそうかもしれん
だが意図して正規化を崩すのでなければ、変更した技術者のスキルの問題だろう

普通はシステム稼働まえに、設計の段階でどのように使われるか考えるものだろう
DBの変更はプログラムの変更に比べれば簡単だと思う
簡単であるが故に、設計がおろそかになってるんじゃないかと思うな

**NAME IS NULL** · 2009/03/01(日) 15:12:16

そこでスレタイですね

**NAME IS NULL** · 2009/03/01(日) 23:46:49

だからPGはあとまわしでPGによる調整が必要ないところまで
データモデルを作り上げてインプットとアウトプットを固めないと
糞PGになんじゃん

**130** · 2009/03/02(月) 08:43:58

>>132
何を言ってるんだか。
おまえは半年仕事を休んでデータベーススペシャリスト試験を
本気で合格する気で勉強してみろ。

言っておくがオラクルなんかのベンダー資格なんてとっても意味はないぞ。
基本が身についていない奴が製品に依存した知識を持ったところで意味はないからな。

まったく、嫌になる。

**NAME IS NULL** · 2009/03/02(月) 19:08:00

１０年使ってきたDBの変更と、１０年使ってきたウェブアプリの変更どっちが簡単か自明だと思うけどな。
１０年後まで考えてデータベース設計するのは無理。
最初は在庫管理で作ったのに、拡張で顧客管理も入って、更に拡張で売り上げや経営財務管理まで入ってくるし。
　
アナログ的に言うと、社内帳簿フォーマット変えるのと、利用してる現場担当者入れ替えるのとどっちが簡単かって話。

**NAME IS NULL** · 2009/03/03(火) 23:10:30

利用者の顔色を伺って利用者と良好な関係を保つのが仕事をうまくすすめるコツだな

問題は糞利用者が使ってる糞帳簿を改善することではないんだよ。デジドカの鉄則だ

**NAME IS NULL** · 2009/03/03(火) 23:53:30

老害コボラー臭のするヤツがいるな
他の板に居場所ないのか？

**NAME IS NULL** · 2009/03/04(水) 03:34:01

↑うまくいってる？

**NAME IS NULL** · 2009/03/04(水) 14:46:46

>>141
ちゃんと安価書けよこのうんこ

**134** · 2009/03/04(水) 17:38:20

>>138
自明って、お前の主張はどっちなんだ？>>137への反論なのか？

**NAME IS NULL** · 2009/03/13(金) 01:10:06

>>132はある意味、「真理」に近いと思う…

最近は単純に「上流」工程だの、「下流」工程だのと、
誰かが宣伝したテンプレに従い過ぎだ…

んなもん、ケースによって全然違うんじゃ～い！

**NAME IS NULL** · 2009/03/13(金) 02:07:07

実務の世界の人間ではないのですが、「使っているうちに正規化が
崩れる」というのは具体的にどういう状況を指すのかちょっと興味が
あります。

更新のコストが馬鹿にならないので非正規化する、というケースは
理解できるのですが、例えば業務内容に上手くマッチしなくなった
のでスキーマを改変する、というケースであれば、なんで改変後も
正規形を満たすように改変しないのかな、と素人考えでは思って
しまいます。

もし宜しければ簡単な例など教えていただけないでしょうか。

**NAME IS NULL** · 2009/03/13(金) 09:11:07

「正規系が」業務内容に上手くマッチしなかったんだろｊｋ

**NAME IS NULL** · 2009/03/13(金) 13:28:46

スキーマ改変したら、アプリ側の改変しないと駄目で、予算的に膨大になるでしょ。
スキーマ改変なんて現実は、なかなか遣れない。スキーマ改変について来れるようにアプリ側で対応してるのも見た事無いし。

**NAME IS NULL** · 2009/03/13(金) 15:08:04

お客さんに、「いちいち明細なんて入力するの面倒くさいし
そもそも決まった数以下しかないから」っていわれて
しかも見出し・明細が1行のレコードとして
外部と連携したりなどなどで正規化やめたことはある。

**NAME IS NULL** · 2009/03/14(土) 19:50:11

>>146
それはその技術者のスキルが低いからうまくマッチングできないんだろ
>>147が言う、既存部分の変更を嫌がるのが一番の要因だとおもう
あとは>>148のいう、外部要求に合わせるためか。
こっちはできれば、ビューとか外部出力するアプリでの操作で回避したいとこではある

**NAME IS NULL** · 2009/03/14(土) 21:37:15

>>149
なるほど。>>148の繋がる相手に合わせる、というのはよく分かる
気がします。
>>147はまだちょっと難しいです。
既存のスキーマを改変するのはなかなか難しいというところまでは
理解出来るのですが、スキーマを改変しないならそもそも正規形も
崩れようが無いのでは？と思ってしまいます。

これは例えば住所を2件持てるようにしたいので一つの住所カラムに
タブ区切りで2個住所を入れちゃうぞとか、スキーマはそのままでも
入れるデータによって正規形が崩れてしまうような状況を指している
のでしょうか。

**NAME IS NULL** · 2009/03/15(日) 01:02:31

データってのは、ただ溜め込むだけじゃなくて、いろいろな事に使われて応用されていくもの。
いろいろなデータが追加されていくと、正規化が崩れていく。
１０年拡張もせずに動かすというシステムなら、正規化は当初のまま有効だろうね。

**NAME IS NULL** · 2009/04/07(火) 23:03:52

accessと汎用系DBとでは、設計手法が異なると聞きましたが本当ですか？

**NAME IS NULL** · 2009/04/08(水) 03:28:48

どこまでを指して設計手法としてるかにもよると思うが、
たとえばアクセスだとトリガやストアドプロシジャが使えない
そういった、アクセスではできないことを考慮した設計は必要
テーブル設計での正規化とか、そういった基本はあんまり大差ないとは思うが

**NAME IS NULL** · 2009/04/08(水) 07:26:18

>>152
その人の言う「汎用系DB」って、IMSとかのことだったりしてな。

**NAME IS NULL** · 2009/04/08(水) 08:52:29

正規化されてないDBを見て
それを非難するやつがいたとしたら
そうなるまでには経緯とレベルがあるなんて
理解出来ひんねやろうな。

DBがあります。それが正規化されてるとします。
その場合は
１仕様策定の主導権がDB側にある
２パッケージソフト
３数人で作った小規模システム
４出来たてのシステム　
５システム仕様が業務効率化など低レベルなもの

かな。
>>1は、特定の部署でしか使わない、今まで手でやってた仕事を
システム化しましたみたいな
入門者みたいなシステムしか作ってないんちゃうかな

**NAME IS NULL** · 2009/04/08(水) 11:18:57

うわー盛大なバカが出た。

**NAME IS NULL** · 2009/04/08(水) 12:54:06

>>155
正規化されてないDBに経緯があるのは理解できるがな、
レベルってのはなんだ？レベルが低いから正規化されてないのか？
そんなの非難されて当然だろう

お前の言い分だと、正規化されていないのが当然のように聞こえるが、
お前こそ入門者みたいなシステムしか作ってないんじゃないのか？

>>1は何も正規化だけを問題にしてるんじゃなくて、
設計が大事なのになぜ軽視されてるんだろう、って話だが
お前みたいなやつがいるからなんだと思ったぜ

**NAME IS NULL** · 2009/04/08(水) 21:25:23

>>153
遅くなりましたが、
ありがとうございます。
ﾄﾘｶﾞ、ｽﾄｱﾄﾞﾌﾟﾛｼｼﾞｬ、頑張って調べます。

**NAME IS NULL** · 2009/04/08(水) 23:28:49

さすがに>>155は釣りだろｗ

**NAME IS NULL** · 2009/04/08(水) 23:33:40

正規化しといても、どんどん拡張していくうちに崩れてくるしな。
正規化したくても全部のアプリ作り直しは無理。

http://pc11.2ch.net/test/read.cgi/db/1116097001/
頼むから正規化しろよ　第二正規形

**ER図** · 2009/04/28(火) 01:30:12

突然ですがアドバイス下さい。
アパッチのアクセルログで取れる情報のER図をかけといわれたのですがどんな感じのものをかけばよいでしょうか？
一応アクセスログの仕様については調べたのでログフォーマットとかカスタムログとかの記述方法はわかるのですが
これをER図にしろと言われたらよく意味が分かりません
データベースのテーブルでもないのにこんなもんをER図に出来るもんなのでしょうか
よろしるおねがいします

**NAME IS NULL** · 2009/04/28(火) 21:50:03

データベースのテーブルとアクセスログは全く同じ形式じゃないか

**NAME IS NULL** · 2009/04/30(木) 01:51:22

アクセスログをどう使いたいのか、要件がわからないままなら、ログのフォーマットそのものなテーブル１つで終わる。
でも、きっとそんなことは無いはずなので指示者に一応確認してみる。

うまく聞き出せないなら、指示者が長期休暇中なら、貴方が｢こういう使い方したら便利だよね｣と思う使い方を想像し、それにあわせた構成でER図を描けばおｋ。
あとはログフォーマットの各項目をそれぞれ配置する、と。

ついでに｢こういうことするならこんなデータも無きゃいけませんよね｣ってな要素を付け加えて提案してみるのも良いのではないかしらん。
例えば、IPアドレスのブラックリストを準備して、ログテーブルとIPアドレスをキーにジョインして｢ブラックリストのIPからのアクセスだ｣とわかるような仕組みを入れてみるとか。

**NAME IS NULL** · 2009/04/30(木) 02:27:37

もし、運用目的の話ではなく、純粋に情報の構成をER図であらわせ、って話をしているのなら、大雑把に言うと
　・IPアドレス
　・ユーザ
　・アクセス日時
　・発行メソッド(参照URL)
　・ステータス
　・他もろもろ
がどういった関連を持っているか書け、と言う事なのでしょうね。

例えば、URLを中心において
　・そのURLに紐づくユーザ
　・そのURLに紐づくIPアドレス(アクセス元IPアドレス)
　・そのURLに紐づくアクセス日時
といった要素の関連を書き表すとか。

学校の宿題なのか、新入社員さんの研修課題なのかわからないけど、まぁがんばって。

**NAME IS NULL** · 2009/05/01(金) 07:02:14

課題だとしても実用的じゃなさすぎる。
出したやつは馬鹿だなｗ

**NAME IS NULL** · 2009/05/02(土) 16:13:53

そうか？
結構こういう汎用ログからのデータ収集って実社会で役に立つと思うが。
注目してる香具師が極端に少ないだけで。

普通にアクセスログ表示ソフトがどんな項目で分析してるか調べるといいと思う。

http://pc11.2ch.net/test/read.cgi/db/1232457109/
「ビジネス」BIツール「インテリジェンス」
http://pc11.2ch.net/test/read.cgi/hp/1218494105/
【アクセス解析】Google Analytics 5
http://pc11.2ch.net/test/read.cgi/hp/1098282501/
詳細なアクセス解析をしたい！！！
http://pc11.2ch.net/test/read.cgi/php/996937818/
Analogスレ
http://pc12.2ch.net/test/read.cgi/unix/1014402672/
統合監視ツールどうよ?
http://pc11.2ch.net/test/read.cgi/linux/1150732249/
GNU/Linux とネットワーク/セキュリティ

あと、IT監査とかで結構需要は多い。一般ソフト並みとはいかないけど。

**NAME IS NULL** · 2009/05/02(土) 17:29:02

>>166
よく読め。ログをERで表せって話だ。

素人 · 2009/05/11(月) 00:45:40

すみません。オッケーウェブで質問して、回答ももらったのですが、回答が１件だけだったので
もう少し他の意見も参考にしたいと思ってこっちに来ました。オッケーウェブの方はもう締め切って
あるので、マルチだと言わずに聞いて欲しいです

僕が質問したトピックはこちら
ttp://okwave.jp/qa4946216.html

ＥＲ図が削除されていたのでもう一度アップしました
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/9156.zip

確かに回答の通りこの場合はok_ngで検索すればいいだけなので冗長だと思いました。
そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？
使い分け方とメリットデメリットあたりが聞きたいです。

それと、１対１のテーブルは、たまたまマイレージプログラムと乗客のテーブルで見たのですが、
それは「特殊」なパターンなのでしょうか？それとも一般的なものでしょうか？
そのあたりも教えて下さい。

**NAME IS NULL** · 2009/05/11(月) 05:28:05

　｢こういう理由でこの１対１の関係を作ったのだけど、どういった問題があるか指摘して欲しい｣

のような話でないと、なんともいえないです。
｢合格者テーブル｣を作った理由ですね。その理由からメリットデメリットが導かれてくるんじゃないかなぁと。
訳もわからず、理由も無く、なんとなく作ったのなら、それは意味が無いし先の回答者の様な返事になるだけですよ。
※自身で「冗長だ」と思うならそういう設計をしなければ良いわけで....何故悩むのかと。

もし本を読んで見つけたのならそのデータ構造を作る理由を読み直して理解した方が良いです。

※あと、「そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？」も
　ちょっと意味が判りかねます

**NAME IS NULL** · 2009/05/11(月) 08:54:15

なんでマルチが嫌われるのかと言えばだな、回答した香具師に失礼だからさ。
okで回答した香具師に失礼と思わない訳？
にちゃんで回答した香具師にも失礼な行動は予想出来るよな。

にちゃんで回答してもらったが、納得出来ないので教えて欲しいと他所でまた訊くのだろ？

素人 · 2009/05/11(月) 09:31:11

大変失礼しました。

**NAME IS NULL** · 2009/05/25(月) 05:26:51

結局、 >>161 も>>168 も音沙汰無しなんだな。

後日談とかちょっとだけ楽しみにしてた私はマヌケだった。ﾊｽﾞｶｼ.....

**NAME IS NULL** · 2009/05/26(火) 07:16:07

今にちゃんでの回答に納得出来なくて、他所で訊いてる所だろ。

**NAME IS NULL** · 2009/06/18(木) 01:33:24

えーと、初めてのオラクル案件でマスタテーブルを
UNIONで結合したような統合テーブルが設計されていたのだが
オラクルが特別なのか、案件が特別なのかどっちらでしょうか。

**NAME IS NULL** · 2009/06/18(木) 21:46:40

統合テーブルってなに？
viewのこと？

**174** · 2009/06/18(木) 23:37:09

すまん、それは漏れが感じたテーブルのイメージ名。
view ではなく Table です。項目を大雑把に書くと
テーブル名,詳細キー,値1,値2,テキスト1,テキスト2,日付1,日付2,備考,etc…
値の例）
部門,1,null,null,営業,null,null,null,テキスト1:部門名,etc･･･
消費税,1,5,null,null,null,null,null,値1:消費税率×100,etc･･･

**NAME IS NULL** · 2009/06/19(金) 00:47:06

特別だからってどうなるの？　指定なら対応するしか選択肢無いと思うが。

**NAME IS NULL** · 2009/06/19(金) 01:05:15

>>174
オラクルに限ったやり方ではないし
特別ってほど奇異でもない

ただ例としている部門と消費税を一緒にするのはエスカレートしすぎって感じ

**NAME IS NULL** · 2009/06/19(金) 03:25:51

単にテーブルだけ出してきて、それが特別かどうか聞かれてもな
もしかしたらものすごく特別な使い方してる可能性もあるし、
結構見られるようなものかもしれない
汎用的なマスタとして使ってるのかもしれない、リポジトリのような使い方かもしれない

が、使ってるDBMSだ何だろうと、そのテーブルがそのままの形なら
設計やり直してくれとお願いするな、俺ならｗ

**NAME IS NULL** · 2009/06/19(金) 06:01:10

消費税なんて変わりそうなものは別に分けたいね。
まあその時の担当じゃなければどうでもｗｗｗ

コボルベースの設計とかを引き継ぐ理由とか有るのでは？

**174** · 2009/06/19(金) 21:37:46

>>178
オラクルだからって事ではないんですね。

>>179
リポジトリではないですね。
汎用的なマスタなんだろうけど汎用性が高すぎる。
次のプロジェクトから設計やり直しをお願いしてみるよw

>>180
なるほどコボルベースの設計か、
設計者が実績あると言っていたから伝統なんだろうな
ASP.net2008で開発してDBが伝統か

**NAME IS NULL** · 2009/06/19(金) 22:07:28

中身のない実績なんだろうな。

**NAME IS NULL** · 2009/06/20(土) 08:47:31

昔コボルでの実績だろう。

**NAME IS NULL** · 2009/06/20(土) 10:17:54

しかしその何がどう問題なのか、正しく指摘できる者はいないのであった。

**NAME IS NULL** · 2009/06/21(日) 08:51:28

コボルにも対応出来るのが普通だしな。
ちゃんとコストとか実行速度のデータ示せないと検討も出来ない。

**NAME IS NULL** · 2009/06/22(月) 21:30:17

>>184-185

釣れますか？

**NAME IS NULL** · 2009/06/22(月) 23:32:51

3日粘ってようやく一匹。

**NAME IS NULL** · 2009/06/24(水) 00:24:45

すいません、正規化を俺が望まなければちょっとの修正ですんだものを、
DB構造もプログラムも大改修して多大なコストがかかりました

技術屋として間違ってはないと信じてる
でも経営としては間違ってるんだろうな、きっと

**NAME IS NULL** · 2009/06/24(水) 06:53:19

>>188
将来のデータ不整合、障害発生のリスクと
目先のコスト、どっちが大事かな。
まぁ、派遣切りのご時世だもんな。

**NAME IS NULL** · 2009/06/24(水) 09:00:48

金がかかったそもそもの原因は正規化のせいじゃなくて
元々の設計がダメだったせいってなんで気がつかないの

**NAME IS NULL** · 2009/06/24(水) 16:12:25

表層に現れるのは「修正にコストかかった」ってことだけだからな
お偉いさんには「こんな簡単なことに時間かけて何やってんだアイツは」としか映らない
技術者をないがしろにしてきた代償だよ

**NAME IS NULL** · 2009/06/24(水) 19:12:46

>>188
もともと正規化してなかったので、そのちょっとの修正の「ついでに」
正規化した、というのであれば、そのコストは、ついでの作業に伴い発生したコスト

技術屋って言い方すればコスト意識を無視できるわけではないと思うがな
ｘｘ屋さんってのは、ｘｘを売るから屋なわけで
コスト関係なく技術的に最善最上な状態でないと気に食わないというのであれば
それは技術原理主義者とｗ
コストとのバランスをとれるから技術者じゃなくて技術屋なんだと

**NAME IS NULL** · 2009/06/24(水) 19:32:12

しかし、コスト至上を理由に次々とパッチワークしていったシステムはひじょうに脆く、改定に対する耐性が格段に低くなる。
全てを「自分の好みに修正」したいってんなら、お前なにやってるんだの世界だけど。
後まで見据えての決断であれば技術者の良心だろ。
姉歯はいかんよ、姉歯は。

**NAME IS NULL** · 2009/06/25(木) 00:20:29

元々の設計のままでのコストの発生具合による。
好みや良心の技術第一主義で通しても、理解してくれる客は少ない。

でも自分のアピールや努力が足りずに、姉派みたいな弱い立場に陥るのは技術第一主義者には多いと思うよ。
漏れは設計しか遣らないとか逝っても、設計外の人間に理解してもらえる事は少ない。その積み重ねがどんどん立場を弱くして、設計だけしか頼まれない弱い立場で責任だけ押し付けられる事に成る。

設計に金を出してくれる客と良い関係を築けての商売。

**NAME IS NULL** · 2009/06/25(木) 04:53:37

>>193
その、しかしってのは>>192を受けていってるのか？
技術屋ならバランスとれっていってるのに
コストのために犯罪犯すような話といっしょにするなよ

>>194
すくなくとも今のソフトウェア産業において、設計だけでは
ビジネスとして成り立たないと思うがな

本来客は、設計に金をだすんじゃなくて、プログラムやシステム全体に金をだすわけで
その中の設計に配分される割合が低すぎる＝設計が軽視されている
それは客の理解の問題じゃなくて、売り側が過当競争によって
目に見えにくいコストから削ってるからじゃないかと思うが

**NAME IS NULL** · 2009/06/25(木) 06:13:48

だから設計でちゃんとコストが変わる事を設計担当がアピールするのが大事。
何もしないから、配分の割合減らされて、コスト削られてるのだよ。

**NAME IS NULL** · 2009/06/27(土) 01:37:32

>>196
これって客先に説明しておしまい。ってならいいけど

無知な上級SEが良いところ見せようとして・・・説得したあとから
平気で台無しになるようなことをしてきて、あとよろしくって♪って感じの多いわな

**NAME IS NULL** · 2009/06/27(土) 07:52:04

上級SEぐらいおさえられないでどうする
身内の敵はもっと上だぞ
マネージャーやら社長やら・・・

**NAME IS NULL** · 2009/06/27(土) 08:56:32

常に人減らせないか、安い人材に出来ないか考えてるからね。
そういう人たちにも、ちゃんとした設計がコストに影響する事を示せないと負け。

**NAME IS NULL** · 2009/06/27(土) 21:04:36

逆に考えて、
設計がコストに影響することを理解できないような人たちが、
マネージャやら、〇〇長やらを
やってることが問題なんじゃない？

で、この問題をどう解決するか、なんだか。