Re: Business objects, subset of collection

On Sun, 27 Jan 2008 01:57:37 -0800 (PST), frebe <frebe73@xxxxxxxxx>
wrote:

select i.invoiceid
from invoice i join payment p on i.invoiceid=p.invoiceid
group by i.invoiceid
having sum(p.amount) < i.amount and datediff(now(), i,duedate) >= 10

This is the kind of code I write every. Even though the number of
invoices and payments are very high, the queries perform within a
number of millis. The customer is happy, I am happy.

Once again, if that is all you are doing, that is CRUD/USER processing;
you are just moving piles of data back and forth between the UI and the RDB.

Maybe you can show your code performing the same task.

You want code for inventory forecasts? A Linear programs to allocate
advertising budget to various markets' media? A simulation model of
atmospheric diffusion?

No. I was asking for the OO equivalence for the SQL statement above.

There isnt one.   But there is a way to achieve the end result -
locating an invoice.

The end result in my query is to find invoices, so please show the OO
equivalence.

One has to remember that OO isnt about lists of related data as
relational DB are.   Its about collections of unique objects.

Is that an advantage or a disadvantage?

To me in OO every instance of an object is unique and that I feel
means if one knows enough of the attributes one can go directly to the
item without searching for it

By pointer traversal? Doesn't you need some kind of hashmaps etc, in
order to "go directtly". Isn't this also a kind of "search`"?

(in the rare case there are duplicate
items they are reference counted).  In close appromimation to
relational, I think its like knowing the primary key but in OO its a
composite key based on the sum of all of the attributes and methods at
a given point in time (this means that an objects identity can
change).

Object identity is a memory adress.

In OO, I would suggest that we also dont have collections of related
data, we have schemas of objects (a set of rules that define the
collection). Schema can also be composite.  In the SQL statement above
as I interpreted it one has a collection of invoices each with
possibly a collection of payments.   The most ideal way of searching
is to go for the one that is easier to find - so if one knows the
payment find that, then transverse to its invoice (like using a
foreign key).   In other words, sometime its better to reverse the
search order given the information known.

A SQL database is very good at doing thing kind of decisions.
Depending on the query and current statistics, it will choose the best
set of indexes to use.

I disagree, SQL only works if the data has been normalised (ordered)
and the statements are optimised. It does not work on non-orded,
disjoint data. In other words its good at lists, but not disjoint
patterns.

Think of it like Bob going into a crowded hall and
shouting out, can Wilma of 43 someplace street please go to the
information kiosk fill in the appropriate form.  Then a short time
later, a faint voice shouts back, ok I am done what next. (this is the
observer pattern)

I order to "shout out" to every object, you need to traverse every
object. The complexity of the algorithm will be O(N). In a SQL
database, with appropriate indexes, most searches will be O(log N).

This is an incorrect assumption. You simply need to set a flag that
the appropriate items are looking out for. This is a common way of
implementing an event model.

So to me in reference to the select statment above, the request is
simply - can everyone who has a sum of money that is now due for
payment, please now execute their request payment routines (remember,
objects contain methods based on their classification as well).  If
one were being smart one could actually provide them a method
invocation to execute - which is called dynamic method invocation.

That means that every object need to calculate the sums and decide if
calling the callback or not. The complexity will be O(N). Using SQL,
you could create a materialized view with the sum columns, create
indexes for them, and you will have O(log N).

Yes, this is correct. Remember that objects contain the code needed to
perform the actions on their own data. This code is encapsulated in
'methods'.

A single method can have an instance for each object or it can have a
single instance across many objects - this is what we mean when we say
a method is static.


So I think the techniques in OO are that objects can find themselves,
objects can manipulate themselves and it can all work in parallel.

That is why so many OO applications have such bad performance.
They dont, in general they are usually hacked by a poorly designed
relational database. Any application both OO and non-OO will suffer

----------------
AndyW,
Mercenary Software Developer
.

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: 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: Expression that wont do a formula, acts as Parameter
    ... the expression builder, the text box stays unbound, and the formula won't ... You cannot reference the Kin's Total and Kin's payment total queries in this ... If the payment and invoice data is in the same field, ... boxes that sum the various quantities. ...
    (microsoft.public.access.gettingstarted)
  • 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)
Quantcast