Re: Relational-to-OOP Tax

topmind wrote:
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.

In the procedural languages I've seen I still have to create structures of some kind to work with the data in the GUI.

Can you post a link to code that edits a record in a GUI that doesn't use structures of any kind in a procedural language? Even a link to a procedural API to do this would be useful.

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.)

Are you thinking that you just use a database driver to connect to the database and use the database itself to store the entire state of the relational model without any structures at all and just always query the database to get the current state?

Are you thinking business logic is implemented as triggers on tables?

All edits on a screen would just send updates as SQL to the database immediately. The GUI would commit when the user presses a save button, or rollback if the user presses cancel?

That style of application can be written in both OO, and procedural without classes, or structures.

I would seriously question the application style because it requires constant database queries which will negatively impact performance. It also causes long running transactions which will have deadlock issues.

Jeff Brooks
.