J'en ai plus sous la main là pour vérifier, mais de mémoire, dans les cas où j'ai vu des binaires stockés en BDD (côté techno, du Hibernate + PostgreSQL), c'était quand même plus lourd que le fichier binaire de base.
Plus, c'est chiant quand tu veux voir tes données, si t'as pas prévu une table "binary_data" pour isoler les données des méta-données, tu devras bien faire "select (id, date_created...) from media" et pas select * sinon merci la purge.
C'est chiant pour rapatrier un dump de prod sur l'intégration ou le dev, il va enfler très, très vite. Et généralement on peut imaginer que si t'as tout foutu en base tu es partout parti du principe que les données sont là, donc tu pourras pas forcément "nettoyer" le dump à coup de truncate pour le faire maigrir, sous peine que tout explose dans le code.
Ça oblige à avoir beaucoup de place sur les serveurs de données. Exit la BDD sur SSD, ou alors une baie de SSD hors de prix, ou alors tu devras configurer ta BDD pour qu'elle mette cette table sur des disques moins chers. Donc soit te manger une pénalité de latence pour l'accès aux métadonnées si elles ne sont pas séparées, soit séparer le binaire comme dit plus haut, mais alors un peu réinventer le "je mets mes données ailleurs que dans la BDD".
Alors je parle pas des BDD que je ne connais pas, mais dans un RDBMS, sans être impossible, c'est quand même pas terrible (et même s'il y a des nouveautés dans Postgres ou les autres RDBMS qui rendent ça plus facile, ils ne peuvent qu'aider pour le select * et le stockage séparé sur de l'espace moins cher, pas rendre ton code résilient à l'absence des binaires pour éviter de rappatrier des dumps de 3To en dev).
[^] # Re: Migration
Posté par Sufflope (site web personnel) . En réponse à la dépêche Nextcloud, le fork d'ownCloud. Évalué à 4.
J'en ai plus sous la main là pour vérifier, mais de mémoire, dans les cas où j'ai vu des binaires stockés en BDD (côté techno, du Hibernate + PostgreSQL), c'était quand même plus lourd que le fichier binaire de base.
Plus, c'est chiant quand tu veux voir tes données, si t'as pas prévu une table "binary_data" pour isoler les données des méta-données, tu devras bien faire "select (id, date_created...) from media" et pas select * sinon merci la purge.
C'est chiant pour rapatrier un dump de prod sur l'intégration ou le dev, il va enfler très, très vite. Et généralement on peut imaginer que si t'as tout foutu en base tu es partout parti du principe que les données sont là, donc tu pourras pas forcément "nettoyer" le dump à coup de truncate pour le faire maigrir, sous peine que tout explose dans le code.
Ça oblige à avoir beaucoup de place sur les serveurs de données. Exit la BDD sur SSD, ou alors une baie de SSD hors de prix, ou alors tu devras configurer ta BDD pour qu'elle mette cette table sur des disques moins chers. Donc soit te manger une pénalité de latence pour l'accès aux métadonnées si elles ne sont pas séparées, soit séparer le binaire comme dit plus haut, mais alors un peu réinventer le "je mets mes données ailleurs que dans la BDD".
Alors je parle pas des BDD que je ne connais pas, mais dans un RDBMS, sans être impossible, c'est quand même pas terrible (et même s'il y a des nouveautés dans Postgres ou les autres RDBMS qui rendent ça plus facile, ils ne peuvent qu'aider pour le select * et le stockage séparé sur de l'espace moins cher, pas rendre ton code résilient à l'absence des binaires pour éviter de rappatrier des dumps de 3To en dev).