Blog
2004/09/14のBlog
[ 23:44 ]
[ ├■会社にて… ]
...2004/09/14 23:50
システムの開発スパンの終了予定間際、時間がないので、仕事をおうちに持って帰ってきています。
仕事の内容は、テストシナリオの作成。
テストシナリオというのは、システムのテストをやるための指示書のようなもので、どういうタイミングでどういう値を使ってどういう反応があるかをチェックし、それが正しい反応なのかどうかを判断するためのモトネタ帳です。
終了目標は本日27:00まで！
さて、がんばるぞ。(泣)
...2004/09/14 24:30
うう、こんな細かい仕事はキライだー。(泣)
一桁ずれているやんかー！だから固定長フォーマットのファイルなんかキライなんだー！
…と、早くも泣言いっております。
ちなみに、固定長フォーマットというのは、1つのまとまったデータを何の区切り文字もない状態で1行表示する形式です。
区切り文字がないので、m桁目～ｎ桁目がこういう種類のデータですよという指定の仕方をしています。
CAMUSは根性なしなので、すぐ桁がずれます。(涙)
...2004/09/14 25:30
うーん、データのパターンが多すぎるよぅ。(涙)
パターンの網羅ができていないと、バグがつぶせたかどうかの判断ができないではにゃいですか。
後1時間半でできるのか？！
泣言続行中です。しくしく。
ちなみに、｢バグ｣の語源は、昔のコンピュータシステムではデータやプログラムの入力や出力をHDDではなく、紙テープとか紙カードに出していたんですが、そいつが「虫」に食われるとデータやプログラムが誤動作するので、そっから名づけられたそーです。
…とか書いたら、k.tanabeさまから、真空管でねーの？とツッコミを受けました。(爆)
CAMUS、かなりラリっています。
...2004/09/14 25:50
うわーん、ついに電卓登場デス。
そろばん3級なのに、ちょっと屈辱。頭が朦朧としてきたから、しゃーないと割り切るのだ。実際、計算ミス連発中です。
それにしても、旦那が帰ってこないぞ。
...2004/09/14 26:30
あと、さんじゅっぷんじゃ、でっきませ～ん。
でも、できるところまではがむばる。
...2004/09/14 26:40
1カテゴリ丸ごとミス発見。(大泣)
修正してやる！(By カミーユ at Zガンダム)
...2004/09/14 27:20
対応完了済みのファイルを間違って修正してしまいました。(滝涙)
バックアップから拾うべし…よかった、バックアップとっといて。
...2004/09/14 27:55
ああ、新聞屋さん、ご苦労様…。
細かい作業ができなくなってしまいました。
大枠だけ作ってしまうことにします。(泣)
...2004/09/14 28:15
うっしゃー！残るテストパターンはあとふたぁつー！！
って、残り物のテストパターンの資料もって帰ってくるの忘れてるしっ！！！(爆)
…もう寝るしかないな…。
2時間ほどだけど…寝ます。おやすみなさい。
(完)
システムの開発スパンの終了予定間際、時間がないので、仕事をおうちに持って帰ってきています。
仕事の内容は、テストシナリオの作成。
テストシナリオというのは、システムのテストをやるための指示書のようなもので、どういうタイミングでどういう値を使ってどういう反応があるかをチェックし、それが正しい反応なのかどうかを判断するためのモトネタ帳です。
終了目標は本日27:00まで！
さて、がんばるぞ。(泣)
...2004/09/14 24:30
うう、こんな細かい仕事はキライだー。(泣)
一桁ずれているやんかー！だから固定長フォーマットのファイルなんかキライなんだー！
…と、早くも泣言いっております。
ちなみに、固定長フォーマットというのは、1つのまとまったデータを何の区切り文字もない状態で1行表示する形式です。
区切り文字がないので、m桁目～ｎ桁目がこういう種類のデータですよという指定の仕方をしています。
CAMUSは根性なしなので、すぐ桁がずれます。(涙)
...2004/09/14 25:30
うーん、データのパターンが多すぎるよぅ。(涙)
パターンの網羅ができていないと、バグがつぶせたかどうかの判断ができないではにゃいですか。
後1時間半でできるのか？！
泣言続行中です。しくしく。
ちなみに、｢バグ｣の語源は、昔のコンピュータシステムではデータやプログラムの入力や出力をHDDではなく、紙テープとか紙カードに出していたんですが、そいつが「虫」に食われるとデータやプログラムが誤動作するので、そっから名づけられたそーです。
…とか書いたら、k.tanabeさまから、真空管でねーの？とツッコミを受けました。(爆)
CAMUS、かなりラリっています。
...2004/09/14 25:50
うわーん、ついに電卓登場デス。
そろばん3級なのに、ちょっと屈辱。頭が朦朧としてきたから、しゃーないと割り切るのだ。実際、計算ミス連発中です。
それにしても、旦那が帰ってこないぞ。
...2004/09/14 26:30
あと、さんじゅっぷんじゃ、でっきませ～ん。
でも、できるところまではがむばる。
...2004/09/14 26:40
1カテゴリ丸ごとミス発見。(大泣)
修正してやる！(By カミーユ at Zガンダム)
...2004/09/14 27:20
対応完了済みのファイルを間違って修正してしまいました。(滝涙)
バックアップから拾うべし…よかった、バックアップとっといて。
...2004/09/14 27:55
ああ、新聞屋さん、ご苦労様…。
細かい作業ができなくなってしまいました。
大枠だけ作ってしまうことにします。(泣)
...2004/09/14 28:15
うっしゃー！残るテストパターンはあとふたぁつー！！
って、残り物のテストパターンの資料もって帰ってくるの忘れてるしっ！！！(爆)
…もう寝るしかないな…。
2時間ほどだけど…寝ます。おやすみなさい。
(完)
[ 09:57 ]
[ ├■前略 Doblogさま ]
9月7日に
TB：ユーザーに出来ること ～Doblogサーバの負荷を軽くしてあげよう～
というexkydeさまのトラックバック記事を書き、一部メニューの非表示や、表示記事数の削減をして、微々たる物ではあるのは承知の上でDoblogサーバの負荷を軽くしようという行動を起こすことを宣言しました。
その後、Doblogのメンテナンス情報を得て、このような記事を書きました。
09/13はDoblogサーバ大増強(予定)の日 ～塵も積もれば運動は解除できるのか？～
ここで、先のDoblogサーバの負荷を軽減する運動…塵も積もれば運動を、メンテナンスの後、解除することを宣言しました。
というわけで、一部メニューを復活、表示記事数を10件に増やしました。
しかし、Doblogサーバのメンテナンスは失敗に終わったとのことです。
Doblogスタッフによる関連記事はこちら。
リリース延期とシステムの再稼動に関するお知らせ
また重くなるようでしたら、この運動をする可能性があるかもしれませんが、一旦宣言どおり、塵も積もれば運動を解除したいと思います。
このBlogをご覧になってらっしゃる皆様には不便を強いてしまいました。お詫びいたします
閲覧者の皆様、そしてこの運動に賛同してくださった方も、ご協力ありがとうございました。(_o_)
…とりあえず…Doblogスタッフさま、ご苦労様でした。
トラブルが起こっても元戻しがきちんと出来ているようですし、本番稼動については『急いてはコトを仕損じる』と思いますので、コレでよかったのでは、と思います。
…メニューや表示記事を増やして一言。
改めて、自分のBlogが重いっ！
TB：ユーザーに出来ること ～Doblogサーバの負荷を軽くしてあげよう～
というexkydeさまのトラックバック記事を書き、一部メニューの非表示や、表示記事数の削減をして、微々たる物ではあるのは承知の上でDoblogサーバの負荷を軽くしようという行動を起こすことを宣言しました。
その後、Doblogのメンテナンス情報を得て、このような記事を書きました。
09/13はDoblogサーバ大増強(予定)の日 ～塵も積もれば運動は解除できるのか？～
ここで、先のDoblogサーバの負荷を軽減する運動…塵も積もれば運動を、メンテナンスの後、解除することを宣言しました。
というわけで、一部メニューを復活、表示記事数を10件に増やしました。
しかし、Doblogサーバのメンテナンスは失敗に終わったとのことです。
Doblogスタッフによる関連記事はこちら。
リリース延期とシステムの再稼動に関するお知らせ
また重くなるようでしたら、この運動をする可能性があるかもしれませんが、一旦宣言どおり、塵も積もれば運動を解除したいと思います。
このBlogをご覧になってらっしゃる皆様には不便を強いてしまいました。お詫びいたします
閲覧者の皆様、そしてこの運動に賛同してくださった方も、ご協力ありがとうございました。(_o_)
…とりあえず…Doblogスタッフさま、ご苦労様でした。
トラブルが起こっても元戻しがきちんと出来ているようですし、本番稼動については『急いてはコトを仕損じる』と思いますので、コレでよかったのでは、と思います。
…メニューや表示記事を増やして一言。
改めて、自分のBlogが重いっ！
2004/09/11のBlog
[ 10:48 ]
[ ├■前略 Doblogさま ]
Doblogサーバのお仕事を減らしてあげよう！
Doblogユーザでも出来ることをやっていこう！
ということで、「CAMUSのこくばん」では
・記事の表示件数の削減
・メニュー表示項目の削減
運動を行っております。効果のほどは微々たるものでしょうが、塵も積もれば効果で幾分かDoblogサーバが軽くなることを願っております。
この件の具体的な内容は「TB：ユーザーに出来ること ～Doblogサーバの負荷を軽くしてあげよう～」やその記事にあるリンク、またはトラックバック先の記事をお読みくださいませ。
で、本題です。
CAMUSはとりあえずこの運動を 2004/9/13 までこの表示状態のままの状態を維持して続けようと考えております。
2004/09/13 には何があるか、というと、Doblogのトップページからたどれるお知らせにこう書いてあります。
以下、勝手にそのまま引用です。
9/13(月)以下の時間帯におきまして、データベースサーバー増強に伴う、サーバーメンテナンスを実施いたします。
・作業予定時間 ： 9月13日(月) 9:00 - 21:00（予定）
メンテナンス中はBlogの閲覧・書き込み・修正が出来なくなります。
長時間に亘るメンテナンスに伴い、ユーザの皆様には大変ご迷惑をお掛け致しますが、ご理解、ご協力のほどよろしくお願いいたします。
CAMUSはこのときを節目にして、上記で行っていた「塵も積もれば」運動を一旦解除しようと思います。
CAMUSのこくばんにお越しくださる皆様方には、
9/13のDoblogサーバ大増強が終了するまで、ご不便をおかけしますが、
ご理解のほど、よろしくお願いいたします。
運動に参加されている皆様、解除が出来るだけの環境になっているといいですね。
追記) お知らせを見ると、何と、サーバメンテナンス後、そのまま本番稼動するような気配が…
DoblogスタッフBlogに記事が上がりましたので、トラックバックいたします。
[ 2004/09/10 ] システム増設・分散化と正式版サービスの実施のお知らせ
以上、TB：ユーザーに出来ること ～Doblogサーバの負荷を軽くしてあげよう～のセルフトラックバックでした。
Doblogユーザでも出来ることをやっていこう！
ということで、「CAMUSのこくばん」では
・記事の表示件数の削減
・メニュー表示項目の削減
運動を行っております。効果のほどは微々たるものでしょうが、塵も積もれば効果で幾分かDoblogサーバが軽くなることを願っております。
この件の具体的な内容は「TB：ユーザーに出来ること ～Doblogサーバの負荷を軽くしてあげよう～」やその記事にあるリンク、またはトラックバック先の記事をお読みくださいませ。
で、本題です。
CAMUSはとりあえずこの運動を 2004/9/13 までこの表示状態のままの状態を維持して続けようと考えております。
2004/09/13 には何があるか、というと、Doblogのトップページからたどれるお知らせにこう書いてあります。
以下、勝手にそのまま引用です。
9/13(月)以下の時間帯におきまして、データベースサーバー増強に伴う、サーバーメンテナンスを実施いたします。
・作業予定時間 ： 9月13日(月) 9:00 - 21:00（予定）
メンテナンス中はBlogの閲覧・書き込み・修正が出来なくなります。
長時間に亘るメンテナンスに伴い、ユーザの皆様には大変ご迷惑をお掛け致しますが、ご理解、ご協力のほどよろしくお願いいたします。
CAMUSはこのときを節目にして、上記で行っていた「塵も積もれば」運動を一旦解除しようと思います。
CAMUSのこくばんにお越しくださる皆様方には、
9/13のDoblogサーバ大増強が終了するまで、ご不便をおかけしますが、
ご理解のほど、よろしくお願いいたします。
運動に参加されている皆様、解除が出来るだけの環境になっているといいですね。
追記) お知らせを見ると、何と、サーバメンテナンス後、そのまま本番稼動するような気配が…
DoblogスタッフBlogに記事が上がりましたので、トラックバックいたします。
[ 2004/09/10 ] システム増設・分散化と正式版サービスの実施のお知らせ
以上、TB：ユーザーに出来ること ～Doblogサーバの負荷を軽くしてあげよう～のセルフトラックバックでした。
[ 00:56 ]
[ ├■RSS含むXML関連 ]
;)
突貫工事でRSS0.91から、自分のBlogのタイトル一覧リンク集を作れるスタイルシートを作ってみました。
スタイルシートといってもCSSのことではありません。
RSSはXMLというHTMLとちょっと似た形式のファイル形式になっていて、XSLというスタイルシートを作成してやることで、それを自分の好きなように加工することができるようになるんです。
XMLやXSLのことについて詳しく知りたい方は
たのしいXML
等のサイトで学習されるといいと思います。というわけで、ここの解説は割愛しますね。
どんな一覧になるかというと、こちらの画像をご覧くださいませ。
ヒジョーに殺風景ですね。(^^;)
まぁ、突貫工事で作ったなので、こんなもんでお許しを。(_o_)
では、お膳立てはこのぐらいにして、実際どうするとよいのかを説明します。
1) RSS0.91のファイルをGetしよう
まず、自分のBlogの一覧を作るネタを仕入れないといけません。
仕入れるための参考になるのは、こちらの記事でしょうか。(この記事のリンク先も参考になさってください)
RSSを使ってDoblogの全記事をGetする方法 ～文章だけでもバックアップ～
この記事を参考にして、RSS0.91をゲットしてみましょう。CAMUSの場合だとこんなURLを実行します。
http://www.doblog.com/weblog/RSSServlet?CMD=ALL&userid=7562&TYPE=RSS_0_91
useridのあとの番号をご自身のBlogナンバーに変えてやると、ご自身のURLになります。
このURLを実行すると、Webブラウザによってはツリー構造のデータに見えたり、なにやら文字がぐしゃーっと固まって見えたりすると思います。
どういう形式になろうと気にせず、そのままWebブラウザの機能で「ファイル保存」してしまってください。
ちなみに、ログインした状態でRSSをゲットすると、下書き中の記事もGetできます。
ログアウト状態ですと下書き状態の記事はGetできません。
差分をとってどれが下書きかをチェックするために、両方をとってみてもいいと思いますよ。
2) XMLとXSLからHTMLを作ってくれるツールをGetしよう
1で得たRSSファイルはXMLというファイル形式になっています。
それをXSLというスタイルシートで加工して、HTML形式にしてくれるツールを窓の杜やVectorなどでゲットしてきましょう。
例えば、こんなツールがあります。
XtoH - XSL Translate Tool Windows用です。
Macはゴメンナサイ。チトわからないデス…。
コイツをインストールしちゃってくださいませ。
3) XSLをファイル化してGetしよう
さて、問題のXSLですが、ここからダウンロードしてください。
ブラウザによってはツリー表示になったり、ぐしゃっとなったりしていますが、そのままブラウザの機能の「ファイル保存」を使って保存しましょう。
4) RSSとXSLからHTMLを作ろう
2)のソフトを起動し、1のファイルをXML、3のファイルをXSLとして、変換かけてみましょう。
出来上がったHTMLファイルは、上記の画像のような感じで見えると思います。
もし、2のソフトが使えない、と仰る方のうち、XML対応のWebブラウザ(IE6とかNC7とか)をお持ちの方は1のファイルの2行目にこんな行を追加してみてください。
<?xml-stylesheet type="text/html" href="3のファイル名"?>
その上で、XMLファイルをブラウザで見てみると同じ画面が見れると思います。
とりあえず、ここまで…。
この記事も、突貫なので、「この部分がワカンネー！｣とかツッコミ、補足等、ありましたらコメントまで、よろしくお願いしまーす！
【追記 2005/03/11】
XSLファイル置き場のURLが変更になっていたので、修正しました。
Yahooブリーフケースもしょっちゅうチェックしておかなくてはダメね…。orz
どぶさぽちゃん、タレコミありがとうです。(_o_)
【追記 2005/03/28】
XSLファイル置き場、Yahooブリーフケースから、ime.jpに変更です。
よって、リンクも変更です。
【追記 2006/02/24】
XSLファイル置き場、1me閉鎖につき、Yahooブリーフケースに変更です。
スタイルシートといってもCSSのことではありません。
RSSはXMLというHTMLとちょっと似た形式のファイル形式になっていて、XSLというスタイルシートを作成してやることで、それを自分の好きなように加工することができるようになるんです。
XMLやXSLのことについて詳しく知りたい方は
たのしいXML
等のサイトで学習されるといいと思います。というわけで、ここの解説は割愛しますね。
どんな一覧になるかというと、こちらの画像をご覧くださいませ。
ヒジョーに殺風景ですね。(^^;)
まぁ、突貫工事で作ったなので、こんなもんでお許しを。(_o_)
では、お膳立てはこのぐらいにして、実際どうするとよいのかを説明します。
1) RSS0.91のファイルをGetしよう
まず、自分のBlogの一覧を作るネタを仕入れないといけません。
仕入れるための参考になるのは、こちらの記事でしょうか。(この記事のリンク先も参考になさってください)
RSSを使ってDoblogの全記事をGetする方法 ～文章だけでもバックアップ～
この記事を参考にして、RSS0.91をゲットしてみましょう。CAMUSの場合だとこんなURLを実行します。
http://www.doblog.com/weblog/RSSServlet?CMD=ALL&userid=7562&TYPE=RSS_0_91
useridのあとの番号をご自身のBlogナンバーに変えてやると、ご自身のURLになります。
このURLを実行すると、Webブラウザによってはツリー構造のデータに見えたり、なにやら文字がぐしゃーっと固まって見えたりすると思います。
どういう形式になろうと気にせず、そのままWebブラウザの機能で「ファイル保存」してしまってください。
ちなみに、ログインした状態でRSSをゲットすると、下書き中の記事もGetできます。
ログアウト状態ですと下書き状態の記事はGetできません。
差分をとってどれが下書きかをチェックするために、両方をとってみてもいいと思いますよ。
2) XMLとXSLからHTMLを作ってくれるツールをGetしよう
1で得たRSSファイルはXMLというファイル形式になっています。
それをXSLというスタイルシートで加工して、HTML形式にしてくれるツールを窓の杜やVectorなどでゲットしてきましょう。
例えば、こんなツールがあります。
XtoH - XSL Translate Tool Windows用です。
Macはゴメンナサイ。チトわからないデス…。
コイツをインストールしちゃってくださいませ。
3) XSLをファイル化してGetしよう
さて、問題のXSLですが、ここからダウンロードしてください。
ブラウザによってはツリー表示になったり、ぐしゃっとなったりしていますが、そのままブラウザの機能の「ファイル保存」を使って保存しましょう。
4) RSSとXSLからHTMLを作ろう
2)のソフトを起動し、1のファイルをXML、3のファイルをXSLとして、変換かけてみましょう。
出来上がったHTMLファイルは、上記の画像のような感じで見えると思います。
もし、2のソフトが使えない、と仰る方のうち、XML対応のWebブラウザ(IE6とかNC7とか)をお持ちの方は1のファイルの2行目にこんな行を追加してみてください。
<?xml-stylesheet type="text/html" href="3のファイル名"?>
その上で、XMLファイルをブラウザで見てみると同じ画面が見れると思います。
とりあえず、ここまで…。
この記事も、突貫なので、「この部分がワカンネー！｣とかツッコミ、補足等、ありましたらコメントまで、よろしくお願いしまーす！
【追記 2005/03/11】
XSLファイル置き場のURLが変更になっていたので、修正しました。
Yahooブリーフケースもしょっちゅうチェックしておかなくてはダメね…。orz
どぶさぽちゃん、タレコミありがとうです。(_o_)
【追記 2005/03/28】
XSLファイル置き場、Yahooブリーフケースから、ime.jpに変更です。
よって、リンクも変更です。
【追記 2006/02/24】
XSLファイル置き場、1me閉鎖につき、Yahooブリーフケースに変更です。
2004/09/10のBlog
[ 11:32 ]
[ ├■Doblogger企画！ ]
;)
Doblogは毎月どの程度のお金を支払えるサービスか？
について語ってみてくれと、k.tanabeさまが仰せです。
とりあえず、値段だけつけてみます。
1) Doblogの現在の機能を維持 トータル \400
内訳：容量無制限 に \300
RSS/ATOM配布、スライドショウ、カレンダー表示など、表示系オプション に \0
ブックマークされたBlogの新着メール配信 に \100
2) Doblog高速化 \200
3) 今はない機能だがあればこれぐらいかな？ トータル \300
内訳：アクセス解析 に \200
バックアップアーカイブ作成 に \100
このうちどれが欲しいかというと、メール配信以外は欲しいので、\800かな？
あ、カード払いでよろしく。(笑)
最後に。
…せっかくの画像がCAMUSのスタイルシートになじまないよう…。(T_T)
以上、もやじ殿(笑)のお記になったお題：Doblogに毎月いくら払える？のトラックバックでした。
トラック、バックオーライ！もあわせてお読みくださいませ。
について語ってみてくれと、k.tanabeさまが仰せです。
とりあえず、値段だけつけてみます。
1) Doblogの現在の機能を維持 トータル \400
内訳：容量無制限 に \300
RSS/ATOM配布、スライドショウ、カレンダー表示など、表示系オプション に \0
ブックマークされたBlogの新着メール配信 に \100
2) Doblog高速化 \200
3) 今はない機能だがあればこれぐらいかな？ トータル \300
内訳：アクセス解析 に \200
バックアップアーカイブ作成 に \100
このうちどれが欲しいかというと、メール配信以外は欲しいので、\800かな？
あ、カード払いでよろしく。(笑)
最後に。
…せっかくの画像がCAMUSのスタイルシートになじまないよう…。(T_T)
以上、もやじ殿(笑)のお記になったお題：Doblogに毎月いくら払える？のトラックバックでした。
トラック、バックオーライ！もあわせてお読みくださいませ。
2004/09/09のBlog
[ 13:20 ]
[ ├■Doblogger企画！ ]
あなたのBlogナンバーのカラオケ曲はなぁに？ By 渦さま
というわけで、CAMUSのBlogナンバー7562のカラオケ曲が何かを探ってみました。
セガカラ 楽曲検索
結果
→ウィーアー！(ワンピース) / きただにひろし
♪ありったけのゆーめをーかきあつめー♪でしたっけ。
アニメ ワンピースの初代主題歌ですね。歌詞読みながらだったら歌えますがな…。(笑)
以上、渦姫様のお記になった【Tバック企画】ブログナンバーのカラオケ曲からのトラックバックでした。
というわけで、CAMUSのBlogナンバー7562のカラオケ曲が何かを探ってみました。
セガカラ 楽曲検索
結果
→ウィーアー！(ワンピース) / きただにひろし
♪ありったけのゆーめをーかきあつめー♪でしたっけ。
アニメ ワンピースの初代主題歌ですね。歌詞読みながらだったら歌えますがな…。(笑)
以上、渦姫様のお記になった【Tバック企画】ブログナンバーのカラオケ曲からのトラックバックでした。
[ 11:14 ]
[ ├■Doblogger企画！ ]
雨はどうして降るの By jinさま 快答をお求めです。
地球クンのセカンド彼女が実は雨なんです。
地球クンが念力を発して空に浮かんでいるものもみーんな自分の物にしたがるプレイボーイ君です。
地球クンは雨も大好きなんです。だからとっても自分のものにしたいんです。
そんな地球クンが今、一番欲しいものはお月様です。
でも恋焦がれている彼女は地球クンをじらしてじらしてじらしまくっているのです。
そのじらし具合に嫌気が差したとき、地球クンは念力を発してお空に浮かんでいる水が集まったところで一気に自分のものにして気を晴らしているのです。
実は雨は地球クンに好きなようにモテ遊ばれている存在なんですが、雨はそんなこと気がついていないんです。(涙)
そんなわけで、地球クンのフラストレーションのたまり具合によって、雨の強さや時間が決まっているのです。間違いない。(嘘)
以上、jinさまの快答ブログのFirstお題、TB快答ブログ：雨はどうして降るの？のトラックバックでした。
地球クンのセカンド彼女が実は雨なんです。
地球クンが念力を発して空に浮かんでいるものもみーんな自分の物にしたがるプレイボーイ君です。
地球クンは雨も大好きなんです。だからとっても自分のものにしたいんです。
そんな地球クンが今、一番欲しいものはお月様です。
でも恋焦がれている彼女は地球クンをじらしてじらしてじらしまくっているのです。
そのじらし具合に嫌気が差したとき、地球クンは念力を発してお空に浮かんでいる水が集まったところで一気に自分のものにして気を晴らしているのです。
実は雨は地球クンに好きなようにモテ遊ばれている存在なんですが、雨はそんなこと気がついていないんです。(涙)
そんなわけで、地球クンのフラストレーションのたまり具合によって、雨の強さや時間が決まっているのです。間違いない。(嘘)
以上、jinさまの快答ブログのFirstお題、TB快答ブログ：雨はどうして降るの？のトラックバックでした。
2004/09/07のBlog
[ 16:34 ]
[ ├■前略 Doblogさま ]
Doblogのアクセス過多のためのダウン現象をほんの少しでも軽くするために、ユーザに出来ることをexkydeさまが提案されています。
目的は
DoblogのWebアプリケーションサーバのお仕事を減らしてあげる
DoblogのDBサーバへのアクセスを減らしてあげる
の2点です。
僅かながらもCAMUSもその提案に乗らせていただきます。
この行動でレスポンスが0.1秒でもよくなるのであれば、DoblogユーザにもDoblogにお越しいただく読者の方々にもよい効果になることを期待します。
具体的にはこういう行動を取りました。
以下のメニュー項目を非表示にしました。
・Hottolink
・カレンダー
・新着リスト
・コメントリスト
・トラックバックリスト
・リンクリスト
・訪問者リスト → やっぱり寂しいので復活(笑) At 2004/09/08
表示する記事を15件から5件に大幅縮小いたしました。
ほんの些細な軽減措置ですが、出来ることだけでもやっておこうと思います。
「CAMUSのこくばん」をご利用いただく皆様方には少々ご不便をおかけしますが、ご了承いただければ、と存じます。
多少なりとも軽くなったと感じれば、復活の可能性は無きにしも非ず…です。(^^;)
以上、C+EのBのexkydeさまがお記になったユーザーに出来ることからのトラックバックでした。
…って、一番不便だなーって思うのはCAMUSかもしれない。(爆)
2004/09/08 Add
現在のCAMUSがやっている行動はアカラサマにやりすぎ(爆)です。
ここまでやらないとDoblogは遅くてたまらないからやんなさい！ということではありませんので、あしからずご了承くださいませ。
各Doblogユーザさまが各々のBlogに必要な機能をもう一度見極めて、自分のBlogでは最低レベルでどこまで必要か、今一度、考える機会なのだ、実行するかどうかはそれを見極めてから…としていただければ幸いです。
見極めの参考までに…
表示するのにDB(各人の固有データをためておく場所のことです)を見に行かないと思われるもの。
ただし、それらのリンクをクリックすると、DBを見に行き、加工して表示をする処理がはいるので、負荷はかかります。
・Hottolink
・訪問者リスト
・イメージリスト
表示するだけでDBを見に行くと思われるもの
表示するために必要なコストが高いと思われる(CAMUSの主観です)順番に書いてみます。
1) 記事(アタリマエだわな(^^;))
2) トラックバックリスト
2) コメントリスト
4) カレンダー
5) ブックマークリスト
5) ブックマーカーリスト
7) 最新記事
8) リンク
9) 記事のURL
9) トラックバックURL
…この順位の根拠も書いたほうがいい？(^^;)
目的は
DoblogのWebアプリケーションサーバのお仕事を減らしてあげる
DoblogのDBサーバへのアクセスを減らしてあげる
の2点です。
僅かながらもCAMUSもその提案に乗らせていただきます。
この行動でレスポンスが0.1秒でもよくなるのであれば、DoblogユーザにもDoblogにお越しいただく読者の方々にもよい効果になることを期待します。
具体的にはこういう行動を取りました。
以下のメニュー項目を非表示にしました。
・Hottolink
・カレンダー
・新着リスト
・コメントリスト
・トラックバックリスト
・リンクリスト
・訪問者リスト → やっぱり寂しいので復活(笑) At 2004/09/08
表示する記事を15件から5件に大幅縮小いたしました。
ほんの些細な軽減措置ですが、出来ることだけでもやっておこうと思います。
「CAMUSのこくばん」をご利用いただく皆様方には少々ご不便をおかけしますが、ご了承いただければ、と存じます。
多少なりとも軽くなったと感じれば、復活の可能性は無きにしも非ず…です。(^^;)
以上、C+EのBのexkydeさまがお記になったユーザーに出来ることからのトラックバックでした。
…って、一番不便だなーって思うのはCAMUSかもしれない。(爆)
2004/09/08 Add
現在のCAMUSがやっている行動はアカラサマにやりすぎ(爆)です。
ここまでやらないとDoblogは遅くてたまらないからやんなさい！ということではありませんので、あしからずご了承くださいませ。
各Doblogユーザさまが各々のBlogに必要な機能をもう一度見極めて、自分のBlogでは最低レベルでどこまで必要か、今一度、考える機会なのだ、実行するかどうかはそれを見極めてから…としていただければ幸いです。
見極めの参考までに…
表示するのにDB(各人の固有データをためておく場所のことです)を見に行かないと思われるもの。
ただし、それらのリンクをクリックすると、DBを見に行き、加工して表示をする処理がはいるので、負荷はかかります。
・Hottolink
・訪問者リスト
・イメージリスト
表示するだけでDBを見に行くと思われるもの
表示するために必要なコストが高いと思われる(CAMUSの主観です)順番に書いてみます。
1) 記事(アタリマエだわな(^^;))
2) トラックバックリスト
2) コメントリスト
4) カレンダー
5) ブックマークリスト
5) ブックマーカーリスト
7) 最新記事
8) リンク
9) 記事のURL
9) トラックバックURL
…この順位の根拠も書いたほうがいい？(^^;)
[ 16:22 ]
[ ├■DB関連(SQL以外) ]
ある名簿があって、その人名の検索をしたい
こんな要望があったとします。
その名簿のレイアウトをこんなふうに設計してみました。
入力するデータは「氏名漢字」「氏名かな」「氏名アルファベット」の3つとします。
CREATE TABLE TBL_HUMANLIST (
ID VARCHAR(10) NOT NULL PRIMARY KEY,
NAME_KANJI VARCHAR(50) NOT NULL,
NAME_KANA VARCHAR(50) NOT NULL,
NAME_ALPHABET VARCHAR(100) NOT NULL
)
ココで、どういうふうに検索をしたいのかをもっと具体的に突き詰めていくと、こんな要望が上がっていたことがわかったとします。
1) 検索対象は「氏名漢字」「氏名かな」「氏名アルファベット」とする
2) 「氏名かな」にはひらがな、カタカナどちらが入ってもいいとする、ただし全角
3) 検索する際には、「漢字」「ひらがな」「カタカナ」「アルファベット」のいずれを入れてもいい
4) 「氏名かな」にひらがなデータしかなくとも、「カタカナ」で検索してちゃんとヒットする、逆も然り
5) 「氏名アルファベット」は大文字小文字混在しているとする、ただし半角
6) 「氏名アルファベット」の大文字小文字の区別関係なく、アルファベット検索できるようにする
7) 漢字は旧字体・新字体の区別なく検索する…ということまではしなくてよい
8) 検索条件として入力されたものの部分一致したものを全件を表示する
イヤ、お客様というのはワガママですから、コレぐらいの要望は朝飯前に仰ってきますよね。(^^;)
ココで、先のテーブルレイアウトのまま、検索したとします。
すると、こんなクエリを書くことになります。(Transact-SQL方式で記述しています)
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
T.NAME_KANJI LIKE '%' + @検索キーワード + '%'
OR カナ変換関数(T.NAME_KANA) LIKE '%' + カナ変換関数(@検索キーワード) + '%'
OR UPPERCASE(T.NAME_ALPHABET) LIKE '%' + UPPERCASE(@検索キーワード) + '%'
このクエリではこんな現象が起きています。
A) ORを使うことになるので遅い
B) 比較対照のカラムに変換関数を利用しているので遅い
遅いということは、システムだけでなく、利用するユーザにも負担を与えるということです。
コレを回避するための一つの方法として
テーブルレイアウト設計を変更する
という手段をとることがあります。
ココで負担を減らすためのターゲットになるのは、上記のAとBです。
A→ORを使わなくてよいテーブルレイアウトにする、もしくはクエリを工夫する
B→変換関数を使わなくてよいテーブルレイアウトにする
まずAの改良から。
クエリの工夫
ORを利用するよりUNIONを利用するほうがなんぼか負荷を軽減できる可能性があります。
よって、先のクエリはこんなふうに書き換えることが出来ます。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
T.NAME_KANJI LIKE '%' + @検索キーワード + '%'
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
カナ変換関数(T.NAME_KANA) LIKE '%' + カナ変換関数(@検索キーワード) + '%'
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
UPPERCASE(T.NAME_ALPHABET) LIKE '%' + UPPERCASE(@検索キーワード) + '%'
結果は同じはずです。
なお、本当に負荷がかかっていないかどうか、ベンチマークテストなどを行って確認してくださいね。
テーブルレイアウト設計の工夫
DBは基本的に文字変換があまり得意ではありません。
また、関数はじめ関数は極力利用しない方向にもって行く、使わなければいけない場面だけ使うよう勤めるのがよいと思います。
関数だけでなく、式も同様です。極力しなくていい計算はやめておくのが吉だと思います。
というわけで、関数を使わないでよいテーブルレイアウト設計をするための一つとして、今回は「検索用のカラム」を作るという方法があると思います。
「検索用のテーブル」でもよいかもしれません。
ココでは「検索用のテーブルを作成してみます。
CREATE TABLE TBL_HUMANLIST_FORSEARCH (
ID VARCHAR(10) NOT NULL PRIMARY KEY,
NAME_KANJI VARCHAR(50) NOT NULL,
NAME_KANA VARCHAR(50) NOT NULL,
NAME_ALPHABET VARCHAR(100) NOT NULL
)
このテーブルを作成したところで、左記のTBL_HUMANLISTテーブルに、このTBL_HUMANLIST_FORSEARCHテーブルに対して、INSERT/UPDATE/DELETEのタイミングでトリガを仕込みます。
INSERT時
INSERT INTO TBL_HUMANLIST_FORSEARCH
SELECT
ID,
NAME_KANJI,
カナ変換関数(NAME_KANA),
UPPERCASE(NAME_ALPHABET)
FROM TBL_HUMANLIST
UPDATE時
UPDATE TBL_HUMANLIST_FORSEARCH T
SET
T.NAME_KANJI = T0.NAME_KANJI,
T.NAME_KANA = カナ変換関数(T0.NAME_KANA),
T.NAME_ALPHABET = UPPERCASE(T0.NAME_ALPHABET)
FROM TBL_HUMANLIST T0
WHERE T.ID = T0.ID
DELETE時
DELETE FROM TBL_HUMANLIST_FORSEARCH
WHERE ID = TBL_HUMANLIST.ID
このトリガをTBL_HUMANLISTに仕込むことによって、TBL_HUMANLISTに対してデータが更新・削除されるたびに、TBL_HUMANLIST_FORSEARCHという検索用テーブルに検索用情報がたまっていくというわけです。
もちろん、トリガが信用できないDBも中にはありますので(ってほとんどそうかも(爆))、トリガを使わずにプログラムなどで上記を実装してやるほうが確実だと思います。
このテーブルを利用すると、こんなクエリを書くことが出来ます。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_KANJI LIKE '%' + @検索キーワード + '%')
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_KANA LIKE '%' + カナ変換関数(@検索キーワード) + '%')
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_ALPHABET LIKE '%' + UPPERCASE(@検索キーワード) + '%')
コレでだいぶ検索が軽くなったと思います。
更新・削除より、検索のほうがはるかに利用頻度が高いシステムなのであれば、更新・削除に時間がかかったとしても、検索をするときになるべく軽くなるよう、工夫してやるのがよいと思われます。
さらにもう一工夫
お気づきの方もおられるでしょうが、同じ検索キーワードを複数のカラムに対して検索をかけています。
ということは、複数のカラムを一つにまとめてやることで、もう少しクエリが軽くなるのでは？と考えてみましょう。
まず、3つのカラムを一つにまとめる方法としてクエリ…をあげてみます。一応。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_KANJI + T0.NAME_KANA + T0. NAME_ALPHABET
LIKE '%' + @検索キーワード + '%')
最後の行、長いですね。(^^;)
先にも書いたようにクエリ中で式を書くのはDBとしてはあまり得意でない分野を頑張れ！といわれているようなものですので、やめておいたほうがいいです。
ココではテーブルレイアウトの工夫をする方向でやってみたいとます。
CREATE TABLE TBL_HUMANLIST_FORSEARCH (
ID VARCHAR(10) NOT NULL PRIMARY KEY,
NAME_KANJI VARCHAR(50) NOT NULL,
NAME_KANA VARCHAR(50) NOT NULL,
NAME_ALPHABET VARCHAR(100) NOT NULL,
NAME_SEARCH VARCHAR(300) NOT NULL,
)
NAME_SEARCHというカラムを追加してみました。
ここにNAME_KANJI、NAKE_KANA、NAME_ALPHABETの3カラムを合体させたデータを突っ込めばいいのです。(その方法は略(^^;))
そして、上記のテーブルレイアウトを反映させたクエリはこんな感じ。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_SEARCH LIKE '%' + @検索キーワード + '%')
だいぶとすっきりしました。
最後に
今まで、検索のためのクエリの負荷を軽くする方向ばかりに注目してやってきました。
ところが、この方法、HDDのほうに負荷をかけているのです。
DBのデータのせいで、テーブルの要領も確実に容量が大きくなり、結果、HDDの空き容量が圧迫されます。
そのあたりも考慮に入れた上で、システムの設計をあーでもないこーでもないと試行錯誤してバランスをとっていただければ、と思います。
以上、Doblogスタッフ様もそういうことやって欲しいな…という布石を込めた記事でした。
表示部分、工夫できませんか？多分、変換プログラム・複雑なクエリ多用して表示していると思いますので、この辺、参考にならないかな…という希望的観測。sigh
コレを実行するにはカラムサイズの制限とかあると思うので難しいかとは思いますが…考える余地は…ないことはないですよね？
→ [DB関連INDEX]
こんな要望があったとします。
その名簿のレイアウトをこんなふうに設計してみました。
入力するデータは「氏名漢字」「氏名かな」「氏名アルファベット」の3つとします。
CREATE TABLE TBL_HUMANLIST (
ID VARCHAR(10) NOT NULL PRIMARY KEY,
NAME_KANJI VARCHAR(50) NOT NULL,
NAME_KANA VARCHAR(50) NOT NULL,
NAME_ALPHABET VARCHAR(100) NOT NULL
)
ココで、どういうふうに検索をしたいのかをもっと具体的に突き詰めていくと、こんな要望が上がっていたことがわかったとします。
1) 検索対象は「氏名漢字」「氏名かな」「氏名アルファベット」とする
2) 「氏名かな」にはひらがな、カタカナどちらが入ってもいいとする、ただし全角
3) 検索する際には、「漢字」「ひらがな」「カタカナ」「アルファベット」のいずれを入れてもいい
4) 「氏名かな」にひらがなデータしかなくとも、「カタカナ」で検索してちゃんとヒットする、逆も然り
5) 「氏名アルファベット」は大文字小文字混在しているとする、ただし半角
6) 「氏名アルファベット」の大文字小文字の区別関係なく、アルファベット検索できるようにする
7) 漢字は旧字体・新字体の区別なく検索する…ということまではしなくてよい
8) 検索条件として入力されたものの部分一致したものを全件を表示する
イヤ、お客様というのはワガママですから、コレぐらいの要望は朝飯前に仰ってきますよね。(^^;)
ココで、先のテーブルレイアウトのまま、検索したとします。
すると、こんなクエリを書くことになります。(Transact-SQL方式で記述しています)
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
T.NAME_KANJI LIKE '%' + @検索キーワード + '%'
OR カナ変換関数(T.NAME_KANA) LIKE '%' + カナ変換関数(@検索キーワード) + '%'
OR UPPERCASE(T.NAME_ALPHABET) LIKE '%' + UPPERCASE(@検索キーワード) + '%'
このクエリではこんな現象が起きています。
A) ORを使うことになるので遅い
B) 比較対照のカラムに変換関数を利用しているので遅い
遅いということは、システムだけでなく、利用するユーザにも負担を与えるということです。
コレを回避するための一つの方法として
テーブルレイアウト設計を変更する
という手段をとることがあります。
ココで負担を減らすためのターゲットになるのは、上記のAとBです。
A→ORを使わなくてよいテーブルレイアウトにする、もしくはクエリを工夫する
B→変換関数を使わなくてよいテーブルレイアウトにする
まずAの改良から。
クエリの工夫
ORを利用するよりUNIONを利用するほうがなんぼか負荷を軽減できる可能性があります。
よって、先のクエリはこんなふうに書き換えることが出来ます。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
T.NAME_KANJI LIKE '%' + @検索キーワード + '%'
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
カナ変換関数(T.NAME_KANA) LIKE '%' + カナ変換関数(@検索キーワード) + '%'
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
UPPERCASE(T.NAME_ALPHABET) LIKE '%' + UPPERCASE(@検索キーワード) + '%'
結果は同じはずです。
なお、本当に負荷がかかっていないかどうか、ベンチマークテストなどを行って確認してくださいね。
テーブルレイアウト設計の工夫
DBは基本的に文字変換があまり得意ではありません。
また、関数はじめ関数は極力利用しない方向にもって行く、使わなければいけない場面だけ使うよう勤めるのがよいと思います。
関数だけでなく、式も同様です。極力しなくていい計算はやめておくのが吉だと思います。
というわけで、関数を使わないでよいテーブルレイアウト設計をするための一つとして、今回は「検索用のカラム」を作るという方法があると思います。
「検索用のテーブル」でもよいかもしれません。
ココでは「検索用のテーブルを作成してみます。
CREATE TABLE TBL_HUMANLIST_FORSEARCH (
ID VARCHAR(10) NOT NULL PRIMARY KEY,
NAME_KANJI VARCHAR(50) NOT NULL,
NAME_KANA VARCHAR(50) NOT NULL,
NAME_ALPHABET VARCHAR(100) NOT NULL
)
このテーブルを作成したところで、左記のTBL_HUMANLISTテーブルに、このTBL_HUMANLIST_FORSEARCHテーブルに対して、INSERT/UPDATE/DELETEのタイミングでトリガを仕込みます。
INSERT時
INSERT INTO TBL_HUMANLIST_FORSEARCH
SELECT
ID,
NAME_KANJI,
カナ変換関数(NAME_KANA),
UPPERCASE(NAME_ALPHABET)
FROM TBL_HUMANLIST
UPDATE時
UPDATE TBL_HUMANLIST_FORSEARCH T
SET
T.NAME_KANJI = T0.NAME_KANJI,
T.NAME_KANA = カナ変換関数(T0.NAME_KANA),
T.NAME_ALPHABET = UPPERCASE(T0.NAME_ALPHABET)
FROM TBL_HUMANLIST T0
WHERE T.ID = T0.ID
DELETE時
DELETE FROM TBL_HUMANLIST_FORSEARCH
WHERE ID = TBL_HUMANLIST.ID
このトリガをTBL_HUMANLISTに仕込むことによって、TBL_HUMANLISTに対してデータが更新・削除されるたびに、TBL_HUMANLIST_FORSEARCHという検索用テーブルに検索用情報がたまっていくというわけです。
もちろん、トリガが信用できないDBも中にはありますので(ってほとんどそうかも(爆))、トリガを使わずにプログラムなどで上記を実装してやるほうが確実だと思います。
このテーブルを利用すると、こんなクエリを書くことが出来ます。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_KANJI LIKE '%' + @検索キーワード + '%')
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_KANA LIKE '%' + カナ変換関数(@検索キーワード) + '%')
UNION
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_ALPHABET LIKE '%' + UPPERCASE(@検索キーワード) + '%')
コレでだいぶ検索が軽くなったと思います。
更新・削除より、検索のほうがはるかに利用頻度が高いシステムなのであれば、更新・削除に時間がかかったとしても、検索をするときになるべく軽くなるよう、工夫してやるのがよいと思われます。
さらにもう一工夫
お気づきの方もおられるでしょうが、同じ検索キーワードを複数のカラムに対して検索をかけています。
ということは、複数のカラムを一つにまとめてやることで、もう少しクエリが軽くなるのでは？と考えてみましょう。
まず、3つのカラムを一つにまとめる方法としてクエリ…をあげてみます。一応。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_KANJI + T0.NAME_KANA + T0. NAME_ALPHABET
LIKE '%' + @検索キーワード + '%')
最後の行、長いですね。(^^;)
先にも書いたようにクエリ中で式を書くのはDBとしてはあまり得意でない分野を頑張れ！といわれているようなものですので、やめておいたほうがいいです。
ココではテーブルレイアウトの工夫をする方向でやってみたいとます。
CREATE TABLE TBL_HUMANLIST_FORSEARCH (
ID VARCHAR(10) NOT NULL PRIMARY KEY,
NAME_KANJI VARCHAR(50) NOT NULL,
NAME_KANA VARCHAR(50) NOT NULL,
NAME_ALPHABET VARCHAR(100) NOT NULL,
NAME_SEARCH VARCHAR(300) NOT NULL,
)
NAME_SEARCHというカラムを追加してみました。
ここにNAME_KANJI、NAKE_KANA、NAME_ALPHABETの3カラムを合体させたデータを突っ込めばいいのです。(その方法は略(^^;))
そして、上記のテーブルレイアウトを反映させたクエリはこんな感じ。
SELECT T.*
FROM TBL_HUMANLIST T
WHERE
EXISTS(SELECT 'X' FROM TBL_HUMANLIST_FORSEARCH T0
WHERE T0.ID = T.ID AND
T0.NAME_SEARCH LIKE '%' + @検索キーワード + '%')
だいぶとすっきりしました。
最後に
今まで、検索のためのクエリの負荷を軽くする方向ばかりに注目してやってきました。
ところが、この方法、HDDのほうに負荷をかけているのです。
DBのデータのせいで、テーブルの要領も確実に容量が大きくなり、結果、HDDの空き容量が圧迫されます。
そのあたりも考慮に入れた上で、システムの設計をあーでもないこーでもないと試行錯誤してバランスをとっていただければ、と思います。
以上、Doblogスタッフ様もそういうことやって欲しいな…という布石を込めた記事でした。
表示部分、工夫できませんか？多分、変換プログラム・複雑なクエリ多用して表示していると思いますので、この辺、参考にならないかな…という希望的観測。sigh
コレを実行するにはカラムサイズの制限とかあると思うので難しいかとは思いますが…考える余地は…ないことはないですよね？
→ [DB関連INDEX]
[ 11:04 ]
[ ├■会社にて… ]
今年の9月末日で有効期限が切れる社員証。
新規に切り替えるため、社員証に載せる写真を撮りに行きました。
今、首からぶら下げている社員証をじっと見る。
ふとそこで気がついた事実。
前回写真を取ったときと同じ服を着ているぅ！！
しかも、
ほぼ同じ髪型だぁ！！！
さらに言うと、
明らかに今のほうがやつれているぅ！！！！
なんだか、使用前・使用後で見比べてみたい気分です。
さて、どんな社員証に仕上がるのでしょうか…。
新規に切り替えるため、社員証に載せる写真を撮りに行きました。
今、首からぶら下げている社員証をじっと見る。
ふとそこで気がついた事実。
前回写真を取ったときと同じ服を着ているぅ！！
しかも、
ほぼ同じ髪型だぁ！！！
さらに言うと、
明らかに今のほうがやつれているぅ！！！！
なんだか、使用前・使用後で見比べてみたい気分です。
さて、どんな社員証に仕上がるのでしょうか…。