Przechowywanie dużych plików w bazie danych

Witajcie,
Jak wygląda sprawa z przechowywaniem dużych plików w bazie danych? Jeżeli mam plik, który zajmuje np. 100MB powinienem trzymać jedynie referencję do niego w bazie, a plik w folderze na dysku czy takie dane trzymać w polu BLOB?

jeśli chodzi o MSSQL to masz tam coś takiego jak FileStream, w Oracle BFILE. Coraz więcej baz implementuje coś co służy do przechowywania danych binarnych w systemie plików z dostępem jak do zwykłej tabeli. Sprecyzuj o jaką bazę chodzi.

Pliki trzymamy w bazie. Obecnie dyski są już na tyle szybkie, że nie robi to dużej różnicy. Ważnym elementem jaki zyskujesz w takiej sytuacji jest jednak pełna kontrola nad transakcjami związanymi z zapisem i zmianą danego rekordu.

Chodzi mi o bazę danych MySQL

Żeby uzyskać jakąś sensowną odpowiedź musisz podać jakie operacje i jak często przewidujesz na tych danych.

• utworzenie rekordu - jak często?
• odczyt rekordu częściowy - jak często?
• odczyt rekordu całościowy - jak często?
• kopiowanie rekordu - jak często?
• przeszukiwanie zawartości rekordu - jak często?

I dodatkowo:

• jakiego rodzaju to dane? multimedia? XML? DOC? niestandardowe binarne?

Na pewno będzie problem przy backup - będzie się wydłużał niemiłosiernie (full).
Inkrementalny mniej, ale ten pełny i tak trzeba robić.

@vpiotr czas backupu nie jest istotny, bo to czy backupujesz bazę danych zawierająca pliki czy też zawierającą tylko linki nie ma znaczenia! Załóżmy, że masz pad dysku i musisz odzyskać dane.

Przypadek 1. baza zawierająca pliki

Backup-y są długie.
Odzyskiwanie jest długie.
Odzyskujesz wszystkie dane.

Przypadek 1. baza zawierająca linki
Backupy bazy są krótkie.
Potrzebny jest długi backup systemu plików.
Odzyskiwanie bazy jest krótkie.
Potrzebujesz odzyskać też kolejny backup z plikami.

Samo odzyskanie bazy nic nie daje, bo otrzymujesz tylko meta informacje dla danych (linki), a nie same dane (pliki).

@Zaprogramowany, w MySQL masz BLOBy, a ciebie dokładnie interesują MEDIUMBLOB (maksymalna wielkość 16MB) i LONGBLOB (maksymalna wielkość 4GB). I teraz uwaga, bo można sobie zabić apkę w widowiskowy sposób. Jeżeli używasz ORMa to koniecznie oznacz pole pliku jako leniwe. Jeżeli piszesz własny dostęp do danych to też zrób to tak by pliki były wybierane leniwie. Inaczej zapchasz pamięć plikami gdy np. pobierzesz listę plików danego użytkownika.

Gdyby ORM automatycznie wczytywał do pamięci pliki (nawet 4-kilobajtowe) to nie byłoby zabijanie bazy tylko błąd architektury. Przy 100MB taki błąd uniemożliwiłby pracę z aplikacją.
Czyli sprawdzenie tego to jest "must have".

Pytanie dodatkowe do autora wątku:

• w jakim stopniu pliki są kompresowalne?

Nie każdy ORM obsługuje leniwe pola, więc trzeba przemyśleć jego wybór.

na upartego same pliki można trzymać w osobnej bazie i mieć dwie osobne kopie bazy - dane i pliki. Można jednym selectem wyciągać dane z obu baz. W razie czego najpierw wgrywasz "szybko" backup bazy z danymi a potem "na spokojnie" pliki. Dodatkowo możesz samą tabelę z plikami (obojętnie czy będzie jedna baza czy dwie) umieścić na innym dysku/partycji aby sobie nie zapchać/spowalniać operacji na danych nieplikowych

W dwie bazy to bym się nie bawił, bo to wymaga transakcji rozproszonych, które są problematyczne i niewydajne.
Ale przechowywanie wszystkich plików w jednej tabeli, która jest w oddzielnej filegroupie i na innej partycji, to sensowne rozwiązanie. Dodatkowo nie powoduje to takich problemów z ORMami.