Wpis z mikrobloga

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