Re: Relational-to-OOP Tax

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

Many do, but it is not necessary.

It's not necessary in OO either.

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?

http://www.oscommerce.com/solutions/downloads

PHP doesn't have the construct SELECT INTO, so arrays has to be used
to represent one row in a query result. osCommerce also use classes as
data structures in some scenarios, but mostly not.

OO can use results in arrays as well for return results from the database.

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?

This is the basic idea in the relational model. The application asks
for data using relational algebra, when it needs it.

The problem is if every access requires a database query there is a lot of database queries (latency, shared resource contention).

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

Business logic may be implemented in tables (base relations),
constraints, views (derived relations), triggers, stored procedures or
application code - in that preferred order.

I disagree with your preferred order but all of those can be done using an OO language as well.

No difference there between OO, and procedural there.

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?

The database doesn't need to be remote. The host programming language
may have relational algebra built-in and an light-weight embedded
database engine.

Post a link to any language that does this please.

I would seriously question the application style because it requires
constant database queries which will negatively impact performance.

Only if the application and database are different processes.

What type of application are you thinking about? It appears this debate is about using an OO language to access a relational database and the costs of doing it. The general scenario is software written in an OO language on the client talks to a remote database.

Jeff Brooks
.