Re: Relational-to-OOP Tax

Jeff Brooks wrote:
topmind wrote:
Patrick May wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Schemas *usually* change for the same reasons as application code
In simple CRUD and reporting systems, possibly. In enterprise
systems where the database supports multiple applications and smaller
components, no.

Schemas should mostly only change if the *business rules* or structure
of the biz changes. If a new rule trickles to other apps, then it
trickles to other apps because a change in biz is a change in biz.
Again, we would like to see specific common change scenarios. We are
not going to take your word for it, because you are a sneaky dog.

What do you think is the alternative to the relational-to-OOP tax?

Procedural code doesn't map well relational databases either.

Is there actually a good relational language that can be used to build

Complaining about how relational-to-OOP isn't perfect is moot if there
isn't anything better.

With procedural, you don't have classes as middle-men between the app
code and the schema. The schemas *are* the "classes". The "noun model"
is in the database, not classes. With OO, you have the class noun
structure/model and the database noun structure/model which are fairly
similar (we are assuming existence of RDBMS), but different enough
that you spend time translating between the two. If you embrace the
DB, you don't have this verbose, code-wasting middle man.

And you are less likely to have to build and manage complex structures
in RAM. (I used to sometimes use tables for local, temporary stuff
also, before they removed such features due to OO hype.)

Jeff Brooks