public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michał Kłeczek <[email protected]>
To: Peter J. Holzer <[email protected]>
Cc: [email protected]
Subject: Re: Lookup tables
Date: Fri, 7 Feb 2025 09:22:13 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
> On 6 Feb 2025, at 22:03, Peter J. Holzer <[email protected]> wrote:
>
> On 2025-02-04 22:41:38 +0100, Thiemo Kellner wrote:
>>
>> I might see what you want to point out. E.g. the table is COLOURS. The
>> rec with id 1 is RED, the one with id 2 is BLUE, 3 is GREE and so on.
>> Now you load these values into the dropdown box that sports RED, BLUE,
>> GREE and so on. While someone selects GREE, there is a maintenance
>> release changing GREE to YELLOW. So when that someone sends the
>> selection by id to the backend, not GREE is selected but YELLOW.
>
> I fail to see why use of a surrogate key is the problem here.
>
> Either changing the color from GREE to YELLOW makes sense or it doesn't.
>
> If it doesn't make sense, then it's release which is faulty, not the
> model.
>
> if it does make sense (I'm a bit at a loss when that might be the case,
> maybe the "color" is just a code word, or maybe they are colors in a
> design which are arbitrary but must be consistent), then the experience
> that the user has is exactly the same as if the maintenance release was
> applied just after they selected the color. Which might be a bit
> confusing but is almost certainly what is wanted.
>
This is simply saying “what is implemented is certainly wanted, so what’s the point”.
The discussion is about *defining* what is wanted and using DBMS to *enforce* that.
>
>> A) Your release changed the sementics of the record 3. It's meaning
>> changed. I cannot recommend doing that.
>
> If the release changed the semantics of an existing record the release
> was almost certainly wrong.
Is it possible to minimize the risk of “wrong releases” using mechanisms that DBMS provides?
>
>> B) If you absolutely must change the semantic, put your application
>> into maintenance mode in which noone can select anything beforehand.
>>
>> If the maintenance would just correct the typo from GREE to GREEN,
>> nothing would happen. Yor customer still ordered the lavishly green
>> E-Bike her hear ever desired.
>
> Yeah, that's a good example where changing the color from GREE to YELLOW
> doesn't make sense. Presumably that ID 3 is used as a foreign key in
> lots of places, e,g. in an inventory table. Your bikes in stock won't
> just magically change color just because you changed some text in the
> database. So that change simply doesn't make sense and shouldn't be done
> as part of a maintenance release. Confusing a few people who just happen
> to open the dropdown in the wrong second is the least of your problems.
We are in agreement here. What I am also saying is:
having color name as PK and all FKs referencing it *prevents* these unwanted updates.
—
Michal
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Lookup tables
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox