エンタープライズアプリケーションでMSSQLIdentityを使用することは良い習慣ですか？ビジネスロジックの作成やデータベースの相互移行が難しくなりませんか？
8869 次
5 に答える
14
個人的には、ID列がないと生活できず、どこでも使用できませんでしたが、使用しないことを考える理由がいくつかあります。
元々、ID列AFAIKを使用しない主な理由は、データを移動するためにレプリケーションやさまざまなミドルウェアコンポーネントを使用する分散マルチデータベーススキーマ（切断）が原因でした。利用可能な分散同期機構がなかったため、衝突を防ぐための信頼できる手段がありませんでした。SQL ServerはIDの配布をサポートしているため、これは大幅に変更されました。ただし、それらの使用は、より複雑なアプリケーション制御のレプリケーションスキームにマッピングされない場合があります。
彼らは情報を漏らす可能性があります。アカウントID、請求書番号など。毎月あなたから請求書を受け取った場合、あなたが送信する請求書の数またはあなたが持っている顧客をまとめることができます。
私は顧客データベースをマージすることで常に問題に遭遇し、すべての側がまだ古いアカウント番号を保持したいと思っています。これは時々私にアイデンティティフィールドへの私の依存症に疑問を投げかけます:)
ほとんどの場合と同様に、最終的な答えは「状況によって異なります」ということです。特定の状況の詳細は、必然的に決定に大きな影響を与えるはずです。
于 2009-05-30T05:52:17.703 に答える
11
はい、それらは非常にうまく機能し、信頼性が高く、最高のパフォーマンスを発揮します。IDフィールドと非IDフィールドを使用することの大きな利点の1つは、新しいIDを予約しようとする複数の呼び出し元の複雑な同時実行性の問題をすべて処理できることです。これはコーディングするのは簡単なことのように思えるかもしれませんが、そうではありません。
以下のこれらのリンクは、IDフィールドに関するいくつかの興味深い情報と、可能な限りそれらを使用する必要がある理由を提供します。
于 2009-05-30T04:58:50.840 に答える
5
はい。
これらは通常、意図したとおりに機能し、DBCC CHECKIDENTコマンドを使用して操作および操作できます。
IDの最も一般的な考え方は、主キーの基礎となる番号の順序付きリストを提供することです。
編集：フィルファクターについて間違っていました。すべての挿入がBツリーの片側で行われることを考慮していませんでした。
また、改訂された質問で、あるDBから別のDBへの移行について質問しました。
移行が一方向のレプリケーションである限り、IDは完全に問題ありません。相互に複製する必要のある2つのデータベースがある場合は、UniqueIdentifier列が最善の策です。
参照：設計の一部としてUUIDを使用することを本当に強制されるのはいつですか？データベースでUUIDをいつ使用するかについての議論。
于 2009-05-30T04:27:59.387 に答える
5
問題は常に：
あるデータベースから別のデータベースに現実的に移行する可能性はどのくらいありますか？マルチデータベースアプリを構築している場合、それは別の話ですが、ほとんどのアプリは、特にSQL Serverのような堅牢なもので開始する場合、新しいデータベースの途中に移植されることはありません。
ID構造は優れており、使用すべきでない理由はほとんどありません。興味があれば、アイデンティティの価値を取り巻く一般的な神話のいくつかについてブログ記事を書きました。
于 2009-05-30T05:01:12.210 に答える
1
アイデンティティに関する優れた記事、http：//www.simple-talk.com/sql/t-sql-programming/identity-columns/
IMO、別のRDBMSへの移行が最近必要になることはめったにありません。必要な場合でも、ポータブルアプリケーションを開発する最良の方法は、アプリケーションを独自の機能から分離するストアドプロシージャのレイヤーを開発することです。
于 2009-05-31T21:51:51.890 に答える