Diving Log Database Structure

[lloyd_borrett]

G'day Sven,

Henrik came up with a bug in phpDivingLog, and thankfully a workaround.

divesites.php doesn't handle multiple countries properly.

In phpDivingLog, I lookup the Place table for the dive site. Then I use the CountryID field to lookup the corresponding details in the Country table.

But I only have one Country record, with ID = 1 and LogID = 0.

In my Place table, all of my CountryID values are 0. So I assumed the CountryID field in the Place table matched the LogID field in the Country table. But it turns out this is not so.

Henrik has multiple countries, but divesites.php is showing all sites as being in the one country.

It seems that in Diving Log, you don't actually use the CountryID field in the Place table. Is this true?

Also, I now have no idea as to what the LogID field in the Country table is actually used for, if at all. Can you please explain?

We have found that we can use the ID value from the Place table to lookup the Country and the CountryID in the Location table. Then the CountryID field in the Location table matches the ID field in the Country table.

So we have a workaround.

But it would be nice if in future versions of Diving Log, you did populate the CountryID field in the Place table with the correct value so that a direct lookup can be done into the Country table. (I'm assuming that is what the field is there for.)

Similarly, I am looking at adding support for dive buddies information into a later version of phpDivingLog. Is it the case that the Country field in the Buddy table must have a corresponding record in the Country table? It would be nice if it did, but I can't tell from the database structure.

Best Regards, Lloyd Borrett

[divinglog]

It seems that in Diving Log, you don't actually use the CountryID field in the Place table. Is this true?

That's true. This field is for a future feature to link dive places, cities and countries, but this isn't implemented at the moment. The LogID field is also unused, I think this is unnecessary and I have forgotten to delete it in the beginning of the database design of version 4.0.

Kind regards,
Sven