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.
