Projektowanie bazy danych - podział tabel i nazwa kluczy głównych

Mamy dwie tabele.
W obu tabelach występują powtarzające się pola (np. login i hasło).
Czy lepszym podejściem będzie wyodrębnić duplikujące się kolumny do osobnej tabeli i połączyć nową tabelę za pomocą związku jeden do jednego z każdą tabelą?
Czy powyższe rozważanie jest powiązane z normalizacją (moim zdaniem nie ale jeśli tak, to prosiłbym o wskazanie, która postać)?

Czy dobrą praktyką jest wstawianie do każdej tabeli klucza głównego o nazwie "id"?
Czy lepiej jest np. potraktować login jako klucz i zrezygnować z dodawania dodatkowego pola o nazwie "id" (moim zdaniem nie, bo jako typ dałbym wtedy CHAR a to raczej nie jest zbyt wydajne rozwiązanie)?

Czy klucz główny o nazwie "id" powinien posiadać sufiks odnoszący się do przeznaczenia tabeli?
Np. dla tabeli USERS pole to powinno mieć nazwę "id" czy "id_user"?

Wiara czyni cuda napisał(a):

Mamy dwie tabele.
W obu tabelach występują powtarzające się pola (np. login i hasło).
Czy lepszym podejściem będzie wyodrębnić duplikujące się kolumny do osobnej tabeli i połączyć nową tabelę za pomocą związku jeden do jednego z każdą tabelą?

Tak

Czy powyższe rozważanie jest powiązane z normalizacją (moim zdaniem nie ale jeśli tak, to prosiłbym o wskazanie, która postać)?

Tak. 2 lub 3.

Czy dobrą praktyką jest wstawianie do każdej tabeli klucza głównego o nazwie "id"?

Praktyką - tak. Ale nie zawsze jest to wtedy zgodne z 3PN.

Czy lepiej jest np. potraktować login jako klucz i zrezygnować z dodawania dodatkowego pola o nazwie "id" (moim zdaniem nie, bo jako typ dałbym wtedy CHAR a to raczej nie jest zbyt wydajne rozwiązanie)?

Nie. Sam sobie uzasadniłeś.

Czy klucz główny o nazwie "id" powinien posiadać sufiks odnoszący się do przeznaczenia tabeli?
Np. dla tabeli USERS pole to powinno mieć nazwę "id" czy "id_user"?

Jeśli np. chcesz robić w PostgreSQL robić NATURAL JOIN to tak. Ja tego nie stosuję - używam tylko id, bo wtedy jednym triggerem mogę "załatwić" parę tabel...