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

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

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

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

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

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

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

**NAME IS NULL** · 2009/08/23(日) 21:33:12

遅いクエリーはストアドであっても遅い

**229** · 2009/08/23(日) 21:54:10

>>234
「保守性」っていうのは、改修の効率の良さ、再利用性の高さ、
論理的整合性の保ちやすさなどをひっくるめた意味で書いた
曖昧な定義でごめんね

**NAME IS NULL** · 2009/08/24(月) 00:12:00

>>235
だったら外部プログラムならなお一層遅いだろ？
論理性がまったくないようだけど本業のほうは大丈夫？

**NAME IS NULL** · 2009/08/24(月) 04:53:27

他のクラウドで処理したデータも拾ってこなきゃならんから遅いだろうね。
全クラウドが、光ファイバーで繋がってて、膨大なクエリ処理しても、遅延は最大でも数百ナノ秒だぜってわけじゃないだろうし。

**NAME IS NULL** · 2009/08/24(月) 06:28:52

サーバーサイドの処理と限定して話をするけど

>COBOLやRPGは知らないけど、「処理の速さ」という点では
>プログラムでゴリゴリ書いたほうが良いこともある

SQLの実行エンジンの最適化処理でブロックI/Oやらをやられると
プログラムで１行FETCHや1行WRITEしている
これらの言語は太刀打ちできないワケだが。

そりゃ、OSのAPIを直打ちするレベルになれば別だけどな…。

今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
一般プログラマにコレを越えるプログラム組めって言っても
かなり辛い。

むろんプログラマが書いた方が良いこともあるだろう。
どんな例か知らんけど。

**NAME IS NULL** · 2009/08/24(月) 17:29:10

なんかストアドよりインデックスが速いよスレの二番煎じな流れだな。

詭弁のガイドライン
2.ごくまれな反例をとりあげる
「だが、RDBよりプログラマが書いた方が良いこともある」
15.新しい概念が全て正しいのだとミスリードする
「クラウドで使われているKVSを使わぬ限りシステム構築に明日はない」

**NAME IS NULL** · 2009/08/24(月) 21:15:01

>>239
> 今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
> 一般プログラマにコレを越えるプログラム組めって言っても
> かなり辛い。
腐るほどあるよ。

**NAME IS NULL** · 2009/08/24(月) 22:02:49

>>241
腐ったSQLを平気で書くプログラマのプログラムを想像した。
北へと旅に出たくなった・・・

**NAME IS NULL** · 2009/08/24(月) 22:27:07

>>241
腐るほどある。と言われても、AS/400みたいなマシンで無い限りSQLと他の言語の
速度比較とかは出来んはずだが、AS/400なんざ普及していないだろ。

RDBMSでSQL使うよりもC++でコレクションクラスを使った方が速いよ、なんて
議論無意味だしな。

**NAME IS NULL** · 2009/08/24(月) 23:03:22

ちょっと議論の的がズレていってない？
>>214は、処理の速さについては
メリットとしてもデメリットとしても挙げてないんだし
問題の本質はそこじゃなくない？

**NAME IS NULL** · 2009/08/25(火) 00:03:36

単に屑PGが適当に組んでも速度が出ないと困るってか？
SQL覚えるのが一番の近道。

**NAME IS NULL** · 2009/08/25(火) 02:06:15

>>244

問題の本質とは?
確かに、214さんが処理の速さについては
言及しておられないようです。

ただ、私見ですが214さんがSQLを良く
理解しておられないのは感じます。

開発側とすれば画面に表示する情報を
1SQLで取得できるように設計するべきで、
その方が楽だと思いますがね。
遅かったら運用のせいにも出来るしね。

>>242
まぁ、そんなこと言わないで、がんばって行きましょ。
分かるけどね…

**NAME IS NULL** · 2009/08/25(火) 02:50:49

>>246
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ

**NAME IS NULL** · 2009/08/25(火) 03:07:51

>>247
いえいえ、とんでもない。
そんなお褒めの言葉、
こちらこそありがとうございます。

**NAME IS NULL** · 2009/08/25(火) 04:14:41

単に複雑なSQL組めない屑PGだろ。
select *だけで全部済む様にしたいとか言いそうだし。
まるでオープン系コボラｗｗｗ

**NAME IS NULL** · 2009/08/25(火) 07:07:25

>>246
情報を1SQLでとれないってのは、どっちが？

**NAME IS NULL** · 2009/08/25(火) 09:54:39

まだまだＤＢのオプティマイザはアホだから、実行プランやトータルコスト考えながらクエリやＰＧ書けない奴はダメだな。
下請けソフトハウスのアプリ屋なんてそんな奴ばっか…
何のためにキーやインデックスがあるのかちょっとは考えてくれよ

**NAME IS NULL** · 2009/08/25(火) 10:08:13

>>249
複雑なSQLはそれ自体のメンテが大変かもね。アクセスパスは不変じゃないし
無理矢理SQLに詰め込まれても、常に効率が良いとは限らない。
要はバランスだと思う。ちょっと頑張ればSQLのみで済むからSQLに詰め込もうとか、
どうせUAPで処理必要なんだから、SQLでは無理せずにUAP側にロジック入れようとか
いろいろ状況もあるだろうし、適材適所で臨機応変に使って行きゃ良い。
まぁ同一システム内でばらばらだと困るので、ある程度の取り決めは必須だが。

ところで、組み込みSQLで select * 使う人はいないはずだけど…。
さすがにそんな人にはコード書かせないでしょ。

**NAME IS NULL** · 2009/08/25(火) 14:02:27

>>252
>ところで、組み込みSQLで select * 使う人はいないはずだけど…。
>適材適所で臨機応変に使って行きゃ良い。

**NAME IS NULL** · 2009/08/26(水) 02:19:56

>>250
こんばんは。246で発言した者です。

どちらかとの御質問ですが、どれとどれのことか分かりませんでした。
私が不出来なもので申し訳ございません。
先に私が発言した主旨としては以下の様になります。

開発側の人としては画面に表示するデータが1SQLで(select * は論外ですが)、
もちろんジョイン、必要であればサブクエリーを使用し取得したデータ群を、
使用する言語によったデータセットで使った方が楽なのではないかと思った次第です。
(それぞれの環境次第なので一概に言えないのは分かっております。)

214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ように思われたので上記の様な発言を致しました。
ただ、214さんがデメリットでそのことを挙げておられることを見過ごしておりました。
申し訳ございません。
先に私が発言しました「214さんがSQLを～]の発言は撤回させてください。

その後の「遅かったら運用の～」は私の過去に受けた経験から発言したものです。
開発より、運用に従事している期間が長いものですから。

>>247
お気を悪くされましたらお詫びいたします。

**NAME IS NULL** · 2009/08/26(水) 07:13:53

遅いのは開発側、というよりDB設計者のせいだよ。

**NAME IS NULL** · 2009/08/26(水) 15:34:09

>>254
そもそもの発端はKVS的な設計はどうだろうって論題で、
KVS的な設計では１SQLでデータ取るのは不可能だって話だ
それを前提にしてるから
>214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ようになってるわけで
１SQLでデータ取れるような設計しろってのは、議論の前提がおかしいだろうが

>>255
その言い方だとDB設計者は開発側の人間じゃないように聞こえるが

**NAME IS NULL** · 2009/08/26(水) 16:03:01

>>214は、この設計を既存のRDBに割り当てて使うって言ってんのかな。

それなら駄目すぎて話しにならんと思うが。

**NAME IS NULL** · 2009/08/27(木) 00:00:34

そもそも「KVS的」といって>>214みたいなのが出てくるのがおかしいし、
あれが1SQLでデータが取得できないというのも変。
いったいオマエラ何の議論をしているの？

**NAME IS NULL** · 2009/08/27(木) 00:27:25

もう>>252がベストアンサーって事で良くね？

**NAME IS NULL** · 2009/08/27(木) 07:01:17

>>259
自演乙

**NAME IS NULL** · 2009/08/29(土) 00:37:35

具体的に1sqlってどこまで許すのか示されてないしな。
まあdb知らない人みたいだから無茶言いそうだが。

**NAME IS NULL** · 2009/09/10(木) 16:45:52

こちらの方がおっしゃっている設計指針についてどう思われるでしょうか。
http://masuda220.jugem.jp/?cid=11
・テーブルの役割・用途は一つ
・（極力？）データに対する更新・削除は行わない
など
なるほどとも思うのですが、役割に応じて分割すると
あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
データの更新・削除を認めないのは冗長かつ非効率な気もします。
実務による、というお答えが返ってきそうですが、一般的な設計指針として
ご意見をお聞かせいただければ幸いです。

**NAME IS NULL** · 2009/09/10(木) 23:30:01

>>262
モデリングの手法としては合ってると思う
ただこの後の工程で、パフォーマンスや効率性を考慮して
冗長化、非正規化することは必要だけど

>あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
モデル上は、細かくテーブル分割してあるほうが分かりやすいよ
テーブル名とリレーション見るだけで何を表しているか分かるからね

>データの更新・削除を認めないのは冗長かつ非効率な気もします。
「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
どこから引用したの？

**262** · 2009/09/11(金) 06:59:45

>>263
レスありがとうございます。
書籍などではここまで言及してあるものを読んだことがなかったので、
どうなんだろうと思っていたのですが、正しい手法なのですね。
（「正しい」という表現が適切かわかりませんが）

> 「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
> どこから引用したの？
これは少しコメントを端折り過ぎました。
「テーブル設計　データモデリングのエッセンス（２）」などに書かれているのですが
> ビジネスイベントは一度作成（インサート）したら、後から、更新や削除はしない。
> このテーブルに許される操作は、インサートと参照のみにする。
とあります。
また、ビジネスリソース系のテーブルについても同様の方法を取ることもあると書かれています。

ここに書かれている業務システムの例に合わせて言えば、
受注テーブルは最新の状態にしておき、更新や削除の記録が必要ならば別テーブルにログとして保持する。
受注テーブルにはキャンセルされた受注や変更前の受注は保持しない。
というのが主流だと自分は思っていました。
また、導出テーブルをトリガで作成するという手法も初めて知りました。

**NAME IS NULL** · 2009/09/12(土) 11:16:27

>>1
1. Excelのワークシートと勘違いしてるから。
2. 設計＆指揮者がコードに関心があるのにデータに関心がないから。

レベル低すぎ？

**NAME IS NULL** · 2009/09/12(土) 11:25:44

むしろコボラ上がりが、繰り返し項目を使いたくって、
正規化なんか理想論だ、実際は性能が落ちる原因だとか
トンデモ説を信仰している（ふりをする）からじゃん

**NAME IS NULL** · 2009/09/12(土) 11:35:27

コボラ上がり(かつRDBを知らん)奴なんて数えるほどだろ。
それよりも、RDBしか使ったことがなくても実はわかってない、ってのが
圧倒的じゃないか？>>265の言うexcelと勘違いしてるようなのとか。

**NAME IS NULL** · 2009/09/12(土) 12:27:58

ファイル設計の延長くらいにしか考えてない奴は多いな

**NAME IS NULL** · 2009/09/13(日) 03:40:03

コボルの本読むとそんな感じだしな。
正規化なんて全く記述無し。

**NAME IS NULL** · 2009/09/13(日) 11:52:21

そりゃ正規化はRDBでしか必要ないからな！固定長レコードで正規化
してもテーブルの連結がめんどくさかったら意味ねえ！

**NAME IS NULL** · 2009/09/13(日) 12:47:27

そういえば昔、上から全項目を固定長にしろとお達しがあって、嫌々やったら速度が上がった
（つーか、負荷テスト後もあんまり性能が落ちない）DBがあったなｗ

**NAME IS NULL** · 2009/09/13(日) 13:25:37

その昔の経験って、今も成り立っているのかな？
そこが曖昧なまま薦められても困るのよね。

**NAME IS NULL** · 2009/09/13(日) 16:04:54

今は一般的にはtext型みたいなのが一番速い
長さチェックも空白詰めもしないから
ただしOracleだけは固定長が速い

**NAME IS NULL** · 2009/09/13(日) 18:09:22

>>273
逆だろ。
Oracleには固定長の文字列型なんてないはず。
最小長と最大長が等しい可変長文字列を、便宜上固定長文字列型って騙ってるだけ。
まぁほとんどのDBMSで、列サイズが固定であるが故の速度的メリットは大きいから、
Oracleでも可変長文字列を入れていた項目を擬似固定長に変更した時の速度向上は
見込めるかもしれないって程度。

**NAME IS NULL** · 2009/09/13(日) 18:15:13

> 固定長の文字列型なんてない
> 列サイズが固定であるが故の速度的メリットは大きい
矛盾してないか？最初の文は、内部的には可変長文字列の特殊設定だと
言っているような気がするんだが。

**NAME IS NULL** · 2009/09/14(月) 04:23:37

CHAR型って固定長じゃないのか

**NAME IS NULL** · 2009/09/14(月) 13:32:43

DB2も固定長の方が速いけど。

text型みたいなのはある程度まではそこそこ速いけど、
ある閾値を越えると急に遅くなったりするので
処理系しだいだろうとは思う。

つか、Oracleとかの「こうすると速い」系のネタは都市伝説が多いよなー。

商品コードとかの長さが決まっている項目なら固定長で、
備考の様な長さが不確定な部分は可変長と素直に設計していけばいいのでは？

「速いから固定長」とかはなんか違うだろ。
「考えるのが嫌だから全て可変長」の方がまだスジが通っている。ｗ

**NAME IS NULL** · 2009/09/14(月) 14:32:30

>>275
Oracleは内部的には全部可変長扱いだって聞いたことがあるからそのことじゃね？
DB2とかだと内部的にCHAR型とVARCHAR型は別扱いなので、きちんと使い分けた
方が望ましいけど、Oracleはちょっと変態なのでムリにCHAR型にする必要はないと。

(全ての？)列サイズが固定で速くなるってのはまた別の話で、データの格納と言うか、
表領域の使われ方のことではないかと。まぁどっちかって言うと行サイズだが…。
HiRDBだとFIX表ってわざわざ宣言したりするね。

**NAME IS NULL** · 2009/09/14(月) 17:34:21

オラクルは昔と今では、だいぶ違うけどな。昔の経験なんて引きずってたらそれこそコボラ状態。

**NAME IS NULL** · 2009/09/14(月) 18:09:35

DB2とかは固定長・可変長は分けて処理するしNOT NULLな制約も考慮して
適切な設計にあわせて実スピードは上がっていく。
逆に設計がアレだとあんまし速度はでないRDBMSだな。

Oracleも昔の都市伝説と言うか、昔のヘンテコ小技を今のVerに持ち込むのは
ヤめてくれって感じるな。

普通に設計して普通にSQL書いてください。

**NAME IS NULL** · 2009/09/15(火) 21:32:23

Oracleの仕様がヘンテコだからな

**NAME IS NULL** · 2009/09/16(水) 10:24:42

何でOracleはヘンテコな仕様なのに普及したんだろうね？
M$やらIBMやらが注力しなかったからかな？

**NAME IS NULL** · 2009/09/16(水) 13:25:20

当時は癖のある DB しかなかったよ

**NAME IS NULL** · 2009/09/16(水) 17:52:21

おかげさまで今でもうっかり(+)とかやっちゃうぜ

**NAME IS NULL** · 2009/09/16(水) 20:18:06

>>282
ごめんね、キミの大好きなOracleを馬鹿にしちゃってｗｗｗ

**NAME IS NULL** · 2009/09/19(土) 02:03:14

今日もアホなテーブルとクエリを見てゲンナリした
○○○○○は遅いねってお前の設計が（ry

**NAME IS NULL** · 2009/09/19(土) 18:16:28

>>282
性能がいいものが売れるとは限らない。
大人の事情というのがあるんだよｗ

**NAME IS NULL** · 2009/09/20(日) 07:47:11

まあそれほどまでに当時のSQL鯖/サイベースとDB2が糞だった訳で。
オラクルの出現で競争が生まれ、それらも今やかなりマシになった功績は大きい。
周りのヘンテコDB仕様に合わせて客取り込んでいって成長したから、今でも名残が残るのはしょうがない。だんだん洗練してヘンテコ仕様もろとも下位互換は切ってくだろうけど。

**NAME IS NULL** · 2009/09/20(日) 08:40:22

そもそもまともに使えるRDBMSを最初に売り出したのがOracle。市場での競争が始まるのが
後発のInformix、Sybase、Ingres等が現れてから。DB2もあったけど、当時のIBMはIMSの
商売の方が重要でDB2はほとんど力を入れておらず、顧客がRDBMSを必要とする場合に
程度でSymfowareやHiRDBのような扱い。
MSのSQL Serverや、他社OSでも使えるDB2 UDB(の原型)が現れて現在のような競争状態に
なるのはそれよりもさらに後。

**NAME IS NULL** · 2009/09/20(日) 11:46:31

過去のことはいいから現在一番ましなRDBはなんなのさ。

**NAME IS NULL** · 2009/09/20(日) 12:10:29

今の製品はだいたいみんなまともだろ？あとはどのポイントを重視するか。
総合1位なんて点数のつけ方で変わるよ。

**NAME IS NULL** · 2009/09/20(日) 12:13:25

君の重視するポイントでよろしく頼むよ。

**NAME IS NULL** · 2009/09/20(日) 12:17:20

製品比較は別スレでやれ。

**NAME IS NULL** · 2009/09/20(日) 12:23:38

>>292
じゃあSQLiteが一番だな。これで満足か？

**NAME IS NULL** · 2009/09/20(日) 12:31:17

どのポイントを重要視したの？

**NAME IS NULL** · 2009/09/20(日) 13:31:27

サポート契約してるとOracleって結構不具合とかあるんだなぁ、
って感じますが、他のRDBMSでもあるんですかね？

**NAME IS NULL** · 2009/09/20(日) 21:30:20

DB2も不具合はある。
Oracleよりは少ないが、それだけDB2普及していない証明でもあるような希ガス。

別に不具合あってもいいんだけどさ、それの対応がタマに「我慢汁」とか「それはOSの不具合です」
とか解決に繋がらない回答を貰うと、「あー、Postgresでいいじゃん」とか思うな。

**NAME IS NULL** · 2009/09/20(日) 23:21:46

DB2は、「なんでいまだにこんなバグが？」と思うようなのがけっこうあるね。
インスタンスダウン→「次のFPで修正されます」のコンボに何回遭遇したか。

**NAME IS NULL** · 2009/09/21(月) 00:11:44

DB2ってiSeriesは鉄なみの硬さがあると思うが、それ以外のプラットフォームは・・・。
Oracleもよくインスタンス落ちるがiのDB2は落ちた事がない。

これもIBMの中の人とガチで仲良し(?)レベルで会話できる人が少ない性もあるんだろうな。

**NAME IS NULL** · 2009/09/21(月) 12:39:41

単にasはろくな処理してなくて使い込んでないから固く見えてるだけじゃ。
全部as内完結で、不安定になる様な秘穴を突けなくしてあるとも言うが。

オラは、いろいろ弄れる割に秘穴を突いてしまう確率が高くなるだけ。
ちゃんと組めばド安定で運用出来るよ。RACも組めるし。

ポスグレはサポート無いから、業務では選択肢に無いな。
マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。

**NAME IS NULL** · 2009/09/21(月) 15:08:44

結局なんだかんだ言いつつサポートの有無でプロダクトを選ぶという矛盾が
別にサポートあったって落ちたときに損害補償してくれるわけでもないんだし
金払うだけ無駄なのがサポートだぜ
パッチの提供なんて逆にPostgreSQLなんか速攻で修正されて出てくる
オープンソースだから原因も即バレで、仕様ですと隠される事もないしな

**NAME IS NULL** · 2009/09/21(月) 15:42:44

矛盾つーか、セルフサポートできるんならOSSも選べるってだけだろ。
一応サポート契約していれば、どんな障害/質問に対しても「マニュアル
読め」以上の何らかの回答を一定期間内にしてくれるし。

**NAME IS NULL** · 2009/09/21(月) 16:42:14

んでその回答って役に立つのか？
PostgreSQLの構築/運用実績あるSIにやって貰った方が
Oracleに無駄に500万払い続けるよりマシな気がする

**NAME IS NULL** · 2009/09/21(月) 17:14:32

おめーら別スレでやれよ

**NAME IS NULL** · 2009/09/21(月) 17:54:54

>>303
サポート契約してれば何か起きたときの事故対策会議で「サポートに問い合わせ中です」
って言える。もちろんその後は「原因不明なので再現待ちです」って逃げる。
DBMSに限らず、商用OS等でも良くあるが…運用担当者が泣く黄金パターンだよな。

まぁ実際問題として、サポートにまともな回答もらえるとはだれも思ってないんだよ。
ただ、実質使えないサポートであっても、それを望んでいる客がいるのもまた事実だから、
そういう提案してしまうのはしょうがないと思う。

**NAME IS NULL** · 2009/09/21(月) 18:55:49

>>303
そりゃ役に立つ人はいるだろうさ。
当然、Postgresでシステム構築したとしても、Postgresのサポートを
必要とする場合だってあるだろうし。

**NAME IS NULL** · 2009/09/21(月) 23:09:15

＞PostgreSQLの構築/運用実績あるSIにやって貰った方が
＞Oracleに無駄に500万払い続けるよりマシな気がする

ぶっちゃけその通りだけどな。

漏れの中ではOracleは言うほどマシなRDBMSじゃないと認識している。

Oracleが必要な業務があるのは事実だろうが、多くの導入例では
「Oracleはいらんだろ」的な納品されている現場は多い。

**NAME IS NULL** · 2009/09/22(火) 09:05:44

しかしPostgresのシステム構築やサポートできるSIなんて
付き合いある範囲じゃ見当たらないな。

**NAME IS NULL** · 2009/09/22(火) 11:04:07

オープンソースのDBすら自分で構築しようとしないエンジニアって・・

**NAME IS NULL** · 2009/09/22(火) 11:39:52

それは「システムを自分で開発しないエンジニアって」と言っているに等しいぞ。
内製するかどうかとオープンソースかどうかなんてあんま関係ない。ただ、開発を
SIに任せる場合にOSSで受けてくれる業者がほとんどないというだけ。

**NAME IS NULL** · 2009/09/22(火) 12:29:28

>>308
知り合いかどうか知らんがPostgresはNTTやらNEC系はやってるな。

別に漏れもヤれと言われれば並みのOracle程度には出来る。

つか漏れも社内のなんちゃってテスト環境用にはDreby使っている。

**NAME IS NULL** · 2009/09/22(火) 12:56:37

まぁ会社としてサポートするとなると、スキルのある要員の継続確保が問題になるな。
俺的には別に特殊なスキルが必要とは思えないのだが、商用/フリーに関わらず
調査すら出来ない人間ってのが意外といるわけで。

**NAME IS NULL** · 2009/09/22(火) 14:38:29

OSSは裾野の部分がまだ弱いからねぇ。研修制度とか、サードパーティの層の厚さとか。
Linuxは大メーカー自身が手がけるようになって大分よくなったけど。

**NAME IS NULL** · 2009/09/22(火) 15:22:04

オープンソースのサポートなんて遣るくらいならオラクル保守入って丸投げのほうが楽だな。
オープンソースで手厚いサポートできるようなスキルある香具師雇うなら、オラクル以上に金かかりそうだw

オラクルに損害賠償請求する馬鹿企業は居ないが、個人に損害賠償してくる馬鹿企業は山ほど居るだろうし。

**NAME IS NULL** · 2009/09/22(火) 20:15:18

>>314
凄い妄想だな。

底辺のオマエには知らん世界だろうが、Oracle使った案件でも契約書に
損害賠償跳ね除ける文面が契約事項としてあげてあるベンダーがほとんどだが。

**NAME IS NULL** · 2009/09/23(水) 06:02:53

Postgresにサポートが無いとか、お前らシロート？

**NAME IS NULL** · 2009/09/23(水) 09:08:19

比率で言うならOracle信者ほど素人が多いのは不思議な現実。
サポートが心の拠り所らしい。

**NAME IS NULL** · 2009/09/23(水) 11:28:58

ポスグレで自分で面倒見るのは自殺行為なんだよ。

**NAME IS NULL** · 2009/09/23(水) 15:25:24

別に「Oracleはインタンスが絶対に落ちなくてサポートが満足な製品で漏れは一度も苦労した事ない」
と言える製品ならそれはそれで構わんよ。

漏れはそんなOracle見た事ないが。年に１・２回はｲﾐﾌﾒｲに落ちる。

ただまあ、漏れの経験でｲﾐﾌﾒｲに落ちた場合サポートに問い合わせても「原因不明です。OSかハードに問題があると思われます」
の逃げ口上が出て終わりなんで、PostgresだろうとOracleだろうと能力のない人間が構築したシステムは
どれも自殺したくなる。

むしろ、上の発言で出てきた問題を全てIBMに投げられるiSeries、もしくはOSSだからと言う理由でPostgresを
選んだほうがラクになれる。

**NAME IS NULL** · 2009/09/24(木) 07:36:57

データやSRAは独自パッケージまで出してるのに

**NAME IS NULL** · 2009/09/25(金) 13:21:23

設計

**NAME IS NULL** · 2009/09/25(金) 16:04:56

今までで一番酷かったのがLinuxの8iだな
2000万払った挙げ句、使用は自己責任でとか言われたｗ

**NAME IS NULL** · 2009/09/26(土) 15:26:21

Linuxの8iって人柱Verだった頃のじゃね？

まあ、未だにそれで動いているトコはあるんだろうけど。

**NAME IS NULL** · 2009/09/26(土) 20:34:26

要するに人柱バージョンを2000万でうりつけてるのかｗ

**NAME IS NULL** · 2009/09/26(土) 21:00:40

値段は規模にもよるから、Linuxで8iで2000万が高いか安いか判断が難しいが。

HP-UXの8でもそれくらい取るベンダー見た事あるし。ただイニシャルはともかくランニングコストは
あんまし安くなかったが。年600万くらい。

Linuxの8iは自己責任と言うからにはランニングコストは０なんだろ。w

DB2(iSeries)だとイニシャルは下は300万で上は２億くらいの幅でランニングは100～600万くらい飛んでいく。

**NAME IS NULL** · 2009/09/27(日) 03:34:04

8iの頃はソラリスが鉄板だったので、リナックスなんて選んだほうが自殺行為なだけ。
東証がポスグレ採用なんて無謀な事はしないのと同じ。

IBMに丸投げ出来るぐらいの資金が有るなら、日電や不実に丸投げしてオラクルの面倒見てもらえるけどな。

うちはRACだけど意味不明に落ちてもリカバリは出来る仕組みにしてるよ。
そもそも絶対に落ちないなんてあり得ないし、ソフトのバグが無いのも信用してない。PGなんてバグ入りの欠陥品しか作れないし。製造業の品質管理に比べたら認識が甘過ぎるよ。
逆に、ポスグレは絶対落ちなくてサポートも満足と保証されてるの？

２億の案件でポスグレで組んで、損害賠償なんて喰らったら人生終わるなw

**NAME IS NULL** · 2009/09/27(日) 04:40:49

oracleは絶対落ちないなんてありえない前提なのにpostgreには要求するのかｗ
どんなdbを使おうがフェイルセーフな構成にすればいいって自分で答えだしてるじゃん

**NAME IS NULL** · 2009/09/27(日) 19:50:33

>>326
なんかあんまし大型案件やった事ないみたいなのでコメントだが。
規模と傾向もあるが基幹系ならIBM(i)とその他のベンダー＋Oracleの組み合わせだとIBMの方が半額くらいのコストで開発・運用が可能だ。
無論、Oracleの方がコスト安いケースもあるが、「IBM＝高い」と言うのは思い込みだ。
ある程度以上の資金がいるのは事実だが、>>326の意見は「安物買いの銭失い」な思考だ。

そして東証もけっこう落ちてるじゃねーかｗ

**NAME IS NULL** · 2009/09/27(日) 20:40:49

いいよな。天下りで仕事もらえるようなところは。
東証を落としてもお咎めなしだぜきっと。

**NAME IS NULL** · 2009/09/29(火) 01:30:04

逆にIで落ちてたら大変なんじゃねw

**NAME IS NULL** · 2009/09/30(水) 01:32:27

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

**NAME IS NULL** · 2009/09/30(水) 05:39:47

痛い目に会うような複雑なシステムじゃないから or ( 痛い目は末端がくらって表に出ない and それが痛い目だと気が付いていない )

**NAME IS NULL** · 2009/09/30(水) 16:53:59

ちゃんとコスト計算が出来るまともなエンジニアが皆無。

**NAME IS NULL** · 2009/10/09(金) 23:00:06

アプローチ使ってるけど、アプリの使い方じゃなくて、データベース設計の初心者本てなんかないかな

**NAME IS NULL** · 2009/10/10(土) 17:22:36

>>334
デマルコ読め