Rearrange representation of person's names in the database

anselm commented

2022-01-16 23:43:42 +01:00

(Migrated from gitlab.anselms.net)

Various people in the SCD community change their names during the course of their life, e.g., by marriage or divorce. The database represents this, somewhat clumsily, by having a separate Person record for each of a person's identities and a self-referential same_as foreign key to link any previous ones to the current one. This of course violates the principle that every entity should have only one database entry.

The proposed fix to this situation is to separate the Person record from a person's name(s), which will be represented by a separate PersonName table. Every Person can have several PersonNames, with one PersonName record designated as the "preferred" one. The content of the "preferred" PersonName will be displayed when a person's name is called for, while the other PersonNames will be useful for searching.

One situation that must be dealt with is the one where person X devises and publishes a dance (or tune, or album, …) and then changes her name to Y. We will have to figure out whether the dance should be credited to Y (because that is the current name of the deviser) or X (because that's what it says on the leaflet or book). The former case would be easier to implement but the latter would be more accurate. It would, however, require us to add an author_name foreign key to PersonName to each situation (dances, publications, albums, …) where there is now an author foreign key to Person, which would be a hassle. Alternatively, dances etc. could point to a NamedPerson table which would contain keys to the Person as well as the PersonName records pertaining to that particular dance. In this setup, NamedPerson would effectively take on the rôle of today's Person table. It remains to be seen whether this will be reasonably efficient to implement. (Note: Dances etc. could just as well point to PersonName instances, since going from NamedPerson to Person instead of from PersonName to Person would presumably be equally (in)efficient.)

While we're changing the way names are associated with people, we can also fix the representation of names themselves. It would, for example, be useful to separate people's first and last names (Note: Or not – see this page) and to cater for nicknames ("Torf"). There should be a way to represent a person's preferred designation which is independent from their actual name. Finally, some Person entries describe entities which are not actually individuals (e.g., the RSCDS or various dance bands). It might be worth adding a field to distinguish between "person", "group of persons", and "non-person entity".

Various people in the SCD community change their names during the course of their life, e.g., by marriage or divorce. The database represents this, somewhat clumsily, by having a separate `Person` record for each of a person's identities and a self-referential `same_as` foreign key to link any previous ones to the current one. This of course violates the principle that every entity should have only one database entry. The proposed fix to this situation is to separate the `Person` record from a person's name(s), which will be represented by a separate `PersonName` table. Every `Person` can have several `PersonName`s, with one `PersonName` record designated as the "preferred" one. The content of the "preferred" `PersonName` will be displayed when a person's name is called for, while the other `PersonNames` will be useful for searching. One situation that must be dealt with is the one where person X devises and publishes a dance (or tune, or album, …) and then changes her name to Y. We will have to figure out whether the dance should be credited to Y (because that is the current name of the deviser) or X (because that's what it says on the leaflet or book). The former case would be easier to implement but the latter would be more accurate. It would, however, require us to add an `author_name` foreign key to `PersonName` to each situation (dances, publications, albums, …) where there is now an `author` foreign key to `Person`, which would be a hassle. Alternatively, dances etc. could point to a `NamedPerson` table which would contain keys to the `Person` as well as the `PersonName` records pertaining to that particular dance. In this setup, `NamedPerson` would effectively take on the rôle of today's `Person` table. It remains to be seen whether this will be reasonably efficient to implement. (**Note:** Dances etc. could just as well point to `PersonName` instances, since going from `NamedPerson` to `Person` instead of from `PersonName` to `Person` would presumably be equally (in)efficient.) While we're changing the way names are associated with people, we can also fix the representation of names themselves. It would, for example, be useful to separate people's first and last names (**Note:** Or not – see [this page](https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/)) and to cater for nicknames ("Torf"). There should be a way to represent a person's preferred designation which is independent from their actual name. Finally, some `Person` entries describe entities which are not actually individuals (e.g., the RSCDS or various dance bands). It might be worth adding a field to distinguish between "person", "group of persons", and "non-person entity".

anselm commented

2022-01-16 23:43:50 +01:00

(Migrated from gitlab.anselms.net)

mentioned in issue #26