設定は慎重に(^^;
えーっと、tcp/ipの基礎って知ってるかな？
その中でポートの設定でtcp/udpを利用することも大丈夫かな？
それでねservicesで10000/tcpとすべきところを10000/udpとしたら何が起こるかな？
あとね、ポートごとに帯域占有の優先順位をたてさせるときにudpとtcpを間違えて設定したら何が起こるかな？
……ま、人間誰しもミスをするものだし、本番稼働前に見つかって良かったよ。
でもなあ、ベンダーの設定ミスをユーザが発見して修正指示を出している現状ってどうなんだろう。
その中でポートの設定でtcp/udpを利用することも大丈夫かな？
それでねservicesで10000/tcpとすべきところを10000/udpとしたら何が起こるかな？
あとね、ポートごとに帯域占有の優先順位をたてさせるときにudpとtcpを間違えて設定したら何が起こるかな？
……ま、人間誰しもミスをするものだし、本番稼働前に見つかって良かったよ。
でもなあ、ベンダーの設定ミスをユーザが発見して修正指示を出している現状ってどうなんだろう。
informixのsp foreach使用上注意
自分用のメモです(^^;
Informix上のストアドプロシージャでforeachを使う場合
if exists(select * from ～) then
foreach select * from ～のようにexistsを予めかましとかないと、まれに予測不能なデータを拾ってしまうという（怖っ）
ので無駄なようだが同じSELECT文を２回発行するのがお作法とのこと。。
Informix上のストアドプロシージャでforeachを使う場合
if exists(select * from ～) then
foreach select * from ～のようにexistsを予めかましとかないと、まれに予測不能なデータを拾ってしまうという（怖っ）
ので無駄なようだが同じSELECT文を２回発行するのがお作法とのこと。。
うーん、確かにわかりやすいけど……
割合複雑なテーブル構造を持つと、正規化をしていく関係でどうしても一回の業務処理でいくつものテーブルを使用しなくてはならない。
それで普通はJOINを多用してさくっとデータを取得して対応するのが吉。
とりわけウェブシステムはレスポンスが課題となることが多いので、可能な限りSQLの発行回数は減らしてトランザクションがたくさんにならないようにしないと。
しかし中には「可読性」を重視しているのかどうか知らないが、一個一個真面目にSELECTしてデータを取得するというちょっち頭が痛めのプログラムを書いてきてくれるプログラマさんも居る。
まあおかげさまでソースを読むと、何をしているのかは一目瞭然ではあるのだが(^^;;;;
まあ今回のエントリーはそんなソースを眺めていて思った雑感ではあるわけで。
正規化されているテーブルを一個一個個別に読む、という上記のプログラマーさんはまあ問題外としても、いくつかの関連性が薄いテーブルから取得する情報を一画面で表現するときなどはちょっと悩むところもある。
またプログラムが部品化されすぎているがために、例えばそのパーツを20個埋めこむような画面がユーザーのパーソナライズによって発生した場合など、各部品が殆ど同等のSQLを部品個数だけ発行させてしまう、というようなこともあり得る。
イメージは次のような画面。
Ａ社
Code:1111
Tel:xxxx-xxx
Ｂ社
Code:1122
Tel:aaaa-zzz
Ｃ社
Code:1132
Tel:aaaa-ssss
Ｅ社
Code:1142
Tel:aaaa-2sss
で、この会社情報個数は可変で、ユーザーが一定の枠の範囲で自由にカスタマイズできる。というようなケース。
この部品がJavaScriptかなんかになっていて、
<script src="xxx.cgi?cd=1111">
<script src="xxx.cgi?cd=1122">
<script src="xxx.cgi?cd=1132">
<script src="xxx.cgi?cd=1142">
とかになっていたら、都合４回の殆ど同じようなSQLを結果として1画面で発行していることになる。
この画面であれば、ユーザーの定義ファイルをサブクエリかなんかにしてWhere 条件として、マスタファイルをselectするのがスマートだろう。
過去の実例で行くとけっこうシステム開発能力には定評のあるカブ・ドットコムなんかがこの問題点を抱えて、抜本的に見直して対応したという事例を日経オープンシステムかなにかで読んだ記憶がある。
株価等の情報を上場企業単位で呼び出せる部品があって、それを自由にユーザーが組み合わせられるような画面でこの問題が顕在化したようで、ソースレベルのレビュー等では気付かない可能性は確かに高そうだと思った記憶があり。
で、自分はどうしてるかって？
個人でつくるようなアプリだとそれほど真面目に正規化していないし、関連するテーブルも少ないので、割と気軽に個別にSQLを発行してたりするのが現実だとはとても恥ずかしくて言えない(笑)
2004/09/20補足:
知人から「でもJOIN多用すれば事実パフォーマンス落ちるじゃん」という指摘(^^;
うむ、確かに(^^;
DBの教科書でも一般的に正規化の問題点のひとつとしてあげられるよね。
また、「単純に程度の問題だけどもJOINをしまくるとあるところで急激にパフォーマンスが落ちるよ。DBMS性能依存だけど」という指摘も(^^; はい、そのとおりです。ごめんなさい。
あと、その時には書かなかったのだが「Webのプレゼンテーション層に近いレベルから個別にSQL発行するからダメなんじゃん。ストアドプロシージャとかにしてDBサーバサイドでやれば複雑なSQL発行しなくても通信のオーバーヘッドは無視できるんじゃないの？」というのはYES。
実際に、そういうポリシーで作成しているシステムもたくさんある。ただ、例示している内容だと別プロセスで個々の部品が起動する以上、通信のオーバヘッドだけでなくサーバサイドの処理プロセスも無用に多く発生しているというのは事実なわけで、これはいくらストアドプロシージャとか使っても解決しない。
それで普通はJOINを多用してさくっとデータを取得して対応するのが吉。
とりわけウェブシステムはレスポンスが課題となることが多いので、可能な限りSQLの発行回数は減らしてトランザクションがたくさんにならないようにしないと。
しかし中には「可読性」を重視しているのかどうか知らないが、一個一個真面目にSELECTしてデータを取得するというちょっち頭が痛めのプログラムを書いてきてくれるプログラマさんも居る。
まあおかげさまでソースを読むと、何をしているのかは一目瞭然ではあるのだが(^^;;;;
まあ今回のエントリーはそんなソースを眺めていて思った雑感ではあるわけで。
正規化されているテーブルを一個一個個別に読む、という上記のプログラマーさんはまあ問題外としても、いくつかの関連性が薄いテーブルから取得する情報を一画面で表現するときなどはちょっと悩むところもある。
またプログラムが部品化されすぎているがために、例えばそのパーツを20個埋めこむような画面がユーザーのパーソナライズによって発生した場合など、各部品が殆ど同等のSQLを部品個数だけ発行させてしまう、というようなこともあり得る。
イメージは次のような画面。
Ａ社
Code:1111
Tel:xxxx-xxx
Ｂ社
Code:1122
Tel:aaaa-zzz
Ｃ社
Code:1132
Tel:aaaa-ssss
Ｅ社
Code:1142
Tel:aaaa-2sss
で、この会社情報個数は可変で、ユーザーが一定の枠の範囲で自由にカスタマイズできる。というようなケース。
この部品がJavaScriptかなんかになっていて、
<script src="xxx.cgi?cd=1111">
<script src="xxx.cgi?cd=1122">
<script src="xxx.cgi?cd=1132">
<script src="xxx.cgi?cd=1142">
とかになっていたら、都合４回の殆ど同じようなSQLを結果として1画面で発行していることになる。
この画面であれば、ユーザーの定義ファイルをサブクエリかなんかにしてWhere 条件として、マスタファイルをselectするのがスマートだろう。
過去の実例で行くとけっこうシステム開発能力には定評のあるカブ・ドットコムなんかがこの問題点を抱えて、抜本的に見直して対応したという事例を日経オープンシステムかなにかで読んだ記憶がある。
株価等の情報を上場企業単位で呼び出せる部品があって、それを自由にユーザーが組み合わせられるような画面でこの問題が顕在化したようで、ソースレベルのレビュー等では気付かない可能性は確かに高そうだと思った記憶があり。
で、自分はどうしてるかって？
個人でつくるようなアプリだとそれほど真面目に正規化していないし、関連するテーブルも少ないので、割と気軽に個別にSQLを発行してたりするのが現実だとはとても恥ずかしくて言えない(笑)
2004/09/20補足:
知人から「でもJOIN多用すれば事実パフォーマンス落ちるじゃん」という指摘(^^;
うむ、確かに(^^;
DBの教科書でも一般的に正規化の問題点のひとつとしてあげられるよね。
また、「単純に程度の問題だけどもJOINをしまくるとあるところで急激にパフォーマンスが落ちるよ。DBMS性能依存だけど」という指摘も(^^; はい、そのとおりです。ごめんなさい。
あと、その時には書かなかったのだが「Webのプレゼンテーション層に近いレベルから個別にSQL発行するからダメなんじゃん。ストアドプロシージャとかにしてDBサーバサイドでやれば複雑なSQL発行しなくても通信のオーバーヘッドは無視できるんじゃないの？」というのはYES。
実際に、そういうポリシーで作成しているシステムもたくさんある。ただ、例示している内容だと別プロセスで個々の部品が起動する以上、通信のオーバヘッドだけでなくサーバサイドの処理プロセスも無用に多く発生しているというのは事実なわけで、これはいくらストアドプロシージャとか使っても解決しない。
技術が利用方法に追い越される時？
CNETの「マイクロソフト、増大するブログのトラフィックに苦慮」へのトラックバックを基調としたエントリー。
RSS = RDF Site Summary ということでサマリ情報がフィードされるというのが私の理解であったので、「全文フィードが当然。そうでなければ無価値」という価値観があることに思い至らなかった。RSSリーダーを普段使っていないから、こういうことを思いつかなかったんだろうなあ＞わし
人間が読むことをではなく、マシン・マシンインターフェイスを考えた規格だとすると、現在のRSSリーダーの普及というのはある種想定外の利用方法、ということになるのかもしれない。
しかし携帯電話のメール機能だって、あいさつ雑談のかわりに使われるようになるだとかは、当初は想定されていなかっただろうし、往々にして技術設定時の想定と食い違って普及するということはあるものだし、そういった普及の仕方をしたものが、本当の意味で根づくのかもしれない。
とはいうものの、ただでさえSPAMやらウィルスやらで逼迫しているインターネットトラフィックにとって、単なる文字情報でこれだけの帯域を食ってしまうというのは確かにある種異常かもしれない。
帯域の不安定さはビジネスアプリを作ってる立場からは勘弁願いたいところだし(^^;
そんな中、NDO:Weblogさんにて「mod_speedyfeed」というエントリを見かけた。
こっちはATOMの話ではあるが、atomフィードの差分配信機能をApacheサイドでコントロールするということで"クライアントにも回線にもサーバにも優しいモジュール"なのが面白い。
真に全文フィードが必要、というのがコモンセンスになるのなら、こうした試みはもっともっと試されていくことになるだろう。
RSS = RDF Site Summary ということでサマリ情報がフィードされるというのが私の理解であったので、「全文フィードが当然。そうでなければ無価値」という価値観があることに思い至らなかった。RSSリーダーを普段使っていないから、こういうことを思いつかなかったんだろうなあ＞わし
人間が読むことをではなく、マシン・マシンインターフェイスを考えた規格だとすると、現在のRSSリーダーの普及というのはある種想定外の利用方法、ということになるのかもしれない。
しかし携帯電話のメール機能だって、あいさつ雑談のかわりに使われるようになるだとかは、当初は想定されていなかっただろうし、往々にして技術設定時の想定と食い違って普及するということはあるものだし、そういった普及の仕方をしたものが、本当の意味で根づくのかもしれない。
とはいうものの、ただでさえSPAMやらウィルスやらで逼迫しているインターネットトラフィックにとって、単なる文字情報でこれだけの帯域を食ってしまうというのは確かにある種異常かもしれない。
帯域の不安定さはビジネスアプリを作ってる立場からは勘弁願いたいところだし(^^;
そんな中、NDO:Weblogさんにて「mod_speedyfeed」というエントリを見かけた。
こっちはATOMの話ではあるが、atomフィードの差分配信機能をApacheサイドでコントロールするということで"クライアントにも回線にもサーバにも優しいモジュール"なのが面白い。
真に全文フィードが必要、というのがコモンセンスになるのなら、こうした試みはもっともっと試されていくことになるだろう。
いまさらながらIMの威力
何をいまさら感があるものの、httpプロトコルによるIM（あえて製品名は書かない(^^;）の利用は、リモート開発時に大いに威力を発揮することを最近痛感している。
しょせん文字ベースのコミュニケーションツールとはいえ、電話よりも情報量があるうえに、お互いの必要な時間収奪が最小限で済むしなあ。
今までもLAN内完結のメッセージングツールを大いに活用して来たのだが、海外のお客様のところから開発部隊のある別の国および本社とつながるってのは一種感動的。
今まではネットワークインフラの関係でお客様のところにLAN参加してもインターネットアクセスできなかったので、時代は変わったとつくづく思う。
ウチの会社もツールを標準化して全体最適早くやらないかなあ・・・
しょせん文字ベースのコミュニケーションツールとはいえ、電話よりも情報量があるうえに、お互いの必要な時間収奪が最小限で済むしなあ。
今までもLAN内完結のメッセージングツールを大いに活用して来たのだが、海外のお客様のところから開発部隊のある別の国および本社とつながるってのは一種感動的。
今まではネットワークインフラの関係でお客様のところにLAN参加してもインターネットアクセスできなかったので、時代は変わったとつくづく思う。
ウチの会社もツールを標準化して全体最適早くやらないかなあ・・・