Dlaczego Workbench tworzy mi dodatkowy klucz obcy "preratings user id" w tabeli ratings kiedy łącze preratings z ratings? Czy nie wiem o czymś, co powoduje, że klucz ten powinien się tam znajdować?
raterid łączy 1:1 z users, ale to chyba w tym przypadku nie jest istotne..
@sir_maad: Ciężko powiedzeć, wszystko zależy od Twoich założeń. Ogólnie wg mnie za mało informacji by to ocenić, a Ty jesteś jedyną osobą posiadająca odpowiednią wiedze na temat systemu by udzielić tutaj odpowiedzi czy powinien czy nie.
@NieMogeSiePoddac: Czyli rozumiem, że to nie jest jakaś obowiązkowa, dobra praktyka i taki klucz trzeba z jakiegoś konkretnego powodu robić i stąd sugestia Workbencha, tylko to po prostu zależy od mojej aplikacji, tak?
@sir_maad: Może czegoś nie rozumiem ale piszesz że łączysz raiting z preraitings - w takim przypadku musisz mieć jakiś klucz skoro chcesz mieć relację między tymi tabelami chyba?
@radeju: No tak, "preratings id" się tworzy, ale do tego tworzy się jeszcze "preratings user id" i to mnie zastanawia. Dlaczego tworzy dwa, a nie tylko jeden.
@sir_maad a już rozumiem. W workbenchu nie pracuję więc nie wiem ale domyślam się następującego - program chce żebyś był pewny że "wylądujesz" zawsze w tym samym rekordzie users, bez znaczenia czy będziesz szedł przez preraitings czy bezpośrednio z raitings. Jeżeli go nie doda to istnieje niebezpieczeństwo że: 1) raitings -> users lądujesz w rekordzie X 2) raitings -> preraitings -> users lądujesz w rekordzie Y. Przy czym powyższe to
@sir_maad: Ogólnie, to są unkatowe klucze które dają Ci możliwość powiązania jednego rekordu z drugim. Gdy usuniesz to co doda Ci workbench - usuniesz też powiązanie - przestanie istnieć. Więc znów wracam do tego co pisałem - zależy od założeń projektowych. Więc nie tyle to jest sugestia, a powiązanie.
Dlaczego Workbench tworzy mi dodatkowy klucz obcy "preratings user id" w tabeli ratings kiedy łącze preratings z ratings? Czy nie wiem o czymś, co powoduje, że klucz ten powinien się tam znajdować?
raterid łączy 1:1 z users, ale to chyba w tym przypadku nie jest istotne..
#programowanie
#bazydanych
#pytanie
1) raitings -> users lądujesz w rekordzie X
2) raitings -> preraitings -> users lądujesz w rekordzie Y.
Przy czym powyższe to
System chce ci zasugerowac aby utrzymal referential integrity PK-FK a nie PK-FK-FK bo srodkowy FK moze byc NULL :)