Tworzenie tabel w bazie danych

Witam

Jestem w trakcie pisania aplikacji i mam parę pytań jak zaprojektować bazę danych:

1. Czy powinienem w tabeli User przetrzymywać tylko login/hasło/email?
2. Czy zrobić to bardziej rozbudowane i trzymać wszystko co User będzie miał tj. koszyk, preferencje, hasła itp. itd.
3. Czy powinno się przypisywać jakieś ustawienia do Usera, czy może na odwrót?

• Czy są jakieś plusy i minusy po której stronie relacji jest klucz obcy?

4. Jakaś sprawdzona literatura do podszkolenia się?

Aplikacja jest pisana w Springu(jeżeli to ma jakiekolwiek znaczenie).

1 i 2) No raczej koszyka lepiej nie pchać do jednej komórki. Koszyk to powinna być tabela zawierająca wiersze z referencjami do usera i produktu dla każdego produktu w koszyku. Bo produkt to też osobna tabela.
3) W aplikacji raczej przez Usera będziesz się odwoływał do innych tabel. Więc lepiej, żeby inne tabele miały referencję na Usera. Poza tym dzięki takiemu rozwiązaniu będzie łatwiej osiągnąć relację jeden do wielu np. w historii zamówień. Jeden użytkownik ma wiele zamówień. Jeśli zamówienie zapiszesz w użytkowniku, to będzie tylko jedno.

a może:
Login (id, login, password)
User (id, login_id, fname, sname, adress, age, itd)
Product (id, name, value, info)
Order (id, date, user_id, paymentStatus)
Basket (id, order_id, product_id, number)

coś w ten deseń. Jak robisz sklep to danych klienta masz dużo. Rozdziel je. Pewnie da się to jakoś sensowniej poukładać, ale ktoś mi kiedyś powiedział że mam specyficzny sposób budowania baz danych :)

Na początek poczytaj o normalizacji. Da Ci to wgląd w proces tworzenia bazy danych. Idealnie wygląda to tak, że bierzesz kartkę (analogową albo cyfrową), siadasz i wypisujesz wszystkie atrybuty (czyli pola z tabel) jakie tylko będziesz potrzebował zapisać w bazie, bez podziału na jakiekolwiek tabele - po prostu zapisujesz wszystko co Ci przyjdzie do głowy a czego możesz potrzebować. Następnie grupujesz atrybuty logicznie - np. imię, nazwisko, login, hasło "dodajesz" do grupy uzytkownik. I tak dalej. Większość baz funkcjonuje w niepełnej 3 postaci normalnej - tzn. że najczęściej ze względów wydajnościowych celowo wprowadza się pewne odstępstwa od 3PN, najczęściej w postaci nadmiarowości.

O projektowaniu i normalizacji możesz poczytać np. tu http://www.sqlpedia.pl/projektowanie-i-normalizacja-bazy-danych/ Najważniejsze wg mnie są przykłady, które pokazują cały proces.

Co do samego pytania to @Spine na większość odpowiedział, ja odniosę się tylko do tego Czy są jakieś plusy i minusy po której stronie relacji jest klucz obcy? - tu nie ma plusów i minusów - to jest kwestia tego, czy człowiek może mieć wiele rąk vs czy ręka może mieć wiele człowieków :)

EDIT na komentarz bo się nie zmieściło

bardzo ciekawa lektura na temat normalizacji baz danych, ale jak bardzo powinniśmy tego przestrzegać? Czy dodanie kolejnej tabeli np z 2 kolumnami np. miasto | kod-pocztowy ma sens? Czy po prostu jest to nieopłacalne?

Jeśli chodzi o przestrzeganie to powinno się - na początku bazę powinno się zaprojektować w 3PN i potem ewentualnie zdenormalizować do postaci pomiędzy 2PN a 3PN (przychodzi z doświadczeniem).

Co do drugiego to zależy :). O ile tabela z miastami ma sens (przede wszystkim uporządkowanie nazw bo jak wiadomo userzy potrafią wpisywać różne kwiatki) to dla kodów pocztowych, o ile nie masz zamiaru zaimplementować podpowiadania miast po wpisaniu kodu, niekoniecznie. Tak samo dodanie ulic/dzielnic ma sens tylko wtedy jeśli od razu do bazy załadujemy słownik wszystkich miast, ulic, kodów, wsp. GPS tak aby user od razu miał możliwość wybrania lub podpowiedzi bo budowanie tak szczegółowej bazy od zera to wg mnie niepotrzebna praca zarówno dla programisty jak i dla usera. Oczywiście są od tego odstępstwa i jakieś specyficzne warunki mogą wręcz wymuszać taką budowę bazy.