Re: domain questionnaire

On Fri, 23 Feb 2001 19:31:46 GMT, "David Cressey" <david_at_dcressey.com> wrote:
>> I've never been able to make any use of the distinction between
>> logical and physical data models -- so I guess I tend to disregard
>> what others may value highly.
>
>I may be misconstruing the difference between logical and physical models,
>but I've always treated them like the difference between interface and
>implementation of objects. That is, those issues that are purely physical
>take place out of the view of the clients of the database.

Well, "physical" in relational tends to mean full specification of association tables, and the like, in my experience, whereas "logical" draws many-to-many arrows directly between tables, or may omit some degrees of denormalization, or the like.

Hmm, perhaps in data warehouse projects with heavy denorms, there would be a point to it! I once did some temporal db work, in which I was all ready to write my own tool, to hide some of the fields and tables necessary to make the temporal stuff work.

>This has to do with ripple effect.

I like strawberry the best, or is that the boone's farm effect?

>Alter a column and you might have to alter the processes that work on that
>column. Alter a table, and you might have to alter many processes that
>work on that table. But alter a tablespace (Oracle), and only the DBA has
>to know about it. The change won't ripple up.
>
>Tablespaces are an example of a physical construct.

I can't recall using a tool that limited its use of the term "physical" to that sort of thing. I would be interested in learning which ones do -- there must be at least one!

>BTW, the difference between the ER model and the Relational model is, as I
>understand it, the difference between the conceptual model and the logical
>model.
>That's not the same as the distinction between the logical and physical
>models.
>Which is the distinction you've never found a use for?

Groan.

Let me be more specific. When I get to the implementation phase, in which I and others are writing stored procedures and presentation-tier code and the like, I've never been able to pass a day without having the physical model in front of me, meaning all attributes of all tables actually instantiated in the database (and, often, some of the reference data populating those tables as well, as that is how domains tend to be realized).

There are places and times in my implementation-centric, commercial-app centric experience, in which higher level conceptual, logical, block diagram, and cocktail napkin diagrams are useful, but when it's time to boogie, they seldom seem to be of much use, unless the full "physical" model is available simultaneously.

If my use of terms does not correspond to some author's or vendor's or poster's practice, please indicate your translation before we spend a lot of time on terminology -- I think the meaning is reasonably clear here. Please note that I do not presume to say that my preferences are those which everyone has or should, I am just yabbering as I tend to new on newsgroups.

Joshua Stern
JRStern_at_gte.net Received on Sat Feb 24 2001 - 00:38:50 CET