Nie z natury, ale jeśli masz duże obiekty BLOB zapychające tabele i pamięć podręczną, co z pewnością spowoduje spadek wydajności.
Tak, to jest powszechne podejście. Zwykle robisz coś takiego jak nazwanie folderów po każdej tabeli, z którą są skojarzone, zawierające nazwy plików oparte tylko na kluczu podstawowym (najlepiej liczbę całkowitą; na pewno nigdy nic przesłanego przez użytkownika).
Czy to lepszy pomysł? To zależy. Posiadanie tylko jednego magazynu danych i brak konieczności martwienia się o przyznanie użytkownikowi sieci dostępu do czegokolwiek z możliwością zapisu ma zalety związane z prostotą wdrażania. Ponadto, jeśli może być uruchomionych wiele kopii aplikacji (np. równoważenie obciążenia typu aktywny-aktywny), musisz zsynchronizować pamięć masową, co jest znacznie łatwiejsze w przypadku bazy danych niż w przypadku systemu plików.
Jeśli używasz systemu plików, a nie obiektu blob, pytanie brzmi, czy serwer sieciowy będzie go obsługiwał, wskazując alias na folder?
- + jest super szybki
- + dobrze buforuje
- - dodatkowa konfiguracja serwera:katalog wirtualny; potrzebuje odpowiedniego rozszerzenia pliku, aby zwrócić żądany
Content-Type - - dodatkowa konfiguracja serwera:trzeba dodać
Content-Disposition: attachment/X-Content-Type-Optionsnagłówki zatrzymujące wąchanie IE w poszukiwaniu HTML jako część środków anty-XSS
czy też obsługujesz plik ręcznie przez skrypt po stronie serwera, który go wypluwa, tak jak w przypadku serwowania z obiektu typu blob MySQL?
- - jest potencjalnie wolny
- - wymaga trochę ręcznej obsługi If-Modified-Since i ETag, aby poprawnie buforować
- + może używać własnych metod kontroli dostępu aplikacji
- + łatwe dodawanie poprawnych nagłówków Content-Type i Content-Disposition ze skryptu obsługującego
Jest to kompromis, na który nie ma jednej odpowiedzi akceptowanej na całym świecie.
