Jaki schemat bazy dla plików?

Zastanawiam się jaki schemat bazy danych przyjąć do trzymania informacji o plikach. Mam tebelki takie jak profiles/users/realestates itd. i każdy rekord z tych tablel może mieć kilka plików. W każdym wypadku będzie tabela files oraz - no właśnie - oto moje pomysły (w przykładzie uzyję tylko tabeli users)

1. Dla każdej z tabel utworzę pivot table w której będzie id z tabeli files oraz id z tabeli users i żeby dogrzebać się do plików danego usera, będę musiał joinować tą tabelę pośrednią user_files
2. W tabeli files dodam kolumny owner_type oraz owner_id. Mój ORM wspiera relacje polimorficzne, więc w łatwy sposób mogę wyciągnąć np. wszystkie pliki powiązane z danym rekordem z tabeli users, bo w kolumnie owner_type będzie nazwa odpowiadającego modelu, czyli będzie tabela files + odpowiednio users/profiles itd..
3. Dla każdej tabeli utworzę odpowiadającą jej tabelę files, w której będą pliki tylko dla danej tabeli profile_files/user_files/realestate_files itd. (** uwaga, nie jest to pivot table, tylko pełna tabela files **)

Tyle mi przychodzi do głowy. Jak myślicie, czy któreś z tych rozwiązań jest dobre?

Zastanawia mnie jeszcze jak rozwiązać kwestie dokumentów. W końcu to też plik... Czy lepiej jest to rozdzielic z uwagi na fakt, że taka generyczna tabela files może urosnąć do gigantycznych rozmiarów i mieć tabelki files oraz documents, czy po prostu umieścić w tabeli files z odpowiednim file_type ? Z drugiej strony dokument również może mieć swój typ i tu się sprawa komplikuje, więc chyba sensowniej jest to rozdzielić.

Jeśli o mnie chodzi to uważam, że najwygodniej będzie stworzyć tabele spięcia user_file bo masz relację wiele do wiele. Musisz też sobie zadać pytanie czy jeden plik może dotyczyć profilu i usera wtedy również rozwiązanie nr 1 jest najlepsze. Trochę więcej będzie pierniczenia przy wyświetlaniu dla usera/profile itd bo trzeba będzie robić albo uniony albo niezależne widoki spinające pliki po innych tabelach ale ... wszystko zależy od potrzeb.

@woolfik, a czy znasz jakieś fajne źródła z których mógłbym zaczerpnąć wiedzy na ten temat? Prawdopodobnie podczas projektowania bazy i podczas kodowania będę miał jeszcze dużo pytań, a nie chce pytać o każdą pierdołę.

@Desu niestety na to pytanie nie ma jednoznacznej odpowiedzi. Wszystko uzależnione jest od konkretnej potrzeby. Inaczej będzie wyglądać struktura bazy danych dla aplikacji biznesowej inaczej dla hurtowni danych, inaczej dla malutkiej bazy firmowej, a inaczej dla gigantycznych zbiorów danych. Ja np zawsze tworząc system robię ile się tylko da po stronie bazy danych (czyli same procedury/funkcje/widoki/constrainty/indeksy/granty itd.) a UI służy tylko do wprowadzania/wyświetlania danych natomiast są również na tym forum programiści, którzy traktują bazę jako zbiór danych i tworzą aplikacje wręcz odwrotnie czyli na bazie tylko tabela a kontrole itd w apce ... wszystko zależy od potrzeb