2

ノードと呼ばれるエンティティに新しいユーザー定義属性を許可するデータベース (mysql で使用するため) を設計しています。

これを達成するために、他に 2 つのテーブルを作成しました。すべてのカスタム属性と、1..n および n..1 の関係を作成するノードとcustomvarsの間の関係を定義する *nodes_customvars* を保持する1 つのcustomvarsテーブル。

描画されたモデルへのリンクは次のとおりです:スケッチされたデータベース モデル

これまでのところうまくいっています...しかし、テーブルごとに個別のIDを使用してINSERTとUPDATEを適切に処理できません。

たとえば、特定のノードに挿入された *nodes_customvars* テーブルにcolorというカスタム属性がある場合、「INSERT ... ON DUPLICATE KEY UPDATE」を試みると、常に挿入または常に更新されます。

*nodes_customvars* テーブルから「ID」フィールドを削除し、ノード idとcustomvars idを使用して複合キーにすることを考えましたが、これが最善の解決策であるかどうかはわかりません...

この記事とコメントも読みました: http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

これに対する最善の解決策は何ですか？

編集：

補足: *nodes_customvars* idはわかりません。nodes idとcustomvars idだけです。*nodes_customvars* テーブルの分析:

1-このテーブルでノード IDおよび/またはcustomvars IDを UNIQUE にすると、「INSERT ... ON DUPLICATE KEY UPDATE」を使用すると常に更新されます。複数のノードが同じcustomvarを共有できるため、これは誤りです。

2-UNIQUEキーを作成しない場合、「INSERT ... ON DUPLICATE KEY UPDATE」は常にINSERTになります。これは、UNIQUEキーがステートメントにまだ見つからないためです...

4

2 に答える 2

0

「INSERT ... ON DUPLICATE KEY」という特定の問題を解決するには、説明したように常に挿入または更新する2つのオプションがあります。

  1. nodeId と customvarId を使用して、プライマリを複合キーに変更します（SyntaxGoonooと質問で可能なオプションとして提案されているように）。

  2. nodeId と customvarId を使用して複合一意インデックスを追加します。

    CREATE UNIQUE INDEX IX_NODES_CUSTOMVARS ON NODES_CUSTOMVARS(nodeId, customvarId);

どちらのオプションでも、「INSERT...ON DUPLICATE KEY」機能を必要に応じて機能させることができます (nodeId と customvarId の一意の組み合わせが存在しない場合は INSERT、存在する場合は更新します)。

複合主キーを使用するか、一意のインデックスを追加した個別の主キー列を使用するかについては、設計時に考慮すべきことがたくさんあります。1NF の考慮事項と、使用しているデータベース プラットフォームの物理的特性、およびたまたま使用している ORM (存在する場合) の設定があります。InnoDB のセカンダリ インデックスがどのように機能するかを考えると ( http://dev.mysql.com/doc/refman/5.0/en/innodb-index-types.htmlの最後の段落を参照)、現在の設計を維持することをお勧めします。それを持って、追加の一意のインデックスを追加します。

HTH、

-ディピン

于 2013-06-24T13:09:57.277 に答える