Jak poprawnie powinna wyglądać struktura bazy oraz co jest wydajniejsze.

Mamy kilka obiektów:
- User (zarejestrowany użytkownik)
- Order (zamówienie)
- Document (dokument, np. faktura)
- Person (osoba która może zostać użytkownikiem)
oraz
- Mail (wiadomość e-mail)

Wiadomość e-mail jest przypisana do co najmniej jednego obiektu z powyższych, ale może być do 2 lub dowolnej ilości równocześnie. Pytanie jak to powiązać? Rozwiązanie pierwsze:

[SQL] pobierz, plaintext 
mails
----------------
id PK INT
user_id INT FK NULL
order_id INT FK NULL
document_id INT FK NULL
person_id INT FK NULL
sender VARCHAR
recipient VARCHAR
body TEXT
[SQL] pobierz, plaintext 

I teraz w przypadku gdy wiadomość jest powiązana z użytkownikiem to w user_id jest jakaś liczba ID użytkownika, a inne pola (order_id, document_id ...) mają NULL-a.

Nie wiem czy to jest dobre rozwiązania, i podświadomie czuje że chyba jednak nie. Zaznaczam że wszystko jest w InnoDB z kluczami obcymi. Tak samo chciałbym zostawić sobie furtkę w postaci możliwości rozbudowy bazy o nowe obiekty.

Drugie rozwiązanie:

[SQL] pobierz, plaintext 
mails
---------------
id PK INT
sender VARCHAR
recipient VARCHAR
body TEXT
[SQL] pobierz, plaintext 

A do tego tabele wiążące:

[SQL] pobierz, plaintext 
mails_users
--------------
mail_id FK INT
user_id FK INT
[SQL] pobierz, plaintext 

[SQL] pobierz, plaintext 
mails_orders
--------------
mail_id FK INT
order_id FK INT
[SQL] pobierz, plaintext 

[SQL] pobierz, plaintext 
mails_documents
--------------
mail_id FK INT
document_id FK INT
[SQL] pobierz, plaintext 

[SQL] pobierz, plaintext 
mails_persons
--------------
mail_id FK INT
person_id FK INT
[SQL] pobierz, plaintext 

I teraz tworzymy poprostu rekord w mails oraz dodatkowo drugi rekord w odpowiedniej tabeli, żeby powiązać tą wiadomość np. z osobą, zamówieniem itd. Unikamy przez to stosowania pól NULL oraz oszczędzamy na miejscu w tabeli mails. Dodatkowo to rozwiązanie wydaje się być bardziej uniwersalne, bo dokładając dodatkowe tabele łączące można wiązać wiadomości z nowymi e-mailami (np. thread - wątek) itd.


Zapraszam do dyskusji


Pozdrawiam

rozwiązanie 2 lepsze pod względem uniwersalności
pod względem wydajności może być różnie (przy bardzo dużych bazach rozwiązanie 1 może być trochę wydajniejsze) ale trzeba by było to sprawdzić dokładnie

Proszę o poprawienie tytułu na bardziej opisujący problem.