SQLとAPI、行ったり来たりでちょっと進んだ（のだろうか）

負荷軽減が喫緊の課題なのに寄り道。

ドットコム「我が社の一冊」は、Googleスプレッドシート→XML公開→simplexmlとドットコムAPIを使ってHTML作成→コピーしてwpにペースト、という流れ。これはこれでうまくいっていたのだが、なぜか一件、どうしてもうまくHTMLが書き出されないアイテムがある。HTMLが書き出せないというか、APIが返ってこない。理由は分からない。そもそもISBNの項目に文字列が入っていたのを削除したのがよくなかったのか。それとも何か他の原因なのか。

「我が社の一冊」は元々は忘年会や会員集会の場に自社の本を持ち寄り、お互いの理解を深めましょう、ついでに欲しい本を持ち帰って読みましょう、という企画だった。これはこれで交流だけで無く相互理解にも非常に効果もあり、なかなか悪くない企画だと思う。ただ、それだけだとその場で終わりなのでWebで公開しましょうという流れになった。これも、アクセスがあまり多くないのを除けば、企画としては悪くない。年末に実施することで一年の振り返りという意味もより強調される。ただ、どうしても実質的な効果、つまり、販売促進的な効果は弱い。アクセスが少ないので。

なので、「我が社の一冊」の次の展開を考えてみた。ひとつは書店向けFAX。これなら郵送に比べると費用は非常に少なくて済むので、会員社からは新たな負担無しで実現できそうだ。しかし、これを実現するのであればオススメの一言だけでなく内容紹介なども盛り込みたい。書店向けということであれば取引取次も明記すべきだろう。過去に相乗りFAXを実施した際には課題がいくつかあった。このあたり、相乗りのDMを実現している工藤さんのノウハウを吸収したいところではある。

もうひとつは書店配布のフリーペーパー。こちらは、どういうものを作るのかにもよるが、制作の手間とコストに加えて配布店舗の確保という難問がある。内容については一言に加えて内容紹介である程度なんとかなりそう。印刷に耐える画像データの確保が課題か。

書店FAXにしてもフリーペーパーにしても色々と詳細な情報を付加しないといけない。そのためにドットコムのDBが使える。が、APIだと内容紹介や取引取次は得られない。そういえばSQLで直接つなぐことは可能だった。

ということでSQLで直接データの取り出しというのを試してみたところ、サクッと動く。面白いので色々やりたいと思いつつ、phpのほうでどこかではまって思い通りに動かせない。結局、余計なstring()とか入れていたのが悪かったようで、それを取り除いたら思ってる通りに動いたので、とりあえず「我が社の一冊」のAPI版と同じことを実行してみた。別テーブルから持ってくるIDだけ上手くいっていないが、それ以外はうまくいってる。……、でも、遅くないか？

API版と比べてみたところ、明らかにAPIのほうが早い。そりゃそうか、いくらSQLとはいえ全件から引っ張ってきてるから……、違うか、多分、またオレのアルゴリズムが大きいループに小さいループを重ねちゃってるんだろうな。大きいループが一周する間に全部片付けていく、みたいなアルゴリズムだと早そうだ。

ん、それってXMLReaderか。そうだな、一周する間にドンドン片付けちゃおうおねって、それってXMLReaderだ。なるほどぉ〜〜。ちょっと目の前の霧が晴れた。そうか、（負荷軽減のほうは）やっぱり、まず検索用のXMLを作成（この際、サイズを小さくするのはもちろん、XMLReaderで扱いやすい形にする）→XMLReaderが一周する間にちゃんちゃん片付けていく、が基本なんだな。で、その際に重要なのは一時的に保管する変数の部分のサイズも小さくするってことか。そうするとJSONみたいな話になってくるのか。

なるほど〜〜。色々面倒に見えるけど実際には必然なのかもなあ。勉強になる。

行ったり来たりで非効率ではあるけれど、やっぱり色々触ってみないと納得できない部分ってあるなあ。

今回のSQL利用で見えたのは「我が社の一冊、二次利用への道」とか「βの負荷大幅軽減への道」というより、「アクセスランキング半自動化への道」だったりする。んー、でもそこはけっこう重要だ。もしかすると土日の手間が一気に減るかも知れない。そうなると今やりたいと思ってる他の勉強ができる（プログラミング以外）。

妻に指摘されたが、どうやらオレは勉強好きらしい。但し、自分のペースで。先生という存在が子どもの頃から嫌いだった。仕事の上で先達は多数いるが師弟という関係ではないと思う。師弟という関係性を築き上げられなかったのだろう。売れてるのに売れてないのがもったいないと思っているあの本を販促に余計なおせっかいをしてしまったのもその辺への忸怩たる思いが根底にあるのかも知れない。