> Now you dont know exactly what field to check.
Yes you do - you have a helper method that encapsulates the details.
In the DB you could also make a view or generated column.
> This is just micro-optimization for no good reason
It’s conceptually simpler to have a representation with fewer states, and bugs are hopefully impossible. For example what would it mean for the bool authorized to be false but the authorized date time to be non-null?
> In the DB you could also make a view or generated column.
Or you could just use a boolean with a natural self describing name.
My proposal is to use a null date.
Did you miss the part about contradictory states? Are you going to add some database constraints to your book instead?
If you need to store a value that has two states, use a boolean, don't overcomplicate it unless there is real value in creating the complication (which there is value, sometimes).
Regarding contradictory states:
Given that just about no DB is in 5th normal form, the possibility of contradictory states exist in almost every RDBMS, regardless of booleans. It seems like an argument that doesn't really have any strength to it.
> If you need to store a value that has two states, use a boolean
Please refer to the article for context of this discussion.
Because the databases you have worked in are bad means we should not teach or advocate for correct data structure design?
> Because the databases you have worked in are bad
You understand my point about 5th normal form, right? 99.99999999% of all databases are in approx (averaged across all tables) somewhere between 2.5 and 3rd normal form.
This means there are many examples in most databases of data that is implied by some other combination of data elements.
Do you store the calculated discounts and net selling price for line items after running the order through the promotion engine? Most system do store things like that because people need to consume that data and it's either impractical or not possible for each consumer to run the data through the promotion engine every time they need to use that data.
Same thing goes for the total invoice qty, amount, taxes, etc.
This is one small example of the type of data dependencies that exist throughout most complex systems.