Mixing P/R philosophy with OO (within J2EE).
Harry
Assuming:
1. we are very much within the custom-business software niche; and
2. we are developing a J2EE-based application...
1. What strategies would OO-critics (such as TopMind) and P/R fans (if
any here other than TopMind) advise to avoid needless translations
between OO and Relational paradigms? Ref: http://www.geocities.com/tablizer/core1.htm
2. TopMind appears to make some very interesting points on OO and P/R
on the above site. However, how many of these ideas can actually be
realized today, say, within the J2EE world... where if you do
something even slight 'out of the ordinary' (like deciding to not
using Hibernate/Kodo in favor of embedding direct JDBC calls in your
business tier), you tend to not reap the full benefits that might have
otherwise come for 'free', today or in future, by sticking to normal
use of the platform. That is, from what I understand, once you are
in J2EE (or .NET) world, your best bet (as one of my friends suggests)
is to stick to everything plain and normal and common-sense, and to
not try any new architectural/design stunts unless they stand
sufficiently proven. (An example of the last point would be Stored
Procedures: a 'normal' J2EE developer would want to code the SPs
within the business tier (in Java) instead of in the RDBMS tier in
vendor-specific SQL... with the rationale being... the database can be
easily switched from let's say mySQL to Oracle to XYZ with zero or
minimal work overnight!)
I apologize for the J2EE-specific nature of my question... but these
days most folks are using only either J2EE or .NET for developing
enterprise class applications! And, on J2EE and .NET forums, no one
would have a clue about TopMind and his P/R insights. Hence, any
practical advice on the APIs, layers, etc that could be conveniently /
elegantly skipped (and, similarly P/R-centric software, APIs, etc that
could be used) to speed up enterprise class application design and
development would greatly put things in perspective for me.
Thanks.
Thomas Gagne
I've written a couple essays on the subject of another way for OO and
RDB to work together, based off, unfortunately, a concept of
transactions. Unfortunate because the word transaction carries a lot of
luggage with it that has little to do with what's really happening under
the covers, and that's messages to the DB in the form of OO programs
affecting state changes through DB stored procedures.
Regardless, I'm developing a lecture for an upcoming Smalltalk
conference <http://www.it360.ca/smalltalk.cfm> based on those essays and
discussions in this newsgroup.
<http://blogs.in-streamco.com/anything.php?title=transaction_oriented_architecture_aka_th>
<http://blogs.in-streamco.com/anything.php?title=the_rdb_is_the_biggest_object_in_my_syst>
<http://blogs.in-streamco.com/anything.php?title=my_schema_is_an_class>
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
topmind
> Hello,
>
> Assuming:
> 1. we are very much within the custom-business software niche; and
> 2. we are developing a J2EE-based application...
>
>
> 1. What strategies would OO-critics (such as TopMind) and P/R fans (if
> any here other than TopMind) advise to avoid needless translations
> between OO and Relational paradigms? Ref: http://www.geocities.com/tablizer/core1.htm
>
> 2. TopMind appears to make some very interesting points on OO and P/R
> on the above site. However, how many of these ideas can actually be
> realized today, say, within the J2EE world... where if you do
> something even slight 'out of the ordinary' (like deciding to not
> using Hibernate/Kodo in favor of embedding direct JDBC calls in your
> business tier), you tend to not reap the full benefits that might have
> otherwise come for 'free', today or in future, by sticking to normal
> use of the platform.
Before we get into the politics of Java, there is something ironic
about O/R wrappers like Hibernate: they are almost more complex than
the RDBMS itself. Thus, one is wrapping the DB with something that is
practically a DB engine *itself*. Is being married to Hibernate less
of a sofware engineering change-flexibility "sin" than being married
to Oracle or PostGreSQL? I never figured out the "logic" behind such.
It appears to be hypocritical to me. I compare it to hiding behind
Dracula to avoid being attacked by Frankenstein. Databases tend to
outlast languages, or at least are switched at roughly the same
frequency as languages. Thus, vendor-swap math doesn't seem to favor
it.
> That is, from what I understand, once you are
> in J2EE (or .NET) world, your best bet (as one of my friends suggests)
> is to stick to everything plain and normal and common-sense, and to
> not try any new architectural/design stunts unless they stand
> sufficiently proven. (An example of the last point would be Stored
> Procedures: a 'normal' J2EE developer would want to code the SPs
> within the business tier (in Java) instead of in the RDBMS tier in
> vendor-specific SQL... with the rationale being... the database can be
> easily switched from let's say mySQL to Oracle to XYZ with zero or
> minimal work overnight!)
If you mean "go against the flow", there is indeed career problems
with that. You seem to be asking a social/political question rather
than a technology one. Java fans will tend to think and act a certain
way with their tools and expect things a certain way. If you go
against "Java culture", you indeed may put yourself in hot water. It
is probably easier to leave the Java culture than to change it. I've
busted my balls trying to run from the OO hype, and it has indeed hurt
my career. Attacking Sacred Cows risks getting yourself caught in a
hamberger grinder. I advise others to just go with the flow if you
like money. You may have to choose between money and truth.
However, when some new fad comes along and OOP/Java looks like COBOL 2
to everybody, you may be in a better position. I suspect the pendulum
will swing back to data-centric techniques (like it was in the
mid-80's) away from OO's code-centric techniques.
>
> I apologize for the J2EE-specific nature of my question... but these
> days most folks are using only either J2EE or .NET for developing
> enterprise class applications! And, on J2EE and .NET forums, no one
> would have a clue about TopMind and his P/R insights.
My detractors here want to keep it that way :-)
> Hence, any
> practical advice on the APIs, layers, etc that could be conveniently /
> elegantly skipped (and, similarly P/R-centric software, APIs, etc that
> could be used) to speed up enterprise class application design and
> development would greatly put things in perspective for me.
>
> Thanks.
Good luck in your choices.
Arne Vajhøj
> Before we get into the politics of Java, there is something ironic
> about O/R wrappers like Hibernate: they are almost more complex than
> the RDBMS itself. Thus, one is wrapping the DB with something that is
> practically a DB engine *itself*. Is being married to Hibernate less
> of a sofware engineering change-flexibility "sin" than being married
> to Oracle or PostGreSQL? I never figured out the "logic" behind such.
> It appears to be hypocritical to me. I compare it to hiding behind
> Dracula to avoid being attacked by Frankenstein. Databases tend to
> outlast languages, or at least are switched at roughly the same
> frequency as languages. Thus, vendor-swap math doesn't seem to favor
> it.
It does if you are in the product business as opposed to
the project business.
Because then the resistance to change database actually
favors tools that encapsulate the database specifics.
Customer X may only buy your product if it runs on top
of database A. They do not care what persistence framework
you use to be able to support database A, B, C and D without
changing the application code.
In cases like that a persistence framework is a real
benefit.
Arne
Thomas Gagne
> topmind wrote:
>> Before we get into the politics of Java, there is something ironic
>> about O/R wrappers like Hibernate: they are almost more complex than
>> the RDBMS itself. Thus, one is wrapping the DB with something that is
>> practically a DB engine *itself*. Is being married to Hibernate less
>> of a sofware engineering change-flexibility "sin" than being married
>> to Oracle or PostGreSQL? I never figured out the "logic" behind such.
>> It appears to be hypocritical to me. I compare it to hiding behind
>> Dracula to avoid being attacked by Frankenstein. Databases tend to
>> outlast languages, or at least are switched at roughly the same
>> frequency as languages. Thus, vendor-swap math doesn't seem to favor
>> it.
>
> It does if you are in the product business as opposed to
> the project business.
creating some vendor-specific linkages to take advantage of features in
each?
Can your product be shipped with a DB engine? Does your product need to
integrate with other of a customer's data?
What kind of throughput do you need? Are concessions made in either the
DB model or the OO model so you can use OR wrappers? If your OO product
didn't exist would the DB model be identical?
Is vendor independence a feature of your current product or a desired
feature of your next one?
Harry
> You're tongue-in-cheek suggests you don't buy that approach. I agree.
I do buy and, in fact, like most of his arguments on OO hype, noun-
oriented class design issues, etc. However, in absence of real tools,
API, (language support?) that encourage P/R style, you can't really do
much, can you? Unless there's an industry-wide initiative to revive P/
R mode of thinking, feeling, and acting a handful or two of ordinary
developers (like myself) can't really go upstream... :-)
I don't have language designing / compiler writing skills myself, so
can't really think in-depth / critically of all issues that would /
could later surface in TOP for large scale, real-world projects.
However, language designers (of major languages such as C++, Java,
Perl, Ruby...) would already have these skills, and I hope they have
considered TOP related arguments.
I think it was ANSI C++ that made popular the generic programming
style... which is heavily template-based, in which collections (data
structures) and algorithms are kept separate (though still as
objects)... which, imho, was a radical break from the usual OOD
thinking prevalent in the mid-90s (which, if I'm correct, was always
to club functions together with data without exception) . So, circa
1993, an applications developer in a pure OO shop couldn't have tried
STL-like stunt in his business modeling. (I think.)
> I've written a couple essays on the subject of another way for OO and
> RDB to work together, based off, unfortunately, a concept of
> transactions. Unfortunate because the word transaction carries a lot of
> luggage with it that has little to do with what's really happening under
> the covers, and that's messages to the DB in the form of OO programs
> affecting state changes through DB stored procedures.
Will surely check them out, thanks.
topmind
Databases are far more than "persistence" if you use them to their
potential. If you *only* treat it as a dumb filing system and do most
of the collection-oriented handling by building complex data
structures in app code, then you are reinventing the wheel. Many OO
designs seem to do this. Complex data structures (such as objects
pointing to objects) should not really be needed often if you use the
DB right.
Plus, you didn't answer the issue of trading marriage to a DB vendor
into being married to Hibernate. If the language carries its own
database engine (which is just about what hibernate is), then you
might as well ship the product with a specific RDBMS, such as MySql or
PostgreSQL to get a consistent DB engine.
>
> In cases like that a persistence framework is a real
> benefit.
If one more OO fan calls RDBMS "persistence" mechanisms, I will
personally bop them. File systems are "persistence mechanisms". RDBMS
are attribute managers, domain noun modelers, and they "encapsulate"
common collection-oriented idioms into a semi-standard tool, rather
than reinvent them from scratch like OO likes to do.
>
> Arne
-T-
Harry
> It appears to be hypocritical to me. I compare it to hiding behind
> Dracula to avoid being attacked by Frankenstein.
:-)
> Databases tend to outlast languages, or at least are switched at roughly the
> same frequency as languages. Thus, vendor-swap math doesn't seem to favor
> it.
Is this really true? I believe switching of databases (assuming you
have zero stored procedures) would relatively be far, far less painful
than switching of languages, for rewriting code is non-trivial
compared to migrating raw table data. Because of this, if given a
choice, wouldn't you switch databases more frequently than languages?
> If you mean "go against the flow", there is indeed career problems
> with that.
I mentioned your OO-debunking site to another developer friend of
mine. And, so OO-brainwashed is he apparently that he's not even
willing to take a look, :-)
> I advise others to just go with the flow if you like money. You may have to
> choose between money and truth.
While I'll go for the money right now, will keep poking at the truth
in the background. I promise.
Thomas Gagne
> On Apr 3, 6:52 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
>
>> You're tongue-in-cheek suggests you don't buy that approach. I agree.
>>
>
> I do buy and, in fact, like most of his arguments on OO hype, noun-
> oriented class design issues, etc. However, in absence of real tools,
> API, (language support?) that encourage P/R style, you can't really do
> much, can you? Unless there's an industry-wide initiative to revive P/
> R mode of thinking, feeling, and acting a handful or two of ordinary
> developers (like myself) can't really go upstream... :-)
>
suggests Fortran can be written in any language.
Personally, our shop makes little effort to map our object data into our
database. There's just little need for it since we don't interact with
the DB that way. As the articles suggest, we communicate to the DB
through stored procedures, which may be peculiar to OLTP systems but
I've used the same approach with other applications (portfolio
management) without problem.
An advantage to interacting with the DB through stored procedures is the
strong analogy to how OO programmers are encouraged to interact with
their own objects with methods (message sends). Nearly as easy as
sending a message to an object to invoke some functionality or affect a
state change within that object we send messages to our database to to
invoke functionality and affect state changes within the DB.
> I don't have language designing / compiler writing skills myself, so
> can't really think in-depth / critically of all issues that would /
> could later surface in TOP for large scale, real-world projects.
> However, language designers (of major languages such as C++, Java,
> Perl, Ruby...) would already have these skills, and I hope they have
> considered TOP related arguments.
>
I'm unsure it's necessary since most languages are general purpose.
It's not language syntax that gets in the way but our (mis)conceptions
of the solution. If one pictures the application as a projection of the
DB's model or the DB as a projection of the application's model then
that's the solution they'll work towards--trying to reconcile a single
model across two very different representations with different and
not-always-complimentary natures. When programmers being struggling
with this reconciliation, even with the aid of O/R mapping tools and
multiple layers of abstraction, they suspect something may be amiss with
either OO or RD--but not their preconceptions.
So common is this problem that it's been given a name: the
object-relational impedance mismatch. Not everyone likes the name, but
they all grapple with it whenever they attempt to give objects the
responsibility to persist themselves into an RDB and instantiate
themselves from same.
Thomas Gagne
> On Apr 3, 9:37 pm, "topmind" <topm...@technologist.com> wrote:
>
>
>> It appears to be hypocritical to me. I compare it to hiding behind
>> Dracula to avoid being attacked by Frankenstein.
>>
>
> :-)
>
>
>> Databases tend to outlast languages, or at least are switched at roughly the
>> same frequency as languages. Thus, vendor-swap math doesn't seem to favor
>> it.
>>
>
> Is this really true? I believe switching of databases (assuming you
> have zero stored procedures) would relatively be far, far less painful
> than switching of languages, for rewriting code is non-trivial
> compared to migrating raw table data. Because of this, if given a
> choice, wouldn't you switch databases more frequently than languages?
>
company that changed its database vendor. Of course, these companies
didn't have applications--they had systems. And each enterprise
database was accessed by applications written in multiple languages.
It was also the case that many of these companies had multiple
databases. The most common of which was DB2 and Oracle.
So the cardinality I've witnessed is really many-to-many
(languages-to-DB vendors).
frebe
> oriented class design issues, etc. However, in absence of real tools,
> API, (language support?) that encourage P/R style, you can't really do
> much, can you?
The short is answer is: Use the LAMP stack.
Table oriented programming is not about new fancy tools, it is more
about not jumping into the layered mapping madness. If your
programming language allows you to use SQL, you have an working
environment. Next step is to use a (pre-) compiler that acutally
supports SQL. If use are using Java, SQLJ is a suitable tool. If you
are using C and Oracle, Pro*C is the tool to use, etc. Stored
procedures are another option. The third step is to use a RAD-tools
for more automatic generation of user interfaces. I can agree that it
is a shortage of production-ready RAD tools and SQL pre-compilers, but
the do exists. And if you don't find any suitable tools, just embedd
SQL statements as strings in your code (wherever you need it). It is
far better than O/R mapping.
/Fredrik
PS. Don't forget to use views as much as possible for writing business
logic.
frebe
> of database A. They do not care what persistence framework
> you use to be able to support database A, B, C and D without
> changing the application code.
The level of standardization in SQL is rather high. If you skip using
stored procedures and use ANSI SQL 92, entry level, you can switch
database rather painless.
> In cases like that a persistence framework is a real benefit.
If you only use a RDBMS for persistence, then it would obviously be
very easy to switch, with or without frameworks, because you are only
using 5% of the features.
/Fredrik
Harry
> PS. Don't forget to use views as much as possible for writing business
> logic.
Wouldn't it become a 2-tier arch then? A side question: can you step
thru a stored procedure in a debugger provided by the rdbms shell? (Is
there such a thing even?)
frebe
> > logic.
>
> Wouldn't it become a 2-tier arch then?
Yes and no. It is nothing wrong with a client calling the database
directly, but for some tasks, it is better if the client calls a
stored procedure or a service on the application server. The client
might call both a database and an application server. As a matter of
fact, the database is kind of an application server. Forcing all
client request to be proxied through a application server to the
database, is only stupid.
> A side question: can you step
> thru a stored procedure in a debugger provided by the rdbms shell? (Is
> there such a thing even?)
I don't know. I would guess that Oracle has such tools. Poor IDE
support didn't stop people from start using Java a decade ago. And it
doesn't stop people from using JavaScript now. Debuggers are a nice
thing to have, but the lack of debugger is not a show stopper.
/Fredrik
topmind
frebe wrote:
> > Customer X may only buy your product if it runs on top
> > of database A. They do not care what persistence framework
> > you use to be able to support database A, B, C and D without
> > changing the application code.
>
> The level of standardization in SQL is rather high. If you skip using
> stored procedures and use ANSI SQL 92, entry level, you can switch
> database rather painless.
It seems the vendors' documentation tends to "trick" one into using
their proprietary syntax and functions, downplaying the standard
approaches. I've found it hard to find documentation on writing vendor-
neutral SQL. (The ANSI documents are not very human-friendly and
require lots of coffee.)
>
> > In cases like that a persistence framework is a real benefit.
>
> If you only use a RDBMS for persistence, then it would obviously be
> very easy to switch, with or without frameworks, because you are only
> using 5% of the features.
>
> /Fredrik
-T-
gryphon_smg
> Arne Vajhøj wrote:
> > topmind wrote:
> > > Before we get into the politics of Java, there is something ironic
> > > about O/R wrappers like Hibernate: they are almost more complex than
> > > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > > practically a DB engine *itself*. Is being married to Hibernate less
> > > of a sofware engineering change-flexibility "sin" than being married
> > > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
will use that as the example. Hibernate is transparent persistence
for the business objects. I want my application to be independent of
the data source, since data can come from more places than the disk
store. So my business logic is not coupled to the RDBMS. Also,
Hibernate is not 'practically a DB engine *itself*.' It is a tool that
aids in letting my business objects be saved. It has none of the
attributes of a DBMS at all.
> > > It appears to be hypocritical to me. I compare it to hiding behind
> > > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > > outlast languages, or at least are switched at roughly the same
Data outlasts applications. Databases and languages change seldom. The
whole point in using ORM is to make use of the data that is available
in a timely fashion without requiring a change or addition in the
database. The domain model for the application may be different from
that of the database, so having an agile mapping system makes sense.
Applications change often, business rules change even more often.
Database change is slow and methodical and can be traumatic if not
handled carefully. We do not want to put frequently changing logic
into the DB, we want to put data into the DB.
> > > frequency as languages. Thus, vendor-swap math doesn't seem to favor
> > > it.
>
> > It does if you are in the product business as opposed to
> > the project business.
>
> > Because then the resistance to change database actually
> > favors tools that encapsulate the database specifics.
Absolutely
>
> > Customer X may only buy your product if it runs on top
> > of database A. They do not care what persistence framework
> > you use to be able to support database A, B, C and D without
> > changing the application code.
>
> Databases are far more than "persistence" if you use them to their
> potential. If you *only* treat it as a dumb filing system and do most
> of the collection-oriented handling by building complex data
> structures in app code, then you are reinventing the wheel. Many OO
> designs seem to do this. Complex data structures (such as objects
> pointing to objects) should not really be needed often if you use the
> DB right.
>
> Plus, you didn't answer the issue of trading marriage to a DB vendor
> into being married to Hibernate. If the language carries its own
> database engine (which is just about what hibernate is), then you
> might as well ship the product with a specific RDBMS, such as MySql or
> PostgreSQL to get a consistent DB engine.
In the case of Java (since that is the language we are talking about)
using a good DAO pattern, it is quite easy to switch the DB interface
layer. Much easier than switching DB's. But that argument is, IMO, a
red herring. I don't see DB switching as an issue. Because data is
such a huge company asset, the DBMS tends not to change. The real
benefit of ORM is that it allows easy use of relational-modeled data
in an OO language.
>
>
>
> > In cases like that a persistence framework is a real
> > benefit.
>
> If one more OO fan calls RDBMS "persistence" mechanisms, I will
> personally bop them. File systems are "persistence mechanisms". RDBMS
> are attribute managers, domain noun modelers, and they "encapsulate"
The relational model is not the domain model. It is a construct that
is mapped to a domain model. It happens to be mathematically sound
and very good at certain operations that conform to the underlying
math, and many of the implementations have done excellent jobs of
efficient storage, security and management of the space. That is what
they are good at. But don't tell me that the model as implemented in
the DB is THE MODEL. In fact, I would argue that a good OO Domain
Model is a better candidate for being THE MODEL than the relational
model. It has less restriction and more flexibility to reflect the
domain than the relational has. That does not mean that we throw the
relational model away, it means that it is another tool in our
developers' tool box that we use when appropriate.
An RDBMS *is* a persistence mechanism. It is a very good one. It is
a bad place to put application code and business logic. An OO program
is a good place to put application code and business logic. It is not
reinventing the wheel, it is using a tool for the purpose it is best
suited. In fact, doing it all in the DB is a case of the 'Golden
Hammer'.
topmind
gryphon_smg wrote:
> On Apr 3, 8:55 pm, "topmind" <topm...@technologist.com> wrote:
> > Arne Vajhøj wrote:
> > > topmind wrote:
> > > > Before we get into the politics of Java, there is something ironic
> > > > about O/R wrappers like Hibernate: they are almost more complex than
> > > > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > > > practically a DB engine *itself*. Is being married to Hibernate less
> > > > of a sofware engineering change-flexibility "sin" than being married
> > > > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
>
> Yes, it is much less of a sin. Since you are picking on Hibernate I
> will use that as the example. Hibernate is transparent persistence
> for the business objects.
Again, if you are using the RDBMS as ONLY a dumb object dumping
ground, then you may be right. However, many of us think it is a good
idea to use the RDBMS to its fuller potentially rather than reinvent
database idioms in app code and build ugly navigational structures
with a bunch of set/get red-tape on top.
> I want my application to be independent of
> the data source, since data can come from more places than the disk
> store.
RDBMS are not about disks. SQL is an *interface*. Hiding from one
interface (SQL) by using another (Hibernate) simply *trades* one
dependency for another, NOT rids net dependencies.
> So my business logic is not coupled to the RDBMS. Also,
> Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> aids in letting my business objects be saved. It has none of the
> attributes of a DBMS at all.
It is complicated middle-ware with some quasi-DB qualities.
>
> > > > It appears to be hypocritical to me. I compare it to hiding behind
> > > > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > > > outlast languages, or at least are switched at roughly the same
>
> Data outlasts applications. Databases and languages change seldom.
Then why the obsession with swapping?
> The
> whole point in using ORM is to make use of the data that is available
> in a timely fashion without requiring a change or addition in the
> database.
Use of app-specific tables, views, and/or databases is not forbidden.
If your DBA does not allow it, then that is an issue of internal
politics. Using objects to create a mini app-specific RAM database is
dumb in my opinion unless as a last resort. OO is crappy at managing
bunches of links between objects, creating navigational spegghetti
which is the Goto of the 2000's.
> The domain model for the application may be different from
> that of the database, so having an agile mapping system makes sense.
> Applications change often, business rules change even more often.
> Database change is slow and methodical and can be traumatic if not
> handled carefully. We do not want to put frequently changing logic
> into the DB, we want to put data into the DB.
Queries and Views are another technique to map the shared data to app-
specific or task-specific views.
> > > Customer X may only buy your product if it runs on top
> > > of database A. They do not care what persistence framework
> > > you use to be able to support database A, B, C and D without
> > > changing the application code.
> >
> > Databases are far more than "persistence" if you use them to their
> > potential. If you *only* treat it as a dumb filing system and do most
> > of the collection-oriented handling by building complex data
> > structures in app code, then you are reinventing the wheel. Many OO
> > designs seem to do this. Complex data structures (such as objects
> > pointing to objects) should not really be needed often if you use the
> > DB right.
> >
> > Plus, you didn't answer the issue of trading marriage to a DB vendor
> > into being married to Hibernate. If the language carries its own
> > database engine (which is just about what hibernate is), then you
> > might as well ship the product with a specific RDBMS, such as MySql or
> > PostgreSQL to get a consistent DB engine.
>
> In the case of Java (since that is the language we are talking about)
> using a good DAO pattern, it is quite easy to switch the DB interface
> layer. Much easier than switching DB's. But that argument is, IMO, a
> red herring. I don't see DB switching as an issue. Because data is
> such a huge company asset, the DBMS tends not to change. The real
> benefit of ORM is that it allows easy use of relational-modeled data
> in an OO language.
>
If swapping vendors is not the issue, so then what exactly *is* the
problem with using direct queries in the app?
> >
> > > In cases like that a persistence framework is a real
> > > benefit.
> >
> > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > personally bop them. File systems are "persistence mechanisms". RDBMS
> > are attribute managers, domain noun modelers, and they "encapsulate"
>
> The relational model is not the domain model. It is a construct that
> is mapped to a domain model.
Horsecrap. It is as much the domain model as a bunch of classes. This
is paradigm bias. (I will agree that some forms of "behavior" are best
at the app level, but this does not take away the general domain
modeling ability since we usually want most behavior at the app
level.)
> It happens to be mathematically sound
> and very good at certain operations that conform to the underlying
> math, and many of the implementations have done excellent jobs of
> efficient storage, security and management of the space. That is what
> they are good at. But don't tell me that the model as implemented in
> the DB is THE MODEL.
Maybe 70% of it.
> In fact, I would argue that a good OO Domain
> Model is a better candidate for being THE MODEL than the relational
> model.
Prove it. Show the code of it being better.
> It has less restriction and more flexibility to reflect the
> domain than the relational has.
Prove it. I agree that the "big iron" view of RDBMS popularized by
Oracle is sometimes restricting, but in a flexible organization it
does not have to be. "We use OO because our DBA is stubburn and slow"
is perhaps understandable, but is that the full justification?
> That does not mean that we throw the
> relational model away, it means that it is another tool in our
> developers' tool box that we use when appropriate.
>
> An RDBMS *is* a persistence mechanism.
Noooooo! Persistence is one of many aspects of a RDBMS. You OO'ers
have an obsession with disks.
> It is a very good one. It is
> a bad place to put application code and business logic. An OO program
> is a good place to put application code and business logic. It is not
> reinventing the wheel, it is using a tool for the purpose it is best
> suited. In fact, doing it all in the DB is a case of the 'Golden
> Hammer'.
So OO is the Golden Hammer? I don't think so.
Lew
> Use of app-specific tables, views, and/or databases is not forbidden.
> If your DBA does not allow it, then that is an issue of internal
> politics. Using objects to create a mini app-specific RAM database is
> dumb in my opinion unless as a last resort. OO is crappy at managing
> bunches of links between objects, creating navigational spegghetti
> which is the Goto of the 2000's.
This is exactly why the relational model supplanted the network model.
O-O "databases" were not very effective the first time they were proffered,
when they were called "network-model" databases.
--
Lew
Arne Vajhøj
> Arne Vajhøj wrote:
>> topmind wrote:
>>> Before we get into the politics of Java, there is something ironic
>>> about O/R wrappers like Hibernate: they are almost more complex than
>>> the RDBMS itself. Thus, one is wrapping the DB with something that is
>>> practically a DB engine *itself*. Is being married to Hibernate less
>>> of a sofware engineering change-flexibility "sin" than being married
>>> to Oracle or PostGreSQL? I never figured out the "logic" behind such.
>>> It appears to be hypocritical to me. I compare it to hiding behind
>>> Dracula to avoid being attacked by Frankenstein. Databases tend to
>>> outlast languages, or at least are switched at roughly the same
>>> frequency as languages. Thus, vendor-swap math doesn't seem to favor
>>> it.
>> It does if you are in the product business as opposed to
>> the project business.
> How many databases are you planning to support?
????
I am not planning on supporting anything.
I am saying that the "you do not change database" arguments
validity depends on whether you are doing a product or a project.
> Have you considered
> creating some vendor-specific linkages to take advantage of features in
> each?
????
I am expecting the persistence framework used to do just that.
> Can your product be shipped with a DB engine? Does your product need to
> integrate with other of a customer's data?
Often using the customers database is a requirement for either data
sharing or operational reasons.
> What kind of throughput do you need? Are concessions made in either the
> DB model or the OO model so you can use OR wrappers? If your OO product
> didn't exist would the DB model be identical?
????
It should be rather obvious that is an O/R mapper is used
then an O/R mapper can be used.
> Is vendor independence a feature of your current product or a desired
> feature of your next one?
????
I am talking in general terms about O/R mappers like
Hibernate.
Arne
Arne Vajhøj
I disagree.
> Plus, you didn't answer the issue of trading marriage to a DB vendor
> into being married to Hibernate. If the language carries its own
> database engine (which is just about what hibernate is), then you
> might as well ship the product with a specific RDBMS, such as MySql or
> PostgreSQL to get a consistent DB engine.
Actually I did answer it. Try and read it again.
> If the language carries its own
> database engine (which is just about what hibernate is), then you
> might as well ship the product with a specific RDBMS, such as MySql or
> PostgreSQL to get a consistent DB engine.
Nonsense.
You are ignoring all data sharing and operational aspects.
>> In cases like that a persistence framework is a real
>> benefit.
>
> If one more OO fan calls RDBMS "persistence" mechanisms, I will
> personally bop them. File systems are "persistence mechanisms". RDBMS
> are attribute managers, domain noun modelers, and they "encapsulate"
> common collection-oriented idioms into a semi-standard tool, rather
> than reinvent them from scratch like OO likes to do.
Databases are used for persisting data. The other stuff is there
to help doing that.
Arne
Arne Vajhøj
>> Customer X may only buy your product if it runs on top
>> of database A. They do not care what persistence framework
>> you use to be able to support database A, B, C and D without
>> changing the application code.
>
> The level of standardization in SQL is rather high. If you skip using
> stored procedures and use ANSI SQL 92, entry level, you can switch
> database rather painless.
Not true.
functions
locking
identity/sequences
>> In cases like that a persistence framework is a real benefit.
>
> If you only use a RDBMS for persistence, then it would obviously be
> very easy to switch, with or without frameworks, because you are only
> using 5% of the features.
It is not.
Arne
Arne Vajhøj
> In my experience (24 years) I've never seen, visited, or consulted a
> company that changed its database vendor.
It do happen.
But not that frequently.
Arne
frebe
> >> of database A. They do not care what persistence framework
> >> you use to be able to support database A, B, C and D without
> >> changing the application code.
>
> > The level of standardization in SQL is rather high. If you skip using
> > stored procedures and use ANSI SQL 92, entry level, you can switch
> > database rather painless.
>
> Not true.
>
> functions
I already made an exception for stored procedures.
> locking
Do claim that different SQL databases implement locking so different
that it is not possible to write SQL statements that works for
different vendors?
> identity/sequences
Yes, som databases vendors handles sequences in a strange way, but it
is pretty easy to encapsulate the use of sequences in functions that
could be switched when the datababase vendor is switched.
The fact that there are some SQL statments that are different for
different vendors, doesn't mean that you have to put all SQL
statements into a separate switchable layer.
Do you have some more examples of differences in SQL syntax between
vendors? Your list is rather short and the issues you point out is
very easy to solve.
/Fredrik
frebe
> for the business objects. I want my application to be independent of
> the data source, since data can come from more places than the disk
> store.
A database and a disk store is two very different things. If you want
to create independence between these two, you can only use smallest
common denominator.
> So my business logic is not coupled to the RDBMS.
As much business logic as possible should be implemented using
predicate logic and set therory (relational algebra).
> Also,
> Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> aids in letting my business objects be saved. It has none of the
> attributes of a DBMS at all.
It has a query language which is more or less a copy of SQL.
> Data outlasts applications.
Indeed. That is why we doesn't need to care so much about being able
to switch database.
> Databases and languages change seldom.
Languages changes more often.
> The domain model for the application may be different from
> that of the database,
Most programming languages only support domain models using the
network model. The relational model is much more powerful for
modelling your domain.
> Applications change often, business rules change even more often.
> Database change is slow and methodical and can be traumatic if not
> handled carefully.
As long as you don't break backward compatibility, changes in the
database schema may be very fast. Views may change very quickly.
> We do not want to put frequently changing logic
> into the DB, we want to put data into the DB.
We want to put as much business logic in the DB, as views, as
possible. Changing view is not traumatic.
> > > In cases like that a persistence framework is a real
> > > benefit.
>
> > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > personally bop them. File systems are "persistence mechanisms". RDBMS
> > are attribute managers, domain noun modelers, and they "encapsulate"
>
> The relational model is not the domain model.
What is wrong with set theory and predicate logic? Do you like pointer
better?
> It is a construct that is mapped to a domain model.
????
> It happens to be mathematically sound
> and very good at certain operations that conform to the underlying
> math,
An exellent reason why we should use it for implementing business
logic.
> and many of the implementations have done excellent jobs of
> efficient storage, security and management of the space.
They have done an excellent job of implementing business logic too.
> That is what
> they are good at. But don't tell me that the model as implemented in
> the DB is THE MODEL. In fact, I would argue that a good OO Domain
> Model is a better candidate for being THE MODEL than the relational
> model. It has less restriction and more flexibility to reflect the
> domain than the relational has.
Please give some examples.
> An RDBMS *is* a persistence mechanism.
Does the statement
select customerid, sum(amount) as total
from customers c join orders o on o.customerid=c.customerid
having total > 2000
have anything to do with persistence?
> It is
> a bad place to put application code and business logic. An OO program
> is a good place to put application code and business logic.
Some motivation please...
/Fredrik
Eugene Kalenkovich
> /Fredrik
>
> PS. Don't forget to use views as much as possible for writing business
> logic.
>
Can you please elaborate a little more here? What are the major benefits of
views (other than job security)?
-- EK
Thomas Gagne
have a requirement for DB neutrality. You brought up the difference
between creating a product or working on a project. I was just asking
questions to come to more specifics. Since this is Harry's thread and
not yours those questions are probably better directed at Harry, or
anyone else thinking vendor neutrality may be a design requirement.
frebe
> to help doing that.
OO people uses databases for persisting data. The rest of us use it
for a lot of other things too.
/Fredrik
frebe
Views plays the same role as functions or methods in imperative
programming languages. They encapsulates logic that may be reused. For
example, lets say we are building a payroll application, we would have
tables (base relations) for data entered by the users, like in/out
punches, absence reports, etc. But as much as possible of the derivied
data, like net pay and tax, would be calculated using views.
/Fredrik
gryphon_smg
> gryphon_smg wrote:
> > On Apr 3, 8:55 pm, "topmind" <topm...@technologist.com> wrote:
> > > Arne Vajhøj wrote:
> > > > topmind wrote:
> > > > > Before we get into the politics of Java, there is something ironic
> > > > > about O/R wrappers like Hibernate: they are almost more complex than
> > > > > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > > > > practically a DB engine *itself*. Is being married to Hibernate less
> > > > > of a sofware engineering change-flexibility "sin" than being married
> > > > > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
>
> > Yes, it is much less of a sin. Since you are picking on Hibernate I
> > will use that as the example. Hibernate is transparent persistence
> > for the business objects.
>
> Again, if you are using the RDBMS as ONLY a dumb object dumping
> ground, then you may be right. However, many of us think it is a good
dumping ground. It has no 'further potential'. If you add to it, it
is then an RDBMS and procedural programming language.
> idea to use the RDBMS to its fuller potentially rather than reinvent
> database idioms in app code and build ugly navigational structures
What is being reinvented?
> with a bunch of set/get red-tape on top.
>
> > I want my application to be independent of
> > the data source, since data can come from more places than the disk
> > store.
>
> RDBMS are not about disks. SQL is an *interface*. Hiding from one
> interface (SQL) by using another (Hibernate) simply *trades* one
> dependency for another, NOT rids net dependencies.
Wrong! RDBMS's are all about disks. I want my application code to
completely isolated from the source. My business logic should work on
the domain model, and not be tied to the source of the data or how it
comes or goes. Then I can use the same logic throughout the
enterprise.
>
> > So my business logic is not coupled to the RDBMS. Also,
> > Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> > aids in letting my business objects be saved. It has none of the
> > attributes of a DBMS at all.
>
> It is complicated middle-ware with some quasi-DB qualities.
Name the quasi-DB qualities.
>
>
>
> > > > > It appears to be hypocritical to me. I compare it to hiding behind
> > > > > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > > > > outlast languages, or at least are switched at roughly the same
>
> > Data outlasts applications. Databases and languages change seldom.
>
> Then why the obsession with swapping?
>
> > The
> > whole point in using ORM is to make use of the data that is available
> > in a timely fashion without requiring a change or addition in the
> > database.
>
> Use of app-specific tables, views, and/or databases is not forbidden.
> If your DBA does not allow it, then that is an issue of internal
> politics. Using objects to create a mini app-specific RAM database is
> dumb in my opinion unless as a last resort. OO is crappy at managing
OO is phenomenally good at creating associations between objects. I
can include all of the FKR of the tables in on object and then treat
the assembly as a whole. That is the point of OO programming. ORM
does not imply a RAM database (although the 2nd level cache in
Hibernate is a huge boost). The DBS's primary concern is the
integrity of the data. If we are embedding application logic into the
database that can challenge that, then the DBA is correct in
forbidding it. It is not politics, it proper.
> bunches of links between objects, creating navigational spegghetti
> which is the Goto of the 2000's.
That sounds like a competence of implementation problem, not an issue
with the underlying model. Anyone can write bad code in any
language. For this discussion, I am assuming that the programmer is
capable writing quality code.
>
> > The domain model for the application may be different from
> > that of the database, so having an agile mapping system makes sense.
> > Applications change often, business rules change even more often.
> > Database change is slow and methodical and can be traumatic if not
> > handled carefully. We do not want to put frequently changing logic
> > into the DB, we want to put data into the DB.
>
> Queries and Views are another technique to map the shared data to app-
> specific or task-specific views.
But once again, they are tied to the database. My users are not
supposed to work on the database, and do not have the qualifications
to do so. We use views for filtering data sets and creating
alternative displays, but to create an order, a view is no better than
the query that defines it and is still not the natural way the the
users expect it. It is also easier to program against one object than
11 tables.
It couples the application directly to database, it imposes the
relational structure of the data onto an OO language and it crosses
concerns.
>
>
>
> > > > In cases like that a persistence framework is a real
> > > > benefit.
>
> > > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > > personally bop them. File systems are "persistence mechanisms". RDBMS
> > > are attribute managers, domain noun modelers, and they "encapsulate"
>
> > The relational model is not the domain model. It is a construct that
> > is mapped to a domain model.
>
> Horsecrap. It is as much the domain model as a bunch of classes. This
> is paradigm bias. (I will agree that some forms of "behavior" are best
> at the app level, but this does not take away the general domain
> modeling ability since we usually want most behavior at the app
> level.)
Wrong. It is a rigid mathematical structure that we use to store
data. An orderitem is part of an order, not a FKR. The domain model
is a model of the enterprise we are trying to automate. It is not
amenable to the restrictions of set theory, normalization or
relational algebra. All of those are restrictions on the model to put
it into an RDBMS. Your 'bunch of classes' are types that reflect the
components that we are modeling (the database has a single type:
table) with the type of relationships the have in the real world (As
opposed to FKR in the database). So it is a much better representation
to the user of the business. The relational model is very good for
persistence modeling, but that is its intention. Once again, trying
to extend it is the 'Golden Hammer' problem.
>
> > It happens to be mathematically sound
> > and very good at certain operations that conform to the underlying
> > math, and many of the implementations have done excellent jobs of
> > efficient storage, security and management of the space. That is what
> > they are good at. But don't tell me that the model as implemented in
> > the DB is THE MODEL.
>
> Maybe 70% of it.
?? What does that mean?
>
> > In fact, I would argue that a good OO Domain
> > Model is a better candidate for being THE MODEL than the relational
> > model.
>
> Prove it. Show the code of it being better.
Consider the classic Orders example. As a relational model it has
tables for Orders, Addresses, Orderitems, Orderitemattributes,
Shipping, Payment, and Tracking. They are associated with each other
through a series of FKR's. To implement in Java, I design a set of
classes. The Instance of the classes has all of the information I need
for that order and none that does not relate to it. I can apply the
business rules to the object or can write methods on the object that
implement the rules. But in anycase, my object is complete. I do not
have to navigate any relationships, I do not get duplicate information
with my joins. Most importantly, I do not have collect and build my
model one piece at a time.
To populate the object using direct queries will multiple queries as I
navigate the FKR's and pulling the results out of the rows that I
retrieve. Once I have applied my business logic, I have to do the
same with the updates. Using Hibernate, I request the Order by its
id, Apply the logic, and save it.
Using an ORM is not free. You have have a good domain object model to
start with, and do the mappings and queries that they use; this
requires talent and dedication. But you do that once and from then on,
you can use it again and again and again. I use one set of domain
models across multiple applications, so I amortize the up front
effort. For a new application, having this saves me 30% of my time
and all of the database access code that I would have to write. It is
easier for new programmers to come up to speed with a consistent
model, and we no longer have SQL embedded willy-nilly through the code
base.
In summary: it is better because it is more flexible, easier to
understand (and hence maintain), and more modular. Game Set Match.
>
> > It has less restriction and more flexibility to reflect the
> > domain than the relational has.
>
> Prove it. I agree that the "big iron" view of RDBMS popularized by
> Oracle is sometimes restricting, but in a flexible organization it
> does not have to be. "We use OO because our DBA is stubburn and slow"
> is perhaps understandable, but is that the full justification?
No we use it because it is faster to develop and more flexible. It
allows our business analysts to try new ideas easier and as a bonus,
our DBA is pretty happy about it as well.
>
> > That does not mean that we throw the
> > relational model away, it means that it is another tool in our
> > developers' tool box that we use when appropriate.
>
> > An RDBMS *is* a persistence mechanism.
>
> Noooooo! Persistence is one of many aspects of a RDBMS. You OO'ers
> have an obsession with disks.
No we have an obsession with using the right tool for the right job.
>
> > It is a very good one. It is
> > a bad place to put application code and business logic. An OO program
> > is a good place to put application code and business logic. It is not
> > reinventing the wheel, it is using a tool for the purpose it is best
> > suited. In fact, doing it all in the DB is a case of the 'Golden
> > Hammer'.
>
> So OO is the Golden Hammer? I don't think so.
No, I don't either. I use the relational database for what it is good
for, an OO Language for what it is good for, an ORM tool for what it
is good for. The database is good for storing data in a
mathematically structured format. It is good at managing that store
reliably for a long time. It is not good at rapidly changing business
logic.
As an analogy, I once (a long time ago) worked with a man who was a
Fortran programmer. He wrote a compiler in Fortran, and tried to use
that as an argument that we did not need any other programming
language: Fortran could do it all. My response was (and it) just
because you can do something, doesn't mean you should. The same
applies to putting business logic into the DB. Sure, I can write my
business logic in stored procedures in the DB, but it is a bad place
to do so. It links business logic to data, and as stated earlier,
data stays, business logic changes often. It also ties your business
logic to the database platform. It forces you to implement you program
in a language that the DB vendor supports in the DB.
The biggest problem is that it pushes the design of the what ever
application you creating to look just like the database structure.
This is the case with things like Oracle forms, but also any tool that
tries to do code generation for CRUD based on the Relational Schema.
The Relational model is suited for efficient storage and retrieval of
table based data, but this model is not particularly natural for
people (especially non-programmers) to use. When I create an order
management application, the end user is interested in treating the
order as a whole, not one screen for customer billing, one for
customer shipping, one for each line item and another for shipping
information. I can write a Hibernate mapping that treats an order as
a single object, apply business logic to the order, not having to
follow FKR's to each part. Validate the object as whole and the
persist it to the underlying DBMS. Then, using a reporting tool, my
coworkers can do metrics and statistics on the same database.
Tomorrow, when my product manager comes to me and announces that we
have a new promotion to add to the business logic, I can implement the
new logic either in my Order object (not ideal) or in my rules engine
(much better), and deploy the change quickly with out affecting the
carefully designed and tuned database.
>
>
>
> > > common collection-oriented idioms into a semi-standard tool, rather
> > > than reinvent them from scratch like OO likes to do.
Please explain.
>
> > > > Arne
>
> -T-
gryphon_smg
> > Hibernate is transparent persistence
> > for the business objects. I want my application to be independent of
> > the data source, since data can come from more places than the disk
> > store.
>
> A database and a disk store is two very different things. If you want
> to create independence between these two, you can only use smallest
> common denominator.
>
> > So my business logic is not coupled to the RDBMS.
>
> As much business logic as possible should be implemented using
> predicate logic and set therory (relational algebra).
persistent, business logic changes frequently. We want to apply
business logic in the business application, not in the database. We
do, however want to express it in the predicate logic format; that is
what a rules engine is for. In fact, they are a much more appropriate
tool for them than stored procedures in your data base.
>
> > Also,
> > Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> > aids in letting my business objects be saved. It has none of the
> > attributes of a DBMS at all.
>
> It has a query language which is more or less a copy of SQL.
So?
>
> > Data outlasts applications.
>
> Indeed. That is why we doesn't need to care so much about being able
> to switch database.
>
> > Databases and languages change seldom.
>
> Languages changes more often.
>
> > The domain model for the application may be different from
> > that of the database,
>
> Most programming languages only support domain models using the
> network model. The relational model is much more powerful for
> modelling your domain.
No, it is actually much less powerful. What it is is much more well
defined and formalized and predicatable. It is a good model for
managing relations and references, but that is all.
>
> > Applications change often, business rules change even more often.
> > Database change is slow and methodical and can be traumatic if not
> > handled carefully.
>
> As long as you don't break backward compatibility, changes in the
> database schema may be very fast. Views may change very quickly.
views are not data.
>
> > We do not want to put frequently changing logic
> > into the DB, we want to put data into the DB.
>
> We want to put as much business logic in the DB, as views, as
> possible. Changing view is not traumatic.
No, we want to keep all of the business logic in one, authoritative
place. Once you split responsibility, you are no longer sure which
implementation is correct (The man with one watch knows what time it
is, the man with two is never sure). Unless you database implements a
rules engine internally, no business logic should be in the database.
Never split responsibility.
>
> > > > In cases like that a persistence framework is a real
> > > > benefit.
>
> > > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > > personally bop them. File systems are "persistence mechanisms". RDBMS
> > > are attribute managers, domain noun modelers, and they "encapsulate"
>
> > The relational model is not the domain model.
>
> What is wrong with set theory and predicate logic? Do you like pointer
> better?
Actually, I like objects better, at least for programming. I like set
theory just fine. It works well for defining a relation model of my
business domain. It is rather poor for creating a general domain
model. It is very poor for expressing the world as the end users
understand it.
>
> > It is a construct that is mapped to a domain model.
>
> ????
>
> > It happens to be mathematically sound
> > and very good at certain operations that conform to the underlying
> > math,
>
> An exellent reason why we should use it for implementing business
> logic.
No, it is a excellent reason for putting our persistent data in
mathematically sound storage system. But that is all the database is.
>
> > and many of the implementations have done excellent jobs of
> > efficient storage, security and management of the space.
>
> They have done an excellent job of implementing business logic too.
They have done a very marginal job implementing business logic. And a
terrible job of quickly adjusting to new business requirement.
Remember the constraints in the relational model are relational
constraints, not business logic.
>
> > That is what
> > they are good at. But don't tell me that the model as implemented in
> > the DB is THE MODEL. In fact, I would argue that a good OO Domain
> > Model is a better candidate for being THE MODEL than the relational
> > model. It has less restriction and more flexibility to reflect the
> > domain than the relational has.
>
> Please give some examples.
>
> > An RDBMS *is* a persistence mechanism.
>
> Does the statement
> select customerid, sum(amount) as total
> from customers c join orders o on o.customerid=c.customerid
> having total > 2000
>
> have anything to do with persistence?
Only to the extent that it is meaninless without it.
>
> > It is
> > a bad place to put application code and business logic. An OO program
> > is a good place to put application code and business logic.
>
> Some motivation please...
See above. Summary: Use the right tool for the right job. Do not share
responsibility. Be agile.
>
> /Fredrik
topmind
gryphon_smg wrote:
> On Apr 4, 2:09 pm, "topmind" <topm...@technologist.com> wrote:
> > gryphon_smg wrote:
> > > On Apr 3, 8:55 pm, "topmind" <topm...@technologist.com> wrote:
> > > > Arne Vajhøj wrote:
> > > > > topmind wrote:
> > > > > > Before we get into the politics of Java, there is something ironic
> > > > > > about O/R wrappers like Hibernate: they are almost more complex than
> > > > > > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > > > > > practically a DB engine *itself*. Is being married to Hibernate less
> > > > > > of a sofware engineering change-flexibility "sin" than being married
> > > > > > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
> >
> > > Yes, it is much less of a sin. Since you are picking on Hibernate I
> > > will use that as the example. Hibernate is transparent persistence
> > > for the business objects.
> >
> > Again, if you are using the RDBMS as ONLY a dumb object dumping
> > ground, then you may be right. However, many of us think it is a good
> The RDBMS is not a dumb object dumping ground; it is a smart object
> dumping ground. It has no 'further potential'. If you add to it, it
> is then an RDBMS and procedural programming language.
>
> > idea to use the RDBMS to its fuller potentially rather than reinvent
> > database idioms in app code and build ugly navigational structures
>
> What is being reinvented?
Structures and structure-handling idioms.
>
> > with a bunch of set/get red-tape on top.
> >
> > > I want my application to be independent of
> > > the data source, since data can come from more places than the disk
> > > store.
> >
> > RDBMS are not about disks. SQL is an *interface*. Hiding from one
> > interface (SQL) by using another (Hibernate) simply *trades* one
> > dependency for another, NOT rids net dependencies.
>
> Wrong! RDBMS's are all about disks.
Not. Some RDB companies are developing RAM-only RDBMS for certain
kinds of applications. Persistence is one of *many* uses for a DB,
and not a necessary one.
> I want my application code to
> completely isolated from the source. My business logic should work on
> the domain model, and not be tied to the source of the data or how it
> comes or goes. Then I can use the same logic throughout the
> enterprise.
I tend to put a large part of the domain model in the DB. Perhaps this
will be clearer when I release my version of R. Martin's OO payroll
example (from his book) in a few weeks, I've been dragging my feet on
it. The differences from Martin's are striking. It is just a whole
different philosophy and mindset. He hard-wires concepts such as
"union dues" into his code. In mine, it is purely a table entry(s) of
line items and line-item categories with a math formula stored in a
table. (I kind of re-invented a domain-specific spreadsheet, if you
will).
>
> >
> > > So my business logic is not coupled to the RDBMS. Also,
> > > Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> > > aids in letting my business objects be saved. It has none of the
> > > attributes of a DBMS at all.
> >
> > It is complicated middle-ware with some quasi-DB qualities.
>
> Name the quasi-DB qualities.
Query language. Concurrency (multi-user, locking, transaction)
management.
> >
> > > > > > It appears to be hypocritical to me. I compare it to hiding behind
> > > > > > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > > > > > outlast languages, or at least are switched at roughly the same
> >
> > > Data outlasts applications. Databases and languages change seldom.
> >
> > Then why the obsession with swapping?
> >
> > > The
> > > whole point in using ORM is to make use of the data that is available
> > > in a timely fashion without requiring a change or addition in the
> > > database.
> >
> > Use of app-specific tables, views, and/or databases is not forbidden.
> > If your DBA does not allow it, then that is an issue of internal
> > politics. Using objects to create a mini app-specific RAM database is
> > dumb in my opinion unless as a last resort. OO is crappy at managing
>
> OO is phenomenally good at creating associations between objects.
No. I've never met a navigational structure that was easier to use
than the same info in relational form (except maybe small, local
stuff). There are "laws" to relational that enforce a certain amount
of consistency and standardize designs and tools more so than nav's.
Almost all non-trivial structures are better under relational in my
opinion. Navigational is the Go To of structures and linking. Nav's
are like shanty-towns: easy to just tack stuff on willy-nilly, but a
huge confusing mess to manage on a larger scale.
How many navigational reporting tools do you know of?
How does one tell if a navigational structure is properly normalized?
> I
> can include all of the FKR of the tables in on object and then treat
> the assembly as a whole.
I assume "FKR" is "foreign key relationships". It is possible to put
these into data dictionaries (tables about tables) and have it
automatically generate commonly-used joins:
select *
from $NaturalJoin("parts,P,inventory,I,suppliers,S")
where ...
This is fairly easy to roll-your-own. (The letters are aliases)
Hibernate has its own query translator that more or less does this
kind of thing also. I can use libraries to simplify my queries also.
It is not an OO-specific fix.
Some RDBMS even have built-in support for natural joins in SQL. (I
agree that SQL has some flaws, but even with these flaws, it is better
than most OO alternatives. Personally, I would like to see SQL
replaced with a programmer-friendly query language. Java has flaws,
Hibernate has flaws, and SQL has flaws. Join management is one of
SQL's flaws, but remediable, per above.)
> That is the point of OO programming. ORM
> does not imply a RAM database (although the 2nd level cache in
> Hibernate is a huge boost). The DBS's primary concern is the
> integrity of the data. If we are embedding application logic into the
> database that can challenge that, then the DBA is correct in
> forbidding it. It is not politics, it proper.
Prove it "proper". Where is your Proper-O-Meter?
>
> > bunches of links between objects, creating navigational spegghetti
> > which is the Goto of the 2000's.
>
> That sounds like a competence of implementation problem, not an issue
> with the underlying model. Anyone can write bad code in any
> language. For this discussion, I am assuming that the programmer is
> capable writing quality code.
I've yet to see quality OO custom biz apps where OO is used to model
the domain. Most are messes, and the programmers don't care because
messes are job security.
> >
> > > The domain model for the application may be different from
> > > that of the database, so having an agile mapping system makes sense.
> > > Applications change often, business rules change even more often.
> > > Database change is slow and methodical and can be traumatic if not
> > > handled carefully. We do not want to put frequently changing logic
> > > into the DB, we want to put data into the DB.
> >
> > Queries and Views are another technique to map the shared data to app-
> > specific or task-specific views.
>
> But once again, they are tied to the database.
A database is a tool. If you have something else that does what the
database would *otherwise* do, then you are then tied to *it* (such as
hibernate, Java, Sun, etc.). It ain't no free lunch. You are simply
dumping one bride and marrying another (or marrying both even). The
Mit Romney paradigm.
> My users are not
> supposed to work on the database, and do not have the qualifications
> to do so.
Databases are easier to learn than OO navigational messes (at least
for some people). Also, I will requote something you said earlier:
(quote)
> That sounds like a competence of implementation problem, not an issue
> with the underlying model. Anyone can write bad code in any
> language. For this discussion, I am assuming that the programmer is
> capable writing quality code.
(end quote)
Your "not qualified to work on databases" contradicts this. Code too
isolated from the database is beurocratic: you spend most of the code
translating back and forth between paradigms instead of doing real
work. Gajillion classes just to print "Hello World". Is OO for retards
who don't get relational???
> We use views for filtering data sets and creating
> alternative displays, but to create an order, a view is no better than
> the query that defines it and is still not the natural way the the
> users expect it. It is also easier to program against one object than
> 11 tables.
Show me with code examples. OO sucks at Joins without lots of aides.
Again, the alternative is not better.
> > > > > In cases like that a persistence framework is a real
> > > > > benefit.
> >
> > > > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > > > personally bop them. File systems are "persistence mechanisms". RDBMS
> > > > are attribute managers, domain noun modelers, and they "encapsulate"
> >
> > > The relational model is not the domain model. It is a construct that
> > > is mapped to a domain model.
> >
> > Horsecrap. It is as much the domain model as a bunch of classes. This
> > is paradigm bias. (I will agree that some forms of "behavior" are best
> > at the app level, but this does not take away the general domain
> > modeling ability since we usually want most behavior at the app
> > level.)
>
> Wrong. It is a rigid mathematical structure that we use to store
> data. An orderitem is part of an order, not a FKR.
An OrderItem also references Parts. It is as tied to Parts as it is
Order. IS-A is very limited in modeling and flexibility. RDBMS are a
"relativity engine", while OO tends to try to force things into static
trees or static hard-wired navigational structures.
> The domain model
> is a model of the enterprise we are trying to automate. It is not
> amenable to the restrictions of set theory, normalization or
> relational algebra.
Those things are good, not bad. Classes are no better a reflection of
the real world. I DON'T have a "Poop" method on my ass the last time I
looked. I'll even let you take a look and verify this the next time I
drive by your office.
> All of those are restrictions on the model to put
> it into an RDBMS.
The "restrictions" are there for a purpose. They are like building
codes (consruction laws). Without them you get shanty towns, which is
what OO designs remind me of.
> Your 'bunch of classes' are types that reflect the
> components that we are modeling (the database has a single type:
> table) with the type of relationships the have in the real world (As
> opposed to FKR in the database).
How exactly are you measuring "real world"-ness??? You sound duped by
all those OO hype books.
> So it is a much better representation
> to the user of the business. The relational model is very good for
> persistence modeling, but that is its intention. Once again, trying
> to extend it is the 'Golden Hammer' problem.
OO ain't no Golden Hammer. It is the Rusted Brass Shanty Town.
>
> >
> > > It happens to be mathematically sound
> > > and very good at certain operations that conform to the underlying
> > > math, and many of the implementations have done excellent jobs of
> > > efficient storage, security and management of the space. That is what
> > > they are good at. But don't tell me that the model as implemented in
> > > the DB is THE MODEL.
> >
> > Maybe 70% of it.
> ?? What does that mean?
I don't expect the DB to be the *entire* model. Some things are best
left to app code. It is specialization. It is just that OO'ers tend
to put a lot more in the app code that the database could otherwise
handle.
>
> >
> > > In fact, I would argue that a good OO Domain
> > > Model is a better candidate for being THE MODEL than the relational
> > > model.
> >
> > Prove it. Show the code of it being better.
>
> Consider the classic Orders example. As a relational model it has
> tables for Orders, Addresses, Orderitems, Orderitemattributes,
> Shipping, Payment, and Tracking. They are associated with each other
> through a series of FKR's. To implement in Java, I design a set of
> classes. The Instance of the classes has all of the information I need
> for that order and none that does not relate to it.
Business logic does not work that way. Things are *natually*
interrelated. Like I said above, OrderItem also relates to the Parts
table. In some cases we need the Parts table, such as to get the part
description (unless you want to copy it over and over, which is bad
design). Your "printOrder" method is probably going to need part
descriptions, which is neither in the order itself nor in orderItems
if you normalize correctly. What is needed per task varies. There is
no One Right View. That is why we need our Relativity Engine, the
RDBMS.
> I can apply the
> business rules to the object or can write methods on the object that
> implement the rules. But in anycase, my object is complete.
How do you get part descriptions for an OrderItem(s)? One could say
the same about a database View, or a query in a subroutine that
returns only a given peice of info that we need. Queries return as
much as or as little as you want. And there are non-OO ways to reuse
them:
x = queryThatWeUseOften(ID_Number)
> I do not
> have to navigate any relationships, I do not get duplicate information
> with my joins. Most importantly, I do not have collect and build my
> model one piece at a time.
Huh?
>
> To populate the object using direct queries will multiple queries as I
> navigate the FKR's and pulling the results out of the rows that I
> retrieve. Once I have applied my business logic, I have to do the
> same with the updates. Using Hibernate, I request the Order by its
> id, Apply the logic, and save it.
I need more info about the context. In other words, use-cases.
>
> Using an ORM is not free. You have have a good domain object model to
> start with, and do the mappings and queries that they use; this
> requires talent and dedication. But you do that once and from then on,
> you can use it again and again and again.
Same with views and queries.
x = queryThatWeUseOften(ID_Number)
> I use one set of domain
> models across multiple applications, so I amortize the up front
> effort. For a new application, having this saves me 30% of my time
> and all of the database access code that I would have to write. It is
> easier for new programmers to come up to speed with a consistent
> model, and we no longer have SQL embedded willy-nilly through the code
> base.
You have not shown me anything that *cannot* be done or res-used with
queries, views, and functions.
>
> In summary: it is better because it is more flexible, easier to
> understand (and hence maintain), and more modular. Game Set Match.
Prove it with code, not English words.
> >
> > > It has less restriction and more flexibility to reflect the
> > > domain than the relational has.
> >
> > Prove it. I agree that the "big iron" view of RDBMS popularized by
> > Oracle is sometimes restricting, but in a flexible organization it
> > does not have to be. "We use OO because our DBA is stubburn and slow"
> > is perhaps understandable, but is that the full justification?
>
> No we use it because it is faster to develop and more flexible. It
> allows our business analysts to try new ideas easier and as a bonus,
> our DBA is pretty happy about it as well.
Everybody claims their favorite technique/paradigm is better. We need
code to inspect, not Yet More Hidden Anecdotes. Anecdotes for anything
are a dime-a-dozen around here.
>
>
> >
> > > That does not mean that we throw the
> > > relational model away, it means that it is another tool in our
> > > developers' tool box that we use when appropriate.
> >
> > > An RDBMS *is* a persistence mechanism.
> >
> > Noooooo! Persistence is one of many aspects of a RDBMS. You OO'ers
> > have an obsession with disks.
>
> No we have an obsession with using the right tool for the right job.
Such as set theory and predicate logic.
>
> >
> > > It is a very good one. It is
> > > a bad place to put application code and business logic. An OO program
> > > is a good place to put application code and business logic. It is not
> > > reinventing the wheel, it is using a tool for the purpose it is best
> > > suited. In fact, doing it all in the DB is a case of the 'Golden
> > > Hammer'.
> >
> > So OO is the Golden Hammer? I don't think so.
>
> No, I don't either. I use the relational database for what it is good
> for, an OO Language for what it is good for, an ORM tool for what it
> is good for. The database is good for storing data in a
> mathematically structured format. It is good at managing that store
> reliably for a long time. It is not good at rapidly changing business
> logic.
I've seen OO'ers hard-wire stuff into code that would be a table entry
in a table-centric design. How is that being more flexible?
>
> As an analogy, I once (a long time ago) worked with a man who was a
> Fortran programmer. He wrote a compiler in Fortran, and tried to use
> that as an argument that we did not need any other programming
> language: Fortran could do it all. My response was (and it) just
> because you can do something, doesn't mean you should. The same
> applies to putting business logic into the DB. Sure, I can write my
> business logic in stored procedures in the DB, but it is a bad place
> to do so. It links business logic to data, and as stated earlier,
> data stays, business logic changes often. It also ties your business
> logic to the database platform. It forces you to implement you program
> in a language that the DB vendor supports in the DB.
Which is probably better than Java. Java is verbosity times verbosity.
It makes COBOL look lean.
The Fortran-er rightly asked for evidence that your technique is
better. He deserves an answer if you are going to belittle him for
using Fortran. People have a right to question superiority claims.
>
> The biggest problem is that it pushes the design of the what ever
> application you creating to look just like the database structure.
Which is worse than looking like Java classes?
> This is the case with things like Oracle forms, but also any tool that
> tries to do code generation for CRUD based on the Relational Schema.
Huh?
>
> The Relational model is suited for efficient storage and retrieval of
> table based data, but this model is not particularly natural for
> people (especially non-programmers) to use.
You are going to have to prove this claim. Navigational was
discredited by Dr. Codd and should stay that way in my opinion. Nobody
knows how to organize it and meta-tize it on a large scale. It is the
Go To of structures.
> When I create an order
> management application, the end user is interested in treating the
> order as a whole, not one screen for customer billing, one for
> customer shipping, one for each line item and another for shipping
> information. I can write a Hibernate mapping that treats an order as
> a single object, apply business logic to the order, not having to
> follow FKR's to each part.
Your FKR argument has been debunked above. Solving it is not OO-
specific.
> Validate the object as whole and the
> persist it to the underlying DBMS. Then, using a reporting tool, my
> coworkers can do metrics and statistics on the same database.
>
> Tomorrow, when my product manager comes to me and announces that we
> have a new promotion to add to the business logic, I can implement the
> new logic either in my Order object (not ideal) or in my rules engine
> (much better), and deploy the change quickly with out affecting the
> carefully designed and tuned database.
You will probably subclass your Java objects whereby in my design an
accounting intern only has to add a new setup into an existing table,
never touching programming code (or we just add an event handler for
the cases where a table entry cannot do it all.)
> > > > > Arne
> >
-T-
Arne Vajhøj
>>>> Customer X may only buy your product if it runs on top
>>>> of database A. They do not care what persistence framework
>>>> you use to be able to support database A, B, C and D without
>>>> changing the application code.
>>> The level of standardization in SQL is rather high. If you skip using
>>> stored procedures and use ANSI SQL 92, entry level, you can switch
>>> database rather painless.
>> Not true.
>>
>> functions
>
> I already made an exception for stored procedures.
Yes.
But functions has nothing to do with SP's.
User defined functions is very similar to SP's.
>> locking
>
> Do claim that different SQL databases implement locking so different
> that it is not possible to write SQL statements that works for
> different vendors?
Yes.
SELECT FOR UPDATE
lock hints
and whatever non standard has sneaked into all the SQL dialects
>> identity/sequences
>
> Yes, som databases vendors handles sequences in a strange way, but it
> is pretty easy to encapsulate the use of sequences in functions that
> could be switched when the datababase vendor is switched.
Yes. But why would anyone want to write that stuff when there
already exist frameworks like Hibernate that already provides
the functionality ?
> The fact that there are some SQL statments that are different for
> different vendors, doesn't mean that you have to put all SQL
> statements into a separate switchable layer.
It is usually considered best practice to put similar functionality
in the same layer. So actually it does mean that.
> Do you have some more examples of differences in SQL syntax between
> vendors? Your list is rather short and the issues you point out is
> very easy to solve.
Well - so far you have failed rather miserable solving them, so
no need to come up with more examples for now.
Arne
frebe
> >>>> of database A. They do not care what persistence framework
> >>>> you use to be able to support database A, B, C and D without
> >>>> changing the application code.
> >>> The level of standardization in SQL is rather high. If you skip using
> >>> stored procedures and use ANSI SQL 92, entry level, you can switch
> >>> database rather painless.
> >> Not true.
>
> >> functions
>
> > I already made an exception for stored procedures.
>
> Yes.
>
> But functions has nothing to do with SP's.
>
> User defined functions is very similar to SP's.
Most SQL databases has an imperative language for defining procedures
or functions. Oracle name it PL/SQL, SQL Server name it T-SQL, etc.
These language are different accross languages, although there are an
ANSI standard for such languages. What do you mean with "functions has
nothing to do with SP's". Functions are not written in languages like
PL/SQL? Are you talking about external functions written in C, or
what?
> SELECT FOR UPDATE
> lock hints
> and whatever non standard has sneaked into all the SQL dialects
During 10 years of working with enterprise application, I have very
rarely come across select for update with lock hints. I don't think it
would be very difficult to make a switchable function producing the
lock hints SQL fragment, like:
sql = "select for update " + lock_hits(vendor, x,y,z);
> >> identity/sequences
>
> > Yes, som databases vendors handles sequences in a strange way, but it
> > is pretty easy to encapsulate the use of sequences in functions that
> > could be switched when the datababase vendor is switched.
>
> Yes. But why would anyone want to write that stuff when there
> already exist frameworks like Hibernate that already provides
> the functionality ?
No you doesn't need to write it. Spring framework has such feature
already. But it wouldn't take very long time to write it by yourself
either.
> > The fact that there are some SQL statments that are different for
> > different vendors, doesn't mean that you have to put all SQL
> > statements into a separate switchable layer.
>
> It is usually considered best practice to put similar functionality
> in the same layer. So actually it does mean that.
Ok, so we put all string handling functionality or all mathematic
calculations in the same layer? Why not putting all class
instantiation in a separate layer?
> > Do you have some more examples of differences in SQL syntax between
> > vendors? Your list is rather short and the issues you point out is
> > very easy to solve.
>
> Well - so far you have failed rather miserable solving them, so
> no need to come up with more examples for now.
What is miserable about the solutions?
/Fredrik
Thomas Gagne
> <snip>
> No, business logic should never be in the database. Data is
> persistent, business logic changes frequently. We want to apply
> business logic in the business application, not in the database. We
> do, however want to express it in the predicate logic format; that is
> what a rules engine is for. In fact, they are a much more appropriate
> tool for them than stored procedures in your data base.
>
business-rule tier?
frebe
> persistent, business logic changes frequently. We want to apply
> business logic in the business application, not in the database.
I have a hard time understand your argumentation. What is the meaning
of "Data is persistent, business logic changes frequently"? Doesn't
data change much frequently than business logic? Is all data
persistent?
My viewpoint is that most business applications is all about register
data and derive new data from the registered data. The rules of data
derivation is called "business logic". A major part of this
derivation process may be done using relational algebra, instead of
state machines.
> We
> do, however want to express it in the predicate logic format; that is
> what a rules engine is for. In fact, they are a much more appropriate
> tool for them than stored procedures in your data base.
A RDBMS is a very good rules engine. They are used for executing
relational algebra (including predicate logic).
Why do you think I want to use stored procedures? Views are a much
better choice. If the business logic is too complicated to be
expressed by relational algebra, I may use views backed up by stored
procedures, stored procedures directly, or put the business logic in
the application on top of the database.
> > > Also,
> > > Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> > > aids in letting my business objects be saved. It has none of the
> > > attributes of a DBMS at all.
>
> > It has a query language which is more or less a copy of SQL.
> So?
That makes it "practically a DB engine".
> > > The domain model for the application may be different from
> > > that of the database,
>
> > Most programming languages only support domain models using the
> > network model. The relational model is much more powerful for
> > modelling your domain.
>
> No, it is actually much less powerful. What it is is much more well
> defined and formalized and predicatable. It is a good model for
> managing relations and references, but that is all.
The network model is more powerful than the relational model? Why do
you think that the relational model replaced the network model so
quickly more than two decades ago? (Hint: which model supports
predicate logic?)
> > > Applications change often, business rules change even more often.
> > > Database change is slow and methodical and can be traumatic if not
> > > handled carefully.
>
> > As long as you don't break backward compatibility, changes in the
> > database schema may be very fast. Views may change very quickly.
>
> views are not data.
Views are derived data.
> > > We do not want to put frequently changing logic
> > > into the DB, we want to put data into the DB.
>
> > We want to put as much business logic in the DB, as views, as
> > possible. Changing view is not traumatic.
>
> No, we want to keep all of the business logic in one, authoritative
> place.
In that case, the RDBMS is the best place.
> Unless you database implements a
> rules engine internally, no business logic should be in the database.
A RDBMS implements a rules engine internally. Do we have an agreement
here, that business logic should be in the database?
> > > The relational model is not the domain model.
>
> > What is wrong with set theory and predicate logic? Do you like pointer
> > better?
>
> Actually, I like objects better, at least for programming.
The reason why many people like the network model bettern than the
relational model, is because it is simpler. It is easier to
understand, but less powerful.
> I like set theory just fine.
But you really don't know how to use it.
> It works well for defining a relation model of my
> business domain. It is rather poor for creating a general domain
> model.
That is because you don't understand the relational model.
> It is very poor for expressing the world as the end users
> understand it.
As a matter of fact, SQL was a huge step in closing the gap between
programmers and end users. It is actually possible to teach end users
how to use SQL for producing reports, etc. It is not possible to teach
end users to write scripts in OO languages for producing reports.
> > > It happens to be mathematically sound
> > > and very good at certain operations that conform to the underlying
> > > math,
>
> > An exellent reason why we should use it for implementing business
> > logic.
>
> No, it is a excellent reason for putting our persistent data in
> mathematically sound storage system. But that is all the database is.
That is all what the database is for you. The rest of us want to use
relational algebra for transient data too.
> > > An RDBMS *is* a persistence mechanism.
>
> > Does the statement
> > select customerid, sum(amount) as total
> > from customers c join orders o on o.customerid=c.customerid
> > having total > 2000
>
> > have anything to do with persistence?
>
> Only to the extent that it is meaninless without it.
So we have an agreement that the select statement above is much more
than "persistence"? A RDBMS is a persistence mechanism and much, much,
more.
And a RDBMS is not meaningless without persistence either. Lets say
that the rows from the orders relation in the example above, are
completly removed when the payment is confirmed, the select statement
would be very useful anyway. Relational algebra may be performed on
transient data as well.
/Fredrik
topmind
Arne Vajhøj wrote:
> frebe wrote:
> > Yes, som databases vendors handles sequences in a strange way, but it
> > is pretty easy to encapsulate the use of sequences in functions that
> > could be switched when the datababase vendor is switched.
>
> Yes. But why would anyone want to write that stuff when there
> already exist frameworks like Hibernate that already provides
> the functionality ?
I have a question for you. If Hibernate forked into different versions
or different vendors and each added custom extensions which started
getting used in practice, would you stop using Hibernate because of
this? If not, why are dialect differences a problem for SQL but not
Hibernate?
Not having choices is a good thing? If we killed off Sybase,
Microsoft, PostgreSQL, etc, and left only Oracle, then there would
never be dialect translation problems (other than version
differences). This would be a net good thing?
-T-
Harry
> Regrettably, much of the Java code I've seen written in private industry
> suggests Fortran can be written in any language.
Could you elaborate (may be with an example)?
> Personally, our shop makes little effort to map our object data into our
> database. There's just little need for it since we don't interact with
> the DB that way. As the articles suggest, we communicate to the DB
> through stored procedures, which may be peculiar to OLTP systems but
> I've used the same approach with other applications (portfolio
> management) without problem.
>
> An advantage to interacting with the DB through stored procedures is the
> strong analogy to how OO programmers are encouraged to interact with
> their own objects with methods (message sends). Nearly as easy as
> sending a message to an object to invoke some functionality or affect a
> state change within that object we send messages to our database to to
> invoke functionality and affect state changes within the DB.
Did this approach *always* work? Meaning, in your experience, did you
encounter a situation where you were forced to put some biz logic
outside stored procedures in the 'application server' layer?
Harry
> Before we get into the politics of Java, there is something ironic
> about O/R wrappers like Hibernate: they are almost more complex than
> the RDBMS itself. Thus, one is wrapping the DB with something that is
> practically a DB engine *itself*. Is being married to Hibernate less
> of a sofware engineering change-flexibility "sin" than being married
> to Oracle or PostGreSQL? I never figured out the "logic" behind such.
> Dracula to avoid being attacked by Frankenstein. Databases tend to
> outlast languages, or at least are switched at roughly the same
> it.
Even if more complex than the RDBMS itself as you say, don't you think
this one-time decision (of choosing to go with Hibernate) would be a
huge pay-off to an applications developer in terms of its ability to
support a whole slew of RDBMSs?
> > That is, from what I understand, once you are
> > in J2EE (or .NET) world, your best bet (as one of my friends suggests)
> > is to stick to everything plain and normal and common-sense, and to
> > not try any new architectural/design stunts unless they stand
> > sufficiently proven. (An example of the last point would be Stored
> > Procedures: a 'normal' J2EE developer would want to code the SPs
> > within the business tier (in Java) instead of in the RDBMS tier in
> > vendor-specific SQL... with the rationale being... the database can be
> > easily switched from let's say mySQL to Oracle to XYZ with zero or
> > minimal work overnight!)
>
> If you mean "go against the flow", there is indeed career problems
> with that. You seem to be asking a social/political question rather
> than a technology one. Java fans will tend to think and act a certain
> way with their tools and expect things a certain way. If you go
> against "Java culture", you indeed may put yourself in hot water. It
> is probably easier to leave the Java culture than to change it. I've
> busted my balls trying to run from the OO hype, and it has indeed hurt
> my career. Attacking Sacred Cows risks getting yourself caught in a
> hamberger grinder. I advise others to just go with the flow if you
> like money. You may have to choose between money and truth.
You could leave aside for now the socio-politico-cultural package that
comes with Java and focus only on the technology part... you could
even assume I have let go of Java... here... gone! Now, I'm wanting
to know (badly) that... without sacrificing change flexibility of a
custom biz application, its scalability, performance (when no. of
concurrent users go up), availability, (security?)... what would be my
choices in the traditional p/r way of architecting things? When I
read about these buzzwords in the J2EE tutorial, and read some of the
material on your site, I wonder how easy or difficult it would be to
design a system that heavily leverages the power of p/r without
getting caught in the net of OO approach.
Harry
> topmind wrote:
> > Before we get into the politics of Java, there is something ironic
> > about O/R wrappers like Hibernate: they are almost more complex than
> > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > practically a DB engine *itself*. Is being married to Hibernate less
> > of a sofware engineering change-flexibility "sin" than being married
> > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
> > It appears to be hypocritical to me. I compare it to hiding behind
> > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > outlast languages, or at least are switched at roughly the same
> > frequency as languages. Thus, vendor-swap math doesn't seem to favor
> > it.
>
> the project business.
>
> Because then the resistance to change database actually
> favors tools that encapsulate the database specifics.
>
> of database A. They do not care what persistence framework
> you use to be able to support database A, B, C and D without
> changing the application code.
>
> benefit.
>
Yes, I'd like to echo that. I know of an actual shop that started out
with their application (for small to medium businesses) with Hibernate
on top and mySQL underneath. Now, this decision gives them the
flexibility to support Oracle, etc.
Harry
> What kind of throughput do you need?
Could you elaborate on this?
Harry
> Arne, those questions were intended, I suppose, to anyone thinking they
> have a requirement for DB neutrality. You brought up the difference
> between creating a product or working on a project. I was just asking
> questions to come to more specifics. Since this is Harry's thread and
> not yours those questions are probably better directed at Harry, or
> anyone else thinking vendor neutrality may be a design requirement.
>
Tom, yes DB neutrality is certainly a requirement. Thru my original
post that started this thread, I wanted to know in a way how much of
OO and OO related stuff I could get rid of while also leveraging this
beast called J2EE that is very much OO. And, I don't think I have very
many P/R choices.
Elsewhere, you mention that you tend to access your DB via stored
procedures only. Could you please elaborate a li'l bit on that? Are
you using J2EE or your own in-house API in doing this? What would be a
few good examples of things that you were forced to put outside the
stored procedure 'layer' into the 'application server layer' (your own
or J2EE)?
Thomas Gagne
> <snip>
>
> Did this approach *always* work? Meaning, in your experience, did you
> encounter a situation where you were forced to put some biz logic
> outside stored procedures in the 'application server' layer?
>
>
There's a separation of responsibilities between low-level business
rules, which I call "how things get done" and higher level business
rules called "why things get done." No matter where a financial
transaction may originate, when it comes to the database there must be
only one path and one correct way to affect that transaction. Seven
applications must not implement a common transaction seven different ways.
However, those seven applications may decide to execute a transaction
for seven (or more) different reasons. An account balance might be
changed from a teller window, a visa terminal, an ATM, an POS terminal,
an online purchase. I prefer to concentrate as much of the
how-things-are-done as close to the DB as possible so they may be easily
leveraged across existing and new applications.
Business rules must have an authoritative definition. That definition
should exist once. Some edits may be duplicated inside applications for
responsiveness, but rules shouldn't migrate.
Thomas Gagne
How many simultaneous DB requests must be handled?
Harry
> Harry wrote:
> > On Apr 4, 5:43 am, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
> >> What kind of throughput do you need?
>
> > Could you elaborate on this?
>
> How many transactions/second? What kind of response time is required?
> How many simultaneous DB requests must be handled?
Hmm. Am I allowed to say "the fastest response time," "the greatest no
of transactions...?"
Imagine a rival shop bidding for the same application space with there
solution, or a benchmarking, no-holds-barred situation. The customer
doesn't give a damn about whether we're using J2EE, this or that
internally; s/he ultimately cares about the orthogonals such as: the
change flexibility of the software (every change will translate into
billable time, so minimal cost of change), scalability, availability,
etc.
Harry
> As much business logic as possible should be implemented using
> predicate logic and set therory (relational algebra).
Functional programmers would like to claim that all or most programs
can be written without assignment (and iterations/loops?). Somehow,
they find recursion-based, non-imperative style more natural and
elegant. I, for one, find it difficult to imagine how it could be so
(having been an imperative programmer myself for many years now)!
Similarly, is it possible there could be many a enterprise app
developer who may find heavy/aggressive use of predicate logic /
relational harder than the alternative, viz, use RDBMSs as dumb
persistent mechanisms (as seemingly encouraged by J2EE) and implement
maximal biz logic in the application server?
Also (a question),
>
> What is wrong with set theory and predicate logic? Do you like pointer
> better?
I'm not a PhD in set theory, relational, or even OO. Could you/someone
provide an example, if one exists, of some biz logic / situation that
cannot be trivially or elegantly handled in the RDBMS layer and
**must** thus be handled outside it... in the 'application server'
layer? From reading the posts so far, the impression I'm getting is
relational and stored procedures can handle **everything** on earth
making an entity like 'application server' layer unnecessary.
Thomas Gagne
> <snip>
> The customer
> doesn't give a damn about whether we're using J2EE, this or that
> internally; s/he ultimately cares about the orthogonals such as: the
> change flexibility of the software (every change will translate into
> billable time, so minimal cost of change), scalability, availability,
> etc.
>
>
rules implemented where they are easiest to change in code, and easiest
to deploy in production. Because much of our business-rule know-how is
in stored procedures, we're often able to make non-trivial fixes and
enhancements to our system without having to redeploy all our
applications. That's a very good thing.
Lew
> Yes, I'd like to echo that. I know of an actual shop that started out
> with their application (for small to medium businesses) with Hibernate
> on top and mySQL underneath. Now, this decision gives them the
> flexibility to support Oracle, etc.
I am an actual programmer who in actual jobs has written direct JDBC code in
most of my paid Java projects, that is, no framework like Hibernate involved.
I have actually seen my own Java code port readily from PostgreSQL to Oracle
and v.v., and MySQL to Oracle and v.v., without any discernible lack of
flexibility.
The greatest difficulty I faced was lack of standards compliance by a DBMS
(MySQL), but Hibernate would've seen the same troubles.
I got the best of both sides of this thread's argument - the full relational
expressiveness of SQL (I've worked on network databases, and frebe makes some
excellent points) with the full freedom to put business (not data) logic in
the Java tier. I have my feet firmly planted in both camps.
Hibernate /is/ in many ways a weak substitute for SQL, for those that
understand and appreciate what relational algebra can do for you. In
practical terms, most business logic doesn't really need that full power, at
least not all at once. Properly designed, a data system will use its
set-oriented nature to support a variety of applications, each with its own
business logic embedded in the logic tier. Views are extremely powerful, and
set-relational thinking solves all kinds of data-slice matters that are tricky
with procedural approaches.
I have used DB-abstraction frameworks. One way to get the most out of them is
to tie them to views rather than directly to tables.
Render unto Caesar what is Caesar's. In the data world, set theory rules. In
the logic world, objects and procedures rule. Making them work together may
feel like riding two spirited stallions, one foot on each saddle, but it's how
to get the best of both technologies.
Like so much in software development, mastery of the tools and theories behind
them is essential. Ignore the strengths of the relational or the object model
at your peril. Don't think a hammer is the only tool you'll need.
--
Lew
Lew
> Even if more complex than the RDBMS itself as you say, don't you think
> this one-time decision (of choosing to go with Hibernate) would be a
> huge pay-off to an applications developer in terms of its ability to
> support a whole slew of RDBMSs?
Compared to what? Payoff is always relative to an alternative choice.
In this case, in Java the alternative is JDBC, which gives the applications
developer the ability to support a whole slew of RDBMSes. Hibernate offers no
additional advantage with respect to this.
Red herring.
--
Lew
Eugene Kalenkovich
Thanks for confirmation that all this is about job security :) (if smily is
not enough, this is a joke)
This works only if you can find some immutable logical layer, otherwise you
are extending your "maintenance scope" to include database. Another
limitation - your db should not be a performance bottleneck of your [set] of
system[s]. In real enterprise where all resources usage is maxed for
efficiency this most probably is not true (yes, this point is not directly
related to OO discussion).
-- EK
topmind
Harry wrote:
> On Apr 3, 9:37 pm, "topmind" <topm...@technologist.com> wrote:
> > Before we get into the politics of Java, there is something ironic
> > about O/R wrappers like Hibernate: they are almost more complex than
> > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > practically a DB engine *itself*. Is being married to Hibernate less
> > of a sofware engineering change-flexibility "sin" than being married
> > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
> > It appears to be hypocritical to me. I compare it to hiding behind
> > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > outlast languages, or at least are switched at roughly the same
> > frequency as languages. Thus, vendor-swap math doesn't seem to favor
> > it.
>
> Even if more complex than the RDBMS itself as you say, don't you think
> this one-time decision (of choosing to go with Hibernate) would be a
> huge pay-off to an applications developer in terms of its ability to
> support a whole slew of RDBMSs?
Most companies do not switch DB vendors very often in my observation.
They are just as likely to switch programming languages as DB vendors,
perhaps more-so.
Anyhow, Hibernate supplies an intermediate query language that
(allegedly) then is translated to vendor-specific dialects of SQL in
the background. This is not a paradigm-specific trait. Such a language/
tool could in theory be used by COBOL, C, etc. Thus, if you are likely
to switch DB vendors for whatever reason, an intermediate query
language like Hibernate may be a good idea (if it works).
I've heard of performance problems and other oddities with Hibernate,
though. Being generic is often in conflict with being fast. Thus, its
magic claims to supply instant vendor neutrality without downsides
should be taken with a grain of salt. Do you really want a slow
application today so that you can swap DB vendors easier 10 years from
now? It does not sound like a good tradeoff. In investment theory,
distant benefits should be downplayed when weighing cost/benefits.
I like dynamic languages. They seem a bit more database-friendly than
static-typed languages and make it easier to automatically generate
and embed SQL string clauses, such as for Query By Example. PHP is
okay I guess, although it is missing named parameters and has other
small annoyances, such as the need for the triple-equal operator for
some functions. I've been using a lot of ColdFusion of late for work
(not necessary my first choice), and it has dynamic typing and some
convient data-oriented features and even a half-usable editable data
grid widget, which are hard to come by in web stuff. You just have to
get used to tags for most of the coding.
> When I
> read about these buzzwords in the J2EE tutorial, and read some of the
> material on your site, I wonder how easy or difficult it would be to
> design a system that heavily leverages the power of p/r without
> getting caught in the net of OO approach.
I'd have to think about that some more. I used to ponder such, but
stopped doing it when it grew clear it wouldn't happen. One thing
that comes to mind is a RDBMS-based code repository so that we could
get away from hierarchical file systems for code management. Each
subroutine and/or module could be put into a table cell along with
meta-data columns of our chosing to help index, classify, and
structure them. Code editors would have to be DB-aware and allow us
to query for routines and then edit the hits. Indexing the paramaters
in a Parameter Dictionary perhaps could also be part of it. It could
supply editing auto-fill features.
This is an area ripe for experimentation, somebody looking for a
university project perhaps.
Convenient table (grid) editors are still lacking in web-oriented
stuff. Only desktop DB's like Access and FoxPro seem to have decent
ones. Web-based ones never seem to get it right.
-T-
frebe
> > > the data source, since data can come from more places than the disk
> > > store.
>
> > RDBMS are not about disks. SQL is an *interface*. Hiding from one
> > interface (SQL) by using another (Hibernate) simply *trades* one
> > dependency for another, NOT rids net dependencies.
>
> Wrong! RDBMS's are all about disks.
Is this some kind of a joke?
> I want my application code to
> completely isolated from the source.
A RDBMS offers that kind of isolation.
> My business logic should work on
> the domain model,
domain model = relational schema
> and not be tied to the source of the data or how it
> comes or goes.
The source could be anything, as long as it has a SQL interface on
top.
> Then I can use the same logic throughout the
> enterprise.
That is why SQL is so popular. A lot of application may access the
corporate data in a standardized way.
> OO is phenomenally good at creating associations between objects.
I know you love pointers, but there are better ways.
> The DBS's primary concern is the
> integrity of the data.
A RDBMS is also very good at data derivation.
> > bunches of links between objects, creating navigational spegghetti
> > which is the Goto of the 2000's.
>
> That sounds like a competence of implementation problem, not an issue
> with the underlying model.
So Goto's are good, it is only incompetent programmers that don't know
how to use them?
> > > The domain model for the application may be different from
> > > that of the database, so having an agile mapping system makes sense.
> > > Applications change often, business rules change even more often.
> > > Database change is slow and methodical and can be traumatic if not
> > > handled carefully. We do not want to put frequently changing logic
> > > into the DB, we want to put data into the DB.
>
> > Queries and Views are another technique to map the shared data to app-
> > specific or task-specific views.
>
> But once again, they are tied to the database.
Your application is tied to the database too.
> My users are not
> supposed to work on the database,
It is much more common that users knows about the database schema,
than the domain object model.
> and do not have the qualifications to do so.
Many customers care about the database schema, but they never care
about your objects.
> We use views for filtering data sets and creating alternative displays,
That's a good start.
> but to create an order, a view is no better than
> the query that defines it and is still not the natural way the the
> users expect it.
A view is like a method, it can be reused in other queries.
> It is also easier to program against one object than
> 11 tables.
I doubt that you would map 11 tables to only one class. In that case I
could imagine a lot of performance problems like the N+1 issue and
lazy loading, etc.
> > If swapping vendors is not the issue, so then what exactly *is* the
> > problem with using direct queries in the app?
>
> It couples the application directly to database, it imposes the
> relational structure of the data onto an OO language and it crosses
> concerns.
Finally a confession, OO languages has no support for relations. Think
about this: Every enterprise choose to use relational databases. OO
has no relational support. What is your conclusion?
> > > The relational model is not the domain model. It is a construct that
> > > is mapped to a domain model.
>
> > Horsecrap. It is as much the domain model as a bunch of classes. This
> > is paradigm bias. (I will agree that some forms of "behavior" are best
> > at the app level, but this does not take away the general domain
> > modeling ability since we usually want most behavior at the app
> > level.)
>
> Wrong. It is a rigid mathematical structure that we use to store
> data.
Relational algebra has very little to do with "storing data".
> The domain model
> is a model of the enterprise we are trying to automate. It is not
> amenable to the restrictions of set theory, normalization or
> relational algebra.
Why not?
> (the database has a single type: table)
A good relational database has an open type system. You should be able
to define any type (SSN, zip code, image, etc) you like. But a
relational database only have one type of data structure: relations.
> > > In fact, I would argue that a good OO Domain
> > > Model is a better candidate for being THE MODEL than the relational
> > > model.
>
> > Prove it. Show the code of it being better.
>
> Consider the classic Orders example. As a relational model it has
> tables for Orders, Addresses, Orderitems, Orderitemattributes,
> Shipping, Payment, and Tracking. They are associated with each other
> through a series of FKR's. To implement in Java, I design a set of
> classes.
Wouldn't you have classes like Order, Address, OrderItem, etc, too?
> The Instance of the classes has all of the information I need
> for that order and none that does not relate to it.
What is the difference compared to relations?
> I can apply the business rules to the object
And the difference compared to relations, is?
> But in anycase, my object is complete. I do not
> have to navigate any relationships,
OO has a lot of navigation. How do you get OrderItem objects? The
relational model doesn't have any navigation. It is only OO people who
try to emulate a network database using a relational database, that
thinks that foreign keys are pointers.
> I do not get duplicate information with my joins.
A join is not data duplication, it is data derivation.
> Most importantly, I do not have collect and build my
> model one piece at a time.
The only time you need to do that is when you map tables to objects or
other host language data structures. Using the relational model, you
just have to ask for the data when you really need it, not long time
before and passing it around the application.
> To populate the object using direct queries will multiple queries as I
> navigate the FKR's and pulling the results out of the rows that I
> retrieve.
A very bad way of doing it.
> Once I have applied my business logic, I have to do the
> same with the updates. Using Hibernate, I request the Order by its
> id, Apply the logic, and save it.
This issue about "saving" shows the weakness of O/R mapping. Before
you "save" you object, you have an inconsistent state. The modified
object has one state different from the real state in the database.
When your object is a local variable this might be acceptable, but if
your object is shared by different thread you have a lot of
concurrency and transaction handling to solve. Instead of doing
customer = broker.findCustomer(a);
customer.setAddress(abc);
customer.save();
you should do
update customer set address=abc where id=a;
> Using an ORM is not free.
Indeed.
> You have have a good domain object model to
> start with, and do the mappings and queries that they use; this
> requires talent and dedication. But you do that once and from then on,
> you can use it again and again and again. I use one set of domain
> models across multiple applications, so I amortize the up front
> effort. For a new application, having this saves me 30% of my time
> and all of the database access code that I would have to write.
Imagine how how time you would save if you skip your domain object
model and data access layer.
> I use the relational database for what it is good for,
I don't think so.
> The database is good for storing data in a mathematically structured format.
And here comes the proof....
> It is not good at rapidly changing business logic.
Why?
> As an analogy, I once (a long time ago) worked with a man who was a
> Fortran programmer. He wrote a compiler in Fortran, and tried to use
> that as an argument that we did not need any other programming
> language: Fortran could do it all. My response was (and it) just
> because you can do something, doesn't mean you should. The same
> applies to putting business logic into the DB. Sure, I can write my
> business logic in stored procedures in the DB, but it is a bad place
> to do so.
Yes, views are a better place.
> It links business logic to data, and as stated earlier,
> data stays, business logic changes often. It also ties your business
> logic to the database platform. It forces you to implement you program
> in a language that the DB vendor supports in the DB.
And by using C# you are not tied to any vendor?
> The biggest problem is that it pushes the design of the what ever
> application you creating to look just like the database structure.
And the problem with that is?
> This is the case with things like Oracle forms, but also any tool that
> tries to do code generation for CRUD based on the Relational Schema.
These kind of tools can save you a lot of time.
> The Relational model is suited for efficient storage and retrieval of
> table based data, but this model is not particularly natural for
> people (especially non-programmers) to use.
It's strange that MS Excel is such a popular product, since table
based data is not particulary natural for non-programmers...
> When I create an order
> management application, the end user is interested in treating the
> order as a whole, not one screen for customer billing, one for
> customer shipping, one for each line item and another for shipping
> information.
Presentation and relations are not the same thing. But I think that it
would take more than one screen for entering an order in most ERP
applications.
> I can write a Hibernate mapping that treats an order as
> a single object,
When you want a sales report for one particular product, will you load
all orders, traverse them and find the matching order lines? Mapping a
lot of relations to one class, will get you terrible performance.
> not having to follow FKR's to each part.
Nobody except from OO people thinks that foreign keys are about
navigation.
> Tomorrow, when my product manager comes to me and announces that we
> have a new promotion to add to the business logic, I can implement the
> new logic either in my Order object (not ideal) or in my rules engine
> (much better), and deploy the change quickly with out affecting the
> carefully designed and tuned database.
How can you add this "promotion" without touching the database schema?
Sorry I forgot, you have one single table:
TheObjectStore:
* objectid
* propertyid
- value
/Fredrik
topmind
Harry wrote:
> On Apr 5, 10:14 am, "frebe" <freb...@gmail.com> wrote:
> > As much business logic as possible should be implemented using
> > predicate logic and set therory (relational algebra).
>
> Functional programmers would like to claim that all or most programs
> can be written without assignment (and iterations/loops?). Somehow,
> they find recursion-based, non-imperative style more natural and
> elegant. I, for one, find it difficult to imagine how it could be so
> (having been an imperative programmer myself for many years now)!
> Similarly, is it possible there could be many a enterprise app
> developer who may find heavy/aggressive use of predicate logic /
> relational harder than the alternative, viz, use RDBMSs as dumb
> persistent mechanisms (as seemingly encouraged by J2EE) and implement
> maximal biz logic in the application server?
Indeed. Everybody thinks different and has different preferences. Many
OO'ers imply OO is the "only and right way" to build apps. I think
this is nonsense, barring objective clean evidence otherwise.
>
> Also (a question),
>
> >
> > What is wrong with set theory and predicate logic? Do you like pointer
> > better?
> I'm not a PhD in set theory, relational, or even OO. Could you/someone
> provide an example, if one exists, of some biz logic / situation that
> cannot be trivially or elegantly handled in the RDBMS layer and
> **must** thus be handled outside it... in the 'application server'
> layer? From reading the posts so far, the impression I'm getting is
> relational and stored procedures can handle **everything** on earth
> making an entity like 'application server' layer unnecessary.
There are extremes on both ends. OO'ers like to use as much as the app
as possible and as little of the DB as possible (that's why they keep
calling it "persistence"), while some people try to do everything on
the DB (although these guys are much rarer than the OO'er extremists).
Until Dynamic Relational is a reality and SQL is overhauled, I think
its best to have a mix of app code and DB work, letting each do what
they do best. RDBMS best handle searching, filtering, and cross-
referencing; while code best handles nitty-gritty conditionals that
cannot be done via predicate logic. When you factor a lot of biz logic
to the database, the resulting app code left over is almost pure
conditionals in some cases. (They can't be readily turned into
polymorphism because they tend to be task-specific and independent of
each other.)
-T-
frebe
> > predicate logic and set therory (relational algebra).
>
> Functional programmers would like to claim that all or most programs
> can be written without assignment (and iterations/loops?). Somehow,
> they find recursion-based, non-imperative style more natural and
> elegant. I, for one, find it difficult to imagine how it could be so
> (having been an imperative programmer myself for many years now)!
Imperative programming is much easer to learn, but I prefer
declarative programming because it results in less bloated code. And
less bloated code is easier to overview. Declarative code is also
easier to verify. A function without side-effects is very easy to
test. But I have yet never seen an environment where you doesn't need
to use imperative languages at all. Look at web development for
example. The GUI is defined by an declarative language (HTML), but you
often need to inject imperative code (JavaScript). You can see the
same pattern in a databases that needs triggers.
> Similarly, is it possible there could be many a enterprise app
> developer who may find heavy/aggressive use of predicate logic /
> relational harder than the alternative,
I think it is mainly a question about education. If you are not
educated in relational algebra, you prefer to use something you
understand.
> I'm not a PhD in set theory, relational, or even OO. Could you/someone
> provide an example, if one exists, of some biz logic / situation that
> cannot be trivially or elegantly handled in the RDBMS layer and
> **must** thus be handled outside it... in the 'application server'
> layer?
If the RDBMS has a stored procedure language, it could do everything
related to data management. But presentation and communication
normally have to be handled outside. I also choose to use an
application server because I don't want to tie the application too
much to a specific database vendor. IDE products are also much better
for languages like Java, than stored procedures languages.
> From reading the posts so far, the impression I'm getting is
> relational and stored procedures can handle **everything** on earth
> making an entity like 'application server' layer unnecessary.
A database is an application server. If you go 10 years back in time,
people used stored procedures a lot for larger tasks that was handled
better on the server side, than the client side. The reason why we
don't use stored procedures so much anymore, is because every vendor
has its own language and new open source vendors has poped up.
Customers don't want to pay Oracle a lot of money anymore, when they
can get it for free.
/Fredrik
Harry
> (snip) I also choose to use an
> application server because I don't want to tie the application too
> much to a specific database vendor.
Would be happy if you could elaborate a little bit with an example or
two. I have not done any real enterprise application development (OO
or relational or both), and I didn't have the good fortune of working
in the 80's to experience and learn things first hand.
frebe
> > application server because I don't want to tie the application too
> > much to a specific database vendor.
>
> Would be happy if you could elaborate a little bit with an example or
> two. I have not done any real enterprise application development (OO
> or relational or both), and I didn't have the good fortune of working
> in the 80's to experience and learn things first hand.
In the 2-tier Client/Server architecture used in the 80's, the only
thing you had on the server was the database. The clients accessed the
database (server) using SQL and ODBC, etc. If the client only called
select/insert/update/delete statements, the client/server
communication become too heavy in some scenarios (like payroll
calculation, bill of material calculations, etc). The solution to this
problem was to use stored procedures, which took a small number of
parameters, did some processing and returned the result to the client.
This is exactly what we use application servers for today. Excecuting
tasks that are better suited to be executed on the server.
The reason that we don't use stored procedures for doing that today is
that it is more database vendors now, than 20 years ago and because
they have failed to conform to any standard regarding stored procedure
languages. It is better to write server tasks in a language that is
not tied to the choice of database vendor.
The big mistake that was done, when application servers was
introduced, was to disallow the client to access the database directly
for trivial calls. Regardless how simple a database call might be, it
has to be proxied through the application server. And worse, it need
to be proxied through a procedural interface.
If the client want to populate a spread sheet component for customers
with the columns id, customername, contactname, it can't just call
"select id, customername, contactname". First you need to build a
value (domain) objects containing the data you need (and probably much
more than you need). Second you need to write a server-side function/
procedure/method returning such objects. For every possible
combination of data you need, you need to write a server-side
function. Or you try to reuse your server-side functions resulting in
that you probably get much more data than you need.
And the madness doesn't stop here. Some people would claim that the
server-side functions should be separated into "business" logic and
"persistence" logic. This will force you first create one
findCustomerHeaderByCritera in the "business" layer, doing nothing
else but delegating to a function in the "persistence" layer with the
same signature.
The conclusion is: Call an application server, when suitable, and call
the database then suitable. Don't create another layered code bloat
monster.
/Fredrik
Harry
I gained quite a bit of insight from this thread. Thank you *all* for
teaching me a few nice things. Let me summarize what I think I've been
able to gather from this thread. Any final opinions/corrections are
very welcome (remember, I have not done any *actual* enterprise
application design/development in my career; only have some concept in
my head).
I tend to believe in the power of the RDBMS. Unlike OO, it seems to
have a sound mathematical basis, a rigor behind its learning and
mastering. I'd like to spend time learning it well (even if it
requires reading good old CJ Date cover to cover).
I do tend to think that *wherever possible*, we should try not to use
OO to re-discover and learn lessons that have already been learned a
decade or two ago (the network model). OO may prove very elegant in
the modeling of static, noun-oriented relationships as found in
mathematics, nature, etc but not necessarily in highly volatile biz
scenarios where we cannot and thus never will, fully understand, ever,
the implications of our own class design choices... where "Catdogs
will always be real possibilities." [Source: http://www.geocities.com/tablizer
]
Having said that, I as a *product* designer (not as an in-house
project/application developer), would want my product to be as change-
friendly as possible. Ideally, the more replaceable components it has
the better. The typical, untrained end-user may not know and thus may
not believe in the power that an RDBMS is capable of wielding; he may
see it merely as one of the many other components of my application
that I'm trying to sell him, and thus may be interested in picking and
choosing an RDBMS for his shop (even despite my recommendation for,
say, XYZ RDBMS). In such a situation, it may be wiser to plan for this
flexibility up-front in my product architecture by shifting all the
intelligence / biz logic out of the RDBMS tier (effectively relegating
it to a dumb persisting mechansim much to the chagrin of many RDBMS
fans) and putting it wholly into the application server tier (app
server as commonly defined and understood today). Having some
intelligence here in this tier and some intelligence there in that
tier and that too in an ad hoc manner will only serve in making things
look uglier and confusing (whereas the soul within would like to seek
beauty and elegance in all its contact with the external). Also, if I
find myself deep within the Java culture, it may make sense to "go
with the flow" as someone suggested.
There may be large, diverse organizations which may have fully staffed
software teams for handling their own *in-house* software needs. This
is the only case where I think I will comfortable relying totally and
completely on the power of the RDBMS, even vendor-specific extensions.
If there were no incompatibilities in the SQL interface across vendors
(IOW, vendors only differed in performance, documentation, pricing and
internal architecture details), I could still consider exploiting the
full power of the RDBMS for building a *product*. Scattering JDBC
calls in the app server tier somehow look ugly to me. (We may
unknowingly leave a vendor-specific SQL construct or two in our JDBC
calls, hoping the QA team would be awake).
Thank you, again, for all your keystrokes!
Regards.
Patrick May
> I tend to believe in the power of the RDBMS. Unlike OO, it seems to
> have a sound mathematical basis, a rigor behind its learning and
> mastering.
Most commercial RDBMSs are based to some extent on relational
algebra, but it is important to note that this doesn't automatically
result in faster, better, or cheaper software development. Common
Lisp is based on the equally formal lambda calculus but one rarely
hears that touted as a benefit in and of itself.
> I do tend to think that *wherever possible*, we should try not to
> use OO to re-discover and learn lessons that have already been
> learned a decade or two ago (the network model).
You seem to be channeling Bryce Jacobs. I'd recommend refraining
from making statements like this until you have sufficient personal
experience with OO to understand that competent developers are most
certainly not doing what you suggest.
> OO may prove very elegant in the modeling of static, noun-oriented
> relationships as found in mathematics, nature, etc but not
> necessarily in highly volatile biz scenarios where we cannot and
> thus never will, fully understand, ever, the implications of our own
> class design choices.
Again, you're showing your lack of experience with the
technology. OO techniques have been and are being used to develop
large, mission critical applications that are flexible in the face of
constantly changing requirements. You should investigate Robert
Martin's papers and some of the agile approaches to learn how.
> If there were no incompatibilities in the SQL interface across
> vendors [ . . . ], I could still consider exploiting the full power
> of the RDBMS for building a *product*.
OO, procedural, relational, functional, and other techniques are
not mutually exclusive, despite what you may have been led to believe
by some overly prolific posters here. Competent developers use the
combination of tools that provides the greatest benefit in addressing
the problem at hand. Don't be a one trick pony.
Finally, I'd like to suggest that you consider one anecdote.
I've been in this industry for almost 20 years. I remember when OO in
general and C++ in particular were first becoming widely used. At the
time, developers were building client-server architectures using
procedural and relational techniques. Over the course of a few years,
many intelligent, experienced developers, all with a solid
understanding of relational databases and procedural programming,
began using OO techniques. Those techniques have been continuously
refined and are still being used today.
What I'd like you to consider is: Does it make sense that every
one of those developers, despite their understanding of the benefits
of relational databases, would have started using OO if they found no
benefits from doing so? Is it really a credible position to imagine
that such a large group of people would succumb to pure hype?
Obviously you should think for yourself and learn the advantages,
disadvantages, and applicability of all of these techniques
personally. However, there are worse ways to prioritize what you're
going to learn than by listening to intelligent, experienced people
who have actually delivered working enterprise-scale systems.
Good luck,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Arne Vajhøj
> Arne Vajhøj wrote:
>> frebe wrote:
>>> Yes, som databases vendors handles sequences in a strange way, but it
>>> is pretty easy to encapsulate the use of sequences in functions that
>>> could be switched when the datababase vendor is switched.
>> Yes. But why would anyone want to write that stuff when there
>> already exist frameworks like Hibernate that already provides
>> the functionality ?
>
> I have a question for you. If Hibernate forked into different versions
> or different vendors and each added custom extensions which started
> getting used in practice, would you stop using Hibernate because of
> this?
If the changes meant that applications would need to be changed
if the database changes, then my estimate would be that
75-90% of the Hibernate users would switch to something else
(there are plenty of persistence frameworks in Java), because
that feature is critical.
> Not having choices is a good thing? If we killed off Sybase,
> Microsoft, PostgreSQL, etc, and left only Oracle, then there would
> never be dialect translation problems (other than version
> differences). This would be a net good thing?
In general: no (prices would go up and innovation would go down).
For those writing products that uses databases: possible (because
they would no longer need to worry about the differences).
Arne
Arne Vajhøj
> Harry wrote:
>> Even if more complex than the RDBMS itself as you say, don't you think
>> this one-time decision (of choosing to go with Hibernate) would be a
>> huge pay-off to an applications developer in terms of its ability to
>> support a whole slew of RDBMSs?
>
> Most companies do not switch DB vendors very often in my observation.
No but as explained earlier products may need to support
multiple databases. Usually a growing list of supported
databases.
> Anyhow, Hibernate supplies an intermediate query language that
> (allegedly) then is translated to vendor-specific dialects of SQL in
> the background. This is not a paradigm-specific trait. Such a language/
> tool could in theory be used by COBOL, C, etc. Thus, if you are likely
> to switch DB vendors for whatever reason, an intermediate query
> language like Hibernate may be a good idea (if it works).
I have not seen CHinernate or CobHibernate, but NHibernate exist.
> I've heard of performance problems and other oddities with Hibernate,
> though. Being generic is often in conflict with being fast.
Oh yeah. We know.
:-(
> Thus, its
> magic claims to supply instant vendor neutrality without downsides
> should be taken with a grain of salt. Do you really want a slow
> application today so that you can swap DB vendors easier 10 years from
> now? It does not sound like a good tradeoff. In investment theory,
> distant benefits should be downplayed when weighing cost/benefits.
I am not aware of anyone claiming tools like Hibernate is
"without downsides".
Most ideas/concepts has downsides.
Most implementations has problems.
But there are definately a demand for the type of product.
When it is a good choice and which actual product that are
good is another story.
Hibernate just happens to be the most popular framework of
this type in the Java world in these years.
Arne
Arne Vajhøj
> Most SQL databases has an imperative language for defining procedures
> or functions. Oracle name it PL/SQL, SQL Server name it T-SQL, etc.
> These language are different accross languages, although there are an
> ANSI standard for such languages. What do you mean with "functions has
> nothing to do with SP's". Functions are not written in languages like
> PL/SQL? Are you talking about external functions written in C, or
> what?
Try look in the index of a database manual.
>> SELECT FOR UPDATE
>> lock hints
>> and whatever non standard has sneaked into all the SQL dialects
>
> During 10 years of working with enterprise application, I have very
> rarely come across select for update with lock hints.
May be.
But having to use non standard SQL to achieve the necessary
integrity and keep performance is often an issue.
> I don't think it
> would be very difficult to make a switchable function producing the
> lock hints SQL fragment, like:
>
> sql = "select for update " + lock_hits(vendor, x,y,z);
Ignoring the fact that the above is a mix of two unrelated
things, then I do not understand why you are so keen on writing
your own code instead of using somebody elses code.
>>>> identity/sequences
>>> Yes, som databases vendors handles sequences in a strange way, but it
>>> is pretty easy to encapsulate the use of sequences in functions that
>>> could be switched when the datababase vendor is switched.
>> Yes. But why would anyone want to write that stuff when there
>> already exist frameworks like Hibernate that already provides
>> the functionality ?
>
> No you doesn't need to write it. Spring framework has such feature
> already. But it wouldn't take very long time to write it by yourself
> either.
Fine. And ?
You use some code to encapsulate the differences in databases.
I am rather indifferent on whether it is Spring or Hibernate.
>>> The fact that there are some SQL statments that are different for
>>> different vendors, doesn't mean that you have to put all SQL
>>> statements into a separate switchable layer.
>> It is usually considered best practice to put similar functionality
>> in the same layer. So actually it does mean that.
>
> Ok, so we put all string handling functionality or all mathematic
> calculations in the same layer? Why not putting all class
> instantiation in a separate layer?
It is called Spring !
:-)
No. There is a big difference between putting things that
are logically separate in separate layers and putting things
that are logically the same in separate layers depending
only on whether the SQL is standard or not.
>>> Do you have some more examples of differences in SQL syntax between
>>> vendors? Your list is rather short and the issues you point out is
>>> very easy to solve.
>> Well - so far you have failed rather miserable solving them, so
>> no need to come up with more examples for now.
>
> What is miserable about the solutions?
Read.
Arne
Harry
> "Harry" <simonsha...@gmail.com> writes:
> > I tend to believe in the power of the RDBMS. Unlike OO, it seems to
> > have a sound mathematical basis, a rigor behind its learning and
> > mastering.
>
> Most commercial RDBMSs are based to some extent on relational
> algebra, but it is important to note that this doesn't automatically
> result in faster, better, or cheaper software development. Common
> Lisp is based on the equally formal lambda calculus but one rarely
> hears that touted as a benefit in and of itself.
I have not explored lamba calculus so can't comment on it.
My current understanding is that the RDBMS is a layer, and a non-
trivial layer at that. It is already hiding within it a lot of crappy/
boring/repetitive programming drudgery, and providing me a very
valuable, a very significant service in terms of something (set
theory) that I'm well familar with since my pre-college days. In
absence of any multi-vendor-RDBMS support requirement, I'd very much
like my solution to be closest to this layer. Wouldn't you?
> > I do tend to think that *wherever possible*, we should try not to
> > use OO to re-discover and learn lessons that have already been
> > learned a decade or two ago (the network model).
>
> You seem to be channeling Bryce Jacobs. I'd recommend refraining
> from making statements like this until you have sufficient personal
> experience with OO to understand that competent developers are most
> certainly not doing what you suggest.
Who, TopMind? I've been very much a hands-on OO developer for many
years. Some of the things he talks about on the tablizer site about
OO... I could instantly connect with them because I have experienced
many of them first-hand (some rather painfully). I only wish I had
run into his OO critique early on in my career. He has saved me (and
I bet many others, the seekers of 'truth') much work by
systematically presenting the flip-side of OO, if you will... things
what most OO book authors won't tell you... even in a relegatory
appendix.
> > OO may prove very elegant in the modeling of static, noun-oriented
> > relationships as found in mathematics, nature, etc but not
> > necessarily in highly volatile biz scenarios where we cannot and
> > thus never will, fully understand, ever, the implications of our own
> > class design choices.
>
> Again, you're showing your lack of experience with the
> technology. OO techniques have been and are being used to develop
> large, mission critical applications that are flexible in the face of
> constantly changing requirements. You should investigate Robert
> Martin's papers and some of the agile approaches to learn how.
It's not that I've written off OO completely. It's just I would be
very cautious in buying into bold, blanket promises. In purely the
interest of the software-design--the-OO-way community , I urge well-
known OO experts to furnish point by point rebuttals of the tablizer
site contents. Until then, I may read their papers and books and what
not but all with a pinch of salt.
> > If there were no incompatibilities in the SQL interface across
> > vendors [ . . . ], I could still consider exploiting the full power
> > of the RDBMS for building a *product*.
>
> OO, procedural, relational, functional, and other techniques are
> not mutually exclusive, despite what you may have been led to believe
> by some overly prolific posters here. Competent developers use the
> combination of tools that provides the greatest benefit in addressing
> the problem at hand. Don't be a one trick pony.
The pony would definitely love to learn many new tricks. But the pony
here, out of sheer pony-peer pressure, began learning a new trick
without critically understanding what all the earlier trick (that many
other ponies already knew of and successfully used in the 80s) was
capable of accomplishing. This pony now doesn't want to be in a
situation where he's keeping on going on learning new tricks without
fully mastering the earlier ones. Otherwise, he risks being hailed as
pony of all trades, master of none.
(Your point well taken, though.)
> Finally, I'd like to suggest that you consider one anecdote.
> I've been in this industry for almost 20 years. I remember when OO in
> general and C++ in particular were first becoming widely used. At the
> time, developers were building client-server architectures using
> procedural and relational techniques. Over the course of a few years,
> many intelligent, experienced developers, all with a solid
> understanding of relational databases and procedural programming,
> began using OO techniques. Those techniques have been continuously
> refined and are still being used today.
>
> What I'd like you to consider is: Does it make sense that every
> one of those developers, despite their understanding of the benefits
> of relational databases, would have started using OO if they found no
> benefits from doing so? Is it really a credible position to imagine
> that such a large group of people would succumb to pure hype?
A counter-anecdote/parable would be: The Emperor's New Clothes.
I somehow doubt this OO refinement process will ever end. Could the
need for this "continous refinement" be a function of its
incompleteness and hint at something fundamental that it's lacking?
I'm not aware of any refinements being done to P/R. Could this hint
at the inherent completeness/maturity of this device?
> Obviously you should think for yourself and learn the advantages,
> disadvantages, and applicability of all of these techniques
> personally. However, there are worse ways to prioritize what you're
> going to learn than by listening to intelligent, experienced people
> who have actually delivered working enterprise-scale systems.
I have read amply (and you can trust me on this one) about the
benefits, merits, advantages of OO. Unfortunately, I've never run
into one OO book (pl point me if you know of one) that talks about the
flipside of OO... instances of which are covered in great detail on
the tablizer site. (If anyone knows of any other OO-critique site, pl
let me know.) It helps me greatly if I know upfront the things a tool/
technology cannot do rather than only knowing what it can do.
Regards,
Harry.
Patrick May
> On Apr 7, 6:37 pm, Patrick May <p...@spe.com> wrote:
>> Most commercial RDBMSs are based to some extent on relational
>> algebra, but it is important to note that this doesn't
>> automatically result in faster, better, or cheaper software
>> development. Common Lisp is based on the equally formal lambda
>> calculus but one rarely hears that touted as a benefit in and of
>> itself.
> My current understanding is that the RDBMS is a layer [ . . . ]
> providing me a very valuable, a very significant service in terms of
> something (set theory) that I'm well familar with since my
> pre-college days. In absence of any multi-vendor-RDBMS support
> requirement, I'd very much like my solution to be closest to this
> layer.
Why?
>> > I do tend to think that *wherever possible*, we should try not to
>> > use OO to re-discover and learn lessons that have already been
>> > learned a decade or two ago (the network model).
>>
>> You seem to be channeling Bryce Jacobs. I'd recommend
>> refraining from making statements like this until you have
>> sufficient personal experience with OO to understand that competent
>> developers are most certainly not doing what you suggest.
>
> Who, TopMind? I've been very much a hands-on OO developer for many
> years. Some of the things he talks about on the tablizer site about
> OO... I could instantly connect with them because I have experienced
> many of them first-hand (some rather painfully). I only wish I had
> run into his OO critique early on in my career. He has saved me
> (and I bet many others, the seekers of 'truth') much work by
> systematically presenting the flip-side of OO, if you will... things
> what most OO book authors won't tell you... even in a relegatory
> appendix.
Bryce Jacobs (posting here and elsewhere under the pseudonym
Topmind) has admitted in this very newsgroup that he has very limited
practical experience with OO techniques. Your breathless
near-sycophancy strongly suggests to me that you are his sock puppet.
>> Again, you're showing your lack of experience with the
>> technology. OO techniques have been and are being used to develop
>> large, mission critical applications that are flexible in the face
>> of constantly changing requirements. You should investigate Robert
>> Martin's papers and some of the agile approaches to learn how.
>
> It's not that I've written off OO completely. It's just I would be
> very cautious in buying into bold, blanket promises.
More Bryce Jacobs nonsense. Please provide some evidence of
these "blanket promises". Competent, experienced developers use OO
techniques, where they are applicable, because they provide value.
Those same developers use relational, procedural, and functional
techniques when appropriate.
>> What I'd like you to consider is: Does it make sense that
>> every one of those developers, despite their understanding of the
>> benefits of relational databases, would have started using OO if
>> they found no benefits from doing so? Is it really a credible
>> position to imagine that such a large group of people would succumb
>> to pure hype?
>
> A counter-anecdote/parable would be: The Emperor's New Clothes.
The developers to whom I am referring have to build real,
working, enterprise-scale systems. Reality is a wonderful constraint
for focusing one's thoughts. Are you seriously suggesting that
everyone using OO techniques is simply following the herd?
[ . . . ]
> Unfortunately, I've never run into one OO book . . . that talks
> about the flipside of OO... instances of which are covered in great
> detail on the tablizer site.
If by "covered" you mean "railed against by someone completely
lacking competence in the relevant disciplines", then you are correct.
Since you claim OO experience, what problems have you,
personally, encountered that lead you to give any credence whatsoever
to Bryce's ramblings?
Sincerely,
Lew
> Bryce Jacobs (posting here and elsewhere under the pseudonym
> Topmind) has admitted in this very newsgroup that he has very limited
> practical experience with OO techniques. Your breathless
> near-sycophancy strongly suggests to me that you are his sock puppet.
Your breathless /ad hominem/ rhetorical style strongly suggests that you are
afraid to address the points on their merits.
--
Lew
Patrick May
I suggest you familiarize yourself with Bryce Jacob's history on
this newsgroup. You will find that he is neither capable of nor
amenable to rational discourse.
If you have a particular point that you believe has not been
addressed, please explain it. Bryce has proven himself to be not
worth responding to; thus far you have not.
Regards,
Lew
> If you have a particular point that you believe has not been
> addressed, please explain it. Bryce has proven himself to be not
> worth responding to; thus far you have not.
Thank you.
I am a fan of both the O-O approach and the "set algebra" of SQL. topmind,
and to a greater extent, frebe have raised points on this thread in favor of
the expressive power of SQL and the relational model.
As a practitioner who has worked with network-model database systems,
relational-model database systems, object-to-relational frameworks, direct
JDBC and integrated RDBMS/front-end products like Paradox and MS-SQL+VB[A], as
well as C++ and Java development, I have learned that object models and
relational models have their value in their respective demesnes. I find that
various O-R frameworks like the Hibernate constellation tend to hamper my
development efforts, because indeed they succeed at abstracting away the
SQLish aspects of the work. OTOH, data abstraction is a Good Thing and I
usually encode an object-to-relational layer of some sort. It's just that
with JDBC calls (in my Java work) I have better control than with the usual
frameworks.
I don't think it's useful to denigrate either the O-O or the RDBMS approaches.
It is a valid criticism that attempts to abstract away the SQL side of
things tends to deprive one of the power of set operations; it is better to
let data manipulation, integrity and views come from the back end to support
the object model of the middle layers.
Kung fu that steals ideas and techniques from all styles is more powerful than
any single style.
--
Lew
Patrick May
> Kung fu that steals ideas and techniques from all styles is more
> powerful than any single style.
A sensible, articulate post with a reasonable conclusion. How do
you expect to fit in on Usenet if you act like that?
Lew
> Lew <l...@nospam.lewscanon.com> writes:
>> Kung fu that steals ideas and techniques from all styles is more
>> powerful than any single style.
>
> A sensible, articulate post with a reasonable conclusion. How do
> you expect to fit in on Usenet if you act like that?
The ultimate troll: stays on topic and works with reason. Drives other trolls
bananas, while doing no harm to the innocent.
--
Lew
topmind
> Lew <l...@nospam.lewscanon.com> writes:
> > Kung fu that steals ideas and techniques from all styles is more
> > powerful than any single style.
But takes 2 lifetimes to learn and transfer to the new batch of
hirees. Kungfooer's only have to win. Software developers have to
share their work. Analogy deflection.
>
> A sensible, articulate post with a reasonable conclusion. How do
> you expect to fit in on Usenet if you act like that?
>
> Regards,
>
> Patrick
-T-
Lew
>>> Kung fu that steals ideas and techniques from all styles is more
>>> powerful than any single style.
topmind wrote:
> But takes 2 lifetimes to learn and transfer to the new batch of
> hirees. Kungfooer's only have to win. Software developers have to
> share their work. Analogy deflection.
Are you saying you missed my point?
No analogy will be perfect in all points; if it were it wouldn't be an
analogy, it'd be the thing itself. The question is whether the analogy served
the purpose in illustrating the message that one should use the best of all
available techniques.
If you want to share your work, this is even more important. It actually
intensifies the point I was making.
The notion that "kungfooers [sic] only have to win" betrays a complete lack of
understanding of the principles of kung fu. Kung fu is about self-mastery and
the graceful accomplishment of perfection. It has absolutely nothing to do
with winning. Analogy deflection completely missed its mark.
The point in all kung fu is to teach the next generation of warriors, not to
hold the knowledge to oneself. Analogy back on track.
--
Lew
Harry
> "Harry" <simonsha...@gmail.com> writes:
> > On Apr 7, 6:37 pm, Patrick May <p...@spe.com> wrote:
> >> Most commercial RDBMSs are based to some extent on relational
> >> algebra, but it is important to note that this doesn't
> >> automatically result in faster, better, or cheaper software
> >> development. Common Lisp is based on the equally formal lambda
> >> calculus but one rarely hears that touted as a benefit in and of
> >> itself.
> [ . . . ]
> > My current understanding is that the RDBMS is a layer [ . . . ]
> > providing me a very valuable, a very significant service in terms of
> > something (set theory) that I'm well familar with since my
> > pre-college days. In absence of any multi-vendor-RDBMS support
> > requirement, I'd very much like my solution to be closest to this
> > layer.
>
> Why?
Why?? What do you mean! If you had a good, very useful (let's say:
an OO) layer (say, X) that was abstracting away something ugly (say,
Y) and providing you a useful service, why would you want to build a
few more layers on top of it and code against them instead of X. The
Facade pattern and its motivations don't apply to the above case
because I (for one) am comfortable with the SQL interface, find it
elegant enough, and would thus want to use, nay exploit, its full
power.
> Bryce Jacobs (posting here and elsewhere under the pseudonym
> Topmind) has admitted in this very newsgroup that he has very limited
> practical experience with OO techniques. Your breathless
> near-sycophancy strongly suggests to me that you are his sock puppet.
And, breathless sycophancy to R. Martin et al would be OK I guess.
Bryce Jacobs is welcome to do a 180° on his stance on OO; it won't
change my current impressions on OO.
My research + experience + insight = My world view.
Please try and refrain from such ad hominems. They serve no useful
purpose.
Thomas Gagne
> <snip>
> Finally, I'd like to suggest that you consider one anecdote.
> I've been in this industry for almost 20 years. I remember when OO in
> general and C++ in particular were first becoming widely used. At the
> time, developers were building client-server architectures using
> procedural and relational techniques. Over the course of a few years,
> many intelligent, experienced developers, all with a solid
> understanding of relational databases and procedural programming,
> began using OO techniques. Those techniques have been continuously
> refined and are still being used today.
>
> What I'd like you to consider is: Does it make sense that every
> one of those developers, despite their understanding of the benefits
> of relational databases, would have started using OO if they found no
> benefits from doing so? Is it really a credible position to imagine
> that such a large group of people would succumb to pure hype?
>
what percentage of today's programming population is made up with folks
from the 80s? Even if we assume /everyone/ from the 80s is doing OO
right a lot of programmers have been added in just the past 10 years and
I suspect new-comers outnumber old-timers. Regardless, the argument is
ad populum: the preponderance of enthusiasm for an idea doesn't doesn't
make it right--it just makes it popular. If popularity was the
definition of success Java would be the best-engineered language known
to computer-science.
Patrick May
> On Apr 8, 7:27 pm, Patrick May <p...@spe.com> wrote:
>> > My current understanding is that the RDBMS is a layer [ . . . ]
>> > providing me a very valuable, a very significant service in terms
>> > of something (set theory) that I'm well familar with since my
>> > pre-college days. In absence of any multi-vendor-RDBMS support
>> > requirement, I'd very much like my solution to be closest to this
>> > layer.
>>
>> Why?
>
> Why?? What do you mean! If you had a good, very useful (let's say:
> an OO) layer (say, X) that was abstracting away something ugly (say,
> Y) and providing you a useful service, why would you want to build a
> few more layers on top of it and code against them instead of X.
And how, exactly, does this demonstrate the value of relational
algebra to real world problem domains?
> The Facade pattern and its motivations don't apply to the above case
> because I (for one) am comfortable with the SQL interface, find it
> elegant enough, and would thus want to use, nay exploit, its full
> power.
What power are you talking about, exactly?
To give you an idea of where I'm coming from, the systems I build
have behavior. They read data feeds, run Monte Carlo simulations,
compute risk, and feed the results to trading systems. They provision
telco network elements. They manage workflows that integrate
disparate COTS systems running over WANs. They broadcast video via
satellite. I want to implement these systems in a language that
matches the problem domain, not in SQL.
>> Bryce Jacobs (posting here and elsewhere under the pseudonym
>> Topmind) has admitted in this very newsgroup that he has very
>> limited practical experience with OO techniques. Your breathless
>> near-sycophancy strongly suggests to me that you are his sock
>> puppet.
>
> And, breathless sycophancy to R. Martin et al would be OK I guess.
Of course not. You have, however, quoted two completely bogus,
unfounded assertions from Bryce Jacobs' site. First, that OO is a
rehash of the network database model. Second, that OO is unsuitable
for dynamic scenarios. No one with any experience with OO techniques
would make either claim.
> Bryce Jacobs is welcome to do a 180° on his stance on OO; it won't
> change my current impressions on OO.
>
> My research + experience + insight = My world view.
You should use your own words, then.
Patrick May
> Patrick May wrote:
>> What I'd like you to consider is: Does it make sense that
>> every one of those developers, despite their understanding of the
>> benefits of relational databases, would have started using OO if
>> they found no benefits from doing so? Is it really a credible
>> position to imagine that such a large group of people would succumb
>> to pure hype?
>>
> The questions isn't whether those early adopters are doing it right,
> but what percentage of today's programming population is made up
> with folks from the 80s? Even if we assume /everyone/ from the 80s
> is doing OO right a lot of programmers have been added in just the
> past 10 years and I suspect new-comers outnumber old-timers.
> Regardless, the argument is ad populum: the preponderance of
> enthusiasm for an idea doesn't doesn't make it right--it just makes
> it popular.
I agree, which is why I also wrote the paragraph that followed
what you quoted:
>> Obviously you should think for yourself and learn the
>> advantages, disadvantages, and applicability of all of these
>> techniques personally. However, there are worse ways to prioritize
>> what you're going to learn than by listening to intelligent,
>> experienced people who have actually delivered working
>> enterprise-scale systems.
> If popularity was the definition of success Java would be the
> best-engineered language known to computer-science.
And Windows would be the pinnacle of OS development. Goddess
preserve us.
Regards,
topmind
Lew wrote:
> Lew writes:
> >>> Kung fu that steals ideas and techniques from all styles is more
> >>> powerful than any single style.
>
> topmind wrote:
> > But takes 2 lifetimes to learn and transfer to the new batch of
> > hirees. Kungfooer's only have to win. Software developers have to
> > share their work. Analogy deflection.
>
> Are you saying you missed my point?
>
> No analogy will be perfect in all points; if it were it wouldn't be an
> analogy, it'd be the thing itself. The question is whether the analogy served
> the purpose in illustrating the message that one should use the best of all
> available techniques.
>
> If you want to share your work, this is even more important. It actually
> intensifies the point I was making.
>
> The notion that "kungfooers [sic] only have to win" betrays a complete lack of
> understanding of the principles of kung fu. Kung fu is about self-mastery and
> the graceful accomplishment of perfection. It has absolutely nothing to do
> with winning.
Well, I guess the analogy ends yet again.
We've already had a big debate on the value of "paradigm pot-purri"
roughly about 7 weeks ago. I don't wish to repeat it today.
> Analogy deflection completely missed its mark.
>
> The point in all kung fu is to teach the next generation of warriors, not to
> hold the knowledge to oneself. Analogy back on track.
>
> --
> Lew
-T-
JXStern
Well, I agree too.
But here's the thing, those people in the 1980s (more like early
1990s) who built client/server systems with C++ and relational -
(cough) me (cough) - maybe didn't know all that much about relational
afer all, and for that matter, RDBMS running on 100mhz (Alpha), 16mb
processors, 10mhz ethernet, 56kb telecom, wasn't all that hot anyway.
HUGE difference from the way RDBMS runs on 8-way 2+ghz 64gb 64-bit
servers, 10mhz WANs, gigahertz server-room backbones, multi-terabyte
SANS, etc. You can finally do "data model" they way it's supposed to
be, and not just isolated tables with an impoverished few FKs.
In the world, a lot of developers went to OO instead of learning more
about RDBMS. OO had until about 1999 before Oracle 8 and SQLServer 7
came out for the first time in industrial strength, on 300mhz
dual-processor Wintel boxes, and relational had something to offer.
And around that time, all the fuss was about getting your web service
to run and route and look nice, so RDBMS was relatively low priority
for another couple of years.
So really, there was nothing much to argue about until very, very
recently. I look at my knowledge level in 1994, and just sneer at
that young punk.
>> If popularity was the definition of success Java would be the
>> best-engineered language known to computer-science.
>
> And Windows would be the pinnacle of OS development. Goddess
>preserve us.
Werd.
J.
topmind
Patrick May wrote:
> "Harry" <simon...@gmail.com> writes:
> > I tend to believe in the power of the RDBMS. Unlike OO, it seems to
> > have a sound mathematical basis, a rigor behind its learning and
> > mastering.
>
> Most commercial RDBMSs are based to some extent on relational
> algebra, but it is important to note that this doesn't automatically
> result in faster, better, or cheaper software development.
I agree. However, it does offer *consistency* of design more so than
OO. There are no OO normalization rules (other than what it tries to
barrow from relational) and something as simple and intuitive as step-
wise refinement of procedural task subdivision (at a smallish scale).
OO is a big soup of organically hack-togethered shanty-town classes.
Of course, metrics for "consistency" are probably hard to come by, but
so far I've not seen many OO'ers claim "consistency" as a selling
point of OO (which is amazing, since they've claimed just about
everything under the sun.)
> Common
> Lisp is based on the equally formal lambda calculus but one rarely
> hears that touted as a benefit in and of itself.
>
> > I do tend to think that *wherever possible*, we should try not to
> > use OO to re-discover and learn lessons that have already been
> > learned a decade or two ago (the network model).
>
> You seem to be channeling [topmind].
Are you saying OO does *not* produce navigational structures? Others
have made the same conclusion regarding OO before I've ever posted to
comp.object even. I did NOT originate that view.
> I'd recommend refraining
> from making statements like this until you have sufficient personal
> experience with OO to understand that competent developers are most
> certainly not doing what you suggest.
Then please do show what you *do* do. Why hide your candle under a
bushel?
>
> > OO may prove very elegant in the modeling of static, noun-oriented
> > relationships as found in mathematics, nature, etc but not
> > necessarily in highly volatile biz scenarios where we cannot and
> > thus never will, fully understand, ever, the implications of our own
> > class design choices.
>
> Again, you're showing your lack of experience with the
> technology.
Accusing the other side of not having experience without producing the
fruits of your own experience for forum inspection is not proper
debate procedure.
> OO techniques have been and are being used to develop
> large, mission critical applications that are flexible in the face of
> constantly changing requirements.
So have some COBOL and assembler applications. What does this prove?
Your logic is weak.
> You should investigate Robert
> Martin's papers and some of the agile approaches to learn how.
Martin holds the typical "device driver" mentality of many OO authors,
and proposes hiding away the database behind beurocratic, busy-work-to-
chage interfaces. (The bloat and inflexibility of his design will
become appearent when I release my version of his payroll example.)
>
> > If there were no incompatibilities in the SQL interface across
> > vendors [ . . . ], I could still consider exploiting the full power
> > of the RDBMS for building a *product*.
>
> OO, procedural, relational, functional, and other techniques are
> not mutually exclusive, despite what you may have been led to believe
> by some overly prolific posters here. Competent developers use the
> combination of tools that provides the greatest benefit in addressing
> the problem at hand. Don't be a one trick pony.
No they don't. Paradigm Pot-purri has large drawbacks, especially from
a staffing angle. Developers love it because it is job security, but
that is a biased view.
>
> Finally, I'd like to suggest that you consider one anecdote.
> I've been in this industry for almost 20 years. I remember when OO in
> general and C++ in particular were first becoming widely used. At the
> time, developers were building client-server architectures using
> procedural and relational techniques. Over the course of a few years,
> many intelligent, experienced developers, all with a solid
> understanding of relational databases and procedural programming,
> began using OO techniques. Those techniques have been continuously
> refined and are still being used today.
Good, then publicly-inspectable evidence of superiority should be
child's play for such an experienced mind. I welcome your
presentation.
>
> What I'd like you to consider is: Does it make sense that every
> one of those developers, despite their understanding of the benefits
> of relational databases, would have started using OO if they found no
> benefits from doing so? Is it really a credible position to imagine
> that such a large group of people would succumb to pure hype?
There are at least these possibilities:
1. They didn't "get" relational and set theory.
2. Paradigms are subjective such that some favor OO and some don't.
3. The hype did indeed trick them. It happens.
>
> Obviously you should think for yourself and learn the advantages,
> disadvantages, and applicability of all of these techniques
> personally. However, there are worse ways to prioritize what you're
> going to learn than by listening to intelligent, experienced people
> who have actually delivered working enterprise-scale systems.
And demand public evidence that you can present to your peers for
review. People who are afraid to have their claims scrutinized are
fairly likely to be flim-flam artists, or perhaps just incompetant
evidence presenters.
Demand Evidence and don't take Bullshit. Software should not be given
a "get out of science free" card.
>
> Good luck,
>
> Patrick
>
-T-
topmind
Patrick May wrote:
>
> > The Facade pattern and its motivations don't apply to the above case
> > because I (for one) am comfortable with the SQL interface, find it
> > elegant enough, and would thus want to use, nay exploit, its full
> > power.
>
> What power are you talking about, exactly?
>
> To give you an idea of where I'm coming from, the systems I build
> have behavior. They read data feeds, run Monte Carlo simulations,
> compute risk, and feed the results to trading systems. They provision
> telco network elements. They manage workflows that integrate
> disparate COTS systems running over WANs. They broadcast video via
> satellite. I want to implement these systems in a language that
> matches the problem domain, not in SQL.
For puke's sake again, show us an example of OO kicking P/R's ass in
these domains. Kill P/R dead with CODE & SCENARIOS, not braggings and
anecdotes.
Don't let your ego write checks that your keyboard can't cash.
> Sincerely,
>
> Patrick
>
-T-
frebe
> > an OO) layer (say, X) that was abstracting away something ugly (say,
> > Y) and providing you a useful service, why would you want to build a
> > few more layers on top of it and code against them instead of X.
>
> And how, exactly, does this demonstrate the value of relational
> algebra to real world problem domains?
I think that have been demonstrated over and over again in all these
sucessful business applications using relational algebra.
> > The Facade pattern and its motivations don't apply to the above case
> > because I (for one) am comfortable with the SQL interface, find it
> > elegant enough, and would thus want to use, nay exploit, its full
> > power.
>
> What power are you talking about, exactly?
I think he is talking about the power of predicate logic and set
theory.
> To give you an idea of where I'm coming from, the systems I build
> have behavior. They read data feeds,
Relational algebra is used for data management, it is not used for
communication (or presentation).
> run Monte Carlo simulations,
Doesn't your Monte Carlo simulatons operate on data? Isn't relations a
suitable way of organizing data in this case? Wouldn't relational
algebra be helpful for doing parts of the calculations?
> compute risk,
Yet again, relational algebra would probably be a very helpful tools
for computing risk.
> and feed the results to trading systems.
Communication tasks is outside the realm of relational algebra.
> They provision telco network elements. They manage workflows that integrate
> disparate COTS systems running over WANs.
Relations would be a perfect tools for modelling workfolows. The
communication part is another issue. You seem to be mixing concerns in
you task descriptions.
> They broadcast video via satellite.
Communication...
> I want to implement these systems in a language that
> matches the problem domain, not in SQL.
If the problem domain is data management, SQL matches it.
> > And, breathless sycophancy to R. Martin et al would be OK I guess.
>
> Of course not. You have, however, quoted two completely bogus,
> unfounded assertions from Bryce Jacobs' site. First, that OO is a
> rehash of the network database model. Second, that OO is unsuitable
> for dynamic scenarios. No one with any experience with OO techniques
> would make either claim.
OO doesn't rehash the network model? I think there are almost a
consensus at comp.object that OO implements the network model. OO is
more than a data model, but it do uses the network data model. Can you
point out the differences?
/Fredrik
Harry
> "Harry" <simonsha...@gmail.com> writes:
> > On Apr 8, 7:27 pm, Patrick May <p...@spe.com> wrote:
> >> > My current understanding is that the RDBMS is a layer [ . . . ]
> >> > providing me a very valuable, a very significant service in terms
> >> > of something (set theory) that I'm well familar with since my
> >> > pre-college days. In absence of any multi-vendor-RDBMS support
> >> > requirement, I'd very much like my solution to be closest to this
> >> > layer.
>
> >> Why?
>
> > Why?? What do you mean! If you had a good, very useful (let's say:
> > an OO) layer (say, X) that was abstracting away something ugly (say,
> > Y) and providing you a useful service, why would you want to build a
> > few more layers on top of it and code against them instead of X.
>
> And how, exactly, does this demonstrate the value of relational
> algebra to real world problem domains?
Relational/procedural style predates OO. The burden of proving the
inadequacy of relational/procedural in "real-world problem domains"
lies on you, not me. Once you're done designing the schema for your
real-world problem, you need to be coming up with a sound, convincing
justification for what *exactly* is lacking at the RDBMS/sql level and
in procedural style that would necessitate invocation of OO.
> > The Facade pattern and its motivations don't apply to the above case
> > because I (for one) am comfortable with the SQL interface, find it
> > elegant enough, and would thus want to use, nay exploit, its full
> > power.
>
> What power are you talking about, exactly?
The ability to *very* easily relate/join, at runtime, two or more
arbitrary tables (provided, of course, it makes sense) is what I
believe is the single biggest powerful feature of SQL/relational. In
OOP, far more thinking and keystrokes (some of which could be avoided,
see below) would typically be involved in accomplishing the same,
'practical' end-result.
> To give you an idea of where I'm coming from, the systems I build
> have behavior. They read data feeds, run Monte Carlo simulations,
> compute risk, and feed the results to trading systems. They provision
> telco network elements. They manage workflows that integrate
> disparate COTS systems running over WANs. They broadcast video via
> satellite. I want to implement these systems in a language that
> matches the problem domain, not in SQL.
And you truly believe P/R can't do any of those things? Each of the
names you've dropped above can be handled outside of OO just as
elegantly, provided you're unbiased and open enough to see elegance in
things other than OO.
> >> Bryce Jacobs (posting here and elsewhere under the pseudonym
> >> Topmind) has admitted in this very newsgroup that he has very
> >> limited practical experience with OO techniques. Your breathless
> >> near-sycophancy strongly suggests to me that you are his sock
> >> puppet.
>
> > And, breathless sycophancy to R. Martin et al would be OK I guess.
>
> Of course not. You have, however, quoted two completely bogus,
> unfounded assertions from Bryce Jacobs' site. First, that OO is a
> rehash of the network database model. Second, that OO is unsuitable
> for dynamic scenarios. No one with any experience with OO techniques
> would make either claim.
There's something in OO 'filosofy' itself (I think!) that tends to
slow you down by encouraging (forcing?) you think hard / 'consciously'
about issues which could otherwise be pragmatically ignored or which
wouldn't normally surface or could be handled in alternate ways in the
procedural world. I'm not saying we all become doofuses and not
exercise our gray matter, or that procedural does not require any
thinking at all... but that, IMO, it does not typically involve that
much of head-scratching. A first-semester programmer, IMO, can very
quickly, almost overnight, become an expert in identifying and writing
procedures. Procedural is mainly action oriented (or, procedural). To
carry out an action, there are steps... step 1, step 2, 3, 4... If
there's a step 3.5 here and a step 2.23 there to be introduced, it is
very easy and straightforward to do so. If you need to add a new
field to a C-struct, boom, you go ahead and add it. In OO however,
you must also pay attention to nontrivial design aspects such as
types, their roles, and their relationships. All this requires an
insight which simply cannot be gained overnight; infact, in most cases
it will take years and years of exposure to not only 'good' but also
'not-so-good' and 'bad' real-world OO designs.
If each type were to truly stand in isolation of and independent from
other types in the system, a major plus of OO (is-a / polymorphism)
will be lost, and the situation would get more or less akin to C-
structs... with may be a bunch of member functions attached (making it
lesser of a namespace pollution). (Note that trying to force an is-a
into a has-a is not only unnatural / unintuitive in some OO
situations, it also involves more (delegation-related) keystrokes.)
And, if an effort *is* made to 'really look around' in the system, in
the problem space... for commonalities, then it becomes a question of
how much thorough / serious / sincere / pedantic / filosofical you
want to get. For example, should I go for pure interfaces or abstract
classes? Traits/aspects? Should I follow the pimpl idiom thruout my
system? Should I forgo the use of new operator in favor of the Factory
pattern? To how much extent should I go in making my classes suitable
for extension/derivation? Is my class final enough to be designated as
such (in Java)? If no, what can I do to make it so? Should I even
worry about the finality of my classes? Should I go for MI (which C++
supports and also exemplifies via the iostream hierarchy), or should I
not go for MI (for, if a successful OO language such as Java and the
bright OO folks at Sun chose to not even support the feature, may be I
too should stay away from MI (within C++))? What should be my Vehical
hierarchy? Should TwoWheeler and FourWheeler be derived from Vehicle?
Or, should Vehicle support a method 'int getNumberOfWheels()'? Or
both? When introducing a Task type (that is capable of running in
parallel with the primary thread of the system)... now, IS Task A
Thread? Or, does Task HAVE A Thread within it? Should I derive it off
of a new GenericTask (an abstract class or an interface)? Hmm... my
system can in near future have sequential (non-parallel) tasks as
well, so let me give this thing some more thought...! If I'm
introducing GenericTask as an afterthought... is my existing class
hierarchy robust enough to handle it... or is it fragile (let me
double check this...)? Etc. Etc. Etc.
OO is about modeling reality. The problem is that we can never truly
and fully understand what reality is, as reality gets revealed (via
our experiments) in stages. The good news, however, is that this
generally is a very slow process in nature... spanning decades if not
centuries. Dare I say, it's slow enough to be stably captured by even
the most ordinary of OO taxonomists. If I model Earth as a planet and
Mars too a planet, it is very unlikely that every few weeks our
scientists would be altering either their status or the definition of
what constiutes a planet! Similary, the blue whale is going to remain
a mammal for a long time (I think). As astutely noted by TopMind (no
sock puppeting here), things don't happen this way in the most if not
all of biz situations... "CatDog's are a real possibility."
In modeling of reality in software, we naturally superimpose *our*
perception of these relationships on our class model. Which is a
*lot* of additional work (compared to p/r where all we're saying is
that this 'object' has this, this, and this attribute and that object
similarly has these other bunch of attributes, and here... here are
the loosely coupled operations you could invoke on them). So, if all
this additional work is in need of frequent re-work, than I fail to
understand what the whole point is!
> > My research + experience + insight = My world view.
>
> You should use your own words, then.
>
Ultimately, there's no such thing! Even the language we're using
right right now is a borrowed one... our parents and teachers sock
puppetted us into speaking a particular way and we continue it to this
day. Originality, some say, is remembering things while forgetting
their source! :-)
Now, sir, with your permission and blessings, I'd like to close this
exchange and get back to my work... a great deal of which (you'd be
pleased to know) is OO- and not P/R-based!
Regards,
Harry.
Thomas Gagne
> <snip>
>
> Relational/procedural style predates OO.
Yes, and spaghetti predated procedural, and COBOL before it, and
assembly before it, and machine language before it. There were other DB
structures before relational, too. It doesn't make them better or
worse. It only makes them older.
> The burden of proving the
> inadequacy of relational/procedural in "real-world problem domains"
> lies on you, not me. Once you're done designing the schema for your
> real-world problem, you need to be coming up with a sound, convincing
> justification for what *exactly* is lacking at the RDBMS/sql level and
> in procedural style that would necessitate invocation of OO.
>
OO-related newsgroups suggests they already accept the value of OO
languages and concepts. The burden of proof lies with those asserting
OO is inadequate. It is not c.o's responsibility to prove anything
about P/R, or even to have a position on P/R at all.
>
> <snip>
>
> OO is about modeling reality.
real-world objects as inspirational rather than coincidental. OO is
more about roles, responsibilities, and messaging, even than it is about
hierarchies.
As you seem to realize, attempting to model the real world is nearly
futile, even for The Architect from The Matrix.
topmind
Thomas Gagne wrote:
> > The burden of proving the
> > inadequacy of relational/procedural in "real-world problem domains"
> > lies on you, not me. Once you're done designing the schema for your
> > real-world problem, you need to be coming up with a sound, convincing
> > justification for what *exactly* is lacking at the RDBMS/sql level and
> > in procedural style that would necessitate invocation of OO.
> >
> You're shifting the burden of proof. Both c.o and c.l.j.d being
> OO-related newsgroups suggests they already accept the value of OO
> languages and concepts. The burden of proof lies with those asserting
> OO is inadequate. It is not c.o's responsibility to prove anything
> about P/R, or even to have a position on P/R at all.
By what debate reasoning do you conclude this? It is NOT
comp.object.evangalism or the like. It is *about* objects, not
necessarily PRO-objects. Being about a topic and being pro-topic are
different animals. Many technical topics in wikipedia rightfully have
a "Criticism" section.
> >
> > <snip>
> >
> > OO is about modeling reality.
> >
> It is not. Programmers often mistake an OO model's similarity to
> real-world objects as inspirational rather than coincidental. OO is
> more about roles, responsibilities, and messaging, even than it is about
> hierarchies.
Note that the "reality" comment is not mine. However, NOBODY AGREES ON
WHAT OOP IS and some OO'ers do claim it is about 'reality'. There is
no consensus. Thus, saying what OO is or is not is going to be sticky
either way. That being said, "roles, responsibilities, and messaging"
is a bit nebulous, especially "messaging". Everything is a message
just about. A query is message, so is HTTP requests and email. What is
different about OO messages?
>
> As you seem to realize, attempting to model the real world is nearly
> futile, even for The Architect from The Matrix.
Note that some OO'ers *do* claim OO is about reflecting the "real
world". I would roughly estimate it to be about 30% of OO fans based
on past debates.
>
> --
> Visit <http://blogs.instreamfinancial.com/anything.php>
> to read my rants on technology and the finance industry.
-T-
Thomas Gagne
> Thomas Gagne wrote:
>
>
> <snip>
>
>>> <snip>
>>>
>>> OO is about modeling reality.
>>>
>> It is not. Programmers often mistake an OO model's similarity to
>> real-world objects as inspirational rather than coincidental. OO is
>> more about roles, responsibilities, and messaging, even than it is about
>> hierarchies.
>>
>
> Note that the "reality" comment is not mine. However, NOBODY AGREES ON
> WHAT OOP IS and some OO'ers do claim it is about 'reality'.
and written about the subject they helped invent.
> There is
> no consensus. Thus, saying what OO is or is not is going to be sticky
> either way. That being said, "roles, responsibilities, and messaging"
> is a bit nebulous, especially "messaging". Everything is a message
> just about. A query is message, so is HTTP requests and email. What is
> different about OO messages?
>
concept than even "objects."
>> As you seem to realize, attempting to model the real world is nearly
>> futile, even for The Architect from The Matrix.
>>
>
> Note that some OO'ers *do* claim OO is about reflecting the "real
> world". I would roughly estimate it to be about 30% of OO fans based
> on past debates.
>
topmind
Thomas Gagne wrote:
> topmind wrote:
> > Thomas Gagne wrote:
> >
> >
> > <snip>
> >
> >>> <snip>
> >>>
> >>> OO is about modeling reality.
> >>>
> >> It is not. Programmers often mistake an OO model's similarity to
> >> real-world objects as inspirational rather than coincidental. OO is
> >> more about roles, responsibilities, and messaging, even than it is about
> >> hierarchies.
> >>
> >
> > Note that the "reality" comment is not mine. However, NOBODY AGREES ON
> > WHAT OOP IS and some OO'ers do claim it is about 'reality'.
>
> That's why it is sometimes helpful to read what OO pioneers have said
> and written about the subject they helped invent.
Which pioneer? Simula was interested in physical simulation (tugboats
and loading docks), while Alan Kay seemed to not emphasize the
physical issues so much.
>
> > There is
> > no consensus. Thus, saying what OO is or is not is going to be sticky
> > either way. That being said, "roles, responsibilities, and messaging"
> > is a bit nebulous, especially "messaging". Everything is a message
> > just about. A query is message, so is HTTP requests and email. What is
> > different about OO messages?
> >
> Alan Kay, Smalltalk's inventor, considered messages Smalltalk's bigger
> concept than even "objects."
That may technically be true quote-wise, but it still does not provide
a clear definition of "message", nor OO.
> >
> >> As you seem to realize, attempting to model the real world is nearly
> >> futile, even for The Architect from The Matrix.
> >>
> >
> > Note that some OO'ers *do* claim OO is about reflecting the "real
> > world". I would roughly estimate it to be about 30% of OO fans based
> > on past debates.
> >
> That's fine. I used to think that, too.
So are those people doing bad OO code until they "get it'?
>
> --
-T-
Harry
> Harry wrote:
> > <snip>
>
> > Relational/procedural style predates OO.
>
> Yes, and spaghetti predated procedural, and COBOL before it, and
> assembly before it, and machine language before it. There were other DB
> structures before relational, too. It doesn't make them better or
> worse. It only makes them older.
No comments on Cobol. Never used it.
Spaghetti is out of consideration here as it is trivially and
universally accepted to be a 'bad thing.'
In enterprise class systems of today, I've never heard anybody going
below the level of C, so assembly and machine languages are out of
consideration as well.
Enterprise class systems of today do, however, have the RDBMS as one
of the their components. Again, am not aware of any other DBMSs other
than Relational ones in use.
Thus, what I wanted to say was: in enterprise class systems of today,
if the RDBMS component is very much in the picture, *and* if it is
providing a nontrivial service with such solid mathematical
foundations as set theory and predicate calculus, *why* would anybody
want to ignore it and proceed to architect additional layer(s) on top
of it?
> > The burden of proving the
> > inadequacy of relational/procedural in "real-world problem domains"
> > lies on you, not me. Once you're done designing the schema for your
> > real-world problem, you need to be coming up with a sound, convincing
> > justification for what *exactly* is lacking at the RDBMS/sql level and
> > in procedural style that would necessitate invocation of OO.
>
> You're shifting the burden of proof. Both c.o and c.l.j.d being
> OO-related newsgroups suggests they already accept the value of OO
> languages and concepts.
c.o Description: Object-oriented programming and languages.
c.l.j.d Description: Databases, java.sql, JDBC, ODBC.
I don't see anything in these descriptions that suggests "they
already accept the value of OO and languages and concepts!"
> The burden of proof lies with those asserting
> OO is inadequate. It is not c.o's responsibility to prove anything
> about P/R, or even to have a position on P/R at all.
My point of view, again, is that if the layer below (the RDBMS) is
providing me with a very rich and valuable service, *and* if the
procedural style is already available, why on earth would I want to
write another set of abstraction layers if I'm perfectly happy and
comfortable with the former's interface?
>
> > OO is about modeling reality.
>
> It is not. Programmers often mistake an OO model's similarity to
> real-world objects as inspirational rather than coincidental. OO is
> more about roles, responsibilities, and messaging, even than it is about
> hierarchies.
>
> As you seem to realize, attempting to model the real world is nearly
> futile, even for The Architect from The Matrix.
>
Now that's a revelation to me! OO devoid of its somewhat
anthropomorphic style of visualizing entities, I think, would leave
big room for design errors. I'll never be absolutely sure if my
concrete classes are correctly pointing to concrete or vague/abstract
concepts.
Dmitry A. Kazakov
> A first-semester programmer, IMO, can very
> quickly, almost overnight, become an expert in identifying and writing
> procedures. Procedural is mainly action oriented (or, procedural). To
> carry out an action, there are steps... step 1, step 2, 3, 4... If
> there's a step 3.5 here and a step 2.23 there to be introduced, it is
> very easy and straightforward to do so.
I used to review code of such people, it is full of cut'n'paste. Students
don't understand abstraction, whether it be procedural, ADT or relational.
It takes much time and efforts to show them how to do it right, to analyse
the program, to be able to explain what the given piece of software does.
> If you need to add a new
> field to a C-struct, boom, you go ahead and add it.
In fact they don't use structures to bind related things together. It is
another abstraction most of them fail gasp.
You know, people don't have instinct of programming.
> OO is about modeling reality.
It is not.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Thomas Gagne
> <snip>
> Thus, what I wanted to say was: in enterprise class systems of today,
> if the RDBMS component is very much in the picture, *and* if it is
> providing a nontrivial service with such solid mathematical
> foundations as set theory and predicate calculus, *why* would anybody
> want to ignore it and proceed to architect additional layer(s) on top
> of it?
>
object models to relational models--even at the expense of one, the
other, or both.
>
> <snip>
>
> My point of view, again, is that if the layer below (the RDBMS) is
> providing me with a very rich and valuable service, *and* if the
> procedural style is already available, why on earth would I want to
> write another set of abstraction layers if I'm perfectly happy and
> comfortable with the former's interface?
>
with it? Aren't you advocating that relational databases are tools
programmers risk under-utilizing if they don't first try to exploit
everything an RDB may provide them?
>
>> <snip>
>
> Now that's a revelation to me! OO devoid of its somewhat
> anthropomorphic style of visualizing entities, I think, would leave
> big room for design errors. I'll never be absolutely sure if my
> concrete classes are correctly pointing to concrete or vague/abstract
> concepts.
>
of the real world, the goal is to create appropriately modeled Java
classes properly subdividing roles and responsibilities to maximize
flexibility, agility, expression, and maintainability. If the result
rhymes with the real world or if you find useful analogies there, that's
not a bad thing. It's just not the goal.
topmind
Dmitry A. Kazakov wrote:
> On 10 Apr 2007 01:02:48 -0700, Harry wrote:
>
> > A first-semester programmer, IMO, can very
> > quickly, almost overnight, become an expert in identifying and writing
> > procedures. Procedural is mainly action oriented (or, procedural). To
> > carry out an action, there are steps... step 1, step 2, 3, 4... If
> > there's a step 3.5 here and a step 2.23 there to be introduced, it is
> > very easy and straightforward to do so.
>
> I used to review code of such people, it is full of cut'n'paste. Students
> don't understand abstraction, whether it be procedural, ADT or relational.
> It takes much time and efforts to show them how to do it right, to analyse
> the program, to be able to explain what the given piece of software does.
That is true *regardless* of the paradigm. One has to walk before they
run. People need to get used to the basics of variables and loops
before they can focus their energies on big-picture design and long-
term maintenence. (Some suggest starting from the big-picture and
working their way down, but most students need to play with concrete
issues before playing with abstract ones. Of course, there are
exceptions.)
Factoring out duplication just because you can is not always the right
answer anyhow. You need experience to know why there is duplication in
the first place and the impact of factoring it out. Not all
duplication is bad, but only the hard knocks of experience will show
you why.
>
> > If you need to add a new
> > field to a C-struct, boom, you go ahead and add it.
>
> In fact they don't use structures to bind related things together. It is
> another abstraction most of them fail gasp.
Premature, perhaps.
>
> You know, people don't have instinct of programming.
I think many do as far as getting something up and running. I've seen
some pretty amazing things from people using merely Lotus 1-2-3
macros. As far as it being maintenance-friendly; well, that is why
they hire us instead.
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
AndyW
I would suggest to you that the number of people in the industry whom
entered the profession in the early 80s is quite large. Many of us
are approaching our early 40s now and many have gone on into other
aspects of software development - including management.
For myself, I can remember the early days of PC development when one
had to write ones own data strorage routines to store data, let alone
have the luxury of having an actual database.
I consider myself an OO specialist but I am also a pragmatist and know
when OO is not suitable and when a mix of the two techniques are
ideal.
When I read some of the discussions on OO it often seems to me that
more often than not what people are talking about is just procedural
development with extensions rather than real OO. Having said that I
have met many OO people who do truly get what OO is and I have also
met many people who wouldnt have the slightest concept about OO simply
because they are too far down the logic path.
And, many people who were around in the 80s may probably remember the
debates about whether maths people could do OO or not because of that
professions reliance on logic. This same argument also occurs in the
RDB vs ODB debate and often when I review the arguments it often comes
down to whether the presons culture is high or low context (wether
they naturaly deal with generalisations and abstractions or whether
they naturaly require detail and logic).
----------------
AndyW,
Mercenary Software Developer
JXStern
>And, many people who were around in the 80s may probably remember the
>debates about whether maths people could do OO or not because of that
>professions reliance on logic. This same argument also occurs in the
>RDB vs ODB debate and often when I review the arguments it often comes
>down to whether the presons culture is high or low context (wether
>they naturaly deal with generalisations and abstractions or whether
>they naturaly require detail and logic).
Did you see the article in the recent CACM, some professor who thinks
cs students should be regularly tested for their ability to abstract,
and expelled from the program, or something, if they don't measure up!
J.
Thomas Gagne
> <snip>
> Did you see the article in the recent CACM, some professor who thinks
> cs students should be regularly tested for their ability to abstract,
> and expelled from the program, or something, if they don't measure up!
>
> J.
>
>
Patrick May
> On Mon, 09 Apr 2007 20:37:37 -0400, Patrick May <p...@spe.com> wrote:
>>>> Obviously you should think for yourself and learn the
>>>> advantages, disadvantages, and applicability of all of these
>>>> techniques personally. However, there are worse ways to
>>>> prioritize what you're going to learn than by listening to
>>>> intelligent, experienced people who have actually delivered
>>>> working enterprise-scale systems.
>
> Well, I agree too.
>
> But here's the thing, those people in the 1980s (more like early
> 1990s) who built client/server systems with C++ and relational -
> (cough) me (cough) - maybe didn't know all that much about
> relational afer all, and for that matter, RDBMS running on 100mhz
> (Alpha), 16mb processors, 10mhz ethernet, 56kb telecom, wasn't all
> that hot anyway. HUGE difference from the way RDBMS runs on 8-way
> 2+ghz 64gb 64-bit servers, 10mhz WANs, gigahertz server-room
> backbones, multi-terabyte SANS, etc. You can finally do "data
> model" they way it's supposed to be, and not just isolated tables
> with an impoverished few FKs.
Moore's Law rocks. I love the fact that my editor of choice,
Emacs, is now considered lightweight.
> In the world, a lot of developers went to OO instead of learning
> more about RDBMS. OO had until about 1999 before Oracle 8 and
> SQLServer 7 came out for the first time in industrial strength, on
> 300mhz dual-processor Wintel boxes, and relational had something to
> offer. And around that time, all the fuss was about getting your
> web service to run and route and look nice, so RDBMS was relatively
> low priority for another couple of years.
That's an interesting argument, but I'm not entirely convinced.
Nearly every system I've worked on, even since OO became ubiquitous,
involved a relational database. I even used to work for a company
that made a CASE tool that supported Gane-Sarson, Yourdon/DeMarco,
and a few other common data modeling approaches. I know a lot of
people with excellent relational, procedural, and OO skills. The
state of the art hasn't remained static.
> So really, there was nothing much to argue about until very, very
> recently. I look at my knowledge level in 1994, and just sneer at
> that young punk.
Ah, if I knew then what I know now.... Oh, wait, we were talking
about software. Sorry.
Patrick May
> On Apr 10, 5:32 am, Patrick May <p...@spe.com> wrote:
>> >> > My current understanding is that the RDBMS is a layer [
>> >> > . . . ] providing me a very valuable, a very significant
>> >> > service in terms of something (set theory) that I'm well
>> >> > familar with since my pre-college days. In absence of any
>> >> > multi-vendor-RDBMS support requirement, I'd very much like my
>> >> > solution to be closest to this layer.
>>
>> >> Why?
>>
>> > Why?? What do you mean! If you had a good, very useful (let's
>> > say: an OO) layer (say, X) that was abstracting away something
>> > ugly (say, Y) and providing you a useful service, why would you
>> > want to build a few more layers on top of it and code against
>> > them instead of X.
>>
>> And how, exactly, does this demonstrate the value of
>> relational algebra to real world problem domains?
>
> Relational/procedural style predates OO. The burden of proving the
> inadequacy of relational/procedural in "real-world problem domains"
> lies on you, not me.
The burden of proof is on the person making the claim. You are
claiming that mapping the solution to an RDBMS and SQL provides value,
so it's your burden to prove it.
Attempting to shift the burden of proof is one of Bryce Jacob's
traits. Admit it: You're a sock puppet.
>> > The Facade pattern and its motivations don't apply to the above
>> > case because I (for one) am comfortable with the SQL interface,
>> > find it elegant enough, and would thus want to use, nay exploit,
>> > its full power.
>>
>> What power are you talking about, exactly?
>
> The ability to *very* easily relate/join, at runtime, two or more
> arbitrary tables (provided, of course, it makes sense) is what I
> believe is the single biggest powerful feature of SQL/relational.
How, exactly, does this translate into value in real world
problem domains (aside from those with an explicit need to join
arbitrary tables)? I'm trying to understand why you believe that all
problem domains are best addressed by mapping the solution to the
relational model.
>> To give you an idea of where I'm coming from, the systems I
>> build have behavior. They read data feeds, run Monte Carlo
>> simulations, compute risk, and feed the results to trading systems.
>> They provision telco network elements. They manage workflows that
>> integrate disparate COTS systems running over WANs. They broadcast
>> video via satellite. I want to implement these systems in a
>> language that matches the problem domain, not in SQL.
>
> And you truly believe P/R can't do any of those things?
No, and I never made that claim.
> Each of the names you've dropped above can be handled outside of OO
> just as elegantly, provided you're unbiased and open enough to see
> elegance in things other than OO.
I agree. Personally, I've found value in the ease with which
domain specific languages can be created in Common Lisp. I'm trying
to understand why you think that RDBMSs and SQL should be used
preferentially. How does being based on relational algebra provide
value in practice?
>> Of course not. You have, however, quoted two completely
>> bogus, unfounded assertions from Bryce Jacobs' site. First, that
>> OO is a rehash of the network database model. Second, that OO is
>> unsuitable for dynamic scenarios. No one with any experience with
>> OO techniques would make either claim.
>
> There's something in OO 'filosofy' itself (I think!) that tends to
> slow you down by encouraging (forcing?) you think hard /
> 'consciously' about issues which could otherwise be pragmatically
> ignored or which wouldn't normally surface or could be handled in
> alternate ways in the procedural world.
Can you provide specific examples?
> I'm not saying we all become doofuses and not exercise our gray
> matter, or that procedural does not require any thinking at
> all... but that, IMO, it does not typically involve that much of
> head-scratching. A first-semester programmer, IMO, can very
> quickly, almost overnight, become an expert in identifying and
> writing procedures. Procedural is mainly action oriented (or,
> procedural). To carry out an action, there are steps... step 1, step
> 2, 3, 4... If there's a step 3.5 here and a step 2.23 there to be
> introduced, it is very easy and straightforward to do so. If you
> need to add a new field to a C-struct, boom, you go ahead and add
> it.
And then you have to recompile and relink every module that uses
it. Then you have to retest everything you just changed.
> In OO however, you must also pay attention to nontrivial design
> aspects such as types, their roles, and their relationships.
You have to pay attention to detail to produce quality software
using any set of techniques. OO gives you more tools in your virtual
toolbox. That's a good thing.
> All this requires an insight which simply cannot be gained
> overnight; infact, in most cases it will take years and years of
> exposure to not only 'good' but also 'not-so-good' and 'bad'
> real-world OO designs.
Another issue that is technique independent. Just because
procedural coding may be easier for many students to learn initially
doesn't mean that it simplifies the creation of solutions to real
world problems. In fact, "beginner friendly" languages can be a
problem. As I tell my Java wielding colleagues, not entirely
facetiously, C++ is a far better language than Java because it is more
difficult to use. With C++ you need a certain level of understanding
in order to get to the point of having a badly running, incorrect
program. With Java, any idiot can get something running, and many do.
Developing quality software requires skill and experience. News
at 11.
> OO is about modeling reality.
No, it is not. The best short summary of the purpose of OO that
I've heard is that "OO is about dependency management." I'm not sure
I buy that 100%, but it's a good first (and second) approximation to
reality.
JXStern
<tga...@wide-open-west.com> wrote:
>JXStern wrote:
>> <snip>
>> Did you see the article in the recent CACM, some professor who thinks
>> cs students should be regularly tested for their ability to abstract,
>> and expelled from the program, or something, if they don't measure up!
>>
>I didn't. Do you have a link?
Is abstraction the key to computing?
Jeff Kramer
April 2007 Communications of the ACM, Volume 50 Issue 4
http://portal.acm.org/citation.cfm?id=1232743.1232745&coll=ACM&dl=ACM&idx=1232743&part=periodical&WantType=periodical&title=Communications%20of%20the%20ACM&CFID=16189888&CFTOKEN=64127060
But you have to be a member.
He's written about it before:
http://www.google.com/search?hl=en&q=%22Jeff+Kramer%22+abstraction
J.
AndyW
wrote:
I'm not a member so cant view the document.
However, as I mentioned above, I think there is a cultural aspect to
peoples natural ability and I dont think it would be an idea to boot
someone from a course on that basis. I come from a generalist culture
and I have often had problems communicating concepts to those of a
more specialist nature and I am sure it goes the other way around.
Harry
> "Harry" <simonsha...@gmail.com> writes:
> > On Apr 10, 5:32 am, Patrick May <p...@spe.com> wrote:
> >> >> > My current understanding is that the RDBMS is a layer [
> >> >> > . . . ] providing me a very valuable, a very significant
> >> >> > service in terms of something (set theory) that I'm well
> >> >> > familar with since my pre-college days. In absence of any
> >> >> > multi-vendor-RDBMS support requirement, I'd very much like my
> >> >> > solution to be closest to this layer.
>
> >> >> Why?
>
> >> > Why?? What do you mean! If you had a good, very useful (let's
> >> > say: an OO) layer (say, X) that was abstracting away something
> >> > ugly (say, Y) and providing you a useful service, why would you
> >> > want to build a few more layers on top of it and code against
> >> > them instead of X.
>
> >> And how, exactly, does this demonstrate the value of
> >> relational algebra to real world problem domains?
>
> > Relational/procedural style predates OO. The burden of proving the
> > inadequacy of relational/procedural in "real-world problem domains"
> > lies on you, not me.
>
> The burden of proof is on the person making the claim. You are
> claiming that mapping the solution to an RDBMS and SQL provides value,
> so it's your burden to prove it.
Nonsense! You can safely assume,
1. I'm an OO dummy.
2. I'm comfortable with SQL/Relational and C-style functions.
Now, *you* need to come up with a sound argument, a convincing
example... of something that *cannot* be done in P/R that would force
me/others to look to OO as our savior! For an OO expert such as
yourselves dealing with 'Large scale, mission-critical, distributed OO
systems design and implementation', this should be a piece of cake.
Man, you can't be so abysmally pathetic! I bet you got badly sucked
into OO without having had the chance to learn and apply P/R
principles properly.
Suggestion: Stop resorting to endless issue evading and name
calling! I don't somehow believe you can be at SP Engineering and
also be *that* stupid so as not to understand with whom lies the
burden of proof in light of the above givens.
> Attempting to shift the burden of proof is one of Bryce Jacob's
> traits. Admit it: You're a sock puppet.
You have an unhealthy obsession with Bryce Jacobs. Is it because he
kicks your sorry a** all the time? Are you sure you're not
<somebody>'s c**dom puppet?
Harry
> > providing me with a very rich and valuable service, *and* if the
> > procedural style is already available, why on earth would I want to
> > write another set of abstraction layers if I'm perfectly happy and
> > comfortable with the former's interface?
>
> Actually, when you put it that way what does "procedural" have to do
> with it? Aren't you advocating that relational databases are tools
> programmers risk under-utilizing if they don't first try to exploit
> everything an RDB may provide them?
> Aren't you advocating that relational databases are tools
> programmers risk under-utilizing if they don't first try to exploit
> everything an RDB may provide them?
Yes. For a change, I'd like to think critically (something I haven't
been doing all these years), and I'd like to start bottom-up... at the
RDBMS layer.
> Actually, when you put it that way what does "procedural" have to do
> with it?
What I'm saying is: the RDBMS component is already an un-ignorable
given in all enterprise-class systems. Now, given also that I happen
to be comfortable writing loosely hanging, C-style functions/
procedures... what advantages OO and its fixed class hierarchies
approach is going to provide me over relational/procedural in terms of
time and money savings, and even elegance?
The answer that I've sort of gotten so far (to my original post) is:
if it's a social, cultural, political, career issue: go with the Java
and the general OO herd. An answer I've come to terms with already.
However, at the technical and purely merit level, I've not so far seen
anybody furnish any convincing argument for NOT sticking to the tried
and tested, simple and intuitive, and mathematically sound and
relatively less subjective P/R techniques.
Patrick May
> On Apr 11, 8:18 am, Patrick May <p...@spe.com> wrote:
>> The burden of proof is on the person making the claim. You
>> are claiming that mapping the solution to an RDBMS and SQL provides
>> value, so it's your burden to prove it.
>
> Nonsense!
No, my statement is an accurate summary of the burden of proof.
In this case, it lies squarely on you.
> You can safely assume,
> 1. I'm an OO dummy.
> 2. I'm comfortable with SQL/Relational and C-style functions.
> Now, *you* need to come up with a sound argument, a convincing
> example... of something that *cannot* be done in P/R that would force
> me/others to look to OO as our savior!
I have never, in this thread or any other, portrayed OO
techniques as a silver bullet. You, on the other hand, have made the
positive claim that mapping solutions to the relational model and SQL
provides value in practice. Defend your claim or retract it.
>> Attempting to shift the burden of proof is one of Bryce
>> Jacob's traits. Admit it: You're a sock puppet.
>
> You have an unhealthy obsession with Bryce Jacobs.
That's just what Bryce Jacobs would say, sock puppet.
Patrick May
>> > The Facade pattern and its motivations don't apply to the above
>> > case because I (for one) am comfortable with the SQL interface,
>> > find it elegant enough, and would thus want to use, nay exploit,
>> > its full power.
>>
>> What power are you talking about, exactly?
>
> I think he is talking about the power of predicate logic and set
> theory.
How, exactly, does that translate to practical benefits in real
problem domains?
>> To give you an idea of where I'm coming from, the systems I
>> build have behavior. They read data feeds,
>
> Relational algebra is used for data management, it is not used for
> communication (or presentation).
Exactly my point, relational algebra doesn't add value in this
part of the problem domain.
>> run Monte Carlo simulations,
>
> Doesn't your Monte Carlo simulatons operate on data? Isn't relations
> a suitable way of organizing data in this case? Wouldn't relational
> algebra be helpful for doing parts of the calculations?
Not necessarily. The amount of data is huge. There isn't a
commercially available RDBMS that can handle the load in the time
available.
Now, that's not saying that a distributed, in-memory relational
database couldn't do so, but it's not clear what value relational
algebra would provide over other techniques in this domain.
>> compute risk,
>
> Yet again, relational algebra would probably be a very helpful tools
> for computing risk.
And again, there are no commercially available RDBMSs that can
perform acceptably in this problem domain. Consider a system
receiving a thousand ticks per second of market data and computing
risk on hundreds of portfolios with tens of thousands of positions
each. This information needs to be made available to other systems
twenty times a second.
>> I want to implement these systems in a language that matches the
>> problem domain, not in SQL.
>
> If the problem domain is data management, SQL matches it.
Not always. Mr. Kazakov has described the "nearest neighbor"
problem several times in this newsgroup. I don't recall seeing a
relational solution.
Another example I've described once or twice before comes from a
financial system similar to those I mentioned above. We had a
directed graph of transactions that had be settled in the order
specified by the edges. That is, a given transaction could not settle
until all of the transactions it pointed to had settled or it had to
settle at the same time as those transactions. The solution involved
identifying all cycles in the graph, converting them to single,
complex transaction nodes, and then doing settlement over the
resulting directed acyclic graph. This system is continuously
modifying the graph based on new input and settles a couple of million
transactions per day.
What value does relational algebra provide in these situations?
Harry
far... even since the beginning of time(!), will you consider doing
the following?
> > You can safely assume,
> > 1. I'm an OO dummy.
> > 2. I'm comfortable with SQL/Relational and C-style functions.
> > Now, *you* need to come up with a sound argument, a convincing
> > example... of something that *cannot* be done in P/R that would force
> > me/others to look to OO as our savior!
Will you? Or, will you prefer remaining in your I-said-You-said
infinite loop?
> >> Attempting to shift the burden of proof is one of Bryce
> >> Jacob's traits. Admit it: You're a sock puppet.
>
> > You have an unhealthy obsession with Bryce Jacobs.
>
> That's just what Bryce Jacobs would say, sock puppet.
Er, let him say that himself. You probably don't realize this: you
accuse me of doing X (which I don't do), and then go ahead and do X
yourself anyways. In addition to X, you innocently think you don't do
Y.
Legend:
X = sock puppeting to BJ.
Y = big time sock puppeting to OO counterparts of BJ
Dmitry A. Kazakov
> That is true *regardless* of the paradigm. One has to walk before they
> run.
You have an idea of locomotion first.
> People need to get used to the basics of variables and loops
> before they can focus their energies on big-picture design and long-
> term maintenence. (Some suggest starting from the big-picture and
> working their way down, but most students need to play with concrete
> issues before playing with abstract ones. Of course, there are
> exceptions.)
No you don't gills, because your ancestors were fishes.
IMO it is a widespread delusion that training should follow the way science
took to research the thing being trained. In schools kids first learn the
physics of XVIII century, to hear 2-3 years later, forget it, that was
wrong. Same with mathematics, even worse.
P.S. I was lucky to participate in an experimental school program. We
started algebra just with the set theory, and used mathematical notation
right from the beginning. I don't remember any problems with that.