> On 5 Feb 2025, at 19:07, Thiemo Kellner <thi...@gelassene-pferde.biz> wrote:
>
> El 04-02-25 a las 18:08, Michał Kłeczek escribió:
>>> 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.
> Only if you do not see the primary key as the main immutable value
> identifying an object, entity, you name it.
Surrogate key cannot identify any (real) object by definition :)
What object is identified by PK value 42 in “restaurants” table?
> Having said that, it is very questionable that a natural key (names to name
> one) can be a suitable primary key (think of typo).
Typos are indeed a problem but adding surrogate key does not solve it, I’m
afraid.
—
Michal
