1

バーまたはイベントの所有者 (プロファイルを所有しているため管理テーブル) がユーザーにアラートを送信するデータベース設計を作成する必要があります。

「ALERT」テーブルを作成したいのですが、使用する主キーを決めるのに苦労しています。少なくとも admin_ID (PFK)、user_ID (PFK) を含む複合キーを追加することを考え、主キーに日付と時刻のスタンプを追加して、管理者が多くのアラート (通知) を送信できることを示すことを考えましたが、1 つで 1 つだけです。ある時点。
ただし、このスレッドから: Timestamp as part of complex primary key? 、タイムスタンプを使用すべきではないことを学びました。
ちなみに、どのDBソフトを使うかは現時点では決まっていません。

私は時々自動インクリメント キーにすぐに移行する傾向があります。(Access で) 問題に気付いたことはありませんが、私が読んだ限りでは、これが常に最も意味のあることであるとは限らないため、専門家に質問します。
バックエンドを根本的に正しくする正しい方法でこれを行うチャンスは 1 回しかありません。
これについてどう思いますか？

4

3 に答える 3

7

PK に何を使用するかという問題について、多くの激しい議論が行われるでしょう。純粋主義者は、自動インクリメント キーを使用すべきではないと言うでしょう (SQL SERVER を想定)。実際の塹壕にいた人は、PKとして（ほとんどの場合）まったく問題なく、いくつかの実際の利点があると言うでしょう.

何らかの方法であなたを説得しようとはしません。しかし、私の経験をお話しします。私は 25 年間ソフトウェアを開発してきましたが、その間ずっと RDBMS (主に SQL Server) を使用してきました。個人的には、自動インクリメント PK は非常に価値があり、99.99% の確率で他のものを使用することは考えません。なんで？

  1. SQL Server はそれらを生成するため、すべての同時実行の問題を処理します。
  2. サイズが小さいため、これらのキーの検索は非常に高速です。
  3. Id 値を使用して、テーブル内の特定の行を簡単に参照できます。これは大したことではないように聞こえるかもしれませんが、確かに便利です。たとえば、キー値が 12345 のテーブルの行を確認するように共同開発者に何度依頼したかわかりません。単純なことですが、非常に便利です。
  4. テーブル内の PK を参照する FK は同じタイプであるため、小さくて高速で、操作が簡単です。
  5. 特に PK が (SQL Server の) クラスター化インデックスである場合、インデックスの断片化はほとんどまたはまったくありません。

この種の PK には、大きな欠点が 1 つあります。あるデータベースから別のデータベースに行をマージする必要がある場合、PK 値の競合が発生する可能性があります。ただし、これを回避する方法もあります。また、もちろん、自動インクリメント値には真の意味はありません。しかし、それは大丈夫です。その目的は、独自性を提供することです。

これは完璧な解決策ですか？いいえ。また、他の人はそれらの使用に同意しません。しかし、それらは私にとって、ほとんどのハイエンドでビジネスクリティカルなプロジェクトで非常にうまく機能しています.

于 2012-09-12T12:04:00.693 に答える
0
  • 複合主キー自体に問題はありません
  • PK のコンポーネントのいずれかが NULLable である場合、問題があります
  • ... コンポーネントのいずれかが別のテーブル (または「ドメイン」) への FK としても機能する場合など
于 2012-09-12T12:23:47.023 に答える
0

データベースの主キーにUUID ( http://en.wikipedia.org/wiki/Universally_unique_identifier )を使用するオプションが常にあります。

すべての主要なプログラミング言語はそれをサポートしており、IMO は 1 つの選択肢ですが、効率が低いため最適ではない可能性があります。

于 2012-09-12T12:04:11.780 に答える