よみがな　あり｜なし

スタジオムーンリーフがウェブサイトを取り扱うようになって以来、データベースをどのように取り扱うかについて、かなりの試行錯誤がありました。ニュースサイトを扱っていた（今でも扱っていますが）こともあり、更新性を考えると、ニュースの見出しや記事をデータベース化して扱うことを考えるのは、当然と言えば当然です。

本来であれば、MySQLやオラクル等と連携したウェブデザインを前提とすべきでしょうけど、なにせスタジオムーンリーフにはそんな贅沢なサーバーを維持できる体力もありませんし、MySQLにしてもオラクルにしてもキチンとしたデータベース設計をする必要があるので、個人の性質上、面倒くさいという気持ちもありました。

現在ではウェブデザインとして使えるデータベースとセットになっているようなウェブサーバーがあるかもしれませんけど、そもそもMySQLやオラクルといったデータベースは何万件以上といった、とても人間の目では探し切れない大きなデータを扱うのに向いています。ニュースの見出しや記事をデータベース化しようと考えた時、扱う件数はせいぜい数千件。これではサイズが合いません。無理してMySQL付きのサーバーを利用することは、逆の意味で割りが合わないことになります。

そこで最後に残った選択肢が、テキストベースのデータベースです。
テキストベースのデータとして有名なのが、ＣＳＶ形式。１行をひとつのデータとして考えカンマ区切りでカラムを区切った単純な形式です。スタジオムーンリーフでも最近までこのＣＳＶ形式でウェブのデータを扱っていました。

しかしながら、ＣＳＶ形式は個々のデータがカンマ区切りで並んでいるため、何のデータが何番目にあるかをしっかり設計しなければなりませんし、仕様変更で新たにデータを追加しようとする時は、プログラム全体を見直すなど、かなり神経を使う作業を強いられます。

お見せするのも恥ずかしい昔使っていたＣＳＶ形式のデータの中身。あくまで１例。複雑なデータや１件だけで長大なデータには不向き。目で見て探せる範囲ならテキストエディタで簡単に修正できるのが強み。

「もっと手軽でデータ設計が変わっても柔軟に対応できるような形式はないもんかな」

データベースの設計が簡単で、あとで設計が変わってもプログラムでそれを自動的に検出できるくらいの手軽さが欲しかったのです。

最終的に辿り着いたのがＸＭＬ形式でデータを扱うことでした。ただ、サーバーがＸＭＬ用のパーサーがないバージョンだったため、パーサーもどきは自作となりました。これにより、データベースの取り扱いは大変ラクチンになりました。自作パーサーもどきを、ＳＥＬＥＣＴ文っぽい動作ができるように改造できたのが強みです（ＳＥＬＥＣＴ文っぽい動作＝データ全体から特定のＩＤのデータを抽出し、そのデータから好きなカラムを呼び出せる処理です。例えるなら、住所録（データ全体）から○○さん（ＩＤ）の住所（カラム）を呼び出す動作）

ＸＭＬ形式のデータの中身。１例としてＲＳＳフィードの中身。自由度が高いのがＸＭＬ形式の強み。専用のパーサー（Parser）で構造を解析するのが一般的。スタジオムーンリーフのウェブサーバはＸＭＬパーサー未装備のバージョンだったため、パーサーもどきを自作。

さて、次に。
データベースを作っただけではあまり意味がありません。データを簡単に登録できる仕組みが必要です。そして、登録してあるデータを簡単に更新（編集）する仕組みだって必要です。おそらく、ニュースサイトを運営している企業などでは、ブログをアップするような仕組みでデータの登録や編集を行うようになっていると思います。つまり、ウェブのフォームを使った方法です。

スタジオムーンリーフでも、つい最近までこのフォームを使った方法でニュース記事をアップしたり、編集したりしていました。しかし、この方法だとどうにも効率が悪いうえ、誤字が発生しやすいんです。また、データベースなど仕様が変わった時に、入力フォームの形も変えなきゃならないとか、妙に手間ばかりかかる仕組みです。

取材の現場で周りを見ますと、やはり誤字が発生しやすいのか、まずは記事をテキストファイルに下書きしてからそれをフォームにペーストしてアップしているような方がいらっしゃいました。わたしも、誤字が怖いのと文章全体が見やすいのとで、まずはテキストファイルに書くことから始め、その後フォームにペーストする操作をするようになりました。

それがどうにも効率が悪いので、下書きしたテキストファイルをアップデートするだけで自動的にデータベースに反映される仕組みに変更しました。テキストファイルはある程度のフォーマットに従う必要はありますが、目で理解できる範囲です。アップデートすると、ファイルは自動的にナンバリングされ、特定のフォルダにバックアップされます。バックアップされたファイルを編集してアップデートすることで更新も可能としました。ウェブフォームを考えなくて良くなったので、非常に効率が良くなりました。

お恥ずかしい限りですが、昔使っていたウェブフォーム。あくまで１例。とてもシンプルな形ですが、これでも文章全体が見えにくいため、誤字の発生率が高いのです。かといってテキストファイルで清書してからペーストするという手順は効率が悪いです。画像の例ですと、タイトルと本文の２回ペースト作業をしないとならないので、頻度が高くなってくると面倒くさくなってきます。

データをＸＭＬ形式にしたこと、ＸＭＬパーサを自作したこと、ウェブフォームでのアップデートをやめてテキストファイルのアップデートとしたこと。これらの工夫で効率良く作業ができるようになりました。

昔から現在まで、効率という意味で変えようが難しいのが画像の取り扱いです。
ウェブ掲載用に画像を変更してアップデートする仕組みは、トリミングも含め画像編集ソフトを使うより向上させようが思いつきません。こればっかりは１枚１枚目で見て確認する作業となっております。

≫ NEXT_LOG 通信料スリム化計画【その１】

≪ PREV_LOG 備忘録としてのブログコンテンツ