問題タブ [cardinality]

たとえば、と列を持つテーブルがあるcity場合state、インデックスを使用するための最良の方法は何ですか？

明らかcityにカーディナリティが最も高くなるので、その列をインデックスの最初に配置する必要がありますか、状態を配置する必要がありますか、それともそれほど重要ではありませんか？

mysqlを使用してテーブル間の関係のカーディナリティを見つけなければならないという問題で立ち往生しています。この投稿に続いて
MySQL：プログラムで外部キー関係を決定する方法は？
私のテーブルと外部キーである列に関連するすべてのテーブルを見つけました。今、私はまた、関係のカーディナリティ、すなわち、1対1、1対多、または多対多を見つけたいと思っています。任意のアイデアやスニペットをいただければ幸いです

カーディナリティとは何かを理解しているので、説明しないでください;-)

カーディナリティを実行する目的がデータモデリングで何であるか、そしてなぜ私が気にする必要があるのか​​を知りたいです。

例：ERモデルでは、関係を作成し、関係にカーディナリティを追加します。開発プロセスでカーディナリティをさらに使用するのはいつですか？カーディナリティを気にする必要があるのはなぜですか？

たとえば、ERモデルを完成させた後、カーディナリティをどのように、いつ、どこで使用しますか。

ありがとう ：-）

図を説明します。

2 つのエンティティ: E1 & E2

カーディナリティ:

-E1 から E2 へ (リレーション R 経由): (6,50)

-E2 から E1 へ (リレーション R 経由): (3,5)

カーディナリティを強制することになっていますが、この本では ASSERTION の詳細についてはあまり掘り下げていません。これは、カーディナリティを強制する正しい方法でしょうか?

急速に成長している 1,800 万行を超えるテーブルがあります。

datetime 列 (数百万の一意の値)、intColumn 1 (約 40,000 の一意の値)、intColumn 2 (約 3,000 の一意の値)、および intColumn 3 (1,000 の一意の値) に複合インデックスを作成しました。

インデックスのカーディナリティは 197 になりました。

私はこれに本当に混乱しており、何か間違ったことをしたのか、それとも欠けているものがあるのでしょうか。このインデックスは役に立たないようです。

私はデータベース開発を勉強しており、独自の ER モデルを作成しなければならない段階にあります。StarUML ではこれまでのところすべて問題ありませんが、コース ノートには、エンティティ タイプ (カーディナリティと参加) 間に多重度オプションを追加する方法については言及されていません。

誰かがここで私を助けてくれることを願っていますか?

どうもありがとうピーター

PDO を使用して次のクエリを生成しています。

このクエリはループ内で生成されるため、そのprint_r($query);部分を取得してここに貼り付けました。

次に、私のPHPには、次のようなパラメーターをバインドするループがあります。

次のエラーが表示されます。

私のテーブル定義は次のようになります。

誰でも私を助けることができますか？

現在、レガシー MySQL データベースに基づいて新しい Grails アプリケーションを作成しようとしています。アプリケーションは情報を読み取るだけです。具体的な DB スキーマは、特定のドメイン クラスに対して、クラス階層構造ごとのテーブルと、これらのクラスに必要な新しい情報を追加するためのプロパティ クラスを使用します。

現在、 のプロパティ情報を取得できませんtransation。例外はありませんが、私もフィールドにアクセスできませんproperties。私が直面する可能性のある問題の 1 つは、単語propertiesが Grails のドメイン フィールドのキーワードであるということです。しかし、特定の従来のテーブルの命名のために、それを使用する必要があります。

レガシー テーブルの名前はtransactionおよびtransaction_propertiesです。複数transcation持つことができますtransaction_properties。transaction_id関連付けは、テーブル内のキーを介して行われtransaction_propertiesます。

テーブルトランザクション

テーブルtransaction_properties

ドメイン クラストランザクション

ドメイン クラスTransactionProperty

2 つのエンティティ間に親子関係があるスキーマがあります。これは一対多なので、当然次のように実装されます。

ただし、子の 1 つを特別なケースとして扱う必要もあります (「昇格した」子と呼びましょう)。これを行うには、次のようないくつかの方法が考えられます。

に属性を付けるだけですChildren：

データベースが一貫性を保証できないという点で、明らかに欠陥があります（少なくとも通常の外部キー制約では）

Parentsテーブルに外部キーを作成します。

これは私の最初の傾向でしたが、循環依存という明らかな欠点があるため、おそらく最適ではありません。

Children私が考えることができる別のオプションは、テーブルに2番目の外部キーを置くことです:

これにより、一意のインデックスを配置できるため、データベースの一貫性が確保されます。これに関する 1 つの問題は、親 A の子が親 B の昇格としてリストされるという、無意味な関係を持つ可能性があることです。

私が考えることができる最後のオプションは、中間テーブルを作成することです。

繰り返しになりますが、parent_id+is_promotedに対して一意の制約を宣言して、一貫性を確保できます。関係を完全なエンティティに昇格させるのはやり過ぎのように思えるので、私はこれについて少し曖昧ですis_promoted.

この問題を処理する標準的な方法について、あなたがどう考えるか知りたいです。特に私はRailsを使っているので、何が最も現実的な解決策であるかに影響するかもしれません。

MySQLテーブルにエントリが追加されると、どのインデックスの更新に時間がかかるのか疑問に思いました。カーディナリティが高いインデックスまたはカーディナリティが低いインデックス。

原則ですか？