Re: Clean Object Class Design -- What is it?

"Bob Badour" <bbadour_at_golden.net> wrote in message news:AUu17.4164$yr1.75998233_at_radon.golden.net...
> >Why are you hung up on this? What difference is there *semantically*
 between
> >a set and a relation that enforces uniqueness?
>
> All relations enforce uniqueness. All relations are sets. Assuming each of
> set and relation define the same operators, no difference exists at all.
 Of
> course, if an array defines the same operators, no difference exists with
> array either. If a hash defines the same operators, no difference exists
> with it either.

A set is a collection of "things" that are guaranteed to be unique. A bag is a collection of "things" that are not guaranteed to be unique An array is an ordered collection of things. A map is an associative container of keys and things where keys are guaranteed to be unique
A multi-map is an associative container of keys and things where keys are not guaranteed to be unique.

These are different concepts. OK?

> >> An RDBMS does not force one to choose between arbitrary interfaces for
 a
> >> single concept. All information are represented to the user as values
 in
> >> relations. Physical structure is handled independently from logical
> >> interface. One can change the physical bias of the database without
 changing
> >> the logical interface or any of the dependent applications.
> >
> >But we aren't dealing with a single concept.
>
> You were the one who introduced modelling from the perspective of the
> problem space and not from the solution space. The problem space has no
> single inherent ordering of entities. The problem space does not have
> essential performance requirements -- the solution space does.

Yours may not. Mine does. Be careful of the "God complex" where what-I-know-is-all-there-is.

> "Report A must order employees by tenure."
> "Report B must order employees alphabetically by last name, then first
 name,
> then middle initial."
> "Report C must order employees by decreasing salary."

So? I find report generation a toy and singularly uninteresting problem. I wouldn't use an ODBMS for that either, most likely.

> >But "bag" and "set" do not map directly to
> >"relation".
>
> Sure they do. How not?

Because they represent different concepts. You can't have it both ways.

> >You must add constraints on your relation and awkward arbitrary
> >key values
>
> You must have some logical means of identifying your data. This is an
> attribute of the problem space. If you cannot identify a thing, you cannot
> even begin to talk about it. I fail to see what is awkward about this.

In order to normalize data, it is necessary to split repeated values into separate tables. Although the modelling of the data just recognizes the aggregation of the parts by the whole, you must create key values to put into your tables so that you can re-constitute the parts and the whole together. These key values are arbitrary and not inherently part of the problem space, but an artifact of your solution space.

> >And if you are dead set on not learning new concepts then why are you
 even
> >using a computer?
>
> I am not the one who is dead set on learning new concepts. I am not even
> opposed to applying new names to old concepts; although, you have accused
 me
> of such.

You don't want to learn set, bag, array. How else should I take it?

> >Fine. These views are created because someone (you?) programmed them.
>
> Because someone declared them. No programming (in the sense that most of
 our
> audience understands it, at least) is required.

Then your understanding is way too limited. They were "declared" in a language. Transforming a human derived model to computer executable instructions is programming. Just as people program Excel spreadsheets and Word macros.

> >Of course, if the data model was
> >not constructed to support all these views in the first place (e.g.,
> >"department" as a column of "employee" rather than an assignment table
 that
> >links employee to department by date), then you will have to do a bit
 more
> >work. So would I. So where's the beef?
>
> The relational model allows the latter design as well. They content of the
> views would change slightly, but I would not consider it "more" work.

You expect to be paid for it, don't you?

> >I disagree with your assertion that OODBs add needless complexity.
>
> Your disagreement doesn't change the fact that non-relational OODBs add
> needless complexity.

And your opinion is not equivalent to fact.

> >> >> Why does everyone want to throw away the logical model just because
 vendors
> >> >> have failed to deliver on the physical side? Changing the logical
 model
 will
> >> >> only make things worse.
> >> >
> >> >My favorite quote is attributed as Coggins' Law of Software
 Engineering:
> >> >"Elegance must give way to pragmatics because Nature cannot be
 impressed."
> >>
> >> Unfortunately, the quotation does not address any of my questions.
> >
> >Certainly it does. People abandon purity to achieve success.
>
> No, it does not. It explains why people will accept the deficiencies of
> incomplete database products. It does not explain why many people actively
> want to throw away the logical model, the relational data model. This has
> nothing to do with what Nature has given but what these individuals demand
> of Nature.

I've finally figured out that you have been arguing about purely theoretical databases (while criticizing real object databases). Since you've admitted elsewhere that no major vendor can implement the concepts you are clinging dearly to, we are at a major impasse. Some of us still have real systems to build. We cannot afford to cry out from our ivory towers of intellectual purity when there are real deadlines to meet.

> >Actually, the users don't want to have to learn or type arcane SQL
> >statements.
>
> I don't blame them. I doubt the average clerk or administrator is any more
> interested in having to learn or type programmes in an OO language.

And who would ever suggest that they do?

> >Is it POSSIBLE that there is AT LEAST ONE application for which an object
> >database is a superior tool than a relational one?
>
> Since a relational database is an object database, your question cannot be
 a
> matter of the "object-ness" of the database. Presumably, you mean a
> non-relational object database. To answer this, I will need to know in
 what
> ways you think the non-relational database should differ from a relational
> database.

That's odd. I wonder why people like Oracle and Informix have to provide substantial object-relational mapping tools to accomplish the feat you say is inherent. Oh, I forgot, you get to imagine the database you want and hold it up against people who have to use real-world tools for a living.

> >If you answered "no" to the above question, then either you are
 omniscient
> >and therefore God, or you are making a religious assertion based on
> >incomplete information. If you answered "yes", then I can live with most
 of
> >what you've said.
>
>
> And if I gave neither of those answers?

And if I don't answer your question either? Received on Wed Jul 11 2001 - 03:47:50 CEST