Jaki schemat tabel dla aktywności użytkownika

Chcę zrobić system, który będzie gromadził aktywności użytkownika w serwisie. Np. założenie konta, dodanie zdjęcia, dodanie do ulubionych itp... Przewiduję około 10 różnych akcji... No i zastanawiam się jak to zrobić...

Opcja 1. Jedna tabela
user_id | action_type | param

param - w zależności od action_type; np. id zdjęcia

Zalety:

• wszystko w jednej tabeli
• prawie brak nadmiarowości (prócz przypadku, gdzie param = null)
  Wady:
• brak kontroli klucza obcego dla parametru
• bałagan

Opcja 2. Wiele tabel
Dla każej akcji inna tabela.

Zalety:

• obsługa klucza obcego
• całkowity brak nadmiarowości

Wady:

• dużo tabel

Opcja 3. Jedna tabela, wiele kolumn
user_id | action_type | new_accont | photo_id | favourite_id | ....... |

Dla każdej akcji tylko jedna kolumna ma wartość, reszta to null.

Zalety:

• obsługa klucza obcego
• jedna tabela
  Wady:
• duża nadmiarowość bazy

Takie mam pomysły :) Który wydaje się najlepszy? A może jeszcze inny?

======================================

Właśnie wymyśliłem inną opcję:

4. Połączenie opcji 1. i 2.
   Tabela główna: user_action
   id | user_id | date | action_id

I dodatkowo tabele, które opisują bardziej szczegółowo zdarzenia które tego wymagają np.

user_action_photo
action_id | photo_id

Zalety:

• brak nadmiarowości
• szybki i uniwersalny dostęp do podstawowych informacji wszystkich akcji, w razie potrzeby dostęp do szczegółów
• obsługa kluczy obcych
• porządek

Wady:

• niepełna obsługa kluczy obcych (ale można napisać trigger) - w przypadku usunięcia zdjęcia, nie zostanie usunięty rekord user_action, ponieważ zależność jest w drugą stronę.

Chyba najlepsza ta opcja :-)

Zdecydownie opcja nr 1.

Mozesz traktowac pole param jako miejsce na dodatkowe informacje. W Twoim przypadku: ID nowego zdjecia. Nie musisz tutaj zakladac klucza obcego. Nawet jak user wywali zdjecie (wiec param nie bedzie wskazywal na wskazane zdjecie), to i tak masz informacje o danym zdarzeniu. Aha - i nie zapomnij o kolumnie timestamp abys wiedzial kiedy dana akcja byla wykonana :P

Jedna tabela Actions:
id, user_id, date, action_type

PRIMARY KEY oczywiście na id, BIZNESOWY na user_id, date, action_type, FOREIGN KEY action_type do tabeli słownikowej

Druga tabela ActionParams:
id, param_type, action_id, param_value

PRIMARY KEY oczywiście na id, BIZNESOWY na param_type, action_id, FOREIGN KEY action_id i drugi FOREIGN KEY param_type do tabeli słownikowej

Do tego oczywiście dwie tabele słownikowe:
ActionTypes i ParamTypes