[sir_maad]

Mam chyba głupie pytanie. Relacje jak ze skrina.

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

[NieMogeSiePoddac]

@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.

[sir_maad]

@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?

[radeju]

@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?

[sir_maad]

@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.

[radeju]

@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

[NieMogeSiePoddac]

@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.

[stateless]

@sir_maad: prerating userId moze byc teoretycznie NULL, wiec nie gwarantuje ci relacji do users.

System chce ci zasugerowac aby utrzymal referential integrity PK-FK a nie PK-FK-FK bo srodkowy FK moze byc NULL :)