Re: Business objects, subset of collection

Responding to Frebe...

invoiceSet = this -> R1 WHERE (date=20080113)
FOREACH invoice IN invoiceSet
// process invoice objects

or

select invoiceid from invoice
where customerid=? and date=20080113

paymentSet = this -> R1 -> R2 WHERE (date=20080113)
FOREACH payment IN paymentSet
// process payment objects

or

select paymentid from invoice i join payment p on
i.invoiceid=p.invoiceid
where customerid=? and p.date=20080113

Yes, they are quite similar. But apropos of your other message, that just reflects that both are based on the relational model. However, the models are quite different because the collection sets are object-based in the AAL but they are table-based for the SQL. The set of invoices and the set of payments examined in the AAL case will usually be much smaller that the corresponding invoice and payment sets in the RDB.

when the user wants payments. [Note that the WHERE clause filters the
date attribute in the target set. When a multistage path is navigated it
is assumed that the membership of the intermediate collections already
limits the set adequately. If not, one needs to do the second fragment
in two stages.]

Using an SQL database we don't have to bother about limiting the
volume of data. In
this case we can assume the indexes to do a pretty good job, O(log n).

There is nothing you can do with an RDB index that can't be done in the implementation of a relationship's collection class. But the 'n' in O(log n) will usually be much smaller in the OO application because the collections are object-based rather than class-based.

This is fine so long as the filter is simple, such as a date. Each
collection is optimized for efficient access via a date. As you point
out, it gets somewhat messy if there are multiple filters (e.g., one
also may want payments where the amount was less than some percentage of
the outstanding balance).

Using relational algebra (SQL) it wouldn't be messy.

select paymentid
from invoice i join payment p on i.invoiceid=p.invoiceid join customer
c on c.custid=i.custid
where customerid=? and p.date=20080113 and p.amount < c.balance*0.10

What is messy is the number of different indices into the same set. When one adds/removes a member of the set, every index must be updated and when a member is modified all the relevant indices must be updated.

Then the collection class needs an interface
for each distinct selection criteria. Each accessor may need a
specialized implementation as well.

Yes, the OO (network) solution is indeed a mess.

Let me see if I understand this. A collection class with multiple interfaces for different selection criteria is a mess but different database queries for different selection criteria is not a mess. A collection class with different implementations for those criteria is a mess but multiple indices on the same table is not a mess.

However, that is pretty much why collection classes exist; they manage
collections.

That's pretty much why databases exists, they manage data.

True, but I'm talking about collection classes, whose database analogue is a table index, not the database itself.


More to the point, that is /all/ they do; they encapsulate
the collection management in one place. IOW, the collection class
isolates and encapsulates complexity of a highly focused nature. In
general that is a Good Thing.

Yes, that's why we uses databases.

For data storage that is independent of applications but this context is about solving specific customer problems.

However, at OOP time one addresses other issues like performance and
maintainability. Suppose Invoices and Payments are very rarely added
compared to how often the various selection criteria are accessed. In
that case it may well be more efficient to have multiple 1:*
relationships in parallel, each with its own optimized collection
mechanics. Thus one has R2A optimized to access by <arbitrary> date and
R2B optimized to access by some amount criteria. For example, one
collection is sorted by date while the other is sorted by amount. The
overhead of adding the same entry to each collection is <hopefully>
small compared to accessing the same elements many times.

What about integrity? If a bug causes an exception after adding the
payment to the collection sorted by date, but before adding to the
collection sorted by amount?
>
What if, you modify the amount and forget to update the collection?
What if you add another search cirteria, and forget one of the add/
modify/delete methods?

And your point is...? Data integrity issues are orthogonal to this context (performance, maintainability).

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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.

Relevant Pages

  • Re: Business objects, subset of collection
    ... with amount due, payment total, etc. ... for the selected vendor ... I think one way to express my point is that the filter is the WHERE clause and one specifies the attributeto be checked in it. ...
    (comp.object)
  • Re: Business objects, subset of collection
    ... from invoice i join payment p on i.invoiceid=p.invoiceid ... locating an invoice. ... composite key based on the sum of all of the attributes and methods at ... A SQL database is very good at doing thing kind of decisions. ...
    (comp.object)
  • Re: Getting Data from 2 Queries into 1 Report
    ... the Payment in a one-to-many relationship. ... to something else that generates your actual invoice and that you may ... the Primary Key of the 'one' table. ... don't include any Lookup Fields! ...
    (microsoft.public.access.gettingstarted)
  • Re: credit card reciept response
    ... transaction is submitted for processing. ... to the consumer or a POST string to a site designated by the merchant. ... Here you accept the POST data, validate it, and mark the invoice ... DO NOT send any order details back to the payment ...
    (comp.lang.php)
  • Re: Business objects, subset of collection
    ... from invoice i join payment p on i.invoiceid=p.invoiceid ... locating an invoice. ... composite key based on the sum of all of the attributes and methods at ... A SQL database is very good at doing thing kind of decisions. ...
    (comp.object)