Station id

[isedwards]

@DenisStuber wrote:

About the technical design of the data and the meta models. All the different Ids of a station (WMO [new and old], local[s], ICAO, etc.) could or should be unique but they shall not be used as a primary key to specify, internally in the system, a station. The primary key of a station shall not represent any semantic information e.g. an incremental value. All information part of the future Graphic User Interface should have the possibility to be modified, included the Ids type, and I would add with a multi-language design.

[jaggh]

I mostly agree. But I do not see great inconveniencies if local Ids are used as primary keys, as long as they are short numeric or alphanumeric (ASCII characters in this case) and free from spaces and punctuation characters...

[DenisStuber]

In fact, Ids used commonly in Met Services have most often a meaning e.g. WMO Ids. This meaning is subject to modification (administrative, location, etc.). So, once you choose as a primary key (PK) an Ids for a station that has a meaning, when the meaning is changing you will not be able to change the PK, or with great difficulty.
It is much more convenient and flexible to have a PK without any meaning. You are able to trace the different histories of Ids e.g. from date_1 to date_2 such station has had such Id.
We found some articles that mention such database good practices. I will try to get those.

[jaggh]

Yes, it is clear that PK should not be changed along the history of a station. In AEMET local climatological IDs are only 4-5 characters long: HNNNx, where x is an optional letter, NNN is a number (left padded with zeros if needed) and H, the only character with a semantic meaning, refers to the main hydrological basin, which is not expected to change in forthcoming centuries... :)     Jose El 31/8/21 a las 12:37, DenisStuber escribió: In fact, Ids used commonly in Met Services have most often a meaning e.g. WMO Ids. This meaning is subject to modification (administrative, location, etc.). So, once you choose as a primary key (PK) an Ids for a station that has a meaning, when the meaning is changing you will not be able to change the PK, or with great difficulty. It is much more convenient and flexible to have a PK without any meaning. You are able to trace the different histories of Ids e.g. from date_1 to date_2 such station has had such Id. We found some articles that mention such database good practices. I will try to get those. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#16 (comment)", "url": "#16 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]