Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Ive always felt uncomfortable putting files inside a database; the filesystem is the ideal database for files (you are not limited in size to what your o/s can handle), the indexing/search can be handled by a separate application and your database can be reduced to a simple table containing uri-esque links back to each actual file in your system and any other appropriate meta data.</p> <p>In your case, a file indexer/search engine like <a href="https://lucene.apache.org/" rel="nofollow">lucene</a> may be a better fit for your project than trying to use a traditional DMBS as a filesystem.</p> <p>Since you are planning on putting your content into a database I am assuming you will have control over how documents are added to your system. This allows you to more easily and highly integrate your presentation layer with your filesystem data store without worrying about files being dropped, changed or removed willy nilly into your special repository.</p> <p>So a very very basic high level system overview might look something like this:</p> <pre><code>[(APP) Your System]---------[(DB) Catalog ] | \ | | -------- | | \ | [(FileSystem) Files]--------[(App) Indexer] </code></pre> <p>With Your system doing all the smarts of the document maintenance and front facing searching and the Indexer monitoring the File System and updating the Catalog DB. (The Catalog may be unnecessary if your indexer ends up providing sufficient functionality or the ability to add meta data - but it might be easier to use in conjunction with the indexer if you really need to searches based on 'documents between 100 and 300')</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload