> On 5 Feb 2025, at 19:07, Thiemo Kellner <thiemo@xxxxxxxxxxxxxxxxxxxx> 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
