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
