トップページ⇒tech
906コメント323KB

【ノウ】DBアプリ開発ノウハウ【ハウ】

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
・SQL文をコード内に埋め込むとコードが汚くなっちゃう。うまく分ける方法無い?
・似たようなSQLがあっちこっちのプログラムで出て来るんだけど…
・Viewとかストアドとか、みんながポンポン作っちゃって収拾付かないよ〜。
・分かりやすく長すぎないテーブル項目名のつけかたは?
・見やすい帳票レイアウトって? 入力しやすい画面遷移って?

などなど、悩むところはみんな一緒。
DBアプリ開発のノウハウを語るスレッドです。
0153デフォルトの名無しさんNGNG
>>145
テーブルTBLに1000万レコードあるとして
項目Aは 2通りの値を持ち
項目Bは100万通りの値を持つとき
(値はほぼ均等に分布しているとする)

select * from TBL where A=1 and B=1
と
select * from TBL where B=1 and A=1
では効率が全然ちがうでしょ
0154デフォルトの名無しさんNGNG
>>153 自己レス
複数のテーブルを組み合わせるともっと極端になるね
0155デフォルトの名無しさんNGNG
>>153
それぐらいならオプティマイザで勝手にしてくれない?
0156デフォルトの名無しさんNGNG
>>155
そっか・・・最近のはそうみたいだね
実装によっても違うし、一概にはなかなか難しいかな〜
0157デフォルトの名無しさんNGNG
そんな高度な奴じゃなくて、Like条件を無意味にORで繋いでたり
それを更にANDで括ってたりする奴もいた。
0158デフォルトの名無しさんNGNG
>>152
サンクス
逝ってきた。(というより、すでに逝っていた)
tp://www.blue.gr.jp/~munetika/mllog/o4l/msg00733.html 等

RECORDS_TOTAL < 65535
のばあい
control_file_record_keep_time=0
とせよとあるので複数のRedhat6.2のノードで対処済みだが、

65535の約半分の回数のインサートでクエリが止まり、しばらくすると
ORA12571が・・・

今試したが何の対策もしていないSolaris8では32000は上回る
と思われ。

うーん、数字だけ見てると単に自分がドキュソか。
スマソ。もっとよく逝ってくる。
0159デフォルトの名無しさんNGNG
>>156
おいらもしっかりWHARE句の最適化はやってるよ。
確かにオプティマイザが勝手にやってくれるDBが多いけど。
基本的に良い習慣だと思っている。

Cのif文は発生する確率が高い方からチェックするようにすれば高速化できるしね。
そういう地道な努力は高速化する上での重要な要素の1つとだと思う。

普段から注意していないと、なかなか身に付かないしね。
0160138NGNG
>>136
では解説
RDBじゃインデックスを使うかどうかパフォーマンスに大きな影響が出るわけよ。
単純で簡単なことだけど、一番大事なことなわけ。

インデックスの基本理論からするとDBMSに依存する部分は少ないよ。
複合インデックスは順番に評価する
インデックス列に関数は使わない。
これは大原則です。

結合が多くなっても同じことが言えるわけで
分からないということはおそらくアクセスパスの解析をしたことが無いってことだろう。

まあ確かに端折りすぎた。
もっといい例きぼん。

>>159
良い習慣だと思う。
0161デフォルトの名無しさんNGNG
データ量やインデックスの種類も重要だと思われ。

データ量が少ないと主キーは別としても最近のRDBエンジンは
インデックスなんて使わないでしょ。

2値の列にハッシュインデックス貼ったりするのも激しく無意味だし。

やぱり最終的なチューニングは各DBのアクセスパス解析ツールを
使わないと、そのエンジンによっぽど精通してないと
人間の判断なんてあてにならないような気がするぞ。
0162デフォルトの名無しさんNGNG
>>161
最終的にはそらそーだ。
ただDBMS依存の最終的なチューニングによる効率UPよりも
非依存の基本的なチューニングの効率UPのほうがでかいって話では?

>2値の列にハッシュインデックス貼ったりするのも
これだって非依存だろ?

0163161NGNG
なるほど、そうだーね。基本がひどいとまずいやね。そりゃ。
基本を押さえた上で、DBMS依存のチューニングをかけると。

ただ、インデックスのチューニングって結構むずかしいと個人的には思ってるのよ。
運用中に頻繁に更新があるならたくさんつくりゃいいってもんでもないし。

いろんな検索パターンがあるシステムだと、多数決とゆうか、重要度とか
人間的な判断で決めちゃったりして。>みんなはどーよ。

個人的に欲悩むのはJOINしたテーブル同士の検索条件は、
Where節で指定するか、JOINのONで指定するのがいいかって事かなー。
アクセスパス見るとまったく変わらなかったりするのだけれど。。。
0164デフォルトの名無しさんNGNG
WO使ってみた。
SQL書く必要なかった。
(バックエンドで発行されてるSQLは見られる。)
1つのオブジェクトに、別々の鯖で動いてる別製品のRDBのテーブルをマップできるらしい。
なんか鬱。
0165デフォルトの名無しさんNGNG
>>164
ふーん。すごそーだな。
これも会社に買わせようか・・・・


つかこのスレのせいで稟議書がふえてるな(w
Visioといい、ERWinといい、WebObjectといい・・・
0166デフォルトの名無しさんNGNG
>個人的に欲悩むのはJOINしたテーブル同士の検索条件は、
Where節で指定するか、JOINのONで指定するのがいいかって事かなー。

実際には同じ実行プランに落ちるはずなので、好みでいいんじゃない。
ノウハウというのもなんだけど、ある程度複雑なSQLを使うときは実行プランは
確認しようね。とんでもないプランで実行しているときがあるから。
0167デフォルトの名無しさんNGNG
SQLはDBやバージョンごとにチューニングのポイントがあるから
それを調べておけ。

で、まともなDBならインデックスが期待したとおりに使用されるかどうかの
実行プランがみれるから、それを使え。

オプティマイザにも色々種類や特性があって、少し柔軟にインデックスを
見に行ってくれるものや、明示的に統計情報を取得・更新しないと
まともな最適化をしてくれないものとかある。

SQLレベル以外にも、DBへのコネクション方法やテーブルレイアウトの設計、
インデックスの分散や隣接配置、テーブルスペースの配置、
ディスク装置の選択やRAIDの選択、使用メモリのチューニング、
ログの分散、管理、バックアップ・レプリケーション、
見るべきところはたくさんある。

一個だけつまんで見せて、「コレひどいよね」といっても、
木を見て森を見ず、の場合だって有るのだ。
0168デフォルトの名無しさんNGNG
私はオプティマイザは使わないほう(以下Oracleの話ね)。
タコSQLの被害低減ぐらいと思っている。

何より困るのは、開発、評価、実機で動作が変わるから。

また、アナライズもかけないで、オプティマイザを使っています
という、タコプロジェクトも見たことあるが、実データがない場合は
評価困難だしね。

個人的には重そうなsqlはかいたらすぐプランとって見るし、
少なくともチューンするときはヒントで、プランを
固定するようにしている。

Oracleもルールはなくして、コストベースにだけしますと
とずーと昔から言っているが、ずーとできそうになさそう。
ただ、コストベースでないと使えない機能があるので、
DB自体はコストベースにして、ヒント等で固定化してる。

知り合いのプロジェクトでは、外注に納品物件にプランの
提出を義務づけ、とりあえず(full)をチェックしてるみたい。

動的SQLはどーすんだと突っ込まれると思うが、量的には少ないし、
完全に読めないことはないので、インデックスあてといて、あとは
テスト、運用で発見個別対応になるね。なにより、できるやつに
その仕事をふること。

ただ、一度50人ぐらいのプロジェクトでは、動的SQLを作成する
ルーチンを書いて、表名、フィールド、条件とうの入力と、検索結果
をテーブル渡しにして、動的SQLの発行を一箇所でコントロールしたこと
もある。実際に発行されるSQLをログって監査する必要があったこともだが、
タコに動的SQL書かせて、後でデバッグ、チューンする恐怖より、
このルーチン作るほうを選んだ。
0169デフォルトの名無しさんNGNG
あのさぁ、外部参照制約とかデフォルト制約って使ってる?
うちの会社なんでか使ってないんだよね。
テーブル設計書とかにはちゃんと初期値 = 0 とか、初期値 = システム日付 とか
書いてあるのに、デフォルト制約にしないで、入力プログラム(VB)で
発行するInsert文やUpdate文で明示的に 0 とかシステム日付セットしてる。
0とかの固定値はともかく、システム日付をVBで算出するとクライアントの
時計を使ってしまうので、困ると思うんだが…。

外部参照制約に関してもまったく設定してないんだよ。
仕様書には「商品マスタに該当レコードがあるかチェックする」とか書いてある。
外部参照制約作っといて、例外補足すればいいんじゃないの?

他の会社でもこんなもんなのか?
0170デフォルトの名無しさんNGNG
DBアプリ作るのに、SQL最適化なんて本質の話しじゃないね
できればSQLなんて書かずに、ビジネスロジックの作り込みに専念すべきだ
そんな部分にパワーかけてどうする
0171デフォルトの名無しさんNGNG
>>170
性能で客から怒られたことのない素人が紛れ込んだ模様。
0172デフォルトの名無しさんNGNG
>>171
SQL作成とインデックスの追加申請くらいしかやらせてもらえない
駆け出しが紛れ込んだ模様。
0173デフォルトの名無しさんNGNG
>>171
なんだ、新卒ブビ厨?
SQLごときでパフォーマンスでないような作り方してんのか。まさにドキュソだね。

俺もWO使ってるけど、SQLなんか一度も書いたこと無いし、客から怒られたこともない。
元々金融系から始まって10年くれぇの実績のあるフレームワークと、
たいしたスキルも無い厨房が書くゴリゴリのSQLと、客はどちらを信用するのかねぇ(w
0174デフォルトの名無しさんNGNG
SQL作成に血道をあげるのはいいんだけど、ちゃんとロッキングとかやってないSQL厨って
けっこう多いんだよね・・・
0175デフォルトの名無しさんNGNG
一部のDB屋って特定DBのチューニングテクニックを知ってるだけで
鼻高々としてるから可笑しいよね。運用上は必要だけど、DQN仕事だな。
俺はやりたくない。

DBを、単なるデータストアでなく、ソフトウェアコンポーネントの一つとして
見て欲しいんだがなあ。どうもデータが出たり入ったりするのを見て
エクスタシー感じてる連中が多いみたいだね、ここには。
0176デフォルトの名無しさんNGNG
そりゃ、出たり入ったり入れたり出したりってのは、気持ちがいいからなぁ(w
0177デフォルトの名無しさんNGNG
イン・アウトがキモチイイ(・∀・)のは世界共通語だYO!
0178デフォルトの名無しさんNGNG
とりあえず、今のところWebObjectsが最高なのはゆるぎない事実だ。
0179デフォルトの名無しさんNGNG
>169
同意。
外部参照制約のデメリットは、更新時のパフォーマンスなんだが、データが腐ることよりはずっとましと思う。
昔、あるシステムの改造をいらいされて、DBリバースしてみたところ、ただの表のあつまり。エクセルじゃないんだからってなかんじ。
案の定、データ腐りまくりで、開発より、データクリーング、移行のほうがはるかにコスト高。
ってことで、その案件はつぶれた。

デフォルト値は、場合によりけりだね。
追加開発で、新しいnotnullの属性を追加するときとかに、仕方なくデフォルト
入れることはあり。
0180デフォルトの名無しさんNGNG
>173
金融やってたってひとで、自信あるやつ多いんだけどさ。
コンサルでは使いk物にならないこと多し。
金融の場合は、目的が明確なこともあると思うが、まったく
別種のビジネスでのコンサルに入ると分析能力無し。

技術てきにも、そのすばらしいフレームワークとやらのおかげで、
自分で一から構築したことがないんでまるで、提案できない。
0181デフォルトの名無しさんNGNG
>>178
でも、あまりWebObjectsは広まって欲しくない・・・
誰にも使わせたくないっていう感じ(藁
わかるだろ?この感覚。
0182デフォルトの名無しさんNGNG
>>180
日本語もまともに理解できないアフォドキュソですな(w

金融系やってた人間そのものの話しなんかだれがしてるんだよ。
WOの実績の例を出しただけだろ。
使い物にならないコンサルを、カバーするだけの力量がフレームワークにあるってことだ。
SQL以前に、小学校から国語をやりなおしてこい。

そもそも、一から構築したことのないヤツに、WOを使わせても無駄。
自前で実装した苦労や、他のツールで地獄を見た経験を持ったヤツだけが、その価値を理解できる。
0183デフォルトの名無しさんNGNG
>>181
広く使われるとボロが出るからな。
悪い評判が立つと客が嫌がるし。
0184デフォルトの名無しさんNGNG
>>183
うんそうだね。だから、君には必要なんだろう。
いつまでもSQLの作り込みに勤しんでくれたまえ。
自分で何もかも把握できた方が、効率よく作ることより重要だからな。
0185デフォルトの名無しさんNGNG
失敬、

>だから、君には必要なんだろう。

は、

>だから、君には必要無いだろう。

に訂正。
0186デフォルトの名無しさんNGNG
>>181
うん。すごくわかる。
でも、広まってくれないとWebの案件をWebObjectsで提案しても蹴られる可能性あり。
0187デフォルトの名無しさんNGNG
>自分で何もかも把握できた方が、効率よく作ることより重要だからな。

これが相反関係にあると言いたいのか?
すげーな。
0188デフォルトの名無しさんNGNG
>>183
まあ181はマカー根性丸出しってことで
sagesage
0189デフォルトの名無しさんNGNG
マックは触ったことないですけど
WebObjectsはWindows2000で開発してソラリスで運用するんだよ
0190デフォルトの名無しさんNGNG
>>187
つくづく厨房だな(w
お前、PGでもコーダーの部類だろ。
0191デフォルトの名無しさんNGNG
184は効率という言葉を使いたかっただけだろうね。

>>187
トレードオフという言葉を覚えましょう。
俺もそれらがトレードオフになるとは思わないけど(w
0192デフォルトの名無しさんNGNG
>>170と>>180およびその周辺。

>>1もろくに読めない馬鹿が雁首そろえて偉そうなこと言うな。
0193デフォルトの名無しさんNGNG
せっかくの良スレがぁ...
0194デフォルトの名無しさんNGNG
良スレだったのか
0195デフォルトの名無しさんNGNG
いや、最初から糞スレだったような…
結局 【自慢話を語るスレでした】 って事だな
0196デフォルトの名無しさんNGNG
グチってても仕方ないから次いきましょう。

DBアプリを納品してからも仕様の変更・追加ってあるよね。
テーブル設計が変わっちゃったりした場合とか、被害を最小限にしたいよね。
そのためにやってることってある?

WebObjects、.NETなど、オブジェクトに自動マッピングされる環境では
仕様変更ってどうなるの?
0197デフォルトの名無しさんNGNG
WebObjectsでは、仕様変更も他に比べて柔軟に対応できるよ。
DBが絡んだWebアプリでも、表示項目とUIが同時に変更になったとしても、
開発ツール上でデザイン変更できるし、DBとの接続もドラッグ&ドロップでほとんど完了。
他のJavaベースのツールみたいに、泣きながらゴリゴリ再コーディングっていう手間はあまり発生しないなぁ。
もちろん、純粋なビジネスロジックのコーディングし直しってのもあるけど、
かなりの部分がフレームワークが提供するメソッド利用するだけで目的が達せられるから
開発者としては、とても楽。

.NETって、どうなんだろうね?
0198デフォルトの名無しさんNGNG
>>196
ありきたりだけど…
(1) Select項目は明示して * を使わない
(2) Insert項目も明示的に指定する
こうしておくと、仕様変更でテーブルにフィールドが追加されても
その追加フィールドにデフォルト制約を付けておけば、
既存のプログラム(参照、更新ともに)結構動くよ。
0199デフォルトの名無しさんNGNG
SQL意識してる時点で、使う側に立った開発よりも開発者よがりの開発になるな。
0200デフォルトの名無しさんNGNG
>>199
ユーザーが使いやすいシステムを構築する上で
ストレスを感じさせないだけのパフォーマンスは必要

SQL云々もその一環だから使う側に立っていないとはいえないと思うよ

おっと、200ゲトー
0201デフォルトの名無しさんNGNG
>>199
確かにその観点はある意味間違っていない。

だが客にとっては、
SQLを直接書こうが書くまいが、WebObjectsだろうが、Javaだろうが.NETだろうが、
結果を出せるかと、最後まで責任をとれるか、が重要だと思う。

だいたいこの世界、欧米も含めてまだぜんぜんWebObjects一色ってわけじゃないでしょ?
WebObjectsがまだ知られていないというわけでもないだろうし。

欧米のメーリングリストなんかでもまだまだSQLネタって多いしね。
そこが現実ラインでしょ?
0202デフォルトの名無しさんNGNG
>>200
概ね同意だけど、ストレスを感じさせないだけのパフォーマンスを出せる実装を
できるだけのスキルのあるやつって、現場レベルでも最近少いような気がする。
パフォチューなんて思想無し。た〜だSQL書いてますみたいなやつ。
派遣や外注でやってくるヤツラで、「おお!こいつやるな!」みたいな人間にここ数年出会ってない。

なんていってるおれも、最近WebObjects始めた。
WinXPで開発、Linuxで運用。
なんつーか、目から鱗。
DB使うWebアプリが、ここまで効率化できるとは思ってなかったよ。
パフォーマンスも問題なし。

しかし、こんなツールが何故広まってないんだろうか。
アップル製だからかな?
Webオーサリングツールと勘違いされてるとかね(ワラ
0203デフォルトの名無しさんNGNG
WebObjectsが流行らないのは、元請が売ってるツールを使わされるからでしょ
WebObjectsは7万円だけど、他のツールは何百万ってするもんね。
そりゃ、高く売れるほうがいいよね。
0204デフォルトの名無しさんNGNG
>>199
バカじゃないの?
実装も意識して、かつユーザビリティも意識した開発するのが当たり前だろ。
それともお前の所ではそれがトレードオフになるのか?

>>1も
・見やすい帳票レイアウトって? 入力しやすい画面遷移って?

とスレの裾野が広がるような議題を持ってきているのにも関わらず、それを無視して
開発者よがりな話に持っていこうとしてるのはお前の方だろう。
0205デフォルトの名無しさんNGNG
>>204
おまえもわけわからん。。。。
0206デフォルトの名無しさんNGNG
>>204
同意。SQLしか意識していない技術オタは糞だが、
SQLを意識している技術者が、UIなどをないがしろにしているとは言えないからな。
>>205はもう一回読み直してみ?
0207 NGNG
「チューニング」や「正規化」が変にもてはやされたからね。

とりあえず動くモノを作って次にチューニング、なんてのはSQL屋失格だし、
「正規化」とやらも初心者向けというか暗記型向けというか、
最適設計にはならない。
0208デフォルトの名無しさんNGNG
>>203
マジか。WebObjectやめた。
0209デフォルトの名無しさんNGNG
>> 207
> 「チューニング」や「正規化」が変にもてはやされた

それが全てだとは言わないけど、それよりも大事なものって何なの?

一見するときれいな画面設計?
一見親切な操作方法?

画面設計や操作方法を考えるのももちろん大切だけど、
それよりも「システム」がしっかりしているが大事で、
しっかりした良いシステムを作るためには「正規化」が
大切だというのがいわば常識。

良いシステムを作るために「正規化」が
万能ではないという話ならばわかるけど、
207は良いシステムをつくるということを
考えていないように感じられる。システムが
ちゃんとしていないならば、本当の意味で
ユーザーにとって使いやすいアプリであるはずは
ない。
0210 NGNG
最初に設計ありき。
チューニングなんぞ「敵が城を囲んでから対応策を考えるようなもの」
正規化は「モノを考えられないアフォを訓練してあるレベルにまで持ってくる」
為の手法であって、マトモな設計者がやる事ではない。
0211209NGNG
> 最初に設計ありき。

全面的に同意。

> チューニングなんぞ「敵が城を囲んでから対応策を考えるようなもの」

確かに設計の段階でパフォーマンスも充分に意識すべき。
ただし神ならぬ人の身には、思いもかけず敵に城を囲まれる
こともあるし、その際には対応策を考えざるを得ない。

> 正規化は「モノを考えられないアフォを訓練してある
> レベルにまで持ってくる」為の手法であって、
> マトモな設計者がやる事ではない。

正規化よりまともな方法がわかるというのであれば、
設計者にしておくのはもったいない。世界的な研究者に
なれるんじゃないかな。現在のDB設計上、もっとも
マシな指針が正規化。それをまったく使わないのは
世界的研究者レベルの大天才か、ろくでもない設計者の
いずれかと思われる。
0212デフォルトの名無しさんNGNG
>>211
いや、正規化なんて誰に教えられるわけでもなく身に付くはずって事だろ。
手法と言うよりは理屈の話だしね。
それをわざわざ教えなければならないってのが
>「モノを考えられないアフォを訓練してあるレベルにまで持ってくる」
って意味じゃないの?

つーか、スレの方向と著しく違うのでこれで終了にするか、どこかよそでやってくれ。
0213デフォルトの名無しさんNGNG
正規化をきちんとやると、更新系と参照系を同時にやるようなシステム
では速度が出ない。理屈からして当たり前。

普通プログラムの応答速度を上げる為にキャッシュとなるバッファを取る
のと同様に、DB内部に冗長な部分をどのように作るかが、RDBMS技術者と
しての本領になると思う。
0214デフォルトの名無しさんNGNG
>>213
例を挙げて冗長にした方がいい場合を説明しないとただの独り善がりだぞ。
技術者の本領だの禅問答じみた話はいいからノウハウを語れ。
0215デフォルトの名無しさんNGNG
>>214
俺の言いたいこと言ってくれてありがとう。
途中から飲み屋のオヤジ会話になってる。
0216デフォルトの名無しさんNGNG
要は、レスポンスとDBの負荷が最小になるモデルを作って、そのモデルに
合うようにテーブル設計すれば良いだけ。
こっちの方が正道の設計。
「正規化」はDBの構造を知らない素人でも70点のモノが作れるようにする
為の手法であって、正道ではない。

うんと単純化したケースで言えば、
冗長の方がアクセス回数が1回で済む場合は冗長にした方が良い。
0217デフォルトの名無しさんNGNG
結合演算を伴うクエリーが頻繁に行われる時に、正規化されたテーブル
群に毎回結合演算を要求するのは無駄なことがあるでしょ。

例えば、そういうときにビュー作ったり、ビューでは都合が悪い時に
クエリーが高速に行えるような単純なテーブルを別に作っておいて、
更新をトリガーにしてそこに結合演算の結果を別途書き込んでおく、
なんていうのも、よくやるでしょ。
0218デフォルトの名無しさんNGNG
>>217
よくわからないんですが、それって正規化された設計を
基本として、ビューとか高速化用のテーブルとかを追加
するという「チューニング」をやってるわけですよね。
それともそういうのはチューニングじゃないのかなあ。
0219名無しさんNGNG
>>218
そういうのを前もって設計段階で考慮しておくってことじゃないの?

後で、「遅いからチューニングしよう」とかじゃなくて。
0220デフォルトの名無しさんNGNG
「チューニング」で出来るのは一部の手直しでしょ。
全体の設計を変えないまま、糞設計をいくら手直ししても無駄。
性能出す為には全体設計ってのが一番効く。
0221デフォルトの名無しさんNGNG
>>220
禿同。
正規化云々ってのも、すごく理解はできるし、そこにパワーをガッツリと割けるだけのリソースがあればいいけど、
そんな恵まれた環境やDB屋がいる現場って、そうそう無い。

それに、もう今は現実として、実装のスピードとパフォーマンスが、従来の開発手法だと
釣り合わなくなってきてるしね。
0222デフォルトの名無しさんNGNG
パフォーマンスの悪さに悩まされ、設計やSQLレベルのチューニングが行き着いたときに、
さらにそこから性能改善ができるかどうかが真のチューニング技術だと思うんだ。

基幹システムを莫大な額を投入して、運用を開始して、
業務規模が拡大するに伴って当初予定した業務量を逸脱するようになってくると
思わぬボトルネックがでてきて性能ががくんと落ちることがある。

そういう部分を予測、検出して、なるべく少ないコストで改善するって、大変なことだよ。

web objectsって、その辺、どうなんだろうね。

厨だからよくしらんわ。
0223デフォルトの名無しさんNGNG
WOにも欠点は多数あるけど・・・それを補ってお釣りが来ると思われ。

とりあえず、DBゴリゴリの更新系アプリ作っても、パフォーマンス的にはほとんど問題ないと
言い切っていいと思う。
WO自身は、リリースが95年あたり。他のどんなアプリ鯖よりも老舗といえるかな。
みんなDBアクセスする部分とビジネスロジック、UIとの接続などの部分のほとんどを
コーディングしてると思うけど、WOだといわゆる「当たり前」に実装してる部分、ほとんどを
フレームワークが提供してくれてるんで、効率いい。
WOの設計思想自体が、もはや開発者がゴリゴリSQL書くようなものを想定してない気がする。

アプ鯖が負荷上がってきてアップアップになったら、物理的な鯖と運用パッケージを買い足して、
作ったアプリにゃ手を加えずに運用ツール側で負荷分散先をしてやるだけ。

ともあれ、最近はSQL意識するような開発してないからなぁ、考え方ズレてるかも。。。
0224Disca ◆NAfP6znE NGNG
少し質問ですが、SQLなどで提供されているのデータベースは、
速度的に速いのでしょうか…。それとも、独自で探索木などを作ったほうが
高速になるのでしょうか…。
一応、データソース(リスト)が百万件あったと仮定します。
0225デフォルトの名無しさんNGNG
単一のプロセスでしか読み書きしないなら、
自前で書いた方が速くなる可能性は高い。

が、原子性の保証やバックアップ・リカバリの方法、
アクセス方法の標準化、ネットワーク対応、負荷分散、
複雑なクエリーやリレーションの解決など考えると
DBを使った方がお得だ。

ISAMの利用も検討してみるといい。
自分で作るより、おそらくそっちの方が早いし速い。
0226デフォルトの名無しさんNGNG
ISAMって何?
アゴ?
0227デフォルトの名無しさんNGNG
http://yougo.ascii24.com/gh/13/001361.html
0228Disca ◆NAfP6znE NGNG
>>225 >>226 >>227
レスありがとうございます。只今考えているのがマルチスレッドでの検索サーバなのですが、
(複数のスレッドで同時データファイル読み込み可能、書きこみは一スレッドのみ^^)

ISAM、始めて知りました。(無知にも気付かされました)
これって、NAMAZUのようなもの(インデックスサーチ)でしょうか…。
0229デフォルトの名無しさんNGNG
OPEN系でよく使われるのISAMがMySQLとかだね。
RDBじゃないけどSQL文が使える。
マルチスレッドにも対応、そこそこ速い。

NAMAZUは検索エンジン。
ISAM/RDBはDBのアクセス法に対する設計の違い。
0230デフォルトの名無しさんNGNG
全体設計でよく出会うケース。

1)本当に分散が必要か?
実は1台で間に合うものを、分散したが為に6台も必要になってしまったとか。

2)意味の有る分散か?
サーバーの負荷分散のための分散のはずが、情報まで分散してしまって、
それを再構成するのに分散した以上の負荷が生じているケース。

3)狂ったか?集中処理。
意味の無い分散を繰り返した後、「管理が楽だから」と一部機能を集中処理
してしまう。(そして破綻へ)
もうね、アフォか馬鹿かと・・・。
0231デフォルトの名無しさんNGNG
>>230
DBに限ったことじゃないね。システムのプロセスも、技術者の
オナニーで無駄に分散するのが流行ってる昨今。
0232デフォルトの名無しさんNGNG
>>231
今の流行なんだろうね。
Servletで十分なのをEJB使ってみたりとか。
おまえEJB使いたいだけちゃうんかと小一時間(以下略

同じようなことがOracleにもいえるがなー
>>230
分散をOracleにしても似たような感じ
0233デフォルトの名無しさんNGNG
>>232
>Servletで十分なのをEJB使ってみたりとか。
>おまえEJB使いたいだけちゃうんかと小一時間(以下略

JDBCで十分、つー表現が適切かと(w
揚げ足取りスマソ
0234デフォルトの名無しさんNGNG
>>230-233
偉そうなこと言いたいだけのガキはマ板逝け。邪魔。
0235デフォルトの名無しさんNGNG
234はオナニ勢力ですな
0236デフォルトの名無しさんNGNG
クライアントの話題ですが、.Netみたいにサーバカーソルを
忘れさすフレームワークってどうなんでしょうか?

個人的には大容量のデータ処理には向かないし、
クライアントキャッシュされたデータは
業務的にロックしないといけないし、
なーんかしっくりこないんですけども。
0237デフォルトの名無しさんNGNG
さすがMS。そんな危険な機能搭載とはね・・・。
.NETは厨が集まる事わかってんのかいな?
0238デフォルトの名無しさんNGNG
DBとはカンケーないんだけどさ、MSのUNIX捨てろキャンペーンが提供されてるサーバって
FreeBSDだったってな。
禿シクワラタ
0239デフォルトの名無しさんNGNG
>>236
新しい考え方が受け入れられないとCOBOLERみたくなっちゃうよ
ADO.NETはすばらしい
0240デフォルトの名無しさんNGNG
>>229
あ、あのー…
SQLが使えるのにRDBじゃないんでしょうか。いやマジレス希望。
0241デフォルトの名無しさんNGNG
実務では過去1年のデータがあれば十分なのに、
5〜6年分(日次単位)持っている会社があるんですが、
やっぱりこれってテーブルを分割したほうが良いんですよね?

「全部一度に見たい」っていうんでビューにしる! って言ったんですが
理由もなく却下されました。こんな企業はDQNですか? 辞めどき?
0242デフォルトの名無しさんNGNG
>>241
俺は同じ意味を持つデータは一つのテーブルにおいておくのが好み。
パフォーマンスに影響がでるならしょうがないけどさ。
そんな俺はDQNなんだろうか。
0243デフォルトの名無しさんNGNG
365(日)x5-6(年)x社員数でパフォーマンスに影響する会社って
1000人以上くらいですか?
0244デフォルトの名無しさんNGNG
>>243
マシンスペックが低い可能性も考慮せよ
0245デフォルトの名無しさんNGNG
>241
パフォーマンス、ディスク容量、バックアップ等の管理考えて問題
なければいいんじゃない。
oracleなら別表にしないで、パーティションにするけど。
オプションは高いが。
0246デフォルトの名無しさんNGNG
>>243
なんで社員数かけてんの?
勤怠かなんかのトランザクションなのか?

社員数少なくても業務によっては膨大なトランザクションデータを
日々発生させているんだよ。Web受注システムとかな。
0247デフォルトの名無しさんNGNG
ちょっと前の、設計か、チューンかの話しなんだけどさ。
設計が重要で、影響でかいのは決まってるけど、実際はチューンも必要に決まってるジャン。

多人数でやってりゃタコもいるしミスもあるし、遅くてもとりあえず動かす必要
があれば動かして、稼動後にチューンだよな。でなきゃ会社つぶれるしね。

設計よかったとしても、だいたい、ウォーターフォール開発の時代じゃ無し、設計要件が固定のまま
のはず無いし、いくらデータモデルが安定っていっても追加、変更はあるしね。

「私の辞書に、やってみなければ分からないという言葉はない」ってマジこのとうり
言ったコンサルもいるけど、結果は...。神様でもなきゃ完全に
見切れるわけない。世の中動いてんだから。

以上、設計いいかげんでいいという話ではない。が、スケジュールにチューン期間
を考えないのも、非現実的。
0248デフォルトの名無しさんNGNG
>>241
> 実務では過去1年のデータがあれば十分なのに、
これが本当ならば、5〜6年分持っておくこと自体がムダ。
使いもしないようなデータを後生大事に取っておく会社多いよね。

しかし全部見たいというニーズがある以上、そのデータになんらかの活用方法が
あるわけだから、分割などは避けるべき。
データは人間が使ってこそ意味がある。コンピュータよりの都合であまり不自然な
形にするべきじゃない。

だいたい>>241にしたってコッチから見れば
過去5〜6年分のデータを「分割しる!ビューで見れ!」理由もなくって言ってるんですが
こいつはDQNですか? 辞めさせどき?

だぞ。そもそもなんで分割したいんだ?
0249デフォルトの名無しさんNGNG
>>247
なんかもうツッコミ所満載なんで途中までレス書いてたけどヤメタ。
あくまでノウハウを語るスレだし。

もう1度コンサルに教えを請うた方がいい。
>「私の辞書に、やってみなければ分からないという言葉はない」
この意味が分かるようになるまでね。
0250デフォルトの名無しさんNGNG
>>246
キャッシュ可能容量の概算。
0251デフォルトの名無しさんNGNG
 PostgreSQLとPHP初心者です。「リレーションシップ」という
ものについて質問があります。

 リレーションシップの役割や概念は分かってきたのですが、
自分が、「売上テーブルと売上明細にはリレーションシップを
設定して」と頼まれた時、具体的に何と何をすればいいのか不安です。

 具体的な作業として、「リレーションシップを設定する」とは
どういう作業をさすのでしょうか?教えてください。

 簡単に売上テーブル(売上No)と売上明細テーブルをつくる
作業を仮定させて頂いたとして、
「リレーションシップを設定する」というのは下記の、どちらでしょうか?

1.具体的な命令句ではなく、売上明細テーブルの中に売上No(売上テーブル)を
  含めた、段階でリレーションシップが設定された、と判定される(設計段階?)。
2.PostgreSQLのCreate Tableの命令で具体的に参照整合性を
  設定をすることが、リレーションシップの設定である。

 たぶん、まだ理解が足らないかと思われますので、
上記の例に含まれていない場合、可能なら具体的な作業を
例示してご教授いただけないでしょうか?

 もし、この本に全部書いてあるよというような
参考書がございましたら、そちらをご紹介頂いても
結構です。よろしくお願い申し上げます。

 あと、ここではなく、他で聞け、という場合もご指摘ください。
0252デフォルトの名無しさんNGNG
>>251
こっちこっち
http://pc.2ch.net/test/read.cgi/tech/1001351439/
■ このスレッドは過去ログ倉庫に格納されています