Normalizacja, powiązania

[Krzychu]

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:

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

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:

mails
---------------
id PK INT
sender VARCHAR
recipient VARCHAR
body TEXT

A do tego tabele wiążące:

mails_users
--------------
mail_id FK INT
user_id FK INT

mails_orders
--------------
mail_id FK INT
order_id FK INT

mails_documents
--------------
mail_id FK INT
document_id FK INT

mails_persons
--------------
mail_id FK INT
person_id FK INT

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

[wloochacz]

Krzychu pisze:
> Jak poprawnie powinna wygl�da� struktura bazy oraz co jest
> wydajniejsze.
ZAWSZE w temacie postu pisz o jak� baz� chodzi, to wynika z tre�ci, ale
gdyby� napisa� MySQL - nigdy bym tu nie zajrza� i zaoszcz�dzi� bym sobie
czasu ;-)

/ciach/

> 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.
Tak, ale wymaga tabelki dla ka�dego wi�zania, a co za tym idzie -
osobnych zapytaďż˝.

Jest jeszcze 3 wyj�cie:
mails_objects
--------------
mail_id PFK INT
object_id PFK INT
-- typ obiektu, gdzie: 0 - user; 1- order; 2 - document, itd.
object_kind PK INT

--
wloochacz