現在のプロジェクトで、マスター DB スクリプトに出会いました。よく見てみると、元の主キーはすべて数値型 (38,0)で あることがわかりました。現在、プライマリ DB プラットフォームとして SQL Server 2005 を実行しています。
少し説明すると、バックエンドとして Oracle と SQL Server の両方をサポートしています。Oracle では、主キーのデータ型は数値 (38,0) です。
そのような実装の可能性のある副作用とパフォーマンスへの影響を知っている人はいますか? 私は常にintまたはbigintを主キーとして提唱し、実装してきました。
まあ、実際には決して到達できない数値を保存するために、より多くのデータを費やしています.
bigint は 8 バイトで 9,223,372,036,854,775,807 になります
int は 4 バイトで最大 2,147,483,647 になります
NUMERIC(38,0) は、正しく計算すると 17 バイトになります。
大きな違いではありませんが、データ型が小さい = メモリ内の行数が多い (または行数が同じ場合のページ数が少ない) = ルックアップ (インデックスまたはデータ ページのシーク) を行うためのディスク I/O が少なくなります。レプリケーション、ログ ページなどについても同様です。
SQL Server の場合: INT は IEEE 標準であるため、CPU で比較しやすいため、INT と NUMERIC (パック 10 進形式) を使用すると、パフォーマンスがわずかに向上します。(Oracle では、現在のバージョンが私が育った古いバージョンと一致する場合、すべてのデータ型がパックされているため、内部の INT は NUMERIC( x,0 ) とほとんど同じであるため、パフォーマンスの違いはありません)
したがって、大まかに言えば、大量のディスク、RAM、および予備の I/O がある場合は、必要なデータ型を使用してください。もう少しパフォーマンスを上げたい場合は、もう少し控えめにしてください。
そうでなければ、この時点でそのままにしておきます。物事を変える必要はありません。
ストレージに関する考慮事項と将来のDBAによる最初の混乱を除けば、NUMERIC（38,0）が悪い考えになる理由はわかりません。テーブルには最大9.99x10 ^ 38のレコードを許可していますが、これは絶対に到達することはありません。私がこれをすばやく掘り下げても、それを使用しないという明白な理由は見つかりませんでした。あなたの唯一の潜在的な問題はそれによって消費されるストレージスペースであると思いますが、ストレージスペースがいかに安いかを考えると、それは問題ではないはずです。
これは、SQL ServerでデフォルトでINTまたはBIGINTを使用するのと同様に、テーブルを作成するときに考慮する必要のない非常に大きなデフォルト値であるため、Oracleデータベースでかなりの回数見ています。
これほど多くの行が存在することはないため、これは大きすぎます。サイズが大きいほど、より多くのストレージスペースが得られます。これ自体は大したことではありませんが、テーブルまたはインデックスからデータを取得するためのディスク読み取りが増えることも意味します。これは、データベースサーバーのメモリに収まる行が少なくなることを意味します。
修正に煩わされるほど壊れているとは思いません。
GUID を使用したほうがよいでしょう。本当。これを使用しない通常の理由は、整数の方がパフォーマンスが優れているからです。ただし、GUID は数値 (38) よりも小さく、切断されたユーザーが新しいレコードを作成して同期できるようにするなどの操作が少し簡単になるという追加の利点があります。