アプリケーション開発者は、ストアドプロシージャ内にデータベース操作を格納することで最適なパフォーマンスが得られ、SQLインジェクション攻撃から保護されると長い間信じてきました。また、これらの利点は、データベースロジックのメンテナンス、テスト、および別のベンダーへの移行に関連する追加コストに見合う価値があると考えられていました。近年、開発者がこれらの長年の前提に疑問を持ち始めたため、流れはストアドプロシージャ（またはproc）からHibernateやEntity Frameworkなどのオブジェクトリレーショナルマッパー（ORM）に変わりつつあります。
ストアドプロシージャは時代遅れのツールですか？の記事では、アプリケーションコードとORMを優先してストアドプロシージャを避けるいくつかの理由を取り上げました。今週は、上記で紹介した2つの神話を調査し、今日でもそれらが精査に耐えられるかどうかを見ていきます。
ストアドプロシージャは、ここ数年、一部の組織で好まれなくなっています。これらの企業がデータベースにアクセスするために推奨するアプローチは、NHibernateやEntity Frameworkなどのオブジェクトリレーショナルマッパー（ORM）を使用することです。次の2つのブログ記事では、その理由と、このパラダイムシフトがストアドプロシージャの最終的な陳腐化を示しているかどうかを探ります。
あなたのビジネスを理解することの一部は、販売数などの販売指標を追跡し、最良の顧客を特定することです。そのためには、おそらく、月、四半期、年、またはその他の期間で最も多くの購入を行った顧客に関するデータをフェッチすることから始めることをお勧めします。このデータにより、購入パターンを分析し、傾向を特定できます。このブログでは、強力なCount()関数とGROUP BY句およびHAVING句を組み合わせることによってこれを行うサンプルクエリをいくつか紹介します。
テーブルから奇数行または偶数行のみを選択しなければならないということは、実際に行うまでは必要のないことのように思えます。Googleのクイックサーチでは、これが十分頻繁に行われていることであるとわかりますが、その方法を知っているデータベース専門家はほとんどいないため、彼らは答えを求めて常にオンラインデータベースコミュニティに目を向けます。このブログの読者は、今日ここで我々が事実を明確にしますので、データベースフォーラムで解決策を探し回る手間を省くことができます。
CSVはカンマ区切りの値ファイルで、データを表形式で保存できます。これは長い間、データベース間でデータを転送するための推奨形式でした。最近では、XMLやJSONなどのインターネット主導のフォーマットも大きな注目を集めています。CSVファイルは、テーブルデータを非常に適切に表現し、Microsoft ExcelやGoogleスプレッドシートなど、ほぼ全てのスプレッドシートプログラムで使用できるため、データベースに適しています。今日のブログでは、MySQLでテーブルデータをCSVにエクスポートするいくつかの方法を見ていきます。
