Re: Mixing OO and DB

"Patrick May" <pjm_at_spe.com> wrote in message news:m2ir073ms9.fsf_at_spe.com...
> frebe <frebe73_at_gmail.com> writes:
> >> I tried to be very clear with what I was saying. In the large
> >> OO systems that I've worked on, there was no problem with
> >> proliferation of finder methods in practice.
> >
> > In applications there problem with proliferation of finder methods
> > doesn't exists, the find methods have to be very simple, like
> > "select * from employee where id=?". Otherwise the problem do
> > exists.
>
> Not true. The state of each element in the set of root objects
> may be constructed from complex queries over multiple tables. The
> objects reached from those root objects may be lazily loaded, again
> with complex queries. Regardless of the complexity of those queries,
> there is typically no proliferation of finder methods.
>
> >> Typically, once a core set of objects have been instantiated,
> >> access to related objects is via reference rather than repeated,
> >> explicit database access.
> >
> > And obviously introducing synchronization issues...
>
> You are assuming that the database is always the system of record
> and that the system is data-centric. Those assumptions are not always
> valid so your "obvious" synchronization issues do not occur. There
> are more ways of building large scale distributed systems than are
> dreamt of in your RDBMS.
>
The adverb "obviously" qualifies "introducing", not "synchronization", as I read it.

Since the discussion presented an example in SQL, I think the assumptions you refer to are the rule rather than the exception. I'll grant that there is a proliferation of SQL databases embedded in a single application these days, but those databases can be considered as if they were nothing more than intricate files, from the point of view of DB theory.

I agree with your last point, but how many of those "other ways" use SQL as the means of conveying data form one part of the system to another? Received on Fri Feb 29 2008 - 17:42:54 CET