08/12/01 01:07:27 X6n/IiFX.net
何故データベース設計は軽視されるのか？
ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
2:NAME IS NULL
08/12/01 01:09:40 .net
ここでいうデータベース設計とは、テーブルレイアウトを決める作業を指し、
データベースとは、リレーショナルデータベースを指しています。
3:NAME IS NULL
08/12/02 01:24:11 .net
プログラムのデザインも、正規化も知らない奴がSEを名乗ってるからだろ。
驚くぐらい何も知らない。
4:NAME IS NULL
08/12/04 15:02:51 n/7HAnFW.net
むしろDBの設計でPGが大きく変わって組みやすくなる可能性もあるというのに・・・・
確かに>>3の言う通りだと思う
5:NAME IS NULL
08/12/04 21:48:53 .net
ERDのこと？
6:NAME IS NULL
08/12/04 22:10:28 .net
とりあえず今保守してるシステムのテーブル名とカラム名に
日本語を使ってるのやめさせたい。それからコボラーの薫陶を
受けたVBA使いの作ったシステムを全て作り直したい。
7:NAME IS NULL
08/12/05 08:38:19 .net
動きゃいい、と思ってるからですかね。
8:NAME IS NULL
08/12/05 23:36:44 .net
>>7
動けばいいとすら思ってない。
作って納品しちまえばおｋと思ってるw
9:NAME IS NULL
08/12/08 09:10:39 .net
納品時のテストデータでかろうじて動作はするものの
本運用に入ったら誤作動しまくり落ちまくりってのはもう
狙ってそう組んでるとしか思えなくなってきた・・・
10:NAME IS NULL
08/12/09 09:24:10 .net
いまだに綱渡り的な設計とかが存在してるのな(；´∀｀)
11:NAME IS NULL
08/12/09 20:00:03 .net
いまだに「テーブル名・カラム名は全てID制です！」ってとこもあるからな。
IDが何なのかってのを記憶してる人間が技術力高いつて重宝されとる……
12:NAME IS NULL
08/12/10 04:46:06 .net
そろそろ今のPJが終わるので今度入る予定のPJチームに挨拶行った。
若手のSEがDB設計中だったので覗いたら、テーブル名・カラム名を日本語で書いてる・・・
んで、それはやめようよと言ったら、マニュアルのどこにダメって書いてあるんですか！日本語は使えるはずですよね！
と言われたので、その場でPJから外してもらうよう上司に頼みに行った。
送り仮名で嵌るんだよ・・・
13:NAME IS NULL
08/12/10 09:36:26 .net
SYOHIN
SHOHIN
SHOUHIN
前任のアフォが設計したDBでこれらが混在してたから
全部「商品」で統一して新規で作り直す仕事何べんもやってるw
14:NAME IS NULL
08/12/10 20:38:31 .net
ど素人でＤＢに興味あるものですが、
このスレ読んでおれもＤＢ設計してみようかなと思った
15:NAME IS NULL
08/12/11 01:23:12 .net
つうかね会社の方針が変わったり条例が変わったり法律が変わったりするたびに変更しなきゃならないシステムもたくさんあるわけよ
そのたびに一から作ってたら間に合わんし客も予算出せないでしょ
実稼働中の物を今日まではこれ、でも明日からはこのシステムで
なんて無茶な用件はたくさんある
だからある程度の遊びフィールド作ったり妙な拡張して過去の残骸が残ってたりする物が出来てくるわけ
それを最初見た奴にとっては謎いシステムかもしれないけどさ
簡単に言うとガチガチに設計すると馬鹿を見る事も多いんだよ
16:NAME IS NULL
08/12/11 01:34:09 .net
>>15
コボラ？
17:NAME IS NULL
08/12/11 05:04:21 .net
>>1
データベース屋がまともな仕事をしないからだろ。
>>3のような技術力の不足、利用シーンを考えない独り善がりな設計など。
むやみに正規化してりゃいいってもんじゃないし。
18:NAME IS NULL
08/12/11 14:30:58 T35oVHMe.net
とりあえず
2008/11/12
を画面上でH.20.11.12
とかで表現するのはいいけど
DBにまで
H.20.11.12
として保存する仕様は勘弁してください。
19:NAME IS NULL
08/12/11 22:15:44 .net
>>18
そんなのまだまし。
3601112←これ昭和60年な
3201112←これ平成20年な
4011112←これ西暦2001年な
和暦は3で西暦は4な。
20:NAME IS NULL
08/12/12 00:02:36 .net
>>19
平成22年とベビーブームが始まる昭和22年はバッティングしないのでせうか( ﾟдﾟ)
21:NAME IS NULL
08/12/12 09:51:04 .net
>>20
生年月日とかでなければバッティングしないんじゃない？
それにしても、その仕様は無いなw
22:NAME IS NULL
08/12/12 09:58:47 .net
そういえば、社会保険庁が提供している申請用ソフトも
データが和暦格納で使いにくいな。
スレとは関係ないけど、そいつが吐き出すCSVはクォーテーションが付いてないので
うっかりExcelなんかで開くと、コードの頭のゼロが取れていたりする糞仕様。(0001→1)
23:NAME IS NULL
08/12/12 12:18:20 .net
>>22
心配するな。「"」付きでもExcelはゼロサプレスしてくれるよ。
んで、うっかりExcelで開いて保存しちゃったCSVを本番に突っ込んじゃった
アホがいたもんだから、マスタが一切引けなくなってえらい目にあった。
…DB設計の問題じゃないけど。
24:NAME IS NULL
08/12/12 22:23:04 .net
>>20
バッティングする。しかし詳細はばれるので明かせないが、３０年の期限が
管理できればいいので、生きてるデータは最古でも1978年。
死んでるデータはもうグダグダ。ゴミ。
25:NAME IS NULL
08/12/13 13:01:20 .net
>>22
可能です。
以上。
↓次どうぞ
26:NAME IS NULL
08/12/13 13:45:18 .net
>>1
経営者や管理職や客は、目に見えるものしか評価できないから、
DB屋よりもJava屋の意見を聞く。
↓
Java屋は、O/Rマッパを使いまくって、DBをオブジェクトの永続化ストレージ
としか考えない。DB設計？なにそれ？おいしいの？
↓
それでも動く。
↓
Java屋
「ほら見ろ、俺のやり方が正しい」
「DB屋の言うことなんか聞いてたら開発おわんねw」
↓
数年後： DBあぼ(ry
↓
開発当時の人間いない。だれのせいか分からない。
DBがダメになったから、DB屋が悪かったに違いないという判断。
↓
DB屋、ますます発言力低下。
↓
以下、ループ。
27:NAME IS NULL
08/12/14 12:59:31 .net
DB屋が論理設計途中でトンズラされたPJ。
既に実装スタートしてたから皆でオンデマンドでDB設計やってたぜw
28:NAME IS NULL
08/12/15 09:48:21 .net
>>19
明治は１，大正は２，昭和は３，西暦は４，
てなのを大昔にコボルさんが組んでて、
昭和天皇の崩御で困った困ったって話？
29:NAME IS NULL
08/12/15 10:16:58 .net
>>19
つっか、マジな話、
今の天皇が幾久しく健康でありますようにと、お祈りする必要があるね。
30:NAME IS NULL
08/12/17 10:16:13 .net
>>28
まさに文系乙の、非論理的な設計ですね。
文系の声がでかいのも、論理的な正しい設計が軽視される原因と見た。
31:NAME IS NULL
08/12/17 19:46:04 .net
>>30
文系とか関係ないだろ。見通しの甘さが全ての原因だ。
ようするにバカなんだよ。
32:NAME IS NULL
08/12/17 20:52:39 .net
ＳＥの机にデーターベース入門とか並んでて吹いた
33:NAME IS NULL
08/12/18 00:42:35 .net
まあ、たしかにＤＢ屋の地位とかは低いよな。。
俺は運用側なので、開発側が主催する
システムリリースの打ち合わせに呼ばれる。
開発側の説明を受けた後で、運用上、設計上の問題をあげ、
改定を提案すると、いつも返答はこれだ。
「リリースしないと業務に支障がでる！」
だったら、システム設計のころから打ち合わせに呼べよ。
割を食うのはいつもこっちだ。
すまん、愚痴った。
34:1
08/12/18 00:42:43 CvpxRnbY.net
年月日を和暦で格納するとか、
カラム名が日本語や日本語をローマ字にしたものであるとか、
運用を続けていくうえで仕様変更が続き過去の残骸データが残っているとか、
このあたりはもうしょうがないというか、諦めています。
我慢できます。
問題にしたいのは、論理性（純粋な意味での設計）です。
例えば1対nの関係にある情報を2テーブルに格納すべきところを
1側の情報を多側にn個格納したり、
候補キーが不十分で対象のレコードを特定できないケースがあるテーブルがあったり、
日々追加削除が発生するテーブルが第3正規形になっていなかったり、
（ケースバイケースがあることは承知しています）
こういった問題のほうがデスマーチに陥りやすいと思います。
で、デスマーチに陥ったら陥ったで何故かプログラムで対応しようとする。
設計に立ち戻らないんですね。ここが問題だと思っています。
35:NAME IS NULL
08/12/18 14:25:33 .net
建築に例えれば、DBとかネットワークは土台、地盤にあたる部分だよね。
それが緩い、いい加減なところの上でシステムを構築することが、
いかにリスクが高いか、判らないのかねぇ。
判らないんだろうなぁ。
システムは目に見えないからねぇ。
36:NAME IS NULL
08/12/19 07:52:58 H7TAHI1+.net
この板には最近来るようになった新参者ですが
このスレは書き込み少ないけど非常に参考になります。
37:NAME IS NULL
08/12/25 09:38:42 Y/SoMNRd.net
稼働システムでDB設計がおかしくてPGで何とかしようとするのはいい
もう稼働してしまっているから大きな改造などは怖いので出来るだけやりたくないという理由
でも・・・なんであいつ等それを教訓にして次の土台の硬め方を変えようとしないのか
同じような設計して同じようなトラブル産んで・・・・
追伸
正規化とかもやりすぎは使いにくさにつながるかもしれないけど、適度な正規化くらいかけてください。
38:NAME IS NULL
08/12/25 18:39:06 .net
今は昔よりサクサク作れるんでしょ？
ＤＢも使い捨ての時代じゃないの？
39:NAME IS NULL
08/12/25 21:37:48 .net
アプリケーションはサクサクと使い捨てられることも多いけど、
DBは後々、受け継がれて残っていくからなぁ。
アプリケーションの進化に比べると、SQLやRDBの進化は遅いしね。
っていうか全角でＤＢ www
40:NAME IS NULL
08/12/27 00:32:30 .net
遅いかねえ
最新のDBの機能なんて誰も使いこなしてねーじゃねーか
41:NAME IS NULL
08/12/27 01:02:18 .net
昔IBMの博士がRDBの基礎理論を発表してから、常に進歩・進化していると思うが。
OracleやDB2なんかは使いこなしている奴の方が極レアだろうに。
42:NAME IS NULL
08/12/27 02:11:29 .net
RDBMSの実装自体は猛烈な勢いで進化していますが、
スキーマ設計手法やクエリ言語に関しては案外ゆっくりと
しているのではないかと。
SQL92以降の拡張って実際どの程度使われていますか？
43:NAME IS NULL
08/12/27 03:50:52 .net
LINQがどうなるのかってところか。＞クエリ拡張
あとは、ORマッピングの活用とかそっちも全然進んでなくね？＞特に日本
44:NAME IS NULL
08/12/27 08:06:29 .net
xml関係の拡張(?)も凄いと思うし、モバイル対応とか、組み込みとか
あれこれ頑張っていると感じる。
45:NAME IS NULL
08/12/27 08:52:24 .net
>>43
O/Rマッピングにそんなに価値を感じてるのですか？
流行に踊らされていませんか？
46:NAME IS NULL
08/12/27 09:23:03 .net
そりゃまあ、COBOLerには縁がないから、価値を感じないだろうなぁ。
47:NAME IS NULL
08/12/27 10:59:58 .net
COBOLは全然分からないが、DB設計の立場で見ると、
O/Rマッパには、
DB「設計」不要の簡易システムなら画面プログラマだけで作れる、
という以上の価値は感じられない。
48:NAME IS NULL
08/12/27 13:56:21 .net
ポトペタな画面アプリ作る時には実際、O/Rマッパって必須だと思うけど。
簡単なものが簡単に作れるのは実際ありがたいし。
ちなみにDB設計不要ってくだりはｲﾐﾌﾒｲだな。
そりゃＤＢ設計者と思い込んでいる運用チームの人間が言っているなら
なんとなくわかるが。ｗ
49:NAME IS NULL
08/12/28 04:56:16 .net
不要ってことは無いけど、重要視されてないのは事実。
糞なテーブル設計でも、一応動くし、速度も糞高い鯖でも買えば力技で何とかなるのも事実。
PGの学習能力は、そもそも糞なPGなのか、予算的問題で優秀なPGが確保できてないのか、営業的問題で長期運用を前提として無いとかだろう。
営業的には４年程度なんとか動いて、定期的に新しいシステムに更新してもらうのが儲かる。データ移行という名目でぼろ儲けしているのをわざわざ無くす必要は無いし。
運用ならもうちょっと強く逝ってもいいと思うぞ。開発の尻拭いも大変だろうし。
そのままリリースしてしまうと業務に支障がでる！
と強く逝ってやれ。実際、業務に支障が出るのは毎度の事だし。
ある程度汎用的に使おうとすると、結局は最新機能は使わずに終わってしまう事が多い。
このアプリケーションでは対応して無いとかで最大公約数的に使える機能が絞られて行く。
50:NAME IS NULL
08/12/28 07:46:38 .net
むしろテーブル設計よりも、糞クエリを書く奴をなんとかして欲しい
SELECT一文で数KBとか馬鹿もいいとこ
このマシン遅いとか、冗談きついわ
アプリで処理すべきことをDBにやらせて遅くしてるのはお前だ
51:NAME IS NULL
08/12/29 02:43:23 .net
俺の経験だとSQLで出来ることを
アプリにやらせて遅くしてるやつの方が多い。
とても遅くなって困る。
52:NAME IS NULL
08/12/29 17:57:30 .net
URLﾘﾝｸ(capsctrl.que.jp)
53:NAME IS NULL
08/12/30 04:17:20 .net
>>52
なつかしいなそれ。割引金額をアプリで持ってるから
割引率変更になった時点で過去売り上げの改ざんになるのな。
揚げ足取りはさておき、ドメインロジックはまだいいんだけど
クロス集計とか頑張ってやってたのを見てびっくりした事ありますよ。
54:NAME IS NULL
08/12/30 18:59:03 .net
クロス集計って、アプリ側、DB側、どちらで頑張っていたのでしょうか？
今はSQL/OLAPが使えるようになってきて随分楽ですね。
55:NAME IS NULL
09/01/02 13:44:40 .net
>>51
テーブル設計がよろしくなくて、アプリ側でエラい苦労させられたことがある。
SQL書けねえやつに設計させるなと。
56:1
09/01/04 02:15:37 .net
テーブル設計が問題なのか、
SQLが問題なのか、
アプリが問題なのか…についてですが、
結論からいって、全てにおいてまずテーブル設計の問題だと思います。
理由はそれが土台だからです。
テーブル設計がおかしいという理由で、
おかしなSQLを書かざるを得ない状況に陥ることは多々あるし、
テーブル設計がおかしいから、
アプリでおかしな制御をせざるを得なくなったりするんです。
それと、「正規化もやりすぎると使いづらくなる」などという意見がありましたが、
自分は何があっても、どんなシステムあっても、どんな利用用途であっても
RDBでデータを管理する以上、必ず全てを第三正規形まで落とす必要があると思います。
正しくはその正規系を業務や仕様にあわせて（敢えて）「崩す」のです。
だから「正規化はしないほうがいい場合もある」というのは語弊があります。
正しくは「正規化は必ずしなければならない。その上で（状況に応じて）崩すことは構わない」
ということです。
57:NAME IS NULL
09/01/04 08:45:00 .net
モバオクみたいに１人のスーパーエンジニアに全部ヤらせればいいんだよ。
要件定義から設計～実装～テストまで自前でやればドコがおかしいか
自分で気がつくだろうに。
時々、老害が自分の立場を守るためにくだらねぇ自己主張
しまくるから、設計がグダグダになっていくケースがあるしなぁ。
58:NAME IS NULL
09/01/05 21:02:37 .net
一人はそいつが飛んだら終わりだけどな。
二人一組ぐらいにはするべき。
59:NAME IS NULL
09/01/06 03:30:29 .net
さらっと「飛んだら」と書かれてちょっとビクっとした。
「意識が途切れる」「遠いところに逃げる」「宙を舞う」。含意は色々ですが。
60:NAME IS NULL
09/01/07 01:26:04 XvNxYhBN.net
「レコード数が少ないから主キーはいらない」
と真顔でのたまう、うちのSE。。。
61:NAME IS NULL
09/01/07 21:14:01 .net
>>59
飛ぶっていうのは逃げるとか逃亡するとか辞めるとかの意味。
62:NAME IS NULL
09/01/07 22:49:47 .net
まず、Tか島平団地で飛ぶとか、そっちを考えたわｗ
63:NAME IS NULL
09/01/11 12:18:16 .net
全てのテーブルが外部結合を必要なく設計されてるシステムってある？
あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
で判定するのはRDBとしては誤っていると思うんだけど。
RDB設計をまともにやればシステムの便利さは格段に向上するのは間違いない
システムへの要求も高度化するだろう。RDB設計をまともにしない人には
低度な要求を解決する仕事を続けるためにRDB設計を軽視し続ける
べきだ、保身のために。
日本は現場の国だ。現場以外は糞。そしてシステムに関する決定権は
現場には無い。使う側の現場力と開発する側の現場力が糞によって
互いに相反する方向へ注力させられている。まったく無駄なことよ。
64:NAME IS NULL
09/01/12 02:57:32 .net
URLﾘﾝｸ(www.google.co.jp)
設計を軽視するとこうなる
65:NAME IS NULL
09/01/12 10:22:11 .net
>全てのテーブルが外部結合を必要なく設計されてるシステムってある？
>あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
>で判定するのはRDBとしては誤っていると思うんだけど。
RDBでないDBはそうするしかないと思うが。
RDBでそうしているオマエの現場が糞と言うなら「そうだろうな」としかいい様がないわけだが。
「システムに関する決定権は現場には無い」ってオマエがオペレーターみたいな
現場といっても最底辺だとないだろうとは思うが、普通の開発現場なら
あからさまにイカれている設計なんかはレビューや評価で却下すればいいんじゃねーか？
66:NAME IS NULL
09/01/12 11:47:45 .net
>>65
そのレビューとやらに呼ばれないｗ
67:NAME IS NULL
09/01/12 17:55:09 .net
Oracleで対象非対象をレコードが有るか無いかで設計してあるのはやっぱ間違いだよね。
Oracleやってる奴も汎用機COBOLで経験つんだエンジニアばっか。COBOL流のシステム
設計をむりやりOracleに載せてる。それが常識で考えた標準らしいですよ。何も言えねえ。
68:NAME IS NULL
09/01/12 18:43:00 .net
>対象非対象をレコードが有るか無いかで設計してある
こいつはどういう状態のことだ？
つうか、>67はどんな対案が正論だと言いたいんだ？
69:NAME IS NULL
09/01/12 19:02:10 .net
ジョインされる２つのテーブルのキーが1:nになっているべきか1,0:nを前提に設計するかって話だよ
70:NAME IS NULL
09/01/12 20:12:57 .net
んーっと
1:n設計は間違いだっていう主張？
71:NAME IS NULL
09/01/13 00:00:54 .net
>>64
ひどいｗ
これは損害請求レベルじゃないのか
72:NAME IS NULL
09/01/15 03:02:24 .net
ちがう、1:nを守るためにマスタにレコード追加しようとしたら引かれたの。意味無いとか言われて。
73:NAME IS NULL
09/01/15 07:27:58 .net
レコード番号 | 存在フラグ
---------------------------
1 | 存在する
2 | 存在しない
3 | 存在する
or
レコード番号 | 存在フラグ
---------------------------
1 | 存在する
3 | 存在する
の違いって事？
74:NAME IS NULL
09/01/15 07:30:37 .net
あー頭死んでた。
レコード番号 | 対象フラグ
---------------------------
1 | 対象
2 | 非対象
3 | 対象
※フラグ見て対象かどうか判断
or
レコード番号
-----------
1
3
※レコードの存在の有無で対象かどうか判断
の違いって事？
75:NAME IS NULL
09/01/15 08:30:46 .net
>>72
どういう状況でどんなテーブルに何をしようとしたのか端的に説明してくれ。
とにかく状況が小出しじゃ何も判断できん。
76:NAME IS NULL
09/01/16 00:24:21 aohFMQX5.net
>>72
あと、「引く」という言葉の意味が分かりません。
77:NAME IS NULL
09/01/16 03:48:45 .net
はぁ？
ひくわ
78:NAME IS NULL
09/01/16 06:15:57 .net
>>63
なにか、ＲＤＢがあるからデータ入れよう的な考え方に聞こえるぞ
まったく結合するものがないなら、「Ｒ」ＤＢである必要はないわな
レコードがあるかないかで判断するか、（結合された）レコードに書かれてる内容で判断するかは、
それがどういった情報を格納してるかで決定するべきで、ＲＤＢなのだから
必要ない結合先のレコード（や、もしかするとそのテーブルそのものも）を作らないといけないということはないだろう
>そしてシステムに関する決定権は現場には無い
現場は必要もないＲＤＢを使いたくなく使ってるのかもしれないな
そして必要もないのに、ＲＤＢだからどうのこうのという、
現場の空気を読まない原理主義者みたいなやつがさらに話をややこしくするんだ
>>67
口調が違うが同一人物じゃないのか？
ちなみに、ＲＤＢ使った開発でＳＱＬを書いてるやつでも、
exists使ったことないってやつは結構いるだろう
ＲＤＢだから、ＯＲＡＣＬＥだから、レコードのあるなしで判断するのは間違ってるだろうとか
その判断基準がおかしいとしか思えん
まあ、現実的なＤＢの選択としてはＲＤＢＭＳしかない現状もあるがな
79:NAME IS NULL
09/01/17 12:17:11 .net
１さんの言うことはまったくもって正しいんだけど、
実際にこういうことを口に出しちゃうと
「頭でっかちで現場じゃ使えない」って評価になるんだよね
おれがそうだからよく分かるwww
80:NAME IS NULL
09/01/17 13:23:40 .net
制約を強くするとデータを入れにくいじゃない？とか平気で言うPLがいるとやる気0だよね～
それで親の無い子レコードや、不正なデータが山のようにあるんじゃ世話ねーよ
81:NAME IS NULL
09/01/18 01:12:13 .net
そうそう、そんな感じｗｗ
設計と製造の現場はまさに自分はDB設計を軽視してませんって顔して
キーマンの顔色を伺って程度をあわせる世界だよね。アホすぎｗｗ
ここもそんなもんだね。あ～あ
82:NAME IS NULL
09/01/18 01:57:28 .net
>>81
ここもそんなもんだねとか達観した気になる前にここで吐き出せよ。>80みたいに。
それすらできないくせに嘆くな。
83:NAME IS NULL
09/01/18 13:16:55 .net
お前何言ってんの？
84:NAME IS NULL
09/01/18 14:47:36 .net
俺？俺は何も言ってないよ。
85:NAME IS NULL
09/01/18 15:08:45 .net
オレも何も言ってない。
>>86はどう？
86:NAME IS NULL
09/01/18 23:18:56 .net
俺も。
87:NAME IS NULL
09/01/20 01:39:08 .net
39+3 ： すずめちゃん(catv?) [] ：2009/01/20(火) 00:55:46.00 ID:5lC2DwfT (2/2)
市況２のスレを読んだら、どうも
データベースがぶっこわれたみたいで、金曜の取引データが飛んだみたい
で、約定メールから復旧させようとしてるとか
88:NAME IS NULL
09/01/23 23:30:34 .net
取引先の「偉い上司」デター！
ぼくの考えたデータベース持ってキター！
さて、どうすっかな・・・
89:NAME IS NULL
09/01/24 11:34:33 .net
データベース設計が軽視されているのではなく、
データベース設計に携わる人間が軽視されているのだ。
という命題をたててみる。
90:NAME IS NULL
09/01/28 20:45:41 .net
>>89
それは、その人間の行う作業が軽視されてるから、
その人間が軽視されてるじゃないか
そうでないなら、別の人間が代わりにその作業をすることになるだろう
91:NAME IS NULL
09/01/30 17:19:32 .net
そもそもちゃんと仕事できてないから人間的に信頼されて無いとか？
データベース以前の問題だな。
結局、現場の意見のほうが採用されて、ボンクラDBA涙目。
組織で仕事するという条件で目標を達成するためのスキームをちゃんと考えたほうがいいよ。
92:NAME IS NULL
09/01/31 16:21:56 .net
ここ読んでて恐ろしいのは自分の関わったシステムではDB設計軽視して無いって
本気で思ってそうな人がいることだ。RDB的な不備が出るのは現実的に
仕方の無いことだが、あくまでも例外であって、あるシステムの中で数個の
数少ない心残りとして記憶されてしかるべきもの。
こんなバカだらけではキーマンの顔色を伺ってISAMバカ基準でシステムを組んだほうが
計画は立てやすいだろう。RDBMSを使ったPK、ソート、VSAMユーティリティと考える。
だいたいRDBMSをPK、ソート、VSAMユーティリティとしてシステム組んだ経験がある
人だとそれで正解だと誤解しちゃうんだろうな。それで動くから。
底辺会社の底辺システムの目標としてはそれでもいいだろう。動けば底辺客も
文句言わないから。しかし、そんな設計してRDBの特徴を活かさなかったら
RBD以前の非生産性を引きずったシステムが出来上がるわけだよ。しかし、
その非生産性は1円入札して保守で儲けるビジネスモデルでは工数が稼げる
かもしれんよ。いつか関わりたいなRDBのシステム。。。
そういえば某メガバン統合でCOBOLアホシステムで統合決定してるのが象徴的だねえ。
COBOLアホシステム準拠が日本では巻かれるべき長いものと決定したようなもんだ。
93:NAME IS NULL
09/01/31 20:03:29 .net
メガバンのＭ菱サイドの方がオープン系とかにシフトする勇気がないんだろうし。
ああいうのは変に金があるから、コスト度外視の設計しても疑問に思わずに、
「こういうもんだ」と納得してんだろう。
94:NAME IS NULL
09/02/01 04:06:38 .net
Mでは実績が無いだけでしょ。いわゆる前例がないってやつだ。
提案してるベンダもリスク回避として、今のシステム踏襲路線てのも悪く無い決断だと思うけどな。
まずは確実に統合して不具合を出さない事が第一目標だろう。一気に欲張って失敗するくらいなら、落ち着いてじっくり今後を考えればいい。
RDB的に正しい正規化した設計と、現場が把握し易い伝票ベースの設計のどちらがいいかは力関係も大きいし。
95:NAME IS NULL
09/02/01 04:31:52 .net
>>92
お前の考え方は、道具に合わせてものを作れって考え方だ。
それはそれで否定しないが、その考え方だけが唯一の正解のごとく、
他の考え方を貶めるのはやめたほうがいいぞ
96:NAME IS NULL
09/02/01 06:47:01 .net
DBAが満足する、実績の無い新しいシステムで、銀行ATM止めて大迷惑かけてしまうのと、
DBAは不満だけど、実績のある既存のシステムで、銀行ATM止めずに問題なく使えるのと、
どちらを決断するって話だろ。
DBA様の首斬って損害賠償請求逝ってもよければ、勝負もあり。
97:NAME IS NULL
09/02/01 09:20:00 .net
しかしあのメガバンってアフォみたいにATMを停止させてる現実があるんだが。
単に突然使えないのが事前に「メンテナンス」と言う言葉で停止させるかの
違いなんだろうけど、その「メンテナンス」が予定時間オーバーも珍しくないワケで、
利用者としては「アレ？朝には使えるって言っていたのに･･･」ってクレームも
たくさんあるんだが。
結果論からすると「COBOLでも十分に失敗する」と言う前例は今回の合併だけでなく
以前から繰り返されている予定調和な感があるけどな。
U○Jの以前の倒壊＆惨羽の合併ではそんなに混乱は起きていないけど、
ＭとU○Jではこんなにゴタゴタしているのは、両者の技術レベルのギャップが
凄いんだろうなぁ。Ｍは特に悪評高いパッケージだし。
98:NAME IS NULL
09/02/01 14:01:11 .net
それでもまだ復旧の見込みがあるぶんだけ優位だろ。
DBAの提案聞いてオープソ系とか導入して何日も復旧できなかったら終わる。
99:NAME IS NULL
09/02/01 17:25:49 .net
あれくらいの仕事する案件では「失敗した時の復旧プラン」もちゃんと計画に入っているんだがな･･･。
「○時時点でこのチェックポイントをクリアできない場合は戻す」と言う具合に。
そこまでしておいて、それでも予定時間オーバーってのは、
COBOLを前提とするシステムと言うのは性善説に成り立っている仕組みが多いという事だな。
逆にオープン系なんかは性悪説(?)に成り立っている感があるので、
JOBの再投入もやりやすいように設計する人おおいからなぁ。
そして何日も復旧できない事態なんて存在しない。
オープン系が優位とは言わんが、COBOLが実績があって安定性云々なんて
寝言を言う人間は間違いなく現場の金融系の実体を知らん厨房だと思う。
100:NAME IS NULL
09/02/01 22:31:46 .net
>>95
君は知識的にコンプレックスがあるだけだと思うよ。勉強不足だからホントの事いわれると
貶められたような誤解をするんだと思う。スコップをちりとり代わりに使用しても不便だ、
三角より平型スコップならちりとり性もupするよね。実際、いくつかのOracleのバージョン
アップはISAMシステム実装のしやすさも機能強化されていってると思う。
おれはDBAらしい仕事は一度もしたこと無いが、SEのRDBコンプレックスは見苦しい。
もっと使いこなさないと関係モデルは組めん。半端な知識だから破綻してISAMに
逃げることになんだよ。そんなISAMやりたいんならRDBMSを開発する側に回るべき
だね。そこに食い込めないなら引退すべきだよ。老害なのかなと思う。
101:NAME IS NULL
09/02/01 23:10:46 .net
ISAMシステムに逃げるってどういうこと？
102:NAME IS NULL
09/02/02 00:45:23 .net
いつも自分の意見が取り入れなくてストレス溜め込んでるのだろうな。
だれもオープン系のシステムにしてくれないｗｗｗ
Mが従来通りの路線で行くのを理解できないほうが、現場の金融系の実体を知らん厨房でしょ。
だからオープン系のシステムにこだわり続ける。
実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。
オープン系って何日も復旧できない事態って本当に存在しないの？
全部のオープン系システムの事態を把握してるのも怪しいが。
103:NAME IS NULL
09/02/02 06:44:35 .net
>>101
1つの長大なテーブルをいくつものPGでいくつもいくつも作るシステムといえば伝わるかな？
104:NAME IS NULL
09/02/02 21:13:41 .net
>実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。
現に動いてないと言う実態を知らんのか？
あのメガバンのメンテナンスと言う名の停止っぷりは半端ないが。
当初のスケジュールがどんどん遅延して何年かけて統合するつもりなのか知らんが、
現場はいい迷惑だ。
105:NAME IS NULL
09/02/02 21:55:10 .net
噂によく聞くコボラーってやつか。
本当にそんな人種いるの？
それならExcelでいいじゃんよｗ
106:95
09/02/02 22:46:33 .net
>>100
俺は別にコンプレックスをもって言ってる気はないんだがな
お前のいうホントのことって何だ？
まあ、お前がＲＤＢ使ってないのはバカ基準で底辺のアホシステムだと
考えてるというのはよくわかった
まあ、思っててもあんまり簡単に他人をバカだアホだ底辺だといわんほうが良いよ
107:NAME IS NULL
09/02/03 01:53:50 .net
>>104
オープンだろうが大型汎用機だろうが関係なく、あんな大規模なシステム統合を本気で丁寧に障害なく
進めるならあれくらいは当然だと思うよ。
見切り発車のＭとみっちり石橋たたきのＭ。どちらがいいか経営者には良い判断サンプルになったんじゃないか？
石橋を叩くのを選べるほど金が使えるのはＭくらいだろうけど。システム部長は石橋を叩けるだけ叩くのが仕事だわな
108:NAME IS NULL
09/02/03 23:24:57 .net
プロセス中心で考えるエンジニアとデータ中心で考えるエンジニアが
理解し合うのははっきり言って無理
109:NAME IS NULL
09/02/04 06:37:55 .net
お互いに相手の領域を理解すれば効率が何倍もあがるというのに。
110:NAME IS NULL
09/02/04 23:06:33 .net
>>109
いや相容れないだろ。このスレ読んでもわかるように
それぞれの優先順位が違いすぎるもの。
プログラム言語の違い以上に深い隔たりがあると思う。
新人の時からデータ中心アプローチをたたきこまれた俺としては、
９２さんの文章は少し挑発的だけど、内容はけっこう共感できるよ。
111:NAME IS NULL
09/02/04 23:09:25 .net
自演乙
112:NAME IS NULL
09/02/05 00:48:16 raK4Q0Jb.net
というか、
>>1によると、ここでは「業務システム」についての設計の話だそうだから、
データ中心で考えるのが正解ではないのか？
113:NAME IS NULL
09/02/06 15:01:56 .net
>>109
理解するだけではだめだな。妥協が必要
ただ、その妥協点は、かなりどっちかよりでないと成立しない
実際は設計するときにどっちの考え方でやるか統一しとかないとだめだな
>>112
業務システムの設計だから、データ中心が正解だという理由を説明してほしいもんだが
プロセス中心の設計は間違いなのか？
データーベース設計の話だから、データ中心の方が良いというのなら理解できるんだがな
114:NAME IS NULL
09/02/07 02:03:06 .net
業務システムをプロセス中心で開発するってのは
たいがいにおいて業務プロセス中心に開発するんじゃなくて
システムプロセス中心に開発するの意だからな
115:NAME IS NULL
09/02/11 13:36:01 .net
かくしてエンジニアのオナニー状態の使えないシステムが作られて行く訳だな。
そして次の契約が取れず淘汰されて行く。
116:NAME IS NULL
09/02/11 15:45:17 .net
>>115
いや、逆でエンジニアにオナニーさせたほうがいいものができるぜ。
マネージャのオナニーの結果、よくないものができてるのが現状でしょ？
マネージャとエンジニアのセックスなんてありえないでしょ？
117:NAME IS NULL
09/02/11 16:50:55 .net
>>115
DB設計は家を建てるのに例えれば基礎工事みたいなもんでしょ
外観や内装に注文つける客はいても、基礎工事に注文つける客はいないでしょ
118:NAME IS NULL
09/02/11 17:54:21 .net
見えにくい部分だけあって理解も無いから。
ここは地盤が緩いから事前にこれだけアンカー打ち込んでおけと
指示しても施工出来る人がいないとか後での設計変更が云々とか。
DB設計軽視はシステム開発の耐震偽装みたいなものかな。
119:NAME IS NULL
09/02/11 18:26:50 .net
>>116
一番怖いのは、営業と客のオナニー
日本ではマネージメント専門の人はプロジェクトにいないのが普通
そういう意味では真のマネージャーなぞ存在しない
120:NAME IS NULL
09/02/14 02:52:52 .net
>>1
情報系の人間がただでさえ軽んじられてててさ、
当社では工学部おっけ～、文系でもおっけ～、だれでもおっけ～みたいな会社ばっかで
まともに学校でDBについて勉強したことないやつが多すぎるからだろ
情報系はもっとも理解されてない学科
121:NAME IS NULL
09/02/14 03:20:54 .net
会社で昼休みにテクデの勉強してたら資格オタク扱いされたなぁ
122:1
09/02/15 13:28:47 .net
>>120
文系、理系の問題ではないと思います。
私は文系ですし。
123:NAME IS NULL
09/02/19 23:58:36 .net
>>120
ふむ。
今の情報系の学科がどのようなカリキュラムか知らないが、
大学出の者を戦力と考える会社はいまどき居ないだろ。
会社としては2,3年掛けてようやく戦力として使えるかな？
という人間を探しとているということではないかなぁ。
それには出身の大学、学部、学科はあまり考慮されないと思う。
124:NAME IS NULL
09/02/20 15:11:09 .net
でも地頭は大事。新卒の場合、出身大学のランクを元に、見込みで採用してるだけ。
中途なら、出身大学のランク高くても、経験や実績無ければゴミだろ。
IT系は専門知識不要で採用してしまうからな。そして現場で不良施工状態のデスマ。
ちゃんとIT理解してる理系が、人嫌いでPCにばっかり向かっていて、客との対話を営業任せで放棄してるのも、低コストで短納期で突貫工事的な変な仕様で迷走する理由の一つだと思う。
客は住み易さとか快適性能に重点置いてるのに、施工してる側は基礎工事だけに専念していいものが出来たってオナニーを満足してちゃ意味無いだろ。
家は３回建て直さないとまともなものが出来ないように、システムも１回で使えるものが出てこないのは、理系のオナニーのため。
125:NAME IS NULL
09/02/20 19:30:18 .net
釣りか？！データモデル設計とテストデータ実装、本番データの実装、ACCESSのクエリーなりでＵＩ概要とすれば
ＰＧ無しで開発できる。プロトタイピングからスパイラルモデルで進めれる
２サイクル目でＰＧの帳尻合わせなんかしないリモデルリトライだ
だいたい物理的組み立て積み上げで作る家なんかと比較してるなんて現実にあるシステムの機能を
知らな過ぎ
126:NAME IS NULL
09/02/21 01:48:51 .net
まあ
二人ともモノ知らなさ過ぎな事はわかるがｗ
127:NAME IS NULL
09/02/21 10:45:09 .net
>>125
突っ込みどころ満載だなwww
128:NAME IS NULL
09/02/22 21:31:56 .net
できるのに大学行かないやつも迷惑だよな
129:NAME IS NULL
09/02/26 09:29:54 .net
底辺大卒の悲壮ですか？
130:NAME IS NULL
09/02/28 16:59:28 hnW2hUJ8.net
正規化も3層スキーマの考え方も身についていないような奴が
DB技術者を名乗っちゃうから嫌になる。
自称DB技術者のおっさんが主キーがどれかすらはっきりしない
テーブルもどきの何かを作ってきたんで正規化してくれと頼んだら
しばらくネットで何かを調べた後にテーブル数が増えてわかりにくくなるから
正規化しなかったと言い訳してきた。
よくネットでテーブル数が増えるから正規化はしなくていいなんていう
無茶苦茶なことを書いてる似非DB入門サイトがあるが、それに騙されちゃったんだろうな。
131:NAME IS NULL
09/02/28 18:29:31 .net
問題を指摘されたらググって言い訳を探す医者や自動車設計者が
いたら結構イヤン。
132:NAME IS NULL
09/03/01 00:06:37 .net
でも使ってるうちに正規化が崩れていくのも事実。
データベースがどのような事に使われていくかはシステム稼働後にしか分からないし。
呼び出してるDBアプリほど、柔軟には、DB側は組み直しとか出来ないし。
簡単に正規化組み直しとか出来る機能が付けばいいけどね。
133:NAME IS NULL
09/03/01 09:56:25 .net
DBの組みなおしは簡単に出来るよ。それこそ制約に従ったSQL書ければ簡単だよ。
組み直しが難しいのはPG
134:NAME IS NULL
09/03/01 11:37:45 .net
>>132
使う、っていうのが、システムの変更も含めているのならまあそうかもしれん
だが意図して正規化を崩すのでなければ、変更した技術者のスキルの問題だろう
普通はシステム稼働まえに、設計の段階でどのように使われるか考えるものだろう
DBの変更はプログラムの変更に比べれば簡単だと思う
簡単であるが故に、設計がおろそかになってるんじゃないかと思うな
135:NAME IS NULL
09/03/01 15:12:16 .net
そこでスレタイですね
136:NAME IS NULL
09/03/01 23:46:49 .net
だからPGはあとまわしでPGによる調整が必要ないところまで
データモデルを作り上げてインプットとアウトプットを固めないと
糞PGになんじゃん
137:130
09/03/02 08:43:58 aM7tqfv0.net
>>132
何を言ってるんだか。
おまえは半年仕事を休んでデータベーススペシャリスト試験を
本気で合格する気で勉強してみろ。
言っておくがオラクルなんかのベンダー資格なんてとっても意味はないぞ。
基本が身についていない奴が製品に依存した知識を持ったところで意味はないからな。
まったく、嫌になる。
138:NAME IS NULL
09/03/02 19:08:00 .net
１０年使ってきたDBの変更と、１０年使ってきたウェブアプリの変更どっちが簡単か自明だと思うけどな。
１０年後まで考えてデータベース設計するのは無理。
最初は在庫管理で作ったのに、拡張で顧客管理も入って、更に拡張で売り上げや経営財務管理まで入ってくるし。
アナログ的に言うと、社内帳簿フォーマット変えるのと、利用してる現場担当者入れ替えるのとどっちが簡単かって話。
139:NAME IS NULL
09/03/03 23:10:30 .net
利用者の顔色を伺って利用者と良好な関係を保つのが仕事をうまくすすめるコツだな
問題は糞利用者が使ってる糞帳簿を改善することではないんだよ。デジドカの鉄則だ
140:NAME IS NULL
09/03/03 23:53:30 .net
老害コボラー臭のするヤツがいるな
他の板に居場所ないのか？
141:NAME IS NULL
09/03/04 03:34:01 .net
↑うまくいってる？
142:NAME IS NULL
09/03/04 14:46:46 .net
>>141
ちゃんと安価書けよこのうんこ
143:134
09/03/04 17:38:20 .net
>>138
自明って、お前の主張はどっちなんだ？>>137への反論なのか？
144:NAME IS NULL
09/03/13 01:10:06 .net
>>132はある意味、「真理」に近いと思う…
最近は単純に「上流」工程だの、「下流」工程だのと、
誰かが宣伝したテンプレに従い過ぎだ…
んなもん、ケースによって全然違うんじゃ～い！
145:NAME IS NULL
09/03/13 02:07:07 .net
実務の世界の人間ではないのですが、「使っているうちに正規化が
崩れる」というのは具体的にどういう状況を指すのかちょっと興味が
あります。
更新のコストが馬鹿にならないので非正規化する、というケースは
理解できるのですが、例えば業務内容に上手くマッチしなくなった
のでスキーマを改変する、というケースであれば、なんで改変後も
正規形を満たすように改変しないのかな、と素人考えでは思って
しまいます。
もし宜しければ簡単な例など教えていただけないでしょうか。
146:NAME IS NULL
09/03/13 09:11:07 .net
「正規系が」業務内容に上手くマッチしなかったんだろｊｋ
147:NAME IS NULL
09/03/13 13:28:46 .net
スキーマ改変したら、アプリ側の改変しないと駄目で、予算的に膨大になるでしょ。
スキーマ改変なんて現実は、なかなか遣れない。スキーマ改変について来れるようにアプリ側で対応してるのも見た事無いし。
148:NAME IS NULL
09/03/13 15:08:04 .net
お客さんに、「いちいち明細なんて入力するの面倒くさいし
そもそも決まった数以下しかないから」っていわれて
しかも見出し・明細が1行のレコードとして
外部と連携したりなどなどで正規化やめたことはある。
149:NAME IS NULL
09/03/14 19:50:11 .net
>>146
それはその技術者のスキルが低いからうまくマッチングできないんだろ
>>147が言う、既存部分の変更を嫌がるのが一番の要因だとおもう
あとは>>148のいう、外部要求に合わせるためか。
こっちはできれば、ビューとか外部出力するアプリでの操作で回避したいとこではある
150:NAME IS NULL
09/03/14 21:37:15 .net
>>149
なるほど。>>148の繋がる相手に合わせる、というのはよく分かる
気がします。
>>147はまだちょっと難しいです。
既存のスキーマを改変するのはなかなか難しいというところまでは
理解出来るのですが、スキーマを改変しないならそもそも正規形も
崩れようが無いのでは？と思ってしまいます。
これは例えば住所を2件持てるようにしたいので一つの住所カラムに
タブ区切りで2個住所を入れちゃうぞとか、スキーマはそのままでも
入れるデータによって正規形が崩れてしまうような状況を指している
のでしょうか。
151:NAME IS NULL
09/03/15 01:02:31 .net
データってのは、ただ溜め込むだけじゃなくて、いろいろな事に使われて応用されていくもの。
いろいろなデータが追加されていくと、正規化が崩れていく。
１０年拡張もせずに動かすというシステムなら、正規化は当初のまま有効だろうね。
152:NAME IS NULL
09/04/07 23:03:52 AzDX/Nl7.net
accessと汎用系DBとでは、設計手法が異なると聞きましたが本当ですか？
153:NAME IS NULL
09/04/08 03:28:48 .net
どこまでを指して設計手法としてるかにもよると思うが、
たとえばアクセスだとトリガやストアドプロシジャが使えない
そういった、アクセスではできないことを考慮した設計は必要
テーブル設計での正規化とか、そういった基本はあんまり大差ないとは思うが
154:NAME IS NULL
09/04/08 07:26:18 .net
>>152
その人の言う「汎用系DB」って、IMSとかのことだったりしてな。
155:NAME IS NULL
09/04/08 08:52:29 +UUt8naG.net
正規化されてないDBを見て
それを非難するやつがいたとしたら
そうなるまでには経緯とレベルがあるなんて
理解出来ひんねやろうな。
DBがあります。それが正規化されてるとします。
その場合は
１仕様策定の主導権がDB側にある
２パッケージソフト
３数人で作った小規模システム
４出来たてのシステム
５システム仕様が業務効率化など低レベルなもの
かな。
>>1は、特定の部署でしか使わない、今まで手でやってた仕事を
システム化しましたみたいな
入門者みたいなシステムしか作ってないんちゃうかな
156:NAME IS NULL
09/04/08 11:18:57 .net
うわー盛大なバカが出た。
157:NAME IS NULL
09/04/08 12:54:06 .net
>>155
正規化されてないDBに経緯があるのは理解できるがな、
レベルってのはなんだ？レベルが低いから正規化されてないのか？
そんなの非難されて当然だろう
お前の言い分だと、正規化されていないのが当然のように聞こえるが、
お前こそ入門者みたいなシステムしか作ってないんじゃないのか？
>>1は何も正規化だけを問題にしてるんじゃなくて、
設計が大事なのになぜ軽視されてるんだろう、って話だが
お前みたいなやつがいるからなんだと思ったぜ
158:NAME IS NULL
09/04/08 21:25:23 pRRCN4Xu.net
>>153
遅くなりましたが、
ありがとうございます。
ﾄﾘｶﾞ、ｽﾄｱﾄﾞﾌﾟﾛｼｼﾞｬ、頑張って調べます。
159:NAME IS NULL
09/04/08 23:28:49 .net
さすがに>>155は釣りだろｗ
160:NAME IS NULL
09/04/08 23:33:40 .net
正規化しといても、どんどん拡張していくうちに崩れてくるしな。
正規化したくても全部のアプリ作り直しは無理。
ｽﾚﾘﾝｸ(db板)
頼むから正規化しろよ 第二正規形
161:ER図
09/04/28 01:30:12 .net
突然ですがアドバイス下さい。
アパッチのアクセルログで取れる情報のER図をかけといわれたのですがどんな感じのものをかけばよいでしょうか？
一応アクセスログの仕様については調べたのでログフォーマットとかカスタムログとかの記述方法はわかるのですが
これをER図にしろと言われたらよく意味が分かりません
データベースのテーブルでもないのにこんなもんをER図に出来るもんなのでしょうか
よろしるおねがいします
162:NAME IS NULL
09/04/28 21:50:03 .net
データベースのテーブルとアクセスログは全く同じ形式じゃないか
163:NAME IS NULL
09/04/30 01:51:22 .net
アクセスログをどう使いたいのか、要件がわからないままなら、ログのフォーマットそのものなテーブル１つで終わる。
でも、きっとそんなことは無いはずなので指示者に一応確認してみる。
うまく聞き出せないなら、指示者が長期休暇中なら、貴方が｢こういう使い方したら便利だよね｣と思う使い方を想像し、それにあわせた構成でER図を描けばおｋ。
あとはログフォーマットの各項目をそれぞれ配置する、と。
ついでに｢こういうことするならこんなデータも無きゃいけませんよね｣ってな要素を付け加えて提案してみるのも良いのではないかしらん。
例えば、IPアドレスのブラックリストを準備して、ログテーブルとIPアドレスをキーにジョインして｢ブラックリストのIPからのアクセスだ｣とわかるような仕組みを入れてみるとか。
164:NAME IS NULL
09/04/30 02:27:37 .net
もし、運用目的の話ではなく、純粋に情報の構成をER図であらわせ、って話をしているのなら、大雑把に言うと
・IPアドレス
・ユーザ
・アクセス日時
・発行メソッド(参照URL)
・ステータス
・他もろもろ
がどういった関連を持っているか書け、と言う事なのでしょうね。
例えば、URLを中心において
・そのURLに紐づくユーザ
・そのURLに紐づくIPアドレス(アクセス元IPアドレス)
・そのURLに紐づくアクセス日時
といった要素の関連を書き表すとか。
学校の宿題なのか、新入社員さんの研修課題なのかわからないけど、まぁがんばって。
165:NAME IS NULL
09/05/01 07:02:14 .net
課題だとしても実用的じゃなさすぎる。
出したやつは馬鹿だなｗ
166:NAME IS NULL
09/05/02 16:13:53 .net
そうか？
結構こういう汎用ログからのデータ収集って実社会で役に立つと思うが。
注目してる香具師が極端に少ないだけで。
普通にアクセスログ表示ソフトがどんな項目で分析してるか調べるといいと思う。
ｽﾚﾘﾝｸ(db板)
「ビジネス」BIツール「インテリジェンス」
ｽﾚﾘﾝｸ(hp板)
【アクセス解析】Google Analytics 5
ｽﾚﾘﾝｸ(hp板)
詳細なアクセス解析をしたい！！！
ｽﾚﾘﾝｸ(php板)
Analogスレ
ｽﾚﾘﾝｸ(unix板)
統合監視ツールどうよ?
ｽﾚﾘﾝｸ(linux板)
GNU/Linux とネットワーク/セキュリティ
あと、IT監査とかで結構需要は多い。一般ソフト並みとはいかないけど。
167:NAME IS NULL
09/05/02 17:29:02 .net
>>166
よく読め。ログをERで表せって話だ。
168:素人
09/05/11 00:45:40 .net
すみません。オッケーウェブで質問して、回答ももらったのですが、回答が１件だけだったので
もう少し他の意見も参考にしたいと思ってこっちに来ました。オッケーウェブの方はもう締め切って
あるので、マルチだと言わずに聞いて欲しいです
僕が質問したトピックはこちら
URLﾘﾝｸ(okwave.jp)
ＥＲ図が削除されていたのでもう一度アップしました
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)
確かに回答の通りこの場合はok_ngで検索すればいいだけなので冗長だと思いました。
そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？
使い分け方とメリットデメリットあたりが聞きたいです。
それと、１対１のテーブルは、たまたまマイレージプログラムと乗客のテーブルで見たのですが、
それは「特殊」なパターンなのでしょうか？それとも一般的なものでしょうか？
そのあたりも教えて下さい。
169:NAME IS NULL
09/05/11 05:28:05 .net
｢こういう理由でこの１対１の関係を作ったのだけど、どういった問題があるか指摘して欲しい｣
のような話でないと、なんともいえないです。
｢合格者テーブル｣を作った理由ですね。その理由からメリットデメリットが導かれてくるんじゃないかなぁと。
訳もわからず、理由も無く、なんとなく作ったのなら、それは意味が無いし先の回答者の様な返事になるだけですよ。
※自身で「冗長だ」と思うならそういう設計をしなければ良いわけで....何故悩むのかと。
もし本を読んで見つけたのならそのデータ構造を作る理由を読み直して理解した方が良いです。
※あと、「そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？」も
ちょっと意味が判りかねます
170:NAME IS NULL
09/05/11 08:54:15 .net
なんでマルチが嫌われるのかと言えばだな、回答した香具師に失礼だからさ。
okで回答した香具師に失礼と思わない訳？
にちゃんで回答した香具師にも失礼な行動は予想出来るよな。
にちゃんで回答してもらったが、納得出来ないので教えて欲しいと他所でまた訊くのだろ？
171:素人
09/05/11 09:31:11 .net
大変失礼しました。
172:NAME IS NULL
09/05/25 05:26:51 .net
結局、 >>161 も>>168 も音沙汰無しなんだな。
後日談とかちょっとだけ楽しみにしてた私はマヌケだった。ﾊｽﾞｶｼ.....
173:NAME IS NULL
09/05/26 07:16:07 .net
今にちゃんでの回答に納得出来なくて、他所で訊いてる所だろ。
174:NAME IS NULL
09/06/18 01:33:24 .net
えーと、初めてのオラクル案件でマスタテーブルを
UNIONで結合したような統合テーブルが設計されていたのだが
オラクルが特別なのか、案件が特別なのかどっちらでしょうか。
175:NAME IS NULL
09/06/18 21:46:40 .net
統合テーブルってなに？
viewのこと？
176:174
09/06/18 23:37:09 .net
すまん、それは漏れが感じたテーブルのイメージ名。
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･･･
177:NAME IS NULL
09/06/19 00:47:06 .net
特別だからってどうなるの？ 指定なら対応するしか選択肢無いと思うが。
178:NAME IS NULL
09/06/19 01:05:15 .net
>>174
オラクルに限ったやり方ではないし
特別ってほど奇異でもない
ただ例としている部門と消費税を一緒にするのはエスカレートしすぎって感じ
179:NAME IS NULL
09/06/19 03:25:51 .net
単にテーブルだけ出してきて、それが特別かどうか聞かれてもな
もしかしたらものすごく特別な使い方してる可能性もあるし、
結構見られるようなものかもしれない
汎用的なマスタとして使ってるのかもしれない、リポジトリのような使い方かもしれない
が、使ってるDBMSだ何だろうと、そのテーブルがそのままの形なら
設計やり直してくれとお願いするな、俺ならｗ
180:NAME IS NULL
09/06/19 06:01:10 .net
消費税なんて変わりそうなものは別に分けたいね。
まあその時の担当じゃなければどうでもｗｗｗ
コボルベースの設計とかを引き継ぐ理由とか有るのでは？
181:174
09/06/19 21:37:46 .net
>>178
オラクルだからって事ではないんですね。
>>179
リポジトリではないですね。
汎用的なマスタなんだろうけど汎用性が高すぎる。
次のプロジェクトから設計やり直しをお願いしてみるよw
>>180
なるほどコボルベースの設計か、
設計者が実績あると言っていたから伝統なんだろうな
ASP.net2008で開発してDBが伝統か
182:NAME IS NULL
09/06/19 22:07:28 .net
中身のない実績なんだろうな。
183:NAME IS NULL
09/06/20 08:47:31 .net
昔コボルでの実績だろう。
184:NAME IS NULL
09/06/20 10:17:54 .net
しかしその何がどう問題なのか、正しく指摘できる者はいないのであった。
185:NAME IS NULL
09/06/21 08:51:28 .net
コボルにも対応出来るのが普通だしな。
ちゃんとコストとか実行速度のデータ示せないと検討も出来ない。
186:NAME IS NULL
09/06/22 21:30:17 .net
>>184-185
釣れますか？
187:NAME IS NULL
09/06/22 23:32:51 .net
3日粘ってようやく一匹。
188:NAME IS NULL
09/06/24 00:24:45 .net
すいません、正規化を俺が望まなければちょっとの修正ですんだものを、
DB構造もプログラムも大改修して多大なコストがかかりました
技術屋として間違ってはないと信じてる
でも経営としては間違ってるんだろうな、きっと
189:NAME IS NULL
09/06/24 06:53:19 .net
>>188
将来のデータ不整合、障害発生のリスクと
目先のコスト、どっちが大事かな。
まぁ、派遣切りのご時世だもんな。
190:NAME IS NULL
09/06/24 09:00:48 .net
金がかかったそもそもの原因は正規化のせいじゃなくて
元々の設計がダメだったせいってなんで気がつかないの
191:NAME IS NULL
09/06/24 16:12:25 .net
表層に現れるのは「修正にコストかかった」ってことだけだからな
お偉いさんには「こんな簡単なことに時間かけて何やってんだアイツは」としか映らない
技術者をないがしろにしてきた代償だよ
192:NAME IS NULL
09/06/24 19:12:46 .net
>>188
もともと正規化してなかったので、そのちょっとの修正の「ついでに」
正規化した、というのであれば、そのコストは、ついでの作業に伴い発生したコスト
技術屋って言い方すればコスト意識を無視できるわけではないと思うがな
ｘｘ屋さんってのは、ｘｘを売るから屋なわけで
コスト関係なく技術的に最善最上な状態でないと気に食わないというのであれば
それは技術原理主義者とｗ
コストとのバランスをとれるから技術者じゃなくて技術屋なんだと
193:NAME IS NULL
09/06/24 19:32:12 .net
しかし、コスト至上を理由に次々とパッチワークしていったシステムはひじょうに脆く、改定に対する耐性が格段に低くなる。
全てを「自分の好みに修正」したいってんなら、お前なにやってるんだの世界だけど。
後まで見据えての決断であれば技術者の良心だろ。
姉歯はいかんよ、姉歯は。
194:NAME IS NULL
09/06/25 00:20:29 .net
元々の設計のままでのコストの発生具合による。
好みや良心の技術第一主義で通しても、理解してくれる客は少ない。
でも自分のアピールや努力が足りずに、姉派みたいな弱い立場に陥るのは技術第一主義者には多いと思うよ。
漏れは設計しか遣らないとか逝っても、設計外の人間に理解してもらえる事は少ない。その積み重ねがどんどん立場を弱くして、設計だけしか頼まれない弱い立場で責任だけ押し付けられる事に成る。
設計に金を出してくれる客と良い関係を築けての商売。
195:NAME IS NULL
09/06/25 04:53:37 .net
>>193
その、しかしってのは>>192を受けていってるのか？
技術屋ならバランスとれっていってるのに
コストのために犯罪犯すような話といっしょにするなよ
>>194
すくなくとも今のソフトウェア産業において、設計だけでは
ビジネスとして成り立たないと思うがな
本来客は、設計に金をだすんじゃなくて、プログラムやシステム全体に金をだすわけで
その中の設計に配分される割合が低すぎる＝設計が軽視されている
それは客の理解の問題じゃなくて、売り側が過当競争によって
目に見えにくいコストから削ってるからじゃないかと思うが
196:NAME IS NULL
09/06/25 06:13:48 .net
だから設計でちゃんとコストが変わる事を設計担当がアピールするのが大事。
何もしないから、配分の割合減らされて、コスト削られてるのだよ。
197:NAME IS NULL
09/06/27 01:37:32 .net
>>196
これって客先に説明しておしまい。ってならいいけど
無知な上級SEが良いところ見せようとして・・・説得したあとから
平気で台無しになるようなことをしてきて、あとよろしくって♪って感じの多いわな
198:NAME IS NULL
09/06/27 07:52:04 .net
上級SEぐらいおさえられないでどうする
身内の敵はもっと上だぞ
マネージャーやら社長やら・・・
199:NAME IS NULL
09/06/27 08:56:32 .net
常に人減らせないか、安い人材に出来ないか考えてるからね。
そういう人たちにも、ちゃんとした設計がコストに影響する事を示せないと負け。
200:NAME IS NULL
09/06/27 21:04:36 .net
逆に考えて、
設計がコストに影響することを理解できないような人たちが、
マネージャやら、〇〇長やらを
やってることが問題なんじゃない？
で、この問題をどう解決するか、なんだか。
201:NAME IS NULL
09/06/28 00:47:26 .net
日本で仕事をしない。
これ最強。
202:NAME IS NULL
09/06/28 02:52:03 .net
理解しなくても、会社の資本金を出してたり、出資者から任命されてたりするから権限持ってる。
文句有るなら自分の資金で設計遣ってれば良い。
203:NAME IS NULL
09/07/27 20:54:41 .net
どんなまずい設計のシステムでも、
実際に運用されていて問題のないものはあまりいじらないものだよ。
204:NAME IS NULL
09/07/28 06:21:49 .net
まずさ加減に寄るな。
致命的なのや、将来的に問題になりそうなのは苦労してでも弄らないと後で困るよ。
弄らないまでも、報告だけはしてシステム関係者の中で共通認識は築いておくべき。
後で、問題が起きてからDB担当の個人の責任にされたほうが割喰うよ。
205:NAME IS NULL
09/07/28 21:02:53 .net
もちろん問題点の把握はしておかなければいけない。
あと、問題が発生して誤動作したときのリカバリーの手順とかもマニュアル化しておく。
206:NAME IS NULL
09/07/29 03:38:45 .net
誤動作する時点て致命的じゃないのかなあ。
データ失うよね？
207:NAME IS NULL
09/07/29 14:16:26 .net
>>203=205は
もっともらしい事言いたいだけの
他の板に居場所がない老害コボラー
208:NAME IS NULL
09/08/10 19:46:20 fUpv0ZNe.net
>>206 完璧主義者の集まりが作ったシステムなら あっさりデータなくなるだろうけど
多少の開発経験がある人が居れば DB経験がなくても バックアップや履歴、ログは残るはずだよ
スムーズに復旧できるかどうかは別の問題だが…
209:NAME IS NULL
09/08/22 00:12:51 /H1vAtQw.net
むやみに正規化できないケースはいくつもあるぞ。
顧客コードとそれに対応する顧客名称などがテーブルにあっても、
実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
顧客名称のみ画面から入力したいという与件があったりするケース。
ＥＤＩで顧客からマスタと依頼データをもらっていて、
依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
いけないケース。
複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
必要があって、下手にデータの持ち方を変えてしまうと、
明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
210:NAME IS NULL
09/08/22 02:06:14 .net
>>209
>顧客コードとそれに対応する顧客名称などがテーブルにあっても、
>実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
>顧客名称のみ画面から入力したいという与件があったりするケース。
>ＥＤＩで顧客からマスタと依頼データをもらっていて、
>依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
>いけないケース。
これは別に全然問題ない
「顧客名称のみの登録もできる」
「依頼データをもらった時点の値を保持する」
という仕様のもとに設計して正規化すればいいだけの話
>複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
>必要があって、下手にデータの持ち方を変えてしまうと、
>明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
これはありがちな話で、実際妥協してしまうことも多いんだけど
そもそも「明確に仕様化されていない部分」があることが問題なわけで
正規化できない理由にはしてほしくない
211:NAME IS NULL
09/08/22 03:20:06 .net
その辺は正規化してちゃんと効果有るの？
正規化したいだけの自己満足程度？
212:NAME IS NULL
09/08/22 04:39:23 .net
>>211
正規化することに理由を求められてもな・・
逆に「正規化しないこと」にこそ理由が必要だと思うんだが
逆に質問していい？
「君の会社の開発標準において、論理データモデルを
作成するという工程はないの？」
213:NAME IS NULL
09/08/22 06:57:35 .net
あるわけがない。
214:NAME IS NULL
09/08/22 15:07:29 .net
最近、クラウド絡みでKVSって聞くけど、別にクラウド云々関係なしにKVS的な構造ってどうなんだろ？
例えば会員テーブルというのがあったとして通常なら（型とサイズは面倒なので略）
create table 会員(会員番号,姓,名,性別,住所,誕生日)
レコードは
00001,会員,太郎,男,東京都,2000/01/01
00002,会員,花子,女,神奈川県,2000/01/02
ってな感じだろうけど、それを
create table 会員(会員番号,属性コード,値)
00001,001,会員,...
00001,002,太郎,...
00001,003,男,...
00001,004,東京都,...
00001,005,2000/01/01,...
00002,001,会員,...
00002,002,花子,...
00002,003,女,...
00002,004,神奈川県,...
00002,005,2000/01/02,...
基本的にジョインはしない。複数テーブルの情報が欲しければそれぞれのテーブルからその都度取る。
メリットとしては
・SQLがきわめて単純になる。
・DB構造に頭を悩ませる必要がなくなる。
・スケールアウトしやすい。
・項目単位でロックが掛けられる。
デメリットとしては
・レコード数が多くなる。
・今まで1つのSQLで取得できてたものが複数回のSQLになる。
・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
個人的にはSQLが単純になるというのが大きい。複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
もちろん、全てのケースでこの形でうまくいくとは思えないが多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（究極的にはテーブルは一つで全レコードがそのテーブルの中。レコードを区別する為のコードがさらに必要にはなるけど）
215:NAME IS NULL
09/08/22 15:16:00 .net
RDBすてろよｗ
216:NAME IS NULL
09/08/22 18:01:32 .net
>>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
>・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
>多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
頭使わなくて済む個所が減ったらダメだろｗ
いままでSQL書いただけでやってくれてたことを、全部自前で実装するんだぞ？
プログラムしないといけないことも増えるし、頭使うとこも増えると思うがな
>今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（
いまのRDBMSでも、やろうと思えばそういう風にできるわけだ
でも普通はみんなそんなことはやらない。それが答えだと思うがな
メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
217:NAME IS NULL
09/08/22 18:50:31 .net
>>216
>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリットになると思います。
>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。
>頭使わなくて済む個所が減ったらダメだろｗ
”余計な頭を使う箇所が減る”の間違いでした。
>メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
>このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
おっしゃるとおりで、このスレッドの趣旨には反しますがこれが一番のメリットと思います。頭を使う必要が少なければ、設計する人によって品質がバラバラという可能性が減るのではないのでしょうか（こういう構造で業務を満たせるのであれば）。
職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
218:NAME IS NULL
09/08/22 19:11:02 .net
>>214
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ
219:NAME IS NULL
09/08/22 21:45:36 QZMSHBrB.net
開発効率が３０年前に逆戻りすることだけは確実だな…
220:NAME IS NULL
09/08/22 22:12:18 .net
馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。
221:NAME IS NULL
09/08/22 22:19:41 .net
>>217
>職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
逆だ。DBでやらない分アプリでやることが増えて、
プログラマの腕頼みになるだけだ
みんなが言ってるとおり、時代に逆行しているよ
222:NAME IS NULL
09/08/23 00:47:33 .net
カスは時給安くても働くから、時給高い熟練は不要になるしな。熟練にしか出来ない正規化とかの無駄な仕事が必要ｗｗｗ
単にDB使いこなせないからアプリでがんばるよ的発想だよな。
SQLを使ってたほうが遥かにパフォーマンスが良い現実。
これまでの歴史で今の状況に成ってるのを理解しないと。
オブジェクト廚が、オブジェクトDBなら便利になるぜとかのたまってたけど遅くて結局は消えてるし。
また馬鹿が湧いて、無駄な事を繰り返すのかな。
223:216
09/08/23 01:05:42 .net
>>217
>最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリット
クラウドにしやすい、ゆえにスケールアウトしやすいメリットがあるっていうならわかるが
クラウド云々関係なしに ってのはお前の出した前提条件だが？
クラウドにしないでスケールアウトってんならデータ形式はあんまり関係ないだろ
あくまでクラウドに適してるのがメリットであって、スケールアウトは副次的な話だ
>SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。
オプティマイザが入るSQL処理でさえ簡単にそれだけの差がでる。
自前アプリでその処理をやるわけだ
みんながみんなSQLのオプティマイザより賢くプログラム組めるのか？
>みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。
みんながみんなプログラムのエキスパートであれば問題ないのですが。
それに比べれば(SQLの方がオプティマイザある分)ましかなと思ってます
>メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
いやだからその２者をくらべたときに、誰にとってメリットデメリットだと？
ほんとに頭使わないシステム開発者にとってのメリットでいいのかよ
>品質がバラバラという可能性が減るのではないのでしょうか
減るかもしれんな。頭使わない安価粗悪な物によってまともな物が駆逐されてな
全体のレベルを下げるだけだ。品質低い方に統一してどうする
>職人頼りなシステム開発が工業製品へと
工芸品が工業製品になるためには、その職人の技が一般化されてることが必要なわけで
一部の人しかできないことを、だれにでもできる事だけで作ったとしてもそれは単なる粗悪品
一部の人しかできなかったことを、誰にでもできるようにしないと意味がない
そのために論理や技法があり、それを学んだり論議したりしてるんだよ
お前の主張は、
工業製品ならだれでも作れないとダメでしょ。
馬鹿にはシステム開発できないんで、システム開発は工業製品じゃないよね
ってことだ
224:NAME IS NULL
09/08/23 01:25:59 .net
>>214袋叩きワロタw
225:NAME IS NULL
09/08/23 02:35:18 .net
>>217
> みんながみんなSQLのエキスパートであれば問題ないのですが。
SQLのエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。
226:NAME IS NULL
09/08/23 03:11:11 .net
おっ！最近レス多いですねぇ。いいじゃないですか。
スレの趣旨に合っていれば、DB技術者の意見を気軽に言い合ってもいいんじゃない。
レスが一つ入ると反応する方が結構居そうなので。
それぞれ扱ってるシステムの規模や影響、会社の風土とが違うでしょうから、
一概に良いか悪いかは言えませんが。
227:NAME IS NULL
09/08/23 04:28:10 .net
>>214
とりあえず、「KVS的な構造」といって後者はないだろう。
228:NAME IS NULL
09/08/23 07:11:42 .net
>>214
COBOLやRPGの時代にそういうテーブル設計しているのありました。
今SQLで実装している業務を試しにCOBOLで実装してみたほうがいい。
まあ、あの時代はある種夢の時代だったな。
「おれ５０００ステップのプログラム作っちゃったぜ！」と
無駄に長いプログラムを作れば儲かった頃だし。
ちなみにSQLより速い処理が組めるRPGやCOBOLのプログラマなんて
ツチノコ並みの珍獣だと思うが。
229:NAME IS NULL
09/08/23 10:56:13 .net
>>228
COBOLやRPGは知らないけど、「処理の速さ」という点では
プログラムでゴリゴリ書いたほうが良いこともある
DB側（リレーション、制約、ストアド、SQL）に機能を持たせる
一番のメリットはやはり保守性だろう
230:NAME IS NULL
09/08/23 13:45:30 .net
サーバーでやるかクライアントでやるかの違いだろうね。>>214
メリット・デメリットは>>214の他に
メリット
自分で最適化できる。
デメリット
サーバー/クライアント間のデータ転送量が多くなる。（高速LANなら無視できる）
かな？
231:NAME IS NULL
09/08/23 14:32:06 .net
>>229
ストアドの速さに勝てるの？ありえなくないか？
DBに機能をもたせると保守性は落ちるとおもうが。
232:NAME IS NULL
09/08/23 15:05:03 .net
ストアドにしたからといっては飛躍的に高速になるわけではない。
233:NAME IS NULL
09/08/23 16:21:00 .net
処理の種類によるけど遅くなることはないだろｗ
234:NAME IS NULL
09/08/23 21:31:35 .net
データをどこに持っているかにもよる
DBMSに格納されているなら、そのDBMSに特化したストアドより早く外部プログラムが
実行できるとは思えない。
ストアドでも外部プログラムでも、ロジックは同じように作れるわけだからな
保守性については、システムの保全とか改修のしやすさとか、
何を主眼として保守性とするかによって変わると思うが
235:NAME IS NULL
09/08/23 21:33:12 .net
遅いクエリーはストアドであっても遅い
236:229
09/08/23 21:54:10 .net
>>234
「保守性」っていうのは、改修の効率の良さ、再利用性の高さ、
論理的整合性の保ちやすさなどをひっくるめた意味で書いた
曖昧な定義でごめんね
237:NAME IS NULL
09/08/24 00:12:00 .net
>>235
だったら外部プログラムならなお一層遅いだろ？
論理性がまったくないようだけど本業のほうは大丈夫？
238:NAME IS NULL
09/08/24 04:53:27 .net
他のクラウドで処理したデータも拾ってこなきゃならんから遅いだろうね。
全クラウドが、光ファイバーで繋がってて、膨大なクエリ処理しても、遅延は最大でも数百ナノ秒だぜってわけじゃないだろうし。
239:NAME IS NULL
09/08/24 06:28:52 .net
サーバーサイドの処理と限定して話をするけど
>COBOLやRPGは知らないけど、「処理の速さ」という点では
>プログラムでゴリゴリ書いたほうが良いこともある
SQLの実行エンジンの最適化処理でブロックI/Oやらをやられると
プログラムで１行FETCHや1行WRITEしている
これらの言語は太刀打ちできないワケだが。
そりゃ、OSのAPIを直打ちするレベルになれば別だけどな…。
今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
一般プログラマにコレを越えるプログラム組めって言っても
かなり辛い。
むろんプログラマが書いた方が良いこともあるだろう。
どんな例か知らんけど。
240:NAME IS NULL
09/08/24 17:29:10 .net
なんかストアドよりインデックスが速いよスレの二番煎じな流れだな。
詭弁のガイドライン
2.ごくまれな反例をとりあげる
「だが、RDBよりプログラマが書いた方が良いこともある」
15.新しい概念が全て正しいのだとミスリードする
「クラウドで使われているKVSを使わぬ限りシステム構築に明日はない」
241:NAME IS NULL
09/08/24 21:15:01 .net
>>239
> 今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
> 一般プログラマにコレを越えるプログラム組めって言っても
> かなり辛い。
腐るほどあるよ。
242:NAME IS NULL
09/08/24 22:02:49 .net
>>241
腐ったSQLを平気で書くプログラマのプログラムを想像した。
北へと旅に出たくなった・・・
243:NAME IS NULL
09/08/24 22:27:07 .net
>>241
腐るほどある。と言われても、AS/400みたいなマシンで無い限りSQLと他の言語の
速度比較とかは出来んはずだが、AS/400なんざ普及していないだろ。
RDBMSでSQL使うよりもC++でコレクションクラスを使った方が速いよ、なんて
議論無意味だしな。
244:NAME IS NULL
09/08/24 23:03:22 .net
ちょっと議論の的がズレていってない？
>>214は、処理の速さについては
メリットとしてもデメリットとしても挙げてないんだし
問題の本質はそこじゃなくない？
245:NAME IS NULL
09/08/25 00:03:36 .net
単に屑PGが適当に組んでも速度が出ないと困るってか？
SQL覚えるのが一番の近道。
246:NAME IS NULL
09/08/25 02:06:15 .net
>>244
問題の本質とは?
確かに、214さんが処理の速さについては
言及しておられないようです。
ただ、私見ですが214さんがSQLを良く
理解しておられないのは感じます。
開発側とすれば画面に表示する情報を
1SQLで取得できるように設計するべきで、
その方が楽だと思いますがね。
遅かったら運用のせいにも出来るしね。
>>242
まぁ、そんなこと言わないで、がんばって行きましょ。
分かるけどね…
247:NAME IS NULL
09/08/25 02:50:49 .net
>>246
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ
248:NAME IS NULL
09/08/25 03:07:51 .net
>>247
いえいえ、とんでもない。
そんなお褒めの言葉、
こちらこそありがとうございます。
249:NAME IS NULL
09/08/25 04:14:41 .net
単に複雑なSQL組めない屑PGだろ。
select *だけで全部済む様にしたいとか言いそうだし。
まるでオープン系コボラｗｗｗ
250:NAME IS NULL
09/08/25 07:07:25 .net
>>246
情報を1SQLでとれないってのは、どっちが？
251:NAME IS NULL
09/08/25 09:54:39 /mfME5w3.net
まだまだＤＢのオプティマイザはアホだから、実行プランやトータルコスト考えながらクエリやＰＧ書けない奴はダメだな。
下請けソフトハウスのアプリ屋なんてそんな奴ばっか…
何のためにキーやインデックスがあるのかちょっとは考えてくれよ
252:NAME IS NULL
09/08/25 10:08:13 .net
>>249
複雑なSQLはそれ自体のメンテが大変かもね。アクセスパスは不変じゃないし
無理矢理SQLに詰め込まれても、常に効率が良いとは限らない。
要はバランスだと思う。ちょっと頑張ればSQLのみで済むからSQLに詰め込もうとか、
どうせUAPで処理必要なんだから、SQLでは無理せずにUAP側にロジック入れようとか
いろいろ状況もあるだろうし、適材適所で臨機応変に使って行きゃ良い。
まぁ同一システム内でばらばらだと困るので、ある程度の取り決めは必須だが。
ところで、組み込みSQLで select * 使う人はいないはずだけど…。
さすがにそんな人にはコード書かせないでしょ。
253:NAME IS NULL
09/08/25 14:02:27 .net
>>252
>ところで、組み込みSQLで select * 使う人はいないはずだけど…。
>適材適所で臨機応変に使って行きゃ良い。
254:NAME IS NULL
09/08/26 02:19:56 .net
>>250
こんばんは。246で発言した者です。
どちらかとの御質問ですが、どれとどれのことか分かりませんでした。
私が不出来なもので申し訳ございません。
先に私が発言した主旨としては以下の様になります。
開発側の人としては画面に表示するデータが1SQLで(select * は論外ですが)、
もちろんジョイン、必要であればサブクエリーを使用し取得したデータ群を、
使用する言語によったデータセットで使った方が楽なのではないかと思った次第です。
(それぞれの環境次第なので一概に言えないのは分かっております。)
214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ように思われたので上記の様な発言を致しました。
ただ、214さんがデメリットでそのことを挙げておられることを見過ごしておりました。
申し訳ございません。
先に私が発言しました「214さんがSQLを～]の発言は撤回させてください。
その後の「遅かったら運用の～」は私の過去に受けた経験から発言したものです。
開発より、運用に従事している期間が長いものですから。
>>247
お気を悪くされましたらお詫びいたします。
255:NAME IS NULL
09/08/26 07:13:53 .net
遅いのは開発側、というよりDB設計者のせいだよ。
256:NAME IS NULL
09/08/26 15:34:09 .net
>>254
そもそもの発端はKVS的な設計はどうだろうって論題で、
KVS的な設計では１SQLでデータ取るのは不可能だって話だ
それを前提にしてるから
>214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ようになってるわけで
１SQLでデータ取れるような設計しろってのは、議論の前提がおかしいだろうが
>>255
その言い方だとDB設計者は開発側の人間じゃないように聞こえるが
257:NAME IS NULL
09/08/26 16:03:01 .net
>>214は、この設計を既存のRDBに割り当てて使うって言ってんのかな。
それなら駄目すぎて話しにならんと思うが。
258:NAME IS NULL
09/08/27 00:00:34 .net
そもそも「KVS的」といって>>214みたいなのが出てくるのがおかしいし、
あれが1SQLでデータが取得できないというのも変。
いったいオマエラ何の議論をしているの？
259:NAME IS NULL
09/08/27 00:27:25 .net
もう>>252がベストアンサーって事で良くね？
260:NAME IS NULL
09/08/27 07:01:17 .net
>>259
自演乙
261:NAME IS NULL
09/08/29 00:37:35 .net
具体的に1sqlってどこまで許すのか示されてないしな。
まあdb知らない人みたいだから無茶言いそうだが。
262:NAME IS NULL
09/09/10 16:45:52 .net
こちらの方がおっしゃっている設計指針についてどう思われるでしょうか。
URLﾘﾝｸ(masuda220.jugem.jp)
・テーブルの役割・用途は一つ
・（極力？）データに対する更新・削除は行わない
など
なるほどとも思うのですが、役割に応じて分割すると
あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
データの更新・削除を認めないのは冗長かつ非効率な気もします。
実務による、というお答えが返ってきそうですが、一般的な設計指針として
ご意見をお聞かせいただければ幸いです。
263:NAME IS NULL
09/09/10 23:30:01 .net
>>262
モデリングの手法としては合ってると思う
ただこの後の工程で、パフォーマンスや効率性を考慮して
冗長化、非正規化することは必要だけど
>あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
モデル上は、細かくテーブル分割してあるほうが分かりやすいよ
テーブル名とリレーション見るだけで何を表しているか分かるからね
>データの更新・削除を認めないのは冗長かつ非効率な気もします。
「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
どこから引用したの？
264:262
09/09/11 06:59:45 .net
>>263
レスありがとうございます。
書籍などではここまで言及してあるものを読んだことがなかったので、
どうなんだろうと思っていたのですが、正しい手法なのですね。
（「正しい」という表現が適切かわかりませんが）
> 「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
> どこから引用したの？
これは少しコメントを端折り過ぎました。
「テーブル設計 データモデリングのエッセンス（２）」などに書かれているのですが
> ビジネスイベントは一度作成（インサート）したら、後から、更新や削除はしない。
> このテーブルに許される操作は、インサートと参照のみにする。
とあります。
また、ビジネスリソース系のテーブルについても同様の方法を取ることもあると書かれています。
ここに書かれている業務システムの例に合わせて言えば、
受注テーブルは最新の状態にしておき、更新や削除の記録が必要ならば別テーブルにログとして保持する。
受注テーブルにはキャンセルされた受注や変更前の受注は保持しない。
というのが主流だと自分は思っていました。
また、導出テーブルをトリガで作成するという手法も初めて知りました。
265:NAME IS NULL
09/09/12 11:16:27 .net
>>1
1. Excelのワークシートと勘違いしてるから。
2. 設計＆指揮者がコードに関心があるのにデータに関心がないから。
レベル低すぎ？
266:NAME IS NULL
09/09/12 11:25:44 .net
むしろコボラ上がりが、繰り返し項目を使いたくって、
正規化なんか理想論だ、実際は性能が落ちる原因だとか
トンデモ説を信仰している（ふりをする）からじゃん
267:NAME IS NULL
09/09/12 11:35:27 .net
コボラ上がり(かつRDBを知らん)奴なんて数えるほどだろ。
それよりも、RDBしか使ったことがなくても実はわかってない、ってのが
圧倒的じゃないか？>>265の言うexcelと勘違いしてるようなのとか。
268:NAME IS NULL
09/09/12 12:27:58 .net
ファイル設計の延長くらいにしか考えてない奴は多いな
269:NAME IS NULL
09/09/13 03:40:03 .net
コボルの本読むとそんな感じだしな。
正規化なんて全く記述無し。
270:NAME IS NULL
09/09/13 11:52:21 .net
そりゃ正規化はRDBでしか必要ないからな！固定長レコードで正規化
してもテーブルの連結がめんどくさかったら意味ねえ！
271:NAME IS NULL
09/09/13 12:47:27 .net
そういえば昔、上から全項目を固定長にしろとお達しがあって、嫌々やったら速度が上がった
（つーか、負荷テスト後もあんまり性能が落ちない）DBがあったなｗ
272:NAME IS NULL
09/09/13 13:25:37 .net
その昔の経験って、今も成り立っているのかな？
そこが曖昧なまま薦められても困るのよね。
273:NAME IS NULL
09/09/13 16:04:54 .net
今は一般的にはtext型みたいなのが一番速い
長さチェックも空白詰めもしないから
ただしOracleだけは固定長が速い
274:NAME IS NULL
09/09/13 18:09:22 .net
>>273
逆だろ。
Oracleには固定長の文字列型なんてないはず。
最小長と最大長が等しい可変長文字列を、便宜上固定長文字列型って騙ってるだけ。
まぁほとんどのDBMSで、列サイズが固定であるが故の速度的メリットは大きいから、
Oracleでも可変長文字列を入れていた項目を擬似固定長に変更した時の速度向上は
見込めるかもしれないって程度。
275:NAME IS NULL
09/09/13 18:15:13 .net
> 固定長の文字列型なんてない
> 列サイズが固定であるが故の速度的メリットは大きい
矛盾してないか？ 最初の文は、内部的には可変長文字列の特殊設定だと
言っているような気がするんだが。
276:NAME IS NULL
09/09/14 04:23:37 .net
CHAR型って固定長じゃないのか
277:NAME IS NULL
09/09/14 13:32:43 .net
DB2も固定長の方が速いけど。
text型みたいなのはある程度まではそこそこ速いけど、
ある閾値を越えると急に遅くなったりするので
処理系しだいだろうとは思う。
つか、Oracleとかの「こうすると速い」系のネタは都市伝説が多いよなー。
商品コードとかの長さが決まっている項目なら固定長で、
備考の様な長さが不確定な部分は可変長と素直に設計していけばいいのでは？
「速いから固定長」とかはなんか違うだろ。
「考えるのが嫌だから全て可変長」の方がまだスジが通っている。ｗ
278:NAME IS NULL
09/09/14 14:32:30 .net
>>275
Oracleは内部的には全部可変長扱いだって聞いたことがあるからそのことじゃね？
DB2とかだと内部的にCHAR型とVARCHAR型は別扱いなので、きちんと使い分けた
方が望ましいけど、Oracleはちょっと変態なのでムリにCHAR型にする必要はないと。
(全ての？)列サイズが固定で速くなるってのはまた別の話で、データの格納と言うか、
表領域の使われ方のことではないかと。まぁどっちかって言うと行サイズだが…。
HiRDBだとFIX表ってわざわざ宣言したりするね。
279:NAME IS NULL
09/09/14 17:34:21 .net
オラクルは昔と今では、だいぶ違うけどな。昔の経験なんて引きずってたらそれこそコボラ状態。
280:NAME IS NULL
09/09/14 18:09:35 .net
DB2とかは固定長・可変長は分けて処理するしNOT NULLな制約も考慮して
適切な設計にあわせて実スピードは上がっていく。
逆に設計がアレだとあんまし速度はでないRDBMSだな。
Oracleも昔の都市伝説と言うか、昔のヘンテコ小技を今のVerに持ち込むのは
ヤめてくれって感じるな。
普通に設計して普通にSQL書いてください。
281:NAME IS NULL
09/09/15 21:32:23 .net
Oracleの仕様がヘンテコだからな
282:NAME IS NULL
09/09/16 10:24:42 .net
何でOracleはヘンテコな仕様なのに普及したんだろうね？
M$やらIBMやらが注力しなかったからかな？
283:NAME IS NULL
09/09/16 13:25:20 .net
当時は癖のある DB しかなかったよ
284:NAME IS NULL
09/09/16 17:52:21 .net
おかげさまで今でもうっかり(+)とかやっちゃうぜ
285:NAME IS NULL
09/09/16 20:18:06 .net
>>282
ごめんね、キミの大好きなOracleを馬鹿にしちゃってｗｗｗ
286:NAME IS NULL
09/09/19 02:03:14 .net
今日もアホなテーブルとクエリを見てゲンナリした
○○○○○は遅いねってお前の設計が（ry
287:NAME IS NULL
09/09/19 18:16:28 .net
>>282
性能がいいものが売れるとは限らない。
大人の事情というのがあるんだよｗ
288:NAME IS NULL
09/09/20 07:47:11 .net
まあそれほどまでに当時のSQL鯖/サイベースとDB2が糞だった訳で。
オラクルの出現で競争が生まれ、それらも今やかなりマシになった功績は大きい。
周りのヘンテコDB仕様に合わせて客取り込んでいって成長したから、今でも名残が残るのはしょうがない。だんだん洗練してヘンテコ仕様もろとも下位互換は切ってくだろうけど。
289:NAME IS NULL
09/09/20 08:40:22 .net
そもそもまともに使えるRDBMSを最初に売り出したのがOracle。市場での競争が始まるのが
後発のInformix、Sybase、Ingres等が現れてから。DB2もあったけど、当時のIBMはIMSの
商売の方が重要でDB2はほとんど力を入れておらず、顧客がRDBMSを必要とする場合に
程度でSymfowareやHiRDBのような扱い。
MSのSQL Serverや、他社OSでも使えるDB2 UDB(の原型)が現れて現在のような競争状態に
なるのはそれよりもさらに後。
290:NAME IS NULL
09/09/20 11:46:31 .net
過去のことはいいから現在一番ましなRDBはなんなのさ。
291:NAME IS NULL
09/09/20 12:10:29 .net
今の製品はだいたいみんなまともだろ？あとはどのポイントを重視するか。
総合1位なんて点数のつけ方で変わるよ。
292:NAME IS NULL
09/09/20 12:13:25 .net
君の重視するポイントでよろしく頼むよ。
293:NAME IS NULL
09/09/20 12:17:20 .net
製品比較は別スレでやれ。
294:NAME IS NULL
09/09/20 12:23:38 .net
>>292
じゃあSQLiteが一番だな。これで満足か？
295:NAME IS NULL
09/09/20 12:31:17 .net
どのポイントを重要視したの？
296:NAME IS NULL
09/09/20 13:31:27 .net
サポート契約してるとOracleって結構不具合とかあるんだなぁ、
って感じますが、他のRDBMSでもあるんですかね？
297:NAME IS NULL
09/09/20 21:30:20 .net
DB2も不具合はある。
Oracleよりは少ないが、それだけDB2普及していない証明でもあるような希ガス。
別に不具合あってもいいんだけどさ、それの対応がタマに「我慢汁」とか「それはOSの不具合です」
とか解決に繋がらない回答を貰うと、「あー、Postgresでいいじゃん」とか思うな。
298:NAME IS NULL
09/09/20 23:21:46 .net
DB2は、「なんでいまだにこんなバグが？」と思うようなのがけっこうあるね。
インスタンスダウン→「次のFPで修正されます」のコンボに何回遭遇したか。
299:NAME IS NULL
09/09/21 00:11:44 .net
DB2ってiSeriesは鉄なみの硬さがあると思うが、それ以外のプラットフォームは・・・。
Oracleもよくインスタンス落ちるがiのDB2は落ちた事がない。
これもIBMの中の人とガチで仲良し(?)レベルで会話できる人が少ない性もあるんだろうな。
300:NAME IS NULL
09/09/21 12:39:41 .net
単にasはろくな処理してなくて使い込んでないから固く見えてるだけじゃ。
全部as内完結で、不安定になる様な秘穴を突けなくしてあるとも言うが。
オラは、いろいろ弄れる割に秘穴を突いてしまう確率が高くなるだけ。
ちゃんと組めばド安定で運用出来るよ。RACも組めるし。
ポスグレはサポート無いから、業務では選択肢に無いな。
マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。
301:NAME IS NULL
09/09/21 15:08:44 .net
結局なんだかんだ言いつつサポートの有無でプロダクトを選ぶという矛盾が
別にサポートあったって落ちたときに損害補償してくれるわけでもないんだし
金払うだけ無駄なのがサポートだぜ
パッチの提供なんて逆にPostgreSQLなんか速攻で修正されて出てくる
オープンソースだから原因も即バレで、仕様ですと隠される事もないしな
302:NAME IS NULL
09/09/21 15:42:44 .net
矛盾つーか、セルフサポートできるんならOSSも選べるってだけだろ。
一応サポート契約していれば、どんな障害/質問に対しても「マニュアル
読め」以上の何らかの回答を一定期間内にしてくれるし。
303:NAME IS NULL
09/09/21 16:42:14 .net
んでその回答って役に立つのか？
PostgreSQLの構築/運用実績あるSIにやって貰った方が
Oracleに無駄に500万払い続けるよりマシな気がする
304:NAME IS NULL
09/09/21 17:14:32 .net
おめーら別スレでやれよ
305:NAME IS NULL
09/09/21 17:54:54 .net
>>303
サポート契約してれば何か起きたときの事故対策会議で「サポートに問い合わせ中です」
って言える。もちろんその後は「原因不明なので再現待ちです」って逃げる。
DBMSに限らず、商用OS等でも良くあるが…運用担当者が泣く黄金パターンだよな。
まぁ実際問題として、サポートにまともな回答もらえるとはだれも思ってないんだよ。
ただ、実質使えないサポートであっても、それを望んでいる客がいるのもまた事実だから、
そういう提案してしまうのはしょうがないと思う。
306:NAME IS NULL
09/09/21 18:55:49 .net
>>303
そりゃ役に立つ人はいるだろうさ。
当然、Postgresでシステム構築したとしても、Postgresのサポートを
必要とする場合だってあるだろうし。
307:NAME IS NULL
09/09/21 23:09:15 .net
＞PostgreSQLの構築/運用実績あるSIにやって貰った方が
＞Oracleに無駄に500万払い続けるよりマシな気がする
ぶっちゃけその通りだけどな。
漏れの中ではOracleは言うほどマシなRDBMSじゃないと認識している。
Oracleが必要な業務があるのは事実だろうが、多くの導入例では
「Oracleはいらんだろ」的な納品されている現場は多い。
308:NAME IS NULL
09/09/22 09:05:44 .net
しかしPostgresのシステム構築やサポートできるSIなんて
付き合いある範囲じゃ見当たらないな。
309:NAME IS NULL
09/09/22 11:04:07 .net
オープンソースのDBすら自分で構築しようとしないエンジニアって・・
310:NAME IS NULL
09/09/22 11:39:52 .net
それは「システムを自分で開発しないエンジニアって」と言っているに等しいぞ。
内製するかどうかとオープンソースかどうかなんてあんま関係ない。ただ、開発を
SIに任せる場合にOSSで受けてくれる業者がほとんどないというだけ。
311:NAME IS NULL
09/09/22 12:29:28 .net
>>308
知り合いかどうか知らんがPostgresはNTTやらNEC系はやってるな。
別に漏れもヤれと言われれば並みのOracle程度には出来る。
つか漏れも社内のなんちゃってテスト環境用にはDreby使っている。
312:NAME IS NULL
09/09/22 12:56:37 .net
まぁ会社としてサポートするとなると、スキルのある要員の継続確保が問題になるな。
俺的には別に特殊なスキルが必要とは思えないのだが、商用/フリーに関わらず
調査すら出来ない人間ってのが意外といるわけで。
313:NAME IS NULL
09/09/22 14:38:29 .net
OSSは裾野の部分がまだ弱いからねぇ。研修制度とか、サードパーティの層の厚さとか。
Linuxは大メーカー自身が手がけるようになって大分よくなったけど。
314:NAME IS NULL
09/09/22 15:22:04 .net
オープンソースのサポートなんて遣るくらいならオラクル保守入って丸投げのほうが楽だな。
オープンソースで手厚いサポートできるようなスキルある香具師雇うなら、オラクル以上に金かかりそうだw
オラクルに損害賠償請求する馬鹿企業は居ないが、個人に損害賠償してくる馬鹿企業は山ほど居るだろうし。
315:NAME IS NULL
09/09/22 20:15:18 .net
>>314
凄い妄想だな。
底辺のオマエには知らん世界だろうが、Oracle使った案件でも契約書に
損害賠償跳ね除ける文面が契約事項としてあげてあるベンダーがほとんどだが。
316:NAME IS NULL
09/09/23 06:02:53 .net
Postgresにサポートが無いとか、お前らシロート？
317:NAME IS NULL
09/09/23 09:08:19 .net
比率で言うならOracle信者ほど素人が多いのは不思議な現実。
サポートが心の拠り所らしい。
318:NAME IS NULL
09/09/23 11:28:58 .net
ポスグレで自分で面倒見るのは自殺行為なんだよ。
319:NAME IS NULL
09/09/23 15:25:24 .net
別に「Oracleはインタンスが絶対に落ちなくてサポートが満足な製品で漏れは一度も苦労した事ない」
と言える製品ならそれはそれで構わんよ。
漏れはそんなOracle見た事ないが。年に１・２回はｲﾐﾌﾒｲに落ちる。
ただまあ、漏れの経験でｲﾐﾌﾒｲに落ちた場合サポートに問い合わせても「原因不明です。OSかハードに問題があると思われます」
の逃げ口上が出て終わりなんで、PostgresだろうとOracleだろうと能力のない人間が構築したシステムは
どれも自殺したくなる。
むしろ、上の発言で出てきた問題を全てIBMに投げられるiSeries、もしくはOSSだからと言う理由でPostgresを
選んだほうがラクになれる。
320:NAME IS NULL
09/09/24 07:36:57 .net
データやSRAは独自パッケージまで出してるのに
321:NAME IS NULL
09/09/25 13:21:23 .net
設計
322:NAME IS NULL
09/09/25 16:04:56 .net
今までで一番酷かったのがLinuxの8iだな
2000万払った挙げ句、使用は自己責任でとか言われたｗ
323:NAME IS NULL
09/09/26 15:26:21 .net
Linuxの8iって人柱Verだった頃のじゃね？
まあ、未だにそれで動いているトコはあるんだろうけど。
324:NAME IS NULL
09/09/26 20:34:26 .net
要するに人柱バージョンを2000万でうりつけてるのかｗ
325:NAME IS NULL
09/09/26 21:00:40 .net
値段は規模にもよるから、Linuxで8iで2000万が高いか安いか判断が難しいが。
HP-UXの8でもそれくらい取るベンダー見た事あるし。ただイニシャルはともかくランニングコストは
あんまし安くなかったが。年600万くらい。
Linuxの8iは自己責任と言うからにはランニングコストは０なんだろ。w
DB2(iSeries)だとイニシャルは下は300万で上は２億くらいの幅でランニングは100～600万くらい飛んでいく。
326:NAME IS NULL
09/09/27 03:34:04 .net
8iの頃はソラリスが鉄板だったので、リナックスなんて選んだほうが自殺行為なだけ。
東証がポスグレ採用なんて無謀な事はしないのと同じ。
IBMに丸投げ出来るぐらいの資金が有るなら、日電や不実に丸投げしてオラクルの面倒見てもらえるけどな。
うちはRACだけど意味不明に落ちてもリカバリは出来る仕組みにしてるよ。
そもそも絶対に落ちないなんてあり得ないし、ソフトのバグが無いのも信用してない。PGなんてバグ入りの欠陥品しか作れないし。製造業の品質管理に比べたら認識が甘過ぎるよ。
逆に、ポスグレは絶対落ちなくてサポートも満足と保証されてるの？
２億の案件でポスグレで組んで、損害賠償なんて喰らったら人生終わるなw