On Thu, Sep 11, 2014 at 10:35 AM, Alexander Shorin <[email protected]> wrote:
> On Thu, Sep 11, 2014 at 6:19 PM, Eric B <[email protected]> wrote: > > So then my second option becomes to assign a "document-type" key to every > > document and then filter upon that. Where my "document-type" key is akin > > to an organizational/collection name. It's definitely better, but still > > seems a little odd. > > > > The whole process seems very disorganized. > > Having document type field is a good and common practice. In fact, > MongoDB uses the same, but at more high level calling this > "collection". You can implement the same by using document type field > and the view which emits documents by type. More over, you can create > "collections" (views) across various documents by conditions whatever > you like. > > Is that not horribly inefficient? For a handful of documents I can see how it would work, but for large datasets (ex: millions of docs), how efficient is running everything through a JS compiled view? Each time you open a view, it needs to filter millions of docs. For example, I have a client using an RDBMS of about 7G of data. Some tables contain >1M records. With proper indexing, it is quick and responsive. How can CouchDB be fast having to parse 7G of data to populate a view? Thanks, Eric
