問題タブ [surrogate-key]

Railsを使用して新しいアプリを作成しているので、すべてのテーブルにid列があります。外部キーを使用してドメイン制約を適用するためのベストプラクティスは何ですか？私の考えと欲求不満の概要を説明します。

これが私が「TheRailsWay」として想像するものです。それは私が始めたものです。

これに伴う問題は、ある会社の製品が別の会社の請求書に表示される可能性があることです。LineItemsに（company_id：整数、nullではない）を追加しました。これは、自然キーとシリアルのみを使用する場合と同じように、複合外部キーを追加しました。

これにより、LineItemsは単一の会社に適切に制約されますが、過剰に設計されており、間違っているように見えます。LineItemsのcompany_idは、代理外部キーが外部テーブルですでに一意であるため、無関係です。Postgresでは、参照される属性に一意のインデックスを追加する必要があるため、idは単純に一意ですが、Products and Invoicesの（id、company_id）に一意のインデックスを作成しています。

参照される列はすでに自然キーであり、一意のインデックスがすでにあるため、自然キーとシリアル請求書番号を含む次の表では、このような複雑さは増していません。

LineItemsテーブルの代理キーは無視できますが、これも間違っているようです。使用する整数がすでにあるのに、なぜデータベースをcharで結合させるのですか？また、上記とまったく同じように行うには、製品と請求書に自然外部キーであるcompany_codeを追加する必要があります。

妥協...

他のテーブルに自然外部キーは必要ありませんが、使用可能な整数がある場合は、charで結合されます。

スキーマとインデックスを複雑な混乱に変えることなく、神が意図したような外部キーを使用してドメイン制約を適用するクリーンな方法はありますか？

FactTableにディメンションテーブルへの12回のルックアップを入力してSKを取得しました。そのうち、6回は異なるDimテーブルへのルックアップで、残りの6回は同じ自然キーへのルックアップを行う同じDimTable（タイプII）へのルックアップです。

元：

PrimeObjectID=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

同じことをする他の列を取得しました

OtherObjectID1=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID2=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID3=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID4=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID5=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

このような複数のルックアップの場合、SSISパッケージでどのように処理する必要がありますか。

今のところ、lookup /unionallforeachルックアップを使用しています。これにもっと良い方法はありますか？

まず、PostgreSQLデータベースの永続性プロバイダーとしてJPA2.0とHibernate3.5を使用しています。

JPA 2.0アノテーションを介してデータベースのシーケンスを単一フィールド代理キーの自動生成値として正常に使用し、すべて正常に機能します。

現在、次の方法で混合キーを必要とするバイテンポラルデータベーススキームを実装しています。

今、問題があります。ご覧のとおりINSERT、新しい要素の場合、フィールドidは自動生成され、問題ありません。UPDATEただし、このスキーム内のフィールドが必要な場合はvalidTimeBegin、-fieldを変更せずに列を変更し、id次のように新しい行として挿入する必要があります。

行の更新前：

正確に2010-05-01-10：35：01.788サーバー時間に発生する行の更新後：

したがって、私たちの問題は、フィールドに自動生成されたシーケンスを使用すると、これがまったく機能しないことですid。新しい行を挿入すると、idは常に自動生成されますが、実際には複合キーの一部であり、動作する場合があります。別の方法で。

だから私の質問は：id同じ人の新しい品種を生成し、他のすべての場合に通常どおり続行したい場合に、JPAを介して休止状態にフィールドの自動生成を停止するように指示する方法はありますか？カスタムコードでID生成全体を引き継ぎますか？

よろしくお願いします、ジェラルド

オブジェクトAには1対多の関連付けがあります：多くのオブジェクトB。

データベースを見ると、名前を確認するために代理整数識別子を常に結合または副選択するのではなくTableB、一意で読み取り可能な文字列を確認したいと思います。A.Name

Nameの識別子としてマップできますが、NHibernateはのインスタンスが一時的であるか永続的であるかを識別できないためA、これにより多くの余分なクエリが発生します。SELECTA

ネイティブに割り当てられた代理キーと自然キーを組み合わせて、複合キーを使用できると思います。これは最適ではないようですが、いくつかの意見を聞きたいと思います。

私が本当に探しているのは、NHibernateが一時的なインスタンスを識別できるようにしながら、単一列の自然キーを使用するための戦略です。

• 出来ますか？
• マッピングとは何ですか-流暢またはhbm？

一方、これがすべてひどい考えであり、副選択を含むデータベースビューに依存する必要がある場合は、説明してください。

ありがとう。

どちらがベストプラクティスであり、その理由は何ですか？

a）タイプテーブル、サロゲート/人工キー

外部キーはfromuser.typeからtype.id：

b）タイプテーブル、自然キー

外部キーはfromuser.typeからtype.typeName：

私のテーブルスキーマは次のようなものです

1.マスターテーブル：条項

列

1. ClauseID =サロゲートpk（ID）
2. ClauseCode=nvarcharユーザー指定値
3. Class =nvarcharFKからマスタークラステーブルへ
4. 等...

ClauseCode +Class=このテーブルの候補キー

2.マスターテーブル：GroupClause

列

1. GroupClauseID =サロゲートpk（ID）
2. GroupClauseCode=nvarcharユーザー指定値
3. Class =nvarcharFKからマスタークラステーブルなどへ。

GroupClauseCode +Class=このテーブルの候補キー

3.トランザクション/マッピングテーブル::GroupClause_Clause_Mapping：このテーブルは、各グループ句を複数の個別の句にマッピングします

列

1. GroupClauseID=FKからGroupClausePK
2. ClauseID=FKからClausePK
3. 等...

要件：各Group句は、それ自体と同じクラスに属する句にのみマップできます。

問題：上記のテーブルデザインは、DBレベルでその要件を強制しません。

考えられる解決策の1つ：テーブル*GroupClause_Clause_Mapping*には列があります

1. ClauseCode
2. GroupClauseCode
3. クラス

ここで、ClauseCode + Class as FKtoclauseテーブルとGroupClauseCode+Class as FKtoGroupClauseテーブルを作成できます。

ただし、この方法で行うと、代理IDキーは役に立たなくなり、それらを削除した方がよい場合があります。

代理キーを使用したデザインに問題はありますか？

代理キーを使用し、DBレベルで制約を適用する方法に関する提案はありますか？

プレーン整数の代わりにハッシュを代理キーとして使用するアプリケーションがたくさんあります。このようなデザインの理由はわかりません。

ほとんどのUUID実装はハッシュされたタイムスタンプであるとすると、なぜ多くのデータベース設計者がアプリケーション全体の代理キーにそれらを選択するのでしょうか。

私は2つのテーブルを持っています:

データベースのエントリは次のようになります。

書類：

セクション：

DocumentDOC_ID に生成された Id があり、SectionDOC_ID と SECTION_NUM に複合主キーがあります。

SECTION_NUM は、ローカル (アプリケーション) で生成されたシーケンス番号で、ドキュメントごとに新たに開始されます。

私のエンティティクラスは次のようになります。

新しいドキュメントと関連するセクションを挿入するときは、次のようにします。

永続化すると、列 SECTION_NUM に NULL は許可されていないという例外が発生します。私は OpenEJB (単体テストのために舞台裏で OpenJPA に依存している) を使用しており、OpenJPA コードをステップ実行すると、Document オブジェクトが正常に永続化されることがわかりましたが、Section オブジェクトになると、新しいインスタンスが反射的に作成され、すべてが設定されます。 fields が null に設定されるため、sectionNum の値が失われ、Document オブジェクトにリンクする前に保持されます。

残念ながら、レガシー システムであるため、DB スキーマを変更することはできません。誰かが似たようなことをして、それを機能させましたか?

IDを作成して保存するためのベストプラクティスは何であるか疑問に思いました。数年前、教授は、社会保障番号を例として使用して、不十分に構築されたIDシステムの危険性について私に話しました。特に、SSNにはエラー検出機能がないため、9桁の文字列と有効なSSNの違いを区別することはできません。そして今、政府機関は、データを追跡し、その検証を確実にするために、姓+SSNや誕生日+SSNなどを必要としています。さらに、あなたの社会保障番号は、あなたが生まれた場所に基づいてある程度予測可能です。

今、私はユーザーデータベースを構築しています...そしてこのアドバイスに基づいて、「useridmediumintauto_increment」は受け入れられないでしょう。特に、このIDをユーザーのプライマリIDとして使用する予定の場合。（たとえば、ユーザーにユーザー名の変更を許可した場合、ユーザー名は数値のユーザーIDよりも追跡が難しくなります...カスケード外部キーなどが必要になります。）電子メールの変更、ユーザー名の変更、パスワードの変更。 。ただし、ユーザーIDは永久に一定である必要があります。

明らかに、auto_incrementはsurrogate_keys用にのみ設計されています。つまり、プライマリ識別メカニズムがすでにある場合にのみ便利なショートカットですが、データの「固有の識別子」として使用しないでください。ランダムなUUIDを作成することは面白そうに見えますが、ランダム性は私をオフにします。

そして、私は尋ねます：「主キー」識別番号を作成するためのベストプラクティスは何ですか？

C＃/。NET WinForms/Desktopアプリケーションにセキュリティを追加する必要があります。OracleDBバックエンドを使用しています。

テーブルは単純です：User（ID、Name）、Role（ID、Role）、UserRole（UserID、RoleID）。

Windowsアカウント名を使用してユーザーテーブルにデータを入力しています。今のところ、ロールテーブルは単に「Admin」、「SuperUser」、「BasicUser」になります。

2人が同じWindowsアカウント名を持つことは不可能だったので...これらの名前管理を制御していなくても（netopsは制御しているので、Windowsアカウントを使用したいので、管理する必要はありません;））。ロールテーブルの場合、重複値を設定することはできません。入力を制御します。入力は3つだけです（戦術アプリは1年以内に廃止されます）。UserRoleは、ユーザーとロールの多対多の関係を表す結合テーブルであるため、サラグキーは正当化されません。

簡単な質問-ユーザーとロールのテーブルで「ID」（int）を気にするのはなぜですか？ここで何かポイントや利点はありますか？これは「私はいつもこのようにしてきた」タイプのものの1つですか？それとも、しばらくの間これを行わず、理由を忘れたことがありますか？