問題タブ [primary-key-design]

論文を書いているとき、私は SQL データ型と、データベース構造を設計するときにそれらを賢く選択する方法についての部分を書いていました。

ベスト プラクティスとして、負の値を PK に割り当てないことをどこかで読みました。これは次の質問につながります。

SQL Server のインスタンスは、既定で主キーに負の値を割り当てますか? それらを自分で割り当てることができることは知っていますが、SQLサーバーがデフォルトでそれらを割り当てるかどうか疑問に思っていました。

Amazon DynamoDB の上にオブジェクトのスケーラブルな順序付けされていないコレクションを実装することを検討しています。これまでのところ、次のオプションが検討されています。

1. DynamoDB ドキュメント データ型 (マップ、リスト) を使用し、ドキュメント パスを使用してスタンドアロン アイテムにアクセスします。これには、コレクションが 400KB のデータに制限されるという明らかな欠点が 1 つあります。つまり、サイズにもよりますが、おそらく 1..10K オブジェクトです。あまり目立たない欠点は、そのようなコレクションに新しいオブジェクトを挿入するコストが膨大になることです。Amazon は、新しく追加されたオブジェクトだけでなく、アイテムの合計サイズに基づいて書き込み容量が差し引かれることを指定しています。サイズ制限に近づくと 1KB オブジェクトを挿入します。それで、これが除外されたと考えると？

2. 複合プライマリ ハッシュ + 範囲キーを使用します。ここで、プライマリ ハッシュはコレクション内のすべてのオブジェクトで同じままであり、範囲キーは単なるランダムまたはアトミック カウンターです。明らかな欠点は、同一のハッシュ キーを使用すると、キーの配布がうまくいかないことです。多数のオブジェクトを含むコレクションがある場合、カーディナリティが低くなります。これは、不適切なパーティショニングを意味し、同じコレクションのすべての読み取り/書き込みが 1 つのシャードにスタックされるというスケールの問題が発生し、DynamoDB パーティションの 1 秒あたり 3000 回の読み取り / 1000 回の書き込みの制限を受けることになります。

3. セカンダリ ハッシュ + レンジ キーでグローバル セカンダリ インデックスを使用します。ハッシュ キーは同じコレクションに属するすべてのオブジェクトで同じままであり、レンジ キーはランダムまたはアトミック カウンターです。上記と同様に、パーティショニングは GSI にとって不適切になり、同一のハッシュが多すぎるとボトルネックになり、プロビジョニングされたすべての容量がインデックスに急速に排出されます。GSI が正確にどのように実装されているかわかりませんでした。

問題は、私が (2) または (3) と一緒に暮らすことができ、理想的ではないキー配布に苦しむことができるかどうか、または見過ごされていたコレクションを実装する別の方法があるかどうか、またはおそらく別の nosql データベースエンジンを検討することを検討する必要があるかどうかです。

行のバージョン管理を使用して、テーブルの主キーを設計したいと考えています。私のテーブルには、ID とタイムスタンプの 2 つの主要なフィールドと、その他のフィールドが含まれています。一意の「ID」については、以前のバージョンのレコードを保存したいと考えています。したがって、テーブルの主キーを ID フィールドとタイムスタンプ フィールドの組み合わせとして作成しています。したがって、特定の ID のすべてのバージョンを表示するには、次のように指定できます。

ID の最新バージョンを返すには、次を使用できます。

最初の要素を取得します。ここでの私の質問は、ID フィールドが主キー フィールドの一部であることを考慮して、テーブル全体をスキャンして同じ ID に一致するすべてのエントリを取得する代わりに、このクエリは効率的で O(1) で実行されるでしょうか? 理想的には O(1) で結果を取得するには、主キー全体を提供する必要がありました。テーブル全体のスキャンを実行する必要がある場合、このリクエストを O(1) で実行できるように主キーを設計するにはどうすればよいでしょうか?

ありがとう、スリラム

私は DDD に関する多くの記事を読んでいて、ほとんどがデータベースに永続化するときに ID として GUID を使用していることに気付きました。GUID はスケーラビリティに優れており、自動インクリメント ID はスケーラビリティに関しては絶対にダメだと言われています。

GUIDまたはを使用するかどうか今混乱していますauto-increment。

基本的にドメインはmembership system (binary tree). (tracking of register members)

最初の要件は、システム内でそれらを一意に識別するもの (私たちはそれを と呼びますAccount No.) がおそらく 7 桁である必要があるということです。

その後Members、別の で新規登録できますMember。私たちはそれを紹介と呼んでいます。

今私が計画しているMemberIdのは、結合に使用される主キー、外部キーとして機能する DomainObject Id として GUID タイプを持つことです (Referral では、referer_id は GUID になりますMemberId)。AccountNo自動インクリメント列になるか、MAX() + 1 によってリポジトリから取得される可能性があります。主に、システム内およびリンク内の検索機能に使用されます。

DomainObject の ID は、単なる技術的な実装であるため、システムのユーザーに対して非表示のままにする必要がありますか?

両方を組み合わせても大丈夫ですか？データベースの row_id としての GUID (代理キー)。（ナチュラルキー）の自動インクリメント？

AccountNoとにかく自動インクリメントされるので、コンストラクターから除外しても大丈夫ですか? 不変条件を強制する必要性についてはどうですか? では、リポジトリから次の ID を取得AccountNoしてコンストラクターに含める方法はありますか?

Auto-Increment ID に固執し、GUID を忘れて削除MemberIdしAccountNo、DomainObject の ID にする必要がありますか?

ノート：

私はある種の次の Facebook を構築していません。

私は、DDD の戦術面を練習して、長所と短所を知った上で難しいアーキテクチャ上の決定を下す方法を学びたいと思っています。

DDD の戦略的な側面を練習して、長所と短所、およびその実装を理解した上で、難しいアーキテクチャ上の決定を下す方法を学びたいだけです。

会員登録で3つのシナリオを作る場合：

• 最初のシナリオ: メンバー登録は毎分行われます。
• 2 番目のシナリオ: メンバー登録は 1 時間ごとに行われます。
• 3 番目のシナリオ: メンバー登録は毎日最大 5 回行われます。

それは決定にどのように影響しますか？

技術スタック:

• ASP MVC 5
• SQL Server 2014
• C#
• ダッパーORM

これらのテーブルのデータは、今後大幅に増加する可能性があるため、インデックス作成戦略を検討する最善の方法について皆さんに聞いていただければ幸いです。単一テーブル アプローチでマルチテナント データを格納することで続行することにしました。たとえば、このディスカッション用のテーブルは 2 つしかありません。

• MenuTypeName はテナントごとに一意である必要があります。したがって、 TenantID と MenuTypeName に一意のインデックスを作成します。
• TenantID は Tenant テーブルを参照する必要があります。したがって、TenantID の外部キー。
• 自動インクリメント列であるMenuTypeIDに主キーまたはクラスター化インデックスを設定する必要があるかどうかをまだ考えています。
• 将来、テーブルのサイズが大きくなったときに、TenantID に基づいてデータを新しいデータベース サーバーに簡単に分割できるようになるはずです。

質問:

1. SQL Server では増分シードが保証されていることがわかっているため、MenuTypeID に主キーを定義する必要はありますか。MenuTypeID にクラスター化インデックスを定義することはできますか?
2. TenantID と MenuTypeName に一意のキーを定義します。

このアプローチを使用すると、テーブルの設計に主キーの概念がなくなります。しかし、テーブルに主キーがないことで、将来的に問題が発生する可能性があるかどうかを知りたいです。

日付ディメンションテーブルに自然キーを持つという概念を理解しようと懸命に努力しています。

ディメンション テーブルでランダムな代理キーが作成されるのを常に見てきました。20150806しかし、私は最近、自然の代理キーと比較して、ファクトテーブルからのルックアップと逆ルックアップに関して、forのような日付ディメンションで自然キーを使用すると、Aug-06-2015はるかにうまく機能し、かなりのパフォーマンスが向上することを読みintました。

それがどのようにパフォーマンスを向上させるのか理解できません。join日付ディメンションにこの派手なキーを使用したとしても、ファクトとディメンションの間にはまだ必要です。

誰かがこれについて洞察を持っている場合は、知識を共有していただけませんか。例を挙げてフォローアップしていただければ幸いです。

foo と bar の 2 つのテーブルがあるとします。どちらにも主キーがあります。foo.id と bar.id を組み合わせたセットが一意になるように、SQLAlchemy で設定したいと考えています。どうすればいいですか？

次のように、主キーのみを含み、foo と bar に外部キーを持つ別のテーブルを追加してみました。

しかし、それは私にこのエラーを与えました:

FlushError: インスタンスに NULL ID キーがあります。これが自動生成された値である場合は、データベース テーブルで新しい主キー値の生成が許可されていること、およびマップされた Column オブジェクトがこれらの生成された値を期待するように構成されていることを確認してください。また、load() イベント内など、不適切な時間にこの flush() が発生していないことも確認してください。

私がやろうとしていることに対するより良い解決策はありますか？

編集:私は sqlite db を使用しています。

「ソース」と「id」という名前の列を持つテーブルがあります。このテーブルは、オープン データ DB から入力されます。私のデータは独自のIDシステムを持つ他のデータベースからのものであるため、「ID」をUNIQUEにすることはできません。同じ ID を持っていても、実際には異なるデータを持つという実際のリスクがあります。

source と id を組み合わせて単一の値にする別の列を作成したいと思います。

|| を使用する例を見てきました。および値を連結する関数。これは良いことですが、この 3 番目の列を PRIMARY KEY にして、重複を避け、あまり計算せずにクエリでき、他のテーブルの外部キー制約として使用できる本当に一意の ID を作成したいと考えています。

探しているのは複合型だと思いますが、毎回手動で値を設定するのではなく、「source」と「id」のみを設定して自動的に取得したい

私はpostgresqlにかなり慣れていないので、どんな助けも大歓迎です。ありがとうございました。

General Number または Fixed 形式のいずれかで主キーを設定しようとしましたが、小数点を 1 桁に設定しました。別のフィールドにポインターを合わせると、値は代わりに 101.0 に変わります。10 進値を入力後に保持し、目的の 101.1 ではなく 101.0 にならないようにしたい。