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.
