Dwie tabele czy jedna wieksza?

Mam tabele odnosnie logowania platnosci sms, bede chcial wyswietlac userom historie doladowan SMS oraz wybrane produkty za zgromadzone punkty z sms'ow. Teraz <ort>niewiem </ort>czy stworzyc tabele:

tabela1 (przywilejow)
sms_id
uzytkownik
data
nazwa_przywileju

tabela2
sms_id
uzytkownik
data
koszt_sms (wyslanych sms'ow)

Czy zlaczyc takie dwie tabele w jedna:

tabela
sms_id
uzytkownik
data
koszt_sms (wyslanych sms'ow)
nazwa_przywileju

Czemu <ort>niechce </ort>laczyc? Poneiwaz gdy bede chcial wyciagnac z bazy wszystkie operacje jednego usera, to przy dwoch tabelach bedzie szybciej:
SELECT * from tabela_sms_doladowan where user_id = XXX;

A dla tabeli polaczonej w jedna, np bede chcial wyciagnac doladowania to musze zrobic:
SELECT * from tabela_sms where userd_id = XXX and przywilej IS NULL

ktore <ort>na pewno </ort>bedzie dzialalo duzo wolniej. Sa jakies wady posiadania dwoch tabel zamiast jednej?
Dzieki za wypisanie plusow i minusow takich rozwiazan i rady

Nie bardzo jeszcze rozumiem co chcesz osiągnąć, ale jak widzę powtarzające się pola w tabelach to aż się prosi o tabele master/detail, ja bym chyba jednak lepiej wszystko zrobił na osobnych tablicach, czyli każdą operacje rozbił na osobne tablice:

TABLE USER (tablica nadrzędna)
USER_ID
UZYTKOWNIK
IMIE
NAZWISKO
NR_TELEFONU

TABLE USER_DOLADOWANIE (podrzedna do USER)
USER_ID (foreign key do USER) (primary key)
USER_DOLADOWANIE_ID (primary key)
KWOTA

TABLE jakas_inna_podrzedna_do_USER
...

Nie bardzo jeszcze rozumiem co chcesz osiągnąć, ale jak widzę powtarzające się pola w tabelach to aż się prosi o tabele master/detail, ja bym chyba jednak lepiej wszystko zrobił na osobnych tablicach, czyli każdą operacje rozbił na osobne tablice:

TABLE USER (tablica nadrzędna)
USER_ID
UZYTKOWNIK
IMIE
NAZWISKO
NR_TELEFONU

TABLE USER_DOLADOWANIE (podrzedna do USER)
USER_ID (foreign key do USER) (primary key)
USER_DOLADOWANIE_ID (primary key)
KWOTA

TABLE jakas_inna_podrzedna_do_USER
...

tabele userow oczywiscie mam stad moge uzywac user_id
chodzi wlasnie o caly system platnosci sms a dokladniej w tym temacie o jedna rzecz

wydajnosc rozwiazania z 1 tabela i 2-ma

Jesli umieszcze wszystko w jednej (kwota wyslanego sms'a + wybrane przywileje za wyslane sms'y) to zapytania SQL beda bardziej skomplikowane bo jak bede chcial wybrac tylko kwoty wyslanych sms'ow jednego usera to bede musial zastrzec ze wybieram pola gdzie przywilej jest NULL.
( bo rekord albo bedzie zawieral kwote doladowania a wtedy przywilej = NULL albo
rekord bedzie zawieral nazwe przywileju a kwota doladowania bedzie NULL )

Odwrotnie, jesli bede chcial zobaczyc jakie user wybral przywileje, to bede musial select * z tabeli ale bez kwot wyslanego sms'a.

Zapytania wypisalem powyzej, co trace na dwoch takich tabelach, wedlug mnie redundancja niewystapi a zapytania beda szybsze ale omnibusem niejestem moge sie mylic lub o czyms zapomnialem/niewiem.

IMO gorsza redundancja, wydajnoscia zapytan zajmie sie silnik. W tym wypadku to bym sie raczej nie martwil. Bardziej skomplikowane zapytania to raczej 10 wrzuconych podzapytan + agregacje i joiny a nie jedna dolozona kolumna do warunku where.

No ale wlasnie niebedzie redundancji, po prostu dane sa rozdzielone na dwie tabele, w jednej kupione a w drugiej wybrane. (tak jakbys rozpatrywal tabele kupione/sprzedane)

Te pola:
sms_id
uzytkownik
data

roznia sie w obu tabelach zawsze, wiec NIE MA mowy o redundancji, bo jak kupuje to jest inna data niz jak wybieram (sprzedaje)

Juz mi sie dodatkowo wyklarowala sytuacja, bo musialem dodac do tych tabel dla kupionych i wybranych dodatkowe unikalne kolumny.