Re^2: Update XML Values using two primary keys

In the context of database like storage they are indeed two primary keys even though they represent one point. That single point may be associated with multiple entries in the "database" even if it is a single point (assuming of course it represents a point on a two dimensional substantially unfolded surface).

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Comment on Re^2: Update XML Values using two primary keys

Replies are listed 'Best First'.
Re^3: Update XML Values using two primary keys by hippo (Archbishop) on Jan 06, 2021 at 09:49 UTC
They could both be keys but I don't see how they could both be primary unless combined into a single primary key as jcb suggested. Do you happen to use or know of a database that supports multiple primary keys on the same table? 🦛	[reply]
Re^4: Update XML Values using two primary keys by jcb (Parson) on Jan 06, 2021 at 23:31 UTC
Logically, the primary key here is a "geographic point" type, but SQL does allow a primary key to be declared as an arbitrary tuple of multiple columns in the same table. The `PRIMARY KEY` constraint must be written as a table constraint instead of a column constraint to do this. For our questioner's example, and assuming a database that does not directly support lat/long coordinates (i.e. not Postgres with PostGIS installed), there could be a table like: (untested) `CREATE TABLE tags ( lat numeric(24,20), lon numeric(24,20), name text, PRIMARY KEY(lat, lon));` [download]	[reply] [d/l] [select]