Looks like you're just trying to do phone number lookups, so converting the
numbers into a canonical form and using that as the _id sounds perfect -
globally unique natural keys are what you want and it saves you having to store
a view that has the same information.
As for better ways to store your data, I think you need to do some benchmarking
:-) You need to look at your full application "lifecycle" (all the database
actions it does) and determine what you can do to satisfy your requirements.
Seems to me though that what you're proposing is probably best.
Wout.
On Oct 10, 2010, at 21:55 , John Logsdon wrote:
> Hi
>
> I'd like to draw on the experience of the user community to see if there is
> a more efficient way to store large lists of numbers.
>
> in my simplest case I have just a List of Numbers with no data attached i.e.
> my doc looks something like this:
>
> {
> "_id":"<a uuid>",
> "_rev":"<a couchdb rev",
> "list_id":"The enclosing list uuid",
> "no":"012739876543"
> }
>
> I can shrink that done to:
>
> {
> "_id":"012739876543",
> "_rev":"<a couchdb rev",
> "list_id":"The enclosing list uuid",
> }
>
> With the latter I can just search for docs by _id and avoid the expense of
> the index.
>
> My lists of telephones can be quite large (Several million) so I'm wondering
> if there are better ways to store such simple data in couchdb? e.g. Avoid
> one document per number and go for a more complex document with multiple
> numbers, array, or whatever.
>
> BTW - The document per number is workable, I'm merely wondering whether I'm
> over-egging the problem.
>
> Anyway, I thought I'd ask as i'm sure you've come up with some very creative
> solutions for various domains that could be useful to people like me.
>
> Regards
>
> John
