3 ms·
If you were to go with PostgreSQL, wouldn't you store this in a large object, which is effectively stored outside of the actual table row? So, if you can store
by sverhagen 5y ago
If you were to go with PostgreSQL, wouldn't you store this in a large object, which is effectively stored outside of the actual table row? So, if you can store enough rows of meta data AND you provision enough storage, why wouldn't the database be able to do this. I don't imagine you want to put a primary key on the actual image data column (not possible with large objects, since the column just contains an "oid"). I'm not arguing for storing images in the database, I've seen it done either way, and done it myself either way, but I believe that it's an ongoing source of heated debate between proponents and opponents. I.e. not settled out of hand.
- dijit 5y agoLarge objects are _mostly_ an access method, the underlying implementation is staggeringly similar to TOAST. > The large object implementation breaks large objects up into “chunks” and stores the chunks in rows in the database. A B-tree index guarantees fast searches for the correct chunk number when doing random access reads and writes. You might try Foreign Data Wrapping. In which case I still wouldn't because the database is going to be spending more time in doing round trips, better my application server does that, there's usually more of them.