【ノウ】DBアプリ開発ノウハウ【ハウ】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG・似たようなSQLがあっちこっちのプログラムで出て来るんだけど…
・Viewとかストアドとか、みんながポンポン作っちゃって収拾付かないよ〜。
・分かりやすく長すぎないテーブル項目名のつけかたは?
・見やすい帳票レイアウトって? 入力しやすい画面遷移って?
などなど、悩むところはみんな一緒。
DBアプリ開発のノウハウを語るスレッドです。
0153デフォルトの名無しさん
NGNGテーブル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複数のテーブルを組み合わせるともっと極端になるね
0155デフォルトの名無しさん
NGNGそれぐらいならオプティマイザで勝手にしてくれない?
0156デフォルトの名無しさん
NGNGそっか・・・最近のはそうみたいだね
実装によっても違うし、一概にはなかなか難しいかな〜
0157デフォルトの名無しさん
NGNGそれを更にANDで括ってたりする奴もいた。
0158デフォルトの名無しさん
NGNGサンクス
逝ってきた。(というより、すでに逝っていた)
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おいらもしっかりWHARE句の最適化はやってるよ。
確かにオプティマイザが勝手にやってくれるDBが多いけど。
基本的に良い習慣だと思っている。
Cのif文は発生する確率が高い方からチェックするようにすれば高速化できるしね。
そういう地道な努力は高速化する上での重要な要素の1つとだと思う。
普段から注意していないと、なかなか身に付かないしね。
0160138
NGNGでは解説
RDBじゃインデックスを使うかどうかパフォーマンスに大きな影響が出るわけよ。
単純で簡単なことだけど、一番大事なことなわけ。
インデックスの基本理論からするとDBMSに依存する部分は少ないよ。
複合インデックスは順番に評価する
インデックス列に関数は使わない。
これは大原則です。
結合が多くなっても同じことが言えるわけで
分からないということはおそらくアクセスパスの解析をしたことが無いってことだろう。
まあ確かに端折りすぎた。
もっといい例きぼん。
>>159
良い習慣だと思う。
0161デフォルトの名無しさん
NGNGデータ量が少ないと主キーは別としても最近のRDBエンジンは
インデックスなんて使わないでしょ。
2値の列にハッシュインデックス貼ったりするのも激しく無意味だし。
やぱり最終的なチューニングは各DBのアクセスパス解析ツールを
使わないと、そのエンジンによっぽど精通してないと
人間の判断なんてあてにならないような気がするぞ。
0162デフォルトの名無しさん
NGNG最終的にはそらそーだ。
ただDBMS依存の最終的なチューニングによる効率UPよりも
非依存の基本的なチューニングの効率UPのほうがでかいって話では?
>2値の列にハッシュインデックス貼ったりするのも
これだって非依存だろ?
0163161
NGNG基本を押さえた上で、DBMS依存のチューニングをかけると。
ただ、インデックスのチューニングって結構むずかしいと個人的には思ってるのよ。
運用中に頻繁に更新があるならたくさんつくりゃいいってもんでもないし。
いろんな検索パターンがあるシステムだと、多数決とゆうか、重要度とか
人間的な判断で決めちゃったりして。>みんなはどーよ。
個人的に欲悩むのはJOINしたテーブル同士の検索条件は、
Where節で指定するか、JOINのONで指定するのがいいかって事かなー。
アクセスパス見るとまったく変わらなかったりするのだけれど。。。
0164デフォルトの名無しさん
NGNGSQL書く必要なかった。
(バックエンドで発行されてるSQLは見られる。)
1つのオブジェクトに、別々の鯖で動いてる別製品のRDBのテーブルをマップできるらしい。
なんか鬱。
0165デフォルトの名無しさん
NGNGふーん。すごそーだな。
これも会社に買わせようか・・・・
つかこのスレのせいで稟議書がふえてるな(w
Visioといい、ERWinといい、WebObjectといい・・・
0166デフォルトの名無しさん
NGNGWhere節で指定するか、JOINのONで指定するのがいいかって事かなー。
実際には同じ実行プランに落ちるはずなので、好みでいいんじゃない。
ノウハウというのもなんだけど、ある程度複雑なSQLを使うときは実行プランは
確認しようね。とんでもないプランで実行しているときがあるから。
0167デフォルトの名無しさん
NGNGそれを調べておけ。
で、まともなDBならインデックスが期待したとおりに使用されるかどうかの
実行プランがみれるから、それを使え。
オプティマイザにも色々種類や特性があって、少し柔軟にインデックスを
見に行ってくれるものや、明示的に統計情報を取得・更新しないと
まともな最適化をしてくれないものとかある。
SQLレベル以外にも、DBへのコネクション方法やテーブルレイアウトの設計、
インデックスの分散や隣接配置、テーブルスペースの配置、
ディスク装置の選択やRAIDの選択、使用メモリのチューニング、
ログの分散、管理、バックアップ・レプリケーション、
見るべきところはたくさんある。
一個だけつまんで見せて、「コレひどいよね」といっても、
木を見て森を見ず、の場合だって有るのだ。
0168デフォルトの名無しさん
NGNGタコSQLの被害低減ぐらいと思っている。
何より困るのは、開発、評価、実機で動作が変わるから。
また、アナライズもかけないで、オプティマイザを使っています
という、タコプロジェクトも見たことあるが、実データがない場合は
評価困難だしね。
個人的には重そうなsqlはかいたらすぐプランとって見るし、
少なくともチューンするときはヒントで、プランを
固定するようにしている。
Oracleもルールはなくして、コストベースにだけしますと
とずーと昔から言っているが、ずーとできそうになさそう。
ただ、コストベースでないと使えない機能があるので、
DB自体はコストベースにして、ヒント等で固定化してる。
知り合いのプロジェクトでは、外注に納品物件にプランの
提出を義務づけ、とりあえず(full)をチェックしてるみたい。
動的SQLはどーすんだと突っ込まれると思うが、量的には少ないし、
完全に読めないことはないので、インデックスあてといて、あとは
テスト、運用で発見個別対応になるね。なにより、できるやつに
その仕事をふること。
ただ、一度50人ぐらいのプロジェクトでは、動的SQLを作成する
ルーチンを書いて、表名、フィールド、条件とうの入力と、検索結果
をテーブル渡しにして、動的SQLの発行を一箇所でコントロールしたこと
もある。実際に発行されるSQLをログって監査する必要があったこともだが、
タコに動的SQL書かせて、後でデバッグ、チューンする恐怖より、
このルーチン作るほうを選んだ。
0169デフォルトの名無しさん
NGNGうちの会社なんでか使ってないんだよね。
テーブル設計書とかにはちゃんと初期値 = 0 とか、初期値 = システム日付 とか
書いてあるのに、デフォルト制約にしないで、入力プログラム(VB)で
発行するInsert文やUpdate文で明示的に 0 とかシステム日付セットしてる。
0とかの固定値はともかく、システム日付をVBで算出するとクライアントの
時計を使ってしまうので、困ると思うんだが…。
外部参照制約に関してもまったく設定してないんだよ。
仕様書には「商品マスタに該当レコードがあるかチェックする」とか書いてある。
外部参照制約作っといて、例外補足すればいいんじゃないの?
他の会社でもこんなもんなのか?
0170デフォルトの名無しさん
NGNGできればSQLなんて書かずに、ビジネスロジックの作り込みに専念すべきだ
そんな部分にパワーかけてどうする
0171デフォルトの名無しさん
NGNG性能で客から怒られたことのない素人が紛れ込んだ模様。
0172デフォルトの名無しさん
NGNGSQL作成とインデックスの追加申請くらいしかやらせてもらえない
駆け出しが紛れ込んだ模様。
0173デフォルトの名無しさん
NGNGなんだ、新卒ブビ厨?
SQLごときでパフォーマンスでないような作り方してんのか。まさにドキュソだね。
俺もWO使ってるけど、SQLなんか一度も書いたこと無いし、客から怒られたこともない。
元々金融系から始まって10年くれぇの実績のあるフレームワークと、
たいしたスキルも無い厨房が書くゴリゴリのSQLと、客はどちらを信用するのかねぇ(w
0174デフォルトの名無しさん
NGNGけっこう多いんだよね・・・
0175デフォルトの名無しさん
NGNG鼻高々としてるから可笑しいよね。運用上は必要だけど、DQN仕事だな。
俺はやりたくない。
DBを、単なるデータストアでなく、ソフトウェアコンポーネントの一つとして
見て欲しいんだがなあ。どうもデータが出たり入ったりするのを見て
エクスタシー感じてる連中が多いみたいだね、ここには。
0176デフォルトの名無しさん
NGNG0177デフォルトの名無しさん
NGNG0178デフォルトの名無しさん
NGNG0179デフォルトの名無しさん
NGNG同意。
外部参照制約のデメリットは、更新時のパフォーマンスなんだが、データが腐ることよりはずっとましと思う。
昔、あるシステムの改造をいらいされて、DBリバースしてみたところ、ただの表のあつまり。エクセルじゃないんだからってなかんじ。
案の定、データ腐りまくりで、開発より、データクリーング、移行のほうがはるかにコスト高。
ってことで、その案件はつぶれた。
デフォルト値は、場合によりけりだね。
追加開発で、新しいnotnullの属性を追加するときとかに、仕方なくデフォルト
入れることはあり。
0180デフォルトの名無しさん
NGNG金融やってたってひとで、自信あるやつ多いんだけどさ。
コンサルでは使いk物にならないこと多し。
金融の場合は、目的が明確なこともあると思うが、まったく
別種のビジネスでのコンサルに入ると分析能力無し。
技術てきにも、そのすばらしいフレームワークとやらのおかげで、
自分で一から構築したことがないんでまるで、提案できない。
0181デフォルトの名無しさん
NGNGでも、あまりWebObjectsは広まって欲しくない・・・
誰にも使わせたくないっていう感じ(藁
わかるだろ?この感覚。
0182デフォルトの名無しさん
NGNG日本語もまともに理解できないアフォドキュソですな(w
金融系やってた人間そのものの話しなんかだれがしてるんだよ。
WOの実績の例を出しただけだろ。
使い物にならないコンサルを、カバーするだけの力量がフレームワークにあるってことだ。
SQL以前に、小学校から国語をやりなおしてこい。
そもそも、一から構築したことのないヤツに、WOを使わせても無駄。
自前で実装した苦労や、他のツールで地獄を見た経験を持ったヤツだけが、その価値を理解できる。
0183デフォルトの名無しさん
NGNG広く使われるとボロが出るからな。
悪い評判が立つと客が嫌がるし。
0184デフォルトの名無しさん
NGNGうんそうだね。だから、君には必要なんだろう。
いつまでもSQLの作り込みに勤しんでくれたまえ。
自分で何もかも把握できた方が、効率よく作ることより重要だからな。
0185デフォルトの名無しさん
NGNG>だから、君には必要なんだろう。
は、
>だから、君には必要無いだろう。
に訂正。
0186デフォルトの名無しさん
NGNGうん。すごくわかる。
でも、広まってくれないとWebの案件をWebObjectsで提案しても蹴られる可能性あり。
0187デフォルトの名無しさん
NGNGこれが相反関係にあると言いたいのか?
すげーな。
0188デフォルトの名無しさん
NGNGまあ181はマカー根性丸出しってことで
sagesage
0189デフォルトの名無しさん
NGNGWebObjectsはWindows2000で開発してソラリスで運用するんだよ
0190デフォルトの名無しさん
NGNGつくづく厨房だな(w
お前、PGでもコーダーの部類だろ。
0191デフォルトの名無しさん
NGNG>>187
トレードオフという言葉を覚えましょう。
俺もそれらがトレードオフになるとは思わないけど(w
0193デフォルトの名無しさん
NGNG0194デフォルトの名無しさん
NGNG0195デフォルトの名無しさん
NGNG結局 【自慢話を語るスレでした】 って事だな
0196デフォルトの名無しさん
NGNGDBアプリを納品してからも仕様の変更・追加ってあるよね。
テーブル設計が変わっちゃったりした場合とか、被害を最小限にしたいよね。
そのためにやってることってある?
WebObjects、.NETなど、オブジェクトに自動マッピングされる環境では
仕様変更ってどうなるの?
0197デフォルトの名無しさん
NGNGDBが絡んだWebアプリでも、表示項目とUIが同時に変更になったとしても、
開発ツール上でデザイン変更できるし、DBとの接続もドラッグ&ドロップでほとんど完了。
他のJavaベースのツールみたいに、泣きながらゴリゴリ再コーディングっていう手間はあまり発生しないなぁ。
もちろん、純粋なビジネスロジックのコーディングし直しってのもあるけど、
かなりの部分がフレームワークが提供するメソッド利用するだけで目的が達せられるから
開発者としては、とても楽。
.NETって、どうなんだろうね?
0198デフォルトの名無しさん
NGNGありきたりだけど…
(1) Select項目は明示して * を使わない
(2) Insert項目も明示的に指定する
こうしておくと、仕様変更でテーブルにフィールドが追加されても
その追加フィールドにデフォルト制約を付けておけば、
既存のプログラム(参照、更新ともに)結構動くよ。
0199デフォルトの名無しさん
NGNG0200デフォルトの名無しさん
NGNGユーザーが使いやすいシステムを構築する上で
ストレスを感じさせないだけのパフォーマンスは必要
SQL云々もその一環だから使う側に立っていないとはいえないと思うよ
おっと、200ゲトー
0201デフォルトの名無しさん
NGNG確かにその観点はある意味間違っていない。
だが客にとっては、
SQLを直接書こうが書くまいが、WebObjectsだろうが、Javaだろうが.NETだろうが、
結果を出せるかと、最後まで責任をとれるか、が重要だと思う。
だいたいこの世界、欧米も含めてまだぜんぜんWebObjects一色ってわけじゃないでしょ?
WebObjectsがまだ知られていないというわけでもないだろうし。
欧米のメーリングリストなんかでもまだまだSQLネタって多いしね。
そこが現実ラインでしょ?
0202デフォルトの名無しさん
NGNG概ね同意だけど、ストレスを感じさせないだけのパフォーマンスを出せる実装を
できるだけのスキルのあるやつって、現場レベルでも最近少いような気がする。
パフォチューなんて思想無し。た〜だSQL書いてますみたいなやつ。
派遣や外注でやってくるヤツラで、「おお!こいつやるな!」みたいな人間にここ数年出会ってない。
なんていってるおれも、最近WebObjects始めた。
WinXPで開発、Linuxで運用。
なんつーか、目から鱗。
DB使うWebアプリが、ここまで効率化できるとは思ってなかったよ。
パフォーマンスも問題なし。
しかし、こんなツールが何故広まってないんだろうか。
アップル製だからかな?
Webオーサリングツールと勘違いされてるとかね(ワラ
0203デフォルトの名無しさん
NGNGWebObjectsは7万円だけど、他のツールは何百万ってするもんね。
そりゃ、高く売れるほうがいいよね。
0204デフォルトの名無しさん
NGNGバカじゃないの?
実装も意識して、かつユーザビリティも意識した開発するのが当たり前だろ。
それともお前の所ではそれがトレードオフになるのか?
>>1も
・見やすい帳票レイアウトって? 入力しやすい画面遷移って?
とスレの裾野が広がるような議題を持ってきているのにも関わらず、それを無視して
開発者よがりな話に持っていこうとしてるのはお前の方だろう。
0205デフォルトの名無しさん
NGNGおまえもわけわからん。。。。
0206デフォルトの名無しさん
NGNG同意。SQLしか意識していない技術オタは糞だが、
SQLを意識している技術者が、UIなどをないがしろにしているとは言えないからな。
>>205はもう一回読み直してみ?
とりあえず動くモノを作って次にチューニング、なんてのはSQL屋失格だし、
「正規化」とやらも初心者向けというか暗記型向けというか、
最適設計にはならない。
0208デフォルトの名無しさん
NGNGマジか。WebObjectやめた。
0209デフォルトの名無しさん
NGNG> 「チューニング」や「正規化」が変にもてはやされた
それが全てだとは言わないけど、それよりも大事なものって何なの?
一見するときれいな画面設計?
一見親切な操作方法?
画面設計や操作方法を考えるのももちろん大切だけど、
それよりも「システム」がしっかりしているが大事で、
しっかりした良いシステムを作るためには「正規化」が
大切だというのがいわば常識。
良いシステムを作るために「正規化」が
万能ではないという話ならばわかるけど、
207は良いシステムをつくるということを
考えていないように感じられる。システムが
ちゃんとしていないならば、本当の意味で
ユーザーにとって使いやすいアプリであるはずは
ない。
チューニングなんぞ「敵が城を囲んでから対応策を考えるようなもの」
正規化は「モノを考えられないアフォを訓練してあるレベルにまで持ってくる」
為の手法であって、マトモな設計者がやる事ではない。
0211209
NGNG全面的に同意。
> チューニングなんぞ「敵が城を囲んでから対応策を考えるようなもの」
確かに設計の段階でパフォーマンスも充分に意識すべき。
ただし神ならぬ人の身には、思いもかけず敵に城を囲まれる
こともあるし、その際には対応策を考えざるを得ない。
> 正規化は「モノを考えられないアフォを訓練してある
> レベルにまで持ってくる」為の手法であって、
> マトモな設計者がやる事ではない。
正規化よりまともな方法がわかるというのであれば、
設計者にしておくのはもったいない。世界的な研究者に
なれるんじゃないかな。現在のDB設計上、もっとも
マシな指針が正規化。それをまったく使わないのは
世界的研究者レベルの大天才か、ろくでもない設計者の
いずれかと思われる。
0212デフォルトの名無しさん
NGNGいや、正規化なんて誰に教えられるわけでもなく身に付くはずって事だろ。
手法と言うよりは理屈の話だしね。
それをわざわざ教えなければならないってのが
>「モノを考えられないアフォを訓練してあるレベルにまで持ってくる」
って意味じゃないの?
つーか、スレの方向と著しく違うのでこれで終了にするか、どこかよそでやってくれ。
0213デフォルトの名無しさん
NGNGでは速度が出ない。理屈からして当たり前。
普通プログラムの応答速度を上げる為にキャッシュとなるバッファを取る
のと同様に、DB内部に冗長な部分をどのように作るかが、RDBMS技術者と
しての本領になると思う。
0214デフォルトの名無しさん
NGNG例を挙げて冗長にした方がいい場合を説明しないとただの独り善がりだぞ。
技術者の本領だの禅問答じみた話はいいからノウハウを語れ。
0215デフォルトの名無しさん
NGNG俺の言いたいこと言ってくれてありがとう。
途中から飲み屋のオヤジ会話になってる。
0216デフォルトの名無しさん
NGNG合うようにテーブル設計すれば良いだけ。
こっちの方が正道の設計。
「正規化」はDBの構造を知らない素人でも70点のモノが作れるようにする
為の手法であって、正道ではない。
うんと単純化したケースで言えば、
冗長の方がアクセス回数が1回で済む場合は冗長にした方が良い。
0217デフォルトの名無しさん
NGNG群に毎回結合演算を要求するのは無駄なことがあるでしょ。
例えば、そういうときにビュー作ったり、ビューでは都合が悪い時に
クエリーが高速に行えるような単純なテーブルを別に作っておいて、
更新をトリガーにしてそこに結合演算の結果を別途書き込んでおく、
なんていうのも、よくやるでしょ。
0218デフォルトの名無しさん
NGNGよくわからないんですが、それって正規化された設計を
基本として、ビューとか高速化用のテーブルとかを追加
するという「チューニング」をやってるわけですよね。
それともそういうのはチューニングじゃないのかなあ。
0220デフォルトの名無しさん
NGNG全体の設計を変えないまま、糞設計をいくら手直ししても無駄。
性能出す為には全体設計ってのが一番効く。
0221デフォルトの名無しさん
NGNG禿同。
正規化云々ってのも、すごく理解はできるし、そこにパワーをガッツリと割けるだけのリソースがあればいいけど、
そんな恵まれた環境やDB屋がいる現場って、そうそう無い。
それに、もう今は現実として、実装のスピードとパフォーマンスが、従来の開発手法だと
釣り合わなくなってきてるしね。
0222デフォルトの名無しさん
NGNGさらにそこから性能改善ができるかどうかが真のチューニング技術だと思うんだ。
基幹システムを莫大な額を投入して、運用を開始して、
業務規模が拡大するに伴って当初予定した業務量を逸脱するようになってくると
思わぬボトルネックがでてきて性能ががくんと落ちることがある。
そういう部分を予測、検出して、なるべく少ないコストで改善するって、大変なことだよ。
web objectsって、その辺、どうなんだろうね。
厨だからよくしらんわ。
0223デフォルトの名無しさん
NGNGとりあえず、DBゴリゴリの更新系アプリ作っても、パフォーマンス的にはほとんど問題ないと
言い切っていいと思う。
WO自身は、リリースが95年あたり。他のどんなアプリ鯖よりも老舗といえるかな。
みんなDBアクセスする部分とビジネスロジック、UIとの接続などの部分のほとんどを
コーディングしてると思うけど、WOだといわゆる「当たり前」に実装してる部分、ほとんどを
フレームワークが提供してくれてるんで、効率いい。
WOの設計思想自体が、もはや開発者がゴリゴリSQL書くようなものを想定してない気がする。
アプ鯖が負荷上がってきてアップアップになったら、物理的な鯖と運用パッケージを買い足して、
作ったアプリにゃ手を加えずに運用ツール側で負荷分散先をしてやるだけ。
ともあれ、最近はSQL意識するような開発してないからなぁ、考え方ズレてるかも。。。
0224Disca ◆NAfP6znE
NGNG速度的に速いのでしょうか…。それとも、独自で探索木などを作ったほうが
高速になるのでしょうか…。
一応、データソース(リスト)が百万件あったと仮定します。
0225デフォルトの名無しさん
NGNG自前で書いた方が速くなる可能性は高い。
が、原子性の保証やバックアップ・リカバリの方法、
アクセス方法の標準化、ネットワーク対応、負荷分散、
複雑なクエリーやリレーションの解決など考えると
DBを使った方がお得だ。
ISAMの利用も検討してみるといい。
自分で作るより、おそらくそっちの方が早いし速い。
0226デフォルトの名無しさん
NGNGアゴ?
0228Disca ◆NAfP6znE
NGNGレスありがとうございます。只今考えているのがマルチスレッドでの検索サーバなのですが、
(複数のスレッドで同時データファイル読み込み可能、書きこみは一スレッドのみ^^)
ISAM、始めて知りました。(無知にも気付かされました)
これって、NAMAZUのようなもの(インデックスサーチ)でしょうか…。
0229デフォルトの名無しさん
NGNGRDBじゃないけどSQL文が使える。
マルチスレッドにも対応、そこそこ速い。
NAMAZUは検索エンジン。
ISAM/RDBはDBのアクセス法に対する設計の違い。
0230デフォルトの名無しさん
NGNG1)本当に分散が必要か?
実は1台で間に合うものを、分散したが為に6台も必要になってしまったとか。
2)意味の有る分散か?
サーバーの負荷分散のための分散のはずが、情報まで分散してしまって、
それを再構成するのに分散した以上の負荷が生じているケース。
3)狂ったか?集中処理。
意味の無い分散を繰り返した後、「管理が楽だから」と一部機能を集中処理
してしまう。(そして破綻へ)
もうね、アフォか馬鹿かと・・・。
0231デフォルトの名無しさん
NGNGDBに限ったことじゃないね。システムのプロセスも、技術者の
オナニーで無駄に分散するのが流行ってる昨今。
0232デフォルトの名無しさん
NGNG今の流行なんだろうね。
Servletで十分なのをEJB使ってみたりとか。
おまえEJB使いたいだけちゃうんかと小一時間(以下略
同じようなことがOracleにもいえるがなー
>>230
分散をOracleにしても似たような感じ
0233デフォルトの名無しさん
NGNG>Servletで十分なのをEJB使ってみたりとか。
>おまえEJB使いたいだけちゃうんかと小一時間(以下略
JDBCで十分、つー表現が適切かと(w
揚げ足取りスマソ
0234デフォルトの名無しさん
NGNG偉そうなこと言いたいだけのガキはマ板逝け。邪魔。
0235デフォルトの名無しさん
NGNG0236デフォルトの名無しさん
NGNG忘れさすフレームワークってどうなんでしょうか?
個人的には大容量のデータ処理には向かないし、
クライアントキャッシュされたデータは
業務的にロックしないといけないし、
なーんかしっくりこないんですけども。
0237デフォルトの名無しさん
NGNG.NETは厨が集まる事わかってんのかいな?
0238デフォルトの名無しさん
NGNGFreeBSDだったってな。
禿シクワラタ
0239デフォルトの名無しさん
NGNG新しい考え方が受け入れられないとCOBOLERみたくなっちゃうよ
ADO.NETはすばらしい
0240デフォルトの名無しさん
NGNGあ、あのー…
SQLが使えるのにRDBじゃないんでしょうか。いやマジレス希望。
0241デフォルトの名無しさん
NGNG5〜6年分(日次単位)持っている会社があるんですが、
やっぱりこれってテーブルを分割したほうが良いんですよね?
「全部一度に見たい」っていうんでビューにしる! って言ったんですが
理由もなく却下されました。こんな企業はDQNですか? 辞めどき?
0242デフォルトの名無しさん
NGNG俺は同じ意味を持つデータは一つのテーブルにおいておくのが好み。
パフォーマンスに影響がでるならしょうがないけどさ。
そんな俺はDQNなんだろうか。
0243デフォルトの名無しさん
NGNG1000人以上くらいですか?
0244デフォルトの名無しさん
NGNGマシンスペックが低い可能性も考慮せよ
0245デフォルトの名無しさん
NGNGパフォーマンス、ディスク容量、バックアップ等の管理考えて問題
なければいいんじゃない。
oracleなら別表にしないで、パーティションにするけど。
オプションは高いが。
0246デフォルトの名無しさん
NGNGなんで社員数かけてんの?
勤怠かなんかのトランザクションなのか?
社員数少なくても業務によっては膨大なトランザクションデータを
日々発生させているんだよ。Web受注システムとかな。
0247デフォルトの名無しさん
NGNG設計が重要で、影響でかいのは決まってるけど、実際はチューンも必要に決まってるジャン。
多人数でやってりゃタコもいるしミスもあるし、遅くてもとりあえず動かす必要
があれば動かして、稼動後にチューンだよな。でなきゃ会社つぶれるしね。
設計よかったとしても、だいたい、ウォーターフォール開発の時代じゃ無し、設計要件が固定のまま
のはず無いし、いくらデータモデルが安定っていっても追加、変更はあるしね。
「私の辞書に、やってみなければ分からないという言葉はない」ってマジこのとうり
言ったコンサルもいるけど、結果は...。神様でもなきゃ完全に
見切れるわけない。世の中動いてんだから。
以上、設計いいかげんでいいという話ではない。が、スケジュールにチューン期間
を考えないのも、非現実的。
0248デフォルトの名無しさん
NGNG> 実務では過去1年のデータがあれば十分なのに、
これが本当ならば、5〜6年分持っておくこと自体がムダ。
使いもしないようなデータを後生大事に取っておく会社多いよね。
しかし全部見たいというニーズがある以上、そのデータになんらかの活用方法が
あるわけだから、分割などは避けるべき。
データは人間が使ってこそ意味がある。コンピュータよりの都合であまり不自然な
形にするべきじゃない。
だいたい>>241にしたってコッチから見れば
過去5〜6年分のデータを「分割しる!ビューで見れ!」理由もなくって言ってるんですが
こいつはDQNですか? 辞めさせどき?
だぞ。そもそもなんで分割したいんだ?
0249デフォルトの名無しさん
NGNGなんかもうツッコミ所満載なんで途中までレス書いてたけどヤメタ。
あくまでノウハウを語るスレだし。
もう1度コンサルに教えを請うた方がいい。
>「私の辞書に、やってみなければ分からないという言葉はない」
この意味が分かるようになるまでね。
0250デフォルトの名無しさん
NGNGキャッシュ可能容量の概算。
0251デフォルトの名無しさん
NGNGものについて質問があります。
リレーションシップの役割や概念は分かってきたのですが、
自分が、「売上テーブルと売上明細にはリレーションシップを
設定して」と頼まれた時、具体的に何と何をすればいいのか不安です。
具体的な作業として、「リレーションシップを設定する」とは
どういう作業をさすのでしょうか?教えてください。
簡単に売上テーブル(売上No)と売上明細テーブルをつくる
作業を仮定させて頂いたとして、
「リレーションシップを設定する」というのは下記の、どちらでしょうか?
1.具体的な命令句ではなく、売上明細テーブルの中に売上No(売上テーブル)を
含めた、段階でリレーションシップが設定された、と判定される(設計段階?)。
2.PostgreSQLのCreate Tableの命令で具体的に参照整合性を
設定をすることが、リレーションシップの設定である。
たぶん、まだ理解が足らないかと思われますので、
上記の例に含まれていない場合、可能なら具体的な作業を
例示してご教授いただけないでしょうか?
もし、この本に全部書いてあるよというような
参考書がございましたら、そちらをご紹介頂いても
結構です。よろしくお願い申し上げます。
あと、ここではなく、他で聞け、という場合もご指摘ください。
0252デフォルトの名無しさん
NGNGこっちこっち
http://pc.2ch.net/test/read.cgi/tech/1001351439/
■ このスレッドは過去ログ倉庫に格納されています