K enneth, sounds to me like you are on the right path. Much of it depends on the sheer volume of documents. As some pointed out, a vast number of documents in a single folder can bog down OS storage systems, although that is way less a problem now than it was several years ago. Much also depends on why you are storing them and what you have to do with them later. It might come in handy to store the doc type, in case you need to call a specific routine (or sub-launch a special app or whatever) in order to view it directly. Also, I've found over the years that one can easily create all kinds of workable routines for the computer (4D) to store and retrieve documents, but invariably one will find that there is a need for a human to go through those folders trying to find a specific document, so I try now to make my storage folder mechanism and file naming conventions somewhat human understandable, or at least logically understandable within the scope of the application's world in case something comes up and a human has to dig through that repository. Another important consideration is how redundant or robust your storage needs to be. Depending on volume, I'm a huge fan of storing raw source documents in AWS S3 buckets. One of our projects is digitizing, indexing, and providing access to county courthouse documents in both tiff and pdf format. Millions and millions and millions and many many terabytes of documents that are indexed to 4D fields so users can search/sort/report normal 4D digital records and/or then download the actual digital disk document(s). We quickly ran out of disk space in normal office and enterprise hard drive environments, especially with duplicate backups in geo diverse locations since we can't afford to lose that many documents. AWS cloud storage was the answer for us (but similar to most of the large cloud storage systems). There are lots of ways to access cloud buckets, depending on who you go with, but we chose a "Cloudberry Drive" solution (cloudberrylab.com) so that AWS buckets become available locally as familiar network mounted drives (and they work with all the large cloud vendors); document access and manipulation works as if you are in a local lan type world - but with unlimited storage capacity. Surprisingly fast and efficient and cost effective. As for our document naming and placing routines, we obviously start the folder hierarchy with the "county name". Over time we've worked out a storage system that is well suited to this courthouse world based on the year, the month, and the day of the filing date for each document, combined with the county clerk's "instrument number" or in some counties the vol/page nomenclature they use. Fairly universal stuff in the court system vertical market, but probably not so meaningful in yours. Nonetheless, the naming and folder hierarchy logic is an important element to get right at the beginning. ---------------------------- Steve Simpson Cimarron Software
On Thu, Jan 25, 2018 at 1:24 PM, K enneth Geiger <kgeiger....@gmail.com> wrote: > > [snip] > > I’ve not started prototyping anything yet but I think I’ve got a viable > approach. The server will have a shared directory with a sub-directory for > each of their clients. There will be a dialog where the user enters > information about the document, including a text box where they can enter a > brief description of the document. The user would then drag-and-drop a scan > of the document onto the description text box and an “on drop” event would > trigger a document capture method. This method will have to rename the > document (the file-name will be created automatically within 4D without > changing the extension), check that the relevant sub-directory exists on > the server (and create it if it does not), and then save the renamed file > to the server. > > If any of you have done something similar, I would really appreciate any > feedback on my approach and would welcome any suggestions, pseudo-code, or > code that you would be willing to share. > [snip] > ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
