Architektura bazy danych z mailami, Jaką filozofię przechowywania informacji wybrać? Opcje

[golab]

Witam,

Piszę sobie bazę danych z mailami, które mogą wymieniać użytkownicy pomiędzy sobą. Nie są to prawdzie maile, tylko rekordy w bazie danych: id odbiorcy, id nadawcy, treść i inne techniczne kolumny.

Planuję moją bazę danych, powiedzmy, na 1000 użytkowników, każdy z nich odbierze łącznie z 5000 maili (tak dużo, bo dużo będzie maili generowanych automatycznie lub rozsyłanych do większej grupy osó.

Jak powinna wyglądać architektura takiej bazy danych w SQL?

Pomysł #1
Jedna tabela, w której indeksem jest id odbiorcy, id nadawcy
Tabela nazywa się "maile" i jest przeglądana za każdym razem, gdy skrzynkę mailową odwiedzi dowolny użytkownik używając "SELECT * FROM miale WHERE id_odbiorca={$id} OR id_nadawca={$id}"

Pomysł #2
Jedna tabela na każdego użytkownika
Tabele nazywają się "maile_{$id}", każdą tabelę przeszukuje tylko jeden użytkownik "SELECT * FROM maile_{$id}"


W pomyśle #1 rekord z mailem jest wspólny dla nadawcy i odbiorcy. W pomyśle #2 ten sam mail jest zapisany osobno w tabeli nadawcy, osobno w tabeli odbiorcy.

Pomysł #2 zajmuje zatem 2x więcej miejsca... ale czy daje jakąkolwiek poprawę szybkości przeglądania maili, skoro pomysł #1 jest indeksowany?



Pytam, ponieważ nie mam możliwości porównania obu typów architektury - wybór jednej wiąże się z ogromnymi zmianami w całym interface.
Nie oczekuję jednoznacznej odpowiedzi, a raczej wasze doświadczenia w tej sprawie.

Wybrałem pomysł #1 i zastanawiam się, czy nie jest to błąd.


Proszę o pomoc

[Pyton_000]

Zdecydowanie nie...
Do #1 warto dodać pole "readed"

[golab]

Zdecydowanie nie...

Zdecydowanie nie... co?
Rozumiem, że zdecydowanie pomysł #1 nie jest błędem?

A pola takie dodałem - "stan_od", "stan_do", czy mail jest usunięty przez jednego z korespondentów, czy przez obu itd.