asp mvc と mssql を使用してクラウド Web アプリを構築しています。クライアントは同じデータベースを共有します。主キーのタイプをまだ決めていません。GUID または Bigint を使用する必要がありますか? bigint では、スケーラビリティが心配です。GUID では、パフォーマンスが心配です。ここでのベストプラクティスは何ですか? stackoverflow のような大規模なクラウド Web サイトは、主キーとして使用されますか? 光を当ててください。
ありがとう、
レイナルディ
Both have their good and bad. The real question is not about what datatype to use, but rather "in what way is the data going to be used"?
For example, if you are going to use the data in a manner where you will have millions of reads, and you require the data in the inserted order, and it makes sense to 'sort' the data in the manner that it was inserted, then perhaps an IDENTITY INT column will do. No need for BIGINT really, you can even seed your INT column with -2 billion and have potentially 4 billion records in there, and I doubt you will get there. You will not want to use int or bigint if you ever want to 'shard' or scale your table out. Especially when you use SQL Azure, which makes scaling out simple, you then would want to steer more in the direction of using a GUID.
Sure with a GUID it is not 'sorted' in the table in inserted order, but it definitely makes sense to use if you plan to scale out, or even use to join tables in other databases.
If you are going to do massive batch inserts, say 10,000 rows plus per batch, then something like an INT will be better suited, since it will avoid page splits, or keep it to a minimum rather. However, if the batch inserts happens during quiet hours, this is not an issue.
Again, SQL Server indexes are brilliant, and if you can get a proper index for your table, there is no need not to use either of them.
Indexes is a whole other kettle of fish, but since it was not part of the question, I will not attempt to answer it here, but I would spend a bit of time understanding the impact of too many/little or the wrong indexes on a table, if I were you.
Really the answer to your question is not as simple as GUID or INT/BIGINT, but rather a holistic view and understanding of your application, its usage, and how and when your table will be used. Only then can you make a decision that will best suit your table.
I hope this helps.