GENEALOGY-DNA-L ArchivesArchiver > GENEALOGY-DNA > 2009-01 > 1233371111
From: Victor Villarreal <>
Subject: Re: [DNA] PUBLIC Y-DNA DATABASE
Date: Fri, 30 Jan 2009 21:05:11 -0600
> <<<Message truncated>>>
> One way to avoid this is to reverse the problem. If I can produce a
> high-quality proof-of-concept that is fully functional and provides hooks
> that existing vendors can link into, I might be able to work around the NIH
> Syndrome by making it their systems using a service rather than a service
> using their systems. That can be a big difference in perspective.
A lot of good ideas have been presented, which I've been following with
IMO, a search for haplotype matches has relevance only if it is performed in
a dataset of its genetic peers. For someone looking out for genetic matches
all those other haplotypes belonging to haplogroups different than his own
are totally irrelevant.
Therefore, the efficient thing to do is to create not a single database but
multiple databases, at least one per haplogroup. Many of the problems
associated with Ysearch and FTDNA's databases stem from their size. They
are getting to be unmanageable not only for the number of records but from
the number of simultaneous queries that they have to serve from an ever
growing number of users. And the problem will only get worse because
genetic distance and TMRCA calculations with extended haplotypes can be
So what's my suggestion? Create a working database model for one haplogroup
and then replicate it for as many as necessary, each in its own subdomain.
Everyone will be much happier, I'm sure.
The E-M35 Database
|Re: [DNA] PUBLIC Y-DNA DATABASE by Victor Villarreal <>|