null == "" is true?

[Antonio]

On Wednesday, 20 July 2022 at 13:35:14 UTC, Kagamin wrote:
> On Tuesday, 19 July 2022 at 18:05:34 UTC, Antonio wrote:
>> In a relational database, `NULL` is not the same that `""`... 
>> and `NULL` is not the same that `0`.  Are semantically 
>> different and there are database invariants (like foreign 
>> keys) based on it.   Trying to "mix" this concepts in a 
>> database is a mistake.
>
> So, it's an implementation detail or a relational database that 
> leaks into business logic because nobody thought about it? Just 
> because a relational database has many features, it doesn't 
> mean business logic must use them all, it must use only what 
> makes sense for business logic.
>
It is not about "so many fetaures"... it is about entity model 
and how relational database stores it.   General purpose 
programming languages include their own representation to the 
NULL concept that is not "relational model" dependent:  Optional, 
Maybe, Nullable, Union types

> What semantics your domain models implement? Is it semantics of 
> all features of a relational database or is semantics of 
> business logic?

Database is an **strict repository**:  it stores the entity model 
with relational semantics including strict invariant management 
(primary keys, foreign keys, field types, nullablility, ...) and 
following normalization rules (3th normal form, at least).  It 
is, basically, a "consistent" model.

Business logic **trust on database repository invariants** and 
implements whatever your Business Model require (i.e.:  complex 
model operations involving multiple repository operations).  
Business works using Objects/Entities of the domain and it is 
required a way to map this to relational model (ORM or manual 
SQL)... Usually in a specific "Data" or "DAO" layer.  
Transactions are your friend (The only way to ensure that high 
level invariants are enforced)

If you can't be confident with database invariants (because you 
are using NoSQL repository like MongoDB or DynamoDB or an Old 
ISAM MySQL or "trash" models over relational engine) then you 
need to "move" all these "consistency" control to the business 
layer developing workflows/processes that must be ready to work 
with "inconsistent" data...  (You can read this article I wrote 2 
years ago about SQL/NoSQL solutions and Brewer's conjecture: 
https://qr.ae/pvklQA)


Business "architecture" based on a single repository is the 
simplest one...  But the pleasure of trusting on a relational 
database is always welcome.