Aktywne Wpisy

LewCyzud +349
Abuxx +3
Ktory kanal o inwestowaniu cenisz sobie najbardziej?
- Marcin Iwuć – Finanse Bardzo Osobiste 11.3% (24)
- Independent Trader (Cezary Głuch / Trader21) 7.5% (16)
- Piotr Cymcyk 6.6% (14)
- Tomasz Trela 5.6% (12)
- Zawód Inwestor 31.5% (67)
- Inwestomat (Mateusz Samołyk) 20.2% (43)
- FXMAG 3.3% (7)
- Finax Polska 1.4% (3)
- Inny - daj komentarz jaki. 12.7% (27)





Mirki mam pytanie, otóż w pewnej bazie danych najważniejsze informacje o użytkownikach, przechowuję w 2 tabelach: users i settings (tu jest klucz obcy do id z users). Tabela users nie ma żadnych wartości NULL, natomiast settings ma większość wartości NULL dopóki użytkownik ich nie uzupełni.
Przy pobieraniu dużej ilości rekordów z users i settings JOINowanie tabeli settings zajmuje dużo czasu. Profesor od baz danych z polibudy powiedział, że on scalił by obie tabelę. Z drugiej jednak strony, jeżeli jakaś kolumna ma puste wartości to powinno się zrobić tabelę pomocniczą dla niej np users_lang (atomizacja itd). Co wy o tym sądzicie? Dodam, że baza będzie bardzo duża w przyszłości.
ja bym zwyczajnie trzymał dane z jednego modelu w jednej tabeli, jak mi przyjdzie zbiór innych modeli przyłączyć (np zdjęć) to łącze relacją modele (i w zależności od relacji polimorfizm albo wiele do wielu i i śmiga ;) ), ale każdy może zdobywać własne doświadczenie ( ͡° ͜ʖ ͡°)
@kowad: Różnie. Zależy od aplikacji. Tam gdzie user jest tylko użytkownikiem systemu i wszystko czego potrzeba to email, hasło, jego grupa czy status - wszystko siedzi w jednej tabeli.
Gdzie indziej, tam gdzie z uzytkownikiem są zwiazane na przykład finanse, jego stawka uzależniona od wielu różnych parametrów - jest to rozbite na dwie czy
Bardziej mnie zaintrygowalo podejscie takie zeby za wszelka cene unikac joinow :)
@msq: To Postgres, są natywnie
@plushy: Mówiłem ze nei znam za bardzo postgresa. Jeśli tak i jeśli da się to nromalnie wyszukiwać z poziomu SQL bez dramatycznego spadku wydajności to spoko.
Komentarz usunięty przez autora