Database Reference
In-Depth Information
But this is unrealistic because you can also imagine wanting to find recipes based
on, say, the ingredients you have in your pantry. Or perhaps you want to search by cui-
sine. For those cases, you need more indexes.
So here's a second question. With just one index on the recipe name, how do you
find all the chicken recipes? Again, lacking the proper indexes, you'd have to scan the
entire topic, all 5,000 pages. This is true for any search on ingredients or cuisine.
So you need to build another index, this time on ingredients. In this index, you
have an alphabetical listing of ingredients each pointing to all the page numbers of
recipes containing that ingredient. The most basic index on ingredients would thus
look like this:
Cashews: 3, 20, 42, 88, 103, 1,215...
Cauliflower: 2, 47, 88, 89, 90, 275...
Chicken: 7, 9, 80, 81, 82, 83, 84...
Currants: 1,001, 1,050, 2,000, 2,133...
Is this the index you thought you were going to get? Is it even helpful?
This index is good if all you need is a list of recipes for a given ingredient. But if
you want to include any other information about the recipe in your search, you still
have some scanning to do—once you know the page numbers where Cauliflower is
referenced, you then need to go to each of those pages to get the name of the recipe
and what type of cuisine it is. This is better than paging through the whole topic, but
you can do better.
For example, imagine that you randomly discovered a great chicken recipe in The
Cookbook Omega several months ago, but you've forgotten its name. As of now, you
have two indexes, one on recipe name and the other on ingredients. Can you think of
a way to use these two indexes in combination to find your long-lost chicken recipe?
In fact, this is impossible. If you start with the index on recipe name, but don't
remember the name of the recipe, then searching this index is little better than pag-
ing through the entire topic. If you start with the index on ingredients, then you'll
have a list of page numbers to check, but those page numbers can in no way be
plugged into the index on recipe name. Therefore, you can only use one index in this
case, and it happens that the one on ingredients is more helpful.
ONE INDEX PER QUERY Users commonly believe that a query on two fields can
be resolved using two separate indexes on those fields. An algorithm exists for
this: look up the page numbers in each index matching each term, and then
scan the union of those pages for the individual recipes matching both terms.
A number of pages won't match, but you'll still narrow down the total num-
ber of scanned items. Some databases implement this algorithm, but
MongoDB doesn't. Even if it did, searching two fields that comprise a com-
pound index will always be more efficient than what I just described. Keep in
mind that the database will use a single index per query and that if you're
going to be querying on more than one field, ensure that a compound index
for those fields exists.
Search WWH ::




Custom Search