プライマリキーとしての文字列データ型と数値データ型
リレーショナルデータベースのプライマリキーの選択に関するこのシリーズへようこそ。パート1では、ナチュラルプライマリキーとサロゲートプライマリキーについて説明し、どちらか一方を選択する理由を検討しました。今回の記事では、プライマリキーとしての文字列と数値のデータ型について調べ、どちらが好ましいのかを確認します。
ナチュラルキー対サロゲートキー
データベース設計者として直面する最初の決定事項の 1 つは、テーブルで使用するプライマリキー（PK）の種類です。データベース管理者、開発者、テスターなど、日常的にデータベースを扱っている人に尋ねると、無数の意見や正当な理由が得られるでしょう。答えを導き出すための障害をさらに複雑にしているのは、万能なソリューションがないことです。それを念頭に置いて、このシリーズでは、様々な種類のPKに賛成する理由と反対する理由の両方を示します。それら全てのアイデアのどこかに、あなたの組織のニーズのために使用するのに最適なタイプのPKへと導くいくつかのアイデアがあるでしょう。この最初の記事では、PKの2つの基本的なタイプであるナチュラルキーとサロゲートキーを比較します。その後、データベースの自動インクリメント機能を使用するかどうか、およびどのデータ型（複数存在する場合）が最適なPKになるかについて説明します。
アプリケーション開発者は、ストアドプロシージャ内にデータベース操作を格納することで最適なパフォーマンスが得られ、SQLインジェクション攻撃から保護されると長い間信じてきました。また、これらの利点は、データベースロジックのメンテナンス、テスト、および別のベンダーへの移行に関連する追加コストに見合う価値があると考えられていました。近年、開発者がこれらの長年の前提に疑問を持ち始めたため、流れはストアドプロシージャ（またはproc）からHibernateやEntity Frameworkなどのオブジェクトリレーショナルマッパー（ORM）に変わりつつあります。
ストアドプロシージャは時代遅れのツールですか？の記事では、アプリケーションコードとORMを優先してストアドプロシージャを避けるいくつかの理由を取り上げました。今週は、上記で紹介した2つの神話を調査し、今日でもそれらが精査に耐えられるかどうかを見ていきます。
ストアドプロシージャは、ここ数年、一部の組織で好まれなくなっています。これらの企業がデータベースにアクセスするために推奨するアプローチは、NHibernateやEntity Frameworkなどのオブジェクトリレーショナルマッパー（ORM）を使用することです。次の2つのブログ記事では、その理由と、このパラダイムシフトがストアドプロシージャの最終的な陳腐化を示しているかどうかを探ります。
あなたのビジネスを理解することの一部は、販売数などの販売指標を追跡し、最良の顧客を特定することです。そのためには、おそらく、月、四半期、年、またはその他の期間で最も多くの購入を行った顧客に関するデータをフェッチすることから始めることをお勧めします。このデータにより、購入パターンを分析し、傾向を特定できます。このブログでは、強力なCount()関数とGROUP BY句およびHAVING句を組み合わせることによってこれを行うサンプルクエリをいくつか紹介します。
