Hai fondamentalmente due scelte. Puoi archiviare i dati direttamente nella riga o puoi utilizzare la funzione per oggetti di grandi dimensioni. Poiché PostgreSQL ora utilizza qualcosa chiamato TOAST per spostare campi di grandi dimensioni fuori dalla tabella non dovrebbe esserci alcuna riduzione delle prestazioni associata all'archiviazione diretta di dati di grandi dimensioni nella riga. Rimane un limite di 1 GB nella dimensione di un campo. Se questo è troppo limitato o se desideri un'API di streaming, puoi utilizzare la funzione per oggetti di grandi dimensioni, che ti offre qualcosa di più simile ai descrittori di file nel database. Memorizzi l'ID LO nella tua colonna e puoi leggere e scrivere da quell'ID.
Personalmente suggerirei di evitare la struttura per oggetti di grandi dimensioni a meno che non ne abbiate assolutamente bisogno. Con TOAST, la maggior parte dei casi d'uso viene coperta semplicemente utilizzando il database nel modo previsto. Con oggetti di grandi dimensioni, ti dai un ulteriore onere di manutenzione, perché devi tenere traccia degli ID LO che hai utilizzato e assicurarti di scollegarli quando non vengono più utilizzati (ma non prima) o rimarranno nel tuo directory dei dati che occupa spazio per sempre. Ci sono anche molte strutture che hanno un comportamento eccezionale intorno a loro, i cui dettagli mi sfuggono perché non le uso mai.
Per la maggior parte delle persone, la grande penalizzazione in termini di prestazioni associata all'archiviazione di dati di grandi dimensioni nel database è che il software ORM estrarrà i big data su ogni query a meno che non venga espressamente indicato di non farlo. Dovresti fare attenzione a dirlo a Hibernate o qualunque cosa tu stia usando per considerare queste colonne come grandi e recuperarle solo quando sono specificatamente richieste.
