問題タブ [cardinality]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
554 参照

sql-server - テーブル データから主キーを解釈する

SQL Server 2008 r2 にインポートされたレガシー データベースがあります。これには、数百のテーブル (数百の列を持つものもあります) のインデックスと主キー/外部キーが含まれていません。私が手動で特定した主キー (一部は複合キー) は、通常、列の序数の上位にありますが、私ができることなら、すべてを解決するのに何週間も費やすつもりはありません。

データのカーディナリティを分析して、可能性の高い主キーを提案またはスクリプト化するために使用できるツールまたはスクリプトはありますか?

これまでのところ、次のスクリプトを見つけましたが、いくつかのエラーが発生しています。私はそれをデバッグして、何がうまくいかないかを確認しますが、誰かが同様の問題に遭遇し、何かを機能させることができたかどうか疑問に思っています.

リンクからのスクリプトテキストは以下です

0 投票する
3 に答える
4418 参照

ruby-on-rails - RubyまたはRailsに序数から基数関数はありますか?

私はキュウリを表現するより良い方法を見つけようとしているので、これを変換する序数から基数関数を探しています:

より動的なものに (行ごとに個別のステップを作成する代わりに)

ここに私のWebステップのサンプルがあります

0 と 1 がわかりますか?「最初」を基数に変換したいので、単に置き換えることができます。キュークを宣言するより良い方法を提案することもできます:)

更新された回答私はリファクタリングの最中ですが、基本的には最初の代わりに1stを使用し、その上でto_iを使用しました

0 投票する
2 に答える
777 参照

python - 長さ(/カーディナリティ)が1のセットのアイテムを削除せずに取得するPythonの好ましい方法は?

セットsが与えられた場合、以下のどのセグメントがよりよく見えますか?

また

また

最後のセグメントが最も効率的だと思いますが、実際にはループしないループを使用するのはばかげているように見えませんか?

Python セットに、項目を削除しない pop の代替方法がないのはなぜですか?

これは些細な質問のように思えるかもしれませんが、このシナリオに何度も出くわしたので、引っかき傷が必要になってきました。

0 投票する
1 に答える
331 参照

database - データカーディナリティ

私は0:Mの関係について混乱しています。

それで、それについてお聞きしたいと思います。

2つのテーブルがあると仮定します。

次のような属性を持つ連絡先:ContactID(PK)、Name

次のような属性を持つアドレス:AddressID(PK)、Desc、ContactID(FK to Contact、Nullable、Not Unique)

私の声明は正しいですか:

  • 0:Mの関係は、Contactに1つの行があり、そのContactIDがAddressに表示されない場合に発生しました。

  • 0:Mの関係を作成するには、テーブルアドレスの列ContactIDがnull可能である必要があります。

前もって感謝します

0 投票する
2 に答える
6977 参照

mysql - インデックスの NULL カーディナリティは問題ですか - MySQL 5.x

システムのライブ バージョンで、ローカルで再現できないパフォーマンスの問題が発生しています。

データベースのローカル コピーとライブ データベースのいくつかの EXPLAIN の結果を比較すると、複数フィールド インデックスがライブの一部の場所では使用されていないが、ローカルで使用されていることに気付きました。ライブではNULL。

これが問題だと思いますが、NULLカーディナリティは何を意味し、インデックスが使用されなくなりますか? オプティマイズはこれを修正しますか? また、再発を防ぐ手段はありますか? ライブ MySQL データベースへの完全なアクセス権がないため、分析と最適化は通常の機能の範囲外です。

返信ありがとうございます。

0 投票する
1 に答える
10629 参照

sql - カーディナリティとは何ですか?それはパフォーマンス(SQL Server)にどのように影響しますか?

単一の行を更新する必要がある巨大なテーブルがあります。行の主キーはわかりませんが、そのテーブル内で一意のvarchar値があります。そのテーブルには、他のいくつかの列の値もあります。

アップデートの実行には3分以上かかり、テーブル全体のスキャンを実行していると思います。

テーブルのインデックスを見ると、列のインデックスのカーディナリティはゼロで、ページ数はゼロです。テーブルの行数(数百万)に等しいカーディナリティーと数十万のページ数を持つ他のインデックスがあります。

これらの数字は実際にはどういう意味ですか?

また、フォローアップとして、カーディナリティまたはページ数が高いインデックスにヒットする制限を追加すると、実行が高速化されますか?または、変更する行をすばやく見つけるのに適したものを見つけるために、インデックスを調べることができるものは他にありますか。

0 投票する
5 に答える
6280 参照

sql - 更新ステートメントの実行に時間がかかりすぎる

Simple Update ステートメントを実行しています。実行に時間がかかりすぎます。更新とインデックスの詳細は次のとおりです。

エクスポートされた列のデフォルト値は 0 です

索引:

0 投票する
1 に答える
2103 参照

sql - SQL Server と LINQ-to-SQL で片側オプションの 1 対 1 の関係を定義する方法

User テーブルと UserInfo テーブルの間に一方のオプションである 1 対 1 の関係を作成しようとしています。仕様では、UserInfo は正確に 1 つの User を持つ必要がありますが、User は 1 つまたはゼロの UserInfo を持つことができます。また、User テーブルの列が変更されないように、UserInfo テーブルに外部キーが存在する必要があります。C# LINQ-to-SQL でリレーションシップを使用したいと考えています (例: user.UserInfo.Email = "test@test.com",userInfo.User` など)。

テーブルの T-SQL と UserInfos から Users への外部キーは (大まかに) 次のとおりです。

問題は、Users.UserId (主キー) から UserInfos.UserId への外部キーを定義すると (これは、オプションではない1 対 1 の関係を定義する正しい方法だと理解しています)、LINQ を実行することです。 -to-SQL コードuser.UserInfo = nullも を に設定user.UserIddefault(int)ます。

Usersとの間の外部キーを定義するために使用する T-SQL を次に示しますUserInfos

この外部キーを定義しないと、Userにアクセスできる LINQ-to-SQL プロパティが取得されませんUserInfoUsersテーブルとLINQ-to-SQL でトラバース可能な関係をどのように持つことができますか?UserInfos同時に、この関係をUser側から null にすることができますか? ありがとうございました。

0 投票する
1 に答える
496 参照

oop - オブジェクトの関連付けカーディナリティを適用するためのパターンとプラクティス

私は最近、SOLID、デメテルの法則、DDD などのオブジェクト指向の原則/実践/パラダイムについてよく考えてきましたが、表面化し続けているテーマは、オブジェクトのカーディナリティを強制することです。

オブジェクトの関連付けカーディナリティは、特定のエンティティを特定の数の他のエンティティ オブジェクトにのみ関連付けることを義務付けるビジネス ルールから派生します。たとえば、倉庫を管理するシステムを設計している場合、ビジネス ルールとして、1 つのアイテムを 1 つの倉庫にのみ保管できるようにすることができます。明らかに、ソフトウェア設計内でこれらのルールを強制することは、実装の問題です。

私が疑問に思っているのは、ビジネス ドメインで厳格なカーディナリティ モデルが必要な場合、それを実施する最善の方法は何でしょうか? オフハンドで考えられるテクニックには、次のようなものがあります。

  • 双方向参照- 関連付けられたオブジェクト間の双方向の関連付け (オブジェクト A はオブジェクト B を参照し、オブジェクト B はオブジェクト A を参照します)

    /li>
  • 所有エンティティをカプセル化する- 所有者がその作成と削除を制御し、実際のエンティティ実装を抽象化する一連の API を介してアクセスを提供できるようにします (オブジェクト A は渡されたエンティティ B を複製するか、渡されたスキーマに基づいてエンティティ B を作成します)。

    /li>
  • サード パーティ モニター- カーディナリティの制約を理解しているサード パーティに、オブジェクトの関連付けを適切に作成および接続してもらいます (オブジェクト C は A と B の関係を認識しており、その作成と維持を担当します。このメソッドは C のみが使用でき、クライアントは使用できません。 )

    /li>

どの技術にも長所と短所があると思います。双方向の関連付けにより、オブジェクト グラフが複雑になり、参照を更新するためのプライベート API が必要になる可能性がありますが、実装は非常に簡単で、ビジネス エンティティ クラスにビジネス制約を埋め込むことができます。所有エンティティをカプセル化すると、エンティティに値ベースの説明を強制することでドメイン モデルが複雑になる可能性がありますが、非常にクリーンです。サード パーティの監視手法は、明示的なカーディナリティの適用を別のクラスに分離しますが、ドメイン モデルも複雑にします。

誰か他の考え、アイデア、またはより良いアプローチがありますか?

0 投票する
1 に答える
1323 参照

jpa - 属性によってマップされたSpringRooカーディナリティ

AddressOneToManyマッピングを使用して、エンティティとエンティティをマッピングしようとしPersonています。「各人の住所は1つだけですが、住所には多くの人がいる可能性があります」。

Addressエンティティを(太字)でマップする方法がわかりません。JPA(EclipseLink)とSpring rooの経験はほとんどありませんが、PersonエンティティmappedBy should equal addressIDの双方向のManyToOnemappedByはpersonIDと同じである必要がありますか?