7

私の質問の最初の部分に関して: 私は最近、リレーショナル データベース内の特定のテーブルに一意の識別子を持つことの利点とトレードオフは何かを自問していました。例として、Facebook (FB) Graph API を使用すると、同じ URL を使用して「ユーザー」、「イベント」、「ページ」などのさまざまなタイプのオブジェクトをフェッチできます。たとえば、https://domain/251906384206はhttps://domain/195466193802264は「グループ」タイプのオブジェクトを返しますが、タイプ「イベント」のオブジェクト。

https://domain/event/251906384206またはhttps://domain/group/195466193802264のように使用される「一般的でない」API を提供する場合と比較して、このアプローチの利点は何ですか。この場合、各オブジェクト タイプには独自の識別子スコープがあるため、同様の識別子が異なるオブジェクト タイプに使用される可能性があります。

質問の 2 番目の部分について: グローバルに一意の識別子を実装するためのオプションは何ですか?

私の頭に浮かぶ2つのオプションは次のとおりです。

  1. 継承ベースのアプローチ (クラスごとのテーブル、単一テーブルなど) の使用。クラスごとのテーブル アプローチが使用されていると仮定すると (スーパー テーブルには一意の識別子が主キーとしてのみ含まれ、オブジェクト タイプを表すサブ テーブルにはスーパー テーブルと同じ識別子と追加のデータが含まれます)、スーパー テーブルとサブ テーブルの間に結合が必要であり、スケールが大きくないように見えます。スーパーテーブルがボトルネックになるから？

  2. 以下を含む 3 列のテーブルを提供する

    • 一意の識別子、
    • オブジェクト タイプ固有の主キー、および
    • テーブル名。

    一意の識別子を外部キーとして参照する列を含む、オブジェクト タイプごとの追加のテーブル。各オブジェクト タイプ固有のテーブルには、独自の主キー スコープがあります。

どちらのアプローチでも、前述の FB API のような汎用 API を提供できます。2 番目のアプローチでは、オブジェクト テーブル固有の主キーを内部で使用し、グローバルに一意の識別子のみを公開できます。ただし、グローバル一意識別子が内部で使用される可能性がある場合、2 番目の方法でも結合が必要になります。

グローバルに一意の識別子の長所と短所に関する経験はありますか?それを実装するためのベスト プラクティスは何ですか?

4

2 に答える 2

0

グローバル識別子を実装する提案された方法はどちらも、大きなテーブルの結合と、データベース内のレコード数の効果的な倍増を伴います (各オブジェクトは独自に存在しますが、グローバル ID を持つ親/レコードもそうです)。

アプリケーション/データ アクセス層でグローバル ID を強制する方がよいと感じています。これは、特定のタイプのオブジェクトごとに ID が可能な ID のサブセットのみから取得されるように強制することで簡単に実行できます。たとえば、オブジェクト タイプを指定するために、すべての ID の最後/最初の x ビットを予約できます。ID の残りの部分は、「実際の ID」になります。

特定のテーブルに ID を割り当てる際のエラーが心配な場合は、ID が正しいことを強制するチェック制約を追加できます (例: ID < 4000 AND ID > 10000)。識別子でオブジェクトのタイプのために無駄になっているビット/バイトが気になる場合は、データベース アクセス API でのみグローバル ID を公開できます。オブジェクト型から派生)。

于 2011-03-28T03:55:34.887 に答える
0

「よく述べられた問題とは、すでに半分解決された問題である」.

あなたはいくつかの概念を混ぜ合わせているように私には思えます。他のデータベース アプリをチェックしますが、情報を得るどころか混乱してしまったようです。

クラスの異なる複数のオブジェクトがあり、それらをデータベースに格納する方法を知りたいと考えています。これは、通常、オブジェクト リレーショナル マッピング (ORM) の「派手な名前」によって呼び出されます。

さらに、Global Unique Identifier (GUID) を使用して、オブジェクトをビジネス/プログラミング オブジェクトとテーブル内の行の両方として識別したいと考えています。

さらに、GUID を使用して、特定の種類のクラスまたはオブジェクトを識別したいと考えています。

アプリを構築しているとしましょう。いくつかのオブジェクトがある場所。「Users」、「Events」、「Pages」など、オブジェクトにはいくつかのクラスがあります。同じクラス/タイプのオブジェクトを複数持つことができますが、それぞれを識別する方法が必要です。ミシガン州の「John Doe」を特定するには、クイーンズランド州の「John Doe」から。オブジェクトがタイプ GUID のプロパティを使用するとします。

したがって、各クラスのテーブルを作成すると仮定しましょう (「ユーザー」の場合は「ユーザー」、テーブルの標準 ID は単数形で小文字です。無視してもかまいませんが、「イベント」の場合は「イベント」など)。各テーブルには、各オブジェクトのプロパティを表すいくつかのフィールドがあります。したがって、「user」には「user_key GUID」のようなフィールドがあり、おそらく「user_name varchar(100)」と「user_birthdate datetime」があります。他のテーブルも同様です。

「supertable」を使用しましたが、一般的なアプリではなく、非常に具体的なアプリのみに使用しました。「ユーザー」、「イベント」、「ページ」を混在させるテーブルは必要ないと思います。スーパーテーブル「顧客」に加えて、特定の追加フィールドを持つ「会社」および「個人」サブテーブルがある場合がありました。時々、すべての顧客の売上を確認し、「顧客」テーブルと結合する必要がありました。時には、製品の法人割引を提供し、「会社」サブテーブルをブラウズする必要がありました。

この一般化/「IS a」スーパーテーブルが必要な場合は、スーパーテーブルの主キーと詳細テーブルの主キーに別のフィールドを用意する必要はなく、同じタイプにすることができます。

複合/複合キー (「マスター キー」と「その他の」フィールド) の使用は絶対に避け、単一フィールドの主キーを使用することをお勧めします。データベースではなく、プログラミングを使用して GUID キーを割り当てることもお勧めします。

GUID は、整数キーよりも多くのメモリとディスク領域を使用しますが、複製が非常に困難なキーを非常に高速かつ簡単に取得できます。

繰り返しになりますが、質問は、GUID の使用法よりも、データベース内のオブジェクトを表現する方法の方が重要です。

于 2011-03-10T16:26:11.253 に答える