Re: Queries and OO

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/09/05 

Date: Sun, 09 Jan 2005 22:11:16 GMT

Responding to Frebe...

>>But if one has to find the Orders for a
>>given Customer, one must search, albeit optimized by an index, through
>>the entire Order set.
>
> Searching though the entire set is not a correct description. The index
> (BTree) will make the search rather efficient. But yes, navigations with
> pointer in a network database is in this case faster.

I see the B-Tree as just a specialized index. That sort of thing is
what I meant by "optimized by an index".

>
>
>>That requires
>>synchronization on both create and delete of instances due to
>>referential integrity issues.
>
> If you have multiple maps or sorted sets for being able to find and
> traverse objects by different criteras, it can be a lot of container
> objects that needs to be updated when you creates, updates or inserts
> objects. Every time you add a sorted set or map to enable searching in
> a new way, create, insert and delete logic has to be changed. I think
> this one of the reason why network databases was abandoned.

But one deals only with the <binary> relationships that are relevant to
the problem in hand and one instantiates them one at a time. What we
are discussing here is simply providing a collection class on the 1-side
of a 1:* relationship. Whether that relationship is in the RDB or in
the program, it is still a feature of the problem space that one needs
to deal with.

BTW, ordered sets are seen much less frequently in OO applications than
in RDBs. IME, maybe one in fifty relationships are explicitly ordered.
  If processing only Widgets that are green is important to the problem,
a collection for green Widgets will be created and as the Widget objects
are instantiated, the green ones will be added to the collection.

[Adding such collections is logically no different than adding a sort
index to an RDB table. However, it has the advantage from above that no
matter how one optimizes the index, it still involves a search for
access while the dedicated collection does not.]

> Lets say I want to find every order belonging to a given customer, and a
> delivery date less than a given date. In that case there are two
> different solutions. First I can navigate to the customer object,
> traverse
> every order having belonging to this customer and check the delivery
> date.
> The other solution is search the set that are sorted by delivery date,
> traverse every order with a matching date and check which customer it
> belongs to. Which one of these two solutions that is the best,
> depends on many many order the customer have compared to how many
> orders
> that have a maching delivery date. Using a query, the query optimizer
> will make the decision about how to use the indexes. But in a network
> database, the execution order has to be hard-wired.

Alternatively:

            1 generates *
[Customer] ------------------------- [Orders]
      | 1 | *
      | | recently
      | | generated
      | |
      +----------------------------------+

If the given date is truly arbitrary, then one is in the realm of ad hoc
selection and one would need an ordered collection. However, most
specific problems don't have ad hoc selection; the solution rules are
usually very specific. And those with parametric selection rules can
still be handled with a dedicated collection in many cases.

For example, suppose the given date is the beginning of the preceding
quarter (i.e., 'recently' is an Order generated in the current or
previous quarter). At startup the factory object that instantiates
Orders can determine the date of the previous quarter and then add
Orders to the the 'recently generated' collection based on comparison to
that date. As a quarter boundary passes, the instantiation and
navigation logic is the same; just the comparison date changes.

>
> I agree with you that network databases is faster for pre-defined
> simple search-scenarios. But I doubt that they would be faster in more
> advanced scenarios. Why do you thing network databases was abandoned
> in favour of relational databases.

I don't think OO programs have significantly more relationships than
corresponding RDBs. They have a few more because of special situations
or because the application will probably spread the data among a few
more classes than the RDB would spread among tables. But not a whole
lot more. So I don't see the network analogy for OO applications; a
Class Diagram is still pretty close to a Data Model. The real
difference lies in the way they are implemented.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages

  • Re: Relational database & OO
    ... It really doesn't matter to the time management problem solution whether the data is persisted in an RDB, an OODB, flat files, or clay tablets. ... So one could regard the DB Access subsystem I proposed as being a PSE from the perspective of the problem solution. ... I argue that the DB Access subsystem needs to deal with the particular persistence mechanisms that are at hand. ... Here is a basic example that you may find in a customer care & ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... Solve the customer's problem first and then worry about how objects in that solution will map into tables in the RDB. ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... Product, not the OrderLineItem. ... access subsystem to properly access the RDB to obtain the information, ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... > The first thing to do is forget about what the RDB looks like. ... > depends on the Customer identity, ... > Product, not the OrderLineItem. ... > To do that the persistence access subsystem needs to know more about ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... That's because things like product descriptions are unique to the Product, not the OrderLineItem. ... That allows you to address performance problems in RDB access in that subsystem or layer so that it does not affect your problem solution logic. ... The persistence access subsystem needs to map that notion of Order into the actual tables in the RDB. ...
    (comp.object)
  • Re: Queries and OO
    ... > given Customer, one must search, albeit optimized by an index, ... delivery date less than a given date. ... every order having belonging to this customer and check the delivery ... I agree with you that network databases is faster for pre-defined ...
    (comp.object)