Hi Max,
I am not an active data collector (yet) and have little exposure to the data on planefinder.net. I came here hoping to cooperate for a research project for which I was looking for historic flight data. ... now to your question.
I fully support your finding. From a database perspective the aircraft registration (in colloquial terms: the tail number) and a flight identification (information used by ATC when coded in ICAO, or on ticket/airport basis when coded in IATA) are two different "data items" (= values).
From a "tidy data" perspective they should sit in different columns/fields and should not confused to be the same (also their values might be the same as in your example).
Please note that across the globe, it is common practice to use the aircraft registration as the flight identification - mostly for light types (smaller aircraft) and/or VFR flights. In some cases (smaller) commercial operations do also not make use of a separate flight identification. This practice goes basically back to the requirements of a flight plan.
Coming back to the "tidy data" paradigm, I also suggest to remove the hyphen or any other separator (or combinator) in the aircraft registration. These "extra" symbols are conventions. E.g. in various countries you will find a (2) leading letters, for example Germany D-AIGE or D-EFKE. In this example even the use of the letter "A" and "E" has a meaning. However, this does not apply globally (and is beyond the scope of this post).
What is important that - in terms of flightplan or flight identification - the registration is communicated as DAIGE or DEFKE.
In this example is it very likely that the aircraft DAIGE will operate a flight (connection between two airports) as DLH123 (ICAO coding) or LH123 (IATA coding). The light type, will typically not operate with a separate flight identifier (but could).
The latter point (removal of extra symbols as part of the aircraft registration) might contradict what you hoped for. However, the data selection problem would be solved by identifying clearly 2 different data items, i.e. 1. aircraft registration and 2. flight identification.
A respective database search would have to look for one or the other, or work on both data items. This way, database design and data use (i.e. query) are properly differentiated. (This will also work, if the hyphen is kept).
From a database perspective another "temporal" phenomena needs to be addressed on top. Registrations can (and will change). Thus, today's DAIGE or DEFKE might not be the same aircraft tomorrow (e.g. aircraft sale or transfer under new authority). This is the reason why the 24-bit address/hexcode was perceived as a unique aircraft/airframe identification. I leave it to the purist to discuss to what extent this is (long-term) unique and/or how group hexcodes (primarily for state aircraft) are dealt with.
Nonetheless, the example shows that a database would need to capture also the validity period of such "identifiers".
Hope this helps a bit to rethink (long-term) database design/requirements.
Happy New Year to all !
Rainer
P.S. Sorry for using bold print. But I wanted to stress the different concepts that seem to be mixed here.
