Re: Business objects, subset of collection
- From: frebe <frebe73@xxxxxxxxx>
- Date: Tue, 15 Jan 2008 06:04:30 -0800 (PST)
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
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).
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
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.
However, that is pretty much why collection classes exist; they manage
collections.
That's pretty much why databases exists, they manage data.
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.
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?
Maintainability may also drive the use of (1) simply because the
internal mechanisms for optimizing around several disparate criteria are
just making the collection object too complex to modify.
Yes, indeed.
Bottom line: in OOA/D one wants to think generically about (2) without
worrying about the details and the OOA/D notations are designed around
that. But at OOP time one is addressing other issues and those may drive
using (1).
Bottom line: Use relational algebra for data management.
//frebe
.
- Follow-Ups:
- Re: Business objects, subset of collection
- From: H. S. Lahman
- Re: Business objects, subset of collection
- From: jimbalo22
- Re: Business objects, subset of collection
- References:
- Business objects, subset of collection
- From: jimbalo22
- Re: Business objects, subset of collection
- From: H. S. Lahman
- Business objects, subset of collection
- Prev by Date: Re: Refactoring into ravioli code
- Next by Date: Re: How should a container class "know" its contained objects?
- Previous by thread: Re: Business objects, subset of collection
- Next by thread: Re: Business objects, subset of collection
- Index(es):
Relevant Pages
|
