reaanb2
Joined 8 years ago
Karma
32
Submissions
24
Member since
Aug 6
Recent submissions
Comment · 2 months ago
This article describes the OOP approach that leads to object-relational mapping, boilerplate code, database schema duplicated in code, navigational data access and the impedance mismatch. It defines OOP around data modeling and taxonomy, rather than around responsibilities. Principles such as "Tell, don't ask" and "Single responsibility" are just ignored. What responsibility does a book have in a library management system? It doesn't, it's just a subject of recorded facts, and a better approach would be to identify the behavioural components of the solution space, construct those as classes/objects, and let facts be encapsulated in or communicated between objects.
Comment · 2 months ago
It's not a new or exotic conceptualization, it's a recovery of the semantics that Codd had in mind and well defined in fact-oriented modeling approaches like object-role modeling / NIAM and FCO-IM. It provides conceptual parsimony: attributes are just relationships between entities and values, and n-ary relationships are handled consistently rather than being reduced to binary relationships, among other things. And if more people adopted this, we might get better data abstraction layers incorporated into development frameworks than object-relational mappers (which should rather be renamed to "network data model to SQL mappers").
Comment · 2 months ago
Can we also move on from speaking about rows as if they're vertices in the conceptual model graph, and start treating them as n-ary associations / facts?
Comment · 3 months ago
FCO-IM elegantly bridges the gap between data and language. Has anyone tried/compared SQL query generation based on that?
Comment · 3 months ago
We had general-purpose graph databases before graph databases became a thing. I'm talking about relational databases. Values are the vertices, tuples are the edges, FK constraints are inclusion dependencies. In fact, n-ary relations means a hypergraph database, not just a binary graph db.
Comment · 1 year ago
Trying to placate the gods who are busy destroying their world...
Comment · 1 year ago
A better solution would be to move away from object-oriented domain modeling towards SQL-speaking entity-component systems.
Comment · 1 year ago
That's a cool approach that could work well if you don't need realtime data validation such as in a UI. I would love to find a solution that allows the same validation rules to be used in the DBMS as well as in the backend and frontend code.
Comment · 1 year ago
I disagree. From a fact-oriented modeling perspective, relationships among entities are already well-modelled and represented in tables. There's a reason the relational model calls tables relations - they relate things. The mistake here is viewing tables/rows as representing entities, FK constraints as representing relationships, and viewing entities as containers of attributes rather than the subjects of facts.
Joining tables is composing complex facts from simple ones, and is the opposite of normalization which is decomposing complex facts into simpler ones. The ability to join tables on arbitrary conditions is fundamental to the ability to ask a DBMS complex questions and have it respond with all the facts that match that question.
Comment · 1 year ago
In my view, the O/R impedance mismatch derives from a number of shortcomings. Many developers view entities as containers of their attributes and involved only in binary relationships, rather than the subjects of n-ary facts. They map directly from a conceptual model to a physical model, bypassing logical modeling. They view OOP as a data modeling system, and reinvent network data model databases and navigational code on top of SQL.
Comment · 1 year ago
See https://arxiv.org/abs/2312.00638 for one proposal to address this
Comment · 1 year ago
In real life, insurance often doesn't pay for everything and service providers would need to support capturing both sets of info, not either one or the other. But that's beside the point.
Properly naming check constraints can go a long way towards providing better error messages, and then there are stored procs which can be used to ensure that multiple tables are updated as a single logical step. It would've been nice if SQL supported literal values in FK constraints, e.g. FOREIGN KEY (id, 'uninsured') REFERENCES patients(id, payment_type), as well as exclusion constraints, e.g. FOREIGN KEY (id) NOT REFERENCES insured_payment_info(id). As it stands, my preferred approach would be combining approach 4 with stored procs, except I would make id the primary key and (id, payment_type) a unique key.
Comment · 1 year ago
EF is limited to binary relationships: https://learn.microsoft.com/en-us/ef/core/modeling/relations.... When entities are mapped to rows and relationships to foreign key constraints, it results in a network data model interpretation of SQL databases. The relational model is better conceptualized from a fact-oriented modeling perspective, in which entities map to values, domains to FK constraints, relationships to the association of two or more entity sets in a table, and rows represent propositions about entities rather than entities themselves. However, non-binary relationships don't easily translate into navigational data access (cf. Bachman's paper "The programmer as navigator" about the network data model) and a logical view is difficult for the non-mathematical programmer, while structs and pointers are naïvely easy to understand, that's why ORMs remain popular. The impedance mismatch is less about mapping flat to rich data structures than about the network data model vs fact-oriented perspectives and row-at-a-time vs batch data access.
Comment · 1 year ago
"Object-relational mapper" is a misnomer, they should be called network data model to SQL mappers. They're not primarily for mapping between different arrangements of the same data, but about recreating a network data model perspective. How many ORMs support composite primary keys and non-binary relationships?
As you said, the challenge of understanding math is why the relational vision failed, but also why the industry keeps reviving the network data model.