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ę:
- 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 :-)