Witam,
Mam pytanie dotyczące teorii tworzenia serwisów internetowych.
Czy powinno się dzielić dane użytnowników na profile i konta? Były by one reprezentowane przez dwie osobne tabele.
Tabela konta przechowywała by jedynie e-mail, hasło i ew, jakies tokeny, czy pytania dotyczące odzyskania hasła - mówiąc krócej - podstawowe dane zebrane podczas rejestracji.
W drugiej znajdowały by się inne informacje, jak imie, nazwisko, płeć, data urodzenia, link do avataru.
Co sądzisz o takim podziale? Jak Ty to robisz?

Pozdrawiam

Ale po co coś takiego? Nie widzę w ogóle sensu w tym co napisałeś. Jedna tabela, w której trzymasz wszystko co dotyczy użytkownika, w zupełności wystarczy. Przynajmniej ja tak uważam.

można podzielić, ale nie w taki sposób co opisałeś, to zależy od przypadku, jeżeli masz bardzo dużo kolumn to możesz je logicznie podzielić na tabele, ale jeżeli masz tylko login, hasło, e-mail, imie, nazwisko, płeć, data urodzenia, link do avataru to trzymaj w jednej

No tak, ale wszyscy chyba zapomnieli o tabeli properties:

USERS:
ID, nick...

PROPERTIES
user, property, value

kuma?

Erix... To jest fajne rozwiązanie z dynamicznie zmienianą userowi liczba zajętych kolumn (brak nulli i innych śmieci) w przypadku posiadania ich dużej ilości, ale niesie z soba problemy natury wielokrotnego UPDATE, gdyż modyfikacja kilku rzeczy wymaga kilku zapytań tego typu zamiast jednego. Oba rozwiązania są dobre, ale zależne od przypadku. Raz lepiej zastosować jedno, innym razem drugie. Ogólnie podział na profil, users czy inne tabele (tzw. partycjonowanie pionowe) jest dobre gdy masz wiele kolumn i chcesz to logicznie podzielić na bloki danych funkcjonalnych. Z małą ilością kolumn wydzielanie specjalnie tylko po to by wydzielić -> sztuka dla sztuki. jest wiele rzeczy, które powinno się robić, ale z pewnych względów nie zawsze ma to sens. Podział o którym mówisz jest tu dobrym przykładem. Mogą zajść bowiem różne przypadki
1) Mała liczba kolumn w users - nie ma sensu dzielić
2) Mała liczba, ale wiele kolumn jest pustych - można zastosować properties podane przez erixa
3) Większa liczba kolumn - można wydzielić bloki funkcjonalne. Osobno dane firmy, osobno profil czy dane kontaktowe. To czy wydzielone to będzie do osobnej tabeli jako 1 rekord (jak proponujesz) czy jako osobne właściwości (erix) jest już zależne od tego co chcesz robić z nimi. Może być tak, że zastosujesz dla jednej tabeli rozwiązanie swoje, a dla innej erixa. Nic temu nie przeszkadza. Zależy od przeznaczenia, częstotliwości odczytów i zapisów do bazy, możliwej rozszerzalności tabeli (dodanie kolumny dla wszystkich vs dodanie po prostu rekordu userowi o danej nazwie i wartości dla properties ). Tu konieczna jest analiza zachowania się systemu.