問題タブ [surrogate-key]

データベースタイプ：mysql

列：日付、時刻、price1、qty1、price2、qty2の時刻は、1か月のレコード数が約550万ミリ秒になります。

日付は一意ではないため、主キーとして選択することはできませんが、日付と時刻を組み合わせて選択することはできますが、それもお勧めできません。

「この日時」と「その日時」の間で価格と数量の選択などのクエリを実行すると、結果は数百万の範囲になる可能性があります。

主キー、インデックス、および代理キーに関して最良の選択となる可能性があるものと、これを実装するための最良の方法は何ですか。データベースをどのように最適化する必要がありますか。

2つの異なるフォーラムのような異なるデータソースからのスレッドと投稿を保存する巨大なデータベースを持っているというイメージ。データソースごとに、エンティティのID（ThreadId、PostId ...など）は一意ですが、別のデータソースによって取得されたエンティティのIDと衝突する可能性があります。たとえば、forum1とforum2の両方にThreadid=1のスレッドを含めることができます。

Linq2Sqlとリポジトリパターンを使用して、アプリケーションをデータベースに接続しています。Linq2Sqlを使用するときは、複合キー（ThreadIdとDatasourceIdの間）を避ける必要があることを読みました。したがって、代理主キーが私の唯一の選択肢だと思います（そうですか？）：

テーブルスレッド：

• UniqueId-int、PK
• DatasourceId-int
• ThreadId-int
• ..。

テーブル投稿：

• UniqueId-int、PK
• DatasourceId-int
• PostId-int
• ThreadId-int、FKからThreads.ThreadId

さて、私の質問は次のとおりです。Linq2Sqlは、生成されたクラスの投稿とスレッドの間の1：1の関係をマッピングできますか？投稿にThread.ThreadIdへの外部キーがあり、同じThreadIdを持つ2つのエンティティがある場合（もちろん、異なるDatasourceIdがある場合）はどうなりますか？これにより、投稿に割り当てられたスレッドのコレクションが返されると思いますが、これは望ましくありません。どういうわけか、同じDatasourceIdを共有する投稿ごとに1つのスレッドを返すことはできますか？

ユーザーがシステム内のさまざまなもののリストを作成できるようにするリストタイプを構築しています。したがって、リスト要素は、それらが指し示すものの型と識別子の両方への参照を必要とします。

たとえば、ユーザーが製品のリストを作成できるようにします。したがって、リスト要素は、製品を保持していることを知る必要があり (製品テーブルを調べます)、製品 ID が必要です。

リストが保存するものの一部には、数値以外の識別子があります。

では、id/type ペアをリスト要素に入れる必要がありますか、それとも id/type ペアの代理キーを単純な int として作成する新しいテーブルを作成し、それを使用する必要がありますか?

代理キーは、キー ペアを取得するために追加のルックアップ/結合を必要としますが、2 つの列をリスト要素テーブルにマッシュする必要はありません。

Oracle のストアド プロシージャで使用されるいくつかの中間テーブルの代理 ID キーを作成する必要があります。UROWID 列に挿入された ROWID はうまく機能することがわかりましたが、これは古いバージョンの Oracle (10g より前) では正しい方法ではありません。SEQUENCE.NEXTVAL を使用するのは正しい方法です。SEQUENCE.NEXTVAL は 2 ステップのプロセスであり、メモリ/ストレージ (フル テーブル スキャン) を使い果たしますが、ROWID の方法ではアドレスを保存するだけで完了です。(SQL の IDENTITY のように)
ID キーとして ROWID を使用したい。これを行ってもよろしいですか？

（悪い英語でごめんなさい）

モデルA、B、Cがあるとします。各モデルには1つのアドレスがあります。

「SQLアンチパターン：データベースプログラミングの落とし穴の回避」（第7章-ポリモーフィックアソシエーション）には、「共通スーパーテーブル」（ベーステーブルまたは祖先テーブルとも呼ばれます）を使用してこのようなアソシエーションを回避するレシピがあります。

多形的には、次のようになります。

交差テーブルを使用できることは知っていますが、次のソリューションはより洗練されているように見えます。

A、B、CをAddressに多態的に関連付ける代わりに、レシピでは、idフィールド（代理キーまたは疑似キー）のみを持つスーパーテーブル（Addressing）を作成することを提案しています。次に、他のテーブルはアドレス指定を参照します。そうすれば、「外部キーによるデータベースのデータ整合性の強制に頼ることができます」と著者は言います。したがって、次のようになります。

SQLクエリは次のようになります。

質問は次のとおりです。Railsでそのようなシナリオをコーディングする方法は？私はいくつかの方法で試みましたが成功しませんでした。

MySQL で e コマース Web アプリケーションを設計しようとしていますが、ユーザー テーブルの正しい主キーの選択に問題があります。与えられた例は、説明のための単なるサンプル例です。

ユーザーテーブルには次の定義があります

主キー候補列で次の問題に直面しています。

ID列

長所

• ビジネス上の意味なし (安定した主キー)
• テーブル結合の高速化
• コンパクターインデックス

短所

• 「自然な」キーではない
• すべての属性テーブルは「マスター」ユーザー テーブルと結合する必要があるため、非結合の直接クエリは実行できません
• 「自然な」SQL クエリが少なくなる
• 情報漏えい: 開始値が 0 の場合、ユーザーは登録済みユーザーの数を知ることができます (開始値を変更すると、これが整理されます) ii) ユーザーは、プロファイルを time_X に user_A として登録し、しばらくしてから time_Y に user_B として登録できます。期間中の登録ユーザー数を計算する ((user_B の ID) - (user_A の ID)/(time_Y - time_X))

メール欄

長所

• なし

短所

• ユーザーは電子メール アドレスを変更できる必要があります。主キーには適していません

ユーザー名列

長所

• 「自然な」主キー
• テーブル結合が少ない
• よりシンプルで「自然な」クエリ

短所

• テーブルを結合するときに varchar 列が遅くなる
• varchar 列のインデックスは、int 列のインデックスよりコンパクトではありません
• 外部キーは値に依存するため、ユーザー名を変更するのは非常に困難です。解決策: アプリケーションのすべての外部キーを「同期」するか、ユーザーがユーザー名を変更できないようにします。たとえば、ユーザーはプロファイルを削除して新規登録する必要があります。

external_customer 列

長所

• 顧客の外部参照として使用でき、情報を保持しません (代わりに、編集不可能なユーザー名を使用できますか?)

  短所

• 自動増分の場合、情報が漏洩する可能性があります (可能であれば)

• MySQL innodb エンジンは同じテーブルに複数の auto_increment カラムを持たないため、自動インクリメンタル サロゲート ID がすでに使用されている場合、一意の値を生成するのに問題があります。

スケーラブルな e コマース Web アプリケーションのユーザー テーブルの主キーを選択する際の一般的な方法は何ですか? すべてのフィードバックに感謝

UUID.randomUUID() のような一意のサロゲート文字列を生成する方法はありますが、文字のみを含みます (数字がないことを意味します)? 文字列は異なるホスト上の複数のデータベースに格納され、システム全体で一意である必要があります (2 つのキーを同時に生成した場合でも、つまりスレッドによって)。

自然主キーと代理主キーの戦いについて多くの記事を読みました。ユーザーがコンテンツを作成したテーブルのレコードを識別するために代理キーを使用することに同意します。

しかし、テーブルをサポートする場合、何を使用すればよいですか？

たとえば、架空のテーブル「orderStates」では。このテーブルの値は編集できません（ユーザーはこの値を挿入、変更、または削除できません）。

自然キーを使用する場合、次のデータがあります。

代理キーを使用すると、次のデータが得られます。

次に例を見てみましょう。ユーザーが新しい注文を入力します。

自然キーを使用する場合、コードで次のように記述できます。

代わりに、追加の手順があるたびに代理キーを使用します。

注文を新しいステータスに移動する必要があるたびに、同じことが起こります。

それで、この場合、一方のキータイプともう一方のキータイプを選択する理由は何ですか？

正規化がどのように機能するかを正確に理解し、それを特定のプロジェクトに適用しようとしています。最初のステップは候補キーを定義することであるといくつかのビデオで見ました。

私が持っているフィールド (またはこれらのフィールドの組み合わせ) がどれも一意でない場合はどうなりますか? たとえば、Receiver というフィールドがあります。しかし、それが繰り返されることはわかっています。Time_Of_Week という名前のフィールドと組み合わせることを考えましたが、このフィールドも毎週繰り返されます。最後に、フィールド Week_Number と組み合わせることを考えましたが、このフィールドも毎年繰り返されます。

自動インクリメント主キーを定義する唯一の解決策はありますか?

ありがとうございます。

4 つのディメンション テーブルと 1 つのファクト テーブルを含むデータ ウェアハウスの設計があります。

• dimUser id、電子メール、firstName、lastName
• dim住所 ID、都市
• dimLanguage id、言語
• dimDate id、startDate、endDate
• factStatistic id、dimUserId、dimAddressId、dimLanguageId、dimDate、loginCount、pageCalledCount

私たちの問題は次のとおりです。統計の計算 (userId、日付範囲に応じて) と外部キーの入力を含むファクト テーブルを作成したいと考えています。

しかし、自然キーの使用方法を理解していないため、方法がわかりません (私たちが読んだ文献によると、これが問題の解決策のようです)。

自然キーは、ディメンション データを計算するすべての ETL ジョブで必要とされる userId になると思います。

しかし、多くの困難があります:

• ETL ジョブ load() では、重複を削除するために INSERT IGNORE INTO を使用して一括挿入を行います => 生成された代理キーはわかりません
• メタ データ (dimension_name、surrogate_key、natural_key のセットを含む) を作成すると、重複排除のために機能しません。

問題は、重複排除戦略にあるようです。より良いアプローチはありますか？

違いがある場合は、MySQL 5.1 を使用しています。