2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

頼むから正規化しろよ

1 :パフォチュー:03/08/12 21:13 ID:uJybnGok
「パフォーマンス悪いからSQL見直せ」ってあんた。。。
まるっきりDBが正規化されてねーじゃんか!
「冗長化したほうがパフォーマンスがいい」だと?
ハッシュ・ジョインくらい勉強しろ!
論理設計からやり直せ!その前に自腹でベンダーの講習受けて来い!

だからPJに途中参加するのは嫌なんだよ(鬱

2 :名無しさん@お腹いっぱい。:03/08/12 21:22 ID:uJybnGok
2げっと

3 :禿道:03/08/12 21:40 ID:ClWPxTzt
>>1
よくわからんが取り敢えず同意

4 :名無しさん@お腹いっぱい。:03/08/12 21:59 ID:???
素人さんが設計したDBなんて使えません。
システムの中枢部分をな〜んでいい加減に設計するの?
プログラマは苦労する罠

5 :禿道:03/08/12 22:25 ID:ClWPxTzt
>>「冗長化したほうがパフォーマンスがいい」
嘘じゃ無い。
否定できないお前もDQN。
更新の頻度にもよるが書き込み時間を気にしないなら、データの冗長化は
データアクセス時間を短縮することができる。

冗長データが手入力じゃ無いなら、許せ。
俺は手入力を相手に毎日格闘している。

6 :名無しさん@お腹いっぱい。:03/08/12 22:52 ID:uJybnGok
>>5
はぁ?冗長化なんか今時、推奨するところなんてあるの?
PGは複雑になるし、保守性悪いわ、柔軟性はないわ、
テーブルは無駄に巨大化してくわ。。。メリットなんざ思いつかんね。
だいたい何の為のハッシュ・ジョインなんだよ。
つーか、まず正規化してから冗長化など検討すべきだろ。
ロクでもない設計して言い訳的に
「冗長化したほうがパフォーマンスがいい」
なんて言われたら、そりゃキレるよ。

7 :名無しさん@お腹いっぱい。:03/08/12 23:09 ID:FNgPW25+
そんなこといったら、漏れのとこなんて救いようがないぞ。
かなり複雑怪奇なSQL発行しまくり。
副照会か6階層くらいあってたり、仮想領域を3つくらい使ってたり、
もうめちゃくちゃでわけわからん。

作った本人の漏れでさえ、何やってるかわかんなくなる。
まじこんなDB腐ってる。

8 :名無しさん@お腹いっぱい。:03/08/12 23:23 ID:???
また糞スレか・・・・

9 :名無しさん@お腹いっぱい。:03/08/12 23:36 ID:???
俺のところのアプリ部隊はVIEWしかアクセス出来ない。
しかもHINTも使えないからチューニングのしようがない。
んで、制御部隊(設計者)にパフォーマンス悪いと報告すると
逆ギレされる。
一度CREATE VIEWのDDLを拝見したいもんだ。


10 :名無しさん@お腹いっぱい。:03/08/13 00:05 ID:???
DBの設計不良で苦労しているところはよくあるんですね。

チューニングの基本はSQLの見直しだとは思いますけど、
やはり正規化してないと整合性がとれなくなったりして
思わぬバグを誘発する恐れもありますし。

以前、「正規化できないんだよ。このシステムは」なんて平然と
言ってのけるSEがいました。
それでよくBIG ITとかよく宣伝してるなぁと感心しました。

11 :名無しさん@お腹いっぱい。:03/08/13 00:10 ID:???
書き込みのトランザクションがバンバン発生するようなシステム→正規化
でっかくって非定形処理の多いデータウェアハウス→冗長化

どっちにしても、色々チューニングして一番ウマーな状態に
するのはめんどうなのれすよ。


12 :無料動画直リン:03/08/13 00:17 ID:HOrs3D4h
http://homepage.mac.com/miku24/

13 :クラッシャー堺:03/08/13 15:00 ID:JkUi5yos


14 :名無しさん@お腹いっぱい。:03/08/13 18:34 ID:F+w598Ig
データモデリングが大切っちゅーことやね。

15 :v:03/08/13 19:45 ID:cIhiASLL
お色気たっぷりなんですがどこか可愛らしさが漂う綺麗な人妻です。
スレンダーなボディーが更に色気を倍増させている気がします。
じっくり見つめながらフェラをし、小さめのオマンコに男根を導いていきます。
こういう年の取り方をしたいですね。
無料ムービーからどうぞ
http://www.excitehole.com/


16 :名無しさん@お腹いっぱい。:03/08/13 19:46 ID:???
完璧に正規化してくれとは言わない。
冗長化もまだ許せる。
だけど、だけど・・・

横 に 長 い テ ー ブ ル を 作 る の だ け は 勘 弁 を・・・

数量1,2,3・・・10ってなんだよ・・・




17 :名無しさん@お腹いっぱい。:03/08/14 02:01 ID:???
俺、255カラムあるテーブル、30個のDBあつかったことある。
さらに結合いっぱい、書き込みいっぱい、I/Oもメモリもいっぱいいっぱい。
帰りたかった。


18 :名無しさん@お腹いっぱい。:03/08/14 09:05 ID:???
>>16
その系統で数量128とか見て眩暈を起こしました。
数量じゃないけどさ・・・。

19 :山崎 渉:03/08/15 21:58 ID:???
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

20 :山崎 渉:03/08/15 22:49 ID:???
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

21 :名無しさん@お腹いっぱい。:03/08/16 03:15 ID:Nt2klYxE
正規化するのはシステム設計上、当然ですわな。
それを知らずに堂々とコンサルタントするF通の馬鹿さ加減には
うんざ〜り。
一生、SQLは外だしして、クライアント・カーソルを用いて
DBサーバーを苦労させてね!

22 :名無しさん@お腹いっぱい。:03/08/16 03:43 ID:???
F通・N電気・H立...
日本のベンダーは開発(設計)能力無いねぇ。
ちっとは頑張って画期的なDBMSでも作ってね(無理でも)




ゲイツより茂雄が好きな日本人より。

23 :名無しさん@お腹いっぱい。:03/08/16 03:50 ID:???
>>22
>ゲイツより茂雄が好きな日本人より。

それ、わかりづらい!

24 :直リン:03/08/16 09:17 ID:TIJMps1c
http://homepage.mac.com/maki170001/

25 :名無しさん@お腹いっぱい。:03/08/16 13:17 ID:t/5MsxPF

 正規化できない場合があるよ。
 客が主キー制約をどうしても認めない場合。
 あと、テーブル数で料金が決まってる場合とか。
 客はいろんな可能性を後へ残しておきたいんだろうけどな。

 技術的にも論理削除がやりやすいとか言う、逃げもある。

 元々の設計が悪いとか、レビューが悪いとかいうのもあるだろうけど、
 俺が思うには、経験を持った人間がポリシーを持って対処するしかない。
 そうして初めて正規化のメリットがデメリットを上回る。
 この損益分岐点は実は結構高いところにあるのだ。


 

26 :名無しさん@お腹いっぱい。:03/08/16 13:20 ID:???
>>25
あと、下手なDBにしといたほうが、メンテとか仕様変更で金を取れるというのも
あるかもしれんな。 人月で金払ってるんだからこうなるわけだ。

27 :名無しさん@お腹いっぱい。:03/08/16 17:33 ID:???
>>9
select * from viewをexplainで見てみたらいいよ。
DQNな実行プランが出てくるんじゃねぇか?

28 :名無しさん@お腹いっぱい。:03/08/17 20:45 ID:+oqRYfoP
>>27
実行計画採取のGRANTさえ無いユーザじゃない?
うちはそうだよ。




7 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)