| Zitat von fichz |
| Habe ich nun trotzdem irgendwie eine Möglichkeit eine Navigation Property zu erstellen, ohne dass ein FK nötig ist (und auch von EF NICHT erstellt wird)? |
Nein, eine eigentliche Navigation Property basiert immer auf einer Relation und damit einem FK. Du hast keinerlei Chance, dies zu ändern.
| Zitat von fichz |
| Ziel wäre, dass ich dann in der Datenklasse A per Include/Join dann auf Daten in Klasse B zugreifen kann und somit nur eine Abfrage an den SqlServer sende. |
Das ist möglich, aber nicht mit EF Automatismen. Musst das halt alles in Linq ausprogrammieren, denn ohne Navigation Properties kann Dir EF hier nichts abnehmen.
Ebenso kannst Du die keinerlei Schreib-Mechanismen, also das Erstellen von Einträgen, automatisch machen lassen; auch hier musst Du alles ausprogrammieren.
| Zitat von fichz |
|
Ich kann die aktuelle Datenbankstruktur leider nicht ändern, da ich da in Gefahr laufe, dass das Programm nicht mehr korrekt funktioniert. |
Das ist problemlos möglich, damit verdienen tagtäglich viele viele Entwickler:innen- und Datenbank-Profis ihre Brötchen.
Alles eine Frage der Organisation. Aber Schema-Änderungen sind Alltagsdinge beim Umgang mit Schema-behafteten Datenbanken.
In EF6 sind Migrations nicht der Hit (ist in EF Core um Welten besser), aber mit FluentMigrations kann man sowas auch sehr gut lösen.
Schon dutzende Male damit erfolgreich "große" Datenbanken migriert.
Der MSSQL Server hat aber auch integrierte Migration Mechanismen oder eben Standard SQL-Scripts, wie tagtäglich auch auf Enterprise-Ebene laufen.
Ohne Migration macht Dein Vorhaben nur bedingt sinn. Die Zeit, die Du in Workarounds der FK-Sache stecken werden wirst, kannst wahrscheinlich in eine saubere Migration stecken und hast ein besseres, nachhaltigeres Ergebnis.
