それでいくつかの問題は解決しましたが、壁にぶち当たりました。
まず、データベース側で自己参照 FK を作成するときに、「データベースからモデルを更新」しようとすると、Entity Framework はこれらのナビゲーション プロパティをメインの基本型に追加します。これは、TPH の明示的な意味がないためです。モデル側でこれを行う必要があります。
ただし、ナビゲーション プロパティを子タイプに手動で追加することはできます。
このエラーを WRT:
これは、"ZipCode_State" 関係と "City_State" 関係に使用しようとしていた "Location_State" という FK があったためです - これは機能しません (理由はまだわかりません)。
それを解決するために、追加の列と追加の FK を追加する必要がありました - 1 つは "ZipCode_State" と呼ばれ、もう 1 つは "City_State" と呼ばれます - 明らかに、nav と物理的な FK の間で 1-1 でなければなりません。
それが私の識別フィールドです。データベース側では、null 不可です .
この問題に関するスレッドを読んだところ、リレーションシップを 0..* から 1..* に変更する必要があるとのことでしたが、私のリレーションシップはすでに 1..* でした。
上記の「場所」の実際のデータベース テーブルを見ると、すべての FK が null 可能です (そうである必要があります)。したがって、私は自分の関係を 0..* にするべきかどうか疑問に思い始めました.
ただし、TPH のため、それらは null 可能です。すべての「場所」に「状態」があるわけではありません。しかし、その場所が「都市」である場合、「州」が必要です。
私の気持ちは、この SO の質問によってさらに慰められました:in-tph">ADO EF - TPH の派生型間の関連付けのマッピング エラー
私は実際にその回避策を試していましたが（遭遇する前に）、回避策はうまくいきません。すべての関係を 1..* から 0..* に変更してみましたが、それでもうまくいきません。
ここで時間を無駄にしたので、TPT に戻りました。
結局のところ、TPH を使用すると、非常に大きなテーブルがあり、冗長で null 可能な列がたくさんあります。 JOINに関しては、より効率的です。しかし、少なくとも TPT では、null 可能で自己参照する FK を持つ必要はありません。
誰かがこの問題の解決策を持っている場合は、私に知らせてください。しかし、それまでは TPT を使い続けます。