検索パターンとその実装どの様な検索ができれば便利か?以下のようなものが思いつきます。種の和名からの検索(結果1行)種の学名からの検索(結果1行)種の英名からの検索(結果1行)属の学名からの検索(結果複数行)科の学名からの検索(結果複数行)科の和名からの検索(結果複数行)目の学名からの検索(結果複数行)目の和名からの検索(結果複数行)種の和名からの部分一致検索(結果複数行)種の学名からの部分一致検索(結果複数行)種の英名からの部分一致検索(結果複数行)それぞれの検索機能に必要なテストをいくつかやってみます。使用頻度が多いかもしれません。正規表現的には/^[ア-ン]+$/のはずです。種名はカタカナで書く決まりですが、ひらがなでも受け付けるようにしておきたいです。和名は、空白や記号・英数字等は含まれません。ストアードプロシジャーを使うの三つの方式を実装してテストしてみました。やることのシーケンスは一緒です。送り込むか、サーバサイドのプロシジャで一括して処理するかの違いで、原則的に後者が速いはずです。上でやっていますが、ネットワーク経由だとさらに差は開きます。最初のバージョン最初にやってみて、愕然としました。いうか、かなりというか、焦りました。10倍の時間がかかっています。制約を書いていなかったのです。制約を付けてやり直したものです。方式の方がかなり速いです。この差を有意と見るか無視するかは用途と目的次第です。性能向上をハードウェア増強でやろうとしたら、どれだけ大変なことか?こういうバグを作り込んでしまった場合、マクロな総合テストでは、まず分かりません。一つ一つのミクロな処理に関して検証しないと見えてきません。時間が経ちデータ量が増大していよいよシステムが力を発揮するべき時に、思わぬ事態になります。バージョンで、データ量を変化させてみます。実際のシステム開発では、プログラマにはごく少量のテストデータしか与えられないことがよくあります。(それすらなくて、プログラマが自分で数行のデータを打ち込んでいたりする光景も見かけます)そもそも、末端のプログラマに渡された仕様書に運用時のデータ量が書いてあるのか、テスト指示書にデータ量が指定されていたのか?すら怪しい。使わない方が速い場合もあるわけですから。違いを思い出してください。件のデータを使用したので、注意深く見ると違いが見えました。件のテストデータでやってみましょう。msecこれでは、熟練したテスターでさえ、問題を見落とすでしょう。そのまま本番稼働、次第にデータが増えてきました。100万件に増加しました。ビーグル号の航海によるダーウィンのガラパゴス以来の大発見です。壊滅的な破綻1,000,000件のデータでテスト。バグ持ちビューの壊滅の様子。キーであると認識することが多いようで、これほど酷い事態にはならないことが多いです。いつでも成功するわけではありません。時間がかかってしまったケース。その他の順番・タイミング、データ量等さまざまな条件で変化するため、余計に見逃す可能性が増えます。データ量は怖くないそして、もう一つ重要なこと。100万件でも、測定誤差程度の違いしかないことを『実感・体感!』してください。万件のデータを生成してみました。それでも、殆ど変わりません。1,000万件なんて『屁』でもないんですよ、実のところは。自分で手を動かして「実感して、体で感じる」って、大事です。理屈だけ知っていても、いざ開発の修羅場になると、「データが増えると検索が遅くなる」という日常的感覚に引きずられて正確な判断ができなくなります。エクセルだって行数が増えたら遅くなりますものね、そう考える方が自然。鳥類の場合の種名は/^[A-Z][a-z]+\s[a-z]+$/以外のパターンは無いはずです。先頭が必ず大文字で他は小文字、1個の空白で属名部分と種小名に分けられます。入力にはそこまでの厳格さを要求せず、可能な限り上記ルールに沿って正規化して受け入れるようにします。和名からの検索と同じ傾向です。いろんなパターンがあります。ワードの数も不定です。アルファベット以外にアポストロフィがあったりするので、エスケープ処理をしっかりやらないとはまります。2例と違う条件が加わります。結果の検証おやおや?遅いぞ前の2例に比べて凄く遅いです。何が違うんでしょう?そうです。変換しているところが違います。