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.

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.

We do this because using the RDB query model with table-based indices would be very inefficient for memory-based computing when solving particular problems. That paradigm is fine for generic data storage and access but searching large sets sucks for algorithmic processing.

The emphasis on avoiding large searches goes back to before Nicolas Wirth's "Programs = Algorithms + Data Structures". When solving complex algorithm problems one /always/ tailors data structures to minimize such searches based on unique features of the problem in hand. That tailoring is what application developers /do/. The OO paradigm just provides a bit of help in formalizing that with object-based relationship instantiation.

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.

Did you miss the part in the first message where I said that if one is doing CRUD/USER processing, one should use a RAD IDE rather than an OO approach?

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?

I said, "usually'. You are postulating a class-based search as a problem requirement.

[Even then there are ways to avoid it. For example, one can define a relationship to [Invoice] that only includes unpaid invoices. When an invoice is paid, it is removed from the collection. Whether that (or other optimizations) is viable will depend on other, mostly nonfunctional problem requirements. The point is that the application developer would look for such solutions and would use them if they were viable.]


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.

Again, did you miss the part where I said the OP might be able to save a bunch of keystrokes by not doing OO? Where I said that RAD infrastructures provide a lot of automation that would have to be done from scratch in an OO approach?

In a context where the OO paradigm would be useful, then such a solution would be messy and one would look for a better one. The database engine doesn't have that option, which is pretty much the point of providing generic facilities vs. highly tailored problem solutions.

[Note that I also never said one shouldn't take advantage of the RAD facilities. One should do that in a client-side data access subsystem where the RDB schema is relevant. But when customizing the problem solution data structures one needs to provide the access to those data structures anyway and one needs to do it efficiently through custom tailoring.]

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.

A SQL database allows him to construct CRUD/USER applications quickly because the only problem being solved is data view conversion. That is exactly what the Form/Query/Table RAD paradigm is designed to largely automate and it does a good job of it.

But when you have a problem to solve that requires complex processing of the data, you have to optimize to the problem and provide custom data structures. IOW, you are going to have to provide unique access because the mappings are not the same as in the RDB schema. That's what application design is all about outside of CRUD/USER contexts.

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.

IMO, that is very bad practice for a DBA because it precludes reuse of the data to solve other, different problems.

When one creates a Data Model, it should be based on the overall problem domain rather than specific problems within the domain. If you do that, then the same schema should be reusable by all the core accounting applications.


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

  • Select and updates records based on previous record selections
    ... INVOICE DATA: consisting of Invoice Number, ... PAYMENT DATA: consisting of Invoice Number, customer number, sales order ... number, check number, pay date, pay amount. ...
    (microsoft.public.access.queries)
  • Re: Remove Redundancy in joined tables
    ... return the invoice dates and payment dates in a single column: ... Qty, Amount, NULL AS PaidAmount, ... the payment amounts for the cutomer before the current date. ... customer less the sum of the payment amounts for the customer up to the ...
    (microsoft.public.access.queries)
  • Re: Transportation For Data !!
    ... Think of it as adding products to tblProducts and then dynamically adding them directly to an invoice at the same time. ... bill to customers ... i use filter and all the product from [Invoice Marketing Bill to Customer] will be filtered and only products manufactured by Microsoft Industries Limited will be transferred from to. ... How to use transfer text or add data in a form based that based on a query to another form that based on a different query? ...
    (microsoft.public.access.modulesdaovba)
  • Re: Can (should) an auto number be set up on a invoice (report)?
    ... The staff takes the customer information (stored in the ... The staff then records what procedures the customer wants ... This table stores Customer ID, Concatenated Customer Name (separate query), ... Procedure, Cost, Sales Tax) except for the invoice number. ...
    (microsoft.public.access.reports)
  • Re: Asking too much?? Form-subform based on 4 tables, one is a junction table.
    ... the subform be based on query on the-other one-table. ... One receipt from a customer can be used to pay more than one invoice. ... Then the user will enter the payment amount for each invoice, ...
    (microsoft.public.access.formscoding)