Re: oo vs procedural model
Daniel Pitts wrote:
There aren't so many tools to
manipulate already persisted object definitions, but most RDBMS allow
you to manipulate the name and number of existing columns.
Can you explain in more detail what you mean by this? What confuses me
is "object definitions" and "name and number of existing columns"
The trouble becomes, OO land is arguable easier (flexible) to actually
model business logic in,
I dont think its oo systems that makes it so much easier, i think its
more a consequence of the programming language. plsql (oracle), for
example, is not worth much as a "programming language", but it suitable
for database stored procedures. The reason is it doesnt have all the
expressiveness of e.g. java or all the premade libraries etc. Of course
one can programm procedures as many languages such as java, c, python
etc. The language decides how efficient it is, e.g. c procedures can
utilise db internal c functions and get native speed. In java and python
I suspect it has to go trough a translation layer.
Really, its a hard problem to solve, because there is a disconnect
between Relational systems and OO systems, and how they operate. You
can find a single subset of both systems, but then you've severely
limited the expressiveness and power of both systems, to the point of
almost uselessness.
I know, thats why I prefer to do db centric tasks in a database oriented
way, so the db layer of the application becomes a set of DAOs and the
parsers needed to convert to and from the db data model.
That is not an easy problem to solve (believe me, smart people have
tried), so we're stuck with an imbetween "ORM" layer, that translates
between the two systems. The trouble comes when you try to forget about
the translations, or the "other" layer (depending on your POV). Really,
you have an Application, that is built out of a Relational Model, and a
Object Oriented Domain Model, and a Translation Between The Two.
I know, but that is a discussion I will save for later.
regards
tom