I do tend to agree with Frederick on this one. "I don't know" seems to
be the real answer here.
Nevertheless, he touched some valuable points in general design which,
in your case, would be concluded in "divide et impera" (if I understood
correctly your problem). That means:
1. at the database level, try to achieve better granularity (by
designing smaller databases with as optimal number of documents as
possible);
2. at the view level, use pagination (10 subproducts per page would
allow enough time to build all the views until the user hits the button
for the next page).
Keep in mind that if you don't find a way, you who knows the best your
project requirements, nobody can find it for you unless that person is
really into your project.
On 10/21/2011 08:29 AM, Frederick Dalgleish wrote:
The real answer I have for you is "I don't know."
The other answer is a bunch of generalities, some of which may be even true,
all of which you
probably have already considered....but if not, here goes. All of this is
worth what you paid for it....the advice that is.
The number one rule of design is to make the granularity of your design such
that each document is about
equal to an object in an object oriented programming language, let's say,
Objective C for kicks and grins.
So an object might be a dog. A dog is a product in your schema. A dog or a
product might have characteristics, like objects do.
Dogs have sizes, colors and tail lengths. Products have prices, quantities and
maybe colors or something.
The product is a document. The fields are the characteristics.
The second rule of design is that a million items in CB won't process as fast
as say, 10 items. So feel free to have a bunch of
databases with fewer numbers of objects in them. Consider scaling up to more
servers. Consider getting better advice than mine.
That won't be difficult.
The third rule of design is to remember the machine and/or the CB product you
are using. A CB product which caches some of
the more frequently used or frequently somethinged items in RAM, rather than
forcing all the fun to and from the disk which is spinning
as fast as that poor disk is able, trying to keep up with your app....will be
faster than otherwise. So consider Membase related products.
The fourth rule of design has nothing to do with design. It isn't really a
rule. It just says that things go faster when the machine has more
cycles per second, more processors, higher bus speeds, higher bandwidth to and
from the server, more RAM, and a billion other little things.
All the external to the server stuff can be ruled out if you are using
localhost, probably.
So, if your machine is the cat's meow and your budget for software and CB help
instances is limitless, you are certain to figure this out.
Cheers. FD
PS If you get an answer to your question that really rocks, please consider
sharing it with me (us).
On Oct 21, 2011, at 12:06 AM, Thomas Hommers wrote:
Hi,
i am quite new to couchDB and trying to build a sales application.
I designed a document as product. One product consist of multiple sub-products
that are unique to one product.
Next i designed a sales document that consists of multiple products. The
quantity of each sub-product can be chosen independent.
When i know want to see the total sales quantity, i created a view that runs
through all sales-docs and emits the sold quantity, with the product- and
sub-product-number as keys. This way I am able to see the sold quantity by
product and by sub-product with a reduce function.
The problem i am facing is that it takes a long time to display an overview of
all quantities.
Did i maybe design something wrong and should take another approach? e.g. maybe
I should create a doc for each sub-product instead of having them all in one
product-doc? Would this be faster?
I am really thankful for any advice, hint or comment.
Regards
Thomas
