> On 4 Feb 2025, at 17:51, Karsten Hilbert <Karsten.Hilbert@xxxxxxx> 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 These are of course problems ( and beyond the scope of my contrived example ). The point is though, that having surrogate PK not only does not solve these issues but makes them worse by kicking the can down the road and allowing for inconsistencies. — Michał
