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

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

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

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

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

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

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

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

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

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

**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のエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。