Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Wed, 07 Jun 2006 19:40:55 +0200
Message-ID: <44870fa9$0$6195$626a54ce_at_news.free.fr>
Marshall wrote:
> Bruno Desthuilliers wrote:
>
>>Marshall a écrit :
>>
<meta>
Just a quick answer on some points. I won't follow the rest of this
stupid troll.
</meta>
(snip)
> Every part of the application that's going to work on the
> application-specific data must necessarily know the structure
> of that data. The only exceptions would be the kinds of
> things like a math library or some generic utility function
> possibly that you wrote specifically for the app, but none
> of them using any application-specific data structures.
>
(snip)
> Each module in each application needs to know its appropriate
> subset of the database schema. You cannot operate on
> data that you don't the schema for, no matter how many
> times this idea is asserted.
>
(snip)
>
> Again: the application can't not know the structure of its data.
>
You should know better. As a matter of fact, a RDBMS *is* an application. And, as an application, it *is* able to operate on datas whose structures where not known at coding time. Or do you believe that each and any possible SQL schema is already hardcoded into the code of the RDBMS program ?-)
Either you realise this, ask yourself how it is possible (it of course doesn't require OO, that's not the question here - objects are just handy in that they're able to describe themselves and query others), and eventually have a "aha" moment, or you stick to your (mis)conceptions about what is or not possible. FWIW, I just don't care, it's *your* problem, not mine.
(snip)
> Why did you write the query that way, then? Why didn't you
> write the query such that it *did* return the exact data for the
> parts of the application that was doing the query? If one part
> of the app needs one structure and another part needs another,
> *why* would you ever have them use the same query?!
>
> The only reason I can think of for doing such a perverse thing
> would be that you had bought in to this "narrow interface" idea,
> and had cut yourself off from the power of the dbms, in favor
> of your crippled functional API, driven by the limitations of
> your misbegotten ORM, or your devotion to decoupling for
> its own sake, without paying attention to what is being
> decoupled from what.
>
> Your above sentence is a great example of the problems
> that a number of us have been trying to point out all along.
> It supports my thesis perfectly.
>
This - as well as lot of other (snipped) stuff - is not only irrelevant, it's also somewhat insulting. Had you paid any attention to what I wrote, you would have understand that you're actually talking about some other (existing or fantasmatic) person - but not about me.
To make long things short:
- I don't (never ever) use Java, which I consider to be one of the most
braindead languages ever
- I don't have a use for an ORM, I'm perfectly able to write (even
complex) SQL queries.
- I do know how to design and write a program, thanks. And I'm confident
that *you* know how to design and fine-tune and administrate a
relational database.
Here again, I can't (and won't try any further to) stop you from abusing what I say to try and turn me into some fantasmatic representation of someone(s) you don't like. Here again, it's your problem, not mine.
(snip)
>
>>>I cannot make sense of this. The app must know that there exists >>>a set of orders, but knowledge of the orders table, which is nothing >>>more than a set of orders, >> >>An 'orders' table in a RDBMS is not 'a set of orders' - it's how the set >>of orders is represented by the RDBMS. Which is totally different (from >>an implementation POV).
>
>
> Completely incorrect. The orders table in the database is exactly
> and completely a set of orders, and no other thing.
Are really confusing the bits that make your "customers" table with a group of living human beings ?-)
(snip)
> Again, incorrect. The UI has to be written such that it knows
> what fields the orders table contains. It cannot escape having
> this knowedge.
(snip)
>>... The UI code's responsability is to display the user a >>representation of the data (including what's needed to take action on >>these data) that matches the user's view of the data for a given job.
>
>
> And the dbms's job is to supply a representation of the data that
> matches the UI code's query for the data it needs. Their roles
> match up perfectly.
>
> Introducing any layers between them is introducing friction.
<IMHO>This is of course one of the dumbiest possible ways to write an application (using the RDBMS as a flat files being another one)</IMHO>. I pity the poor guys that'll have to maintain it.
But at least posterity will retain that you think the VB direct-sql-to-view mess is a sound design. Lol.
(snip)
> I believe that making existing application languages able to support
> the high level of abstraction found in the relational model will be
> necessary.
Learn a real hi-level language (Common Lisp or OCaml should be good candidates here), realize that Java is to OO what MySQL4 is to the relationel model, and we may talk about "supporting" a "hi level of abstraction".
> For example, once you have declarative integrity
> constraints, you don't need encapsulation.
Once you've learned what encapsulation is, and the profound difference between encapsulation and (so called) data-hiding, you'll realize that what you say here makes no sens. Hint : what are SQL views, and what does one use them for ?
And this will be my last contribution with feeding this troll. Too bad, there could be constructive things coming out from DBA/application programmers discussions. But with so many fanatics around, any tentative to have an open-minded exchange based on mutual respect and open-mindedness seems to be doomed.
Regards,
--
bruno desthuilliers
python -c "print '_at_'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb_at_xiludom.gro'.split('@')])"
Received on Wed Jun 07 2006 - 19:40:55 CEST