2

私はこのDBモデルを持っています：

DBモデル

（TEXT実際にはVARCHAR）

entity_group_type実行時に変更することはできませんが、近い将来、開発チームによってエントリを数回追加するように変更される予定です。

entity次に、指定されたからすべてのエントリを取得する必要がありますentity_group_type。ソフトウェアはこの種のクエリをどのように処理する必要がありますか？ソフトウェアでentity_group_type _id/をハードコーディングする必要がありますか？nameもしそうなら、なぜ私はこのテーブルが必要なのですか？そして、何が良いですか、ハードコード_idまたはname？

それとも、これは私のデータを構造化する間違った方法ですか？

前もって感謝します！

4

3 に答える 3

2

一度に 1 つずつ質問を受け付けます。

ソフトウェアでエンティティ グループをどのように参照する必要がありますか? IDまたは名前をハードコーディングしますか?

コードが最も読みやすい方法でエンティティ グループを参照してください。したがって、おそらく名前を使用するか、名前のように見えるが値が id である定数を使用する可能性があります。定数を使用すると、エンティティをグループ タイプ別に検索するときに 1 つの結合を回避できますが、通常、これはあまり問題になりません。

なぜDBにそのテーブルが必要なのですか? これは私のデータを構造化する間違った方法ですか?

これは、データを構造化するのに完全に受け入れられる方法です。最も正しい方法は、データで何をしているかによって異なりますが、ほとんどのアプリケーションでは、構造が正しいでしょう。ただし、データベースにそのテーブルは必要ありません。代わりに、entity_group テーブルに「group_type」フィールドを作成できます。長所と短所は次のとおりです。

現在の構造の利点:

  • entity_group_type を説明するフィールドを簡単に追加できます。たとえば、一部のグループ タイプを管理者ユーザーのみが表示できるようにしたり、無効にしたりしたい場合があります。これが将来の可能性である場合、このデータベース構造が必要になります。
  • データベース ソフトウェアに参照整合性を適用させる機能。つまり、entity_group テーブルと entity_group_type テーブルの間でデータの一貫性が保たれます。

entity_group テーブルに group_type フィールドを追加する利点:

  • おそらく、コード内のより単純な表現です。たとえば、MVC アーキテクチャを使用する場合、追加のテーブルを使用するには、コード内に別のモデル オブジェクトが必要になる場合があります。これは通常は問題ではなく、利点もあるかもしれませんが、シンプルな方が良い場合もあります。
  • エンティティ グループ タイプごとにエンティティを検索する場合、関連するテーブル/結合が 1 つ少なくなるため、SQL ステートメントはわずかに単純になります。

データの使い方にもよりますが、ほとんどの場合、現在の構造が先行していると思います。データを別の方法で構造化する正当な理由がない限り、現在の構造に固執します。

于 2013-05-15T21:00:31.747 に答える
1

entity_group_type上記の設計図に従って、データベースの独自のテーブルに確実に保存する必要があると思います。その情報を DB に格納すると、その情報に対してクエリを実行できるようになり、設計に柔軟性が追加されます。

この情報をDBに入れたら、質問は、それを独自のテーブルに分割するか、entity_typeテーブルの列として保存するかのようです。entity_type外部キー制約 from to を使用して、独自のテーブルに分割する必要があると思いますentity_group_type。

  • entity_group_type独自のテーブルを持つことで、そのタイプのすべてのエンティティ グループが DB から削除された場合でも、グループ タイプを保持できます。
  • 外部キーを利用して、entity_group_type名前のスペルが一貫していることを確認できます。挿入entity_groupされた s は外部キー制約を満たす必要があるため、適切なスペルentity_group_typeの名前を持つ既存の を参照するかentity_group_type、その new に適切なスペルを設定する を挿入する必要がありentity_group_typeます。

テーブルに合成キーを使用して、名前entity_group_typeの出現における苦痛な冗長性を減らします。entity_group_typeこれにより、データ モデルがよりDRYになり、entity_group_typeの名前を更新して 1 つのテーブルを簡単に更新できるようになります。

entity_group_typeアプリケーション ロジックに を保存する場合は、名前を保存し、必要なときに ID を検索することをお勧めしますentity_group_type。これにより、アプリケーションのコードベースがより読みやすくなると思います。また、この関連情報をデータベースで表現する必要があると考える理由について、説得力のある議論をしたと思います。

于 2013-05-15T06:28:02.217 に答える
0

name実行時にのを知っている場合、その ですべてのentity_group_typeを見つける正しい方法は、結合を使用します。entity_groupentity_group_type.name

SELECT entity_group._id, entity_group.name, entity_group_type.name AS groupTypeName
FROM entity_group
JOIN entity_group_type ON entity_group.id_type = entity_group_type._id
WHERE entity_group_type.name = 'someGroupName';

これにより、 のすべてのentity_group情報が得られgiven entity_group_type nameます。

はい、これはその種の情報を保存するための適切な、または少なくとも可能な方法です。entity_group_type最終的にが新しい属性を取得することを想像してみてくださいdisabled。entity_groupその場合でも、型に含まれる (含まれない)すべての s を簡単に見つけることができdisabledます。

于 2013-02-01T13:22:55.500 に答える