ほぼすべて 行ごとの関数はパフォーマンスに影響を与えます。唯一の本当の問題は、「影響は心配しないほど小さいか」です。
これは、推測するのではなく、測定することによって発見する必要があるものです。データベース管理は、データもクエリも変更されない場合にのみ、設定して忘れるアクティビティです。それ以外の場合は、パフォーマンスを定期的に監視して、問題が発生しないようにする必要があります。
上記のコメントで「十分に小さい」とは、次のようなパフォーマンスへの影響について心配する必要がないことを意味します。
select * from friends where lowercase(lastname) = "smith"
友達が3人しかない場合。
テーブルのサイズが大きくなるにつれて、これらの影響はより深刻になります。たとえば、1億人の顧客がいて、コンピュータに関連している可能性が高いすべての顧客を見つけたい場合は、試してみたくないでしょう。
select name from customers where lowercase(name) like '%comp%'
それはあなたのDBAをたくさんのレンガのようにあなたに降ろす可能性があります。
過去にこれを修正した1つの方法は、データに冗長性を導入することです。その最初の例を使用して、lowerlastnameという列を追加します。 lastnameの小文字の値を入力します 。次に、検索目的でインデックスを作成し、select ステートメントは、当然のことながら、目がくらむほど速くなります。
そして、それは私たちの非常に愛されている3NFに何をしますか？自分が何をしているのかを知っていれば、答えは「あまりない」です:-)
データの一貫性を維持するために、この新しい列に挿入/更新トリガーが入力されるようにデータベースを設定できます。結果を理解して軽減することを条件として、パフォーマンス上の理由から3NFを破ることは完全に許容されます。
同様に、その2番目のクエリには、新しいインデックス付き列name_contains_compに入力される挿入/更新トリガーを含めることができます。 関連するテキストを含むエントリが更新または挿入されたときはいつでも。
ほとんどのデータベースは書き込まれるよりもはるかに頻繁に読み取られるため、これにより計算のコストが挿入/更新に移動し、選択したすべての操作で効果的に償却されます。その場合、クエリは次のようになります。
select name from customers where name_contains_comp = 'Y'
繰り返しになりますが、挿入と更新がわずかに遅くなるというわずかなコストで、クエリは目がくらむほど速くなります。