Vous avez essentiellement deux choix. Vous pouvez stocker les données directement dans la ligne ou vous pouvez utiliser la fonction d'objet volumineux. Puisque PostgreSQL utilise maintenant quelque chose appelé TOAST pour déplacer des champs volumineux hors de la table, il ne devrait pas y avoir de pénalité de performances associée au stockage direct de données volumineuses dans la ligne. Il reste une limite de 1 Go dans la taille d'un champ. Si cela est trop limité ou si vous voulez une API de streaming, vous pouvez utiliser la fonction d'objet volumineux, qui vous donne quelque chose de plus comme des descripteurs de fichiers dans la base de données. Vous stockez l'ID LO dans votre colonne et pouvez lire et écrire à partir de cet ID.
Personnellement, je vous suggérerais d'éviter la grande installation d'objets à moins que vous n'en ayez absolument besoin. Avec TOAST, la plupart des cas d'utilisation sont couverts en utilisant simplement la base de données comme vous l'attendez. Avec les objets volumineux, vous vous donnez une charge de maintenance supplémentaire, car vous devez garder une trace des ID LO que vous avez utilisés et assurez-vous de les dissocier lorsqu'ils ne sont plus utilisés (mais pas avant) ou ils resteront dans votre répertoire de données prenant de l'espace pour toujours. Il y a aussi beaucoup d'installations qui ont un comportement exceptionnel autour d'elles, dont les détails m'échappent car je ne les utilise jamais.
Pour la plupart des gens, la grande pénalité de performance associée au stockage de données volumineuses dans la base de données est que votre logiciel ORM extraira les données volumineuses de chaque requête, sauf si vous lui demandez spécifiquement de ne pas le faire. Vous devez prendre soin de dire à Hibernate ou à tout ce que vous utilisez de traiter ces colonnes comme volumineuses et de ne les récupérer que lorsqu'elles sont spécifiquement demandées.
