Re: Business objects, subset of collection

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.

That is a limitation you have to do, because your solution will
perform too bad otherwise. A relational database on the contrary isn't
limited to only operate on small amounts of data.

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.

Indeed. The only difference is that using a SQL database, the
implementation already exists. Your solution is to create the
implementation by yourself.

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.

Lets say you want to find all unpaid invoices. Why would the n be much
smaller in a OO solution?

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.

These operations are performed by the database. The application
developer doesn't have to care. Everything is already implemented.
Using your solution, you have to implement this by yourself.

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.

The difference is the time the application developer has to spend to
create the application. A SQL database enables him to create the
application much faster, by resuing existing tools. Quality is also a
major benifit, since implementing such features by yourself, you will
inevitable introduce some bugs on the way.

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.

Your claim that a relational schema is designed for "data storage that
is independent of the applications", is debatable. When I design
schemas, I design them to fit the specific customer problem. Why
wouldn't I? If you look at the schemas for three different invocing
applications, you will find three different schemas. There doesn't
exists any application independent schema for invoices. It all depends
on the specific customer problem.

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).

The point is, that you have clearly demonstrated the implications with
having to implement these features by yourself. Data management may be
low-level, but it isn't trivial. That is why using existing products,
like a SQL database, is such a benefit.

//frebe
.

Relevant Pages

  • Re: Can Excel Choose from a List What Makes a Particular Total?
    ... >> Not easily and there would be a lot of potential ambiguity. ... What rule will you use to decide whether to apply the payment to ... And what if your customer is not applying the same rule, ... with one of the invoices, but hasn't gotten around to informing you yet? ...
    (microsoft.public.excel.misc)
  • Re: Can Excel Choose from a List What Makes a Particular Total?
    ... I wasn't sure what you meant by ambiguity, but now I see your point. ... > What rule will you use to decide whether to apply the payment to ... > And what if your customer is not applying the same rule, ... > with one of the invoices, but hasn't gotten around to informing you yet? ...
    (microsoft.public.excel.misc)
  • Re: help calculation in Query
    ... this is how the table looks, it is sorted by customer number so that all the ... Like to take pay/credit amt from invoice # until ... >>the payment for all customers. ... >>invoices could be applied to send payment. ...
    (microsoft.public.access.queries)
  • Re: Is part design lagging cnc capability?
    ... holding onto a big payment with no work. ... tooling for a job that was only worth $500. ... I started out with a cam operated Swiss screw machine. ... customer was still giving me the little 100-600 piece orders, ...
    (alt.machines.cnc)
  • Re: A Builders Terms & Conditions
    ... The Customer accepts liability for the safe custody of materials ... collectors fees incurred in obtaining the said payment. ... 8.Interest Charges On Overdue Accounts ...
    (uk.legal)