Re: Relational-to-OOP Tax

topmind wrote:
Patrick May wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Schemas *usually* change for the same reasons as application code
changes.
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 software?

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

Jeff Brooks
.

Relevant Pages

  • Re: Relational-to-OOP Tax
    ... In simple CRUD and reporting systems, ... What do you think is the alternative to the relational-to-OOP tax? ... is in the database, not classes. ... structure/model and the database noun structure/model which are fairly ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... In simple CRUD and reporting systems, ... Schemas should mostly only change if the *business rules* or structure ... trickles to other apps because a change in biz is a change in biz. ...
    (comp.object)
  • Re: Parts List and Inventory Software
    ... Always done it that way, too, since day one of my biz. ... Stick with a common database format, don't use spreadsheet software for that job. ...
    (sci.electronics.design)