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

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

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

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

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

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

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

**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

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

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

**NAME IS NULL** · 2009/06/28(日) 00:47:26

日本で仕事をしない。
これ最強。

**NAME IS NULL** · 2009/06/28(日) 02:52:03

理解しなくても、会社の資本金を出してたり、出資者から任命されてたりするから権限持ってる。
文句有るなら自分の資金で設計遣ってれば良い。

**NAME IS NULL** · 2009/07/27(月) 20:54:41

どんなまずい設計のシステムでも、
実際に運用されていて問題のないものはあまりいじらないものだよ。

**NAME IS NULL** · 2009/07/28(火) 06:21:49

まずさ加減に寄るな。
致命的なのや、将来的に問題になりそうなのは苦労してでも弄らないと後で困るよ。
弄らないまでも、報告だけはしてシステム関係者の中で共通認識は築いておくべき。
後で、問題が起きてからDB担当の個人の責任にされたほうが割喰うよ。

**NAME IS NULL** · 2009/07/28(火) 21:02:53

もちろん問題点の把握はしておかなければいけない。
あと、問題が発生して誤動作したときのリカバリーの手順とかもマニュアル化しておく。

**NAME IS NULL** · 2009/07/29(水) 03:38:45

誤動作する時点て致命的じゃないのかなあ。
データ失うよね？

**NAME IS NULL** · 2009/07/29(水) 14:16:26

>>203=205は
もっともらしい事言いたいだけの
他の板に居場所がない老害コボラー

**NAME IS NULL** · 2009/08/10(月) 19:46:20

>>206 完璧主義者の集まりが作ったシステムならあっさりデータなくなるだろうけど
多少の開発経験がある人が居れば DB経験がなくてもバックアップや履歴、ログは残るはずだよ
スムーズに復旧できるかどうかは別の問題だが…

**NAME IS NULL** · 2009/08/22(土) 00:12:51

むやみに正規化できないケースはいくつもあるぞ。
顧客コードとそれに対応する顧客名称などがテーブルにあっても、
実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
顧客名称のみ画面から入力したいという与件があったりするケース。
ＥＤＩで顧客からマスタと依頼データをもらっていて、
依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
いけないケース。
複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
必要があって、下手にデータの持ち方を変えてしまうと、
明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。

**NAME IS NULL** · 2009/08/22(土) 02:06:14

>>209
>顧客コードとそれに対応する顧客名称などがテーブルにあっても、
>実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
>顧客名称のみ画面から入力したいという与件があったりするケース。
>ＥＤＩで顧客からマスタと依頼データをもらっていて、
>依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
>いけないケース。

これは別に全然問題ない
「顧客名称のみの登録もできる」
「依頼データをもらった時点の値を保持する」
という仕様のもとに設計して正規化すればいいだけの話

>複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
>必要があって、下手にデータの持ち方を変えてしまうと、
>明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。

これはありがちな話で、実際妥協してしまうことも多いんだけど
そもそも「明確に仕様化されていない部分」があることが問題なわけで
正規化できない理由にはしてほしくない

**NAME IS NULL** · 2009/08/22(土) 03:20:06

その辺は正規化してちゃんと効果有るの？
正規化したいだけの自己満足程度？

**NAME IS NULL** · 2009/08/22(土) 04:39:23

>>211
正規化することに理由を求められてもな・・
逆に「正規化しないこと」にこそ理由が必要だと思うんだが

逆に質問していい？
「君の会社の開発標準において、論理データモデルを
作成するという工程はないの？」

**NAME IS NULL** · 2009/08/22(土) 06:57:35

あるわけがない。

**NAME IS NULL** · 2009/08/22(土) 15:07:29

最近、クラウド絡みで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なんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。

もちろん、全てのケースでこの形でうまくいくとは思えないが多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。

今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（究極的にはテーブルは一つで全レコードがそのテーブルの中。レコードを区別する為のコードがさらに必要にはなるけど）

**NAME IS NULL** · 2009/08/22(土) 15:16:00

RDBすてろよｗ

**NAME IS NULL** · 2009/08/22(土) 18:01:32

>>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？

>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
>・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな

>多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
頭使わなくて済む個所が減ったらダメだろｗ
いままでSQL書いただけでやってくれてたことを、全部自前で実装するんだぞ？
プログラムしないといけないことも増えるし、頭使うとこも増えると思うがな

>今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（
いまのRDBMSでも、やろうと思えばそういう風にできるわけだ
でも普通はみんなそんなことはやらない。それが答えだと思うがな

メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
このままだと頭使わない奴にとってメリットがあるって結論になるなｗ

**NAME IS NULL** · 2009/08/22(土) 18:50:31

>>216

>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？

最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリットになると思います。

>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな

SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。

>頭使わなくて済む個所が減ったらダメだろｗ

”余計な頭を使う箇所が減る”の間違いでした。

>メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか

メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。

>このままだと頭使わない奴にとってメリットがあるって結論になるなｗ

おっしゃるとおりで、このスレッドの趣旨には反しますがこれが一番のメリットと思います。頭を使う必要が少なければ、設計する人によって品質がバラバラという可能性が減るのではないのでしょうか（こういう構造で業務を満たせるのであれば）。

職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。

**NAME IS NULL** · 2009/08/22(土) 19:11:02

>>214
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ

**NAME IS NULL** · 2009/08/22(土) 21:45:36

開発効率が３０年前に逆戻りすることだけは確実だな…

**NAME IS NULL** · 2009/08/22(土) 22:12:18

馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。

**NAME IS NULL** · 2009/08/22(土) 22:19:41

>>217
>職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。

逆だ。DBでやらない分アプリでやることが増えて、
プログラマの腕頼みになるだけだ
みんなが言ってるとおり、時代に逆行しているよ

**NAME IS NULL** · 2009/08/23(日) 00:47:33

カスは時給安くても働くから、時給高い熟練は不要になるしな。熟練にしか出来ない正規化とかの無駄な仕事が必要ｗｗｗ

単にDB使いこなせないからアプリでがんばるよ的発想だよな。
SQLを使ってたほうが遥かにパフォーマンスが良い現実。
これまでの歴史で今の状況に成ってるのを理解しないと。

オブジェクト廚が、オブジェクトDBなら便利になるぜとかのたまってたけど遅くて結局は消えてるし。
また馬鹿が湧いて、無駄な事を繰り返すのかな。

**216** · 2009/08/23(日) 01:05:42

>>217

>最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリット
クラウドにしやすい、ゆえにスケールアウトしやすいメリットがあるっていうならわかるが
クラウド云々関係なしにってのはお前の出した前提条件だが？
クラウドにしないでスケールアウトってんならデータ形式はあんまり関係ないだろ
あくまでクラウドに適してるのがメリットであって、スケールアウトは副次的な話だ

>SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。
オプティマイザが入るSQL処理でさえ簡単にそれだけの差がでる。
自前アプリでその処理をやるわけだ
みんながみんなSQLのオプティマイザより賢くプログラム組めるのか？
>みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。
みんながみんなプログラムのエキスパートであれば問題ないのですが。
それに比べれば(SQLの方がオプティマイザある分)ましかなと思ってます

>メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
いやだからその２者をくらべたときに、誰にとってメリットデメリットだと？
ほんとに頭使わないシステム開発者にとってのメリットでいいのかよ

>品質がバラバラという可能性が減るのではないのでしょうか
減るかもしれんな。頭使わない安価粗悪な物によってまともな物が駆逐されてな
全体のレベルを下げるだけだ。品質低い方に統一してどうする

>職人頼りなシステム開発が工業製品へと
工芸品が工業製品になるためには、その職人の技が一般化されてることが必要なわけで
一部の人しかできないことを、だれにでもできる事だけで作ったとしてもそれは単なる粗悪品
一部の人しかできなかったことを、誰にでもできるようにしないと意味がない
そのために論理や技法があり、それを学んだり論議したりしてるんだよ

お前の主張は、
工業製品ならだれでも作れないとダメでしょ。
馬鹿にはシステム開発できないんで、システム開発は工業製品じゃないよね
ってことだ

**NAME IS NULL** · 2009/08/23(日) 01:25:59

>>214袋叩きワロタw

**NAME IS NULL** · 2009/08/23(日) 02:35:18

>>217
> みんながみんなSQLのエキスパートであれば問題ないのですが。

SQLのエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。

**NAME IS NULL** · 2009/08/23(日) 03:11:11

おっ！最近レス多いですねぇ。いいじゃないですか。
スレの趣旨に合っていれば、DB技術者の意見を気軽に言い合ってもいいんじゃない。
レスが一つ入ると反応する方が結構居そうなので。

それぞれ扱ってるシステムの規模や影響、会社の風土とが違うでしょうから、
一概に良いか悪いかは言えませんが。

**NAME IS NULL** · 2009/08/23(日) 04:28:10

>>214
とりあえず、「KVS的な構造」といって後者はないだろう。

**NAME IS NULL** · 2009/08/23(日) 07:11:42

>>214
COBOLやRPGの時代にそういうテーブル設計しているのありました。

今SQLで実装している業務を試しにCOBOLで実装してみたほうがいい。

まあ、あの時代はある種夢の時代だったな。
「おれ５０００ステップのプログラム作っちゃったぜ！」と
無駄に長いプログラムを作れば儲かった頃だし。

ちなみにSQLより速い処理が組めるRPGやCOBOLのプログラマなんて
ツチノコ並みの珍獣だと思うが。

**NAME IS NULL** · 2009/08/23(日) 10:56:13

>>228
COBOLやRPGは知らないけど、「処理の速さ」という点では
プログラムでゴリゴリ書いたほうが良いこともある
DB側（リレーション、制約、ストアド、SQL）に機能を持たせる
一番のメリットはやはり保守性だろう

**NAME IS NULL** · 2009/08/23(日) 13:45:30

サーバーでやるかクライアントでやるかの違いだろうね。>>214

メリット・デメリットは>>214の他に
メリット
自分で最適化できる。
デメリット
サーバー/クライアント間のデータ転送量が多くなる。（高速LANなら無視できる）

かな？

**NAME IS NULL** · 2009/08/23(日) 14:32:06

>>229
ストアドの速さに勝てるの？ありえなくないか？
DBに機能をもたせると保守性は落ちるとおもうが。

**NAME IS NULL** · 2009/08/23(日) 15:05:03

ストアドにしたからといっては飛躍的に高速になるわけではない。

**NAME IS NULL** · 2009/08/23(日) 16:21:00

処理の種類によるけど遅くなることはないだろｗ

**NAME IS NULL** · 2009/08/23(日) 21:31:35

データをどこに持っているかにもよる
DBMSに格納されているなら、そのDBMSに特化したストアドより早く外部プログラムが
実行できるとは思えない。
ストアドでも外部プログラムでも、ロジックは同じように作れるわけだからな

保守性については、システムの保全とか改修のしやすさとか、
何を主眼として保守性とするかによって変わると思うが

**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
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ