Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Many thanks, Marshall, for replying in such a thorough fashion; I don't have a whole lot to add! I'll just elaborate slightly:

Marshall wrote:
> Every part of the application that's going to work on the
> application-specific data must necessarily know the structure
> of that data.

I'll add that every "application" offers a restricted "view" (not the relational sense per se) of the database. This is what applications offer; the ability to present data tailored, sorted, etc. to the needs of a specific user with specific needs. But here's the critical point: the data that's presented (and possibly manipulated) STILL has the same constraints as the data in the DB.

Read any of the recent "updateable view" articles from Date, McGovern, Darwen, and Pascal to get more details (and there are some disputes there too). But the application still needs to obey the rules, and they're the same rules (if not ALL of them, then the applicable subset which doesn't contradict the overall database predicate).

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

Agreed!

> > And even in this case, I wouldn't
> > want to have to retype this exact SQL query in each part of the code
> > where I need to get this representation of the data.
>
> So make an abstraction for it. If it's the right code for several
> different places in the app, it's a fine candidate for a method
> or whatever kind of abstraction you care to make of it. You
> wouldn't do any differently for, say, five consecutive lines of
> Java that was needed in several different parts of the code.

Or make it a view, or some DBMS-specific object like a stored procedure.

> > True, for most of the application's own code[*]. Did I ever claimed
> > otherwise ? Now I still fail to see why would imply that all the
> > application code should have detailed knowledge of the RDBMS schema.
>
> I didn't say it could. It is not the case that all the code needs to
> know all the schema, nor more than it is the case that all the
> code needs to know every class. But every bit of code that
> works with customers needs to know what attributes a customer
> has; there is no escaping it. These attributes will be present
> in the customers table, and present in the customer-specific
> application code. You *can't* get away from that.

Maybe what he's referring to is the application knowing that the data is in relations (or as close as we can get right now)? If so, this argues for MORE relational constructs and operators in the application, rather than less. If you could easily treat your app as a node of the database, you could manipulate in-memory data relationally, not break the rules (since the constraints would also necessarily be present), and easily "persist" (*gag*) the data later (e.g. when the user presses "save").

> > The model is not "an RDBMS". The RDBMS schema is one representation of
> > the model. Which is totally different.

Not at all. A relational schema is a more abstract and powerful model than many other things. Of course, some of this depends on your definition of "model."

> The schema is the model; the model is the schema. What
> would motivate you to have them be different things?

Oy - every time I add something to this subthread, I find Marshall already has...

> I agree that UIs can be quite sophisticated.
>
> But I disagree that users don't care about the schema. Users
> *do* care about the model for the application you are designing.
> They care a lot about what fields a customer entity has. That's
> what the schema is: what entities are there, what attributes do
> they have, what relationships do they have among them? Users
> care about that.

They also care about whether various apps/"sub-apps" give consistent results. Do they want their reports to correlate both with reality and each other? Do they care whether new hire Fred down the hall is corrupting the database? Yes, they care, though they may not have the same vocabulary as we do.

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

Hear, hear.  

• erk