Re: Lookup tables

> On 5 Feb 2025, at 19:07, Thiemo Kellner <thiemo(at)gelassene-pferde(dot)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