Another significant milestone – in July our database grew to contain
more than one million records of individuals, and the current count is
1,045,419. Thank you to everybody who
has submitted their GED files, and especially well done to Tony Cairns who has
been very busy ferreting out data that can be loaded into the GDB. In fact, we’d probably have had more except
that I had to tell Tony to slow down, as our growth brought with it some
problems. Which leads to: -
NZGDB had started as experimental programming using spare capacity on a
friend’s server, but we’ve well and truly outgrown this. As the size of our database grew, and our
application demanded more and more capacity, we started to experience
instability and failures, not only in NZGDB, but also in the other systems
sharing this server. As a result, I’ve
ordered our own server. This will
allow us to increase the level of service, with better response, fewer
failures, and effectively unlimited data capacity. NZGDB could probably grow to 50 or 100 times its present size on
the new server before we need to go through this exercise again.
Next month I’ll expect to be telling you that the new server is all
installed and running, but with any luck you won’t need me to tell you because
you should have already noticed how much faster the system is. I also hope that the increased speed will be
sufficient to allow me to experiment with new search options that are simply
impractical at the moment, such as searching for people by facts (for example,
immigrants to NZ between dates). There will be a few days, perhaps a week,
where NZGDB will not be available for update, although you’ll still be able to
access it, as we change servers.
Exciting stuff! But it means
that NZGDB must get serious about covering its costs: -
We promised that NZGDB would be free until the end of the year, and viewing
(and updating) your own records would always be free. We will keep these promises, but we have to find a way of
covering our costs. Our current plan
is to charge a small annual membership fee, but with a credit for loading
data. For example, if you load a GED
with 2000 records then you’d get a year’s free membership. We’d also welcome sponsorship and group
membership proposals. Hopefully we can keep the charge very low and still pay
our costs and to buy the professional services that we need to improve the
site. Subscription will allow you to view other people’s public records:
without a subscription you’d be limited to your own records and the
indexes. All this means that I have to
develop code to take payments and manage subscriptions, but at least I have a
few months to do so.
We’d appreciate some feedback.
Would you be prepared to support us if the annual subscription was: -
$20 $30 $40 $50 More
than $50?
Are there any vital facilities that it currently lacks that must be
provided before you’d be prepared to subscribe? Just click Reply, and let us
know what you think.
We already have several users who, at 2000 records per year, will have
qualified for free membership for life, so we need lots of others if we’re
going to pay our way. So tell all your
friends if you like this site! Tell us
if you don’t – and tell us what we can do to make it better.
In the meantime, I’ve been busy on other software changes: -
Previously the search required you to enter a person’s family name, but
this could create difficulties when you knew a woman only by her married name
so we’ve implemented the ability to enter either a person’s family name, or
their spouse’s family name. Thus you
can search for my grandmother as
or as
Fortunately this was implemented in a neutral way, because I found it
unexpectedly useful for men. Within my
ancestry some names are very common name: for example, a search for John OLD
will return many records even from one GED, and as there have been several
GED’s submitted dealing with this line of ancestry the amount of duplication
finding the particular record that you want can be quite difficult. Adding the partner’s name: -
makes the search much more precise.
When combined with a particular owner, this will return a single
record. Eureka!
Previously if you re-submitted your GED file, this completely replaced
everything that you had submitted before.
Thus suppose I submitted a GED called Barnes.Ged that included
individuals Robert, Mary, and Rachel.
I then granted permissions to others to see these (live people) records,
and added some photos and documents.
Others discover these records and link (“Duplicate”) to them.
But suppose that I update my desktop database. It’s now out of step with NZGDB, and so I resubmit the GED. With the previous logic, the earlier
records were completely wiped from NZGDB and new records created. This meant that all of the on-line updating
– creating permissions, adding photos, documents, and duplicate links, and any
other changes that I’d made on line – were all lost.
This has all changed. Now you
can update a GED, which means that all the previous records are retained, but
the facts and family relationships are updated by the resubmitted GED. Thus if I resubmit Barnes.Ged, this time
containing Robert, Mary, and Hannah then the Robert and Mary records will be
updated, Rachel will be unchanged, and Hannah will be added. All the permissions and softlinks (photos,
documents, and links) will remain unchanged.
You should use the Replace option only when your records have become so
messed up that the only way to proceed is to delete them and start again.
Not only does this preserve the online updates, it can be far more
efficient. I can update my desktop
database, and then submit just the one family.
I can submit some of my records, and then some more later. Provided that I use the same name for the
GED, and it comes from the same desktop database, then it will neatly slot into
my previous records. For example, everything
that I produce from my Barnes.FTW (Family Tree Maker) database will be
submitted to the system as “Barnes.ged”, whether it is the whole database, one
family, or even just one record.
An added bonus: if the GED is very small, as it would be for an update,
then you will have an option to have it processed immediately instead of
waiting for the overnight processing.
I’ve been working on facilities to make it easy to manage the
duplication – update records so that they record the same facts, and combine
trees to reduce duplication. These
facilities didn’t quite make it for this month, but you can read what’s coming
at http://www.nzgdb.co.nz/help/gdb5_help.htm. I’d love to hear from you if you’re willing
to go through this and help me test it out when it’s released for testing in
about a week. I’m struggling to find a
way of making it easy to use while preserving essential principles such as
record ownership.
What would you
like us to develop next? What is
important to you? Have a look at http://www.nzgdb.co.nz/help/Current%20Status.htm
for our current plans, and then tell us what we should do first. We have a list a mile long (well, at least
100 items anyway) of things we might add to the system, so helping us to sort out
the priorities would be very useful. We don’t promise to do what you want, but
we will at least listen.