5 に答える
英数字フィールドに作成しているインデックスがテーブルのクラスター化されたインデックスである場合、パフォーマンスの違いはごくわずかです。これは、あなたの質問に基づいて当てはまりますが、完全を期すために注意したいと思います。私は2つの理由でこれを言います：
- クラスタ化されたインデックスはテーブルの物理的な順序であるため、そのインデックスを検索するときに、クエリのデータページからおそらくより多くのデータを検索する場合、そのインデックスも物理的にその順序で格納されるため、バイナリ検索を実行できます。
- 二分探索は、統計的指標を忘れないように、あなたが得ることができるのとほぼ同じくらい効率的です。整数の主キーは、数学的に言えば、たとえば2が1の後に来ることがわかっているため、取得できる限り高速なシークである統計インデックスを構築するため、これを呼び出します。
したがって、英数字、または複合キーとインデックスを作成し、それらと整数キーの違いを比較しようとするときは、このことを念頭に置いてください。個人的には、整数の主キーを使用することを好みます。これは、極端な成長の際に、時間の経過とともにパフォーマンスが向上することがわかったためです。
これがお役に立てば幸いです。
私は英数字の主キーを定期的に使用していますが、まったく問題はありません。パフォーマンスの問題はなく、アドレス可能なスペースが広く、表現力があり、人間が読める形式になっています。整数キーは単なる慣例です。
移植の問題に加えて主要なアーキテクチャの変更を追加することにより、プロジェクトに追加するリスクに加えて、可能な限り既存のスキーマに固執すると思います。
パフォーマンスの向上はありません。実際、パフォーマンスの問題があることを知っていて証明/測定できない限り、「より速くするために」物事を変更すると、通常は苦痛につながります。
ただし、主キーに意味があるように見えることが懸念されます。これは国コードであり、数字が連結されています。従業員が米国から英国に移動した場合はどうなりますか？英国が1000人目の従業員を雇用した場合はどうなりますか？
そのため、意味のない主キーを使用するようにアプリケーションをリファクタリングします。INTであるかVARCHARであるかは、それほど重要ではありません。
このPKを追加し、以前のPKも保持すると、データ管理の問題に対処する必要があります。またはおそらくあなたの顧客。新しいデータベースにアップグレードする既存のユーザーがいる場合、古いPKを削除することは現実的ではない可能性があります。
EmployeeCode（以前のPK）がデータのユーザーによって従業員を識別するために使用される場合、このフィールドが一意であることを確認するために制約を追加する必要があります。両方のコードを実行すると、期待していたパフォーマンスの向上がすべて失われます。
もし私だったら、私は十分に一人で去ります。パフォーマンスの向上は、あるとしても、取るに足らないものになります。
たまに英数字の主キーに出くわすことがあります。個人的には、人生が難しくなるだけだと思います。変更できて、変更したい場合は、先に進んでください。後で作業が簡単になります。 。FKである場合は、すべてのデータを適切に更新するためのスクリプトを慎重に作成する必要があります。これを行う1つの方法は次のとおりです。
Step 1: Create a new int column for the PK and set Identity Insert to true
Step 2: Add a new int column in your child table and then:
Step 3: write an update script like this:
UPDATE childTable C
INNER JOIN parentTable P ON C.oldEmpID = P.oldEmpID
SET C.myNewEmpIDColumn = P.myNewEmpIDColumn
Step 4: Repeat steps 2 & 3 for all child tables
Step 5: Delete all old FK columns
そのようなもので、最初に現在のDBをバックアップすることを忘れないでください;）