Masz w zasadzie dwie możliwości. Możesz przechowywać dane bezpośrednio w rzędzie lub możesz skorzystać z dużego obiektu. Ponieważ PostgreSQL używa teraz czegoś, co nazywa się TOAST aby przenieść duże pola poza tabelę, nie powinno wystąpić obniżenie wydajności związane z bezpośrednim przechowywaniem dużych danych w wierszu. Pozostaje ograniczenie rozmiaru pola do 1 GB. Jeśli jest to zbyt ograniczone lub jeśli potrzebujesz interfejsu API do przesyłania strumieniowego, możesz użyć funkcji dużych obiektów, która zapewnia coś bardziej przypominającego deskryptory plików w bazie danych. Przechowujesz LO ID w swojej kolumnie i możesz czytać i pisać z tego ID.
Osobiście sugerowałbym unikanie dużego obiektu, chyba że absolutnie tego potrzebujesz. Dzięki TOAST większość przypadków użycia jest uwzględniona w korzystaniu z bazy danych w sposób, jakiego można oczekiwać. W przypadku dużych obiektów narażasz się na dodatkowe obciążenie związane z utrzymaniem, ponieważ musisz śledzić używane identyfikatory LO i pamiętaj o odłączeniu ich, gdy nie będą już używane (ale nie wcześniej) lub będą siedzieć w twoim katalog danych zajmujący miejsce na zawsze. Istnieje również wiele obiektów, które mają wyjątkowe zachowanie wokół siebie, których szczegóły umykają mi, ponieważ nigdy z nich nie korzystam.
W przypadku większości ludzi duża obniżka wydajności związana z przechowywaniem dużych danych w bazie danych polega na tym, że oprogramowanie ORM będzie pobierać duże dane przy każdym zapytaniu, chyba że wyraźnie poinstruujesz, aby tego nie robić. Powinieneś zadbać o to, aby Hibernate lub cokolwiek innego używasz, aby traktować te kolumny jako duże i pobierać je tylko wtedy, gdy są one specjalnie wymagane.
