-
- いいね！0
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
ぜひ、こちら http://bit.ly/9wrdmq も、ご覧下さい。 QT @ryan5500: マーティンファウラーの記事読んでる．これすごいなー．ドメインモデルが一番わかりやすいけど，その一部を差し替えて複雑なSQLにするだけでこんなにパフォーマンスあがるのか．
2010-03-17 07:07:17
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
マーティンさんの http://bit.ly/12p9WO のパフォーマンスの差は私の経験則ではもっと大きな差になると思う。これ、多分、APとDBが同じマシンでやってるのじゃないかな。パフォーマンスの差はデータ量にもよるから何とも言えないけどね。
2010-03-17 08:09:26
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
DBへのアクセスをストアドプロシージャでというと、ビューではやっていたという人が多い。それってねAP側でWHERE句を再生成してるってことね。DB側にJOINまであって、AP側にWHERE句があるという歪な構成になる。でも一般的なんですね……。
2010-03-17 09:13:45
@rezev_hikaru
@Sikushima Ｓｅｒｖｅｒの異なるデータをＤＢのリンクＤＢ機能（ＯＤＢCベース）でＶＩＥＷとして設定される場合も同じＤＢテーブルのように使えますね。そうすると分散トランザクション処理が発生し、ＡＰ側から下手な更新処理やると大幅なパフォーマンスロスしますね。
2010-03-17 09:18:09
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
ここ http://bit.ly/9wrdmq にあるストアドプロシージャをみるとロジックをきっちりDB側に入れる意味が分かると思う。ストアドプロシージャが理解できないブラックボックスは嫌というのは、つまりできない人に合わせるということ。
2010-03-17 09:22:08
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
@rezev_hikaru DBリンクを挟んだVIEWは危険ですね。それは基本禁止事項かな。
2010-03-17 09:24:24
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
多分、必要があってビューで提供しているのでしょうが、少なくとも更新系はストアドプロシージャに一本化しないと危険すぎて使えないと思う。 QT @gutei:@Sikushima @rezev_hikaru テーブル名あたりの命名ルールでも設けて（例えば、接頭語でLT付けるとか）
2010-03-17 11:34:21
@rezev_hikaru
UIにWEBを使うケースも多々あり、ロール権限に関する情報を管理する仕組みは難しいですね。更新系処理はすべてストアド化し、生ＳＱＬ禁止くらいのほうが信頼性は上がると思います。 QT @Sikushima: なるほど、ロールを変えるのはありかも知れませんが、同じDBにリンクを2つ作
2010-03-17 12:41:12
@rezev_hikaru
ＤＢの階層で実行するストアドであってもリンク先テーブルの更新はご法度。分散トランザクションが発生します。レスポンスの良しあしというより分散トランザクションのない仕組みが必要という意味です。QT @gutei: リンク先とリンク元の双方のテーブルを使った更新では、ストアドしてもレ
2010-03-17 13:03:06
ぐて～
@gutei
既にDBリンクしてるシステムで追加な処理や仕様変更など、悩ましい問題になるでしょうね、実際。当初はｽｯｷﾘだったとしても、そもそもDBリンクと言う状況に内在する、分散トランザクションを発生させる可能性、と言うことを排除出来ないでしょうから。RT @rezev_hikaru: ＤＢ
2010-03-17 13:08:24
@rezev_hikaru
@gutei そうですね。そういう場合は早期にバッチ処理で実テーブルで必要データを持つ設計変更が必要だと思います。あるいはリアルタイム更新に必要なストアドとこれを使うＡＰＩ提供がカギになりますね。
2010-03-17 13:13:40
ぐて～
@gutei
@rezev_hikaru そういう提案がすんなり通って予算付いて発注してくれる状況だとありがたいんですがねぇ（笑）、概ね、予算の壁で設計変更なんて方法（提案）は承認されない方向に（笑）
2010-03-17 13:17:48
ぐて～
@gutei
@Ryuta_M 一般企業でも顧客数、購買履歴などが65000件程度じゃ済まないところは多いから、そいうところで分析的な処理をしようとする場合、UNIX環境が事務部門にあるとも思えず(^^;)、そいう場合は便利かなぁ～、と（笑）
2010-03-17 13:34:11
ぐて～
@gutei
@Ryuta_M Accessで100万件以上のレコードのあるテーブルや数十万件なテーブルを併せ持ったシステムを作ったことありますｗ、提案は、C/S-OKなDBエンジンだったんですが、ありがちな予算の関係ｗで却下。そのお客さんの持っていたAccess95で開発ｗｗｗ
2010-03-17 13:49:37
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
間違いを起こしやすいので、トランザクションではなく Transact SQL でSQLServerのストアドプロシージャ用の拡張言語です。 QT @ryan5500:ありがとうございます！トランザクションを使えばもっときれいに書けるんですね．
2010-03-17 14:12:45
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
SQLServerのよいところ。何と言っても簡単で楽。ストアドプロシージャの楽さは特筆モノ。でもBegin Endをいちいち書かないといけないのはちょっといただけない。2000のクエリーアナライザでできたステップ実行が2005でできなくなったのは何で？呆れる変更。
2010-03-17 16:51:50
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
SQLServerのよいところ。VSとの相性はそれはもうすこぶるよい。この組合せの開発になれると、他が馬鹿らしくなるぐらい楽。
2010-03-17 16:52:59
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
SQLServerの嫌なところ、楽な分凝ったことができない。TransactSQLのくどい文法（戻りの型を指定しないで結果セットを返せるのはよいのですが）ロック関連が甘い。
2010-03-17 16:55:04
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
Oracleのよいところ。単価が高く取れる（笑）ロックが硬い。とにかく細かい設定が自在にできる。
2010-03-17 16:56:39
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
Oracleの悪いところ、PL/SQLの型の宣言がくどい。パッケージの考え方はよいけれどくどい。とにかくくどい。めんどくさい。まぁ、エクセルなどでジェネレートするからイイけどね。ほんとくどいよね～。
2010-03-17 16:57:56
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
PostgreSQLのよいところ。マジで無料ですか？って腰を抜かしかけたほどよくできている。
2010-03-17 16:59:55
SQLの苦手を克服する本(技術評論社)/生島 勘富
@Sikushima
PostgreSQLの悪いところ、pgPL/SQLは余計なところでOracleを真似た感がある。まぁ、無料と思えば許せる。
2010-03-17 17:00:45