Extracting information from a webservice

[Pierre-Yves Chibon]

On Wed, 2013-01-23 at 16:01 +0100, Aurélien PRALONG wrote:
Oops sorry, I made it too quick.
> 
> I just thought the matching between server dives and subsurface dives
was
> too complicated. So I just suggered, on the server side, to add an
auto
> incremented primary key (=PK) in the dive database (=DB), and transmit
it
> to clients, so matching could be easy (string comparison).
> 
> We discussed of this with Pierre, and it appeared the key for dives
was a
> combination of diver / dive name. Maybe this change would break DB
> relationships or elsewhere ? If no, I think a row having it own key is
> cleaner for databases.
> 
I see two different issues here, the first is the database design and
the second is the gps <-> dive matching algorithm.
From a database design, using an incremental integer as primary key
might make sense.
From an algorithm point of view however, I am not sure it does. I think
you are implying that dive number in the web-service will correspond to
the dive number in the desktop application. Am I right?
If that was the case, the matching would be indeed much easier. But I
won't be the case as:
a) My divelog starts at 9, since I have made 8 dives before having my
dive-computer, so the first dive which I would have in the web-service
will not be the first in my divelog.
b) I might forget to bring my phone on the boat, or forget to turn it on
on site, therefore skipping a number between the web-service and the
client.
c) There are more than one person using the web-service, meaning if
dives #1 and #2 are yours, maybe #3 and #4 and #5 are actually from 3
different persons.

If you are not making this assumptions (dive # consistent across the
web-service and the client), then I do not quite see how having a unique
integer attached to each dive will help in the algorithm. Could you
elaborate?

Pierre