On 2/4/25 09:51, Karsten Hilbert wrote:
> Am Tue, Feb 04, 2025 at 05:31:13PM +0100 schrieb Michał Kłeczek:
>
>> It is now completely unclear what it means to change the name of the restaurant for already registered visits.
>> Is it still the same restaurant with a different name or a different restaurant?
>>
>> Or let say someone swaps names of two restaurants.
>> That means a user that goes to the same restaurant every day would register visits to two different restaurants!
>>
>> Using the name of a restaurant as primary key gets rid of these logical anomalies because
>> the database model now reflects facts from reality.
> Reality tends to become so ambiguous as to not be
> reflectable (two entirely different restaurants eventually,
> within the flow of time, carry the very same name).
>
> A primary key is very likely not the proper place to reflect
> arbitrary business logic (is it the same restaurant or not ?
> what if two restaurants have the same name at the same time
> ?). Primary keys are tools at the technical level.
>
> Karsten
> --
> GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
>
>
That OP is using a single column is interesting: Taking this notion to
the restaurant/visit theme, the list of names or restaurants becomes a
proper table 'restaurant' (name, addresss, phone, website, etc). The
name is as useless as a key as first/last is for person.
