Geodatabase Attachments Storage Location Option

2630
6
08-29-2013 03:10 PM
Status: Open
Labels (1)
JeffForeman
New Contributor III

When enabling attachments on a feature class, give the option to store the attachments outside of the geodatabase on a seperate file server. Instead of storing the attachment as a BLOB in the related database table, your related table would contain a path to a file server where your attachment is stored.

6 Comments
MichaelVolz
This would be a very useful alternative to vastly decrease data duplication if you already have the attachments in another robust RDBMS that can mange these files more efficiently than ESRI feature classes.
EricGeddes

Absolutely. A couple other ideas are basically asking the same thing, and another dozen (or more!) would be resolved (or could be more easily resolved) if this were to be implemented. 

That said, what about adding geoprocessing functionality to "push attachments to files" that would, at the database level, extract the files as documents to be stored in a specified location, and replaced with a hyperlink to them. Similarly a "gather files for document" (or similar) could reverse the process???

JohnMDye

Agree. Would be great if I could point it to an S3 bucket for attachments. A popular feature service with attachment s enabled can really eat up your service credits with storage costs.

KatieCullen

Attachments are not part of feature storage. For any service published after July 2, 2014 attachments are charged as file storage which runs 1.2 credits per 1 GB/month.

 

https://www.esri.com/software/arcgis/arcgisonline/credits

 

http://doc.arcgis.com/en/arcgis-online/administer/view-status.htm#ESRI_SECTION1_1D001100A7A24CDF85A0...

JohnMDye

Thanks for the clarity.

QuinnBast

I know this is old and marked as "reviewed", but this is still 100% necessary. It's not just an issue with credits/file storage. Storing data as BLOBs can really increase database size and takes a massive performance hit as storage skyrockets. Not to mention working with BLOB formats is just terrible. Being able to reference attached files in their natural file formats and providing a file path to their location in a file server would be 100 times better than the current BLOB storage method.