Witam. Robię Webową apkę . Mam encję Delegacja. Encja ta zawiera odniesienie do ApplicationUser (To jest ten kto utworzył daną delegację). Ale potrzebuje też mieć w niej odniesienie do użytkownika który będzie akceptował tą delegację. Czy powinno być to jako relacja w bazie czyli klucz obcy z atrybutem [ForeignKey("ApplicationUser")] ? Czy wystarczy sam string z Id ?
public class Delegacja
{
///różne pola
public ApplicationUser User {get;set;}
public string UserId {get;set;}
}
I drugie i jeśli w Klasie Delegacja będzie ten klucz obcy to czy w ApplicationUser muszę robić Kolekcję tych delegacji ?
- Rejestracja:prawie 11 lat
- Ostatnio:około 3 godziny
- Postów:1512
0
C# edytowany 1x, ostatnio: szydlak
- Rejestracja:ponad 8 lat
- Ostatnio:około 2 lata
- Postów:117
0
Czy powinno być to jako relacja w bazie czyli klucz obcy z atrybutem
Tak.
Czy wystarczy sam string z Id ?
Jak już kolega wyżej pisał, Id nie powinno być string'iem.
I drugie i jeśli w Klasie Delegacja będzie ten klucz obcy to czy w ApplicationUser muszę robić Kolekcję tych delegacji ?
Tak.
edytowany 1x, ostatnio: cSharpKazik
jacek.placek
A dlaczego Id nie powinno być stringiem Twoim zdaniem?
- Rejestracja:prawie 11 lat
- Ostatnio:około 3 godziny
- Postów:1512
0
cSharpKazik napisał(a):
Jak już kolega wyżej pisał, Id nie powinno być string'iem.
A Wy Panowie wiecie co to jest ApplicationUser ?
- Rejestracja:ponad 8 lat
- Ostatnio:około 2 lata
- Postów:117
0
szydlak napisał(a):
cSharpKazik napisał(a):
Jak już kolega wyżej pisał, Id nie powinno być string'iem.
A Wy Panowie wiecie co to jest ApplicationUser ?
Tak proszę Pana, ale to już nie moja wina że zostawiasz sobie taki szablon i myślisz że tak musi być.
edytowany 1x, ostatnio: cSharpKazik
- Rejestracja:ponad 7 lat
- Ostatnio:5 miesięcy
- Postów:1065
0
"I drugie i jeśli w Klasie Delegacja będzie ten klucz obcy to czy w ApplicationUser muszę robić Kolekcję tych delegacji ?"
Nie, nie musisz, jeśli nie jest Ci potrzebna.
- Rejestracja:około 22 lata
- Ostatnio:3 miesiące
- Postów:5042
0
szydlak napisał(a):
Skoro ktoś to dał do szablonu domyślnego tzn ze chyba się sprawdza. Po co mam wymyślać swoje mamo jambo
ID jako string to drastyczny spadek wydajności. To jest jeden dobry powód :)
Zobacz pozostałe 8 komentarzy
Ja z tym nie dyskutuje, że to będzie wolniejsze tylko, że niekoniecznie DRASTYCZNIE chociaż to zależy od definicji.
Co do sensu używania naturalnych PK stringów to się zgadzam.
Może i to nie będzie drastyczne. Ale przy pewnych projektach/bazach może okazać się nie do przyjęcia.
@jacek.placek: a czy jeśli nie będzie drastycznie wolniej, to usprawiedliwia robienie źle?
@somekind: nie, ale dla mnie to jest decyzja projektowa. Choć zwykle oczywista. Wciskamy jakieś inty, longi, czy guidy w PK i tyle.
Nie zawsze to oczywista decyzja. Jest pewna cienka granica, kiedy lepiej stosować int, a kiedy guid. Natomiast, jak widać zdarzają się też stringi ;)
- Rejestracja:prawie 11 lat
- Ostatnio:około 3 godziny
- Postów:1512
0
Juhas napisał(a):
szydlak napisał(a):
Skoro ktoś to dał do szablonu domyślnego tzn ze chyba się sprawdza. Po co mam wymyślać swoje mamo jambo
ID jako string to drastyczny spadek wydajności. To jest jeden dobry powód :)
Też to wyczytałem właśnie na stacku. A masz może gdzieś linka jak zmienić ta konwencję domyślną?
Nie. Ja po prostu zawsze od samego początku wszystkie id daję jako biginty. Ostatnio zastanawiam się nad użyciem GUID w nowych systemach. Ale to też ma swoje za i przeciw.
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.